1

Review

2

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

3

Software Requirement Analysis

• Analyze the Information Domain, the Function, Performance, Behavior and Interface Requirements.

• Software Requirements Specification is Produced.

4

Software Requirements Specification

• Should provide information to the SW Designer about:– System,– Data,– Architecture,– Interface and – Components of the System.

5

SW Requirement Analysis

• Bridges System Engineering (big picture) and Design (How to implement)

DesignSystem Eng

Requirement

Analysis

6

Steps of the Req. Eng. Analysis

• Requirement Analysis and Negotiation• Specification Modeling• Requirement Validation “Review”• Requirement Management

• Requirement Elicitation “Gathering”

7

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.

8

Requirements Validation or Review

Once reviewed it becomes a CONTRACTfor Software development

DesignTo …

9

Analysis Modeling

Chapters 12

10

Analysis Modeling• “A Picture is worth a 1000 Words”!!!• This type of modeling is for Analysis• Helps better understand the requirements

– Data– Function and– Behavior

• Analysis modeling helps validate the requirements

11

Analysis Modeling

• Different diagrams:– Data Modeling define :

• Data objects• Attributes and relationships

– Functional Modeling• indicate how data is

transformed

– Behavioral Modeling• Depicts the impact of event

ERD, and Data Object Diagrams

DFD

STD

12

Modeling Elements

Data dictionaryERDDFD

STD

Control Specification

Process Specification

Dat

a Sp

ecif

icat

ion

13

Data Modeling

• What are the primary data objects ?• What is the composition of each?• What attributes describe the object?• What are the relationships between data

objects?

14

Data Dictionary

• Repository that contains description of all data objects consumed or produced by the software

• An organized approach for the characteristics of each data object and control item.

• Lists all data used by the system– Name– Alias– Where-Used / how used– Content description– Other information

15

Data dictionary Example

LID=userID+Password

Data the staff enter to use the system

LIDLoginID

See table XExternal entity who can request staff to add/drop courses

NoneStudent Record

DescriptionWhere Used

AliasData Name

16

Data dictionary Example

Character, 20 Characters.

In the main add/drop menu

NoneStudent Name

Integer, 9 digits

In the main add/drop menu

NoneStudent ID

DescriptionWhere Used

AliasData Name

Table X: Student Record

17

ERD

• Defines all data objects, their attributes and relationships.

– Data object – Instructor– Attributes – Name, SSN, Address, etc.– Relationships to other objects – instructor

teaches a course

18

ERD• Entity – anything in the problem that has physical

characteristics• Relationship – A connection between two objects• Cardinality – The # of occurrences that of one entity can

be related to another– One-to-One– One-to-many– Many-to-many

• Modality – the minimum requirements of the relation– 0 – Optional– 1 - Mandatory

19

Cardinality / Modality Example

Modality: Optional Student does not require

an Course

Student Courseregister

Cardinality: one student registers for

course(s)

Modality: Mandatory implies in order to have a Course we must have a

student

Cardinality: there may be many courses

Stud

entID

Stud

entN

ame

Data Object Table

20

Cardinality / Modality Example

Customer Orderhas

Cardinality: one customer has order(s)

Modality: Mandatory an Order must have a

Customer

Modality: Optional Customer does not require

an Order

Cardinality: Multiple

Orders for a Customer

21

ERD

• Primary purpose is to represent data objects and their relationships

Student CourseRegister

Vendor ItemProvides

• An item is Provided by One or More Vendors, and a Vendor may provide multiple Items

22

DFD• Input, Process (Transform) data, Produce Output• Information flow and transforms that apply to data as it moves from Input

to Output.• All Arrows / Bubbles should be labeled with meaningful names

External Entity

Process or

Transform

Data Item

Data store Input

Data store Output

Data Store

23

DFD• May be used to represent a System – Level 0

– One Bubble for the system– All Inputs and Outputs To/From the system

Instructor User

University Registration System

Info Request

View Info

Staff User

Info Request

View Info

Student Registration System DFD- Level 0

24

DFD – Level 1

Instructor User

Check Instructor ID

Instructor ID

Valid Passwo

rd

Rea

d In

stru

ctor

ID

Process Instruct

or Menu

Invalided Password

Invalid Password Message

Process Class

RoasterRequest Class

Roaster

Student

Stud

ent I

nfo

Class Roaster Printout

Valid Course

ID

Cours

e Info

Instructor

Course Course

25

State Transition Diagrams

• How the system moves from state to state!• Behavior and not Structure• How the system reacts to external events• A event is an observable mode of behavior (i.e

One / Off, Open, Closed, busy, idle, etc.)• A transition is the mean by which the system

change states– It can be Guarded by a Condition– It may be associated with action(s)– Has a name

26

STD

(Put,noOFitems=MAX): print(”Moving to FULL”)

NOT-FULLNOTNOT--FULLFULL

FULLFULLFULL

27

E2

