32
Introduction to Software Engineering (CSC291) Instructor Humaira Afzal Lecturer [email protected] u.pk 1

Generic Software Process Models

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Generic Software Process Models

1

Introduction to Software Engineering(CSC291)

InstructorHumaira Afzal

[email protected]

Page 2: Generic Software Process Models

Generic software process models

• The waterfall model and V model▫Separate and distinct phases of specification and

development

• Evolutionary development▫Specification and development are interleaved

• Component-based development▫The system is assembled from existing components

Page 3: Generic Software Process Models

V Model

• A variation of the waterfall model• It is also known as Verification and Validation model.• It is based on association of a testing phase for each

corresponding development stage.• For every single phase in the development cycle there is a

directly associated testing phase.• This is a highly disciplined model and next phase starts only

after completion of the previous phase.

Page 4: Generic Software Process Models

V Model Design

Page 5: Generic Software Process Models

V Model Verification Phases

Following are the Verification phases in V-ModelBusiness Requirement Analysis: • This phase involves detailed communication with the customer to

understand his expectations and exact requirement. • The acceptance test design planning is done at this stage as business

requirements can be used as an input for acceptance testing. System Design: • System design would comprise of understanding and detailing the

complete hardware and communication setup for the product under development.

• System test plan is developed based on the system design.

Page 6: Generic Software Process Models

Architectural Design: • Based on the technical and financial feasibility the final decision is taken. • System design is broken down further into modules taking up different

functionality. • High Level Design (HLD).• The data transfer and communication between the internal modules and with the

outside world (other systems) is clearly understood and defined in this stage. • With this information, integration tests can be designed and documented during

this stage.

Module Design:• In this phase the detailed internal design for all the system modules is specified• Referred to as Low Level Design (LLD).• It is important that the design is compatible with the other modules in the

system architecture and the other external systems. • Unit tests can be designed at this stage

V Model Verification Phases

Page 7: Generic Software Process Models

V ModelCoding Phase• The actual coding of the system modules designed in the design phase is

taken up in the Coding phase.

• The best suitable programming language is decided based on the system and architectural requirements.

• The coding is performed based on the coding guidelines and standards.

• The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

Page 8: Generic Software Process Models

V Model Validation Phases

Following are the Validation phases in V-Model:

Unit Testing: • Unit tests designed in the module design phase• Unit testing is the testing at code level and helps to eliminate bugs at an

early stage

Integration Testing: • Integration testing is associated with the architectural design phase. • Integration tests are performed to test the coexistence and communication

of the internal modules within the system.

Page 9: Generic Software Process Models

System Testing: • System testing is directly associated with the System design phase. • System tests check the entire system functionality and the communication of

the system under development with external systems. • Most of the software and hardware compatibility issues can be uncovered

during system test execution.

Acceptance Testing: • Acceptance testing is associated with the business requirement analysis phase

and involves testing the product in user environment.• Acceptance tests uncover the compatibility issues with the other systems

available in the user environment. • It also discovers the non functional issues such as load and performance

defects in the actual user environment.

V Model Validation Phases

Page 10: Generic Software Process Models

Advantages of V-model

• Simple and easy to use.• Testing activities like planning, test designing ,happens well

before coding. • Saves a lot of time. • Higher chances of success over the waterfall model.• Works well for small projects where requirements are easily

understood.

Page 11: Generic Software Process Models

V-Shaped Model Problems

• No iteration of phases• Cannot handle dynamic changes in requirements throughout

the life cycle• Requirements are tested too late to make changes without

affecting the schedule• No risk analysis

Page 12: Generic Software Process Models

When to use the V-model

• The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.

• The V-Shaped model should be chosen when technical resources are available with needed technical expertise.

• High confidence of customer is required for choosing the V-Shaped model approach.

• Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.

Page 13: Generic Software Process Models

13

Evolutionary Models

Evolutionary Development:• Interleaves the activities of specification, development and

validation• Initial system is developed from abstract specification• Then refined with customer input to produce a system that

satisfies the customer’ s needs.

Two types of evolutionary development1. Exploratory2. Prototyping

Page 14: Generic Software Process Models

Exploratory Model

• Systems development method ( SDM ) • Used to design and develop a computer system or product• Consists of planning and trying different designs until one of

them seems to be the right one to develop.• This model works best in situations where few, or none, of the

system or product requirements are known in detail.• Work with customers to explore their requirements and

deliver a final system from an initial outline specification.

Evolutionary Models

Page 15: Generic Software Process Models

There are several steps in the exploratory model

• Step 1: A project is launched based on prior best-development efforts and designed to shed light on the system or expected algorithm.

• Step 2: A basic model determined before the project begins is employed with information gathered during Step 1, in addition to new project development team ideas.

• Step 3: The basic model of Step 2 is tested to determine and reinforce strengths, while improving and resolving weaknesses.

