An Introduction to Software Engineering-Stu

8/8/2019 An Introduction to Software Engineering-Stu

1/82

An Introduction to Software

Engineering


2/82


3/82

What is Software?

software is engineered

software doesnt wear out

software is complex


4/82

What are the attributes of good software?

The software should deliver the required functionality andperformance to the user and should be maintainable,dependable and acceptable.

Maintainability Software must evolve to meet changing needs;

Dependability Software must be trustworthy;

Efficiency

Software sh

ould not make wasteful use of system resources; Acceptability

Software must accepted by the users for which it was designed.This means it must be understandable, usable and compatiblewith other systems.


5/82

Softwares Dual Role

Software is a product

Delivers computing potential

Produces, manages, acquires, modifies, displays, or transmits

information

Software is a vehicle for delivering a product

Supports or directly provides system functionality

Controls other programs (e.g., an operating system)

Effects communications (e.g., networking software)

Helps build other software (e.g., software tools)


6/82

The Changing Nature of Software

System Software. Operating Systems, Compilers

Application Software. Railway Reservation

Engineering / Scientific Software. CAD, Mat-Lab Embedded Software. Key Stroke - Character

Product - Line Software. Ms.Office, Editors , Games

WebApps (Web applications Browser). Yahoo

Artificial Intelligence software: Robotics , Expert Systems

Ubiquitous Computing. Present every where

Netsourcing. Downloading using Internet


7/82

Legacy Software

software must be adapted to meet the needs

of new computing environments or

technology. software must be enhanced to implement

new business requirements.

software must be extended to make it

interoperable with other more modern

systems or databases.

software must be re-architected to make it

viable within a network environment.

Why must it change?


8/82

Software Myths

If I decide to out source the software project to the third party,

I can just relax and let that firm build it.

Manage & Control

If we get behind Schedule, we can add more programmers

and catch up.

People can be added but only in a planned and

well coordinated manner Once we write the program and get it to work, our job is done

Software should be modify (changes) at any time


9/82

Chapter 2

Process: A Generic View

A Process defines who is doing what, when, and how to reach the goal


10/82

A Layered Technology

Software Engineering

a quality focusa quality focus

process modelprocess model

methodsmethods

toolstools


11/82

A Process Framework

Process frameworkProcess framework

Framework activitiesFramework activities

work taskswork tasks

work productswork products

milestones & deliverablesmilestones & deliverables

QA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities


12/82

Framework Activities

Communication

Planning

Modeling

Analysis of requirements Design

Construction Code generation

Testing Deployment


13/82

Umbrella Activities

Software project management

Formal technical reviews

Software quality assurance

Software configuration management Work product preparation and production

Reusability management

Measurement

Risk management


14/82

Generic process frame work used as a basics

for the description of process models.

1. Communication

2. Planning

3. Modeling

4. Construction

5. Deployment


15/82

THE CAPABILITY MATURITY MODELINTERATION

(CMMI)


16/82

The CMMI

The CMMI defines each process area in terms of

specific goals and the specific practices required

to achieve these goals.

Specific goals [SG]establish the characteristicsthat must exist if the activities implied by a process

area are to be effective.

Specific practices [SP]refine a goal into a set of

process-related activities.


17/82

SG1 : Establish Estimates

SP1.1. Estimate the scope of the project.

SP1.2. Establish estimates of work product

and task attributes.

SP1.3. Define Project life Cycle.SP1.4. Determine estimates of effort and cost.

For Example: PROJECT PLANNING


18/82

SG2 : Develop a project Plan

SP2.1. Establish the budget and schedule.SP2.2. Identify project risks

SP2.3. Plan for the data management

SP2.4. Plan for the project Resources

SP2.5. Plan for needed knowledge and skills

SP2.6. Plan stakeholder involvement

SP2.7. Establish the project plan



19/82

SG3 : Obtain commitment to the plan

SP3.1. Review plans that affect the project.

SP3.2. Reconcile work and resource levels.

SP3.3. Obtain plan commitment



20/82


21/82


22/82

Prescriptive Models

The Water Fall Model.

Incremental Process Model.

The RAD( Rapid Application Development)Model.

Evolutionary Process Models.

Prototyping

Th

e Spiral Model The Concurrent Development Model.


23/82

1. The Water Fall Model.

2. Incremental Process Model.3. The RAD( Rapid Application Development)

Model.


24/82

Water Fall Model

The Waterfall Model sometimes called as

Classic life cycle, suggests a systematic

sequential approach

to softwaredevelopment that begins with customer

specification of requirements and

progresses through planning ,modeling,

construction and deployment.

The Waterfall model is the oldest paradigm

for software engineering.


25/82

The Waterfall Model

Communication

PlanningModeling

ConstructionDeployment

