3 project organization and management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
3. Project Organization and Management PowerPoint Presentation
Download Presentation
3. Project Organization and Management

Loading in 2 Seconds...

play fullscreen
1 / 166

3. Project Organization and Management - PowerPoint PPT Presentation


  • 224 Views
  • Uploaded on

3. Project Organization and Management. O utline. A n 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '3. Project Organization and Management' - bebe


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
o utline
Outline
  • An Overview of Project
  • An Overview of Project Management
  • Project Management Activities
  • Project Organizations
  • Project Communications
  • Software Life Cycle Model
1 1 what is a 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 p roject a ttributes
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
slide6

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?
2 1 history 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
objectives
Objectives
  • To introduce software project management and to describe its distinctive characteristics
  • To discuss project planning and the planning process
  • To show how graphical schedule representations are used by project management
  • To discuss the notion of risks and the risk management process
2 2 the triple constraint of project management
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?
slide12

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

Successful project management means meeting all three goals (scope, time, and cost) – and satisfying the project’s sponsor!

software project management
Software project management
  • Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software
  • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software
software management distinctions
Software management distinctions
  • The product is intangible
  • The product is uniquely flexible
  • Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc.
  • The software development process is not standardised
  • Many software projects are 'one-off' projects
2 5 management activities in a software project

Project Agreement

Project Kick-off

Formulate Idea

Problem Statement

Initial Software

Definition

Architecture

Team assembly

Infrastructure setup

2.5 Management activities in a software project

Conception

Cost-Benefit Analysis

Feasibility Study

Definition

Initial Software

Project Management Plan

Start

Skill

Identification

slide19

Steady state

Controlling

Risk management

Project replanning

Scope agreement

Termination

Client acceptance

test

Installation

Postmortem

management activities
Management activities
  • Proposal writing
  • Project planning and scheduling
  • Project costing
  • Project monitoring and reviews
  • Personnel selection and evaluation
  • Report writing and presentations
management commonalities
Management commonalities
  • These activities are not peculiar to software management
  • Many techniques of engineering project management are equally applicable to software project management
  • Technically complex engineering systems tend to suffer from the same problems as software systems
2 6 tasks and work products
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
slide23

Work

*

Task

Activity

«invariant»

duration = project.duration

Project Function

work products work packages and roles
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

Work Package

describes

produced-by

*

*

Outcome

Work

*

Set of Work Products

Work Product

Task

Activity

Internal Work Product

Project Deliverable

Project Function

example let s build a house
Example: Let‘sBuild a House

Whataretheactivitiesthatareneededtobuild a house?

what is the problem
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
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

Typicalactivitieswhenbuilding a house

Findingtheseactivitiesisa brainstormingactivity.

Itrequiressimilaractivitiesusedduringanalysis (usecasemodeling)

hierarchical organization of the activities
Hierarchicalorganizationoftheactivities
  • Buildingthehouseconsistsof
    • Preparethebuildingsite
    • BuildingtheExterior
    • BuildingtheInterior
  • Preparingthebuildingsiteconsistsof
    • Surveying
    • Excavation
    • Buyingof material
    • Layingofthefoundation
    • Requestingpermits
from the wbs to the dependency graph
Fromthe WBS totheDependency Graph
  • The work breakdown structuredoes not showany temporal dependenceamongtheactivities/tasks
    • Can weexcavatebeforegettingthepermit?
    • Howmuch time doesthewholeprojectneedif I knowthe individual times?
      • Whatcanbedone in parallel?
    • Are thereanycriticalactitivites, thatcanslow down theprojectsignificantly?
  • Temporal dependenciesareshown in thedependencygraph
    • Nodes areactivities
    • Lines represent temporal dependencies
building a house dependency graph

The activity

„Buy Material“ must

Precedetheactivity

„Lay foundation“

Building a House (Dependency Graph)

Install

Install

Install

Interior

Interior

Wallboard

Plumbing

Electrical

Paint

Interior

Install

Interior

Install

Doors

Flooring

Lay

Build

Excava

Buy

Survey

START

FINISH

Founda

Outside

tion

Material

ing

tion

Wall

Install

Roofing

Install

Exterior

Doors

Request

Paint

Exterior

Install

Install

Install

Exterior

Exterior

Exterior

Siding

Electrical

Plumbing

building a house pert chart
Building a House (PERT Chart)

12/3/94

12/21/94

1/11/95

Each Activity has a start time and an estimated duration

Install

Install

Install

Interior

Interior

Wallboard

Plumbing

Electrical

1/22/95

0

0

0

12

15

9

Paint

Interior

0

2/8/95

11

Install

1/22/95

Interior

Install

Doors

