Software Processes-Softwarre Engineering-Lecture Slides, Slides of Software Engineering

Download Software Processes-Softwarre Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Part I: OVERVIEWSoftware ProcessesSoftware Processes

Software Engineering

Objectives

•^

To introduce software process modelsT

d

ib

th

i^

d l

d

h

•^

To describe three generic process models and whenthey may be used

-^

T

d

ib

tli

m d l

f

•^

To describe outline process models forrequirements engineering, software development,testing and evolutiontesting and evolution

-^

To explain the Rational Unified Process model

-^

To introduce CASE technology to support software

-^

To introduce CASE technology to support softwareprocess activities

The Software Process

•^

A structured set of activities required to develop a

ft

t

software system– Specification;– Design;– Validation;

• Evolution. -^

A software process model is an abstract

-^

A software process model is an abstractrepresentation of a process. It presents a descriptionof a process from some particular perspectiveof a process from some particular perspective.

Generic Software Process Models

•^

Software process models focus on the Softwarelif

l^

h

i i

th

f^

t^

t t

fi i h

lifecycle emphasizing the process from start to finish– Defining goals

• Defining the project outcome, and its role in a global

strategy.

• Analysis of requirements and feasibility
  • Collecting, analyzing, and formulating the customer's

requirements and evaluating constraints.

• General design
  • General architectural requirements of the application.
    • Detailed design

g

• Precise definition of application.

Generic Software Process Models

• Beta Testing

E^

h^

h^

f^

f^

i i

l

• Ensure that the software conforms to original

specifications. D

i

• Documentation
  • Document necessary information for software users

d f

f t

d^

l^

t

and for future development.

• Implementation– Maintenance
  • Corrective procedures and minor software updates.

Generic Software Process Models

•^

The Waterfall model– Separate and distinct phases of specification and

development.

•^

Evolutionary development– Specification, development and validation are

p

,^

p

interleaved.

•^

Component-based software engineeringComponent-based software engineering– The system is assembled from existing

componentscomponents.

Waterfall Model

•^

Software Production Companies– Define outputs for each phase– Define methods to be used to produce outputs– Organize methods into software development

methodology

gy

The Waterfall Model

•^

The model emphasizes the importance of

i^

t^

d

i^

d

lit

requirements, design and quality assurance.– The model suggests that software engineers

should work in a series of stages.

• Before completing each stage, they should

perform quality assurance (verification andvalidation).

• The waterfall model also recognizes, to a limited

extent, that you sometimes have to step back to

,^

y^

p

earlier stages.

11

docsity.com

Feasibility Study

•^

Purpose:

P^

f^

ibili

d^

d^

h^

l

• Prepare a feasibility study document that evaluates cost

and benefits of application

P

l

•^

People:

• Customer, end user, software engineers

•^

Feasibility document contains

• Problem definition• Alternative solutions, expected benefits• Required resources, costs, and delivery dates• Global problem analysis, future worth of software

Requirements Analysis/Specification

•^

Purpose:

Id

if^

i^

d^

li i

f^

li^

i

• Identify required qualities of application

•^

People:

• Interactions between users & software engineers

•^

Requirements specification document contains

q

p

• Functional Requirements
  • What product is intended to perform

What product is intended to perform

• Non-Functional Requirements
  • Reliability (Available Secure Integrity Safety etc)• Reliability (Available, Secure, Integrity, Safety, etc)• Accuracy of Results, Performance, HCI, etc

O

ti^

/Ph

i^

l^

t^

i t

P^

t bilit

t

• Operating/Physical constraints, Portability, etc

Coding and Module Testing

•^

Purpose:

A

ll^

C d

d T

S f

• Actually Code and Test Software

•^

People:

• Software engineers and managers, end users (test)

•^

Alternatives implemented and evaluated

p

• List vs. Array vs. API (Set, Collection, …)• Different Algorithms w.r.t. space and/or time

g^

p

•^

Usage of company wide standards

• Program layout comments and headers naming

Program layout, comments and headers, namingconventions, module testing, code inspection forInspection for adherence to standards, check for

p software qualities

Integration and System Testing

•^

Purpose:

I^

i^

f i di id

l^

d^

i

• Integration of individual components and testing

•^

People:

• Software engineers, teams, managers, users

•^

Collections of modules and entire system tested

y

• Incremental Testing• Big-Bang Testing

g^

g^

g

• Alpha Testing (test under realistic conditions)

•^

Usage of company wide standardsUsage of company wide standards

• Method of integration, test data design• Documentation of tests and results• Documentation of tests and results

Characteristics of Waterfall Model

•^

Linear:– From start to end without backtracking

-^

Rigidity:– Results of each phase completed before

proceeding to next phasep

g^

p

• Assumes requirements and specifications finalized -^

Monolithic:

-^

Monolithic:– All planning is geared towards single delivery date

-^

What are the Problems with this Process?

Limitations of the Waterfall Model

• The model implies that you should attempt to

l t

i^

t^

b f

i^

t^

th

complete a given stage before moving on to thenext stage

D

f^

h^

f^

h^

i

• Does not account for the fact that requirements

constantly change.

• It also means that customers can not use anything until• It also means that customers can not use anything until

the entire system is complete. The model makes no allowances for prototyping

• The model makes no allowances for prototyping.– It implies that you can get the requirements right

b

i^

l^

i i

h

d

d

i^

i^

h

by simply writing them down and reviewing them.

• The model implies that once the product is

finished, everything else is maintenance.

20

docsity.com