analysis

designcode

test

project initiat ionrequirement gathering estimating

scheduling

tracking

delivery

support

feedback


26/82

Waterfall model phases

Requirements analysis and definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

The main drawback of the waterfall model is thedifficulty of accommodating change after the

process is underway. One phase has to becomplete before moving onto the next phase.


27/82

Waterfall model problems

Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer

requirements.

Therefore, this model is only appropriate when therequirements are well-understood and changes will be

fairly limited during the design process.

Few business systems have stable requirements.

Th

e waterfall model is mostly used for large systemsengineering projects where a system is developed at

several sites.


28/82

Problems occurred in waterfall model

Real projects rarely follow the sequential flow. As

the result, changes can cause confusion as the

project team proceeds.

It is often difficult for the customer to state all

requirements explicitly.

The customer must have the patience.

A working version of th

e program (s) will not beavailable until late in the project time span.


29/82

The Incremental Model

C o m m u ni c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

anal

de

n code

t e

t

ncrement #

ncrement #

del

er

o

t

ncrement

del

er

o

nd

ncrement

del

er

o

nt h increment

increment #n

project calendar t ime

C o m m u ni c a t i o n

P l a n n i n g

M o d e l i n g

C o ns t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t e s t

C o m m un i c a t i o n

P l a n n i n g

M o d e l i n g

C o ns t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analysis

designcode

te s t


30/82

Incremental Process Model

The incremental model applies linear

sequences in a fashion as calendar time

progress.

Each linear sequence produces deliverable

increments of the software.

Example: To develop the Word Processing Software.

i. File Management , Editing & Document productionfunctions. (Core product)

ii. Spelling & Grammar checking.

iii. Page Layout.

iv.Advance page Layout


31/82

Incremental Process Model

The delivery date of the project is uncertain.

Early increments can be implemented with

fewer people. If the core product is well

received, additional staff (if required) can be

added to implement the next increment.

It might be possible to plan early increments in

a way that avoids the use ofhardware, therebyenabling partial functionality to be delivered to

end-users


32/82

The RAD Model

Communicat ion

Planning

Model ing

business modeling

data modeling

process modeling

Const ruct ioncomponent reuse

automat ic codegenerat ion

t est ing

D epl oyment

6 0 - 9 0 d a ys

Team 1

Mode l ingbusiness modeling

data model ing

process modeling

Const ruc t ioncomponent reuse

automatic code

generation

tes t ing

Modelingb u s i n e s s m o d e l in g

d a t a m o d e l in g

p r o c e s s m o d e l in g

Constructionc o m p o n e n t r e u s e

a u t o m a t i c c o d e

g e n e r a t i o n

t e s t i n g

Team 2

Team n

integrat ion

delivery

feedback


33/82

RAD Model

RAD is the incremental software process modelthat emphasizes a short development cycle.The RAD model is a high - speed adaptation

of the water fall model, in which rapiddevelopment is achieved by using a componentbased construction approach.

If requirements are well understood and the

project scope is well constrained , the RADprocess enables a development team to createa fully functional system within a short periodof time.


34/82

RAD Model

The RAD approach maps into the generic frame

work activities.

C

ommunication works understand thebusiness problems and information

characteristics that the software must

accommodate.

Planning is essential because multiple

software teams work in parallel on

different system functions.


35/82

RAD Model

Modeling encompasses 3 major phases:

Business Modeling.

Data Modeling.

Process Modeling.

Construction emphasizes the use of pre

existing software components and theapplication of automatic code generation.

Deployment establishes a basis for

subse uent iterations, if re uired.


36/82

Problems occurred in RAD model

1. For large , but scalable projects , RAD requires

sufficient human resources to create the right

number of RAD teams.

2. If developers and customers are not committed

total the system will fail.

3. RAD may not be appropriate when technical

risks are high( e.g ., when a new application

makes heavy use of new technology).


37/82

Evolutionary Process Models

1. Prototyping

2. Th

e Spiral Model3. The Concurrent Development Model.


38/82

Prototyping

Co m m u n ic at io n

Q u ic k

la n

Co n st ru ct io n

o f

ro t o t e

M o d e l in g

Q u i ck d e s i g n

D e li e r

e e d b a c k

ploy nt

communication

Quickplan

ModelingQuick design

Construction

of prototype

Deploymentdelivery &feedback


39/82

Prototyping

A Prototyping can be used as a standalone

process model, it is more commonly used a

technique that can be implemented within the

context of anyone of the process models.

The prototyping paradigm assists the software

engineer and the customer to better understand

what is to be built when requirements are fuzzy.


40/82


41/82

Evolutionary Models: Concurrent

nder revie

aselined

one

nder

revision

aitin

chan

es

nder

develo

ent

none

