You are on page 1of 88

Friday, October 24, 2008

INITIAL SOFTWARE PLANNING
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 1

Friday, October 24, 2008

Initial Planning Overview

1 Overview 2 Understanding the Customer and the Requirements 3 Defining the Approach 4 Analyzing the Environment
Lifecycle Analysis Complexity Analysis Roles and Communication Analysis
Complexity Lifecycle Communication

5 Selecting Process and Methods
Text, chapter 6
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 2

Friday, October 24, 2008

What Is Initial Planning?

Goal: To Scope Out the Project and Plan its Execution so you can Properly Manage the Software Lifecycle When: • As soon as you start
– proposal – contract – any other starting point

• Update at periodic milestones and events during execution
– Whenever you may need to revisit and change the plans
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 3

Friday, October 24, 2008

Process Model Diagram

REFERENCE INFORMATION

INPUTS

Process Step

OUTPUTS

Nitin V Pujari

TSDP-Sep-2005 - Project Management

SUPPORT FACILITIES

Slide 4

Friday, October 24, 2008

Understand the Need

• Identify Customer Needs • Markets • Problem Statement • Requirements • Expectations • Know the Customer • Sponsor • End User • Intermediaries • Know the Commitments • Identify Risks
Nitin V Pujari

Risk Management

Understand the Need

Define the Approach

Generate Detailed Plans

Monitor Execution

This process step is primarily one of communicating with the customers and documenting the needs
Slide 5

TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Who is the Customer?

Champion System Engineer Program Mgr

Software Manager
Nitin V Pujari

Legal Dept TSDP-Sep-2005 - Project Management

End User Slide

6

Friday, October 24, 2008

Eventually, you want to Align the Goals

Goal

Goal Goal Goal Goal Goal Goal Goal

Goal Goal Goal
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 7

Friday, October 24, 2008

Process Chart

• Customer Needs or • RFP or • Draft SOW or • Product Ideas

Nitin V Pujari

BUSINESS PLANS MANAGEMENT AND OBJECTIVES INSIGHT & DECISIONS • Market Analysis • Commitment • Statement of Understand Work • Statement of the Need Requirements • Tests • Expectations FACILITIES TRAINING • Process (hi level) RESEARCH JOB AIDS • Risks 8 TSDP-Sep-2005 - Project Management Slide

Friday, October 24, 2008

Key Outputs

• Market Analysis - Who Wants It, What Will they Pay, and Who is the Competition? • Commitment - Who Promised What to Whom? • Statement of Work - What to Do / What to Deliver • Statement of Requirements - What the Product Must Do • Tests - How We will Decide if it is Right • Expectations - Who Expects What? • Process (hi level) - Life Cycle • Risks Identified
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 9

Friday, October 24, 2008

Statement of Work

A document that states what work is to be performed and what products are to be delivered. It defines the requirements for the project and the process. -- May optionally include such items as: -- when (schedule, delivery dates) -- costs (budgets, spending profile) -- applicable standards -- methods, tools or even processes to be used -- Often used as the basis for a contract because it indicates specific things to be done
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 10

Friday, October 24, 2008

Example SOW

• Develop a spreadsheet program in the C++ language to run under DOS 3.0 under Windows • Deliver the following:
– – – – – Source code User’s guide Load module of the spreadsheet Operator’s guide Installation guide

• Develop using workmanlike processes and methods [i.e., contractor’s choice but must be competent] • Spreadsheet should meet the requirements contained in a separate Management specification Nitin V Pujari TSDP-Sep-2005 - Project Slide 11

Friday, October 24, 2008

Requirements

Statement • Develop a spreadsheet tool that is better than Excel but looks and functions like it

Specification • In response to the “sort” command, the spreadsheet shall do the following: • ...... • ...... • ...... • ......
Slide 12

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Test Requirements

