software models

65
INTRODUCTION TO SOFTWARE ENGINEERING Chapter 2: Process Models Week 3(Lecture 5,6) Maha Butt

Upload: mhboob-ahmad

Post on 10-Apr-2016

216 views

Category:

Documents


0 download

DESCRIPTION

For software development

TRANSCRIPT

Page 1: software models

INTRODUCTION TO SOFTWARE ENGINEERING

Chapter 2: Process Models

Week 3(Lecture 5,6)

Maha Butt

Page 2: software models

Linear ,iterative ,evolutionary ,parallel

Linear process flow executes each of the five activities in sequence.(start from communication and ended at deployment)

An iterative process flow repeats one or more of the activities before proceeding to the next.

An evolutionary process flow executes the activities in a circular manner. Each circuit leads to a more complete version of the software.

A parallel process flow executes one or more activities in parallel with other activities ( modeling for one aspect of the software in parallel with construction of another aspect of the software ).

Page 3: software models
Page 4: software models

SDLC SDLC is a process followed for a software

project, within a software organization. Software life cycle models describe

phases of the software cycle and the order in which those phases are executed

Page 5: software models
Page 6: software models

Planning & Requirement Analysis Take input from the customer Identify the problem to be solved Focus on “what” not “how” End Result: Functional specification. Reviewed by customer and designer.

Page 7: software models

Defining requirement define and document the product

requirements get them approved from the customer. This is done through ‘SRS’ – Software

Requirement Specification (A document which consists of all the product requirements to be designed and developed during the project life cycle.)

Page 8: software models

Designing Product Architecture Focus on “how” SRS is reference for product architecture Based on SRS more than one

architecture is defined in DDS(design document specification) view by stakeholders & implementers

the best design approach is selected for the product based on risk assessment, product robustness (strength), design modularity & time.

Page 9: software models

Developing the product The programming code is generated as

per DDS during this stage. Often the shortest phase if design is

performed in detailed & organized way. Reviewed by designers coders and

tester.

Page 10: software models

Testing product Verifying the code works according to

the functional specifications In this stage products defects are

reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS

Page 11: software models

Deployment & maintenance Sometime product deployment happens

in stages as per the organizations’ business strategy.

The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing)

Get feedback for next version.

Page 12: software models

Waterfall model(classic life cycle)

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. (work flows from communication through deployment in a reasonably linear fashion)

each phase must be completed fully before the next phase can begin. 

 Simple to understand and use.  Used when project is small and requirements are

clear Technology is understood

Page 13: software models
Page 14: software models

When to use Waterfall

The project is short Requirements are very well documented,

clear and fixed Product definition is stable There are no ambiguous requirements Technology is not dynamic

Page 15: software models

Advantages of Waterfall This model is simple and easy to

understand and use. Clearly defined stages Process and results are well documented It is easy to manage due to the rigidity

of the model  Waterfall model works well for smaller

projects where requirements are very well understood.

Page 16: software models

Disadvantages of Waterfall High amounts of risk and uncertainty. Poor model for long and ongoing projects. Not a good model for complex and object-

oriented projects. Cannot accommodate changing requirements.

Page 17: software models

Example Software for medical store Software for library management

Page 18: software models
Page 19: software models

V Model The V model is SDLC model where

execution of the process happens in sequential manner in V-shape.

Also known as verification and validation model.

Page 20: software models

V Model Model is an extension of the waterfall

model based on association of a testing phase

for each corresponding development stage.

Verification phases on one side of the ‘V’ Validation phases on the other side. Coding phase joins the two sides of the

V-Model.

Page 21: software models

21

Verification VS Validation

Verification: Are we building the product right? check whether the software conforms to

specifications.

Validation: Are we building the right product? check whether software meets the customer

expectations and requirements.

Page 22: software models

22

Verification VS ValidationVerification Validation

Verification is a static practice of verifying documents, design, code and program.

Validation is a dynamic mechanism of validating and testing the actual product.

It does not involve executing the code.

It always involves executing the code.

It is human based checking of documents and files.

It is computer based execution of program.

Verification uses methods like inspections, reviews, walkthroughs, and Desk-checking etc.

Validation uses methods like black box (functional)  testing, and white box (structural) testing etc.