Modelin

activity

reresents the state

of a soft!

are en"

ineerin"

activity or tas#


42/82

Still Other Process Models

Component based development Commercial -off -the -Shelf (

COTS) software components ,developed by vendors who offerthem as products , can be usedwhen software is built.

The process to apply when reuseis a development objective


43/82


Formal Methods Models1. Formal Methods enable a software

engineer to specify , develop andverify a computer based system byapplying a rigorous , mathematicalnotation.

2.Emphasizes the mathematicalspecification of requirements


44/82


AOSD (Aspect Oriented SoftwareDevelopment) provides a process andmethodological approach for defining,

specifying, designing, and constructingaspects

Unified Processa use-case driven,architecture-centric, iterative and

incremental software process closelyaligned with the Unified ModelingLanguage (UML)


45/82

inceptioninception

The Unified Process (UP)

soft ware increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration


46/82

UP Phases

I e t i la rat i st r t i ra sit i Pr t i

UP P ases

Workflows

e ire e ts

al sis

esi

I le e tati

est

It r ti n #1 #2 #n-1 #n

Support


47/82

Inception Phase

1. Vision Document

2. Initial use case model

3. Initial project glossary

4. Initial business case

5. Initial risk assessment

6. Project Plan

Phases and Iterations

7. Business Model

If necessary

One or more prototypes


48/82

Elaboration Phase

1. Use case Model

2. Supplementary

requirements including non

- functional

3. Analysis Model

4. Software Architecture

description

5. Executable architecturalprototype

6. Preliminary design

7. Revised risk list


49/82

Elaboration Phase

8. Project Planning including

Iteration plan

Adapted workflow , milestones

Technical work products

Preliminary user manual


50/82

Construction Phase

1. Design Model

2. Software components

3. Integrated software

increment

4. Test plan and procedure

5. Test cases

6. Support documentation

user manuals

Installation manuals

description of current

increment


51/82


52/82

Software Requirements


53/82


54/82

What is a requirement?

The requirements for a system are the description of

the services provides by the system and its operational

constraints.

These reflect the needs of customers for a system thathelps solve some problems such as controlling a

device, placing an order of finding information.

The process of finding out, analysing, documenting and

checking these services and constraints is calledrequirements engineering (RE)


55/82


56/82


57/82

User requirement definition

1. LIBSYS (Library Information System )shall keep

track of all data required by copyright licensing

agencies in the country and elsewhere.


58/82


59/82

Functional requirements

Describe functionality or system services.

Functional user requirements may be high-level statementsof what the system should do

These requirements depend on the type of software beingdeveloped, the expected users of the software and thegeneral approach taken by the organisation when writing therequirements.

The requirements are usually describe in a fair abstract way.

Statements of services the system shouldprovide, how the system should react toparticular inputs and how the system shouldbehave in particular situations.


60/82

Requirements completeness and consistency

In principle, requirements should be both complete and

consistent.

Complete

They should include descriptions of all facilitiesrequired.

Consistent

There should be no conflicts or contradictions in the

descriptions of the system facilities.

In practice, it is impossible to produce a complete and

consistent requirements document.


61/82

Non-functional requirements

1. It is related to emergent system properties such as

reliability , response time and store occupancy.

2. However , failing to meet a non functionalrequirement can mean that the whole system is

unusable.

For Example : if an air craft system does not meet its

reliability requirements, it will not be certified as safefor operation; if a real time control system fails to meet

its performance requirements, the control functions wil

not operate correctly.


62/82


63/82

Non-functional requirement types

Non - Functional

Requirements

Product

Requirements

Organizational

Requirements

External

Requirements


64/82


65/82

Organizational Requirement types

Organizational

Requirements

Delivery

Requirements

Implementation

Requirements

Standards

Requirements


66/82


67/82

SYSTEM GOAL

The system should be easy to

use by experienced controllers

and should be organised in

such a way that user errors are

minimised.


68/82


69/82


70/82

Domain requirements problems

Understandability

Requirements are expressed in the language of the

application domain;

This is often not understood by software engineersdeveloping the system.

Implicitness

Domain specialists understand the area so well that

they do not t

hink of making t

he domain requirementsexplicit.


71/82


72/82


73/82


74/82


75/82

Users of a requirements document

System Maintenance Engineers

Use the requirements to understand the system and

the relationships between its parts.


76/82


77/82


78/82


79/82


80/82


81/82

Key points

Requirements set out what the system should do and

define constraints on its operation and implementation.

Functional requirements set out services the system

sh

ould provide. Non-functional requirements constrain the system being

developed or the development process.

User requirements are high-level statements of what the

system should do. User requirements should be written

using natural language, tables and diagrams.


82/82

Documents

An Introduction to Software Engineering-Stu