SoftwareEngg Lecture 03new

8/12/2019 SoftwareEngg Lecture 03new

http://slidepdf.com/reader/full/softwareengg-lecture-03new 1/58

Software EngineeringBS (Computer Science)

1

Lecture-03(a)Date: 13-10-2012

Dr. S.N Ahsan



Phases of Software Life Cycle

Definition Phase - behavior of the system

Development Phase - How to obtain the desired

behavior

Maintenance - change the behaviorCorrective - fix uncovered defect

Adaptive - Platform change

Enhancement - Perfective, additional functionality

Preventive - re-engineering, make system more

maintainable

31.03.2014 Dr. S. N Ahsan, IQRA-University 2



Software Engineering

1. Software Construction

2. Software Management




Software Common Process Framework


A common process framework is established by defining

a small number of framework activities that are applicable

to all software projects, regardless of their size or

complexity.



A Generic Process Framework1. Communication

2. Planning

3. Modeling4. Construction

5. Deployment




Umbrella Activities

1. Software Project Tracking and Control

2. Risk Management

3. Software Quality Assurance4. Technical Reviews

5. Measurements

6. Software Configuration Management

7. Reusability Management

8. Work Product Preparation and Production



http://slidepdf.com/reader/full/softwareengg-lecture-03new 7/5808.10.2011

Process Flow

1. Linear Process Flow

2. Iterative Process Flow

3. Evolutionary Process Flow

4. Parallel Process Flow

7Dr. S. N Ahsan, IQRA-University



Software Process Models Prescriptive Process Models

1. Waterfall model (Royce, 1970) V-Model: The V-model depicts the relationship of quality assurance

actions to the actions associated with the different step of waterfall

model

2. Incremental Process Models

3. Evolutionary Process Models

Prototyping

Spiral model (Boehm, 1988)

4. Concurrent Models

Specialized Process Models

1. Component Based Development2. The Formal Methods Model

3. Aspect Oriented Software Development

The Unified Process




PRESCRIPTIVE-MODEL

9



Prescriptive Process Models

•Developed to bring order and structure to the

software development process. To get away from

the chaos of most development processes.•But there is a strange balance between order and

chaos. Absolute order means absence of

variability. Absolute chaos makes coordination

and coherence impossible. Thus, a balance isneeded.

08.10.2011 10Dr. S. N Ahsan, IQRA-University



Waterfall Model

Requirements

Design

Implementation

Maintenance

Testing




Waterfall Strengths

Easy to understand, easy to use

Provides structure to inexperienced staff

Milestones are well understood

Sets requirements stability Good for management control (plan, staff, track)

Works well when quality is more important than

cost or schedule




Waterfall Deficiencies

All requirements must be known upfront The following phase should not start until the

previous phase has finished.

Deliverables created for each phase are

considered frozen – inhibits flexibility Can give a false impression of progress

Does not reflect problem-solving nature ofsoftware development – iterations of phases

Integration is one big bang at the end

Little opportunity for customer to preview thesystem (until it may be too late)




When to use the Waterfall Model

Requirements are very well known Product definition is stable

Technology is understood

New version of an existing product Porting an existing product to a new platform.




08.10.2011

V-Shaped SDLC Model

A variant of the

Waterfall that

emphasizes the

verification and

validation of theproduct.

Testing of the product

is planned in parallel

with a corresponding

phase of development




V-Shaped Strengths

Emphasize planning for verification andvalidation of the product in early stages of

product development

Each deliverable must be testable Project management can track progress by

milestones

Easy to use




V-Shaped Weaknesses

Does not easily handle concurrent events

Does not handle iterations or phases

Does not easily handle dynamic changes in

requirements Does not contain risk analysis activities




When to use the V-Shaped Model

Excellent choice for systems requiring highreliability – hospital patient control applications

All requirements are known up-front

When it can be modified to handle changingrequirements beyond analysis phase

Solution and technology are known




Incremental Development Model




Incremental Model Strengths

Develop high-risk or major functions first

Each release delivers an operational product

Customer can respond to each build

Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost

Initial product delivery is faster

Customers get important functionality early Risk of changing requirements is reduced




Incremental Model Weaknesses

Requires good planning and design Requires early definition of a complete and fully

functional system to allow for the definition ofincrements

Well-defined module interfaces are required(some will be developed long before others)

