Enterprise Analysis and Design Method

1
Chapter 6 Enterprise Analysis and Design Method
Ronald E. Giachetti, Ph.D. Associate Professor
Industrial and Systems Engineering, FIU
2
Overview

• Present enterprise architecture mapping to
  system life-cycle
• System life-cycle
• Method tools
• Method techniques

3
(No Transcript)
4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
Method Tools

• Project Charter template
• Business Case template
• Budget spreadsheet
• Requirements template
• Estimation spreadsheet

12
Too much planning?
13
No planning?
14
Work Breakdown Structure (WBS)

• The Work Breakdown Structure (WBS) is a tool that
  defines a project and groups the projects
  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.

15
WBS for Home Construction
? Level 1
? Level 2
Level 3 ?
16
Project Management -- WBS
Work Breakdown Schedule (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

17
Estimation

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

Slide 17
Ronald E. Giachetti December 17, 2013
18
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

19
Responsibility Assignment Matrix

• Assign staff to WBS elements.

20
Responsibility Assignment Matrix

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

21
Cross Life-cycle activities

• Project Management
• Requirements Management
• Quality Assurance
• Configuration Management Control
• Risk Management

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

23
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

24
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
25
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 lt5 cost increase 5-10 cost increase 10-20 cost increase gt 20 cost increase
Schedule Insignificant schedule slippage Schedule slippage lt 5 Overall project slippage 5-10 Overall project slippage 10-20 Overall project slippage gt 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 degradation barely noticeable Only very demanding applications are affected Quality reduction requires client approval Quality reduction unacceptable to client Project end item is effectively unusable
26
Which is more risky with numbers?
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).
27
Probability Impact Matrix
High Risk/Impact
Low Risk/Impact
CAUTION do not put too much stock in actual
values.
28
Sample Probability/Impact Matrix
Taken from IT Project Mgmt, 3rd edition, Course
Technology Publishing
29
Understand Risk
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
30
Identify potential scenarios and associated risks
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.

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
• Dont equate QA with Test (although testing is
  important)

33
QA Feedback
QA
QA
QA Criteria
Objective Feedback via
Should be part of a continuous improvement plan

• Evaluations
• Noncompliance reports
• Corrective actions

ERP Implementation Process
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 Earths
  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).

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

36
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

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)

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?

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

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

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

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

44
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