1 2 Analysis Modeling Review Chapters 12 3 Analysis Modeling - - PowerPoint PPT Presentation

1

2

3

Analysis Modeling Review

Chapters 12

4

Analysis Modeling

• “A Picture is worth a 1000 Words”!!!
• Helps better understand the requirements

– Data – Function and – Behavior

• Analysis modeling helps validate the

requirements

5

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

6

Data Dictionary

• Repository that contains description of all data
• bjects 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

7

Data dictionary Example

LID=userID +Password Data the staff enter to use the system LID LoginID See table X External entity who can request staff to add/drop courses None Student Record Description Where Used Alias Data Name

8

Data dictionary Example

Character, 20 Characters. In the main add/drop menu None Student Name Integer, 9 digits In the main add/drop menu None Student ID Description Where Used Alias Data Name Table X: Student Record

9

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

10

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

11

ERD

• Primary purpose is to represent data objects

and their relationships

Student Course Register Vendor Item Provides

• An item is Provided by One or More Vendors, and

a Vendor may provide multiple Items

12

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 Registratio n System Info Request View Info Staff User Info Request View Info Student Registration System DFD- Level 0

13

DFD – Level 1

Instructo r User Check Instruct

• r ID

Instructo r ID Valid Passwo rd Read Instructor ID Process Instruct

• r

Menu Invalided Password Invalid Password Message Process Class Roaster Request Class Roaster Student Info Class Roaster Printout Valid Course ID Course Info Instructor Course Student

14

Process Specification PSPEC

• Used to describe all flow model processes

that appear in DFD (final level)

• PDL = Text like language

15

E2

Buffer STD Example

(E1,C1):A1

EMPTY EMPTY EMPTY FULL FULL FULL PARTIAL PARTIAL PARTIAL

(E1):A2 (E2):A3 (E2,C2):A3 E1: PUT(item) E2: GET(item) C1: #ofItems=MAX C2: #ofItems=0 E1

16

Managing Software Projects

Chapters 3,5 & 7

17

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?

18

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 ?

19

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

20

Good Team Leader

• Motivation
• Organization – the ability to model existing

processes or invent new ones

• Ideas or innovation
• People Skills.
• Listen
• Understand his team

21

The Software Team

• How should a team be organized? Depends
• n:

– The number of people – Management style of the organization – Team members skills – How difficult the project is.

22

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

23

Three Generic team organizations

• Controlled Centralized (CC)

– Top-level problem solving and team leader – Vertical Communication

24

How to Decide team structure to use?

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

CC DD CD Simple Complex

25

How to Decide team structure to use?

• Things to Consider:
• 2. Size of the Project

CC DD CD Large Small

26

How to Decide team structure to use?

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

CC DD CD Short Long

27

How to Decide team structure to use?

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

CC DD CD High Low

28

How to Decide team structure to use?

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

CC DD CD High Low

29

How to Decide team structure to use?

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

CC DD CD Less Time More Time

30

How to Decide team structure to use?

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

CC DD CD Low High

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

32

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

33

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

34

The Process

• Select the appropriate Process Model based
• n your understanding of the project.
• Many tasks are the same for the all process

models. What are these tasks?

35

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

36

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…

37

Activity

• Chunk of work:

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

38

Project Parameters

• Five constraints that must remain in

balance:

– Scope – Quality – Cost – Time – Resources

39

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.

40

Project Parameters

• Five constraints that must remain in

balance:

– Scope – Quality – Cost – Time – Resources

41

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

42

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.

43

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

44

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

45

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

46

The Project Plan

• Estimates: Determine Cost, Time, and

Schedule.

• When estimating Consider:

– Number of people – Skills – Tools – Reusable SW Components

47

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

• f historical data

More on estimates techniques when we talk about SW Metrics.

48

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

49

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

50

Design Concept and Principles

Chapter 13

51

What is Design

• Design is a meaningful representation of

something to be built.

• SW requirements are the input for the design

– SW requirement specs are translated intto design specs

• Design Specification will be used to construct

“build” the system.

• Designs for SW systems are like Blueprints for

houses.

– Its used to avoid confusion, errors, risks before you start building

52

Design Models

• Data Design

– Transform the information domain (created in analysis) into Data structures.

• Architectural Design:

– Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal

• Interfaces Design - How the system interfaces:

– With itself (procedure calls) – With other systems – With users (Screens)

• Components Design

– Structural elements into procedural description

53

Mapping the Analysis Model into a Software Model

Go To Pressman Page 337 for Figure

54