Flooring

0

7

10/15/94

11/5/94

9/17/94

10/1/94

2/16/95

8/27/94

8/27/94

0

Lay

Build

18

Excava

Buy

Survey

START

1/19/95

FINISH

Founda

Outside

tion

Material

ing

tion

Wall

Install

1/19/95

0

0

Roofing

0

0

12

0

0

10

0

10

Install

0

3

20

15

12

Exterior

9

Doors

8/27/94

15

1/12/95

Request

6

Permits

Paint

Exterior

0

15

12

5

12/31/94

12/17/94

12/3/94

Install

Install

Install

Start Time

8/29/94

Exterior

Exterior

Exterior

Siding

Legend

Electrical

Plumbing

12

12

12

Duration

0

8

10

10

Slack Time

0

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

Equipment

Project

*

Facility

Resource

Fund

*

Organi-

Work

zation

des-

Breakdown

Work

Structure

cribes

Schedule

Package

con-

*

*

sumes

*

*

produces

Organizational

respon-

Outcome

Work

Unit

sible

*

*

*

plays

for

depends

Role

Set of Work

Work

Staff

Activity

Task

Participant

Products

Product

Project

Internal

Department

Team

Project Function

Work Product

Deliverable

project agreement
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
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
IEEE Std 1058: Standard for Software Project Management Plans (SPMP)
  • Whatitdoes:
    • Specifiestheformatandcontentsofsoftwareprojectmanagementplans.
    • Itprovides a standardsetofabstractionsfor a projectmanageror a wholeorganizationtobuilditssetofpracticesandproceduresfordevelopingsoftwareprojectmanagementplans
    • Abstractions: Project, Function, Activities, Tasks
  • Whatitdoes not do:
    • Itdoes not specifytheproceduresortechniquestobeused in thedevelopmentofthe plan
    • Itdoes not provideexamples .
3 1 four 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

Software Project

Task Model

Management Plan (SPMP)

3.2 Planning the Project

Deliverables

Project Planning Products

Project Agreement

Requirements Analysis

Document (RAD)

System Design

Document (SDD)

Schedule