Total cost of the complete system is not lower




When to use the Incremental Model

Risk, funding, schedule, program complexity,or need for early realization of benefits.

Most of the requirements are known up-front

but are expected to evolve over time A need to get basic functionality to the market

early

On projects which have lengthy development

schedules

On a project with new technology




RAD Model

Rapid Application Development – anincremental model that emphasizes a short

development cycle.

Uses component-based construction method.

Does not work for all projects… particularly

large projects or when project is high risk.




RAD Strengths

Reduced cycle time and improved productivitywith fewer people means lower costs

Time-box approach mitigates cost and schedulerisk

Customer involved throughout the completecycle minimizes risk of not achieving customersatisfaction and business needs

Focus moves from documentation to code(WYSIWYG).

Uses modeling concepts to capture informationabout business, data, and processes.




RAD Weaknesses

Accelerated development process must givequick responses to the user

Risk of never achieving closure

Hard to use with legacy systems

Requires a system that can be modularized

Developers and customers must be committed torapid-fire activities in an abbreviated time

frame.




When to use RAD

Reasonably well-known requirements

User involved throughout the life cycle

Project can be time-boxed

Functionality delivered in increments High performance not required

Low technical risks

System can be modularized




Evolutionary Process Models

Software evolves over time (web pages are a prime example)

Limited version is needed to meet business

pressures. Time does not allow a full and complete system

to be developed.

Evolutionary models are iterative as software

engineers develop increasingly more completeand complex systems




Prototyping (Evolutionary Model)

Prototypes are built when goals are general andnot specific.

Prototyping can be used as a standalone process

or by one of the processes presented.

The prototype serves as the first system. Users

get a feel for the actual system and devleopers

get something built quickly.

A prototype is intended for short term use buttoo often they are used much longer.




08.10.2011

Prototyping (Evolutionary Model)

Requirements

Implementation

Design

Testing

Design

Implementation

Testing

Maintenance




Prototyping Strengths

Customers can “see” the system requirements asthey are being gathered

Developers learn from customers

A more accurate end product

Unexpected requirements accommodated

Allows for flexible design and development

Steady, visible signs of progress produced

Interaction with the prototype stimulatesawareness of additional needed functionality




Prototyping Weaknesses

Tendency to abandon structured programdevelopment for “code-and-fix”

development

Bad reputation for “quick-and-dirty”methods

Overall maintainability may be overlooked

The customer may want the prototype

delivered.

Process may continue forever (scope

creep)




When to use Prototyping

Requirements are unstable or have to beclarified

As the requirements clarification stage of a

waterfall model

Develop user interfaces

Short-lived demonstrations

New, original development

With the analysis and design portions of object-

oriented development.




The Spiral Model

An evolutionary model that couples the iterativenature of prototyping with the controlled,

systematic aspects of waterfall model.

Spiral model is often developed in a series of

releases or versions. Is Adobe or Microsoft

working on new releases?

Better for large projects.




Spiral Model (Evolutionary Model)




08.10.2011

Risk analysis

Risk analysis

Risk analysis

Risk analysis Proto-

type 1

Prototype 2

Prototype 3Opera-

tional protoype

Concept of Operation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Development plan

Requirements planLife-cycle plan

REVIEW

Spiral Model (Evolutionary Model)




Spiral Model Strengths

Provides early indication of insurmountablerisks, 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




Spiral Model Weaknesses

Time spent for evaluating risks too large for

small or low-risk projects

Time spent planning, resetting objectives, doingrisk 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 proceedthrough the next iteration




When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because

of potential changes to economic priorities Users are unsure of their needs

Requirements are complex

New product line

Significant changes are expected (research andexploration)




Dr. S. N Ahsan, IQRA-University 39

Evolutionary Models: Concurrent

Under rev iew

Baselined

Done

Under

revision

Await ing

changes

Under

development

none

Modeling act ivit y

represents the state

of a software engineering

activity or task

08.10.2011



40

Evolutionary Models: Concurrent The former image depicted only the modeling activity

Indeed, concurrent engineering is a set of frameworkactivities such as Communication, Modeling, etc.

Each of these activities is in one of its states…

A state is some externally observable mode of behaviour

PROBLEMS:

Prototyping (and other evolutionary processes) pose

problems to project planning (too much uncertainty)

Evolutionary speed may not be optimal: too slow affects

