CS847 Software Engineering

cs.iit.edu

CS847 Software Engineering

CS847 Software Engineering

Review

1


Generic definition of SW

Engineering

• SW Engineering is the:

– Analysis,

– Design,

– Construction,

– Verification and

– Management of Software.

2


Phases of SW Engineering

• Definition Phase, … What info. To be processed

– System engineering task

– SW Project Planning task

– Requirement Analysis task

• Development Phase, … How

– Design task

– Code task

– Testing task

• Support Phase,…focus on Change Management

3


Process Maturity

• Five point grading scheme that determines

compliance with CMM which defines key

activities required at each level.

4


Life Cycle Model

• It is a set of Activities required to:

– Define, Design, Implement, Test and Maintain

a Software product

• A SW Process model is chosen based on the

nature of the project.

5


Example of Life Cycle Models

• Waterfall Model, also knows as the “Linear

Sequential Model”

•Spiral Model

• Incremental Model

• Prototype Model

6


Waterfall Model

• Sequential approach that begins with the

system and progresses through;

– Analysis

– Design

– Coding

– Testing, and

– Support

7


Waterfall Model Activities

Requirements

Gathering

Analysis

Design

Code

Test

8


Evolutionary SW Process Models

• Often, all requirements of a SW product are

not understood.

– They maybe very complex or

– They may change over time

• The core requirements may be well defined

and understood.

9


Incremental Model

•It combines characteristics of the Waterfall

model and the iterative nature of the

Prototyping model.

•1 st build is usually the CORE product

• Each increment “Deliverable” may add a

new functionality.

• This is repeated until the product is

complete

• Go to page 35 for Figure

10


Incremental Model

Analysis

Design

Code

Test

Analysis

Design

Code

Test

Analysis

Design

Code

Test

Analysis

Design

Code

Test

• When staffing is not available by deadline.

11


Spiral Model

• Consist of 6 task regions (Page 37)

– Customer communication - the goal is to

establish good communication between

customer and developer.

– Planning - produce/adjust project plan.

– Risk analysis - assess management and

technical risks.

Engineering - build one or more representations

of the application.

– Construction and release - - to construct, test,

install and support the application

– Customer Evaluation – get customer feedback.

12


When to use the Spiral Model

• Very large projects

• When technical skills must be evaluated at

each step.

13


Requirement Analysis

14


System Eng. The Big Picture

• Before engineering a Software, the system

in which it resides must be understood:

– Analyzed, Designed, and Organized

• Roles of the System, HW,SW,People, and

DB must be identified.

• Requirements must be Analyzed as well.

System Engineering – System View

15


Software Requirement Analysis

• Analyze the Information Domain, the

Function, Performance, Behavior and

Interface Requirements.

Software Requirements Specification is

Produced.

16


Software Requirements Specification

• Should provide information to the SW

Designer about:

– System,

– Data,

– Architecture,

– Interface and

– Components of the System.

17


SW Requirement Analysis

• Bridges System Engineering (big picture)

and Design (How to implement)

System

Eng

Requirem

ent

Analysis

Design

18


Phases of the Req. Eng. Analysis

• Requirement Elicitation “Gathering”

• Requirement Analysis and Negotiation

• Specification Modeling

• Requirement Validation “Review”

• Requirement Management

19


Requirement Elicitation

• Ask the Customer what the system should

do.

– Objectives

– What is to be Accomplished

– How the system will satisfy the needs of the

business

– How the system will be used

20


Requirement Elicitation

• What could go Wrong

– Problems with the scope!

– Problems of understanding!

– Problems with Volatility

• SE must approach the SW requirements in

an organized manner.

21


Requirement Elicitation

Guidelines

• Structured Customer Interview: Context Free

Questions

– Identify stake holders

• Who is behind the request

• Who will use the system

• In there another source

• Who would benefit the most

– Understand the problem

• How would you describe a good output

• What problems will this solution address

• Can you show me (or describe) the environment

• Ask about desired Performance

22


Requirement Elicitation

Guidelines

• Structured Customer Interview: Context

Free Questions

– Effectiveness of the meeting

• Are you the right person to answer these questions

Are your answers “official”

• Are my questions relevant to the problem

• Am I asking to many questions

• Can anyone else provide additional information

• Should I be asking you anything else

23


Requirement Elicitation

Guidelines

• Facilitated Application Specification Technique

(FAST)

– This approach encourages the creation of a joint team

of customers and developers who work together to:

• identify the problem

• propose a solution.

• Negotiate different approaches

• Specify a preliminary set of requirements

“us” vs. “them”

24


Requirement Elicitation

Guidelines

• (FAST)

– A meeting is held attended by Customers and System

Engineers

– One or Two pages Product Request Document is

produced

– Each FAST attendee is asked to prepare the following

list:

• Objects

• Services

• Constraints (cost, size, etc.)

• Performance Criteria

– Review each list and create a combined

list for each topic.

25


• (FAST)

Requirement Elicitation

Guidelines

– Individual lists and then a list of validation

criteria is also produced

– A complete draft of the specification is created

from the mini specifications

– Issues list

26


Phases of the Req. Eng. Analysis

