Top Banner
CSC 426 (Software Engineering) Lecture Note Part I Cont’d: SOFTWARE DEVELOPMENT PROCESS MODELS AJAYI, Olusola Olajide Department of Computer Science, Faculty of Science, Adekunle Ajasin University, Akungba-Akoko, Ondo State, Nigeria. [email protected] / [email protected] 08113699553 / 07056433798 / 08137044500
48

CSC426 - SDLC Models

Jan 11, 2017

Download

Education

Bro Shola Ajayi
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: CSC426 - SDLC Models

CSC 426 (Software Engineering) Lecture Note

Part I Cont’d:SOFTWARE DEVELOPMENT PROCESS MODELS

AJAYI, Olusola OlajideDepartment of Computer Science,Faculty of Science,Adekunle Ajasin University, Akungba-Akoko, Ondo State, [email protected] / [email protected] 08113699553 / 07056433798 / 08137044500

Page 2: CSC426 - SDLC Models

Software Development Process (SDP)_

•Munassar et al (2010) defined it as an abstract representation of a process that presents a description of a process from some particular perspectives.

•In this class/study, SDP refers to activities involved in producing/developing software.

Page 3: CSC426 - SDLC Models

SDP Cont’d – The Activities/Processes

Software SpecificationSoftware DevelopmentSoftware ValidationSoftware Evolution

Page 4: CSC426 - SDLC Models

SDP Cont’d – The Activities/Processes

Software

Specification

Software

Development

Software

Validation

Software

EvolutionFigure 1: Software Development Activities/Processes

Page 5: CSC426 - SDLC Models

SDP Activities/Processes – The Breakdown

•Software Specification: This activity involves stating the functionalities (operations) as well as the constraints/limitations of the software. Major Activity Requirements.

•Software Development: This activity involves developing (producing) a software according to the specification outlined in the first stage of the development process. Major Activity Designs.

Page 6: CSC426 - SDLC Models

SDP Activities/Processes – The Breakdown Cont’d

•Software Validation: This activity checks the software developed to ensure it conforms to the specification earlier concluded upon. Major Activity Testing.

•Software Evolution: This activity ensures that the software produced is modifiable/adjustable.Major Activity Maintenance.

Page 7: CSC426 - SDLC Models

SDP Activities/Processes – The Breakdown Cont’d

•Paraphrasing Pressman, R. S. (2010), we can define SD Process as a roadmap to defining, building, testing, & deploying timely and high quality software applications.

Both User & Developers are

involved

Only Development

Team are involved

Only Development

Team are involved

Both User & Developers are

involved

Requirements Designs Testing Maintenance

Page 8: CSC426 - SDLC Models

SDLC Models

•This refers to the existing and established frameworks for developing software.

•For the purpose of this study, we shall be examining six (6) common ones.

Page 9: CSC426 - SDLC Models

SDLC Models Cont’d

i. Waterfall Modelii. Evolutionary Modeliii. V-Shape Modeliv. Spiral Modelv. Agile Development Modelvi. Rational Unified Process (RUP)

Model

Page 10: CSC426 - SDLC Models

SDLC Models Cont’d

i. Waterfall ModelUndoubtedly the oldest and famous of all the available models. It acts as baseline for other SDLC models. In other words, other models are derivatives of Waterfall Model.

It major strength lies in the fact that it dwells much on requirement gathering and ascertaining of same (by way of feedbacks) to prevent flaws in the development of the project. Most suitable where requirement is well understood.

Page 11: CSC426 - SDLC Models

SDLC Models Cont’di. Waterfall Model - VARIANTS

Requirement Analysis and Definition/Specification

Implementation and Unit Testing

Integration and System Testing

Operation and Maintenance

System and Software Design

Figure 2: Classical Waterfall Model

Page 12: CSC426 - SDLC Models

SDLC Models Cont’di. Waterfall Model – VARIANTS cont’d

Figure 3: Pure Waterfall Model

Page 13: CSC426 - SDLC Models

SDLC Models Cont’di. Waterfall Model – STRENGTHS/ADVANTAGES

With her ‘define-b4-design’ & ‘design-b4-coding’ approach, it reduces flaws/errors in development.

Applications developed with it, are easily understood, implementable and maintained.

Documentation is embraced and enhanced. With its deep flow, quality assurance is ensured.

Page 14: CSC426 - SDLC Models

SDLC Models Cont’di. Waterfall Model – WEAKNESSES/DISADVANTAGES