• A document indicating how the product will be tested and what constitutes acceptable performance • Example:
– The spreadsheet must pass the standard spreadsheet test suite defined by TESTSRUS corporation – The spreadsheet shall be run through each command and the screens will be inspected for proper color, speed, and readibility – The spreadsheet help command will be applied for each command listed in appendix 2 of the requirements statement and the resulting help information must be understandable by at least 80% of a panel of novice spreadsheet users ...
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 13

Friday, October 24, 2008

Typical Requirements Flowdown

3000 pounds 0-60mph in 9 sec Original Requirements Allocated Requirements Engine 500 pounds 250 hp Nitin V Pujari

Automobile

System Analysis & Design

Transmission

Drive Train

Chassis 2000 pounds
Slide 14

...

100 pounds 50 pounds torque ... TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Requirements Trace Mechanism

• Needed so you can connect the requirements the software is designed to address to the original requirements as specified by a system designer or customer Electrical Allocatio Rqmt 1 Mechanical n Process Rqmt a Software Rqmt a Rqmt 2 Rqmt b Rqmt a Rqmt b Rqmt 3 Rqmt c Rqmt b Rqmt c Rqmt d Rqmt c Rqmt d Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 15 Rqmt d

Friday, October 24, 2008

In the DoD World

• SSS (System/Segment Spec) -- System Requirements • SSDD (System/Segment Design Document) -Allocation of Requirements & Requirements Trace Matrix • SRS (SW Requirements Spec) -- Detailed specifications for those requirements allocated to the software • IRS (I/F Requirements Spec) -- Detailed specifications for the interfaces between software products and the rest of the system
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 16

Friday, October 24, 2008

Typical Risks Identified

• • • • • •

Cannot Decide What to Do or What to Deliver Requirements are Too Vague Technology May Not be Adequate Schedules may Not be Feasible Costs May be Prohibitive or Uncertain Domain Knowledge may be lacking
– i.e., we don’t know how to do it – need to go outside for information

• Tests not Stated or not Understood
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 17

Friday, October 24, 2008

3.3 - Define the Approach

1 Analyze the Environment • Communication • Program Life Cycle • Product Complexity 2 Identify the Process • Basic Lifecycle • Tailoring • Identify Risks

Risk Management

Understand the Need

Define the Approach
Monitor Execution

Generate Detailed Plans

This process step has two main tasks, as identified at the left

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 18

Friday, October 24, 2008

Process Chart

MANAGEMENT CONSENSUS APPROVAL • Market Analysis • Competitive Analysis • SOW • Commitment • Requirements • Tests • Expectations • Process • Risks
Nitin V Pujari

PEOPLE • Lifecycle Model - Schedule (hi level); goals • Complexity Model - Organization - Product Struc. • Communication Model • Process Model • Risks
Slide 19

Define the Approach

FACILITIES

TRAINING

TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Principal Outputs

1) Lifecycle Model for project & each subproject • The goal of the project • The phases of the lifecycle • The goals of each phase, and • The characteristics of each phase 2) Complexity Model (interdependency chart) • The structure of the product, and • The structure of the project.
– The magnitude of each part – How the different parts depend on and interface each other
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 20

Friday, October 24, 2008

Principal Outputs (continued)

3) Communication Model • The individuals and organizations involved, • Who has what responsibility and authority, • How communication will occur 4) Process Model (for each subproject) • The tailored process by which each software product will be developed • Specific details for near-term products

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 21

Friday, October 24, 2008

3.4 - Analyzing the Environment

This produces the first three outputs defined above This activity has three parts: • Lifecycle analysis (when to do what) • Complexity analysis (what to do / dependencies) • Communication analysis (who will do what, when)

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 22

Friday, October 24, 2008

Find Your Project’s Location in the Solution Space

I.e., in what environment will you do the work?

Complexity

Lifecycle Communication
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 23

Friday, October 24, 2008

Note

• This is an initial estimate • It is not a detailed plan • Its purpose is to let you scope out the extent of the project:
– – – – What is to be done By whom When With what information and tools and people

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 24

Friday, October 24, 2008

Another Note

These analyses occur concurrently and they feed each other

Lifecycle

Complexity Communication

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 25

Friday, October 24, 2008

Another Note