• Requirement Elicitation “Gathering”

• Requirement Analysis and Negotiation

• Specification Modeling

• Requirement Validation “Review”

• Requirement Management

27


Requirement Analysis and

Negotiation Phases

• Problem recognition

• Evaluation

• Modeling

• Specification

•Review

28


Requirement Analysis and

Negotiation Phases

• Evaluation phase: the analyst must:

– Define all extremely observable data objects

– Evaluate the flow and content and information

– Define all SW functions

– Understand behavior

– Establish system interfaces

– Discover additional constraints.

29


Requirement Analysis and

Negotiation Phases

• Modeling

– Functions Models (DFD)

• Each function has Input, Processing, and output

– Behavior Models (STD)

• events

– Data Models (ERD)

• Relationships among data objects

Data Dictionary

30


Phases of the Req. Eng. Analysis

• Requirement Elicitation “Gathering”

• Requirement Analysis and Negotiation

• Specification Modeling

• Requirement Validation “Review”

• Requirement Management

31


Specification

• Guidelines

– Understand the problem before you start

– Develop Prototypes to define human/machine

interaction

– Record the origin of the reason for every

requirement

– Rank requirements to accommodate for deadlines

changes

– No ambiguity

32


Specification

• Prototyping

– If requirements are not very well understood

– Users are not able to define the requiremetns

This is the point where a Prototype maybe

constructed

33


Specification

• Prototyping Types

– Closed-Ended – Throwaway

– Open-Ended - Evolutionary

34


Phases of the Req. Eng. Analysis

• Requirement Elicitation “Gathering”

• Requirement Analysis and Negotiation

• Specification Modeling

• Requirement Validation “Review”

• Requirement Management

35


Requirements Validation or

Review

• Things to consider

– Is it complete

– Any vague requirements

– Any too detailed requirements

– Are data, functions, and behavior fully described

– Spelling errors, references, numbering, etc.

36


Requirements Validation or

Review

Once reviewed it becomes a CONTRACT

for Software development

To …

Design

37


Phases of the Req. Eng. Analysis

• Requirement Elicitation “Gathering”

• Requirement Analysis and Negotiation

• Specification Modeling

• Requirement Validation “Review

• Requirement Management

38


Requirement Management

• The set of activity that help the project

team:

– Identify,

– Control, and

– Track changes to the requirements.

39


Requirement Management

• What could you do to help tracking

requirement changes

– Assign unique numbers

– Assign requirement type (functional, data,

output, interface,etc.)

– Each requirement could be tagged with a

history field to track changes.

– Use trace-ability tables page 262

40


Requirement Management

• Use trace-ability tables

– Features - how features relate to customer Source

– identifies the source of each requirement. Could

be a person, regulation or a document.

– Dependency - shows how requirements are

related to each other.

– Subsystem - organizes by subsystem.

– Interface - how requirements relate to internal and

external interfaces

41


Project Review

– Your company has been hired by Hana

Software Development Corporation to develop

a Feature and Deliverable Tracking Software.

– The new software will be used by the entire

Software Development organization at Hana

Software Development Corporation.

– The SW Development Organization is made of

the following teams and each team has its own

tasks:

42


Project Review

• The Project Management Team,

– this team is responsible for all aspects of the

Software project, they create the initial project

plan, track changes to the plan, allocate budget

for the each project, track the project at the

feature level, and cost per feature is

documented. They also keep track of all

deliverables for the project at hand. users in

this group should have full access to all view of

the system.

43


Project Review

• Managers

– responsible for commitments and

estimates. Once an estimate query is send from

PjM team to all mangers to estimate a feature,

Mangers should see if the feature is for their

team then they should estimate it and key in the

estimate numbers into the system. They should

enter the estimates in $ amounts. Note a feature

might have more than one deliverable which

could be owned by different managers.

44


Project Review

• System Engineer Team,

– responsible for entering features into the

system. they create and log feature description

documents which should be tied to a feature.

45


Project Review

All other teams (Development, Test, and

Integration),

– can view information about any feature that is

stored in the system (they should not be able

save any information into the system).

46


Project Review

The new system to have the following functionality:

–Maintain Feature information.

–Maintain Feature Status (Pending, Estimated and

Committed to a Project Number, Archived)

–Maintain Budget information. Total cost for all features,

total cost for a Project, and individual feature cost.

– Maintain Feature Estimates.

–Maintain Deliverables.

–Maintain Manger information (Name, Department, etc.)

–Maintain Logging information per team and per user.

– Should uniquely automatically identify each feature with a

working number based on the feature category.

– The automatically created work number could have

multiple deliverables the number of which is automatically

generated based on functionality.

47


Project Review

• The new system should include the following

Reporting/Displaying capabilities:

– For a given feature print all information.

– List features by Project

– List all features.

– List all deliverables and deliverable per feature.

– List all Committed features, and Pending Features, and

Archived Feature.

– Once a project plan is changed, print what has been added,

deleted, or updated from the system.

– List the cost for all features and total cost.

– For a given Status (Committed, Pending, Archived) the

system should display Feature information, estimate, and

deliverables in one view.

48

More magazines by this user
Similar magazines