Your Project

• Your Specification requirement document

will feed into the design document.

– Specification should till “What”. – Design will translate it to “How”. – Your Design document will have to completely comply to what you specified in the requirement analysis phase.

55

Good Design Characteristics

• Must implement the requirements

– Explicit and Implicit

• Must be readable, understandable guide for those

who will implement, test and supports it.

• The design should provide a complete picture of

the SW:

– Data – Functional and – Behavioral domains shall be addressed

56

Good design Guidelines

• 1. A design should exhibit an architectural

structure.

– This structure should be created from recognizable design patterns, – Good design characteristics

• high cohesion,
• low coupling

– Can be implemented in an evolutionary fashion.

57

Good design Guidelines

2. A design should be modular.

– the SW should be organized into functions and sub functions.

3. A design should contain distinct representations

• f

– data, – architecture, – interfaces and – components (modules).

58

Good design Guidelines

• 4. A design should lead to data structures that

are appropriate for the objects to be implemented.

They should use recognizable design patterns.

• Examples linked list, stack where you pop and

push items

• 5. High cohesion.

a module should do one thing

59

Good design Guidelines

6. Low coupling

• reduce the connections between modules and
• simple interfaces to external systems.

7. A design process should be repeatable and driven by the information obtained during SW requirements analysis.

60

Design Concepts

• How should we partition the SW into

individual components?

• How is function or data structure detail

separated from a conceptual representation

• f the software?
• How do we measure Quality? What are the

qualities of a good design?

61

Design Concepts

• Abstraction - Each step of the SW process

refines the solution and removes levels of abstraction:

– High level – user and environment – Low levels – code

62

Design Concepts

• Abstraction – build a house Example:

– Our house will have 4 bedrooms, 3 baths, a family room, living room, dining room and an eat-in kitchen. It should cost < $500,000 to build – Our house will have 2 floors, and follow the blueprint designed by the architect – The contractors will build the house designed. – Inspectors will make sure it is safe. – The bank will ensure you built the house they loaned you the money to build. – 6 months after they promised the house, you will move in.

Each step moves us closer to living in the house.

Each step removes a layer of abstraction in the process, and moves closer to the finished product.

63

Design Concepts

• Refinement

– Step-wise refinement is a top-down design strategy. – Elaboration. – Abstraction and refinement go hand-and- hand. – Through refinement, the designer reveals low-level details as design progresses. This process removes levels of abstraction.

64

Design Concepts

• Modularity

– Monolithic SW is not easy to understand, develop or maintain. – Software is divided into separately named and addressable components, called modules. – modules, working together, satisfy the SW requirements – Balance # of models to cost of integration

• More models cost more

65

Software Architecture

• Describes:

– the structure of a program:

• how the modules interact

– the structure of the data.

66

Program Structure

• Organization of the modules within a

program

– Does not show sequence of processes – It shows how modules call each other

• Hierarchy of Control
• TreeLike Notation

– Represents hierarchical control for call and return architecture (example Pressman Page 347)

67

Program Structure

• Terms (Go to page 347 for figure)
• Depth: shows the number of levels of control
• Width: shows overall span of control
• Fan-in: how many modules directly control a

given module.

• Fan-out: a measure of the number of modules that

are directly controlled by a module.

• Super-Ordinate: the name for the module that

controls other modules. – Sub-Ordinate: the name of the module that is controlled by another module.

68

Structured Partitioning

• The program structure can be partitioned:

– Horizontal partitioning: Define a separate branch of the hierarchy for each major function of the program.

• input, processing and output.

– Vertical partitioning (“Worker Model”):

• decision making modules are high in the hierarchy (control
• nly) and
• the lower modules do the work.

69

Horizontal partitioning

• Advantages:

– SW is easy to

• Test, maintain and

enhance.

– Propagation of fewer side effects.

• Disadvantages:

– More data passed across module interfaces.

70

Vertical partitioning

• Advantages:

– Changes are usually made to worker

• modules. The
• verall control of the

system is less likely to change. – This approach is more maintainable.

• Disadvantages:

– If a change is made to a control modules, there is a higher probability of propagating side effects.

71

Data structure

• It is the representation of a logical

relationship between data elements.

• Classic data structures:

– Scalar item: simplest of all data items.

Examples: an integer, real number, character or a floating point.

– n-dimensional space:

Array is a two-dimensional space. Linked list, stack

72

Software procedure

• Focuses on the processing detail of

each module individually.

• Unlike program structure which disregards

processing details of each module

• Procedure must provide precise specs of