1 developing the problem statement
(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
(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
(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

Subsystem decomposition

Work Breakdown Structure

Develop

UserInterface

System

Develop Control

Develop

Subsystem

Control

UserInterface

Develop Database

Database

Subsystem

4 creating the initial schedule
(4) Creating the initial schedule
  • Temporal Dependencies are established in the task model
  • Task Duration Estimation
  • Schedule creation
3 3 organizing the project
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
slide48

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
3.4 Controlling the Project
  • Decision making relying on collecting accurate status information
    • Meetings
    • Sharp milestones
    • Project reviews
    • Code inspections
    • Prototype demonstration
slide50

Metrics

    • Financial status
    • Technical progress
    • Stability
    • Modularity
    • Maturity
risk management
Risk management
  • Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.
  • A risk is a probability that some adverse circumstance will occur.
    • Project risks affect schedule or resources
    • Product risks affect the quality or performance of the software being developed
    • Business risks affect the organisation developing or procuring the software
the risk management process
The risk management process
  • Risk identification
    • Identify project, product and business risks
  • Risk analysis
    • Assess the likelihood and consequences of these risks
  • Risk planning
    • Draw up plans to avoid or minimise the effects of the risk
  • Risk monitoring
    • Monitor the risks throughout the project
risk identification
Risk identification
  • Technology risks
  • People risks
  • Organisational risks
  • Requirements risks
  • Estimation risks
risk analysis
Risk analysis
  • Assess probability and seriousness of each risk
  • Probability may be very low, low, moderate, high or very high
  • Risk effects might be catastrophic, serious, tolerable or insignificant
risk planning
Risk planning
  • Consider each risk and develop a strategy to manage that risk
  • Avoidance strategies
    • The probability that the risk will arise is reduced
  • Minimisation strategies
    • The impact of the risk on the project or product will be reduced
  • Contingency plans
    • If the risk arises, contingency plans are plans to deal with that risk
risk monitoring
Risk monitoring
  • Assess each identified risks regularly to decide whether or not it is becoming less or more probable
  • Also assess whether the effects of the risk have changed
  • Each key risk should be discussed at management progress meetings
3 5 terminating the project
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
managing people
Managing people
  • People are an organisation’s most important assets.
  • The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful.
  • Poor people management is an important contributor to project failure.
people management factors
People management factors
  • Consistency
    • Team members should all be treated in a comparable way without favourites or discrimination.
  • Respect
    • Different team members have different skills and these differences should be respected.
  • Inclusion
    • Involve all team members and make sure that people’s views are considered.
  • Honesty
    • You should always be honest about what is going well and what is going badly in a project.
motivating people
Motivating people
  • An important role of a manager is to motivate the people working on a project.
  • Motivation means organizing the work and the working environment to encourage people to work effectively.
    • If people are not motivated, they will not be interested in the work they are doing. They will work slowly, be more likely to make mistakes and will not contribute to the broader goals of the team or the organization.
  • Motivation is a complex issue but it appears that their are different types of motivation based on:
    • Basic needs (e.g. food, sleep, etc.);
    • Personal needs (e.g. respect, self-esteem);
    • Social needs (e.g. to be accepted as part of a group).
need satisfaction
Need satisfaction
  • In software development groups, basic physiological and safety needs are not an issue.
  • Social
    • Provide communal facilities;
    • Allow informal communications e.g. via social networking
  • Esteem
    • Recognition of achievements;
    • Appropriate rewards.
  • Self-realization
    • Training - people want to learn more;
    • Responsibility.
individual motivation
Individual motivation

Alice is a software project manager working in a company that develops alarm systems. This company wishes to enter the growing market of assistive technology to help elderly and disabled people live independently. Alice has been asked to lead a team of 6 developers than can develop new products based around the company’s alarm technology.

Alice’s assistive technology project starts well. Good working relationships develop within the team and creative new ideas are developed. The team decides to develop a peer-to-peer messaging system using digital televisions linked to the alarm network for communications. However, some months into the project, Alice notices that Dorothy, a hardware design expert, starts coming into work late, the quality of her work deteriorates and, increasingly, that she does not appear to be communicating with other members of the team.

Alice talks about the problem informally with other team members to try to find out if Dorothy’s personal circumstances have changed, and if this might be affecting her work. They don’t know of anything, so Alice decides to talk with Dorothy to try to understand the problem.

individual motivation1
Individual motivation

After some initial denials that there is a problem, Dorothy admits that she has lost interest in the job. She expected that she would be able to develop and use her hardware interfacing skills. However, because of the product direction that has been chosen, she has little opportunity for this. Basically, she is working as a C programmer with other team members.

Although she admits that the work is challenging, she is concerned that she is not developing her interfacing skills. She is worried that finding a job that involves hardware interfacing will be difficult after this project. Because she does not want to upset the team by revealing that she is thinking about the next project, she has decided that it is best to minimize conversation with them.

personality types
Personality types
  • The needs hierarchy is almost certainly an over-simplification of motivation in practice.
  • Motivation should also take into account different personality types:
    • Task-oriented;
    • Self-oriented;
    • Interaction-oriented.
personality types1
Personality types
  • Task-oriented.
    • The motivation for doing the work is the work itself;
  • Self-oriented.
    • The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc.;
  • Interaction-oriented
    • The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work.
motivation balance
Motivation balance
  • Individual motivations are made up of elements of each class.
  • The balance can change depending on personal circumstances and external events.
  • However, people are not just motivated by personal factors but also by being part of a group and culture.
  • People go to work because they are motivated by the people that they work with.
teamwork
Teamwork
  • Most software engineering is a group activity
    • The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone.
  • A good group is cohesive and has a team spirit. The people involved are motivated by the success of the group as well as by their own personal goals.
  • Group interaction is a key determinant of group performance.
  • Flexibility in group composition is limited
    • Managers must do the best they can with available people.
group cohesiveness
Group cohesiveness
  • In a cohesive group, members consider the group to be more important than any individual in it.
  • The advantages of a cohesive group are:
    • Group quality standards can be developed by the group members.
    • Team members learn from each other and get to know each other’s work; Inhibitions caused by ignorance are reduced.
    • Knowledge is shared. Continuity can be maintained if a group member leaves.
    • Refactoring and continual improvement is encouraged. Group members work collectively to deliver high quality results and fix problems, irrespective of the individuals who originally created the design or program.
the effectiveness of a team
The effectiveness of a team
  • The people in the group
    • You need a mix of people in a project group as software development involves diverse activities such as negotiating with clients, programming, testing and documentation.
  • The group organization
    • A group should be organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected.
  • Technical and managerial communications
    • Good communications between group members, and between the software engineering team and other project stakeholders, is essential.
selecting group members
Selecting group members
  • A manager or team leader’s job is to create a cohesive group and organize their group so that they can work together effectively.
  • This involves creating a group with the right balance of technical skills and personalities, and organizing that group so that the members work together effectively.
assembling a team
Assembling a team
  • May not be possible to appoint the ideal people to work on a project
    • Project budget may not allow for the use of highly-paid staff;
    • Staff with the appropriate experience may not be available;
    • An organisation may wish to develop employee skills on a software project.
  • Managers have to work within these constraints especially when there are shortages of trained staff.
group composition
Group composition
  • Group composed of members who share the same motivation can be problematic
    • Task-oriented - everyone wants to do their own thing;
    • Self-oriented - everyone wants to be the boss;
    • Interaction-oriented - too much chatting, not enough work.
  • An effective group has a balance of all types.
  • This can be difficult to achieve software engineers are often task-oriented.
  • Interaction-oriented people are very important as they can detect and defuse tensions that arise.
group composition1
Groupcomposition

In creating a group for assistive technology development, Alice is aware of the importance of selecting members with complementary personalities. When interviewing potential group members, she tried to assess whether they were task-oriented, self-oriented, or interaction-oriented. She felt that she was primarily a self-oriented type because she considered the project to be a way of getting noticed by senior management and possibly promoted. She therefore looked for one or perhaps two interaction-oriented personalities, with task-oriented individuals to complete the team. The final assessment that she arrived at was:

Alice—self-oriented

Brian—task-oriented

Bob—task-oriented

Carol—interaction-oriented

Dorothy—self-oriented

Ed—interaction-oriented

Fred—task-oriented

group organization
Group organization
  • The way that a group is organized affects the decisions that are made by that group, the ways that information is exchanged and the interactions between the development group and external project stakeholders.
    • Key questions include:
      • Should the project manager be the technical leader of the group?
      • Who will be involved in making critical technical decisions, and how will these be made?
      • How will interactions with external stakeholders and senior company management be handled?
      • How can groups integrate people who are not co-located?
      • How can knowledge be shared across the group?
group organization1
Group organization
  • Small software engineering groups are usually organised informally without a rigid structure.
  • For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.
  • Agile development is always based around an informal group on the principle that formal structure inhibits information exchange
informal groups
Informal groups
  • The group acts as a whole and comes to a consensus on decisions affecting the system.
  • The group leader serves as the external interface of the group but does not allocate specific work items.
  • Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience.
  • This approach is successful for groups where all members are experienced and competent.
5 1 communication is important
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
5.2 Definitions

Communication event

  • Type of information exchange that has defined objectives and scope

Communication mechanism

  • Tool or procedure that can be used to transmit information
group communications
Group communications
  • Good communications are essential for effective group working.
  • Information must be exchanged on the status of work, design decisions and changes to previous decisions.
  • Good communications also strengthens group cohesion as it promotes understanding.
group communications1
Group communications
  • Group size
    • The larger the group, the harder it is for people to communicate with other group members.
  • Group structure
    • Communication is better in informally structured groups than in hierarchically structured groups.
  • Group composition
    • Communication is better when there are different personality types in a group and when groups are mixed rather than single sex.
  • The physical work environment
    • Good workplace organisation can help encourage communications.
key points
Key points
  • People are motivated by interaction with other people, the recognition of management and their peers, and by being given opportunities for personal development.
  • Software development groups should be fairly small and cohesive. The key factors that influence the effectiveness of a group are the people in that group, the way that it is organized and the communication between group members.
  • Communications within a group are influenced by factors such as the status of group members, the size of the group, the gender composition of the group, personalities and available communication channels.
definitions
Definitions
  • Software lifecycle modeling: Attempt to deal with complexity and change
  • Software lifecycle:
    • Set of activities and their relationships to each other to support the development of a software system
  • Software development methodology:
    • A collection of techniques for building models - applied across the software lifecycle
software life cycle
Software Life Cycle
  • Software construction goes through a progression of states

Adulthood

Conception

Childhood

Retirement

Post- Development

Pre- Development

Development

typical software lifecycle questions
Typical Software Lifecycle Questions
  • Which activities should I select for the software project?
  • What are the dependencies between activities?
    • Does system design depend on analysis? Does analysis depend on design?
  • How should I schedule the activities?
    • Should analysis precede design?
    • Can analysis and design be done in parallel?
    • Should they be done iteratively?
possible identification of software development activities

Requirements Analysis

What is the solution?

System Design

What are the mechanismsthat best implement the

solution?

Program Design

How is the solutionconstructed?

Program Implementation

Is the problem solved?

Testing

Can the customer use the solution?

Delivery

Are enhancements needed?

Maintenance

Possible Identification of Software Development Activities

What is the problem?

Problem

Domain

Implementation

Domain

alternative identification of software development activities

Requirements Analysis

What is the problem?

System Design

What is the solution?

What is the solution in the context

of an existing hardware system?

Object Design

Implementation

How is the solution constructed?

Alternative Identification of Software Development Activities

Problem

Domain

Implementation

Domain

software development as application domain simple object model

Software Development

Object Design

Document

Problem Statement

Test Manual

Requirements Analysis

Document

Executable system

System Design

Document

Software Development as Application Domain: Simple Object Model
ieee std 1074 standard for software lifecycle
IEEE Std 1074: Standard for Software Lifecycle

Process Group

IEEE Std 1074

Develop-

ment

Pre-

Development

Project

Management

Post-

Development

Cross-

Development

(Integral Processes)

> Project Initiation

>Project Monitoring

&Control

> Software Quality

Management

> Requirements

Analysis

> Design

> Implemen-

tation

> V & V

> Configuration

Management

> Documen-

tation

> Training

> Installation

> Operation &

Support

> Maintenance

> Retirement

> Concept

Exploration

> System

Allocation

Processes

life cycle model variations on a theme
Life-Cycle Model: Variations on a Theme
  • Many models have been proposed to deal with the problems of defining activities and associating them with each other
  • The waterfall model
    • First described by Royce in 1970
  • There seem to be at least as many versions as there are authorities - perhaps more
problems with waterfall model
Problems with Waterfall Model
  • Managers love waterfall models:
    • Nice milestones
    • No need to look back (linear system), one activity at a time
    • Easy to check progress : 90% coded, 20% tested
  • Different stakeholders need different abstractions
    • => V-Model
  • Software development is iterative
    • During design problems with requirements are identified
    • During coding, design and requirement problems are found
    • During testing, coding, design& requirement errors are found
    • => Spiral Model
  • System development is a nonlinear activity
    • => Issue-Based Model
v model distinguishes between development and verification activities

Client’s Understanding

Developer’s Understanding

Problem with V-Model:

Client’s Perception is the same as the

Developer’s Perception

V Model: Distinguishes between Development and Verification Activities

Level of Detail

Requirements

Elicitation

Acceptance

Testing

Low

System

Testing

Analysis

Design

Integration Testing

Object Design

Unit Testing

High

Project Time

sawtooth model
Sawtooth Model

Client’s Understanding

Developer’s Understanding

sharktooth model
Sharktooth Model

User’s Understanding

Manager’s Understanding

Developer’s Understanding

problems with v model
Problems with V Model
  • The V model and its variants do not distinguish temporal and logical dependencies, but fold them into one type of association
  • In particular, the V model does not model iteration
spiral model boehm deals with iteration
Spiral Model (Boehm) Deals with Iteration
  • Identify risks
  • Assign priorities to risks
  • Develop a series of prototypes for the identified risks starting with the highest risk.
  • Use a waterfall model for each prototype development (“cycle”)
  • If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round
  • If a certain risk cannot be resolved, terminate the project immediately
capability maturity model cmm
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.
s ummary
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.
topics
Topics
  • Project plan development
  • Project scheduling
  • Project budget estimation
  • Tracking project progress
    • Tracking the schedule
    • Tracking the budget
the theme
The theme
  • Management aspect of the software engineering:
    • software project planning and tracking
    • software process management
  • Software project planning and tracking is an ongoing activity of estimating how much time, money, effort and resources need to be expended for the project. It includes:
    • not only scheduling, budgeting and tracking,
    • but also multi-project issues of
      • risk analysis,
      • quality assurance,
      • people management and
      • configuration management.
  • Software project planning continues from strategic planning and business modeling
project plan development
Project plan development
  • Project planning is an ongoing “umbrella” activity spanning the lifecycle phases
planning documents
Planning documents
  • Budget/schedule (cost/time) plan is but one of several planning documents
  • Other documents may include
    • quality plan,
    • test plan,
    • people development plan,
    • configuration management plan, etc.
  • These may be separate documents or parts of a comprehensive project plan document
sections in a typical project plan
Sections in a typical project plan
  • Introduction (objectives, constraints)
  • Project organization
  • Risk analysis
  • Hardware and software resource requirements
  • Work breakdown (activities, milestones and deliverables)
  • Project schedule (time and resources)
  • Monitoring and reporting mechanisms
steps in project planning
Steps in project planning
  • Define objectives, scope and constraints
  • Define deliverables - software products or services that meet project objectives
  • Define milestones, phases and tasks
    • milestone – a significant event in the project (can represent the completion of a deliverable or a phase)
    • task - activity with clear beginning and end
  • Estimate resource needs
    • Resources are people, equipment, materials, supplies, software, hardware, etc. required by project tasks
  • Establish the project team
  • Determine quality standards
    • quality product is a product that satisfies the user
  • Determine project risks (adverse events)
    • risk avoidance strategies and contingency plans
steps in project planning1
Steps in project planning
  • Establish team communications
    • consider technology solutions (workgroup, time management, etc.)
  • Define the schedule
    • includes also allocation of resources to tasks
  • Define the budget
    • estimation of costs required by resources needed for tasks
  • Write project plan document
  • Track project progress
    • and revise project plan
project scheduling
Project scheduling
  • Building time schedules assumes that the work breakdown structure and the task list are known
    • Tasks are activities with clear start and end days, ideally of between one day and two weeks duration
  • Project scheduling is a moving target
  • Critical path is any sequence of linked tasks in the project that must be done on time for the project to finish by the deadline
    • Slippage (delay) in any task on a critical path will result in the project missing the deadline
    • Tasks that are not on a critical path can afford delays (they have slack time)
tasks milestones and deliverables
Tasks, milestones and deliverables
  • Tasks can be hierarchically organized in multiple levels of subtasks
    • Each task is assigned duration (in hours, days, or weeks)
    • Task at the top of hierarchy is known as summary task
    • Subtask is any task that is a part of the summary task or a part of any higher-level subtask
    • Recurring task is a task that repeats at regular time intervals (e.g. every day, once per week)
  • Schedule can be constructed
    • forward (from the project’s start date) or
    • backward (from the project’s end date)
  • Schedule reflects the project calendar
  • Milestone is a task that results in a significant event or outcome
    • it is customary to create milestones as separate tasks with zero duration
  • Milestone can represent a deliverable
task scheduling in bar chart
Task scheduling in bar chart
  • Task dependencies occur between two or more linked tasks
    • Unlinked tasks are considered to have no dependencies so that they can be conducted in parallel
  • There are two main kinds of task dependencies:
    • task dependencies based on the work organization
    • task dependencies due to competing for the same resources (discussed a bit later)
  • Categories of predecessor-to-successor dependencies:
    • finish-to-start (FS) – successor task cannot start until predecessor task is finished
    • start-to-start (SS) – successor task cannot start until predecessor task is started
    • finish-to-finish (FF) – successor task cannot finish until predecessor task is finished
    • start-to-finish (SF) – successor task cannot finish until predecessor task is started
other predecessor to successor dependencies
Other predecessor-to-successor dependencies
  • Delay dependencies in which a lag time is introduced between the predecessor and successor tasks
    • For example, a lag time of three days is specified if the successor task can start only after three days of completion of the predecessor task
  • Overlap dependencies in which a lead time exists between the predecessor and successor tasks
    • This allows the successor task to start before the predecessor task is finished
  • Lag and lead times can be specified
    • in absolute values (e.g. +3 days for lag time or -2 days for lead time)
    • as percentages of the predecessor task duration
task scheduling in gantt chart
Task scheduling in Gantt chart

no dependency

overlap

delay

scheduling constraints
Scheduling constraints
  • As Soon As Possible (ASAP)
    • task will be scheduled as soon as possible subject to dependencies on predecessor tasks and subject to availability of resources
  • As Late As Possible (ALAP)
    • allows the task to obtain maximum input from earlier tasks before it starts
    • allows establishing how much a task can be delayed without delaying the project finish date (i.e. without extending the project’s critical path).
  • Inflexible constraints
    • Must Finish On (MFO)
    • Must Start On (MSO)
    • Finish No Earlier Than (FNET) – inflexible for projects scheduled from the finish date
    • Finish No Later Than (FNLT) – inflexible for projects scheduled from the start date
    • Start No Earlier Than (SNET) – inflexible for projects scheduled from the finish date
    • Start No Later Than (SNLT) – inflexible for projects scheduled from the start date
resources and resource calendars
Resources and resource calendars
  • Resources can be broadly classified into
    • work resources – people and equipment, including hardware and software
    • material resources – consumables and supplies
  • Resource definition includes
    • giving the name to a resource,
    • specifying its type, and
    • indicating the number of resource units available for the work resource
  • Tracking function
    • track the amount of work performed by people and equipment
    • monitor the use of materials
effort driven scheduling in bar chart
Effort-driven scheduling in bar chart
  • Assignment of resources to tasks is based on the maximum number of working time that a resource can offer
    • time is determined from maximum available number of resource units and any constraints in the resource calendar
    • if the work assigned to the resource exceeds the resource daily availability, then such resource is over allocated
  • The approach to scheduling where the duration of tasks can change (up or down) as resources are added or removed from tasks is known as effort-driven scheduling
  • In this approach, the effort required to complete a task remains unchanged, but the duration of the task can change.
methods of budget estimation
Methods of budget estimation
  • Expert judgment
  • Estimation by analogy
  • Schedule-driven budget estimation
    • bottom-up methods, which consider tasks and resources allocated in the project schedule prepared earlier
  • Algorithmic budget estimation
    • some estimated software size metric is used to derive the cost
schedule driven budget estimation
Schedule-driven budget estimation
  • Schedule-driven budget estimation assumes that there exists a prior schedule with resources allocated to tasks
    • this is called the baseline schedule or plan
    • project management tool can maintain multiple baselines and separate budget estimations for each baseline.
  • Seems easy:
    • resources are assigned to tasks in the baseline
    • assign costs to resources
    • add overhead and other fixed costs, and
    • make the project management tool to compute the budget for the project
  • The devil is in the detail:
    • resources can accrue costs at various times during the task duration
    • rates and fixed costs can differ in different time periods
    • there may be some legal rules affecting pay rates and costs
    • accounting principles can affect calculation, etc.
assigning rates and other costs to resources
Assigning rates and other costs to resources
  • standard rates
  • overtime rates
  • per-use rates (set cost for the use of a resource)
cost accrual methods
Cost accrual methods
  • Accrual can be
    • at the start of a task,
    • at the end of a task, or
    • prorated (as worked).
algorithmic budget estimation
Algorithmic budget estimation
  • Algorithmic models use empirically derived formulas to estimate cost of human resources (effort) as a function of the project size.
  • The size can be expressed in
    • lines of code (LOC)
      • the number of thousands (K) of non-comment source statements in the program (KLOC)
    • function points (FP)
      • computed by decomposing software across five features (inputs, outputs, data files, inquiries, and external interfaces) and calculating the number of these features while adjusting the calculation depending on the features’ perceived complexity
    • object points (OP)
      • similar to FP but applying to different features (user interface screens, software reports, and software components)
      • calculation is adjusted to remove reused object points  this leads to the measure called new object points (NOP).
nominal form of algorithmic estimation
Nominal form of algorithmic estimation

effort = c * sizek

  • The exponent k reflects the complexity of the problem and the non-proportional increase of effort in larger projects (typically in the range from 1 to 1.5)
  • The multiplier c is another scaling factor of project difficulty based on assessments of attributes such as required product reliability, skills of the team, available software tools, etc.
  • COCOMO (COnstructive COst MOdel)
    • COCOMO 81
    • COCOMO II
cocomo 81
COCOMO 81
  • Basic (or organic) COCOMO:

effort = 3.2 * size1.05

  • Intermediate (or semidetached) COCOMO – this mode includes a set of cost drivers to scale the nominal development effort based on assessments of product, hardware, personnel, and project attributes:

effort = 3.0 * size1.12

  • Advanced (or embedded) COCOMO – this mode builds up on the intermediate version but uses cost drivers to assess their impact on each phase of the development lifecycle:

effort = 2.8 * size1.20

  • For example, using the basic COCOMO and assuming that the system will consist of 10,000 lines of code (10 KLOCs), the estimated effort expressed in person-months is:

effort = 3.2 * 1001.05 = 3.2 * 125.9 ≈ 403 person-months

cost drivers
Cost drivers
  • “product complexity” is a factor of 2.36 (1.65/0.70)
  • “analyst capability” is a factor of 2.06 (1.46/0.71)
  • “programmer capability” is a factor of 2.03 (1.42/0.70)
  • “required software reliability” is a factor of 1.87 (1.40/0.75)
  • “execution time constraints” is a factor of 1.66 (1.66/1.00)
  • “application experience” is a factor of 1.57 (1.29/0.82)
  • “use of modern programming practices” is a factor of 1.51 (1.24/0.82)
  • “programming language experience” is a factor of 1.20 (1.14/0.95)
cocomo ii
COCOMO II
  • COCOMO II consists of three different models corresponding to three successive phases of the project:
    • application composition model – used in early analysis phase or during early prototyping
    • early design model – used after requirements analysis is completed
    • post-architecture model – used after the software architecture design is known
application composition model
Application composition model
  • Uses weighted object points(OPs) for sizing information
    • OPs are counts of anticipated user interface screens, software reports, and software components
    • the OP count is reduced by the percentage of object points obtained by reuse, so that only new object points (NOPs) are considered for effort estimation.
  • The formula for NOPs is:

NOP = OP * [(100 - %reuse)/100]

  • Uses only two weighting factors to determine the development productivity level (capability)
    • the developers’ experience/capability and
    • the organization’s maturity/capability
  • The two factors are combined to determine five productivity levels (next slide)
productivity metrics in application composition model
Productivity metrics in application composition model
  • Associated with the five levels are productivity “cost drivers” expressed in terms of NOPs that the project team is capable of producing per month
calculating effort in application composition model
Calculating effort in application composition model
  • Once the productivity metric is chosen, the formula to calculate the effort in COCOMO II application composition model is:

effort = NOP/productivity

  • For example, if
    • the count of new object points is 500 and
    • the productivity is 4,
    • then the effort (in person-months) will be estimated at 125.
  • By contrast, if the productivity is 50, then the effort will be only 10 person-months.
early design model
Early design model

effort = c * sizek * m + autoeffort

  • constant coefficient c is set to 2.5
  • exponent k varies between 1.01 and 1.26
  • multiplier m expresses the influence of (seven) cost drivers on the estimated effort
    • each driver is assigned a value (the value of 1 means that the cost driver does not affect the estimation)
    • the value of m is the result of the multiplication of the seven numbers
  • autoeffort – effort put by developers in the automatic code generation and the integration of this code with the manually created programs

effort = 2.5 * 1001.15 * 1.3 + 35 = 2.5 * 199.5 * 1.3 ≈ 678 person-months

post architecture model
Post-architecture model
  • The sizing (lines of code) is adjusted from the early design model by considering two factors:
    • requirements volatility
    • extent of reuse
  • The estimation formula is the same as in the early design model
    • changes relate to the details of how the coefficients and terms are established
tracking project progress
Tracking project progress
  • Comparing the baseline and the actual :
    • the baseline schedule versus the actual schedule
    • the baseline budget versus the actual budget
  • Interim plans may also be created as checkpoints of project progress
  • Information (possibly conflicting) comes from two sources:
    • changes to the planned schedule
    • accounting system
  • Also, time tracking and cost tracking can bring up conflicting information:
    • project can be behind schedule but on or under budget
    • it can also be on or ahead of schedule but over budget
tracking gantt chart
Tracking Gantt chart
  • The lower bar represents the baseline task
  • The upper bar represents the actual task
    • colored to indicate if they are completed, not started yet, or completed in some percentage
  • Variance is the difference between the baseline and the actual
tracking the budget
Tracking the budget
  • Actual costs from schedule = budget tracking as a direct continuation of schedule tracking
    • tracking actual costs on tasks completed, or in progress, by applying resource rates, accrual methods, and any fixed costs
  • Actual costs from accounting
    • because actual costs reported by the accounting system may be different from the costs calculated from actual work performed
    • in some cases, the accounting system may be the only source of information of actual cost
  • Earned value analysis – one of the most useful methods that succinctly informs if the project is on budget
actual costs from accounting
Actual costs from accounting
  • Calculating actual costs from the schedule rarely gives true and final account of costs committed:
    • schedules are unlikely to include all resources consumed by tasks or even to include all tasks
    • the sluggishness of the accounting system can distort the real story
  • Some possible difficulties:
    • fixed cost for the task failed to be entered during scheduling
    • per-use cost charged for a work resource in addition to normal rate-based fees
  • Frequently, budget changes reported by the accounting system relate to non-human resources
earned value
Earned value
  • Earned value analysis = performance management = management by objectives
    • quantitative technique of determining if the project is on budget
    • uses the baseline estimate of the schedule and the actual progress to date to determine the completeness status (“completeness health”) of the project
    • conducted for individual tasks and for the whole project
    • can also be taken down to the level of resources within each task
    • can only be conducted if resources and their rate/costs have been assigned to tasks
      • from the quantitative point of view, a task without resources cannot have any work done and cannot have costs or earned value
earned value analysis
Earned value analysis

BCWS – Budgeted Cost of Work Scheduled

BCWP – Budgeted Cost of Work Performed

ACWP – Actual Cost of Work Performed

SV – Scheduled Variance (SV = BCWP – BCWS)

CV – Cost Variance (CV = BCWP – ACWP)

EAC – Estimate at Completion (equal to ACWP for tasks completed)

BAC – Budget at Completion (equal to BCWP for tasks completed)

VAC – Variance at Completion (VAC = BAC – EAC)

summary
Summary
  • Software project planning and tracking is an ongoing activity of estimating how much time, money, effort and resources need to be expended for the project
  • Scheduling is about estimation of time needed for the development and about allocation of resources to tasks
  • Budgeting is about estimation of costs required by resources needed for tasks
  • The approach to scheduling where the duration of tasks can change (up or down) as resources are added or removed from tasks is known as effort-driven scheduling
  • Schedule-driven budget estimation assumes that there exists a baseline schedule with resources allocated to tasks
  • Algorithmic budget estimation takes some measure (metric) of the size of the problem and applies on it an empirically obtained algorithm to arrive at the budget
  • Tracking project progress involves comparisons of: (1) the baseline schedule versus the actual schedule, and (2) the baseline budget versus the actual budget
  • Earned value analysis is a quantitative technique of determining if the project is on budget