© Copyright De Montfort University 2001 All Rights Reserved INFO3013 Systems Development Management 1 Module Objectives At the end of this module students

INFO3013 Systems Development Management

1© Copyright De Montfort University 2001 All Rights Reserved

Module Objectives

• At the end of this module students should:• Describe the major activities in software project management,• Prescribe organisational structures appropriate to software projects,• Understand the basic principles for planning and scheduling a project,• Define the basic mechanisms for project control,• Understand the principles of software risk management,• Develop an appropriate approach to software estimation,• Identify the principle issues involved in managing software reuse,• Understand the issues involved in team recruitment and management



Topics Covered

• Project Planning and Scheduling

• Project Control

• People Management

• Risk Management

• Software Estimation

• Reuse Management

• Requirements Control

© Copyright De Montfort University 2001 All Rights Reserved

What’s So Difficult about Software Management?



Nature of a Project

• Creates Change

• Has Composite Goals– Human, Technical, Structural

• Is Unique

• Is limited in time and scope

• Involves a variety of resources

• May be large or complex

• May involve several phases.



What’s special about software projects?

• Intangible

• Complex

• No standard processes

• More skill-dependent

• Often greater social effect

• Flexibility



Therefore..

• Greater chance of failure.

• Greater Uncertainty.

• Greater Chance of being affected by organisational change.

• ...



Problems with Software Projects

• Estimating!

• Measuring!

• Communicating!

• Negotiating!

• Resourcing!

• Marketing!

• Training!


The Project Manager’s Role



What is Management?

• Planning

• Organising

• Staffing

• Directing

• Monitoring

• Controlling

• Innovating

• Representing



The ProjectManager

persuasivecommunicator

effective plannertechnically competent

good project trainer organisationally powerful

effective manager ofteams

good controller

sensitive to the problemsof change



The Project Lifecycle

• Describe a typical project Lifecycle

• Where does software project management start?

• Where does it end?


Software Project Management Activities



Time Billing System

• You have been given the brief for the Time Billing System

• Consider– When problems do you envisage with this

project?– What questions would you ask?– What initial activities would you undertake as

project manager?



What Management Practice should be in place?

• Project Planning, Control and Tracking Methods

• Software Quality Management

• Software Configuration Management

• Quantitative Management

• Training.

– Consider the CMM ….



Software Capability Maturity Model• 1)Initial.

– The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

• 2) Repeatable.

– Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

• 3) Defined.

– The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

• 4) Managed.

– Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

• 5) Optimizing.

– Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.



Project Planning Activities

• Identify project scope and objectives

• Identify project infrastructure

• Analyse project characteristics

• Identify project products and activities

• Estimate effort for each activity

• Identify activity risks

• Allocate resources

• Review and publicize plan



Identify project scope and objectives

• Identify objectives and measures of effectiveness

• Establish a project authority

• Identify stakeholders in the project

• Modify objectives in light of stakeholder analysis

• Establish methods of communication



Identify project infrastructure

• Establish relationship between project and organisation

• Identify standards and procedures– Project planning and control– Configuration management– Quality

• Identify project team organisation



Analyse project characteristics

• Analyse nature of software product

• Identify high level project risks

• Take into account client’s standards and requirements

• Select lifecycle approach

• Review overall resource requirements



Identify project products and activities

• Identify and describe project products (product breakdown structure)

• Document generic product flow

• Recognise product instances

• Produce ideal activity network

• Modify to take into account need for stages and checkpoints



Estimate effort for each activity

• Carry out bottom up estimates

• Revise plans in light of estimates



Identify activity risks

• Identify and quantify activity-based risks

• Plan risk reduction and contingency measures

• Adjust plans and estimates to take account of risks



Allocate Resources

• Identify and allocate resources

• Revise plans and estimates to account for resource constraints



Review and Publicize Plan

• Review quality aspects of project plan

• Document plans and obtain agreement


Organisational Structures



Organisational Structure

• Organisational structure is required to enable:

– managerial control– technical control



Steering Committee

• Focuses on managerial control

• Receives details of project through reporting process



Steering Committee Membership