• Once you determine the overall project lifecycle and phase structure, you should apply these techniques in the following fashion: - Prior Phase - This Phase - Next Phase - Next Phase Gather History and Lessons Learned Develop Plans in Detail General Plans Sketch Out Plans

If you are using a non-sequential lifecycle, this needs to be modified accordingly
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 26

Friday, October 24, 2008

Fitting the Project Lifecycle

Phase 1 When you are in phase 1 When you are in phase 2
Nitin V Pujari

Phase 2 General Plans

Phase 3 Sketchy Plans

Complete, Detailed Plans

History, Lessons Learned

Complete, Detailed Plans

General Plans

etc.

TSDP-Sep-2005 - Project Management

Slide 27

Friday, October 24, 2008

3.4.1 - Lifecycle Analysis

Complexity

Lifecycle
Communication

Goal: Establish the overall plan and roadmap • Clear goals and activities for each phase • A clear path (plan) to achieve the goals • Exit criteria tied to the goals
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 28
Lifecycle

Communi ation c

Friday, October 24, 2008

Lifecycle Analysis Procedure

a) Define or confirm the goal and evaluation criteria for the project as a whole
– Should be simple and easy to comprehend

b) Define or ascertain the project lifecycle based on the process concepts identified earlier
– – – – Tailor from a starting concept Focus on what, not how Do at a high level only -- system first, then software Include phases already completed to give a good perspective (expecially important for new staff)

c) Define or determine the phases, goals, criteria, etc. for the project lifecycle
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 29
Lifecycle

Communi ation c

Friday, October 24, 2008

Lifecycle Analysis (continued)

d) Determine what phase you are in now (especially if replanning) e) Detail out the current phase with software lifecycle and process details for each software subproject
– – – – Intermediate goals Milestones Number of cycles or spirals or whatever Note that you may have different processes for different parts of the software – Note that details may change as you execute and learn more
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 30
Lifecycle

Communi ation c

Friday, October 24, 2008

Lifecycle Analysis (continued)

f) Work out a rough, high level schedule corresponding to the lifecycle model and milestones g) Identify the risks

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 31
Lifecycle

Communi ation c

Friday, October 24, 2008

Typical Risks Identified during Lifecycle Analysis

• The goals and requirements are unclear or conflicting
– Must resolve or estimates will be inaccurate

• Too many design ideas too soon
– Focus on needs, requirements, and problems

• Unrealistic optimism
– Are you really this far along? – Can you really do it?

• Unrealistic pessimism
– Leads to perennial research

• Vague details, especially for near-term tasks
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 32
Lifecycle

Communi ation c

Friday, October 24, 2008

Risks (continued)

• Expectations of senior managers or customer sponsors are inconsistent with reality
– Must be negotiated to achieve consensus

• Expectations of technical staff are too conservative
– Potential for “analysis paralysis” – See above

• Evaluation criteria are vague
– Can lead to incomplete testing or failure to meet expectations

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 33
Lifecycle

Communi ation c

Friday, October 24, 2008

Output of Lifecycle Analysis: A Project Lifecycle Model

• Project Goal • Goals, Evaluation Criteria and other characteristics for each phase of the project lifecycle • Schedule (High Level) • Detailed characteristics (software lifecycle) for current phase -- FOR EACH SOFTWARE PRODUCT TO BE DEVELOPED IN THIS PHASE (there may be several different ones)

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 34
Lifecycle

Communi ation c

Friday, October 24, 2008

Example: a Professor’s Database Program

Project Goal: An “easy to use”, PC-based database system for the professor to use in keeping track of students, grades, etc. Project Lifecycle:
Subgoals & Milestones Customer Likes Behavior Software Passes Formal Tests Custome r Retires

Develop Prototype
Schedule
Nitin V Pujari

Develop Final Product
6 mos 18 mos
Complexity

Maintain
10 yrs
Slide 35
Lifecycle

TSDP-Sep-2005 - Project Management

Communi ation c

Friday, October 24, 2008

Example (continued)

Software to be built:

Phase 1

