Enterprise Analysis and Design Method

lumpysteerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

82 εμφανίσεις

Florida International University

December 2, 2013

1

Chapter 6

Enterprise Analysis and Design Method

Ronald E. Giachetti, Ph.D.

Associate Professor


Industrial and Systems Engineering, FIU

Overview


Present enterprise architecture & mapping
to system life
-
cycle


System life
-
cycle


Method tools


Method techniques


Ronald E. Giachetti

December 2, 2013






Slide
2

Method Tools


Project Charter template


Business Case template


Budget spreadsheet


Requirements template


Estimation spreadsheet



Ronald E. Giachetti

December 2, 2013






Slide
11

Too much planning?

No planning?

Work Breakdown Structure (WBS)


The Work Breakdown Structure (WBS) is a tool that defines a
project and groups the project’s discrete work elements in a way that
helps organize and define the total work scope of the project.


WBS also provides the necessary framework for detailed cost
estimating and control along with providing guidance for schedule
development and control.


Ronald E. Giachetti

December 2, 2013






Slide
14

Maintenance
Management
System
Project Initiation
Project Planning
Analysis of
Problems and
Requirements
Generate and
Evaluate
Alternatives
Design System
Construct
System
Implmentation
Interview
management
and collect data
Create project
charter
Data collection
Problem analysis
Requirements
analysis
Model process
Model
information
Create
requirements
document
Research
alternatives
Identify criteria
Perform
feasibility
analysis
Document
selection
Design system
architecture
Design process
Design
information view
(
database
)
Check and
ensure system
integration
Acquire
software
Acquire
hardware
Configure
system
Construct
database
Construct
interfaces
Test system
Train users
Data conversion
Build network
and setup
hardware
Install and setup
software
Provide user
support
Create work
breakdown
structure
Create schedule
Create budget
Create plans
Requirements
management
Project
management

Ronald E. Giachetti

December 2, 2013






Slide
15

WBS for Home Construction



Level 1

Level 3


Project Management
--

WBS

Each task should


have a well
-
defined
start and end


By easy to track
(schedule & budget)


Single individual is
responsible


Have budget allocated
to it


Task duration should be
proportional to overall
project



Ronald E. Giachetti

December 2, 2013






Slide
16

Work Breakdown Schedule (WBS)

Estimation


Ronald E. Giachetti

December 2, 2013






Slide
17

For each Work Breakdown Activity



Assign project team role to activity



Estimate person
-
hours



work measurement



regression analysis



expert



Determine start date and end date



Estimate budget for activity (Rate *
Hrs)

Estimation Approaches


Expert Opinion


Top
-
down


use previous similar projects
to estimate


Parametric


a percentage of size or other
project characteristic


Three
-
point


most likely, optimistic,
pessimistic


Ronald E. Giachetti

December 2, 2013






Slide
18

Responsibility Assignment Matrix


Assign staff to WBS elements.


Ronald E. Giachetti

December 2, 2013






Slide
19

Person
Responsible
Job Title
Interview
management
and collect
data
create project
charter
create
WBS
create
schedule
create
budget
create
plans
requirements
management
project
management
data
collection
problem
analysis
Fraser
Systems
analyst
X
X
X
X
Pegram
Project
manager
X
X
X
X
X
Grilli
Project
manager
assistant
X
Kim
Systems
analyst
X
X
Project Planning
Project Initiation
Analysis of problems and
requirements
Responsibility Assignment Matrix


Can show estimated person
-
hours and determine
workload of each staff member.


Ronald E. Giachetti

December 2, 2013






Slide
20

Person
Responsible
Job Title
Interview
management
and collect
data
create project
charter
create
WBS
create
schedule
create
budget
create
plans
requirements
management
project
management
data
collection
problem
analysis
Fraser
Systems
analyst
10
20
8
8
Pegram
Project
manager
12
5
4
4
150
Grilli
Project
manager
assistant
8
Kim
Systems
analyst
16
16
Project Initiation
Project Planning
Analysis of problems and
Cross Life
-
cycle activities


Project Management


Requirements Management


Quality Assurance


Configuration Management & Control


Risk Management


Ronald E. Giachetti

December 2, 2013






Slide
21

Requirements Management


Requirements Management is the process of managing
change to the requirements.


It is during the analysis phase that requirements are
elicited, specified, and documented.


The project team establishes and maintains a plan for
performing requirements management. Included in
requirements

management is a plan for ensuring bi
-
directional requirements
traceability.

Additionally, requirements are a configuration item to be tracked
and controlled as part of the configuration management process.


Ronald E. Giachetti

December 2, 2013






Slide
22

Risk Management


The systematic process of identifying,
analyzing, and responding to project risk.


Risk is the possibility of suffering
diminished project success (scope, cost,
schedule)


