3. project organization and management - cs.sjtu.edu.cnjdyu/teaching/se/handouts/3. project... ·...

3. Project Organization and Management

Software Engineering

Outline

!   An Overview of Project !   An Overview of Project Management !   Project Management Activities !   Project Organizations !   Project Communications !   Software Life Cycle Model


1. An Overview of Project


1.1 What is a Project

!   A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value.

!   Projects have end dates! !   Attributes of projects

•  Unique purpose •  Non-routine tasks are involved •  Temporary •  Planning is required •  Specific objectives are to be met or a specified project is to be created •  The project has a pre-determined time span


1.2 Project Attributes

!   More attributes •  Work is carried out for someone other than yourself •  Work require resources, often from various areas or involve

several specializes •  Work is carried out in several phases •  The resources that are available for use on the project are

constrained •  Should have a primary sponsor and/or customer •  Project can be large or small and take a short or long time to

complete •  Involve uncertainty


!   Consider the following: •  Producing an edition of a newspaper •  Building the Channel Tunnel •  Getting married •  A programming assignment for a second year

computing student •  Writing an operating system for a new computer

!   Which ones are more like Project?


1.3 Components of a Project

Project

Work Product Schedule Task Participant


2. An Overview of Project Management


2.1 History of Project Management

!   Some people argue that building the Egyptian pyramids was a project, as was building the Great Wall of China

!   Most people consider the Manhattan Project to be the first project to use “modern” project management

•  This three-year, $2 billion (in 1946 dollars) project had a separate project manager and a technical manager


2.2 The Triple Constraint of Project Management

!   Every project is constrained in different ways by its: •  Scope:

•  What work will be done as part of the project? •  What unique product, service, or result does the customer or

sponsor expect from the project? •  How will the scope be verified?

•  Time: •  How long should it take to complete the project? •  What is the project’s schedule? •  How will the team track actual schedule performance? •  Who can approve changes to the schedule?


!   Every project is constrained in different ways by its: •  Cost:

•  What should it cost to complete the project? •  What is the project’s budget? •  How will costs be tracked? •  Who can authorize changes to the budget?

!   It is the project manager’s duty to balance these three often competing goals.


Successful project management means

meeting all three goals (scope, time,

and cost) – and satisfying the

project’s sponsor!


2.3 Project Management Framework


2.4 States of a Project

Conception

Definition

Start

Termination

Steady State

do/FormulateIdea

do/Problem Statement do/Project Kickoff

do/Client Acceptance

do/Develop System

GoAhead ScopeDefined

&& Teams

System Done

New Technology

do/Cost-BenefitAnalysisdo/FeasibilityStudy

do/Review

Assembled

do/Delivery

do/Infrastructure Setup

Infrastructure SetupCompleted

do/Software Architecturedo/Software Plan

do/Skill Identificationdo/Team Formation

do/Controllingdo/Risk Management

do/Replanning

do/Post Mortem

New Need


2.5 Management activities in a software project

Initial Software Definition

Project Management Plan Initial Software Architecture

Start

Skill Identification

Conception Formulate Idea Cost-Benefit Analysis Feasibility Study

Problem Statement Definition

Infrastructure setup Team assembly

Project Agreement

Project Kick-off


Scope agreement Project replanning

Controlling Risk management

Installation

Steady state

Termination

Client acceptance test Postmortem


2.6 Tasks and Work Products

!   A task is a well-defined work assignment for a role

!   A work product is a tangible item that results from a task

•  An object model •  A class diagram •  A piece of source code •  A document •  …


Task

* Work

Activity

Project Function «invariant»

duration = project.duration


Work Products, Work Packages, and Roles

!   Work Package: A description of the work products to be produced, the resource needed, duration (expected), work produces and dependencies

produced-by *

Task

* Work

Activity

Project Function Project Deliverable Internal Work Product

Work Product Set of Work Products

Outcome *

Work Package describes


Example: Let‘s Build a House

What are the activities that are needed to build a house?


What is the problem?

!   Your boss: “How long will this take?” !   You: “Between 1 and 6 months.” !   People are not happy when you respond that way.

•  You figure out that finishing anytime before six months will meet your promise.

•  Your boss figures that with some hard work you can be done in a month!

!   In reality, you don’t have the slightest clue how long it will take, because you don’t know the work to be done.

