The Challenge of using more than one object oriented framework has proven to be much larger than I can handle under the stress of my final year project.
Initially I considered differing and starting a new project for another year. All my lecturers advised me to try and finish this project before April 17th.
I resorted to starting over my development using a contingency I had in mind from the beginning; C# using the DOT NET 3.5 framework. I am familiar with the environment, I used it in the development of the last course work in this degree.
There are high risks involved here; just because i used this environment before does not mean i know all the details for every facet of development in DOT NET. I have little experience here as well and I know where one framework will provide advantage I'm sure to find dis advantage as well.
The thing is I know how to create and connect web services in DOT NET so the main hurdle I can cross.
My lecturers advised a few days of rest before i start the next development phase.
So starting next week I have a little over 2 weeks to develop my entire 3 part system and write my report.
Wednesday, March 25, 2009
Week 36 - Monday 23
From Sunday 22nd March 2009
Problems Encounters -
Work on the new platform - Dot Net 3.5 Environment.
Approach -
Seeing as the time frame is so short I have to re thing how i normally approach coding. There was a great advantage with the previous environment that i could write test and the testing framework (Junit and Jmock) would facilitate creating mock object and prevent continuous persistance of test while foundationing integration of test with every build (BVT - Build Verification Testing). Using C# I would have to write my own test. I dont know if i will have time to write test methods. The test strategy may have to change. Instead of automated unit testing I would now have to rely on more user testing of specific modules.
That aside I have decided to build the system in parts keeping the MVC structure used by the Struts 2 App Framework. In parts meaning instead of layer Models first, Controller/ Managers and then Views... I will have all facets (hopefully in time) but I would like to code by process. So I did login already. I have the base users and the dao for that base object and a view. Functionality only. I still need to come up with a design. I will try to do that today.
Time Frame -
12pm Sunday 22 - 3pm Monday
Work Done -
Approach -
Seeing as the time frame is so short I have to re thing how i normally approach coding. There was a great advantage with the previous environment that i could write test and the testing framework (Junit and Jmock) would facilitate creating mock object and prevent continuous persistance of test while foundationing integration of test with every build (BVT - Build Verification Testing). Using C# I would have to write my own test. I dont know if i will have time to write test methods. The test strategy may have to change. Instead of automated unit testing I would now have to rely on more user testing of specific modules.
That aside I have decided to build the system in parts keeping the MVC structure used by the Struts 2 App Framework. In parts meaning instead of layer Models first, Controller/ Managers and then Views... I will have all facets (hopefully in time) but I would like to code by process. So I did login already. I have the base users and the dao for that base object and a view. Functionality only. I still need to come up with a design. I will try to do that today.
Time Frame -
12pm Sunday 22 - 3pm Monday
Work Done -
- Started Database in SQL Server 2005
- Wrote the basic objects necessary for login.
- Login Successful ...
Problems Encounters -
- Familiarity with the environment
After working for more than half a year in java and using a conglomeration of frameworks its a very sharp turn to get back into the mode of thinking necessary to build in C#. I have used C# and the .Net environment before, for course work and briefly at one of my previous jobs (The job experience was VB not C but in .Net 3.5). The previous experience could not displace the mental conditioning of working in so many different inter working Java frameworks - even though they provided differing functions and they individually varied in syntax it was still java and xml mostly and i grew dependently familiar with the style of syntax, use of annotations and other new things i was never previously aware of in Programming code. - When i attempted to test the first DAO it continually failed.
The DAO code seemed fine. After 2 hours I moved around the code accessing it. Eventually after tweaking the 'code behind' of a web form the failures proved to be just lack of practice with the language. - I am constantly mixing up the design patterns. I used Facade the last time I built in .Net - And I am only a student programmer. As a result i realise i have associated the pattern with the environ. I learnt MVC in java. So some mental re - arranging is necessary.
Week 34
FrameWork Problems.
Before entering the actual objects in the framework I did the tutorial for the appfuse site. The tutorial exposed the Manager Classes as web services and the tutorial shows how access the WSDL when the service is accessible via XFire.
However when further test were done to try and consume the service .... they failed terribly.
In the beginning the only test that i did were to simply to view the WSDL ....
I realise now that may have been the biggest mistake of this project.
The following are some of the efforts i took to try and remedy the problem.
I also sent a mail to the man behind the scenes in appfuse asking for guidance ,,, and his response was that he never used a GUI (i figured as much) and therefor could not guide me further.
Before entering the actual objects in the framework I did the tutorial for the appfuse site. The tutorial exposed the Manager Classes as web services and the tutorial shows how access the WSDL when the service is accessible via XFire.
However when further test were done to try and consume the service .... they failed terribly.
In the beginning the only test that i did were to simply to view the WSDL ....
I realise now that may have been the biggest mistake of this project.
The following are some of the efforts i took to try and remedy the problem.
- XFIRE - I read through the documentation - it was so confusing. With the feeling of panic in my mind i read and re-read almost every config page trying to map something to my code.
http://xfire.codehaus.org/Quick+Start
http://xfire.codehaus.org/Spring%2C+XBean%2C+Servlets+and+more
The are undergoing some serious upgrades so the XFIRE they are currently using will be obsolete soon. This does not vote well where pages are being removed and the site being revamped. - I read alot of appfuse stuff - the big problem here is that the guides for adapting XFIRE from appfuse's support is to build in ANT and well Appfuse 2 is by default in MAVEN ...
I cannot explain the the disheartenment I feel ...
http://raibledesigns.com/wiki/AppFuseXFire.html - I tried the forum a couple of time - i only got one response which was not helpful
- The next thing that i did took me into the next week.
I tired to use an IDE - Netbeans to edit the project to create the web services .... this too was a task of emmense hardship.
I also sent a mail to the man behind the scenes in appfuse asking for guidance ,,, and his response was that he never used a GUI (i figured as much) and therefor could not guide me further.
Monday, March 23, 2009
Week 33
Development
Design -
The MIS design is a simple one. The three object with their relative composition and relationship links. The design's most complex parts is the middleware and even though i have the requirements, working out how these actions will get done is still a blur in my head.
I started putting the actual code together in the frameworks I am using. This week I successfully built a basic structure and I'm coding in the objects slowly but surely.
The process of entering an object in appfuse and configuring it is very structured and a bit more work that I am used to.
First we must write the POJO (Plain Old Java Object).
With Setters and getter, no args constructor and to string methods.
Then each object that must be persisted must have a DAO interface and an implementation of that interface.
The access to the DAO's is provided by managers. The actual manager class is the interface and there must be a implementation of the interface (just as with the DAO).
The next step is to define an action class for the object. The action class is the connection between the web tier of the system and the business logic.
We implement the logic with the Objects and their DAO's and the managers and the Web Application part is structured in using Struts2 in appfuse as a separate logic. (This makes it significantly easier to extend implementation of either part of the whole app)
So I have all the objects thus far connected and using the hibernate annotations to be persisted to the databases. Joining the tables took some work ... but the associations and the compositions are cohesive and working.
Also the framework (Struts2) promotes test first development. This means that the managers, DAO and action classes all have test that are written before the actual classes.
Test driven architecture.
Design -
The MIS design is a simple one. The three object with their relative composition and relationship links. The design's most complex parts is the middleware and even though i have the requirements, working out how these actions will get done is still a blur in my head.
I started putting the actual code together in the frameworks I am using. This week I successfully built a basic structure and I'm coding in the objects slowly but surely.
The process of entering an object in appfuse and configuring it is very structured and a bit more work that I am used to.
First we must write the POJO (Plain Old Java Object).
With Setters and getter, no args constructor and to string methods.
Then each object that must be persisted must have a DAO interface and an implementation of that interface.
The access to the DAO's is provided by managers. The actual manager class is the interface and there must be a implementation of the interface (just as with the DAO).
The next step is to define an action class for the object. The action class is the connection between the web tier of the system and the business logic.
We implement the logic with the Objects and their DAO's and the managers and the Web Application part is structured in using Struts2 in appfuse as a separate logic. (This makes it significantly easier to extend implementation of either part of the whole app)
So I have all the objects thus far connected and using the hibernate annotations to be persisted to the databases. Joining the tables took some work ... but the associations and the compositions are cohesive and working.
Also the framework (Struts2) promotes test first development. This means that the managers, DAO and action classes all have test that are written before the actual classes.
Test driven architecture.
Tuesday, February 24, 2009
Week 32
Requirement & Use Cases.
The Requirements for the Mock MIS is easily derived.
They came directly from the user stories.
Even thought the MIS will only provide a subset of the functionality of an actual system it was important to derive functions and object common to the different departments.
Three object that apply to all the academic departments were chosen;
Academic Body - Universities and Boards
Programme - A Degree / Diploma
Course - Subjects within a programme
ID Requirement Description – Mock MIS
01 Add Academic Body
02 Add Programme
03 Add Course
04 Edit Academic Body
05 Edit Programme
06 Edit Course
07 Remove Academic Body
08 Remove Programme
09 Remove Course
10 Notify Middleware
11 Send Update
ID Requirement Description - Middleware
12 Receive Notification
13 Process Notification
14 Request Update
15 Receive & Publish Update
Use Cases will be used to detail each requirement.
The Requirements for the Mock MIS is easily derived.
They came directly from the user stories.
Even thought the MIS will only provide a subset of the functionality of an actual system it was important to derive functions and object common to the different departments.
Three object that apply to all the academic departments were chosen;
Academic Body - Universities and Boards
Programme - A Degree / Diploma
Course - Subjects within a programme
ID Requirement Description – Mock MIS
01 Add Academic Body
02 Add Programme
03 Add Course
04 Edit Academic Body
05 Edit Programme
06 Edit Course
07 Remove Academic Body
08 Remove Programme
09 Remove Course
10 Notify Middleware
11 Send Update
ID Requirement Description - Middleware
12 Receive Notification
13 Process Notification
14 Request Update
15 Receive & Publish Update
Use Cases will be used to detail each requirement.
Week 31
The following is a diagram depicting the current system as I understand it.
The analysis will include ... a justification of why we are using middleware as the connecting technology. This software could have easily been constructed where the website is in MIS and published from the same server. The MIS could directly interact with the website to publish updates and the system would be significantly simpler in design.
There are several disadvantages to the latter method - commonly refered to as integration.
Disadvantages:
Advantages:
The feasibility analysis compared the following;
The user stories should come after and hopefully be a proper lead into the design that follows.
The analysis will include ... a justification of why we are using middleware as the connecting technology. This software could have easily been constructed where the website is in MIS and published from the same server. The MIS could directly interact with the website to publish updates and the system would be significantly simpler in design.
There are several disadvantages to the latter method - commonly refered to as integration.
Disadvantages:
- Highly coupled design
- Difficult to expand
- Limited load capacity / or capacity relative to hardware
Advantages:
- Simple design
- Simple configurations
- Likely a more cost effective solution
The feasibility analysis compared the following;
1. Technical
2. Operational
3. Economical
4. Schedule
The user stories should come after and hopefully be a proper lead into the design that follows.
Tuesday, February 10, 2009
Week 30
Analysis
User Stories -
The user stories will be initially drafted by me and then sent to the departments for approval. This way the users dont need to spend too much time bogged down with the details of what the project entails and how i need to go about achieving it. When I meet with the department representatives for the second time to show them the user stores that I created, I will give a brief of what type of the system the stories represent.
The user stories will be tied to testing. No its not that strange. For each User story there will be on the same document a corresponding test case. The user stories will be used as a starting place for the user stories that will lead directly into the design but they will not be able to give an appropriation of design time. The user stories will only cover the basics of the Mock MIS operation and therefore cannot be an estimation of the entire development process.
http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
Mountain Goat Software outlines the advantages of user stories. It also individualizes user stories from use cases and requirement definitions.
There is a very good metaphor identifying user stories with goals instead of requirements. This really brought home to me the meaning of what the user story should tell and maybe how to tell it. They described requirements and made mention of the IEEE style for writing them. They contrasted on how formal requirements can be unclear when trying to outline the general or rather actual wants of the user in contrast to a goal. And how a user story is not a goal but rather a description of a goal in the form of a story.
The following resources were also used in forming the methods used for collecting and writing the user stories.
http://www.agile-software-development.com/2008/01/example-of-user-story.html
http://dannorth.net/whats-in-a-story
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
http://www.agilemodeling.com/artifacts/userStory.htm
Work Flow Diagram -
User Stories -
The users will have direct input into the user stories that will foundation the Use Cases for this analysis. According to research user stories should be ideally written by the users themselves. In this case the MIS being constructed is for the purpose of demonstrating the functionality of the middleware and not its (The MIS) functionality. As a result the detail that the users may want to include in user stories would exceed the needs of this system. The user stories should cover enough functionality to modle some of the interactions the user would engage in daily processes. The MIS will not however model these processes in detail. If the users were left to propagate the stories on their own they would most likely exceed the detail necessary and loose sight of the focus of the *Mock MIS*.
The user stories will be initially drafted by me and then sent to the departments for approval. This way the users dont need to spend too much time bogged down with the details of what the project entails and how i need to go about achieving it. When I meet with the department representatives for the second time to show them the user stores that I created, I will give a brief of what type of the system the stories represent.
The user stories will be tied to testing. No its not that strange. For each User story there will be on the same document a corresponding test case. The user stories will be used as a starting place for the user stories that will lead directly into the design but they will not be able to give an appropriation of design time. The user stories will only cover the basics of the Mock MIS operation and therefore cannot be an estimation of the entire development process.
The four simple rules outlined by David Churchville on the Agile Project Planning blog is a clear guide for writing user stories and I employed these guidelines as thoroughly as possible.
http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
Mountain Goat Software outlines the advantages of user stories. It also individualizes user stories from use cases and requirement definitions.
There is a very good metaphor identifying user stories with goals instead of requirements. This really brought home to me the meaning of what the user story should tell and maybe how to tell it. They described requirements and made mention of the IEEE style for writing them. They contrasted on how formal requirements can be unclear when trying to outline the general or rather actual wants of the user in contrast to a goal. And how a user story is not a goal but rather a description of a goal in the form of a story.
The following resources were also used in forming the methods used for collecting and writing the user stories.
http://www.agile-software-development.com/2008/01/example-of-user-story.html
http://dannorth.net/whats-in-a-story
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
http://www.agilemodeling.com/artifacts/userStory.htm
.
Work Flow Diagram -
Week 29
Analysis
Interviews -
I hope to publish the general findings from the interviews here. Time permitting i would like to submitt for the report the findings of the interviews as a diagram or picture. I hope that turns out well - because the interviews will be short my notes will be consice and mostly scribblings; that wount be acceptable as a document.
I hope to draft the similarities and differencs as either a rich pic or a flow diagram and this should link nicely into the requirements for the the first part of the code - The MIS.
Also I intend to turn the conversations into User Stories. I have a whole lot of documents on user stories and I in the next post i will publish some of what i hope to use and the links referencing the documents. After the interviews i will publish my approach to the stories and the requirements. These techniques are in line with the Agile Development path. They include methods like user involvement and having cases and scenarios documented that bring the developer closer to the users understanding of the functionality expected. This hopefully will result in less rework as a result of mis communication.
Interviews -
After review of the methodologies I am using and consideration of the scenario I think that informal interviews will be more appropriate than a set formal questions. I conveyed my thoughts to my project lecturer and my arguments were convincing.
The system composes of 3 parts (front end MIS, middleware and a web site) and each will have to be developed in a separate stage (since I am only one developer). I know for a fact as a amateur and very junior developer attempting to code 3 different systems at the same time is too much for me. Each part of the system will be based on the business processes and business logic of the school's departments who actually use these processes. Even though there will be one analysis I believe that I will have to revisit the people from the original interviews for additional information and confirmation of some of the details involved in the logic of the software. It would serve the project and the employees (SBCS staff) to have a more casual interaction with short conversations instead of structured interviews and questions.
The system composes of 3 parts (front end MIS, middleware and a web site) and each will have to be developed in a separate stage (since I am only one developer). I know for a fact as a amateur and very junior developer attempting to code 3 different systems at the same time is too much for me. Each part of the system will be based on the business processes and business logic of the school's departments who actually use these processes. Even though there will be one analysis I believe that I will have to revisit the people from the original interviews for additional information and confirmation of some of the details involved in the logic of the software. It would serve the project and the employees (SBCS staff) to have a more casual interaction with short conversations instead of structured interviews and questions.
- This way the staff members do not have to structure strict meeting times that would interrupt their schedules.
- I could contact the interviewees via emails or visits to the office (on the days i have class) and I would take care to solicit their time in the most unobtrusive way possible.
- The information from a casual conversation would more honestly describe the users experience with the system and how they feel about certain processes and how they may be reworked for efficiency.
- This way users get to see parts of the system progressivly and their input can be filtered-in incrementally into the design process. (This is a project with a deadline and as a new developer i know i will miss some ingredients in the initial phases - by including the users and constantly having their feedback in small amouts; I hope to catch at least any key points initially left out.)
I hope to publish the general findings from the interviews here. Time permitting i would like to submitt for the report the findings of the interviews as a diagram or picture. I hope that turns out well - because the interviews will be short my notes will be consice and mostly scribblings; that wount be acceptable as a document.
I hope to draft the similarities and differencs as either a rich pic or a flow diagram and this should link nicely into the requirements for the the first part of the code - The MIS.
Also I intend to turn the conversations into User Stories. I have a whole lot of documents on user stories and I in the next post i will publish some of what i hope to use and the links referencing the documents. After the interviews i will publish my approach to the stories and the requirements. These techniques are in line with the Agile Development path. They include methods like user involvement and having cases and scenarios documented that bring the developer closer to the users understanding of the functionality expected. This hopefully will result in less rework as a result of mis communication.
Friday, February 6, 2009
Week 28 - The Framework
Two Things -
The Framework under primary consideration is Struts2 using an integration framework called Appfuse . Struts2 falls under the J2EE environment (that's Java) and is a framework for web centric development. Its is very important to note the purpose of Appfuse. It fuses Struts with a set of other (popular) frameworks to provide a nice MVC platform for software development. It can use a combination of Spring, Hibernate, IBATIS, JPA, Tapestry (and some others) and it builds with Ant or Maven.
All this means is that, Appfuse puts frameworks gered to different implementation solutions (front end, back end, persistence, security ect.) into a bundle and helps with the configurations that were previously very cumbersome. (It is so helpful - that if i were asked to develop using the frameworks without appfuse as an amateur programmer I would never attempt to configure all these on my own - it would certainly be a formidable task).
Part 2 -
This project is composed of 3 parts and their inter-workings; together they are a challenge for a single designer. The coagulation of frameworks serves as a great foundation for a project of this scope. It comes with some built in functionality that will greatly ease the programming burden from tasks that are required for the system to run but are not necessary to demonstrate the core functionality of the middleware. Learning the functionalities of the facilitating technologies and how to use their APIs is a project in itself.
I started learning the framework in late July 2008. It took me a month just to get the framework to Build Successfully. At the time when the framework was up and running, I was proud and happy. Now it seems sometimes like a false celebration. Every day this code throws something new at me. The next series of entries I hope to out line some of the difficulties I encounter.
I am thankful though. The little knowledge I have of computers has served me well. One of the first issues when trying to build my first project was actually exposed later on on the official website as a common occurrence. At the time of course I found little or no support online for the tomcat server that would download nicely but not execute. That was so frustrating. I followed the exception (stated the distribution was corrupted ) to the Locals \ Temp folder where Tomcat was being downloaded to and examined the .zip package. The file did not seem corrupted and the exe ran fine. However in the folder was also the unzipped package which the framework was using to execute. I looked at the innards but most ignored it b/c, it was the same as the zip file just unzipped.
Now after trying for a few nights to pull the tomcat from alternate sources by editing the xml configurations in appfuse and redirecting where it downlowaded that dependancy and had the same probelm over and over, I went back to the tem folder. When I looked at the folder structure of the Unzipped files i noticed something; the Root folder was Tomcat X (the version) and in it contained another folder Tomcat X (version). I thought what if the program was looking in the root for the the exe and the dependant files. It would obviously fail b/c they were not there, they were in a sub folder. Look at that - The stupid local zip program was confusing the poor framwork, not to mention driving me insane for a few nights with little sleep. (And shcool was out - what would happen to me when i had classes and a job and had to do this at night - would I survive - that is still left to be seen...). I restructured the folders to what i thought the framework was expecting and I ran the installation offline. Appfuse allows you to download everything into a repository so your system can build and run offline. Now the idea worked, just not the first time. It took some working into but eventually it ran and I was happy I could finally start learning to use the thing.
The online tutorials are sufficient. After starting to follow them school, course work for another course (DIS) and all the research for this project and deliverables and the deadlines that came along with all these things took precidence and when I finally got back to the framework tutorials in late October (yes months passed) I felt a little lost and resorted to starting over.
Over the Christmas holidays I got throught the most of it, however another deliverable in January did not help my timeline where I planned to have started the actual project application or at least a mock of it.
So here's to the following weeks and the hope that I can apply all that I have learned to the app I have envisioned for the Final Project (and somewhere in between execute and document my analysis and the rest of the writeup).
http://appfuse.org/
http://struts.apache.org/2.x/
- The Framework Justification
- My History with the Framework
The Framework under primary consideration is Struts2 using an integration framework called Appfuse . Struts2 falls under the J2EE environment (that's Java) and is a framework for web centric development. Its is very important to note the purpose of Appfuse. It fuses Struts with a set of other (popular) frameworks to provide a nice MVC platform for software development. It can use a combination of Spring, Hibernate, IBATIS, JPA, Tapestry (and some others) and it builds with Ant or Maven.
All this means is that, Appfuse puts frameworks gered to different implementation solutions (front end, back end, persistence, security ect.) into a bundle and helps with the configurations that were previously very cumbersome. (It is so helpful - that if i were asked to develop using the frameworks without appfuse as an amateur programmer I would never attempt to configure all these on my own - it would certainly be a formidable task).
Part 2 -
This project is composed of 3 parts and their inter-workings; together they are a challenge for a single designer. The coagulation of frameworks serves as a great foundation for a project of this scope. It comes with some built in functionality that will greatly ease the programming burden from tasks that are required for the system to run but are not necessary to demonstrate the core functionality of the middleware. Learning the functionalities of the facilitating technologies and how to use their APIs is a project in itself.
I started learning the framework in late July 2008. It took me a month just to get the framework to Build Successfully. At the time when the framework was up and running, I was proud and happy. Now it seems sometimes like a false celebration. Every day this code throws something new at me. The next series of entries I hope to out line some of the difficulties I encounter.
I am thankful though. The little knowledge I have of computers has served me well. One of the first issues when trying to build my first project was actually exposed later on on the official website as a common occurrence. At the time of course I found little or no support online for the tomcat server that would download nicely but not execute. That was so frustrating. I followed the exception (stated the distribution was corrupted ) to the Locals \ Temp folder where Tomcat was being downloaded to and examined the .zip package. The file did not seem corrupted and the exe ran fine. However in the folder was also the unzipped package which the framework was using to execute. I looked at the innards but most ignored it b/c, it was the same as the zip file just unzipped.
Now after trying for a few nights to pull the tomcat from alternate sources by editing the xml configurations in appfuse and redirecting where it downlowaded that dependancy and had the same probelm over and over, I went back to the tem folder. When I looked at the folder structure of the Unzipped files i noticed something; the Root folder was Tomcat X (the version) and in it contained another folder Tomcat X (version). I thought what if the program was looking in the root for the the exe and the dependant files. It would obviously fail b/c they were not there, they were in a sub folder. Look at that - The stupid local zip program was confusing the poor framwork, not to mention driving me insane for a few nights with little sleep. (And shcool was out - what would happen to me when i had classes and a job and had to do this at night - would I survive - that is still left to be seen...). I restructured the folders to what i thought the framework was expecting and I ran the installation offline. Appfuse allows you to download everything into a repository so your system can build and run offline. Now the idea worked, just not the first time. It took some working into but eventually it ran and I was happy I could finally start learning to use the thing.
The online tutorials are sufficient. After starting to follow them school, course work for another course (DIS) and all the research for this project and deliverables and the deadlines that came along with all these things took precidence and when I finally got back to the framework tutorials in late October (yes months passed) I felt a little lost and resorted to starting over.
Over the Christmas holidays I got throught the most of it, however another deliverable in January did not help my timeline where I planned to have started the actual project application or at least a mock of it.
So here's to the following weeks and the hope that I can apply all that I have learned to the app I have envisioned for the Final Project (and somewhere in between execute and document my analysis and the rest of the writeup).
http://appfuse.org/
http://struts.apache.org/2.x/
Monday, January 26, 2009
Week 27 - Draft Interim Report Hand-Up
So the draft is in and here are some thoughts:
I'm tired. This project is alot of work and the initial enthusiasm is wearing. It's not all gone, I still like what I am doing and I'm very intrigued by my topic area (I hope to make a career out of it afterward or at least a hobby) however this was only a draft report and it took the wind out of me; I can only imagine what the real guts of the thing will smell like.
I am thinking about the analysis and I a have had some brief discussions with some of the technical staff at the school and my project lecturer about less formal ways of information gathering. I know for a fact that the information gathering process will be an ongoing one and a single interview or questioner will not be sufficient. Also i have the feeling that if i need to constantly go back to the same staff to get information that they will be more willing to co operate by setting aside a few minutes of their time to either answer unstructured questions or even respond to an email rather than schedule formal time for having long "sit downs" with me.
Also I have some thoughts on the design and the development stages. I want to use the agile system and a test first approach. I have alot of code to write and with all the details of the report and documentation I believe the less trouble one can get into the better... so Test it First.
This means test plans and test cases from the users and from me. I cant help but state a pattern though. Alot of the samples, explanations and methods that exist for software cater to a team development environment. And I will do my best to adopt as many best practices as i can, however it must be noted that a One Man team is a difficult position to be in, especially in terms of time and work load not to mention spirit.
I'm tired. This project is alot of work and the initial enthusiasm is wearing. It's not all gone, I still like what I am doing and I'm very intrigued by my topic area (I hope to make a career out of it afterward or at least a hobby) however this was only a draft report and it took the wind out of me; I can only imagine what the real guts of the thing will smell like.
I am thinking about the analysis and I a have had some brief discussions with some of the technical staff at the school and my project lecturer about less formal ways of information gathering. I know for a fact that the information gathering process will be an ongoing one and a single interview or questioner will not be sufficient. Also i have the feeling that if i need to constantly go back to the same staff to get information that they will be more willing to co operate by setting aside a few minutes of their time to either answer unstructured questions or even respond to an email rather than schedule formal time for having long "sit downs" with me.
Also I have some thoughts on the design and the development stages. I want to use the agile system and a test first approach. I have alot of code to write and with all the details of the report and documentation I believe the less trouble one can get into the better... so Test it First.
This means test plans and test cases from the users and from me. I cant help but state a pattern though. Alot of the samples, explanations and methods that exist for software cater to a team development environment. And I will do my best to adopt as many best practices as i can, however it must be noted that a One Man team is a difficult position to be in, especially in terms of time and work load not to mention spirit.
23, 24 & 25
Evaluation of Methodologies;
Name: SCRUM
Authors: Hirotaka Takeuchi & Ikujiro Nonaka
Ken Schwaber & Jeff Sutherland
This method is a set of ideas, concepts and values that can be imposed on an existing system, to increase the productivity of development of an actual product. SCRUM focuses alot on delivering an actual product to clients in time boxed iterations.
The system is designed to have daily communications. Other than its daily meetings the type of collaboration it promotes bringing new data to everybody's attention. So good news and bad news gets told and dealt with asap.
There is also a single responsible person for evaluating the ongoing progress. So for example if the project shows signs of being very late on delivery (which can be detected very early - unlike many other methodologies) remedial action can be taken and decisions made to alter how things are being done.
Scrum also promotes non conventional ways of responding to slumps in project delivery times. The typical response being to force human resources to work harder and longer hours. As stated before SCRUM is really a set of beliefs that can be enforced on any system. One of these is generally accepting that employees, development team, etc. are working diligently toward project goals and deadlines. Where normally it would be automatic to sacrifice quality and conformance to industry standards to deliver software on time; SCRUM promotes acceptable working hours, diligence in conforming to best practices (proper documentation) and standards.
This ensures the end product that the company and the team are so dedicated to is actually worthy for the customer deployment and meets the highest levels of quality and usability.
Core Concepts:
The system is designed to have daily communications. Other than its daily meetings the type of collaboration it promotes bringing new data to everybody's attention. So good news and bad news gets told and dealt with asap.
There is also a single responsible person for evaluating the ongoing progress. So for example if the project shows signs of being very late on delivery (which can be detected very early - unlike many other methodologies) remedial action can be taken and decisions made to alter how things are being done.
Scrum also promotes non conventional ways of responding to slumps in project delivery times. The typical response being to force human resources to work harder and longer hours. As stated before SCRUM is really a set of beliefs that can be enforced on any system. One of these is generally accepting that employees, development team, etc. are working diligently toward project goals and deadlines. Where normally it would be automatic to sacrifice quality and conformance to industry standards to deliver software on time; SCRUM promotes acceptable working hours, diligence in conforming to best practices (proper documentation) and standards.
This ensures the end product that the company and the team are so dedicated to is actually worthy for the customer deployment and meets the highest levels of quality and usability.
Core Concepts:
- Product Backlog - List of requirements / needs / activities in order of importance for the project. Highest importance, risk or most needed at the top.
- Sprint Backlog - Sprint - a period of development - usually weeks to 1 month but not much more than a month. The Sprint Backlog is what is to be accomplished at the end of the sprint. It comes from the requirements in the product backlog. The Team is presented with what The Product Owner / Scrum Master wants from the sprint and they get to say how much they can achieve.
- Sprint Meeting (Planning) - Before the start of a scrum sprint a meeting is held to plan the event and process of the scrum. 3 hrs - 8 hrs (max).
- Sprint Review - Team and scrum master and participants review work done in the sprint, the product delivered and the events that took place.
- Daily Meeting - 15 mins meeting held in each day of a scrum
- Burn Down - A chart displaying the remaining work for the project. This is available to all and is updated daily.
Project Pros:
- Focused on Delivery
- Team Oriented
- Supports Best Practices - Quality Software, Documentation
- Constant Evaluation of progress / risks / value / cost
- Focus on deadlines and time line
Project Cons:
- Requires large amts. organization|
- Even though it caters for changing requirements, I feel that it necessitates a solid set of initial requirements.
- The system is based on proper user representation and involvement. If it so happens that the client is slightly misrepresented, even thought it would not be the fault of the developers, the project could fail.
Can I use it:
This is a great framework for a large organization I think, or even a small very tight knit company, where communication and openness are valued and practiced principles.
Companies like Yahoo and Google are using it, so it is being tried. I really like that it is not restricted to just Software development. The fact that it can be used in any environment says alot about the base principles.
I could deploy this - I like some of the values; however the team effort required and the meeting schedules would be very confining and seems not practical for the situation.
So maybe we can adopt some of the values but not necessarily the entire methodology.
http://www.scrumalliance.org
http://www.controlchaos.com/about/
http://www.implementingscrum.com/
http://video.google.com/videosearch?q=SCRUM&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&sa=X&oi=video_result_group&resnum=4&ct=title#
Name: Extreme Programming
Authors: Originally - Kent Beck
Others - Ann Anderson, Ken Auer, Ward Cunningham, Martin Fowler, Chet Hendrickson, Ron Jeffries.
Extreme Programming or XP is a method that is built on the focus of the customer and the iterative design/development process. Like many systems for productive development XP surrounds a set of core practices, when used together boast a stable and more rapid development process. The code is only valuable when it works and works for the client. The code should be built on the test first policy - where the tests are written before the code. The tests should come from the programmers and the users - the test data should come from the most reliable source, i.e. the users. The users are involved from the start and their interaction in the least ambiguous way helps to ensure programmers and the rest of the project team have a clear understanding of what the customer wants. Tests are built to represent this before the software is built so that the efforts and aptitude of the development team is transparent. The development process is attempted in parts according to the requirements as described by the users in User Stories. All stories are organised according to a realistic priority of the users and the resources of the team and this paves the path that the development is guided upon. Each set of requirement from the user stories are attempted in a release and the release can be powered by a release plan.
Core Concepts:
- Development Environment - Other than the standard definitions of what a work environment should be, this methodology seems to take into consideration the people doing the core development work - the programmers. The extreme environment seems to directly address the needs of programmers by keeping the working hours to a limit of a 40hr week. (It is true - programmers need sleep too - even though we may not admit it). It encourages programmers to work together by having them all in the same room. It also has daily meetings to facilitate communication. This methodology goes as far as noting the need to provide food and additions to aid programmers on a daily basis.
- Listening - Involving the customer / users and understanding their needs and wants out of the project in way that is transparent to the programmers supporting the Customer Bill of Rights and the Developer Bill of Rights. User stories are used to capture scenarios that surround the system's environment. The user stories are eventually addressed as the requirements of the system. It is important to note that User Stories are not Use Cases and there are significant differences in the two. The deliverables from the user stories are organised according to importance for the customer and the resources of the development team.
- Design & Development - Extreme Programming is based on Testing and test first procedures. The test for the software are written before the actual software so that when the design is put into code it is sure to meet the requirements and needs of the users / customers. Additional tests called acceptance tests are used to validate software against the features needed by customers. Also the development is done in iterations, usually that each meet some of the user stories described above so that at the end of each cycle or release of the software there is something to test against in terms of user needs / system requirements.
Even though the work is derived from different users and stakeholders, the actual software is written by programmers / developers and there have been many public outcries denoting the disregard for working conditions.
http://www.extremeprogramming.org
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.xprogramming.com
http://www.cs.toronto.edu/~penny/research/release-planning/samplerp.html
http://books.google.tt/books?id=u13hVoYVZa8C&dq=who+founded+extreme+programming&printsec=frontcover&source=in&hl=en&ei=V0WQSZW2G9KgtwfDvtSNCw&sa=X&oi=book_result&resnum=12&ct=result#PPA1,M1
20, 21 & 22
Opening Note:
This is exam week and the last couple of weeks were course work right after the last hand up. In addition to the schedule constraints I realize that the amount of work I intend to put into any deliverable and into the project in general is in actuality always reduced to a much smaller amount. Also I realize that I always feel slightly dissatisfied with the hand ups that i have made so far. Half the battle is knowing the problem - with that said my aim for the next deliverable is to try my best to produce work other that what is acceptable but that will add to my confidence and positive attitude toward this project. I love the work I do and this project means more to me than just a report and a piece of software at the end with hopes of a a passing grade. I know for a fact that this project is a part of me and the only way I can make it valuable is to place some of the value that is me in the efforts I make in it.
Even before my associate degree, I have been made aware of the bad reputation that IT (networking, data centers, repairs and especially programming) departments have when it comes to projects. It was so prominent that IT projects were commonly associated not only with being costly but in addition to having little or negative returns they were primarily known to be unfinished.
This was reinforced in a course i took called System Analysis and Design. In addition to IT departments earning a negative label, IT personnel and professionals were now generally thought of as "too technical" and unable to act in managerial roles.
This article makes some general evaluations that are backed by statistics. Some of which are astounding -
In addition the BSc Computing from UOG specifies that we evaluate the methodologies we are going to employ during the lifetime of the project.
Also I think it makes report writing and project management easier. The tried steps that have been refined by others give cognitive steps as to how to follow through the stages of the project. (So if i ever have doubts as to what i should be doing next the methodology should lead the way - along with my project lecturer).
Using a methodology will also allow me to deliver a more relevant analysis, development, deployment and testing in the critique of the work done. I will better be able to show what i was trying to accomplish to the markers and if i did indeed succeed and at what level by using the documentation specified in the methodology.
So we have established the importance of methodologies and why we need them for this project.
The following are some of the methodologies that are available for use in software development projects and over the next couple of weeks i hope to show how i gathered knowledge on them and use that in my justification of methodologies.
This is exam week and the last couple of weeks were course work right after the last hand up. In addition to the schedule constraints I realize that the amount of work I intend to put into any deliverable and into the project in general is in actuality always reduced to a much smaller amount. Also I realize that I always feel slightly dissatisfied with the hand ups that i have made so far. Half the battle is knowing the problem - with that said my aim for the next deliverable is to try my best to produce work other that what is acceptable but that will add to my confidence and positive attitude toward this project. I love the work I do and this project means more to me than just a report and a piece of software at the end with hopes of a a passing grade. I know for a fact that this project is a part of me and the only way I can make it valuable is to place some of the value that is me in the efforts I make in it.
Even before my associate degree, I have been made aware of the bad reputation that IT (networking, data centers, repairs and especially programming) departments have when it comes to projects. It was so prominent that IT projects were commonly associated not only with being costly but in addition to having little or negative returns they were primarily known to be unfinished.
This was reinforced in a course i took called System Analysis and Design. In addition to IT departments earning a negative label, IT personnel and professionals were now generally thought of as "too technical" and unable to act in managerial roles.
http://www.bcs.org/server.php?show=ConWebDoc.19584
This article makes some general evaluations that are backed by statistics. Some of which are astounding -
... the cost of project failure across the European Union was €142 billion in 2004.The article makes a bold statement about one of the reasons that IT projects fail;
I believe that even though at the root of projects, companies and systems, the driving force are the combined efforts and attitudes of the people involved, we can learn from the mistakes of the past by documentation and implementation of suitable methodologies and methods.
One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process.
In addition the BSc Computing from UOG specifies that we evaluate the methodologies we are going to employ during the lifetime of the project.
Also I think it makes report writing and project management easier. The tried steps that have been refined by others give cognitive steps as to how to follow through the stages of the project. (So if i ever have doubts as to what i should be doing next the methodology should lead the way - along with my project lecturer).
Using a methodology will also allow me to deliver a more relevant analysis, development, deployment and testing in the critique of the work done. I will better be able to show what i was trying to accomplish to the markers and if i did indeed succeed and at what level by using the documentation specified in the methodology.
So we have established the importance of methodologies and why we need them for this project.
The following are some of the methodologies that are available for use in software development projects and over the next couple of weeks i hope to show how i gathered knowledge on them and use that in my justification of methodologies.
- eXtreme Programming
- Prototyping
- Rapid Application Development
- SCRUM
- RUP
- AUP
- SSM
- OOSD
- Waterfall
Subscribe to:
Posts (Atom)