Phase 2

{ {

• Database prototype (to check out performance and disk space issues) • User interface prototype • Final software product • Tests for final product

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 36
Lifecycle

Communi ation c

Friday, October 24, 2008

Example (continued)

Risks Identified: • Professor’s ideas are vague (this is why you chose a prototype phase) • Details of implementation are unclear (another reason for the prototype) • PC may be inadequate • Professor is too cheap to pay for the work
– Have early milestones and deliverables with specific payments required

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 37
Lifecycle

Communi ation c

Friday, October 24, 2008

Q: What is the difference between a lifecycle model and a process description? A: It is a matter of detail. A lifecycle model is essentially a high level model of the process.
– A lifecycle model focuses on the big picture - the phases, the goals, the milestones, and the major outputs – A process description, which is normally done only at a high level during environment analysis, would include what process model is being applied, the major entry and exit criteria for the phases, and the key inputs and outputs of each phase – Later, during detailed planning, a more detailed process model should be developed. – Actually, many of the process details will have to be worked out as part of complexity analysis (next section).
TSDP-Sep-2005 - Project Management

Nitin V Pujari

Slide 38

Friday, October 24, 2008

Q: is a phase a time thing, corresponding to a specific set of dates, or is it a task or a state or a transformation? A: a phase is an aggregate thing consisting of a set of tasks to be performed and a set of results to be produced. Assigning a phase to a specific set of dates is called scheduling, but the phase is not the same as a portion of the schedule. If the work is completed ahead of schedule, we say the phase completed ahead of schedule. Ditto for behind schedule.
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 39

Friday, October 24, 2008

Q: Around here, when you have a phase scheduled you are expected to end the phase when the schedule says you should. Is that wrong? A: It is wrong to delude yourself into thinking the phase is over because a specific date is reached. But due to the realities of funding and customer deadlines, it might be necessary to revise the process and change your plans vis a vis what parts of the work will be completed by a given time.
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 40

Friday, October 24, 2008

Q: If we don’t complete the “design” phase by the scheduled date, our project will be cancelled. How do we handle that when we clearly cannot complete all of the design tasks by the deadline? A: It is one thing to agree with your customer that the “design” phase is complete when a certain part of the design work is over (and other work remains to be completed). But don’t lose sight of the fact that there is other work to be done. You may need to add a “design revision” task to the next phase, for example.
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 41

Friday, October 24, 2008

3.4.2 - Complexity Analysis

Complexity
Lifecycle Communication

Goal: To divide the project into independent parts and characterize those parts (risks, sizes, interrelationships)
Nitin V Pujari TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 42

Friday, October 24, 2008

Complexity Analysis Procedure

a) Partition the project into independent parts (subprojects) • Product structure
– Based on initial concept of system structure – What parts are fundamentally independent?

• Project structure
– – – – Based on how the project will be managed Who will be responsible for what? Often influenced by product structure But also influenced by organizational structure
TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Nitin V Pujari

Slide 43

Friday, October 24, 2008

Product Structure Diagram (System Architecture)

System

Subsystem (segment)

Subsystem (segment)

Subsystem (segment)

Subsystem (segment)

Product or Item (configuration item)
Nitin V Pujari

Product or Item (configuration item)

Product or Item (configuration item)
Slide 44

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Friday, October 24, 2008

Example

Computer

Keyboard

System Unit

Display

Printer

Power Supply

Processor and Memory

System Software

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 45

Friday, October 24, 2008

Organizational Breakdown Structure

Manager

Accounting

Chief Engineer

Contract Administration

Support Manager

Software Development Manager Team for Product 1

Electrical Design Manager

Mechanical Design Manager Software Manager’s Primary Responsibility
Complexity
Lifecycle Communic ation

Nitin V Pujari

....

Team for Product n

TSDP-Sep-2005 - Project Management

Slide 46

Friday, October 24, 2008

A Team-Oriented Organizational Breakdown Structure

Accounting

Customer Interface

Program Management Product Contract Team Engineering Administration Team for Product 1 Team for Product n

Support Engineering

Engineering Team

Team for Product 2
Nitin V Pujari

....

Software Manager Responsibility

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 47

Friday, October 24, 2008

A Typical Organizational Problem

Project

Company A

Company B

A’s Specialty

Other

Other

B’s Specialty

Joint Responsibility
Nitin V Pujari TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 48

Friday, October 24, 2008

Separate Sub-projects

Project A Project E Project B Project D

Project C

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 49

Friday, October 24, 2008

Complexity Analysis Procedure (continued)

b) Show the top level lifecycle for each subproject, showing the major steps and dependencies (*)
Keyboard Keyboard Software Keyboard Emulation Design Design Prototype Code Test Final Design Build