Buffer STD Example

(E1,

C1)

:A1

EMPTYEMPTYEMPTY

FULLFULLFULL

PARTIALPARTIALPARTIAL(E1):A2

(E2):A

3(E2,C2):A3E1: PUT(item)

E2: GET(item)

C1: #ofItems=MAX

C2: #ofItems=0 E1

28

Process Specification PSPEC

• Used to describe all flow model processes that appear in DFD (final level)

• PDL = Text like language

29

Managing Software Projects

Chapters 3,5 & 7

30

What is Project Management

• Planning, Monitoring, and Control of People, Process, and Events that occur as SW evolves form concept to product.

• 4Ps must be organized to perform SW work.

What do you thing the 4Ps are?

31

Project Manager Focus

• People – The Project team• Product – the Software that is to be built• Process – The Framework to follow • Project – How we mange Complexity

What is the most Important ?

32

People – who participate in the SW Process?

• Senior Mangers – define Business issues

• Project Mangers – who plan, motivate, organize and control the Practitioners.

• Practitioners – engineer the SW product

• Customers – Specify Requirements

• End-Users – use the SW

33

Good Team Leader

• Motivation• Organization – the ability to model existing

processes or invent new ones• Ideas or innovation• People Skills.• Listen• Understand his team

34

The Software Team

• How should a team be organized? Depends on:– The number of people– Management style of the organization– Team members skills– How difficult the project is.

35

Three Generic team organizations

1. Democratic Decentralized (DD)– No Leader– Task Coordinators be appointed for short duration– Group made decisions– Communication is Horizontal

2. Controlled Decentralized (CD)– Defined leader and secondary leader (subtasks)– Problem solving remains a group activity– Implementation is partitioned– Communication is Horizontal

36

Three Generic team organizations

• Controlled Centralized (CC)– Top-level problem solving and team leader– Vertical Communication

37

How to Decide team structure to use?

• Things to Consider:1. How Difficult is the problem

CC DDCD

Simple Complex

38

How to Decide team structure to use?

• Things to Consider:2. Size of the Project

CC DDCD

Large Small

39

How to Decide team structure to use?

• Things to Consider:3. Time team will stay together

CC DDCD

Short Long

40

How to Decide team structure to use?

• Things to Consider:4. The degree to which a problem can be modularized

CC DDCD

High Low

41

How to Decide team structure to use?

• Things to Consider:5. Quality and Reliability of SW to be built

CC DDCD

High Low

42

How to Decide team structure to use?

• Things to Consider:6. How Firm is the Due Date

CC DDCD

Less Time More Time

43

How to Decide team structure to use?

• Things to Consider:7. Communication Required for the Project

CC DDCD

Low High

44

Project Manager Focus

• People – The Project team • Product – the Software that is to be built• Process – The Framework to follow • Project – How we mange Complexity

45

The Product

• Before the project can be planned,– the product objectives – from a customer

perspective and – The scope must be defined –

• Boundaries• Data• Behavior

• Requirements help understand the product

46

Project Manager Focus

• People – The Project team • Product – the Software that is to be built• Process – The Framework to follow• Project – How we mange Complexity

47

The Process

• Select the appropriate Process Model based on your understanding of the project.

• Many tasks are the same for the all process models.

What are these tasks?

48

Project Manager Focus

• People – The Project team • Product – the Software that is to be built• Process – The Framework to follow • Project – How we Mange Complexity

49

What is the Project?

• A Sequence of Unique! Complex! And Connected! Activities having:– One Goal– Set Time– Within Budget and– According to Specifications

• Projects are resource limits : i.e #of People,$, etc…

50

Activity

• Chunk of work:– Their sequence is based on technical requirements– What input is needed before work can begin?– What output will be produced ?

51

Project Parameters

• Five constraints that must remain in balance:– Scope– Quality– Cost– Time– Resources

52

Project Parameters

• Scope

– A statement that defines the boundaries of the project, it describes:

• What will be done and • What will NOT be done

– The scope should be stated in terms of data, behavior.

– It should be stated in as easy and understandable manner.

53

Project Parameters

• Five constraints that must remain in balance:– Scope– Quality– Cost– Time– Resources

54

Quality

• There are two type of quality that are part of every project:

– Product Quality – describes the Deliverable from the project

– Process Quality – describes PjM Process

55

Project Parameters

• Five constraints that must remain in balance: Dynamic – Scope– Quality– Cost, the $ cost of doing the project– Time, the time frame, Hard, “drop Dead”,

etc.– Resources, assets : people, equipment, etc.

56

PjM life Cycle Phases?

1. Scope of the Project• State Problem / Opportunity • Establish Goal• Define Objective• List assumptions, risk and constraints

2. Develop the Project Plan• Identify Activities• Estimate Activity Duration• Determine resource Requirements• Construct the project network• Prepare the Project Proposal

57

PjM life Cycle Phase?

