CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997

CS48702-1

Illinois Institute of Technology

CS 487

Software Engineering

David Lash

© Illinois Institute of Technology 1997

CS48702-2

Software Engineering Layers


Quality Focus

Process

Methods

Tools

A focu

s of c

ontin

uous

Impr

ovement

The st

eps u

sed

to d

evelo

p

softw

are

(KPAs) How

to e

ach

parti

cular

step

within

KPAs. (E

.g.,

Testin

g, m

odeli

ng)

Automated or sem

i Automated Support for

KPA work. (E.g., automated test or build

scripts)

CS48702-3

Software Engineering Layers


A waterfall model The prototyping model Evolutionary vs Linear

–Incremental model–Spiral Model–Concurrent Development Model

CS48702-4

Life-cycle models 1. A waterfall model AKA linear

sequential model

CS48702-5

A waterfall model - Problems

–Real projects rarely follow a sequential flow. If not follow linearly can cause confusion.

–Customers often have difficulty stating requirements up-front.

–Working version of software not available until late. No prototype is in this model.

CS48702-6

2. The prototyping model

A prototype is a "model" of a system

*limited functionality *inefficient *low reliability

Listen toCustomer Build/revise

Mock up

Customer Test Drivesmock up

CS48702-7

Purpose of Prototype Model

1. to identify & define the requirements–- Is this the GUI that you want?

2. To determine the feasibility of a concept/algorithm/hardware or technical issue.

E.g., can response time objectives be met?

Will this function work on this O/S? 3. to explain processing options to the client

–- For example show 2 different implementation options

CS48702-8

CS48702-9

Prelim inaryRequirm ents

Design &Im plem ent

FinalRequirem ents

Evalualtion

Pelim inarySpecification

Prototype

FinalSpecification

Requirem ents

Specification

CS48702-10

Real-Life Trade-offs with Prototyping

- Typically if customer likes it, wants to continue use it. Do you support it?

+ Gets into customer’s hands much quicker.

- May have to scrap the entire prototype because of decision based on quickness made

- Prototype may be inefficient, hard to maintain and/or evolve

+/- May be a while between prototype to first real product.

CS48702-11

Evolutionary vs Linear

* Linear sequential models * waterfall model

* prototyping model

* Evolutionary models * the incremental model * the spiral model

CS48702-12

Incremental modelEach increment of cycle produces a product

CS48702-13

* First increment is core of product–gradual delivery of the system– Risk of development is managed more since the product evolves over time.

Appropriate in particular when–Staff is not available to build first product up-front or

– contractually need to meet deadline so scale back functions

– considerable technical risks–Requirements are changing or not known

CS48702-14

Incremental Model

R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 38.

CS48702-15

* May have problems when – As size increases - it becomes harder and harder to incorporate new functionality on each iteration

–May not realistically be able to scale back the product.

– Evolving system architecture/design can run into problems as product evolves.

CS48702-16

Spiral Model

Software developed in a series of incremental phases

Frame work activities called task regions.

–Customer communications–Planning–Risk analysis–Engineering. (Requirements and Design)–Construction & Release (Implementation, System Test)

–Customer evaluation (Acceptance test, Usability Test)

CS48702-17

CS48702-18

* Linear sequential models * waterfall model * prototyping model * Evolutionary models * the incremental model

* the spiral model

CS48702-19

The Spiral Model

- Software delivered in incremental releases - early releases are small (e.g., prototype) Helps manage risks * budget overrun * schedule slip * wrong functionality * performance problems * low reliability

CS48702-20

R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 41.

CS48702-21

The Spiral Model

-Model typically divided into 3-6 different task regions:

* Customer communication - customer to developer communication

– Planning - define resources, timeliness and stuff

–risk analysis - assess technical and management risks

–engineering design and model

– Construction & release - build, test and user support

– customer evaluation - feedback on release

CS48702-22

idea of the spiral model minimize the risk

CS48702-23

More on Spiral

Projects closest to the core are smaller,

Projects evolve via a customer evaluations

prototypes can occur anywhere they are needed

CS48702-24

Concurrent Development ModelAKA concurrent engineering

- Have people in multiple phases of software development of overall project at same time. (E.g., reqmts, testing, etc)

- When you have many simultaneous projects how tell status of overall project?

–- For example a point release with 100 different concurrent functions?

–Not really a model but a way to track state of projects

CS48702-25

CS48702-26

Process in General

–A process model is a template a project

plan. Not a magic solution that will solve all

problems