Build

Subcontracted SW for Numeric Key Pad

Contract

Delivery

(*) Would normally be done using a PERT or project management tool like Microsoft Project or Primavera
Nitin V Pujari TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 50

Friday, October 24, 2008

On a Large Project, you May Need to Make a List of Software Subprojects

Subproject Data Base Operating System Controller Test Sets etc.

Lifecycle Waterfall Spiral (3) Spiral (2) Waterfall etc.

Schedule A B C A etc.

Lead Jones Smith Watson Holmes etc.

Often you will have several basic schedules, tied to specific reviews or deadlines, and several basic lifecycle models in use. This chart Nitin V Pujari helps if there are many software TSDP-Sep-2005 - Project Management Slide products / projects to keep track of.
Complexity
Lifecycle Communi ation c

51

Friday, October 24, 2008

Complexity Analysis Procedure (continued)

c) Generate a pert chart showing the interrelationships between the subprojects
Keyboard Keyboard Software Keyboard Emulation Design Design Build Delivery We will address PERT charts later in the course
Slide 52

Prototype Code Test

Final Design

Build

Subcontracted SW for Numeric Contract Key Pad
Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Friday, October 24, 2008

Complexity Analysis Procedure (continued)

d) Generate a network chart showing the interrelationships and schedule lengths
J F J M A M J J A S O N D J F M J Design J

M

Prototype Code Test

Final Design

Build

Design Build Contract
Nitin V Pujari

Delivery

Network chart shows durations as well as dependencies and clarifies the minimum time required to execute the project (this is the critical path)
Lifecycle Communi ation c

Complexity TSDP-Sep-2005 - Project Management

Also shows top level Slide 53 schedule for the

Friday, October 24, 2008

A Real Network Chart Might Take Up a Wall

Design

Prototype

Design Final Design

Build Prototype Design Prototype

Final Design

Build Build

Final Design Build

Design

Code

Test

Design

Prototype

Final Design

Build

Design

Prototype

Final Design

Build

Contract

Delivery

Design

Prototype

Final Design

Build

Design

Prototype

Final Design

Build Build

Design

Prototype

Final Design

Design Build

Prototype

Final Design

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 54

Friday, October 24, 2008

Warning from Dilbert

“For large projects, Team Leaders use  sophisticated project management software to  keep track of who’s doing what.  The software  collects the lies and guesses of the project team  and organizes them into instantly outdated  charts that are too boring to look at closely.   This is called ‘planning.’”   Adams, The Dilbert Principle
Nitin V Pujari TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 55

Friday, October 24, 2008

Complexity Analysis (continued)

e) Develop an interdependency checklist to show all “independent” activities on which software depends or that software depends on
Software Depends On: Item Emulator Build Keyboard Prototype Numeric Keypad SW Due 2.5 5.5 5.9 Latest 2.9 6.0 6.0 Software Impacts: Item Due Latest 8.0

Keyboard Final 7.5 Design

These are items you must also track closely, These are the items you must as they can endanger track closely, as they can the whole project 56 Nitin V Pujari TSDP-Sep-2005 Slide endanger your schedule - Project Management
Complexity
Lifecycle Communi ation c

Friday, October 24, 2008

Optional Information (add now if known; else later)

• Resource requirements
– – – – Personnel Equipment Facilities Dollars of various “colors”

