Software Life Cycle Models For Presentation (2010)

1
SNS COLLEGE OF TECHNOLOGY Wednesday, May 02, 2012
A life cycle model defines the phases, milestones, deliverables, and evaluation criteria of the software development process. These form the basis of the work breakdown structure (WBS), used for project planning and management.
SOFTWARE LIFE CYCLE

SNS COLLEGE OF TECHNOLOGY
Wednesday, May 02, 2012
Process interrelationships in the IEEE 1074 standard (UML activity diagram, adapted from[IEEE Std. 1074-1995]]. As suggested by this picture, dependencies among processes and activities are complex and seldom allow a sequential execution of processes. Process interrelationships in the IEEE 1074 standard (UML activity diagram, adapted from [IEEE Std. 1074-1995]]. As suggested by this picture, dependencies among processes and activities are complex and seldom allow a sequential execution of processes.
3
Simple life cycles may have only three phases, Design, Development, and Maintenance; while complex life cycles may include 20 or more phases. Generally, software life cycles include the phases shown in Figure
Requirements Design Implementation Testing
Common Life Cycle phases

Deployment Maintenance
Common Life Cycle Phases

Requirements
Design
Implementation
Testing
Consists of analyzing the problem or need for which the software is being developed. This analysis, a systems engineering activity, develops and specifies requirements, stating what the software must do. In addition to stated requirements, requirements are derived from higher-level requirements and 5 statements of need

Requirements
Design
Implementation
Testing
The software structure is defined. Technical approaches are chosen and problems are solved conceptually. This phase is often divided into a Preliminary Design Phase and a Detailed Design Phase. In the preliminary design the initial software architecture is developed. In the detailed design, functional modules are defined, along with user interfaces and 6 interfaces between modules.

Requirements
Design
Implementation
Testing
(sometimes called the Development Phase) is where the programming or coding takes place to execute the software design. This phase is often iterative, with unit and integration testing being performed after a software build, and the results used in another round of programming. 7

Requirements
Design
Implementation
Testing
Testing is often split into three separate phases: Unit Testing, Integration Testing, and Acceptance Testing. The first two may be part of a repeated cycle of coding and testing, while acceptance testing verifies requirements compliance.
8

Requirements
Design
Implementation
Testing
The software is installed in the intended system and users are trained in its operation. At this point the software development effort is considered complete.
9

Requirements
Design
Implementation
Testing
Fixing errors and modifying or upgrading the software to provide additional functionality, such as enabling the software to work with new computing platforms. This phase costs far more in time and effort than the original development. Software maintainers must relearn the original software code to understand what was done, then make changes to specific modules to produce the desired effect without interfering with rest of the software. Its much easier to change requirements earlier than it is to change software code later. This also means that software should be developed with maintenance 10 in mind
Build-and-fix model Waterfall model V-Shaped Model Spiral model Sawtooth model Sharktooth Model Unified Software Development Process Issue-Based Life Cycle Model The Incremental Model
Life cycle Models

