People, Product, Process --> Project Recall: overall project components: project people product process successful management plan must deal effectively

People, Product, Process --> Project

Recall: overall project components:

project

people product process

successful management plan must deal effectively with all three components

Project ManagementProject and Process Metrics

Project--Critical Practices

CRITICAL PRACTICES:

1. people-aware program management

2. well-defined product goals

3. well-defined process

4. quantitative, metric-based project management

5. risk management—identify, plan for risks

6. accurate cost and schedule estimation

7. uniform standards

8. tracking defects against quality definitions

1. People-aware Program Management

PEOPLE ISSUES ("HUMAN FACTORS"):

what are goals / functions of each set of stakeholders?GOAL

FUNCTION•senior managers

•tech managers

•"practitioners" (engineers,programmers)

•customers

• end-users

where do goals conflict?

team leaders need good MANAGEMENT SKILLS to:

provide motivationmaintain organization encourage creativityreward good worksupport positive work environment

training in management skills is necessary; learning them on the job is not acceptable or efficient

How can engineers learn these skills during their college years?


TEAM ORGANIZATION-CHOICES:

democratic / controlledcentralized / decentralized

there is no “best” organization for all tasks

some factors to consider:----problem difficulty

----problem size ----team lifetime ----how much modularity is possible

----quality requirements of finished product----time constraints----communication needs

How does this decision correlate with the process model you choose?


GOOD COMMUNICATION AND COORDINATION are an absolute MUST

Two kinds of communication channels must be set up:

formal communication: documents, memos, milestones, schedules, etc.quality assurance--"reviews"

informal communication: group meetings, problem solving sessions, "collocation"


2. Well-defined Product Goals

PRODUCT:

product is the overall "goal"

it must be WELL-DEFINED

customer input is essential:requirementsintermediate reviews on-site customer (extreme programming)

PROCESS:

many models available, as we have discussed

PROCESS MODEL MUST MATCH:

----product

----available resources

3. Well-defined Process

PROJECT

*start out right

*maintain momentum

*track progress

*"make smart decisions"

*conduct "postmortem"

*watch for Pressman’s "10 signs of trouble"


"10 signs of trouble" :

1. developers don't understand customer needs

2. product scope poorly defined

3. changes poorly managed

4. chosen technology changes

5. business needs change or are ill-defined

6. deadlines unrealistic

7. users resistant

8. sponsorship lost

9. project team members lack appropriate skills

10. team does not use best practices/lessons learned


Planning for a successful project:

Resources:--We need ways to estimate the resources it will take to complete the project--We need to plan how to arrange the project so that sufficient resources will be available

Risks:--We need to plan for "risks"--essentially, "what can go wrong"


--how can we get data to measure?* data from previous projects* "benchmarks”--e.g., industry standards* theoretical models

--what quantities do we need to estimate at the planning stage?

--how can we quantify qualitative questions, e.g., how “difficult” are the programming tasks?


Things we want to measure:

softwaresizedifficultyquality

the process itselfproductivitycost

Things we can measure:

softwareLOC, #classes#I/O, # functions, #objects#bugs found

the process itselfperson-hourssalaries, equipment, space


PROCESS metrics (“strategic”): factors we measure to improve the process; usually indirect

Examples:

--"product defects“--what are they? where did they originate? how can similar defects be prevented in future?

--products delivered

--person-hours

--calendar time used

--was the schedule met?


PROJECT metrics:"tactical"

manager and team may need to adapt their procedures if project metrics are not satisfactory

example: number of bugs uncovered should decrease as the software is tested


PROJECT planning: the W5HH principle (Boehm 1996):

Why is the system being developed? (“business purpose”)

What will be done? (task set)

When will it be done? (schedule)

Who is responsible for a function? (team member roles)

Where are they organizationally located? (e.g., customer)

How will the job be done technically and managerially?

How much of each resource is needed?


SOFTWARE metrics—can quantify product and project

Parameters need to be defined by the organization, based on experience and historical data

Example: KLOC: a simple conceptsize (KLOC)“quality”--defects per KLOCcost per KLOC

Example: function points or object points: a higher-level concept