• Shortest possible schedules using maximum staffing / schedules with minimum staffing • Integration plan
– Order – Who, What, When

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 57

Friday, October 24, 2008

Typical Risks Identified during Complexity Analysis

• Unknowns in all areas • External dependencies
– Some not identified – Some not under good control – Some involve unclear responsibility

• Unknown risks for individual parts of the project
– Eg: is the keyboard emulator a high risk item?

• Breakdown into subprojects is inaccurate or vague or unsuitable
– Eg: key, high risk task under control of inexperienced staff

• Dependencies not communicated to affected parties
Nitin V Pujari TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 58

Friday, October 24, 2008

More Risks from Complexity Analysis

• Legal Issues -- Who Owns this Code?
– Especially if code is reused

• Inadequate Control of Internal Dependencies
– We trust our own organization, so we don’t need to manage it

• Boundaries determined by Political Factors
– Incompetent subcontractors – Irrational division of work

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 59

Friday, October 24, 2008

Outputs of Complexity Analysis: Complexity Model

• Network / Pert Chart for Program • Interdependency Checklist • Risks

Nitin V Pujari

TSDP-Sep-2005 - Project Management Complexity
Lifecycle Communi ation c

Slide 60

Friday, October 24, 2008

3.4.3 - Communication Analysis

Goal: Identify all individuals and organizations Complexity involved in the project Lifecycle • Relationships Communication • Responsibilities • Communication paths Who does what for whom, when and how?
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 61
Lifecycle

Communication

Friday, October 24, 2008

Overview of Communication Analysis

Essentially, communication analysis focuses on the roles each project entity has to play The it determines the connections or interfaces or communication paths that must exist between roles to be successful
Project Manager SW Lead
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity Lifecycle

System Engineer Sw Mgr

Customer
Slide 62
Communication

Friday, October 24, 2008

Methods of Analysis

• We will describe a manual method • You might try an automated method on a large project
– CASE tools

• Key questions: -- Are the communication needs identified? -- Are the communication paths defined?

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 63
Lifecycle

Communication

Friday, October 24, 2008

Communication Analysis Manual Procedure

a) Describe the organization of each entity involved in the project
– Subcontractors – Support Organizations -- Customers -- Project Organizations

- Responsibilities - Products (artifacts generated) - Key positions - Authority levels - Key individuals Annotated organization charts are a good way to do this
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 64
Lifecycle

Communication

Friday, October 24, 2008

Communication Analysis (continued)

• b) Identify the key functions of each entity and the entities they must communicate with Functional Responsibility Chart - Software Eng.
Function Design Communicates With Customer Rep End User Rep. System Engineering Test Engineering Contact Individual Colonel Pete Smith PFC B. Bailey Brad Manly Jane Workhard

Coding etc.
Nitin V Pujari

Customer Rep Colonel Pete Smith Field Test Rep Captain Joe Danger Hardware Engineering Dolores Dooright
TSDP-Sep-2005 - Project Management
Complexity

Slide 65
Lifecycle

Communication

Friday, October 24, 2008

Communication Map

c) Draw a communication map, showing “lines of communication” in graphical form
A Map - based on Org Charts contra ct issues legal issue s technical interchang es TSDP-Sep-2005 - Project Management

Nitin V Pujari

Complexity

Slide 66
Lifecycle

Communication

Friday, October 24, 2008

Another Communication Map

A Map Based on Hierarchy
Company
Department Project Team Individual

Nitin V Pujari

TSDP-Sep-2005 - Project Management
Complexity Lifecycle

Slide 67

Communication

Friday, October 24, 2008

Detail the Interfaces

d) Develop detailed descriptions of interfaces -- who has the right to make legally binding commitments? -- who has the authority to approve releases? -- who has the authority to approve changes? -- etc.

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 68
Lifecycle

Communication

Friday, October 24, 2008

Sample Interface Description

From Tech Supervisor Legal Department

To End User

Description/Authority Technical Design Info No Contractual Commitments Subcontractor Legal Contracts No Technical Commitments

