So ft wa re En gi ne er in g

Chapter 2
Software Development Life Cycle Models

So ft wa re En gi ne er in g

Software Engineering Life Cycle Models

To manage the increasing complexity of software project activities. To increase the quality of the produced software. Provide systematic and wellstructured approaches that and software environment organizations can follow.

So ft wa re En gi ne er in g

Life Cycle Models

A software development life cycle model defines the framework under which a software product is going to be develop.
High Level. The phase that the product under development will go through. Lower level. The activities involved in each of the model phases and their respective deliverables are identified.

Umbrella (on going activities) are activities that do not belong specifically to a particular phase and that must be performed during the various phases of the life cycle model.
Related to project management, risk management, quality assurance, verification, validation and reviews,

So ft wa re En gi ne er in g

Ideal Life Cycle Model

Generic Flexible Adaptable Scalable

So ft wa re En gi ne er in g

Pre-development Activities and Deliverables

Concept exploration. Start with the identification of new ideas and various stakeholders need.
Technical and economic feasibility.

System allocation. Begin with an analysis of the functions described in the statement of need.
Allocation of functions on software, hardware, and people is performed.

Software allocation. Begin with the identified software function obtain after completing the system allocation activities. Initial project management activities. The activities, milestones, and deliverables of initial project plan are specified according to the selected life cycle model.
Software estimation technique. Risks are identified and prioritize. Appropriate human, financial, and physical

So ft wa re En gi ne er in g

Pre-development Activities and Deliverables

Activity Type Concept exploration System allocation Software allocation Project management Initiation Planning Deliverables Statement of need Alternatives and feasibility Hardware, personnel, and software assessments for reused or off-the-shelf requirements Requirements System interfaces requirements softwarespecification Metrics Selected and adapted life cycle model specification Phases and deliverables Initial project plan document Estimation, risk planning, resource allocations and scheduling.

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

The System development Life Cycle (SDLC) model, also called as waterfall model, is one of the most popular development models used in the software industry The original version was first presented by Winston Royce in 1970 Phases of the model include: requirement analysis, design, implementation, testing and

So ft wa re En gi ne er in g

Waterfall Model
Analysis Design Coding Testing Installation Maintenance Po st de ve lo pm en t
Project management and Metrics Quality assurance Evaluation and testing Technical support and training Documentation Configuration management Operations and user training and support

De ve lo pm en t

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Analysis The analysis phase includes the requirement and specifications activities.

Analysis

The definition of both functional and non-functional requirements

The definition of the various interfaces between external entities

The prioritization of both of the identified software requirements

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Analysis Deliverables Software requirements specification documents

Acceptance test plan document

Scope and vision document

Revised project plan

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Analysis Phase Aspects of the software are considered including:

Constraints Assumptions Functionalities User-needs Developmental context and environment Risks Quality requirements

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Design The design phase is initiated once the deliverables of the analysis phase are reviewed and accepted by the appropriate stakeholders.

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables D e si n g

P h a se

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Implementation The activity in this phase is the transformation of the high-level design into an executable code. The database design is implemented and properly integrated with the produced code Created database is also populated with some initial data if required.

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Testing and Integration The developed modules are integrated with external modules, systems and components. The integration test plans are executed. Test results are analyzed and errors are dealt with accordingly The deliverables of this phase is integrated software

So ft wa re En gi ne er in g

Waterfall Model Development Phases, Activities, and Deliverables

Installation The software is properly integrated, delivered to the clients premises, and installed according to the installation and deployment plan. The deliverables to this phase are the official acceptance document signed by the client and the properly installed software system.

So ft wa re En gi ne er in g

Software life cycle development phases and corresponding deliverables

Life cycle phase Analysis Requirements Design Specification Implementation Testing Installation Deliverables Vision and scope Requirements High-level design Software requirements specification Detailed design User interface specification Documented code Database design Acceptance test plan Unit test plans design User interface execution Execution and result analysis report Test plans Integration test Units Installation software Stress and load Official acceptance of the software Performance Integration

So ft wa re En gi ne er in g

Software Maintenance Activities

So ft wa re En gi ne er in g

Software Maintenance Activities

So ft wa re En gi ne er in g

Continuous Life cycle Activities and Deliverables (Umbrella activities)

Activity type Project management Monitoring Quality Assurance Planning (update) Control Evaluation and Testing Technical support and internal training Documentation Configuration management Operations, user training, and support (only post-development) Deliverables Updated project plan Metrics collection plan Quality assurancemaintain Metrics database plan Quality log maintained report Project assurance review Test plans Test data Testexecution report Fault reports Training plan Training program Test metric logs Review of plans and reports Tech support reports Training manuals User manual Various technical document Installation and operating manuals Configuration identification Change logs Help desk request Updated configuration management plan Fault report logs User training plan and training materials

So ft wa re En gi ne er in g

Prototyped Waterfall Model

The prototype is an executable program that mainly implements the functional aspects of the software being developed that are related to the graphical user interface. Prototype can also address nonfunctional concern such as performance, security, and faulttolerance

So ft wa re En gi ne er in g

Waterfall Model with Prototype Requirements

Prototype requirements

Requirements Specifications Design Coding Testing Operations

So ft wa re En gi ne er in g

Object-Oriented Model

