Presentation on theme: "Chapter 6 Development Lifecycles And Approaches Swe 523 Oguz Kupusoglu, 18 October 2004."— Presentation transcript:
Chapter 6 Development Lifecycles And Approaches Swe 523 Oguz Kupusoglu, 18 October 2004
2/40 Lifecycles System development lifecycle: Covers the whole life of the system. Often focused only on the technical deliverables. Project lifecycle: Covers the only the delivery of the specified product. Focused on the technical, management and quality aspects.
3/40 System Development Lifecyle Models The selection of the System Development Lifecyle Model is important for the project. Usually the model selection is not done by the Project Manager. There are only two basic system development models: Waterfall model Spiral model All other “mainstream” models tend to be variants or refinements of these two. This chapter is dedicated to models. It describes models along with their strengths and weaknesses.
4/40 The Waterfall Model After a number of high-profile failures, it was understood that the software projects require some formality. The waterfall model was introduced by W. Royce in 1970. In the waterfall model, system development is broken down to a number of sequential stages: before work starts on a stage, the previous stage needs to be completed. The outputs from one stage are used as inputs to the next.
6/40 The Waterfall Model Each stage is divided into two parts: the first part covers the actual work carried out in the stage and the second part covers the “verification” and “validation” of that work. “Verification” establishes the correspondence between a product and its specification: are we building the product in the right way? “Validation” establishes the suitability of the product for its operational mission: are we building the right product?
7/40 The Waterfall Model Characteristic of the model: Iteration is within a stage, not between stages. Rework is carried out in the succeeding stage and the original stage is not revisited.
8/40 The Waterfall Model Strengths: Establishes a sequence of activities. Quality management through the verification and validation. Configuration management by baselining the product at the end of each stage. Its stage-by-stage nature is useful for project management planning and change control. Weaknesses: Risk-management is not covered. No explicit management control. However, by sequential nature, it is OK. Maintenance phase is not well covered.
9/40 The Waterfall Model Works best when reworking is kept to a minimum and stage output remains fixed. In situations where the requirements are well understood and the product is unlikely to undergo significant change, the waterfall model works well.
10/40 The “b” Model The waterfall model treats the operations and maintenance stage as if it has a separate start and finish like other stages. However, maintenance is on-going and open-ended. However, maintenance requires most of the work a system demands and it can typically represent more than 70% of total lifecycle costs. The “b” model was introduced by N. Birrell and M. Ould to address this shortcoming of the waterfall model.
11/40 The “b” Model Figure 6.2 “b” model (N D Birrell & M A Ould, A Practical Handbook for Software Development, Cambridge University Press, 1985)
12/40 It is a variation of the waterfall model. The left downward leg of the “v” shows the progress from analysis to design. The right upward leg of the “v” shows the progressive assembly and testing till the product delivery. Shows correspondence between different stages in the project, i.e. between the legs of “v”. Hence, this model is good from the quality assurance point of view. Useful when external contractors are hired as the stages are well defined and deliverables of each stage are validated. The “v” Model
13/40 The “v” Model Figure 6.3 “v” model (National Computing Centre Ltd, STARTS Guide, 1987)
14/40 Incremental Model It is a variation of the waterfall model. This model is used where the total functionality of the system is to be delivered in phases over a period of time. Hence, it is sometimes termed “phased delivery”. It makes the delivery and testing more manageable as it delivers the new system to the customer incrementally over a period.
15/40 Incremental Model It can be difficult to break delivery of the system into phases which are internally consistent. Introduces overheads as the latest phase has to be integrated with the earlier ones and the whole system is retested. Total scope and requirements must be defined before the increments are defined. This model is not appropriate where the project scope is poorly defined and the requirements are ambiguous.
16/40 Incremental Model Figure 6.4 Incremental Model
17/40 Spiral Model The spiral model was developed by Barry Boehm. This model introduces an evolutionary or iterative approach to systems development. Useful when the requirements are not well formed or understood by the users. it is difficult to specify the requirements. it is difficult to determine how a proposed solution will perform in practice. The spiral model introduces objective-setting, risk management and planning into the overall cycle which are very desirable from the project management point of view.
19/40 Spiral Model It involves carrying out the same activities over a number of cycles in order to clarify the requirements and fix problems. It amounts to repeating the development cycle several times. The project starts at the center of the spiral and progress outwards. The total cost of the project will increase as the length of the spiral increases.
20/40 The Traditional Approach to Systems Development Most traditional approaches are based on variations of the waterfall method. There are three stages: Analyze requirements: The analyst considers the current system and its problems. The users are interviewed. The output is a set of notes put together by the analyst. Specify requirements: The analyst creates requirements document out of the information collected. This is likely to be mixture of business requirements, functional and non- functional requirements and an overview of proposed hardware and software. Produce high-level design: The designer will create it based on the requirements document.
21/40 The Traditional Approach to Systems Development Figure 6.6 The traditional Approach
22/40 This model is characterized by lack of user involvement, the use of text-based, as opposed to diagrammatic, documentation, emphasis on how things are going to be achieved rather than what is going to be achieved. It is difficult to see how stages are linked. Typically, there is no business case or defined acceptance criteria for the system. The users give feedback only when they review the requirement specifications. Sometimes later, they receive the system! The Traditional Approach to Systems Development Why?
23/40 This method allows the analyst to use “intuitive” techniques and make limited demands on the users’ time which is a virtue. The documentation is easy to understand mostly in plain English. However, the text tends to be ambiguous and interpreted differently by different people. Lack of user involvement and “ownership” usually results in a poor quality system. The Traditional Approach to Systems Development
24/40 Structured Methods Structured methods have largely replaced the traditional approach. This methods are characterized by User involvement: The users review the project throughout the project. Separation of logical and physical:There is a clear separation in the design of the system between what is to be achieved and how it is to be implemented. Emphasis on data: Concentrates on data rather than the processing required by the system as the data tend to be more stable. Diagrammatic documentation Defined Structure: Have an overall structure which ensures smooth progress.
26/40 The drawbacks of the structured methods: The users and analysts\developers need to be trained to understand the documentation. The demand on the users’ time will be much increased. Hence, full user commitment should be obtained. They lead to increased levels of documentation and of bureaucracy. It occurs when the various steps and activities of the method are followed blindly. It is usually disastrous to assume that the method, rather than the analyst, will do the work. Structured Methods
27/40 The Structured Systems Analysis and Design (SSADM) was originally developed by the UK government in 1980. It is a structured method. The default structural model is based on the waterfall model. SSADM+4 was released in 1995 in response to over- prescriptive and bureaucratic accusations. It proposes using of the prototypes at various places and may involve a limited use of the spiral model. SSADM
28/40 Rapid Application Development (RAD) aims at delivering the system quickly often accepting that the implemented system may not be perfect. An advantage of RAD approach is that external changes are reduced. The spiral model is generally used for at least part of the project. RAD becomes necessary when the customers are unable to provide a complete and detailed specifications at the start of the project. So, instead of developing the system in one go, the system is divided into iterations, each adding some functionality or improved performance relative to its predecessors. Rapid Application Development
29/40 As the business and technical requirements are better understood by both customers and developers, additional iterations are scoped. RAD approach generally results in prototypes. RAD considers iteration and rework as unavoidable unlike the most structured methods. Practical experience suggests that RAD is best suited when the system is not too large and the number of stakeholders is fairly small. Timebox concept: The limit for each timebox is set before work starts and delivery is limited to what can best be achieved within each timebox. Rapid Application Development
30/40 Dynamic System Development Method (DSDM) is a formalized approach to RAD. It sets nine principles: Users must be actively involved. Teams must be empowered to make decisions. Products are delivered frequently rather than perfected. Each product should be fit for its business purpose. Iterative and incremental approach is an integral part of the approach. All changes are reversible. Rapid Application Development
31/40 The high level scope of the system should be agreed at a level which does not make it difficult to change it later in development. Testing is an integral part of the lifecycle. All stakeholders must cooperate and collaborate. RAD methods imply speed and a lack of structure. Moreover, poorly defined requirements, possibly even the overall scope, and iterative nature requires that control should be exercised very carefully. Rapid Application Development
32/40 In the structured programming, data and methods are separated. This point creates problems when the software becomes very large. For example, it becomes very difficult to modify or update the existing software if there are thousands of code lines. The genesis of this technology dates back to the early 1960s with the work of Nygaard and Dahl in the development of the first object-oriented language called Simula 67. Research progressed through the 1970s with the development of Smalltalk at Xerox. Currently, Eiffel, Ada, Java, and C++ are available OO languages. Object Oriented Development Methods
33/40 OO methods use the concept of class. A class is an abstraction, usually, from the problem domain. The methods and the data required by the concept are put together. Using the inheritance mechanism, it is possible to create class hierarchies. The base class embodies the most general concepts, and each derived class represents more specific, but related, concept. Object Oriented Development Methods
34/40 Currently, Unified Modeling Language (UML) and Unified Process (UP) are industry standards. UML provides a visual language and UP supplies a process model. Although UP is a non-proprietary approach, Rational Corporation offers well-developed set of processes and tools through its Rational Unified Process. There are four phases in the UP: inception, elaboration, construction and transition. Object Oriented Development Methods
35/40 The objective of the component-based development is avoiding “reinventing the wheel” and instead reuse already available software. In the long run, with this method, the development costs should fall and the development times should be reduced. The problem is finding the right component. The technology used to develop the components is important for the end-users. Component-Based Development
36/40 A rather extreme form of RAD is “Extreme Programming” (XP). It was formulated by Kent Beck, Ward Cunningham, and Ron Jeffries. Kent Beck wrote the first book on the topic, Extreme Programming Explained, published in 1999. It was created to deal with the rapidly changing requirements, tight deadlines and working with new or unfamiliar technologies. Software is created from the user “stories”. It seems XP requires small, tightly focused and highly motivated teams. Extreme Programming
37/40 The developers work in pairs, at the same computer, checking and testing each other’s work. It requires minimal documentation. Continuous automatic testing is required. Refactoring is applied. There are frequent releases. The customers must be available at all times. There must be well-established coding standards. Extreme Programming
38/40 Commercially available off-the-shelf packages provides some advantages: Introduction of the new system require much less time. Cost is likely to be lower as the development costs are shared by all the package users. Support and enhancements are usually available. Often, adopting a packaged solution is unlikely to provide completive advantage as other organizations can easily buy the same package. So, organizations usually buy packages for “routine” operations like accounting. Package-Based IS Projects
39/40 With a package-constrained solution, the organization should buy the package that best fit its requirements. Then, in areas where the package works differently, it is the processes that are to be changed to fit the package rather than vice-versa. With a package-based solution, the organization selects a package that provides most of the functionality and then develops additional functionality on top of it. Experience suggests that extensive customization, say more than 30%, can be more expensive in the long run than developing a custom application. Package-Based IS Projects