Risk management is proactive


identify
risk and take action to prevent or mitigate


Ronald E. Giachetti

December 2, 2013






Slide
23



December 2, 2013




Risk Probability


Often from Expert Opinion without value of
historical data.


Cannot assign valid probabilities with any reliability.


Ordinal Scale


Very
unlikely

Unlikely

Possible

Highly
likely

Almost
certain

0.1

0.3

0.5

0.7

0.9

0.05

0.1

0.2

0.4

0.8



December 2, 2013




Risk Impact
(ordinal scale)

Project
Objective

Very Low
(0.5)

Low (0.1)

Moderate
(0.2)

High (0.4)

Very High
(0.8)

Costs

Insignificant
cost
increase

<5% cost
increase

5
-
10% cost
increase

10
-
20% cost
increase

> 20% cost
increase

Schedule

Insignificant
schedule
slippage

Schedule
slippage <
5%

Overall
project
slippage 5
-
10%

Overall project
slippage 10
-
20%

Overall
project
slippage >
20%

Scope

Scope
decrease
barely
noticeable

Minor areas
of scope
are
affected

Major areas
of scope are
affected

Scope
reduction
unacceptable
to client

Project end
item is
effectively
useless

Quality

Quality
degradatio
n barely
noticeable

Only very
demanding
applications
are
affected

Quality
reduction
requires
client
approval

Quality
reduction
unacceptable
to client

Project end
item is
effectively
unusable

Which is more risky with numbers?


Ronald E. Giachetti

December 2, 2013






Slide
26

Project A

Project B

Technology depends on availability
of rare earth elements that are
only sourced from China and supply
is uncertain.


The likelihood of supply disruptions
is low
(0.1)
, but if it occurs
production of the technology could
stop
(expected budget impact of
$1M).

Application software for new
technology is being written by
government software engineers.
Compared to those in industry, they
are poorly paid, so risk of turn
-
over
is high (especially if economy
improves), and this would disrupt
ability to meet deadlines.


The likelihood of a single software
engineer leaving is high
(0.8)
, but
delays on meeting deadline are
minimum
(expected schedule impact
of 1 week)
.



December 2, 2013




Probability


Impact Matrix

Impact of risk event on objective
(e.g. cost, schedule, or scope)
0.05
0.1
0.2
0.4
0.8
Probability
0.9
0.05
0.09
0.18
0.36
0.72
of
0.7
0.04
0.07
0.14
0.28
0.56
Risk Event
0.5
0.03
0.05
0.10
0.20
0.40
0.3
0.02
0.03
0.06
0.12
0.24
0.1
0.01
0.01
0.02
0.04
0.08
Low
Risk/Impact

High
Risk/Impact

CAUTION: do not put too much stock in
actual values.



December 2, 2013




Sample Probability/Impact Matrix

Taken from IT Project Mgmt, 3
rd

edition, Course
Technology Publishing

Understand Risk


Ronald E. Giachetti

December 2, 2013






Slide
29

Will risky new technology mature before
Milestone B? Is there a risk mitigation plan?

Probability of risk event

consequence

Showing full probability distribution provides complete
information of expected value and variation that can enable
better decision
-
making with respect to risk


Ronald E. Giachetti

December 2, 2013






Slide
30

Identify potential scenarios and associated risks



December 2, 2013







Day 2 Module 8 Slide
31

Strategies


Avoidance



change project plan to eliminate risk or to
protect project objectives from risk impact.


Transference



shift the consequence of the risk to a
third party with ownership of the response. (usually for
financial risks, use of insurance, warranties, and so
forth).


Mitigation



reduce the probability and/or consequence
of the risk to an acceptable threshold. Earlier the better.
Mitigation costs should be appropriate.


Acceptance



do not change project plan. Develop a
contingency plan if risk event should occur.



August 18, 2006






slide
32

Quality Assurance


Quality Assurance (QA) is a planned and
systematic approach necessary to
provide adequate confidence that an item
or product conforms to established
standards, procedures and policies



QA is an umbrella activity that is applied at each step in
the process of building the system


QA is a CMMI Level 2 Process


Don’t equate QA with Test (although testing is important)




August 18, 2006






slide
33

QA Feedback

ERP Implementation Process

QA

QA

Objective
Feedback via

QA
Criteria

Should be part of a
continuous
improvement plan

(i)
Evaluations

(ii)
Noncompliance
reports

(iii)
Corrective
actions




August 18, 2006






slide
34

Famous Software errors


ATT Long Distance phone lines down for 9 hours in
1990.

(caused by a software “upgrade”)


Patriot missile failure to track an incoming SCUD missile
in the 1991 Gulf War. 28 soldiers killed.

(an arithmetic error accumulated over time)


Gemini V orbiter missed its landing site by 100 miles.