–Select a process model that is best for the

product being developed. For example:

»Spiral is used for commercial products

– No process model will solve all problems.

That’s why there are process improvement

groups.

–When in doubt:

»use a variation of the linear sequential.

»Modify it to meet your needs

CS48702-27

Requirements Development

Before you build it you gotta know what your building. (Ch 10)

- Section talks in high level about requirements gathering. Later will talk about specific modeling techniques.

CS48702-28

What are the Tasks? 1 . Systems Modeling – a world view

enterprise

»Information engineering - business

»Product engineering – product development

2. Formal Analysis – Justification and Why

3. Requirements Analysis – a specific view of the system

CS48702-29

1. System Models - world view

* Try to get a handle on the overall system or business you are working with

–How much automation is needed? –How do they do what they do?

Build a common language between Engineer and Customer(s)

– define the processes and the behavior of view being considered

–define the exogenous and endogenous input –show linkages

CS48702-30

Engineering Systems

Before you build, you gotta know What is needed

– May need to know something about the business or system that product will reside

– Who Does This? System Engineer sometimes called business analyst

– Why - some pretty basic errors can be made if don’t understand the business. E.g., Doctor medical files

CS48702-31

Front-end Models - World view* Business Process Engineering -

- Objectives - define the strategic business objectives and goals

- Data Needs - define how a business uses information & how flows

- What DATA do they need - Object: Customer_record

Name

address

phone

- Application architecture - perhaps the existing applications already running in company

- Technology architecture - the infrastructure that encompasses data and application(s). E.g., networks & computers

CS48702-32

Front-end Models - World view

* Business Process Engineering - - Need to consider the

» People»Hardware »Software »Databases »Processes»Documentation

Of the current environment.

* Start with context of entire system and progressively narrow the focus.

CS48702-33

One step may be to model System Context

User Interface Procssing

InputProcessing

OutputProcessing

Maintenance& Self-test

Process andcontrol

Functions

CS48702-34

One step may be to build data model

CS48702-35

One step may be to build Use Case Model

Salesperson

Sales Manager Sales Clerk

CS48702-36


enterprise.

»Information engineering - business



3. Requirements Analysis – a specific view

CS48702-37


* Try to get a handle on if this system should be built, what is needed, what the customer is trying to do, and what are the major pieces:

* identify customer's needs * perform feasibility study * perform economic and technical analysis * establish cost and schedule

constraints * create a system specification

CS48702-38

Formal Analysis

Feasibility – Should it be built?

Economic (cost-benefit analysis)

–Potential Revenue - ROI–Cost estimates–Liability

Market – Will someone buy this and

how much will they pay.

CS48702-39

Economic Analysis

CS48702-40

Studies to Support Analysis

Risk – What are the potential problems

developing this product/system and how are

they dealt with when they occur?

Hazard – Can this product hurt someone?

Technical – What technologies are

involved?

Others as appropriate.

CS48702-41


enterprise\

» Information engineering - business



3. Requirements Analysis – a specific view

CS48702-42

3. Requirements Engineering

* What does the customer want built? - What are the functional and

performance are needed by the system? * Identification of customer's needs *identify desired functions *overall system goals *performance expectations *reliability expectations *quality issues *cost/schedule (deadlines)

CS48702-43

5 Basic Steps

1- Requirements elicitation - ask em what

2 - Requirements analysis - 3 - Requirements specification &

Modeling 4 - Requirements validation 5 - Requirements management

CS48702-44

Requirements Process

G athe r D a ta

B u ild M ode l

W rite S pec ifica tion

N eed M ore In fo rm a tion

A cqu ired D a ta

R eviewS pec ifica tion

R e fine M ode l

C om p le te

C om p le ted

A pproved

CS48702-45

1 - Requirements Elicitation

Seems easy but not - Scope problems - boundary

conditions - understanding - customer may not

understand what is needed, SE may not understand customer business. (doctor system)

- volatility - as uncover more requirements change, or just change over time (intl phone stds)

CS48702-46

1(b) - Requirements Elicitation -

Should produce the following: – statement of need/feasibility– system scope (how bounded) – customers and stakeholders– technical environment description– description of how system used – specification of requirements by functions needed

– prototypes that are used to get these

CS48702-47

1(b) - Requirements Elicitation How is Data Gathered?

Interviewing

Surveys

Facilitated Application Specification

Quality Function Deployment

Prototyping

–throwaway

–evolutionary

Traditional Research

CS48702-48

1(b) - Requirements Elicitation Interviewing