Costly Time-consuming, leading to late project delivery

Page 15: CSC426 - SDLC Models

Maintenance

SDLC Models Cont’di. Waterfall Model – SUMMARY

Summarily, Waterfall Model complies with the process flow shown below:

Requirements

Designs

Testing

Figure 4: SDLC Process showing Waterfall Compliance

Proc

esse

s

Compliance

Page 16: CSC426 - SDLC Models

SDLC Models Cont’d

ii. Evolutionary ModelThis model involves the culmination of major activities involved in developing software. The model emphasize ‘fast/quick’ design approach to solution development.

Unlike Waterfall, the strength of this model is time-saving, which is achieved by rapid way of developing software with adequate feedbacks.

Page 17: CSC426 - SDLC Models

SDLC Models Cont’dii. Evolutionary Model - VARIANTS

The available variants include:

Throw-Away Prototyping ModelRapid Application Development Model / Iterative Prototyping ModelIncremental Prototyping Model

Page 18: CSC426 - SDLC Models

SDLC Models Cont’da. Throwaway Prototyping Model –

Emphasizes fast design + minimal requirement analysis.In this prototyping type, a small portion of an ‘on-going’ system is given to the client/user for evaluation purpose. The feedbacks allow for some modifications to be carried out on the main system, after which the prototype is discarded/done with/thrown away. This is why it is also refer to as a working system – it is only developed for evaluation/testing purposes, it is never part of the final delivered system/software.

Page 19: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 5: Throwaway Prototyping Model – Variant I

Requirement Analysis

Design/Build Demo Software

Testing (Customer Test Run Demo App)

Page 20: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 6: Throwaway Prototyping Model – Variant II

Page 21: CSC426 - SDLC Models

SDLC Models Cont’db. Rapid Application Development (RAD)

This iterative model emphasizes component-based construction in rapid software development approach. It embraces, encourages and enables participation of development team in actualizing speedy/timely development.

Figure 7 shows the different phases of RAD / Iterative model as catered by different development teams.

Page 22: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 7: RAD Model – Variant I

Page 23: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 8: RAD Model – Variant II

Page 24: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 9: RAD Model – Variant III

Specification

Validation

Development

Initial Version

Intermediate Version

Final Version

Specification

Development

Validation

1st Version

Intermediate Version

Final Version or Product

Page 25: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 10: RAD Model – Variant IV

Requirement Analysis

Develop Prototype

DeploymentClient/User Evaluation

Feedback for Modification

Final Implementation

& Integration

Deployment & Operation Maintenance

Page 26: CSC426 - SDLC Models

SDLC Models Cont’dc. Incremental Model – Like the Prototyping, it

emphasizes fast design + minimal requirement analysis. However unlike prototyping where the demo app is delivered, the core product/app is delivered, used and reviewed by the user, and feedback for modifications.

Figure 11 shows the Incremental Model.

Page 27: CSC426 - SDLC Models

SDLC Models Cont’d

Figure 11: Incremental Model

Page 28: CSC426 - SDLC Models

SDLC Models Cont’dDifferences between Waterfall & Evolutionary

Waterfall Evolutionary

Time consuming Time-saving

Costly Cheap

Inflexible Flexible

Process is easily understood, implementable, and maintainable

Clumsy process due to excessive iterations and prototypes

Sufficient requirement analysis carried out

Insufficient requirement analysis performed

Table 1: Differences between Waterfall and Evolutionary Models

Page 29: CSC426 - SDLC Models

SDLC Models Cont’diii. V-Shaped Model

This is an extension of the Waterfall Model, whose development is bent upward after the implementation/coding phase to form a V-Shape.

Figure 12 shows this.

Page 30: CSC426 - SDLC Models

SDLC Models Cont’di. V-Shaped Model

Figure 12: V-Shaped Model

Page 31: CSC426 - SDLC Models

SDLC Models Cont’di. V-Shaped Model – STRENGTHS/ADVANTAGES

Like the Waterfall, it is easy to understood, implement and maintain.

Most suitable for use where requirements are clearly spelt out.

Each development phase and the technologies/tools involved, are known.

Page 32: CSC426 - SDLC Models

SDLC Models Cont’di. V-Shaped Model – WEAKNESSES/DISADVANTAGES

Again, like the Waterfall Model, it is inflexible Costly Time-consuming (even more than the Waterfall Model). Why?

Page 33: CSC426 - SDLC Models