3. Launch the Project• Organize the Team(s)• Establish team operating rules• Schedule Work Packages• Document work Packages

4. Monitor / Control Project Progress• Establish progress reports• Change control tools• Monitor Progress against PLAN• Revise the plan as needed

5. Close out the Project• Customer Acceptance, install Deliverables,complete

documentation,audit, and FINAL PROJECT REPORT

58

The Project Plan

• Objectives is to provide a framework for:– Estimate of the resources, costs, and schedule of the

project• Plan Components:

– Introduction– Estimates– Risk Management– Project Schedule– Staffing– Tracking and Control

59

The Project Plan

• Estimates: Determine Cost, Time, and Schedule.

• When estimating Consider:– Number of people– Skills– Tools– Reusable SW Components

60

Estimation Approaches

• Decomposition Techniques– Decompose the problem into smaller pieces and

estimate each:• LOC• Function Points

– Historical Data– Quality of estimate is dependent on how well the

problem is understood and decomposed and the quality of historical data

More on estimates techniques when we talk about SW Metrics.

61

Project Scheduling

• Begin with a set of tasks, and for each task determine:– Effort, Duration, Start Date, Input, and Owner

• Build Project Network “Activity network”– It shows how the tasks are related to one another– It shows which tasks must be completed for another

task to start– It shows which tasks can be worked on in Parallel

• Assign resources and Level the project– Level the work to teams

• Track the Project

62

Project Tracking

• Generate Time Line Chart– Can be for the entire project– Separate chart for separate project functions

Go To Pressman Page 183 for example

– Critical Path,• The longest path,• It derives the completion date• If it slips the whole project slips

– Track against the Schedule

63

Your ProjectTeam Concepts

Pressman: Chapter 3, Section 3.2

64

Goals of the group project

• Familiarize students with the major phases of the software life cycle.

• It is also designed to help students learn to work as a part of a software development team.

• Each team will develop a software product proceeding through the software life cycle from problem statement to testing and installation.

65

Team Organization

• The teams will consist of 3-4 members.• The entire team is responsible for producing the

"deliverables" which consist of the following items:– Requirements/specification document - 30%– Design document - 25%– Code, test plans - 25%– Final product demonstration and presentation - 20%

66

Team Organization

• The objective of team work is to achieve a goal with a fair division of labor.

• Team organization promotes the division and delegation of the various tasks to achieve the goal.

• Try to us a democratic organization

67

Team Organization• Team Leader to be chosen who is responsible for:

– defining and setting goals, – organizing the group, – delegating responsibilities,– monitoring progress, as well as – performing technical tasks.

• The other team members are in charge of separate aspects of system development for each phase of the life cycle.

68

Requirement Specification Check List

• Understand the objects the system will manipulate, the services (Functions), the constraints, and timing.

• Re-Interview your client as needed– Bring Questions to Class– E-Mail Questions– Use Office Hours (can call during Office hors)

• Remember the Specification requirement focuses on the “what” and not the “how”

• For Diagrams use notations presented in class or in the text Book.

69

Requirement Specification Outline

1. IntroductionTitle of the Project, Team Members, Team

Leader, and an Introductory Paragraph describing the project, and the benefit for the customer

1.1 Goals and Objectives1.2 Statement of the Scope

Describe the SW presented, Major Inputs, Processing functionality and outputs. Describe what you can do during the course time.

1.3 Major Constraints

70

Requirement Specification Outline

2. Data Model DescriptionThis section describes the information domain2.1 data objects, description, and Relationships

Use Data dictionary (table like see book page 330)

2.2 ERD3. Functional Model and description

3.1 A description of each major software function, plus data flow:

– DFD – Level 0– DFD – Level 1

3.1.1 Functions description– Describe each PROCESS in the DFD – level 1 – PSPEC for each function

3.1.2 Performance issues 3.2 Software Interface Description – you can provide

screens!

71

Requirement Specification Outline

4. Behavioral Model and description4.1 Describe the behavior of the SW

4.1.1 Events4.1.2 States

4.2 STDVery simple stay at level 1 system states

5. ConstraintsSpecial issues, OS compatibility, size required to

run your SW, etc.

6. Validation Criteria Types of tests you plan to run.

72

Project Change Request #1

– Hana Software Development Corporation has decided to delay the deployment of the Deliverables features due to Time and Resources Constraints.

– Your organization has the option to either deliver this feature in the first release or delay for subsequence releases.

– Please state your approach in the specifications under constraints section.

73

Project Review

– Your company has been hired by HanaSoftware Development Corporation to develop a Feature and Deliverable Tracking Software.

– The new software will be used by the entire Software Development organization at HanaSoftware Development Corporation.

– The SW Development Organization is made of the following teams and each team has its own tasks:

74

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.

75

Project Review

• Managers– responsible for commitments and

estimates. Once an estimate query is send fromPjM 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.

76

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.

77

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

78

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

79

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.