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.
Monday, January 26, 2009
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)
