In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is:

Transcription

1 In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: The period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirements phase, design phase, implementation phase, test phase, installation and check-out phase, operation and maintenance phase, and sometimes, retirement phase. A Software Lifecycle Model is a particular abstraction that represents a Software Life Cycle. A Software Life Cycle model is often called a Software Development Life Cycle (SDLC). The IEEE standard 1074 establishes a common framework for developing life cycle models. It describes the activities and processes needed for the development and maintenance of software. The standard divides the set of activities into processes, and processes into process groups: Process Group Life Cycle Modeling Project Management Pre-development Development Post-development Integral Processes Processes Selection of a Life Cycle Model Project Initiation Project Monitoring and Control Software Quality Management Concept Exploration System Allocation Requirements Design Implementation Installation Operation and Support Maintenance Retirement Verification and Validation Software Configuration Management Documentation Development Training Table 7.1 Life cycle modeling

2 A variety of life cycle models have been proposed, most of which focus exclusively on the development processes. When formalized and combined with development techniques (modelling, prototyping ), they are called methodologies. Code and Fix Code and Fix is the simplest approach of product construction without specification or attempt of design. Coding, compilation, testing and fixing errors are repeated until the solution is good enough. This is a trial and error approach, which works fine for small software projects but is unacceptable for large or complex systems. Waterfall Model This is one of the first formalized development models. Fig. 7.2 Waterfall Model In this model, development proceeds in a stepwise manner from requirements, through design, implementation, testing, and finally operation. The waterfall model has three underlying assumptions: The problem domain is well known by both client and development team;

3 The problem domain is relatively stable over the development period; The client can wait for the entire solution to be delivered. The Waterfall model is based on the approach used for the development of hardware systems, but there are differences between hardware and software that the waterfall model does not address. Unlike hardware, software requires no fabrication. One could use the analogies of house building and sculpting. Developing hardware can be compared to house building and developing software to sculpting. Sculpting is a less rigid exercise as moldable clay can be added, removed, or otherwise rearranged. Also, the criteria for judging success in house building are largely objective, while the success of a sculpture is judged subjectively. Some variants of the waterfall model allow revisiting the immediately preceding activity (feedback loops) if inconsistencies or new problems are encountered during the current activity. Another variant of the waterfall model - the V-model - associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation activity tests a higher abstraction than its predecessor. The problems with the waterfall model are: It is difficult to define all requirements at the beginning of a project; This model has problems adapting to change; A working version of the system is not seen until late in the project's life; It does not scale up well to large projects; Real projects are rarely sequential. Because these weaknesses, the application of the waterfall model should be limited to situations where the requirements and their implementation are well understood. For example, if an organization has experience in developing accounting systems then building a new accounting system based on the existing designs could be managed with the waterfall model.

4 The Incremental Model The Incremental Model performs the waterfall in overlapping sections thereby attempting to produce usable functionality earlier in the project life cycle. Fig. 7.3 Incremental Model As some modules are completed before others, well-defined interfaces are required. Also, there can be a tendency to push difficult problems to the future to demonstrate early success to management. The Incremental Model can be used when it is too risky to develop the whole system at once.

5 The Spiral Model The incremental model can also be represented as a spiral with erequirements-design- Implementation cycle as a coil. The spiral size corresponds with system size, and the distance between the coils of the spiral shows resources. This view illustrates the fact that resources can be kept constant while the available functionality grows. In the Spiral model proposed by Barry Boehm [90] prototyping is used to control risk. The Spiral model describes development as an iterative four-phase process, for combining the various approaches: Expression of needs; Feasibility; Prototyping; Development of the final product. The spiral model can be used when there is doubt about user requirements (for example in the development of a business intelligence system). A popular variant of the spiral model is the Component Assembly Model. It tries to force reuse of components by: Time boxing Attempting to identify candidate components for use in the system; Using the components if they exist; Develop new components when necessary and adding them to the component library; Constructing the application from library components. In the models discussed above either the requirements are fixed (waterfall) or the resources are fixed (incremental/spiral) while the other elements can vary during development. Another approach is to fix time of the development and to fix the resources as far as possible. This means that the requirements that will be satisfied are allowed to change. Therefore, an important product of the business analysis is a clear prioritization of the high-level requirements. More detailed requirements are collected during the later stages of development and are also ranked. This approach is used in a method known as Dynamic Systems Development Method (DSDM). The flexibility of requirements to be satisfied has significantly affected the development processes and controls, and on acceptance of the system. Indeed, a fundamental assumption of DSDM is that nothing is built perfectly the first time, but that a usable and useful 80% of the proposed system can be produced in 20% of the time it would