• Organisational board member• Finance• IT management• Project manager• Suppliers• Sub-project manager• Quality manager• Risk manager• Estimator



Contract Manager

Sub-project

Sub-contractors

Sub-project Sub-project

Project Manager

Steering Committee



Steering Group Agenda

• Project status• Changes to: Objectives• Scope• Risks• Benefits• Costs• Schedules• Staffing

• Actions taken / required• Responsibilities• Causes• Future issues



Managing Large Scale Projects

• Extra Work

• Education

• managing physical resources

• testing

• file conversion

• Problems

• Staffing - turnover

• Changes

• Organisational change

• intra-organisational co-ordination



Managing Large Scale Projects

• Delivery Strategies

• Monolithic

• version/release

• `evolutionary / fast track

• Project Culture

• technical

• ‘logo’

• marketing

• project induction

• ‘timeout’

• Managing stakeholders

• Negotiation

• reviews

• Briefing



= link persons

use of e-mail

Steering Committee

Sub-projects

Project Management



Large Projects

• Mandatory formal project management.

• Standard

• More detailed steering committee involvement.

• Project management 20-30% of development effort.

• Need for clerical support

• Essential use of project management tools


Activity Planning



Planning Goals

• Ensure appropriate resources will be ready when required;

• Avoid different activities competing for same resources;

• Produce detailed schedule showing which staff carry out which activity

• Produce detailed plan against which achievement can be measured,

• Produce timed cash flow forecast;

• Replan project during its lifer to correct drift from target.



Defining Activities

• Activities

– Have clearly defined start and end point– Require forecastable resources– Forecastable duration– May have precedence requirements



Identifying Activities

• Activity-based approach

– List all activities (brainstorm)– Sub-divide project– Create work breakdown structure– Create task catalogue



Identifying Activities

• Product Based Approach– Used in PRINCE2– Product Breakdown Structure– Product Flow Diagram– List of Activities identified from

transformations



Product Breakdown Structure

Project

QualityManagement Technical

Application OperationsEducation User

TestingDesign



Product Flow Diagram

ToR

AcceptanceCriteria

Requirements

Design

TestApplication /

Product

Education User

Release

System



The transition between product (s) involves numerous activities.

These activities, which have durations and dependencies, can be identifiedfrom the transitions between products at a detailed level from product flowswithin the product breakdown structure.

DESIGN

APPLICATION

program system

again, very highlevel



The activities can be listed:-

Ref Activity Description Duration(days)

Dependencies

05 Produce stage plans 310 Produce requirements 15 0520 Identify enhancements 5 1030 Produce acceptance criteria 5 05



The activities can then be ordered on a PERT activity network:

30

05

10 30



Activity Network

1 2 3 4 5 6 7 8 9 10

A

B

C

D

E

F

G

Technical Plan

3

4

4

3

2

2

1

B D

C

F

E

GA



Each activity becomes a box:-

EARLIEST START TIME DURATION EARLIEST FINISH TIME

REF ACTIVITY DESCRIPTION

LATEST START TIME TOTAL FLOAT LATEST FINISH TIME



Critical Path

• A line which passes through all activities which has zero float.



Resource Allocation

• We then need to allocate activities to resource (people) Technical Plan

• Resources allocated in order of float - activities with floats may have to wait.

• But we haven’t got unlimited resources

resource smoothing• move activities within their floats• change resource allocation



SSADM Version 4 Stage 3: Definition of Requirements

Step 310Define required

system processing

Step 380Assemble

requirementsspecification

Step 370Confirm system

objectives

Step 360Develop

processingspecification

Step 350Develop

specificationprototypes

Step 340Enhance required

data model

Step 330Derive system

functions

Step 320Develop required

data model

RJP/SSADM 3/PP

amend c l DFD toagree with BSO and LDS(this gives required system DFD)

use r.s . DFD to identifyupdate & enquiry functions

use r.s . DFD and LDM as inputs toentity/event modelling, creat ing ELHs,EAPs and ECDs

use r.s . DFD andLDM forreference

required systemLDM prepared

refer to r.s. LDM as necessary

validate andenhance LDMfrom RDA

update required system LDMas necessary

cross check LDM against allother products



Stage Description Analyst User Programmer Manager(days) (days) (days) (days)

310 Define required systemprocessing

3 1

320 Develop required data model 2330 Derive system functions 8 1 1340 Enhance required data model 4 2350 Develop specification

prototypes4 1 10 1

360 Develop processingspecification

8 1 1

370 Confirm system objectives 2 2 1380 Assemble requirements

specification2 1 1


Project Control



Project Control

• Monitoring and controlling the Project to ensure that it stays on course and reacts to unexpected events. Project control is the core of the Project Manager's effort on the project, handling the day-to-day management of the project.



Project Control Activities

• authorising work to be done

• gathering progress information about that work

• watching for changes

• reviewing the situation

• reporting

• taking any necessary corrective action.



THE CONTROL CYCLE

STAGEPRODUCT

QUALITYREVIEW

QUALITYPLANS

DATACAPTURE

CORRECTIVEACTION

IMPACTANALYSIS

PROJECTIONPROBLEMS

INTERPRETATION

REPORTING

REPLANNING

DEVELOPMENT



Report Type Examples CommentsOral formalregular

Weekly or monthlyprogress meetings

While report may be oral, formalwritten minutes should be kept

Oral formalad-hoc

End-of-stage reviewmeetings

Will generate written reports

Writtenformalregular

Job sheets, timesheets, progressreports

Weekly using forms

Writtenformal ad-hoc

Exception reports,change reports.

Oral informalad-hoc

Canteen discussion,Social interaction

Provides early warning



Visualising Progress

• Gantt Chart

• Slip Chart

• Ball Charts

• Timeline



Approaches to getting back on target

• Get more people

• Revise targets

• Revise deadline

• Cut quality

• Use alternative method (e.g. Rapid Application Development)


Software Risk Management



Risk Management is a Core Activity

• Software Management is about risk management– Maintaining a tolerance for uncertainty and

learning;– Expecting and reacting to changing context;– Structuring project management around risk

management;– Understanding the relationship of the project to

organisational risk (internal and external).



What is Risk Management?

• Risk:

– The possibility of suffering harm or loss, danger.



Risk is not bad

• Risk in itself is not bad; risk is essential to progress, and failure is often a key part of learning. But we must learn to balance the possible negative consequences of risk against the potential benefits of its associated opportunity."

• [Van Scoy, Roger L. Software Development Risk: Opportunity, Not Problem. Software Engineering Institute, CMU/SEI-92-TR-30, ADA 258743, September 1992]



A loss associated with the event

• Loss of time, quality,control, understanding– e.g. Requirements change

• Risk Impact



The likelihood that the event will occur

• Estimate probability that event will occur– e.g. New machine not delivered on time.

• Risk probability



The degree to which we can change the outcome

• Minimising effect of event occuring.

• Avoid the event occuring.

• Risk Control



Quantification

• Risk exposure =– Risk impact x risk probability



Risk Types

• Generic

• Project-specific

• Involuntary

• Voluntary



Risk Management Activities

• Risk Assessment– Risk Identification– Risk Analysis– Risk Prioritisation

• Risk Control– Risk reduction– Risk management planning– Risk resolution



Risk Identification

• Checklists

• Decomposition

• Assumption Analysis



Boehm’s Risk List

• Personnel shortfalls• Unrealistic schedules and budgets• Developing the wrong software functions• Developing the wrong user interface.• Gold plating• Continuing stream of requirement changes.• Shortfalls in externally furnished components.• Shortfalls in externally performed tasks.• Real time performance shortfalls• Straining computer science capabilities.



Risk Factors (Hughes and Cotterell)

• Application

• Staff

• Project

• Project Methods

• Hardware/Software

• Changeover

• Supplier

• Environment

• Health and Safety



MANAGEMENT

PROJECT

SYSTEM

Structure

Tasks

Technology

Actors

what is being done?

know-how and tools

communication,authority,systems of workflow

Structure

Tasks

Technology

Actors

Structure

Tasks

Technology

Actors



Risk Analysis

• Performance models

• Cost models

• Network Analysis

• Decision Analysis

• Quality Analysis



Risk Prioritisation

• Risk Exposure

• Compound risk reduction

– A priority scheme enables you to devote your resources only to the most threatening risks



Risk Reduction

• Hazard Prevention

• Likelihood reduction

• Risk reduction leverage

– Avoid the risk– Transfer the risk– Assume the risk



Risk Leverage

• (Risk exposure before reduction - risk exposure after reduction) / (cost of risk reduction)



Risk Management Planning

• Contingency Planning

• Risk element planning

• Risk plan integration



Risk Resolution

• Risk mitigation

• Risk Monitoring and reporting

• Risk reassessment



Improving Risk Management

• Use qualitative and well as quantitative Data• Collect your own historical data (Don’t rely on

other people’s)• Avoid false sense of objectivity• Quantify risk in a meaningful way• Take into account values, beliefs and bias• Look at risk throughout software development life

cycle



Seven Principles of Risk Management (SEI)

• Global perspective

– Viewing software development within the context of the larger systems-level definition, design, and development.

– Recognizing both the potential value of opportunity and the potential impact of adverse effects.

• Forward-looking view

– Thinking toward tomorrow, identifying uncertainties, anticipating potential outcomes.

– Managing project resources and activities while anticipating uncertainties.

• Open communication

– Encouraging free-flowing information at and between all project levels.

– Enabling formal, informal, and impromptu communication.

– Using processes that value the individual voice (bringing unique knowledge and insight to identifying and managing risk).



Seven Principles of Risk Management (SEI)

• Integrated management

– Making risk management an integral and vital part of project management.

– Adapting risk management methods and tools to a project's infrastructure and culture.

• Continuous process

– Sustaining constant vigilance and identifying and managing risks routinely through all phases of the project's life cycle.

• Shared product vision

– Mutual product vision based on common purpose, shared ownership, and collective communication and focusing on results.

• Teamwork

– Working cooperatively to achieve common goal.

– Pooling talents, skills, and knowledge.



Build your own management data

• Quality

• Estimation

• Risk Management


Software Effort Estimation



Why is Estimating So Difficult?

• Think of some things you have to estimate: Are you generally accurate? Are your estimates generally optimistic?

• People often underestimate times and distances. Why is this?

• Should we rely on people’s subjective estimates of programming tasks?

• Often accurate estimates of the size of a software project are so large as to be dismissed as unrealistic, or put the client off. Is there a compromise possible?



What are we trying to estimate?

• Staff resources Analysis

• Programming

• Documentation

• Management

• Computer resources

• Terminals

• Disk space requirements

• CPU time

• Overheads

• Support

• Meetings

• Performance assessment

• Project control systems



Properties of an Estimating Method

• Gives early guidance to the size of a project with an accuracy of +/- 30%,

• Should be easy to use,

• Should give consistent results,

• Uses agreed rules,

• Is supported by tools.



Who should do the estimating?

• Development Team

• Consultant Project Estimator

• Project Manager

• Customer

• Steering Committee



Approaches to Estimating

• Estimates made by an expert. An expert in the business field and the programming language provides estimates.

• Estimates made using reasoning by analogy. A similar type of project is examined and compare to the new project.

• Estimates based on price-to-win. The amount the client can afford is considered, and competitive bidders are undercut.

• Estimates based on available capacity. If we have limited staff resources then that may determine what we can do.

• Estimates based on use of parametric methods. Parametric methods use equations to derive estimate which contain constants derived from statistical studies of a large number of projects.



Software Cost Estimation ModelsSizer Stage

NOT BASED ON LINES OF CODE

ProductivityStage

Based on linesof code

Based onfunction points

Based onfunctionalprimitives

etc.



Function Point Analysis

• Count logical functions

– External inputs - screens

– External outputs - report

– Logical master files

– Enquiry transactions

– Interfaces to other applications



Multiply by weightings to obtainunadjusted function points

Type of Function Point WeightingSimple Average Complex

External Input 3 4 6External Output 4 5 7Logical Internal File 7 10 15External Interface File 5 7 10External Inquiry 3 4 6



Function Point Analysis

• Calculate processing complexity adjustment• Data communications Distributed functions

• Performance Heavily used configuration

• Transaction rate On-line data entry

• End-user efficiency On-line update

• Complex processing Re-usability

• Installation ease Operational ease

• Multiple sites Facilitate change

• Calculate adjusted function point measure



Productivity Estimating Methods

• Static Approaches

• A Static, single variable approach uses one constant (derived from previous studies) and makes no allowance for influencing factors:

L = Line of Code (previously estimated)

E = 1.4L 0.93 Effort (m months)

DOC = 30.4L 0.90 Documentation (# pages)

D = 4.6L 0.26 Duration (months)



• A Static, multivariable approach adds variables to represent the factors that can influence productivity:

• E = 5.22 0.91 D = 4.12 0.36

• I = Wi Xi

• Xi = -1,0,1



• A Dynamic, multivariable assumes that there are a finite number of problems, that each solved problem has an effect on others, and that a decision can remove unsolved problem. For example, once we’ve programmed one insert/amend/update program we can model the rest on it and produce them faster.

• Examples are the Norden / Rayleigh Manpower Distribution Model and the Putman Model for Software Development.



Object Points

• Number of separate screens

• Number of reports

• Number of 3GL modules needed to supplement 4GL code



COCOMO 2

• Early prototyping level– PM = (NOP x (1 - %reuse/100))/PROD

• Early design level– PM = A x Size B X M X PMm

• Post-architecture level



COCOMO2 Cost Drivers

• RELY: Required software reliability

• DATA: Database size

• CPLX: Product complexity

• DOCU Extent of documentation required

• RUSE Required percentage of reusable components

• TIME: Execution time constraint.

• STOR: Main storage constraint.

• PVOL: Volatility of development platform

• ACAP: Analyst capability.

• AEXP: Application experience.

• PCAP: Programmer capability

• PEXP Programmer experience in project domain

• LTEX Language and tool experience

• PCON Personnel continuity

• TOOL: Use of Software Tools

• SCED: Schedule Constraint.

• SITE Extent of multi-site working and quality of site communications



Cost Driver Very Low Low Nominal High Very High Extra HighRELY 0.75 0.88 1 1.15 1.4DATA 0.94 1 1.08 1.16CPLX 0.7 0.85 1 1.15 1.3 1.65STOR 1 1.11 1.3 1.66TIME 1 1.06 1.21 1.56PVOL 0.87 1 1.15 1.3ACAP 1.46 1.19 1 0.86 0.71AEXP 1.29 1.13 1 0.91 0.82PCAP 1.42 1.17 1 0.86 0.7PEXP 1.21 1.1 1 0.9LTEX 1.14 1.07 1 0.95SITE 1.24 1.1 1 0.91 0.82TOOL 1.24 1.1 1 0.91 0.83SCED 1.23 1.08 1 1.04 1.1


Software Reuse Management



Why Reuse?

• Cost saving

• Increased speed of development

• Increased reliability

• Increased quality

• Better standards compliance through componentisation.

• Reduced process risk



What to Reuse

• Specifications

• Design

• Class Definitions

• Source Code

• Data Structures.

– Reuse involves more that just some sub-routines



What Inhibits Reuse?

• Conflict with time and budget priorities• Developers do not know what is available to be

reused• ‘Not invented here’ syndrome• Reuse assets do not meet performance needs• Reuse across team boundaries raise coordination

and ownership issues• Version management problems



Traditional Approach to Reuse

• Centralised library

• Incentive scheme

• Lack of documentation– leads to reuse junkyard.

• Reuse must be senstive to the organisational culture and incentive-compatible



Dimensions of Reuse

• Organisational

• Reuse Production

• Reuse funding



Requirements

• Supporting tools

• Supporting metrics



Organisational Models

• Library - passive library of components, minimal certification.

• Curator - quality certification, marketing and component funding.

• Product Centre - identifies, acquires, stores components

• Expert Services - reuse experts loaned out.

• Team Producer - decentralised reuse teams

• Reuse factory - application teams just assemble components



Where should reuse be focussed?

• Pre-project domain analysis

• In project domain analysis

• In project generalisation

• Post-project generalisation

• Next project generalisation



Funding Models

• Overhead – pooled with other overheads

• Tax– flat reuse levy on all application projects e.g. %

of total project costs• Pay-for-components

– needs cost sharing bank• Activity-based costing

– charge according to degree of consumption



Reuse Process: Creating Reusable Assets

• Creating new assets

• Analysing existing systems

• Assessing proposed asset

• Verifying new asset

• Assessing technology trends



Using Reusable Assets

• Match Requirements with Reusable assets

• Building Products



Support Reusable Assets

• Certify new asset

• Gather reuse statistics and feedback

• Classify and version manage assets

• Train applications staff

• Answer reuse questions



Manage Reusable Assets

• Define reuse policy

• Deal with reuse conflicts

• Review new asset procurement and development proposals

• Obtain funding.

• Control funding, collect revenue, allocate reuse grants to teams.

• Market reuse



Reuse Points

• Reuse adds costs (11 -380% more to make a component reusable).

• Costs and risks of reuse consumption need to be shifted outside application projects.

• Reuse program must be compatible with software development culture and incentives.


People Management



Issues

• Groups and teams

• Motivation

• Use of Consultants

• Targets and overtime

• Recruitment

• Personality Types

• Business/ IT gap

• Appraisals



Team Members

• Driver

– Develops ideas innovates,

– Predicts future,

– Wants to see things changed.

• Planner

– Logical thinker

– Takes ‘required future’ turns it into actions that the team can do.

– Well-organised



Team Members

• Enabler

– Interested in personal values.

– ‘Sales’ person. Outgoing, persuasive.

• Executive

– Realists - turn action into results

– Want to get on and do it.

– What needs attention now

– Makes effort to assure that team works in harmony to get things done.

• Controller

– Analytical thinker

– Enjoys detail - like costs and benefits

– Spots errors

– Monitors progress

– Assesses against objectives



Appraisals

• Clarify Purpose

– promotion review

– training review

• Establish clear performance standards

– actual job responsibility

• Monitor performance and provide ongoing feedback

– use mini-appraisals

– proper supervision



Appraisals

• Conduct a written evaluation

– clear, unambiguous

– supported by examples

• Take time to do it

• Problems

– unclear standards

– lack of preparation

– no ongoing performance feedback

– lack of knowledge



Business/IT Gap

• Perceptions - users

• IT people earn large salaries.

• Projects fail.

• Slaves to methodology.

• Secret budgeting.

• Separate location.

• Technical / education.



Business / IT Gap

• Perceptions - IT

• Our systems are too good for you stupid users.

• We know what you need.

• Users can’t make their minds up.

• Users don’t understand technical difficulties.

• Is there any wonder there are communications problems?



People Capability Maturity Model• Level 2 Key Practices

Work Environment

Communication

Staffing

Performance Management

Training

Compensation

• Level 3 Key Practices

Knowledge and Skills Analysis

Work Force Planning

Competence Development

Career Development

Competence-Based Practices

Participatory Culture



People Capability Maturity Model


Mentoring

Team Building

Team-Based Practices

Organizational Competence Management

Organizational Performance Alignment


Personal Competence Development

Coaching

Continuous Work Force Innovation



The Human Factor

• Software engineering projects fail because of bad management rather than bad technology.

• "IT depends on people. It is a very skill - and - people intensive game, and if you lose your critical people there is no way you can make it" T Barber, ICI Paints.



The Human Factor

• Project managers do not understand users needs

• Project scope is ill-defined

• Project changes are managed poorly

• Chosen technology changes

• Business needs change

• Deadlines are unrealistic

• Users are resistant

• Sponsorship is lost

• Project lacks people with appropriate skills

• Managers ignore best practice and lessons learnt



Conclusions

• Software engineering project management IS software engineering risk management.

• Measurement is essential.

• Put people first.

• Consider reuse as a standard part of software engineering

Documents

© Copyright De Montfort University 2001 All Rights Reserved INFO3013 Systems Development Management 1 Module Objectives At the end of this module students