processing

73

Information Hiding

• Modules should be designed so that their

procedure and data are inaccessible to other modules.

– Communicate with other modules through interfaces – This helps greatly in testing, and debugging

• You know which module changes which data.

74

How to design a good module ?

• A good module has functional

independence.

• It is achieved by developing modules with

"single-minded" function

• Functional Independence is measured

by looking at the cohesion and coupling

• f the modules.

75

Cohesion

• Each module should have a central theme or

purpose.

– Should be able to describe a cohesive module using a sentence with one subject and one verb

• High cohesion is good. Low cohesion is to be

avoided.

76

Cohesion Types

• Coincidentally cohesive (worst):

– module performs tasks that are related loosely or maybe not at all. – Example: divide the monolithic program into modules using a ruler

• Logically Cohesive (low):

– Logically related tasks in one module – Example: A module that does all errors processing tasks.

• Temporal cohesion (low):

– tasks of a module are related because they must be executed in the same time span. – Example: Clean up tasks at the end of processing

77

Cohesion Types

• Communicational cohesion (moderate):

– all processing elements concentrate on one area

• f a data structure.

– Update the record in the database and add to audit trial.

• High cohesion:

– module performs one distinct task. – Example: a Procedure that computes the shipping cost of an order.

78

Coupling

• Refers to the degree of

interconnectedness between modules

• Minimize coupling to reduce the ripple

effect when changes are made.

• The goal is to reduce connection paths

between modules.

• High coupling limits reuse.
• lowest possible coupling

79

Coupling Types

• Data coupling (low):

– Only simple data items are passed

• Stamp coupling (low):

– A structure is passed, even though only a portion of the data items are needed.

• Control coupling (moderate):

– a "control flag", variable that controls decisions in a subordinate or super-ordinate module is passed.

• External coupling (high):

– modules are tied to an environment. I/O ties modules to a specific device, formats and communication protocols.

80

Coupling

• Common coupling (high)

– modules reference a global data area.

• Content coupling (highest):

– when one module makes use of data or control information maintained within the boundary of another module.

• This should always be avoided

81

Steps to obtain a good Modular Design:

• Evaluate the first iteration of the program structure to

– reduce coupling and – improve cohesion.

• Attempt to minimize structures with high fan-out;

– work for fan-in as depth increases.

• Do not allow modules to affect modules that are not

subordinate to it.

• Review interfaces and ensure they are simple and

consistent with the function of the module.

82

Steps to obtain a good modular design:

• Define modules whose functions are

predictable.

– The same external data should always produce the same results.

• Work for controlled entry of modules.

– Do not branch to the middle of another module!

83

Requirement Specification

• Updated Outline

84

Requirement Specification Outline

• 1. Introduction

Title of the Project, Team Members, Team Leader, and an Introductory Paragraph describing the project, and the benefit for the customer 1.1 Goals and Objectives 1.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 1.4 Functional Requirements “Text”

85

Requirement Specification Outline

2. Data Model Description

This section describes the information domain 2.1 data objects, description, and Relationships

Use Data dictionary (table like see book page 330)

2.2 ERD

3. 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!

86

Requirement Specification Outline

• 4. Behavioral Model and description

4.1 Describe the behavior of the SW

4.1.1 Events 4.1.2 States

4.2 STD

Very simple stay at level 1 system states

• 5. Constraints

Special issues, OS compatibility, size required to run your SW, etc.

• 6. Validation Criteria

Types of tests you plan to run.

87

Homework #1

• Due Date:Jun-17-2002 6:25 PM.
• Q4: 25 Points)

– Specify a Software System that Controls a Microwave Oven using STD. The oven has the following buttons:

• START – start cooking
• POWER – ON/OFF
• CANCEL – Cancel Cooking
• TIME-1 – set cooking time to 1 minute
• TIME-2 – set cooking time to 2 minutes
• LIGHT – ON/OFF

– The oven has a DOOR which could be opened at any time.

88

Homework #1

• Due Date:Jun-17-2002 6:25 PM.
• Q5: 25 Points)
• Construct ER diagrams for University Registration System. .

For each entity set, the ER diagram should indicate its name and major attributes (using Data Object Tables). For each relationship set, indicate its name cardinality, modality and major attributes (if any).

– Each student is assigned a unique identification number. The application should store the name, address and phone number for each student. Students take classes, but it is possible that a student is not registered for a class yet. Classes are identified by a unique class number. The university also stores the name and credits for each class. Students can take many classes. Classes are taken by many students.