(Failure to take into account Earth’s motion around
the sun)


Mariner I Venus probe veered off course after lift
-
off and
had to be destroyed.


(A period in the code should have been a comma).




August 18, 2006






slide
35

Types of Tests


Unit Test
: Test each individual component to ensure it
is as defect free as possible


Integration test
: Occurs between unit and system
testing to test functionally grouped components

Interface Test
: Test the interfaces in the end
-
to
-
end business
process

Security Test
: Test users’ security access provides proper
authority for their roles in the business processes


User Acceptance test
: Is an independent test
performed by the end user prior to accepting the
delivered system


users sign off on test results


System Test
: Test the system as a whole


Regression Test
: Test that changes do not adversely
impact already tested components

Configuration Management & Control


The purpose of
Software Configuration Management

is to establish and maintain the integrity of the products
of the software project? throughout the project's software
life cycle.



Software Configuration Management involves identifying
the configuration of the software (i.e., selected software
works products and their descriptions) at given points in
time, systematically controlling changes to the
configuration, and maintaining the integrity and
traceability of the configuration throughout the software
lifecycle.



Standards (approved by ANSI)

IEEE 828: Software Configuration Management Plans

IEEE 1042: Guide to Software Configuration Management


Ronald E. Giachetti

December 2, 2013






Slide
36



December 2, 2013







Day 3 Module 2 Slide
37

Configuration Items


A
configuration item (CI)

is any part of the development
and/or deliverable system which needs to be independently
identified, stored, tested, reviewed, used, changed,
delivered and/or maintained


CIs can differ widely in complexity and may contain other
CIs in a hierarchy


Includes code, modules, and documentation

all type of code files

drivers for tests

analysis or design documents

user or developer manuals

system configurations (e.g. version of compiler used)



December 2, 2013







Day 3 Module 2 Slide
38

Finding Configuration Items


Large projects typically produce thousands of entities
(files, documents, data ...) which must be uniquely
identified


Any entity managed in the software engineering process
can potentially be brought under configuration
management control


But not every entity needs to be under configuration
management control all the time


Two Issues:

What
: Selection of Configuration Items to be under configuration
control

When
: When do you start to place entities under configuration
control?



December 2, 2013







Day 3 Module 2 Slide
39

Finding Configuration Items (continued)


Some items must be maintained for the lifetime of the
software


An entity naming scheme should be defined so that
related documents have related names


Selecting the right configuration items is a skill that takes
practice

Very similar to object modeling in object
-
oriented design

Use techniques similar to object modeling for finding CIs!


Find the CIs


Find relationships between CIs




December 2, 2013







Day 3 Module 2 Slide
40

Which of these Entities should be Configuration Items?


Problem Statement


Software Project
Management Plan (SPMP)


Requirements Analysis
Document (RAD)


System Design Document
(SDD)


Project Agreement


Object Design Document
(ODD)


Dynamic model


Object model


Functional model


Unit tests


Integration test strategy




Source code


API Specification


Input data and data bases


Test plan


Test data


Support software that is part
of the final system


Support software that is not
part of the product


User manual


Administrator manual



December 2, 2013







Day 3 Module 2 Slide
41

Possible Selection of Configuration Items


Problem Statement


Software Project
Management Plan (SPMP)


Requirements Analysis
Document (RAD)


System Design Document
(SDD)


Project Agreement


Dynamic Model


Object model


Functional Model


Unit tests


Integration test strategy




Source code


API Specification


Input data and data bases


Test plan


Test data


Support software (part of the
product)


Support software (not part of
the product)


User manual


Administrator manual

Once the Configuration Items are selected, they are usually organized in a tree



December 2, 2013







Day 3 Module 2 Slide
42

Baseline


A specification or product that has been formally
reviewed and agreed upon, that serves as the
basis for further development, and that can be
changed only through formal change control
procedures


Examples:

Baseline A
: All the APIs have completely been
defined; the bodies of the methods are empty

Baseline B
: All data access methods are implemented
and tested

Baseline C
: The GUI is implemented




December 2, 2013







Day 3 Module 2 Slide
43

Change Management


Change management is the handling of change requests

A change request leads to the creation of a new release


General change process

The change is requested (this can be done by anyone including users
and developers)

The change request is assessed against project goals

Following the assessment, the change is accepted or rejected

If it is accepted, the change is assigned to a developer and implemented

The implemented change is audited


The complexity of the change management process varies with the project.
Small projects can perform change requests informally and fast while
complex projects require detailed change request forms and the official
approval by one more managers

Summary


This chapter establishes the overall
architecture and methodology to do an
enterprise project


Understand life
-
cycle phases, their inputs,
outputs, and activities


Cross life
-
cycle activities


Project initiation and project charter to
start project