softwareengg2012 lecture 03

8/12/2019 SoftwareEngg2012 Lecture 03

http://slidepdf.com/reader/full/softwareengg2012-lecture-03 1/44

Software EngineeringBS (Computer Science)

1

Lecture-03Date: 25-02-2012

Dr. S. N Ahsan



Software Engineering

1. Software Construction

2. Software Management

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



Software Engineering


Quality Focus

Process

Methods

Tools



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/softwareengg2012-lecture-03 7/4408.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 strong balance between order

and chaos. Absolute order means absence of

variability. Absolute chaos makes coordinationand coherence impossible. Thus, a balance is

needed.

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 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.




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




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)




SPECIALIZED PROCESS MODELS

39



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.

softwareengg2012 lecture 03

Documents