productivity, too fast leads to chaos

Sometimes software processes should focus on flexibility

and extensibility, rather than on quality - delivery delays

may make us miss the market niche and window of

opportunity 08.10.2011 Dr. S. N Ahsan, IQRA-University



SPECIALIZED PROCESS MODELS

41



Component Based Development

COTS or Commercial Off-The-Shelfcomponents are becoming more available.

Most (not all) COTS components have targeted

functionality with good interfaces that enable

the component to be integrated.

This approach incorporates many of the aspects

of the spiral model.




Formal Methods Development Model

Formal mathematical specification of thesoftware.

Specify, develop and verify by rigourous math

notation.

Eliminates ambiguity, incompleteness, and

inconsistency.

Used more where safety-critical software is

developed, e.g., aircraft avionics, medicaldevices, etc.




Aspect-Oriented SW Development

Nearly all SW has localized features, functionsand information content.

User or customer concerns or needs must be

included. These can be high-level concerns like

security or lower-level such as marketing

business rules or systemic such as memory

management.




Crosscutting Concerns

AOP addresses behaviors that span many, often

unrelated, modules. Core Concerns:

◦ Primary core functionality.

◦ Central functionality of a module.

Crosscutting Concerns:◦ System wide concerns that span multiple

modules.

◦ Cuts across the typical division of

responsibility. OOP creates a coupling between core and

crosscutting concerns.

AOP aims to modularize crosscutting concerns.




Aspects

In AOP crosscutting concerns are implemented in

aspects instead of fusing them into core modules.

Aspects are an additional unit of modularity.

Aspects can be reused.

By reducing code tangling it makes it easier tounderstand what the core functionality of a

module is.

An “aspect weaver” takes the aspects and the core

modules and composes the final system.




THE UNIFIED PROCESS MODELS

47




Unified Process Models

A “use-case driven, architecture-centric, iterativeand incremental” software process closely

aligned with the Unified Modeling Language

(UML)

08.10.2011

UP Phases




UP Phases

Inception Elaborat ion Construct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

08.10.2011



50

‘rules of thumb’ about approach to be

used

IF uncertainty is high

THEN use evolutionary approach

IF complexity is high but uncertainty is not

THEN use incremental approach

IF uncertainty and complexity both low

THEN use one-shot

IF schedule is tightTHEN use evolutionary or incremental



The Unified Process

Benefits of iterative development include:

1. Early mitigation of high risks

2. Early visible progress.

3. Early feedback, user engagement, and adaptation,

leading to a system that more nearly meets the needsof the various stakeholders.

4. Managed complexity – no compounding of

complexity by postponing the implementation phase.

5. Learning within an iteration.



Timeboxing

Iterations are “timeboxed” or fixed in length.

Iteration lengths of between two to six weeks are

recommended.

Each iteration period has its own development plan.

Management of a UP project:



The Unified Process

Inc. Elaboration Construction Trans.

phase phase

iteration

Final releaseRelease

The end of each

iteration is a minor

release



54

Agile Development

Agile Software Engineering combines a

philosophy and a set of development guidelines. The philosophy encourages customer satisfaction

and early incremental delivery of software,

Small highly motivated project teams

Informal method

Minimal Software Engineering work products

Development simplicity



Agile Software Development

Speed up or bypass one or more life cycle phases Usually less formal and reduced scope

Used for time-critical applications

Used in organizations that employ disciplinedmethods

What is Agility?

◦ Quick and effective response to change

31.03.2014 55Dr. S. Nadeem Ahsan, IQRA-University



31.03.2014 Dr. S. Nadeem Ahsan, IQRA-University 56

Agility and the Cost of Change

E t P i



57

Extreme Programming

Developers work in pairs

Coding is the key activity throughout a software project

Test cases and expected results devised before

software design

After testing of increment, test cases added to aconsolidated set of test cases

Developers work in pairs

Test cases and expected results devised before

software design After testing of increment, test cases added to a

consolidated set of test cases



XP Practices (1-12)

1. Planning game

2. Small releases

3. Metaphor

4. Simple design

5. Testing

6. Refactoring7. Pair-programming

8. Collective ownership

9. Continuous integration

10. 40-hour week11. On-site customer

12. Coding standards

SoftwareEngg Lecture 03new

Documents

Transcript of SoftwareEngg Lecture 03new