etc. ________________________________________________________ WHY DO THIS? - To identify missing interfaces - To reduce misunderstandings DURING THE “HEAT OF BATTLE” IS NOT THE TIME TO RESOLVE SUCH ISSUES
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexity

Slide 69
Lifecycle

Communication

Friday, October 24, 2008

Typical Risks Identified during Communication Analysis

• Structure of some organization is unclear
– Who does Joe Smith report to? – Two people both claim responsibility for testing

• Functions and responsibilities are unclear
– Who is responsible for approving contract changes? – Who has authority to increase the budget?

• Responsibility and authority not defined • Responsibility shared (= responsibility not defined)

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 70
Lifecycle

Communication

Friday, October 24, 2008

Typical Risks (continued)

• Critical interfaces are missing
– We have not identified who should provide technical info

• Potential for unauthorized commitments • Potential for failure to perform important functions “The real objective of business 

communication is to advance your  career.  That objective is generally at  odds with the notion of ‘clear transfer  of information’” Adams, The Dilbert Principle

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Complexity

Slide 71
Lifecycle

Communication

Friday, October 24, 2008

Output of Communication Analysis: A Communication Model

• • • •

Responsibilities Flow of Information Authority Risks
contra ct issues legal issue s technical interchang es

Functional Responsibility Chart - Software Eng.
Function Design Communicates With Customer Rep End User Rep. System Engineering Test Engineering Contact Individual Colonel Pete Smith PFC B. Bailey Brad Manly Jane Workhard

Coding etc.

Customer Rep Colonel Pete Smith Field Test Rep Captain Joe Danger Hardware EngineeringDolores Dooright

Company

From John J Mary S. John J TBD ...
Nitin V Pujari

To Joe Q TBD Cdr. W P. Smith ...

Description Cost Details CM approvals Rqmts Appr. Technical rev. ...

Department Project Team Individual

TSDP-Sep-2005 - Project Management

Complexity

Slide 72
Lifecycle

Communication

Friday, October 24, 2008

A Note on Communication Analysis

Essentially, communication analysis designs a process using a role-based model, where each project entity has roles to play and the connections between roles represent communication paths or interfaces that must exist to be successful
Project Manager SW Lead
Nitin V Pujari

System Engineer Sw Mgr

Customer
Complexity

TSDP-Sep-2005 - Project Management

Slide 73
Lifecycle

Communication

Friday, October 24, 2008

At the End of Environment Analysis

You know a lot more about the scope: • Who is involved • What will be done • When things will be done • What risks are involved You are much better able to decide • Whether to go ahead with the project • What it is likely to cost • What resources will be required • How to manage the project
Nitin V Pujari TSDP-Sep-2005 - Project Management
Complexit y Lifecycl e

Slide 74

Communicati on

Friday, October 24, 2008

3.5 - Software Process Definition

Goal: determine what process to follow for each software subproject Why: the process is the map of what everyone will do -- it synchronizes activity -- it makes you less dependent on individuals because everyone knows what to do -- it helps make estimates more accurate -- you can repeat successes and avoid mistakes -- you can measure and improve the process
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 75

Friday, October 24, 2008

Approach

• It depends on whether you have already defined process models for your organization • If you do NOT have a defined process, you must develop one based on -- the experience of the participants -- information from others, such as industry standards -- customer-imposed standards and procedures -- specific characteristics of your project • If you DO have a defined process, you must Nitin V tailor to meet your specific project needs Slide 76 Pujari TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Document the Process

• In either case, you should document the process so that everyone has the same roadmap of what to do • A good process definition must indicate: -- the activities or tasks to be performed (what to do) -- the inputs and outputs (the artifacts used and produced) -- the relationships (such as sequencing, parallelism, dependencies, etc) among the tasks
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 77

Friday, October 24, 2008

Examples of Process Definitions

• We addressed this in an earlier chapter, but as a reminder:
-- A computer program documents a process for a computer to carry out » declarations define inputs and outputs » executable statements define activities and tasks » ordering of statements, sequence and control statements define the relationships
Nitin V Pujari