It can catch errors that validation cannot catch.

It can catch errors that verification cannot catch.

Target is requirements specification, application and software architecture, high level, complete design, and database design etc.

Target is actual product-a unit, a module, a bent of integrated modules, and effective final product.

Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.

Validation is carried out with the involvement of testing team.

Page 23: software models

23

The V-Model

Page 24: software models

24

The V-Model Verification phases

Requirements modeling Architecture design Module design Code generation

Validation phases Unit testing Integration testing System testing User acceptance testing

Page 25: software models

When to use 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 sufficient technical resources are available with needed technical expertise.

Page 26: software models

26

Advantages of V-Model Simple and easy to use. Proactive defect tracking – that is defects are

found at early stage. Avoids the downward flow of the defects. Works well for small projects where requirements

are easily understood. Easy to manage due to the rigidity of model Testing activities like planning, test designing

happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model.

Page 27: software models

27

Disadvantages of V-Model Very rigid and least flexible. Software is developed during the implementation

phase, so no early prototypes of the software are produced.

Does not easily handle dynamic changes in requirements

Poor model for long and ongoing projects. If any changes happen in midway, then the test

documents along with requirement documents has to be updated.

Does not handle iterations or phases

Page 28: software models

Example Software for Admission management

system

Page 29: software models

Incremental ModelIn incremental model the whole requirement is divided into various builds(chunks). Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. 

Cycles are divided up into smaller, more easily managed modules. 

A working version of software is produced during the first module

So, Working software early on during the software life cycle. 

Page 30: software models

Incremental Model

Page 31: software models

When to use the Incremental Model

This model can be used when the requirements of the complete system are clearly defined and understood.

When user want some portion of the software as early as possible.

There is a need to get a product to the market early.

Resources with needed skill set are not available There are some high risk features and goals. Major requirements must be defined; however,

some details can evolve with time.

Page 32: software models

Advantages of Incremental Model Generates working software quickly and early

during the software life cycle. This model is more flexible – less costly to change

scope and requirements. Time effective Lowers initial delivery cost. It is easier to test and debug during a smaller

iteration. In this model customer can respond to each built. Easier to manage risk because risky pieces are

identified and handled during it’d iteration.

Page 33: software models

Disadvantage of Incremental Model

Total cost is higher than waterfall. Needs good planning and design. Needs a clear and complete definition of

the whole system before it can be broken down and built incrementally.

Integration overhead

Page 34: software models

Example MS word Photoshop CorelDraw

Page 35: software models

Evolutionary Models Software system evolves(to change) over time

as requirements often change as development proceeds. Thus, a straight line to a complete end product is not possible. However, a limited version must be delivered to meet competitive pressure.

Usually a set of core product or system requirements is well understood, but the details and extension have yet to be defined.

Page 36: software models

Cont… You need a process model that has been

explicitly designed to accommodate a product that evolved over time.

It is iterative that enables you to develop increasingly more complete version of the software.

Two types are introduced, namely Prototype Process Model Spiral Process Models.

Page 37: software models

Evolutionary Models: Prototyping The basic idea here is that instead of freezing

the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements.

By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Page 38: software models

Prototype The prototype are usually not complete

systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

It is just the Dummy product, or a sample product just to show the customer that how actual product will look like.

Customer evaluate prototype to refine requirements

Page 39: software models

Prototype Model

Page 40: software 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. It might take a while for a system to be built that allows ease of use and needs minimal training for the end user.

Prototyping ensures that the end users constantly work with the system and provide a feedback which is incorporated in the prototype to result in a useable system. They are excellent for designing good human computer interface systems.

Page 41: software models

Advantages Since a working model of the system is displayed, the

users get better understanding of the system being develop

Errors can be detected much earlier. Reduces time and cost as the defects can be detected

much earlier. Quicker user feedback is available leading to better

solutions. Missing functionality can be identified easily Since in this methodology a working model of the system

is provided, the users get a better understanding of the system being developed.

Confusing or difficult functions can be identifiedRequirements validation, Quick implementation of, incomplete, but functional, application.

Page 42: software models

Disadvantages Leads to implementing and then repairing way

of building systems. Users may get confused in the prototypes and