• Step 4: Based on Steps 2 and 3, a new model is developed to include any improvements or modifications.

• Step 5: The model is tested to evaluate performance and determine future potential improvements or modifications.

• Step 6: The testing process is repeated throughout the project to fulfill user satisfaction and predetermined requirements.

Page 16: Generic Software Process Models

16

Concurrent Activities

Outline Description

Initial Version

FinalVersion

Intermediate Version

Specification

Development

Validation

Exploratory Model

Page 17: Generic Software Process Models

Prototyping Model

• When a customer defines a set of general objectives for a software but does not identify detailed I/O or processing requirements.

• A prototype is built to understand the requirements.• By using this prototype, the client can get an “actual feel” of the system• The interactions with prototype can enable the client to better understand

the requirements of the desired system.• Prototyping is an attractive idea for complicated and large systems

Consists of 4 iterating phases:▫ Requirements gathering.▫ Design and build SW prototype.▫ Evaluate prototype with customer.▫ Refine requirements.

.

Evolutionary Models

Page 18: Generic Software Process Models

18

1 / 4Listen to

Customer

2Build / Revise

prototypes

3Customer

Test-Drives

prototypes

1. Requirements gathering.

2. Design and build SW prototype.

3. Evaluate prototype with customer.

4. Refine requirements.

Prototyping Model

Page 19: Generic Software Process Models

Advantages of Prototype model

• Users are actively involved in the development• Users get a better understanding of the system being

developed.• Errors can be detected much earlier.• Quicker user feedback is available leading to better solutions.

Page 20: Generic Software Process Models

Disadvantages of Prototype model

• Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

• Incomplete application may cause application not to be used as the full system was designed

• Incomplete problem analysis.

Page 21: Generic Software Process Models

When to use Prototype model

• Prototype model should be used when the desired system needs to have a lot of interaction with the end users.

• Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model.

• They are excellent for designing good human computer interface systems.

Page 22: Generic Software Process Models

Evolutionary development

• Problems▫Lack of process visibility▫Systems are often poorly structured▫Special skills (e.g. in languages for rapid prototyping) may

be required.• Applicability▫For small or medium-size interactive systems;▫For parts of large systems (e.g. the user interface);▫For short-lifetime systems.

Page 23: Generic Software Process Models

Component-based software engineering

• Based on systematic reuse where systems are integrated from existing components.

• People working on the project Know of design or code (similar to that required) Modify them as needed incorporate them into their system

• Process stages▫ Component analysis▫ Requirements modification▫ System design with reuse▫ Development and integration

• This approach is becoming increasingly used as component standards have emerged.

Page 24: Generic Software Process Models

Reuse-oriented development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Page 25: Generic Software Process Models

Component-based software engineering

Component analysis• Given the requirement specification• Search is made for components• Usually there is no exact match. Requirement Modification• Requirements are analyzed—using information of discovered components• If modifications are impossible— component analysis activity may be re-

entered to search for alternate solutionSystem Design with Reuse• Frame work of system is designed or an existing frame work is reused.Development and integration Software• Existing software /modified and newly developed components are

integrated.

Page 26: Generic Software Process Models

Component-based software engineering

Advantages• Reduce the amount of software to be developed• Reducing cost and risk• Faster delivery of softwareDisadvantages• Requirement changes—may lead to a system that does not meet the real

needs of users• Control over the system evolution is lost

Page 27: Generic Software Process Models

Process iteration• Change is necessary in all large software projects.

• Change?

• What to do?

• Iteration means earlier stages are reworked in the process for large systems

• Iteration can be applied to any of the generic process models

• Two (related) process models▫ Incremental delivery▫Spiral development

Page 28: Generic Software Process Models

Incremental delivery

“The software specification, design and implementation are broken down into a series of increments that are each developed in turn”

• Waterfall model & evolutionary approach?...in case of change

• Incremental delivery—in-between approach

• System development is decomposed into increments and each delivers a proportion of the system.

• Increments are developed based on their requirement priorities.

Page 29: Generic Software Process Models

Incremental development

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

Page 30: Generic Software Process Models

Incremental delivery(Steps)1.Customer identify—services provided by the system2. Then identify which of the services are most important and

which are least important3. No of delivery increments are then identified with sub-set of

the system functionality4.Highest priority services delivered first5. Requirements for the first increment are defined in detail6. First Increment is developed and delivered ..customer can put

into service.(Benefit for customer?)7.During development ….further requirements analysis for later

increments can take place

Page 31: Generic Software Process Models

Incremental development advantages

• Customer do not have to wait until the entire system is delivered

• Customers can use the early increments...gain experience that informs their requirements for later system increments

• Lower risk of overall project failure..?

• The high priority system services receive more testing..how?

Page 32: Generic Software Process Models

Incremental development Problems and example...?