FUNCTION X(A,B) REAL A; INTEGER B IF A < 2.3 THEN B=B+1 ELSE B=0 ENDIF RETURN

TSDP-Sep-2005 - Project Management

Slide 78

Friday, October 24, 2008

Flow Charts

» Boxes define tasks » arcs and diamonds define relationships, sequencing » circles sometimes show external inputs and outputs, although flowcharts are deficient in showing internal artifacts

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 79

Friday, October 24, 2008

Data Flow Diagrams

Design Software

Design Specification

CM Library

errors

Design Walkthrough

» Boxes and circles define tasks » arcs and data boxes define artifacts, data flow » ordering defines relationships, dependencies (Note parallelism)
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 80

Friday, October 24, 2008

Considerations for Process Documentation

• Who will use the process description?
– You may need several different formats for different classes of users

• What supplementary information is needed?
– Data dictionary to supplement a data flow diagram – Artifact trace to show the complete history of a specific artifact – Input/Output cross reference: » Where does each input come from? » Where does each output go to?

Nitin V Pujari

• Highly formal process descriptions (e.g., petri-nets) tend to be poor for practitioners but good for doing analysis of processes
TSDP-Sep-2005 - Project Management

Slide 81

Friday, October 24, 2008

Considerations (continued)

• Processes tend to be very large and complex
– At the detail level, you need to discuss subsets and views of the process – This is like using “cross sections” of a large, complex molecule to understand its chemistry – Consider highlighting the parts of the process that are under discussion – Or consider using different colors for parts of the process that different groups are responsible for

• Give examples of process documentation in proposals, plans, etc. • Processes focus on WHAT, not HOW
– You may need to supplement with “how” for practitioners
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 82

Friday, October 24, 2008

Process Tailoring

• We discussed lifecycle tailoring above • Process tailoring is similar except at a more detailed level • Start with a standard process or a customerimposed process • Delete unnecessary artifacts and tasks
– Example: for a prototype that is not deliverable, delete formal tests or documents

• Change the scope of artifacts and tasks
– Example: for an incremental development, do not require a complete design specification until the end – Example: for a “clean room” process, reduce testing
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 83

Friday, October 24, 2008

Risks of Tailoring

• Deleting a task and failing to determine who depends on its outputs • Deleting an artifact and failing to determine who uses it and why • Deleting something because you don’t know why it is there
– You should only delete it if you KNOW why it is there – Otherwise you don’t know what damage you may be doing – This is a difference between level 1 and level 3 maturity

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 84

Friday, October 24, 2008

Organizational Process Documentation should Guide Tailoring

• Indicate WHY each task is there and who depends on it • Indicate WHY each artifact is there and who needs it • List the risks of deleting or modifying each task and artifact • Suggest tailoring approaches for specific situations
– Example: “If you are doing non-deliverable software, this formal inspection might be replaced by an informal walkthrough”
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 85

Friday, October 24, 2008

Document Tailoring Decisions

• Why each change was made • Additional risks that must be monitored as a result of tailoring
– Example: we removed the design review due to short program schedule and good design defect experience on the previous project -- must monitor defects during coding to validate that this did not cause trouble

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 86

Friday, October 24, 2008

Example of Tailoring Documentation

Tailoring Checklist
Step ... Design Review Walkthrough ... Artifact ... Design Spec Test Report ...
Nitin V Pujari

Tailoring ... Do Incrementally None ... Tailoring ... Do On-Line Summary Only ...

Rationale ... Iterative Process NA ... Rationale ... More Accurate, Lower $ Non-deliverable SW ...
Slide 87

TSDP-Sep-2005 - Project Management

Friday, October 24, 2008

Summary of Chapter

1 Overview -- Scope Out the Situation 2 Understanding the Customer and the Requirements 3 Defining the Approach 4 Analyzing the Environment
Lifecycle Analysis Complexity Analysis Roles and Communication Analysis

5 Selecting Process and Methods

Nitin V Pujari

TSDP-Sep-2005 - Project Management

Slide 88