actual systems. 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 designedIncomplete or inadequate problem analysis.

Page 43: software models

Example Web Apps online systems

Page 44: software models

Rapid Application Development Model

In RAD model the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery.

Page 45: software models

RAD Model

Page 46: software models

When to use RAD Model RAD should be used when there is a need to develop fully

functional system within very short time(60 to 90 days) Whole System can be divided in to small modules User want complete working software as soon as possible User is willing to pay more It should be used if there’s high availability of designers

for modeling RAD SDLC model should be chosen only if resources with

high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).

Page 47: software models

Advantages Changing requirements can be accommodated. Progress can be measured. Reduced development time. Increases reusability of components Encourages customer feedback Quick initial reviews occur Iteration time can be short with use of powerful RAD

tools. Productivity with fewer people in short time. Integration from very beginning solves a lot

of integration issues.

Page 48: software models

Disadvantages Only system that can be modularized can be built

using RAD. Requires highly skilled developers/designers. High dependency on modeling skills. Inapplicable to cheaper projects as cost of

modeling and automated code generation is very high.

Management complexity is more. Dependency on technically strong team members

for identifying business requirements. Suitable for systems that are component based

and scalable. Requires user involvement throughout the life

cycle. Suitable for project requiring shorter

development times.

Page 49: software models

Spiral Model A heavy-weight, plan-driven, highly-

structured approach for large projects. Especially designed for those with higher

chances of failure. Combines iterative model and waterfall,

emphasizes risk assessment(tashkhees), customer participation, prototyping, and more.

Definitely an iterative process.

Page 50: software models

Spiral ModelSpiral model has different phases depending upon the choice that team make.CommunicationPlanningModelingConstructionDeployment

Page 51: software models

Spiral Model

Page 52: software models

Spiral Model Planning Phase: Requirements are gathered

during the planning phase. Requirements like ‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In this phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

Page 53: software models

Spiral Model Construction Phase: In this phase

software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

Deployment phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

Page 54: software models

When to use Spiral Model When the project is large For medium to high-risk projects When costs and risk evaluation is important Users are unsure of their needs Requirements are complex New product line Long-term project commitment unwise because

of potential changes to economic priorities Significant changes are expected (research and

exploration)

Page 55: software models

Advantages of Spiral Model High amount of risk analysis hence,

avoidance of Risk is enhanced. Good for large and mission-critical

projects. Strong approval and documentation

control. Additional Functionality can be added at

a later date. Software is produced early in

the software life cycle.

Page 56: software models

Disadvantages Spiral Model Can be a costly model to use. Risk analysis requires highly specific

expertise. Project’s success is highly dependent on

the risk analysis phase. Doesn’t work well for smaller projects.

Page 57: software models

Example Robotic software

Page 58: software models

Win-Win Model The Win-Win spiral approach is an

extension of the spiral approach. The phase in this approach is same as the phase in the spiral approach. The only difference is that at the time of the identifying the requirements, the development team and the customer hold discussion and negotiate on the requirements that need to be included in the current iteration of the software.

Page 59: software models

Win-Win Model Addresses more on customer

communication, the following activities are defined:

1. Identification of the system or subsystem’s key “stakeholder”.

2. Determination of the stakeholders’ “win conditions”.

3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned.

Page 60: software models

Win-Win Model

Page 61: software models

Win-Win Model The approach is called Win-Win because it is a winning situation for the development team and also for the customer. The customer wins by getting the product that fulfills most of the requirements while the development team wins by delivering software which is developed with all the requirements established after negotiations with the customer. The Win-Win approach is generally used when you have time-bound releases.

Page 62: software models

Example Complex web app

Page 63: software models

Component Based Development Component based development—the

process to apply when reuse is a development objective (COTS)

Page 64: software models

Component based development Available component-based products are

researched and evaluated for the application domain in question.

Component integration issues are considered. A software architecture is designed to

accommodate the components. Components are integrated into the

architecture. Comprehensive testing is conducted to

ensure proper functionality.

Page 65: software models

Advantages The component-based development

model leads to software reuse, and reusability provides software engineers with a number of measurable benefits.

Your software engineering team can achieve a reduction in development cycle time

as well as reduction in project cost if component reuse becomes part of your culture.