!   Solution: Use divide and conquer •  To give a good answer you have to break the work down into

activities for which you can get good timing estimates •  From these estimates you compute the estimated project duration


Activities to obtain good time estimates

!   Identify the work that needs to be done •  Work breakdown structure (WBS)

!   Identify the dependency between work units •  Dependency Graph

!   Estimate the duration of the work to be done •  Schedule


Typical activities when building a house

!   Surveying !   Excavation !   Request Permits !   Buy Material !   Lay foundation !   Build Outside Wall !   Install Exterior Plumbing !   Install Exterior Electrical !   Install Interior Plumbing !   Install Interior Electrical

!   Install Wallboard !   Paint Interior !   Install Interior Doors !   Install Floor !   Install Roof !   Install Exterior Doors !   Paint Exterior !   Install Exterior Siding !   Buy Pizza

Finding these activities is a brainstorming activity. It is requires similar activities used during analysis (use case modeling)


Hierarchical organization of the activities

! Building the house consists of •  Prepare the building site •  Building the Exterior •  Building the Interior

! Preparing the building site consists of •  Surveying •  Excavation •  Buying of material •  Laying of the foundation •  Requesting permits


Partial Work Breakdown Structure

Build Foundation

Build Walls

Build Roof

Install Heating

Build Structure

Install PlumbingBuild House:WBS

Install Sewer Pipes

Install Cold & HotWater Pipes

Install Tubs & Sinks

Install Electric


From the WBS to the Dependency Graph

!   The work breakdown structure does not show any temporal dependence among the activities/tasks

•  Can we excavate before getting the permit? •  How much time does the whole project need if I know the

individual times? •  What can be done in parallel?

•  Are there any critical actitivites, that can slow down the project significantly?

!   Temporal dependencies are shown in the dependency graph

•  Nodes are activities •  Lines represent temporal dependencies


Building a House (Dependency Graph)

START!

Request !

Survey!ing!!

Excava!tion!

Buy !Material! Founda!

tion!!

Build !Outside !

Wall!

Install !Exterior !Plumbing!

Install !Interior !Plumbing!

Install !Exterior !Electrical!

Install !Interior !

Electrical!

Install !Exterior !

Siding!

Install !Wallboard!

Paint !Exterior!

Install !Roofing!

Install!!Flooring!

Paint !Interior!

!

Install !Interior !Doors!

Install !Exterior !

Doors!

FINISH!

The activity „Buy Material“ must Precede the activity

„Lay foundation“

Lay !


Building a House (PERT Chart)

Duration!

Start Time!

Slack Time!

Each Activity has a start time and an estimated duration

START!

8/27/94!

0!0!

Request !Permits!

8/27/94!

15!0!

Survey!ing!!

8/27/94!

3!12!

Excava!tion!

9/17/94!

10!0!

Legend!8/29/94!

0!

Buy !Material!

10/1/94!

10!0!

Lay !Founda!tion!!!!

10/15/94!

15!0!

Build !Outside !

Wall!

11/5/94!

20!0!

Install !Exterior !Plumbing!

12/3/94!

10!12!

Install !Interior !Plumbing!

12/3/94!

12!0!

Install !Exterior !Electrical!

12/17/94!

10!12!

Install !Interior !

Electrical!

12/21/94!

15!0!

Install !Exterior !

Siding!

12/31/94!

8!12!

Install !Wallboard!

1/11/95!

9!0!

Paint !Exterior!

1/12/95!

5!12!

Install !Roofing!

1/19/95!

9!12!

Install!!Flooring!

1/22/95!

18!0!

Paint !Interior!

!

1/22/95!

11!0!

Install !Interior !Doors!

2/8/95!

7!0!

Install !Exterior !

Doors!

1/19/95!

6!15!

FINISH!

2/16/95!

0!0!

0!


Storage subsystemsystem analysis1Nov 13

5dNov 19

Storage subsystemobject design2Nov 20

5dNov 26

Storage subsystemtest plan5Nov 27

10dDec 10

Storage subsystemimplementation3Nov 27

15dDec 17


Model of a Project from a project manager’s point of view.

*

Resource

Participant

Fund

Equipment

Schedule

Task

*

Activity

con-

Facility

*

Staff

Department Team

produces

Work Set of Work

*

Product Products

*

Internal Project

Work

respon-

sumes

Package

Role