11
The earliest approach Write code Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies
impossible to predict impossible to manage
Build-And-Fix Model
12
Build First version
The easiest way to develop software The most expensive way for maintenance (i.e., maintenance nightmare)
Modify until client is satisfied Maintenance Phase Retirement
Development Maintenance
Build-And-Fix Model
13
The product is implemented without requirements or specifications, or any attempt at design. The developers simply throw code together and rework it as many times as necessary to satisfy the client. It is used in small project and is totally unsatisfactory for products of any reasonable size. It is the worst model for developing a project. The product is built without proper specifications and design steps. In essence, the product is built and modified as many times as possible until it satisfies the client. The cost of using this approach is greater than if specifications are drawn up and a design is carefully developed. Software engineers are strongly discouraged from using this development approach
Build-And-Fix Model
14
This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Waterfall Model
15
Waterfall Model
Requirements Phase
Specification Phase Design Phase Implementation phase
Changed Requirement
Development Maintenance
Integration phase Maintenance
Waterfall Model
Retirement
17
Simple and easy to use. Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood.
Advantages
18
Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing.
Disadvantages
19
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
V-Shaped Model
20
V-Shaped Model
21
In many aspects, the waterfall model and its variants are simplistic abstractions of the software development process. The weakness of these models is that they assume that after an activity is finished and reviewed the associated work product can be baselined. Such an idealized model is only appropriate if the specification of the requirements is of high level of assurance and does not change during development. In practice, system development rarely conforms to this ideal model.
V-Shaped Model
22
Simple and easy to use. Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Works well for small projects where requirements are easily understood.
Advantages
23
Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesnt provide a clear path for problems found during testing phases.
Disadvantages
24
The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.
Spiral Model
25
Developers explore alternatives, define constraints, and identify objectives.
Spiral Model
26
Developers manage risks associated with the solutions defined during the first phase
Spiral Model
27
Developers realize and validate a prototype or the part of the system associated with the risks addressed in this round.
Spiral Model
28
Focuses on the planning of the next round based on the results produced in the current round. The last phase of the round is usually conducted as a review involving the project participants, including developers, clients, and users.
Spiral Model
29
The spiral model proposed by Boehm is an iterative model with the following activities
Determine objectives and constraints Evaluate Alternatives Identify risks Resolve risks by assigning priorities to risks Develop a series of prototypes for the identified risks starting with the highest risk. Use a waterfall model for each prototype development (cycle) If a risk has successfully been resolved, evaluate the results of the cycle and plan the next round If a certain risk cannot be resolved, terminate the project immediately
Spiral Model
38
Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently
Advantages
39
Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
Disadvantages
40
Client Requirements Elicitation Prototype Demonstration 1 Prototype Demonstration 2 Client Acceptance
Developer System Integration & Test Requirements Analysis
Integration & Test System Design
Clients Understanding Developers Understanding
Object Design
Unit Test
Sawtooth Model
Implementation
41
The life cycle models we described until now emphasize the management of software developers. They do not address the needs of the customer or the user. The waterfall model, the V model and the spiral model all assume that the software requirements will not change drastically during the duration of the project and that it is sufficient to show progress according to the development plan. The drawback of this approach is that the client and the user do not see a running system before the client acceptance test, and thus, cannot correct any requirement problems.
Sawtooth Model
42
Client System Prototype Requirements 1 Demo Elicitation Design Review Requirements Analysis
Users Understanding Managers Understanding
Prototype Demo 2
Client Acceptance
Manager System Integration & Test
Develope Component Integration & Test
System Design Object Design Unit Test
Developers Understanding
Sharktooth Model
Implementation
43
The shark tooth model is a refinement of the sawtooth model. In addition to the client demonstrations (large teeth) management reviews and demonstrations are introduced as well (small teeth). For example, large teeth can include a functional prototype and a user interface mock-up. The former demonstrates the feasibility of the functions that will be implemented in the system, whereas the latter illustrates the layout (or look and feel) of the user interface. Small teeth can include a system integration prototype that demonstrates the interaction between the components of the system. Such an integration prototype can be built as soon as the components are selected and need not implement any functionality
Sharktooth Model
44
Use case model

specified by realized by
Analysis model
distributed by
Entity-centered life cycle view of the models of the Unified Process (UML class diagram). the dependencies depict traceability. There are dependencies between all models. Only the dependencies between the use case model and the other models are shown [Jacobson et al., 1999].
Design model
implemented by
Deployment model
Unified Software Development Process

Implementation model
verified by
Test model
45
The Unified Software Development Process (also called the Unified Process) is a life cycle model proposed by Booch, Jacobson, and Rumbaugh [Jacobson et al., 1999]. Similar to Boehms spiral model, a project consists of several cycles, each of which ends with the delivery of a product to the customer. Each cycle consists four phases: Inception, Elaboration, Construction, and Transition. Each phase itself consists of a number of iterations. Each iteration addresses a set of related use cases or mitigates some of the risks identified at the beginning of the iteration.
Unified Software Development Process

46
i1:Issue status={Closed} i5:Issue i2:Issue status = {Open}
status = {Open}
i5:Issue
status={Closed}
Snapshot of a project issue base (UML object diagram). Issues i1 and i5 have been resolved, whereas all other issues are still open. Dependencies among issues indicate that the resolution of an issue can constraint the alternatives for dependent issues.
i3:Issue status = {Open} i6:Issue status = {Open}
Issue-Based Life Cycle Model

47
In the following we describe an entity-centered life cycle model, called the issue-based life cycle model that aims at dealing with frequent changes. This model is based on the rationale behind the system as an issue model (see Chapter 8, Rationale Management). Each project starts with a set of issues. If the project starts from scratch, these issues are drawn from the project managers experience or from a standard template. In a re-engineering or interface project, issues may be available from the issue model of the previous project. If the project has a long history, the rationale should be well populated. Examples of issues are How do we set up the initial teams?, Should the mechanic have access to driver-specific information, What is the appropriate middleware? or What software architecture shall we use?, What should we use as implementation language? All issues are stored in an issue base that is accessible to all project participants
Issue-Based Life Cycle Model