Example of “function points” Component type # X (simple,average,complex) =External inputs 2,1,1 3 4 6 16External outputs 3,1,1 4 5 7 22External inquiries 1,1,1 3 4 6 13Internal logical files 5,1,1 7 10 15 60External interface files 0,2,0 5 7 10 14

Total: 125

Pressman: Comparison of LOC / function point for a language? Avg. Median Low High

Assembler 337 315 91 694C 162 109 33 704C++ 66 53 29 178Java 63 53 --- -----Perl 60 --- --- -----Visual Basic 47 42 16 158


Empirical estimation models:

"experimental approach"

uses data from a set of (completed) projects to try to predict effort required for future projects

basic method: regression analysis ("curve fitting"--statistics):

independent variables can be KLOC, # objects, etc.

dependent variables can be person-hours, cost, etc.--”effort"


basic formula for these models:E = A + B x (ev)C

E: effort (person-months)ev: estimation variable (KLOC or weighted # of objects, e.g.)A,B,C empirical examples:E = 5.5 + 0.73x(KLOC)1.16

E = 5.288 x (KLOC)1.047

E = -13.39 + 0.0545 FPE = 60.62x7.728 x 10-8FP3

E = 585.7 + 15.12FP

why are these so different?


one specific example: COCOMO model (COnstructive COst MOdel)derived by Boehm (81), refined to COCOMO II (99,00)actually a hierarchy of models:

application composition stage:for early use (p. 660, Pressman) estimated effort = (new object pts)/productivity ---weights "object pts", i.e., screens, reports, components; ---factors in reuse ("new") ---productivity based on developer skills, environment

early design stage: use after requirements set and basic architecture determined

post-architecture stage:use during software construction


software quality is harder to measure

for example, is software:

correct?maintainable?usable?robust?


what can you measure in this quarter's project?

process:time (each team member)resourcesprocess "defects"

product:lines of codenumber of classes (weighted?)number of I/O options and interclass linksnumber of errors found / corrected at a given time

Challenges (for quarter project planning):--choose good “weighting” factors for classes, code (requirements, specifications, functionality, etc.)

--include time to integrate modules --must also quantify work done on “design” phase



Risk analysis: managing uncertainty

GOAL: be prepared for whatever happens during project

example: your senior project is due next week and-the system is down-your disk crashes-your car breaks down-you get the flu-your partner disappears

What could you have done during the planning stage to allow for each of these “risks”?

How likely (what is the probability) that each one will occur?

How likely (what is the probability) that more than one will occur?

During planning, a Risk Table is generated: Risks Type* Probability Impact Management Plan

(Pointer)System not availableHardware failureColor printer unavailableIncompatible software updateTeam can’t learn tools/langPersonnel absent

(one meeting)Personnel unavailable

(several meetings)Team members in conflictPersonnel have left project

*Type: Performance (product won’t meet requirements); Cost (budget overruns); Support (project can’t be maintained as planned); Schedule (project will fall behind)

Probability: of this risk occurring (use categories, e.g., low, med, high, unless you have data)

Impact: e.g., catastrophic, critical, marginal, negligible

YOU NEED THIS IN YOUR PLANNING DOCUMENT!!


Then table is sorted by probability and impact and a “cutoff line” is defined. Everything above this line must be managed (with a management plan pointed to in the last column).

what risks will there be in your quarter project? how will you manage risk?

Useful reference: Embedded Syst. Prog. Nov. 00--examples:http://www.embedded.com/2000/0011/0011feat1.htm

.


professional risk analysis is proactive, not reactive


Scheduling and Tracking

why is software late?

unrealistic deadline changing requirementshonest underestimate of resources/timerisks not consideredunforeseen technical difficultiesunforeseen human difficultiesmiscommunicationmanagement failure to recognize/react to delay


scheduling guidelines:

compartmentalize: product & process

determine interdependency:(sequential/parallel tasks) ("Gantt” or timeline chart)

allocate time: "units" + start, stop dates

do not overallocate resources

define responsibilities

define outcomes

define milestones


Scheduling Aids:

•task network--determine interdependencies

•Gantt chart or timeline chart--schedule

•project table--track initial planning + modifications documented


Task network--interdependencies:

Project defn.Project

Modulari-zation

DesignModule

B

IntegrateDesigns for A,B

DesignModule A

ProjectReview

YOU NEED THIS IN YOUR IMPLEMENTATION PLAN!


Work Tasks Week 1 Week 2 Week 3 Week 4 Week 5

1 Define Requirements Define customer needs Define available resources Determine skill levels Create Req. Document, Use Cases Milestone: Requirements Defined2 Create UML description Create ER diagram Create CRC cards Create object message diagrams Create state diagrams Create sequence diagrams, tests Revise UML, complete test cases

Milestone: UML Description Done3 etc……

Gantt or timeline chart



Work Tasks Planned Actual Planned Actual Assigned Effort Notes Start Start Complete Complete Person Alloc.

1 Define Requirements Define customer needs wk1,d1 wk1,d1 wk1,d3 wk1,d5 CP,JS 1.5 p-d cust. Define available resources wk1,d2 wk1,d2 wk1,d3 wk1,d3 DK,EL 1.5 p-d req. Determine skill levels wk1,d3 wk1,d4 wk1,d4 wk1,d5 JS 1 p-d more Create Req. Doc., Use Cases wk1,d2 wk1,d3 wk1,d4 wk1,d5 all 2.5 p-d time Milestone: Requirements Defined wk1,d4 wk1,d5 wk1,d4 wk1,d52 Create UML description Create ER diagram wk1,d5 wk2,d4 wk2,d4 all 8 p-d Create CRC cards wk2,d1 wk2,d4 wk2,d4 CP,JS 6 p-d Create obj. mess. diagrams wk2,d2 wk2,d4 wk3,d2 DK 2 p-d Create state diagrams wk2,d5 wk3,d2 wk3,d3 EL 3 p-d Create sequence diag., tests wk2,d5 wk2,d5 wk3,d5 CP,JS 6 p-d Revise UML, compl. test cases wk2,d1 wk4,d1 all 2 p-dMilestone: UML Description Done wk4,d1 wk4,d13 etc……

Project table--tracking



Quarter project:

Initial schedule: major tasks for each week

This can be determined from the 495 lab page

Examples?

As project progresses, details will need to be added to the schedule.


CONFIGURATION MANAGEMENT:

changing software is easy, managing change is therefore difficult

configuration management guidelines:•identify objectsestablish baselinesimplement version controlmaintain coordination: software and documentation

note: one system for configuration management is CVS (Concurrent Versions System), http://www.cvshome.org/(can be used but is not required for quarter project)


CODING STANDARDS:

Using standard rules for naming, documentation, etc., will help your team and future developers understand and improve your code

Example: an example set of Java coding standards can be found athttp://developer.netscape.com/docs/technote/java/codestyle.html

The coding standards given at this website cover:•general coding rules, including naming conventions and documentation rules, which everyone working on the related project MUST follow•general coding guidelines, including source code style and naming guidelines, source code layout, and documentation for methods and functions, which everyone working on the related project is STRONGLY ENCOURAGED to follow


DOCUMENTATION: good documentation requires you to: •document sufficiently•use “self-documentation (e.g., identifier names) •maintain coordination: software and documentation•use consistent standards for documentation

possible tools to help with documentation:

1. "javadoc"; (Knuth)javadoc website:http://java.sun.com/j2se/javadoc/writingdoccomments/#terminology

2. “Doxygen”:http://www.stack.nl/~dimitri/doxygen/


SOFTWARE QUALITY ASSURANCE: SQA

we must define what "quality" means

we must take steps to achieve this quality

what do we measure?defectscustomer satisfactionreliabilityperformance


what approach do we use to determine quality?

formal methodsstatistical methods--including user surveys

whose responsibility is "quality"? (answer: "everyone's")

are there standards?ISO 9001 (ISO 9000-3)ISO registration--required to develop software for government, medical devices, telecommunications,

etc.


What is an appropriate definition of “quality” and how can this level of quality be achieved in the quarter project?

• “quality” will be part of requirements• quality factors will be included in specification

this implies there must be quality “use cases”• some possible quality factors:

--bug-free--ease of use--user friendliness--completeness and usability of documentation--help provided to user--attractiveness of display--response time--???? Measuring: bug counts, user surveys


Documents

People, Product, Process --> Project Recall: overall project components: project people product process successful management plan must deal effectively