Least expensive of all data acquisition methods

Most frequently used in business applications.

Underused in engineering application.

CS48702-49

1(b) - Requirements Elicitation What Questions do you Ask?

You are not the master inquisitor.

It is better to schedule multiple

interviews than to interrogate the

client. Unless you’re a psychic,

this will be necessary anyway.

The client knows you’re bright.

You got the job.

CS48702-50


Is client ready? Better to be polite?

–How is your day going?–Do you have time for a few questions?

If the client is having a bad day, reschedule the interview.

CS48702-51


Start with open-end (context free) question.

You need just a few questions to get all the

information that you need to start the

requirements process.–Who will use this system/product?

–What is the business purpose for the

system/product?

–What are the constraints or limitations for the

system?

CS48702-52


Probe for more detailed information and clarification. If possible, quantify.

–Can you define what you mean by good / bad.

–Can you quantify frequently / occasionally.

CS48702-53


Evaluate the effectiveness of the interview.

–Is there anything else that I need to understand about this system?

CS48702-54

1(b) - Requirements Elicitation Dos and Don’ts

Don’t interrogate

Don’t use a tape recorder unless

absolutely necessary. Always ask first.

Take good notes, but don’t make the notes

more important than the conversation.

CS48702-55

1(b) - Requirements Elicitation Facilitated Application

Specification Techniques

Good for both business and

product development

Tries to establish a “buy-in.”

Cross functional team

CS48702-56



Group interview conducted

offsite by a facilitator with

developers and customers as

participants.

Formal enough to insure that all

points are covered informal

enough to encourage a free flow

of ideas.

CS48702-57



Goals

–Identify the problem

–Negotiate different approaches

–Preliminary set of solution

requirements

CS48702-58

Facilitated Application Specification Techniques

Consensus is not always possible or a good thing.

CS48702-59

1(b) - Requirements Elicitation Quality Function Deployment

(QFD)

One of the best approaches to translate customer needs into

technical requirements.

Identify how valuable to the

customer things are and thereby

maximize customer satisfaction.

CS48702-60

Quality Function Deployment (QFD)

Uses interviews, observations,

surveys and historical data.

Translate these into a

CUSTOMER VOICE TABLE.

Table ideally maintained

throughout life of development.

CS48702-61

Quality Function Deployment (QFD)

Identifies three types of requirements.

–Normal requirements – Satisfies

customers perceived needs

–Expected requirements – Absence

cause customer dissatisfaction.

–Exciting requirements - Exceeds

customer’s perceived needs.

CS48702-62

5 Basic Steps

1- Requirements elicitation - ask em what

2 - Requirements analysis - 3 - requirements specification &

Modeling 4 - requirements validation 5 - requirements management

CS48702-63

Requirements Process

G athe r D a ta

B u ild M ode l

W rite S pec ifica tion

N eed M ore In fo rm a tion

A cqu ired D a ta

R eviewS pec ifica tion

R e fine M ode l

C om p le te

C om p le ted

A pproved

CS48702-64

Interface Requirements

Machine to Machine–Communication Protocols

Process to Process–Signaling

–Message Passing

Machine to Human–Limited (phone, microwave, HVAC)

–Information Processing

CS48702-65

2 - Requirements Analysis

- Categorizes and organizes them into subsets

- finely examine each requirement - sets up priority order of them - what omissions are there - is each requirement testable?

–(the system must boot up quickly) - any conflicting requirements?

– (large functionality set and performance)

CS48702-66

3 - Final systems Requirements Specification

- Final output of the system and requirements engineer.

- what are the input and output of the system?

- what will be built - this is what is agreed to - May or may not do as a attempt to

validate or understand system

CS48702-67

4 - Final systems Requirements Validation

- Review of requirements (customer, users, other stakeholders)

- are requirements clear -is source of the requirement clear (e.g, user,

standard, some document)–- Traceable to a system model?

–- Traceable to overall system/product

- is requirement bounded? - is testable (what tests used? - Some sort of sign-off? (may not be sign off

to develop just that requirement(s) are complete.

CS48702-68

5 - Requirements Management

- Activities that help identify, control and track requirements.

– Identify each requirement needing tracking <requirement><require#>

– track each requirement and show how different requirements relate to eachother

– which release assigned to

– what requirements are dependent on others?

– how does eliminate 1 requirement affect others?

Documents

CS48702-1 Illinois Institute of Technology CS 487 Software Engineering David Lash © Illinois Institute of Technology 1997