*

des-

*

cribes

Deliverable

sible plays for

Organi- zation

Structure

* *

depends

Work Product Project Function

Project

Outcome Work Organizational

Unit

Work Breakdown


2.7 Project Agreement,Problem Statement vs SPMP

Manager Project TeamClient(Sponsor)

Problem Statement

Project Agreement

Software ProjectManagement Plan


Project Agreement

!   Document written for a client that defines: •  the scope, duration, cost and deliverables for the project. •  the exact items, quantities, delivery dates, delivery location.

!   Client: Individual or organization that specifies the requirements and accepts the project deliverables.

!   Can be a contract, a statement of work, a business plan, or a project charter.

!   Deliverables (= Work Products that will be delivered to the client:

•  Documents •  Demonstrations of function •  Demonstration of nonfunctional requirements •  Demonstrations of subsystems


Software Project Management Plan Template

!   0. Front Matter !   1. Introduction !   2. Project Organization !   3. Managerial Process !   4. Technical Process !   5. Work Elements, Schedule, Budget !   Optional Inclusions


IEEE Std 1058: Standard for Software Project Management Plans (SPMP)

! What it does: •  Specifies the format and contents of software project

management plans. •  It provides a standard set of abstractions for a

project manager or a whole organization to build its set of practices and procedures for developing software project management plans

•  Abstractions: Project, Function, Activities, Tasks

! What it does not do: •  It does not specify the procedures or techniques to

be used in the development of the plan •  It does not provide examples .


3. Project Management Activities


3.1 Four Management Activities

!   Planning the Project !   Organizing the Project !   Controlling the Project !   Terminating the Project


3.2 Planning the Project

Problem Statement

Top-level Design

Organization

Task Model

Schedule

Requirements Analysis Document (RAD)

System Design Document (SDD)

Software Project Management Plan (SPMP)

Project Agreement

Project Planning Products Deliverables


(1) Developing the problem statement

!   Developing the problem statement •  the current situations •  the functionality it should support •  environment in which the system will be deployed •  deliverables, delivery dates and a set of acceptance

criteria •  constraints on the development environment

!   Mutual understanding of the problem !   Roles: Project Manager, Client


(2) Defining the top-level design

!   Describe Software architecture of the system !   Subsystem definition based on high level

function decomposition !   Roles: Software architect


(3) Identifying the WBS

!   Decomposition Approach •  Functional decomposition based on the software

process •  Functional decomposition based on the functions of

the product itself •  Function decomposition based on Geographical

areas •  …

Develop

UserInterface

Control

Database Develop Database

Subsystem

Develop Control

Subsystem decomposition Work Breakdown Structure

UserInterface Subsystem

Develop System


(4) Creating the initial schedule

!   Temporal Dependencies are established in the task model

!   Task Duration Estimation !   Schedule creation


3.3 Organizing the Project

!   Setting up the communication infrastructure •  Schedule Modes •  Event-based modes

!   Identifying skills •  Application domain skills •  Communication skills •  Technical skills •  Quality skills •  Management skills


!   Assigning management roles !   Assigning technical roles !   Dealing with skill shortages !   Selecting team sizes !   Assembling the teams !   Kick-off meeting !   Agreeing on project scope


3.4 Controlling the Project

!   Decision making relying on collecting accurate status information

•  Meetings •  Sharp milestones •  Project reviews •  Code inspections •  Prototype demonstration


!   Metrics •  Financial status •  Technical progress •  Stability •  Modularity •  Maturity


!   Managing risks •  Possible problems

Detail Designand

Development

100

25

50

75

Conceptual-Preliminary

Design

Constructionand/or

ProductionSystem Use, Phaseout,

and Disposal

NEED

% Commitment to Technology,Configuration, Performance, Cost, etc.

Cost Incurred

System-Specific Knowledge

Ease of Change

“If you don’t actively attack the risks, the risks will actively attack you.”

Tom Gilb, 1988


Checklists!Decision driver analysis!

Assumption analysis!Decomposition!

Performance models!Cost models!

Network analysis!Decision analysis!

Quality factor analysis!

Risk exposure!Risk leverage!

Compound risk reduction!

Buying information!Risk avoidance!

Risk transfer!Risk reduction!

Risk element planning!Risk plan integration!

Prototypes!Simulations!Benchmarks!

Analyses!Staffing!

Milestone tracking!Top-10 tracking!

Risk reassessment!Corrective action!

Risk !Resolution!

Risk !Assessment!

Risk !Control!

Risk !Identification!

Risk !Analysis!

Risk !Prioritization!

Risk mgmt!Planning!

Risk !Management!

Risk !Monitoring!


The Top Ten Software Risk Items Risk Item! Risk Management Techniques!

1. Personnel Shortfalls! Staffing with top talent; key personnel!agreements; incentives; team-building; training; !

tailoring process to skill mix; peer reviews!

2. Unrealistic schedules! and budgets!

4. Requirements mismatch;! gold plating!

5. User interface mismatch!

Business case analysis; design to cost; incremental!development; software reuse; requirements descoping; !

adding more budget and schedule!

Stakeholder win-win negotiation; business case!analysis; mission analysis; ops-concept formulation; !

user surveys; prototyping; early users’ manual;!design/develop to cost!

Prototyping; scenarios; user characterization !(functionality, style, workload)!

3. COTS; external components! Qualification testing; benchmarking; prototyping; reference checking; compatibility analysis; vendor

analysis; evolution support analysis!


7. Requirements changes!

9. Externally-performed! tasks!

6. Architecture, performance,! quality!

10. Straining Computer! Science capabilities!

High change threshold; information!hiding; incremental development (defer !

changes to later increments)!

Reference checking; pre-award audits;!award-fee contracts; competitive design!

or prototyping; team-building!

Architecture tradeoff analysis and review boards;!simulation; benchmarking; modeling; prototyping; !

instrumentation; tuning!

Technical analysis; cost-benefit analysis;!prototyping; reference checking!

8. Legacy software! Design recovery; phaseout options analysis;!wrappers/mediators; restructuring!


Project Top 10 Risk Item List: Satellite Experiment Software

Risk Item Mo. Ranking

This Last #Mo. Risk Resolution Progress Replacing Sensor-Control Software 1 4 2 Top Replacement Candidate Unavailable Developer Target Hardware Delivery Delays 2 5 2 Procurement Procedural Delays Sensor Data Formats Undefined 3 3 3 Action Items to Software, Sensor Teams;

Due Next Month Staffing of Design V&V Team 4 2 3 Key Reviewers Committed; Need Fault-

Tolerance Reviewer Software Fault-Tolerance May 5 1 3 Fault Tolerance Prototype Successful Compromise Performance Accommodate Changes in Data 6 - 1 Meeting Scheduled With Data Bus Bus Design Designers Testbed Interface Definitions 7 8 3 Some Delays in Action Items; Review

Meeting Scheduled User Interface Uncertainties 8 6 3 User Interface Prototype Successful TBDs In Experiment Operational - 7 3 TBDs Resolved Concept Uncertainties In Reusable - 9 3 Required Design Changes Small, Monitoring Software Successfully Made


3.5 Terminating the Project

!   Accepting the system •  The presentation of the system and the approval of

the client according to acceptance criteria set forth in the Project Agreement

!   Installation •  It includes the field test of the system, the

comparison of the system results with the legacy system, the rollout of the legacy system, and the training of users

!   Postmortem •  Each project provides a chance for learning


4. Project Organizations


4.1 Team-based Organization

Team Participant Organization * *

UserInterface :Team

Database :Team

Control :Team

Management :Team

Simple Project :Organization


4.2 Relationships between Roles

!   Organizations can have many different types of associations between roles

!   The three most important associations for project organizations are: Reporting, decision making and communicating

!   Reporting association: •  Used for reporting status information

!   Decision association •  Used for propagating decisions

!   Communication association •  Used for exchanging information needed for decisions (e.g.,

requirements, design models, issues).


!   The developers make local decisions and reports them via a status report to the leader (team leader, project manager)

!   The team leader, who has a local overview of the subsystem, can override these decisions. She reports them to the project manager.

!   The project manager, who has a global view of the project, can virtually override any decision.

UserInterface:SubsystemTeam Database

:SubsystemTeam

Control:SubsystemTeam

decision

status

decision

status

Management:Team


!   Developers communicate with each other without having to communicate with the team leader or project leader.

!   Developers make local decisions and report them to the leader •  The team leader, who has a local overview of the subsystem, can

override these decisions. She reports them to the project manager. •  The project manager, who has a global view of the project, can virtually

override any decision.

UserInterface:SubsystemTeam

reports to

reports to

Database:SubsystemTeam

Control:SubsystemTeam

reports to

reports to

reports to

Management:Team

Documentation:CrossFunctionalTeam

Architecture:CrossFunctionalTeam

communicates with communicates with

communicates with communicates with


Types of roles found in a software engineering project.

Configuration Document Editor

Tester

Application Solution

End User

API Engineer

Client

Liaison

Consultant

Manager Team Leader

Project Manager Role

Developer

Manager

Domain Specialist Domain Specialist


4.3 Hierarchical Organization

!   Often also called centralized organization. Examples: Military, church, traditional businesses.

!   Key property: The organization has a tree structure. Decisions are made at the root and communicated to the leaf nodes. The decision association is also used for reporting and communication.

!   Advantages: •  Centralized control over project selection •  One set of management and reporting procedures for all project

participants across all projects •  Established working relationships among people •  Clearly established lines of authority to set priorities and resolved

conflicts •  Authority to pressure people to honor their action items •  Clearly defined career path


Chief Executive

First Level Manager (“Front-Line Manager”)

Project Members

Basis of organization: Complicated information and control flow

across hierarchical boundaries

A B

A wants to talk to B: Complicated Information Flow

Control Flow Information Flow

B wants to make sure A does a certain change: Complicated Controlflow


Example of a Hierarchical Organization: Chief Programmer Team [Brooks 1995]

Chief Programmer

Librarian Administration Tester

Junior Programmer

Assistant Chief Programmer

Senior Programmer


Disadvantages of Hierarchical Organizations

!   Slow response time •  The process of evaluating and approving change requests

often takes too long because of long reporting/decision lines.

!   Difficult to manage the workload of the people: •  People are assigned fulltime to the organization, but projects

don’t’ come in a smooth stream. •  Project request might not require the people who are available

or their expertise.

!   Unfamiliarity with application or solution domain area •  People are usually hired for their technical proficiency in a

specialty that the organization normally performs. •  They often have only limited experience, if the problem to be

solved is outside of their field of expertise.


4.3 Nonhierarchical Organizations

!   Key property: The organization has a general graph structure with different edges for the decision, reporting and communication flows. Decisions can be made at various nodes in the graph.


Nonhierarchical Project Organization

Project Leader

Coaches

Team Members

Basis of organization: Nonlinear information flow across dynamically formed units

Subsystem Team Subsystem Team Subsystem Team

A B

B wants to make sure A does a certain change: Decision Flow A wants to talk to B: Communication Flow


A Nonhierarchical Organization: Egoless Programming [Weinberg 1971]

Analyst

Designer Librarian

Tester Programmer


5. Communications


5.1 Communication is important

•  In large system development efforts, you will spend more time communicating than coding

•  A software engineer needs to learn the so-called soft skills: technical writing, reading documentation, communication, collaboration, management, presentations.


5.2 Definitions

Communication event !   Type of information exchange that has defined objectives and

scope !   Scheduled: Planned communication (e.g., review, meeting) !   Unscheduled: Event-driven communication (e.g., request for

change, issue clarification, problem report)

Communication mechanism !   Tool or procedure that can be used to transmit information !   Synchronous: Sender and receiver are available at the same time !   Asynchronous: Sender and Receiver are not communicating at the

same time.


Classification of Communication

is supported by [M to N association]

* *

Synchronous Mechanism [pull]

Asynchronous Mechanism [push]

Communication Mechanism

Unplanned Event

[unexpected]

Planned Event

[expected]

Communication Event

[ ‘*’ implies an indefinite number >= 0 of instances at the near association end may correspond to a single

instance at the far end]


Planned Communication Events

Problem Presentation •  Objective: Present goals, requirements and constraints •  Example: Client Presentation •  Usually scheduled at the beginning of a project.

Project Review: Focus on system model •  Objective: Assess status of, and review, system model, system

decomposition, and subsystem interfaces •  Examples: Analysis Review, System Design Review •  Scheduled around project milestones and deliverables

Client Review: Focus on requirements •  Objective: Brief client, agree on requirements changes •  Client Review •  Usually scheduled after analysis phase


Status Review •  Objective: Find deviations from schedule and correct them or

identify new issues •  Example: Status section in regular weekly team meeting •  Scheduled every week •  [Fine-grain task progress data enables schedule corrections.]

Brainstorming •  Objective: Generate and evaluate large number of solutions for

a problem •  Example: Discussion section in regular weekly team meeting •  Scheduled every week


Release •  Objective: Baseline the result of each software development

activity •  Software Project Management Plan (SPMP) •  Requirements Analysis Document (RAD) •  System Design Document (SDD) •  Object Design Document (ODD) •  Test Manual (TM) •  User Manual (UM) •  Usually scheduled after each phase

Postmortem Review •  Objective: Describe Lessons Learned •  Scheduled at the end of the project


Unplanned Communication Events

Request for clarification •  The bulk of communication among developers, clients and users. •  Example: A developer may request a clarification about an ambiguous

sentence in the problem statement.

Request for change •  A participant reports a problem and proposes a solution •  Change requests are often formalized when the project size is

substantial. •  Example: A participant reports of a problem the air conditioner in the

lecture room and suggests a change. •  [Example: Computer equipment does not fit through the access way to

its installation point. Repackaging or disassembly is required.]

Issue resolution •  Selects a single solution to a problem for which several solutions have

been proposed. •  Uses issue base to collect problems and proposals


Example of Request for Clarification

From: Alice

Newsgroups: cs413.architecture.discuss

Subject: SDD

Date: Thu, 10 Oct 23:12:48 -0400

Message-ID: <[email protected]>

MimeVersion: 1.0

Content-Type: text/plain; charset=us-ascii

When exactly would you like the System Design Document? There is some confusion over the actual deadline: the schedule claims it to be October 22, while the template says we have until November 7.

Thanks,

Alice


Example of a Change Request

Report number: 1291

Date: 5/3

Author: Dave

Synopsis: The STARS client crashes when empty forms are submitted.

Subsystem: User interface

Version: 3.4.1

Classification: missing/incorrect functionality, convention violation, bug, documentation error

Severity: severe, moderate, annoying

Description: <<Description of the problem>>

Rationale: <<Why the change should be done>>

Proposed solution: <<Description of desired change>>


Example of Issue Base


Synchronous Communication Mechanisms

Smoke signals •  Supports: ?, Pros: ?, Cons: ?

Hallway conversation (face-to-face) •  Supports: Unplanned conversations, Request for clarification,

request for change •  Pro: Cheap and effective for resolving simple problems •  Con: Important information can be lost, misunderstandings can

occur when conversation is relayed to others. Meeting (face-to-face, telephone, video conference)

•  Supports: Planned conversations, client review, project review, status review, brainstorming, issue resolution

•  Pro: Effective mechanism for resolution of issues, and building consensus

•  Con: High cost (people, resources); difficulty of managing them and getting effective results


Meeting Roles

!   Primary facilitator •  Responsible for organizing the meeting and guiding the

execution. •  Writes the agenda describing objective and scope of meeting. •  Distribute the agenda to the meeting participants

!   Minute taker •  Responsible for recording the meeting. •  Identifies action items and issues •  Release them to the participants

!   Time keeper •  Responsible for keeping track of time

[Distribute Assigned Action Item Responsibilities before departure; print cc from a laptop to expedite this.]


Structure of a Meeting Agenda


Asynchronous Communication Mechanisms

E-Mail •  Supports: Release, change request, brainstorming •  Pro: Ideal for planned communication events and announcements. •  Con: E-mail taken out of context can be easily misunderstood, sent to

the wrong person, lost or not read by the receiver. [E.g. D Frankel to ADTF]

Newsgroups •  Supports: Release, change request, brainstorming •  Pro: Suited for notification and discussion among people who share a

common interest; cheap (shareware available) •  Con: Primitive access control (often, you are either in or out)

World Wide Web •  Supports: Release, change request, inspections •  Pro: Provide the user with a hypertext metaphor: Documents contain

links to other documents. •  Con: Does not easily support rapidly evolving documents


Lotus Notes •  Each user sees the information space as a set of databases,

containing documents composed of a set of fields. Users collaborate by creating, sharing and modifying documents

•  Supports: Release, change request, brainstorming •  Pro: Provides excellent access control mechanisms and

replication of databases. •  Con: Proprietary format, expensive


Example: Document Review with Lotus Notes

!   Use cases: •  Fill out a review form •  Attach document to be reviewed •  Distribute the review form to reviewers •  Wait for comments from reviewers •  Review comments •  Create action items from selected comments •  Revise document and post the revised version •  Iterate the review cycle

!   The following example demonstrates a document review database from JAMES project.


Review of Documents

Database


Fill out the Review Form

!   Select reviewers !   Select the document to be reviewed !   Add comments to reviewers !   Determine deadline


Reviewer Notification

!   Selected reviewers get e-mail


Reviewers add their

Comments


Originator Notification


Final Recipient Notification


Review Tasks

!   Editor reviews comments !   Editor selects reviewed comments !   Web Master posts reviewed document and

action items !   Team members complete their action items !   Editor integrates changes !   Editor posts changed document on the review

database for the next review cycle


Accepted Document w/ Action Items


SPMP Action Items


6. Software Life Cycle Model


!   A software life cycle model represents all the activities and work products necessary to develop a software system


Requirements Process

System Allocation Process

Project Initiation Process

Concept Exploration

Process

Design Process

Implementation Process

Installation Process

Operation & Support Process

Verification & Validation

Process

The waterfall model of software development is an activity-centered view of the software life cycle.


System Requirements

Analysis

Implementation

Preliminary Design

Detailed Design

Software Requirements

Elicitation

Operation

Client Acceptance

Requirements Analysis

Unit Test

System Integration

& Test

Component Integration

& Test

V-Model of software

development.

Software Engineering Boehm’s spiral model (Adapted from [Boehm, 1987]).

Determine objectives,alternatives, & constraints

Evaluate alternatives,identify & resolve risks

Develop & verifynext level productPlan next phase

Requirements

Development

Integration

plan

plan

plan

Requirements

Design

validation

validation

Software SystemProduct

Riskanalysis

Riskanalysis

Prototype1Prototype2

Prototype3

Riskanalysis

Concept ofoperation

RequirementsDesign

Code

Unit Test

Integration & TestAcceptance

DetailedDesign

P1

P2

Test


Workflows in the unified software life cycle used by Royce.

*

releases

*

Design

Requirements

Implementation

Deployment

Unified Process Software Life Cycle

Management

*

Environment

Assessment

Workflow

Artifact Iteration Transition

Construction

Inception

Elaboration Phase 4

Cycle *

Product


States of a Software System called phases in the Unified Process.

Inception Elaboration

Construction Transition


The seven workflows in the Unified Process.

Implementat ion Workf low

Management Workf low

Requirements Workf low

Design Workflow

Deployment Workf low

Incept ion E laborat ion Const ruct ionTrans i t ion

Assessment Workf low

Environment Workf low

Time

Iter.#1 Iter.#2 Iter.#1 Iter.#2 Iter.#3 Iter.#1 Iter.#2 Iter.#1 Iter.#2


Capability Maturity Model (CMM)

!   CMM was developed at the Software Engineering Institute (SEI) at Carnegie-Melon University in Pittsburgh, PA, funded largely by the U.S. Defense Department.

!   CMM is design to measure, and thereby improve, the process of software development.

!   SEI establishes standards; it does not perform evaluations of individual firms.

!   Evaluations of firms are done by third parties; these third-party evaluators have varying degrees of expertise and creditability.

!   The highest level of CMM is Level Five; less than a hundred organizations in the world are certified as Level Five.

!   CMM is similar to ISO 9000 and 9001; but while CMM focuses primarily on improving performance, ISO 9000 and 9001 focus on establishing and maintaining careful documentation, procedures, and standards.


What are the Five Levels of CMM? 1.   Initial – poorly controlled; ad hoc; difficult to repeat successful

activities; dependent upon the skills of the individual developers 2.   Repeatable – disciplined processes; can repeat successful

activities and tasks; developers learn from each other 3.   Defined – standard, consistent processes; a database of

development “best practices” is created and maintained; these “best practice” are readily available and understood

4.   Managed – all development activities follow these corporate “best practices”; compliance with these development standards is mandatory

5.   Optimizing – continuous process of seeking out best practices from around the world; active, continuous improvement


Summary

!   Software development as a Project !   Project Management is a modern approach to

coordinate complex task teams !   There are different Software Life Cycle Models

with different characteristics.

Thanks

[email protected]

•  Some materials come from Bernd Bruegge’s PPT, others from Internet

•  csis.pace.e