6 take to produce the total system. Another underlying principle of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables. The mechanism for handling flexibility of requirements in DSDM is the time box. DSDM uses short time boxes of two to six weeks within the overall project duration. Each time box has a fixed end date and a ranked set of requirements assigned to it. Some of these are mandatory and some of a lesser priority. This mix is essential, since, if all the requirements that are to be satisfied in a time box were mandatory, there would be no room for maneuver when things do not go perfectly to plan or when new requirements surface. All necessary reviews and tests are contained within the time box. DSDM can be summarized in nine principles that form a guideline throughout the whole theory: Necessity of active user involvement; Teams have to be allowed to take decisions autonomously; Frequent delivery of intermediate solutions; Fitness for purpose is the fundamental acceptance criterion; Iterative and incremental development; All changes can be undone; Requirements are set at a high level; Testing is integrated in the life cycle; Collaboration of all stakeholders is essential. DSDM can be applied successfully in certain types of development projects. Especially when the functionality can be visualized easily using screens and reports as in these systems prototypes can be used for the visualization and validation of the design. It is also important that the user groups are well defined as in that case it is easy to select the right user representatives. These user representatives (the Ambassadors) are the link between the target organization and the developers. Finally, when the system to be developed is big and complex it has to be possible to cut down the system in smaller and manageable parts that can be developed and tested independently. The time box approach is also used in other Rapid Application Development (RAD) methods. Developing applications rapidly is increasingly essential to business survival. There is, however, an inherent danger. Organizations are often tempted to use RAD techniques to build stand-alone systems to solve a particular business problem. Such systems, if they meet user needs, then become institutionalized. If an organization builds many isolated systems to solve particular problems, the result is a large, undisciplined mass of applications that do not work together (information islands). In practice, most business applications are closely related to each other, making a common infrastructure essential. In addition, as computing systems grow, they become more complex, and such systems are difficult to change unless they have been created within a well-designed architecture that allows one element to be changed without changing the whole system.

7 Agile Software Development Agile means being both effective and maneuverable, agile development methods are both light and sufficient. In the introduction of his book Agile Software Development [97] Alistair Cockburn states: Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensive to everyone, you stop when the document is sufficient to the purpose of the intended audience. Managing the incompleteness of communications is core to mastering agile software development. Agile software development methods are focusing on the people rather than on tools and processes, their goal is working code more than perfect documentation. They try to adapt to changes in the requirements rather than the execution of a predefined plan. One increasingly popular Agile Development Method is known as Extreme Programming (XP). It is a lightweight discipline of software development invented by Kent Beck based on principles of simplicity, communication, feedback, and courage [85]. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly changing requirements. Extreme Programming was created in response to problem domains with changing requirements. In many software environments dynamically changing requirements is the only constant. XP was also set up to address the problems of project risk. If the system is needed by a certain date the risk is high. If that system is a new challenge for the software group the risk is even greater. If that system is a new challenge to the entire software industry the risk is greater even still. The XP practices are set up to diminish the risk and increase the likelihood of success. There are 12 key practices in XP: The Planning Process - The XP planning process allows the XP "customer" to define the business value of desired features and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred; Small Releases - XP teams put a simple system into production early and update it frequently on a short cycle; Metaphor - XP teams use a common "system of names" and a common system description that guides development and communication; Simple Design - A program built with XP should be the simplest program that meets the current requirements; Testing - XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided;

8 Other models Refactoring - XP teams improve the design of the system throughout the entire development by keeping the software clean: without duplication, with high communication, simple, yet complete; Pair Programming - XP programmers write all production code in pairs, two programmers working together at one machine. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone; Collective Ownership - All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay; Continuous Integration - XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page and enables rapid progress; 40-hour Week - Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping fresh, healthy, and effective; On-site Customer - An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers ask them. The effect is that communication improves, with less hardcopy documentation - often one of the most expensive parts of a software project; Coding Standard - For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly. There are many other models such as: Sync-and-stabilize This is Microsoft's loosely structured, small-team style of product development [98]. Many small teams (three to eight developers) work in parallel. Changes are synchronized frequently so components will work together. Developers check in their code by a particular time. A new build (complete recompilation) is done at the end of the day or the next morning. The overall strategy is to quickly introduce products that are "good enough" to capture a mass market, and later improve the product, selling multiple product versions and upgrades; Issue-Based Life Cycle Model - The project is driven by a set of issues such as "How do we set up the initial teams?" and "What software architecture shall we use?" Issues are classified as open or closed, but closed issues can be reopened as changes occur in the application or solution domain. Issues are maintained in an issue base accessible to all project participants. Issues do not directly correspond to risks, as some issues are design problems, not risks. By organizing the project around issues, all life cycle activities can proceed concurrently, using dependencies between issues to determine which activities can be performed concurrently and what the impact of reopening an issue will be.