Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
Industry Project Life Cycles
Construction Management Project Life Cycle
Feasibility
Planning
Design
Production
Turnover
Startup
For a construction project, there are several standard stages for the holistic picture we are looking at. The client is involved in all of these stages and outside appointments may only be made for some of them, depending upon client choice and expertise. The diagram indicates the main phases of a construction project and the order in which they come.
Figure 3 Construction project life cycle
Source: CIOB (1996) Code of Practice for Project Management in Construction and Development, Longmans
The design and tender stages are included within the pre construction box under this model. Engineering commissioning is making sure the systems are working in the building, and client occupation includes fitting out. Only one or two of these stages are considered by the contractor and designer; consequently client objectives are not in perspective and there is frequently no overall strategy for the project which would aid the client. The client's chief concerns are to meet their business objectives which may, for example, concern performance, aesthetics, sustainability, production or sales targets. This makes the client more active in the beginning and the end stages. In other forms of procurement, such as design and build, PFI (Private Finance Initiative) and construction management, the contractor plays a closer role to the client. Industry Project Life Cycles
Rapid Application Development
Philosophy:
Applications must be produced quickly
o to be economical
o to reduce the number of changes between analysis and final delivery
o to be relevant when delivered, not solving last year's problem
o because users want their new system now, or because the organization must conform to new legislation
o to clear the application backlog
User requirements must be understood
o users must be involved in the development process
o understanding is ensured by the use of concrete examples, hence the emphasis on
o prototyping
Software developers must be allowed to do their job with the minimum of bureaucratic interference
Rapid application development
Advantages: Quick results, not abstract, users have assurance that correct solution will be produced
Industry Project Life Cycles Waterfall Approach
Software development has gradually evolved from unstructured to structured, both in producing programs and in managing projects
The waterfall approach assumes all requirements are written down before producing them. Each definition is "signed off" by the user before starting work
Project definition signed before starting project
Systems analysis agreed before starting design
Design agreed before starting programming, and so on
Advantages: Planned duration, responsibility pinned down, orderly, should result in few corrections late in project
Waterfall approach
All is not rosy
It can be difficult to state when a stage is complete, i.e. we may have to correct to previous work Industry Project Life Cycles
Causes of failure once a project has started:
74% Unclear objectives and requirements
60% Lack of business commitment
58% Business requirements changing
45% Poor communication
o Taylor A (2000) IT projects: sink or swim, Computer Bulletin January 2000, BCS
"No-one knows what they want until you give them what they ask for" (Gerry Weinberg)
Industry Project Life Cycles
Extreme Programming (XP)
A late 90's development based on the RAD ideas
Philosophy:
Keep it simple, build it quick, make it work
Analogies between software engineering and other engineering are false
o our customer's requirements change more frequently
o our products can be changed and altered more easily
o the ratio of design cost to build cost is already much higher
o history shows that software design diagrams are often not helpful in producing a reliable design
o if we consider coding as "design" and compile and link as "build"
▪ the "build" task is so quick and cheap it should be considered instant and free
▪ almost all software development is design
o the coding work becomes analogous to the up-front design effort we expect of an engineering discipline
Software developers must be allowed to do their job with the minimum of bureaucratic interference (as with RAD)
o traditional methodologies are too bureaucratic
o some rules are good
o but more rules don't mean "better"
What is special about XP?
Four values
Communication, Feedback, Simplicity, and Courage
We design by coding
programmers meet and communicate with customers regularly
testing is the start point, not the end point
o for each unit the programmer designs the test first
o when the unit is ready, the test is run automatically
the design is kept simple
Industry Project Life Cycles
the design meets known existing requirements, not all possible future functionality
o Beck (1999): "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy. Put in what you need when you need it."
programmers always work in pairs (considered more productive)
the system gets released regularly in small increments
customers are allowed to suggest improvements
redesigns are common - what they call refactoring - and handled easily
A thought
eAD (2000): "If changes are continuous, then we'll never get an up-front design completed. Furthermore, as changes become more unpredictable -- a great likelihood today -- then much anticipatory design likely will be wasted."
XP and project management
Each element of functionality is called a story, and each one is written on a card. The project scope and plan is simply and efficiently created by manipulating the cards by hand. Progress monitoring is achieved by tracking the unit test for each story.
Quality is assured by two main themes. Paired programmers ensure learning, adherence to standards, and avoidance of errors. Unit tests are core to coding and are designed before writing the code. The programmers are responsible for proving to the customer that each unit works correctly, rather than the customer having to prove that it doesn't work. See Hutcheson (2004) for a discussion of software testing in XP projects.
Efficiency is gained through
minimal bureaucracy;
focus on delivering quickly;
focus on getting it right first time;
only documentation: cards and source code;
not trying to predict all possible future changes;
handling current changes easily;
testing automated;
Industry Project Life Cycles
metric collection automated;
progress monitored by following story cards and test results.
Bibliography
Extreme Programming
Wells, J. D. (2002) Extreme Programming: A gentle introduction,
Highsmith, Jim, eAD (2000) Extreme Programming. Article in "eAD - e-business Application Delivery" by the Cutter Consortium
Beck, K. (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley
Nelson, E. (2002) Extreme Programming vs. Interaction Design: When two development design visionaries meet, there's room for consensus—but not much. Fawcette Technical Publications
Hutcheson, M. L. (2004) Testing in the eXtreme Programming (XP) Paradigm: A Case Study". Article in TickIT International, ISSN 1354-5884