SDLC Models Cont’dDifferences between Waterfall & V-Shaped

Waterfall V-Shaped

No planning at early stage – jump start to requirement.

Planning is done as early test approach.

Table 2: Differences between Waterfall and V-Shaped Models

Page 34: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model

This combines the features/characteristics and strengths of prototyping and waterfall models in tandem with adequate risk analysis. It is most suitable for large, complex and security-driven/risk-involving software projects. It was described and presented by Barry Boehm in 1986 in his paper, titled: ‘A Spiral Model of Software Development and Enhancement’. It was widely accepted not because it discusses iterative processes of developing software like other models but because it presented the necessity for risk pattern and cost to be examined from the requirement to the development/deployment stage.

Page 35: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model

Figure 13: Spiral Model – A Typical Model, Variant I

Page 36: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model

Figure 14: Spiral Model – A Typical Model, Variant II

Page 37: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model

Figure 15: Spiral Model – A Full/Complete Model, Variant I

Page 38: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model

Figure 16: Spiral Model – A Full/Complete Model, Variant II

Page 39: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model – Phases & Activities(1) OBJECTIVE/PLANNING Phase

i. Decide on the visibility/possibility of the project.ii. Determine the cost of implementation.iii. Specify project timeline.iv. Suggest alternative approach to implementation.

Page 40: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model – Phases & Activities(2) RISK ASSESSMENT/ANALYSIS Phase

What do we look out for? What do we analyze?i. Developer’s level of experience.ii. Requirement information.iii. Delivery schedules.v. Key system operations.

Page 41: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model – TAXONOMY(1) Risk: Implies an uncertain outcome that has potentials

for loss.It refers to measurable parameter that determines loss.

(2) Verification: Implies checks to ensure the team is building the software product rightly.

(3) Validation: Implies checks to ensure the team is building the right software product.

(4) Testing: Implies executing the program/application with set of data (valid & invalid) to study the software behavior.

(5) Debugging: Implies examining code(s) that cause(s) failing in software performance.

Page 42: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model Flowchart

Figure 17: Spiral Model – The Flow

Page 43: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model – STRENGTHS/ADVANTAGES

Risk avoidance. Precise knowledge of requirements. Accommodates frequent changes in requirements. Like Waterfall, it is more realistic than other iterative

models in that it allows software product to evolve as the development process progresses.

Page 44: CSC426 - SDLC Models

SDLC Models Cont’div. Spiral Model – WEAKNESSES/DISADVANTAGES

Time consuming. Not generic in application – Different application

with different risk factors; so, it has to be developed and applied differently.

Complex process. Involve excessive and rigorous documentation

process. Unsuitable for small software projects.

Page 45: CSC426 - SDLC Models

SDLC Models Cont’dDifferences between Waterfall & Spiral

Waterfall Spiral

Risk is not considered Analyzes and manages risk

No adequate estimation of budget

Adequate estimation of budget achieved through planning and progressive phases

Costly Costlier

Table 3: Differences between Waterfall and Spiral Models

Page 46: CSC426 - SDLC Models

SDLC Models Cont’dSpiral Model – Boehm’s Philosophy

Figure 18: Boehm’s Philosophy that prompted Spiral Model

“Stop the life cycle—I want to get off!” “Life-cycle Concept Considered Harmful.” “The waterfall model is dead.” “No, it isn’t, but it should be.”

Page 47: CSC426 - SDLC Models

SDLC ModelsUnder Topic Exercise (UTE) 1i. Following the demonstrated discussion pattern of

this course and particularly under this topic, write on:a. Agile Modelb. RUP Model

ii. Enumerate the strengths and weaknesses of the various Evolutionary Models.

iii. Come up with a modified Spiral Model and discuss the activities of each phase of the model.

iv. In few paragraphs and in convincing ways, discuss the necessities and benefits of modeling as a pointer and preceding step to software development.

Page 48: CSC426 - SDLC Models

SDLC ModelsUnder Topic Exercise (UTE) 2i. Iterative vs Incremental Models – Comment on the

‘fight’.ii. Discuss the differences between:

i. Evolutionary and V-Shaped Modelsii. Evolutionary and Spiral Modelsiii. Evolutionary and Agile Modelsiv. Evolutionary and RUP Models

iii. Between V-Shaped and Agile Models, which will you prefer and why?

iv. V-Shaped and Agile: Which is more agile? Discuss.v. Considering Spiral and Agile Models, which springs

up software faster and more reliably? Lecture a fellow.