48
It combines elements of the waterfall model applied in an iterative fashion It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered When it is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features remain undelivered The core product is used by customer. As a result, a plan is developed for next increment
The Incremental Model

49

50
This model focuses on the delivery of an operational product with each increment Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments Increments can be planned to manage technical risks

51
It generates working software quickly and early during the software life cycle. Flexibility is more and less costly. Testing and debugging becomes easier during a smaller iteration. Risk can be managed more easily because they can be identified easily during iteration. Early increments can be implemented with fewer people.
Advantages
52
Each phase of an iteration is rigid and do not overlap each other. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.
Disadvantages
53
RAD (Rapid Application Development) is an incremental SW process model that emphasizes a short development cycle RAD model is a high-speed adaptation of the waterfall model, in which rapid development is achieved by using a component-based construction approach If a business application can be modularized in a way that enables each major function to be completed in less than 3 months, it is a candidate for RAD
Each major function can be addressed by a separate RAD team and then integrated to form a whole
The RAD Model

54
The RAD Model

55
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto[1] introduced the term in 2001. Agile management methods can also be applied in other development projects than software development.
Agile Software Development56

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[9] Multiple iterations may be required to release a product or new features.
Agile Software Development 57

Spiral Model as a Tool for Evolutionary Acquisition www.stsc.hill.af.mil/crosstalk/2001/may/boehm.asp Prototypes: Tools That Can Be Used and Misused www.stsc.hill.af.mil/crosstalk/1994/jan/xt94d01g.asp Extreme Methodologies for an Extreme World www.stsc.hill.af.mil/crosstalk/2001/jun/leishman.asp Balancing Discipline and Flexibility With the Spiral Model and MBASE www.stsc.hill.af.mil/crosstalk/2001/dec/boehm.asp Customizing the Software Process to Support Avionics Systems Enhancements www.stsc.hill.af.mil/crosstalk/2001/sep/donzelli.asp Tailoring a Software Process for Software Project Plans Part 1: Context and Making Tailoring Decisions www.stsc.hill.af.mil/crosstalk/1996/apr/tailorin.asp Tailoring a Software Process for Software Project Plans Part 2: Documenting the Project's Defined Software Process www.stsc.hill.af.mil/crosstalk/1996/may/tailorin.asp MIL-STD-498: What's New and Some Real Lessons Learned www.stsc.hill.af.mil/crosstalk/1996/mar/lesslear.asp DeGrace, Peter and Stahl, Leslie, Wicked Problems, Righteous Solutions: A Catalogue of Modern Software engineering Paradigms, Yourdon Press. Department of Energy (DOE) Software Engineering Methodology, Chapter 2: http://cio.doe.gov/sqse/sem_toc.htm
Reference :
58
And thats it. If you have any input, especially your views on advantages and disadvantages of any particular model, feel free to leave them in the comments and I can add them to my copy.
59
60
61
62

Software Life Cycle Models For Presentation (2010)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Life Cycle Models For Presentation (2010)

Hochgeladen von

Copyright:

Verfügbare Formate

1

SNS COLLEGE OF TECHNOLOGY Wednesday, May 02, 2012

SOFTWARE LIFE CYCLE

Wednesday, May 02, 2012

Common Life Cycle phases

Wednesday, May 02, 2012

Common Life Cycle Phases

Common Life Cycle Phases

Common Life Cycle Phases

Common Life Cycle Phases

Common Life Cycle Phases

Common Life Cycle Phases

Life cycle Models

Build First version

Developers explore alternatives, define constraints, and identify objectives.

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

SNS COLLEGE OF TECHNOLOGY

Wednesday, May 02, 2012

Client Requirements Elicitation Prototype Demonstration 1 Prototype Demonstration 2 Client Acceptance

Developer System Integration & Test Requirements Analysis

Integration & Test System Design

Clients Understanding Developers Understanding

Wednesday, May 02, 2012

Manager System Integration & Test

Develope Component Integration & Test

System Design Object Design Unit Test

Wednesday, May 02, 2012

Use case model

Unified Software Development Process

Wednesday, May 02, 2012

Unified Software Development Process

i1:Issue status={Closed} i5:Issue i2:Issue status = {Open}

i3:Issue status = {Open} i6:Issue status = {Open}

Issue-Based Life Cycle Model

Wednesday, May 02, 2012

Issue-Based Life Cycle Model

Wednesday, May 02, 2012

The Incremental Model

Wednesday, May 02, 2012

The Incremental Model

Wednesday, May 02, 2012

The Incremental Model

Wednesday, May 02, 2012

The RAD Model

The RAD Model

Agile Software Development56

Agile Software Development 57

Das könnte Ihnen auch gefallen