So ft wa re En gi ne er in g

Three main Types of Relationships

So ft wa re En gi ne er in g

Classes

So ft wa re En gi ne er in g

Object-Oriented Model

So ft wa re En gi ne er in g

Object-Oriented Model

So ft wa re En gi ne er in g

Incremental and Iterative Model

Software model are prioritized Accelerates the early deployment of high priority software functionalities

So Incremental and Iterative ft wa Model Re req u ire m e n ts a n d th e ir p rio ritie s En Release 1: Top priority requirements gi Requirement specification ne Design Implementation er integration Deployment in Release 2: Medium priority g
Requirement specification Design Implementation integration Deployment

requirements

Requirement specification Design Implementation integration Deployment

Release 3: Low priority requirements

So ft wa re En gi ne er in g

Spiral Model
Introduced by Barry Boehm in 1988 Addresses the weakness of the waterfall model with respect to the treatment of the software development risks Risk management is considered an on going activity that is part of the project management activities

So ft wa re En gi ne er in g

Spiral Model

So ft wa re En gi ne er in g

Rational Unified Process

Is a software engineering process management tool encapsulating best practice in software development and maintenance

So ft wa re En gi ne er in g

Rational Unified Process

So ft wa re En gi ne er in g

Nine workflow in RUP

Business modeling Requirements Analysis and design Implementation Test Deployment Project management Configuration and change management environment

So ft wa re En gi ne er in g

Rational Unified Process

So ft wa re En gi ne er in g

Rational Unified Process

So ft wa re En gi ne er in g

Rational Unified Process

So ft wa re En gi ne er in g

Agile Unified Process

is a simplified version of the Rational Unified Process (RUP) It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.

So ft wa re En gi ne er in g

Agile Unified Process Life Cycle

So ft wa re En gi ne er in g

Agile Unified Process

Serial in the Large

The serial nature of Agile UP is captured in its four phases : Inception.

The goal is to identify the initial scope of the project, a potential architecture for your system, and to obtain initial project funding and stakeholder acceptance.

Elaboration.
The goal is to prove the architecture of the system.

Construction.
The goal is to build working software on a regular, incremental basis which meets the highest-priority needs of your project stakeholders.

Transition.
The goal is to validate and deploy your system into your production environment.

So ft wa re En gi ne er in g

Agile Unified Process

Iterative in the Small

Disciplines are performed in an iterative manner, defining the activities which development team members perform to build, validate, and deliver working software which meets the needs of their stakeholders. The disciplines are:

Model. The goal of this discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain. Implementation. The goal of this discipline is to transform your model(s) into executable code and to perform a basic level of testing, in particular unit testing. Test. The goal of this discipline is to perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met. Deployment. The goal of this discipline is to plan for the delivery of the system and to execute the plan to make the system available to end users. Configuration Management. The goal of this discipline is to manage access to your project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them. Project Management. The goal of this discipline is to direct the activities that takes place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is

So ft wa re En gi ne er in g

Agile Unified Process

Philosophies of the AUP The Agile UP is based on the following principles:

Your staff knows what they're doing. People aren't going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you're interested, but doesn't force them upon you. Simplicity. Everything is described concisely using a handful of pages, not thousands of them. Agility. The Agile UP conforms to the values and principles of the Agile Alliance. Focus on high-value activities. The focus is on the activities which actually count, not every possible thing that could happen to you on a project. Tool independence. You can use any toolset that you want with the Agile UP. My suggestion is that you use the tools which are best suited for the job, which are often simple tools or even open source tools.

So ft wa re En gi ne er in g

Software development and maintenance team

So ft wa re En gi ne er in g

Hybrid functional-and project-based team organization

Project A Project B Project C Requirements specification Design Implementation Integration Deployment

So ft wa re En gi ne er in g

Software Engineering Standards

Institute of Electrical and Electronics Engineers (IEEE) Standards International Standardization Organization / International Electrotechnical Commission (ISO IEC) Standards

So ft wa re En gi ne er in g

Software Processes capability Maturity Model

The capability Maturity Model (CMM) was developed by W. Humphrey at the Software Engineering Institute at Carnegie Mellon University

So ft wa re En gi ne er in g

Characteristics of Five Maturity Levels

Maturity Initial levels 2. Repeatable 3. Defined 4. Managed 5. Optimized Characteristics -Ad hoc, informal, and nondocumented processes and standards partially documented -Processes -Software quality assurance considered -Development methodology and standards -Requirements managements and project documentedprocesses collected -Metrics on tracking in place and qualitative in place -Risk management and workflow performance -Qualitative assessment of quality assessment -Optimal processes of project performance in place in place and software quality management Continuous processes and standard Improvement in place

So ft wa re En gi ne er in g

Unified Modeling Language

UML is the de facto software industry standard modeling language for visualizing, specifying, constructing, and documenting the elements of systems in general and software systems in particular

So ft wa re En gi ne er in g

Aspects of an Object Oriented UML Diagrams

Aspects/views Diagrams Behavioral (functional) / Use Static Model case Use Case model Dynamic Structural (design) / design and Sequence, Activity, State chart, Static model Timing, Interaction Overview, process Class, Object, Composite Dynamic model structure, Component Sequence, Activity, State chart Architectural/implementation Communication Deployment and deployment Package