Software EngineeringSoftware Engineering

Project Management

ObjectivesObjectives

1. To summarize the software engineering life cycle and a simple object oriented process

2. To introduce the role of project management

3. To discuss the management of technical people

Analysis SummaryAnalysis Summary

analysis design code test

Process Model Output

1. Elicit customer requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model (structural)

Conceptual Class Diagram

4. Build an object-behaviour model (dynamic)

Interaction and State Diagrams

Design SummaryDesign Summary

analysis design code test

Process Model Output

1. Subsystem Design: partition the system into components

A Package Diagram

2. Class and Object Design: define class hierarchies

Specification Class Diagram

3. Message Design: convert the object-relationship model into a set of class messages

Message Descriptions

4. Responsibility Design: specify the internal structure of classes

Specification Class Diagram with full attribute and method syntax

C++ Class Headers

Testing SummaryTesting Summary

analysis design code test

Process Technique

1. Class Testing: test methods and state behaviour of classes

Random, Partition and White-Box Tests

2. Integration Testing: test the interaction of sets of classes

Random and Behavioural Testing

3. Validation Testing: test whether customer requirements are satisfied

Use-case based black box and Acceptance tests

4. System Testing: test the behaviour of the system as part of a larger environment

Recovery, security, stress and performance tests

Project ManagementProject Management

An umbrella activity.

Planning, organizing, controlling and monitoring software development.

Elements of Project Management (the 4 P’s): Product (the software to be built)

Process (the set of framework activities and software engineering tasks to get the job done)

People (the most important element of a successful project)

Project (all work required to make the product a reality)

Tightly interrelated (each depends on the other)

Project Management ConcernsProject Management Concerns

staffing?

cost estimation?

project scheduling?

project monitoring?other resources?

customer communication?

risk assessment?

product quality?

measurement??

Product ManagementProduct Management

Need sufficient initial information to plan the project. Part of System Engineering and early Requirements

Analysis. Establish Scope:

a narrative that bounds the problem. Context (How does the software to be built fit into a larger system,

product or business context and what constraints are imposed as a result of the context?)

Information Objectives (What customer visible data objects are input and output?)

Function and performance (What function does the software perform in transforming inputs to outputs. Special performance characteristics?)

decompose problem: establishes an initial functional partitioning

Process ManagementProcess Management

The project manager must decide which process model (linear, prototyping, RAD, spiral, component-based) is most appropriate for:

1. the customers and practitioners

2. the characteristics of the product

3. the project environment in which the software team works

Melding the Product and Process: the product functions are listed (vertical) against the process tasks

(horizontal).

Each cell holds resource requirements, estimated start and end dates and work products.

Melding Problem and ProcessMelding Problem and Process.

Software Engineering Tasks

plan

ning

risk

anal

ysis

engi

neer

ing

Product Functions

Text input

Editing and formating

Automatic copy edit

Page layout capability

Automatic indexing and TOC

File management

Document production

cust

omer

com

mun

icat

ion

COMMON PROCESSFRAMEWORK ACTIVITIES

Process

Activities

People ManagementPeople Management

Management in major technology companies rightly believes that people are the key to success: CIO1: “I guess if you had to pick one thing out that is most important

in our environment, I’d say it’s not the tools that we use, it’s the people”.

CIO2: “The most important ingredient that was successful on this project was having smart people...very little else matters in my opinion”.

CIO3: “The only rule I have in management is to ensure that I have good people – real good people – and that I grow good people – and that I provide an environment in which good people can produce”.

But their actions often contradict this belief.

Good management is more than just free coffee.

The PlayersThe Players

Senior Managers: define the business issues that have significant influence on the project

Project (Technical) Managers: responsible for planning, motivating, organizing and controlling the practitioners who do software work.

Practitioners: deliver the technical skills that are necessary to engineer a product or application.

Customers: specify the requirements of the software being engineered.

End-Users: interact with the system once it is released for production use.

Team StructuresTeam Structures

Democratic Decentralized (DD): No permanent leader, appointed for short duration. Decisions on problems and approach are made by group consensus. Little control and horizontal communication.

Controlled Decentralized (CD): A defined leader who co-ordinates specific tasks. Problem solving is a group activity but implementation of solutions is partitioned among subgroups. Control is vertical and communication is horizontal

Controlled Centralized (CC): Top-level problem solving and internal team coordination are managed by a team leader. Control is hierarchical and communication is vertical. Early example – the “Chief Programmer” structure.

What about Democratic Centralized (DC)?

Issues in Choosing Team StructureIssues in Choosing Team Structure

The following factors must be considered when selecting a software project team structure:1. the difficulty of the problem to be solved

2. the size of the resultant program(s) in lines of code or function points

3. the time that the team will stay together (team lifetime)

4. the degree to which the problem can be modularized

5. the required quality and reliability of the system to be built

6. the rigidity of the delivery date

7. the degree of sociability (communication) required for the project

Exercise: Which Team Structure?Exercise: Which Team Structure?

What team structure would you choose if you had been appointed as a project manager for:1. A small software products company. Task: build a breakthrough

product that combines virtual reality hardware with state of the art software. Because competition for the home entertainment market is intense, there is significant pressure to get the job done.

2. A company that services the genetic engineering world. Task: manage the development of a new software product that will accelerate the pace of gene typing. The work is R&D oriented, but must produce a product within the year.

3. An information systems organization. Task: build an application that is quite similar to others your team has built, although this one is larger and more complex. Requirements have been thoroughly documented by the customer.

Team Structure SolutionsTeam Structure Solutions

There are no absolutes in dealing with people.

Centralized: Fast. Works for simple well-defined problems. Scales well, since performance of teams is inversely proportional to amount of communication.

Decentralized: More and better solutions. Works for difficult problems. Not good for modular problems.

Democratic: leads to higher morale and job satisfaction

Answers:

1. Controlled Decentralized

2. Democratic Decentralized

3. Controlled Centralized

JellingJelling

Jell: In business any group assigned to work together is termed a

“team” but they often don’t have a common definition of success or a team spirit

An effective tightly knit group displays Jell or “Esprit de Corps”. “Once a team begins to jell, the probability of success goes way up. The team can become unstoppable, a juggernaut for success”.

Team Toxicity (factors that work against jelling):1. A frenzied work atmosphere (which wastes energy and lacks

focus)

2. High frustration caused by personal, business, or technological factors that cause friction among team members.

3. Fragmented or poorly coordinated procedures.

4. Unclear definition of roles resulting in a lack of accountability.

5. Morale damaged by continuous and repeated failure.

Coordination and CommunicationCoordination and Communication

Project coordination techniques can be categorized as:

1. Formal, impersonal approaches (software engineering documents and deliverables, technical memos, project milestones, repository data)

2. Formal, interpersonal procedures (status review meetings, design and code inspections)

3. Informal, interpersonal procedures (group meetings and problem solving)

4. Electronic communication (e-mail, electronic bulletin boards)

5. Interpersonal networking (informal “tea break” discussions)

Value and Use of CoordinationValue and Use of Coordination

Use

Value

Line of Equal Use and ValueDiscussion with Peers

Documents

Milestones

Code Inspections

Project Bulletins

Data from a rating study of 65 projects

Source Code

E-mail

Group Meetings

Requirements Review

Design Review

Formal Impersonal

Formal Interpersonal

Informal Interpersonal

Collocation

Electronic Comm.

Interpersonal Network

Project ManagementProject Management

The high-level activities needed to co-ordinate different aspects of the project. The driving mechanism.

A difficult juggling act:

• size

• delivery deadline

• budgets and costs

• application domain

• technology to be implemented

• system constraints

• user requirements

• available resources

Why Projects FailWhy Projects Fail

An unrealistic deadline is established

Changing customer requirements or technology

An honest underestimate of effort

Predictable and/or unpredictable risks

Technical difficulties

Miscommunication among project staff

The project team lacks people with appropriate skills

Failure in project management

W5HH PrinciplesW5HH Principles

There are certain questions which need to be asked in creating an initial project management plan: Why is the system being developed?(i.e. Does the business purpose

justify the expenditure of people, time and money?)

What will be done? By when? (Helps with a project schedule and milestones)

Who is responsible for a function? (roles and responsibilities for team members)

Where are they organizationally located? (customers and users also have responsibilities)

How will the job be done technically and managerially? (a management and technical strategy is needed)

How much of each resource (e.g., people, software, tools, database) will be needed? (need to estimate project metrics)

Critical PracticesCritical Practices

U.S. Department of Defense developed a list of practices considered critical by successful software organizations: Formal risk analysis. What are the top ten risks for this project? For

each, what is the chance of occurrence and impact?

Empirical cost and schedule estimation. Current estimated size of application software and delivery date.

Metrics-based project management. Need to have in place a metrics program as an early warning system.

Earned value tracking. Each task given a budgeted cost (in person days). Keep track of progress towards the total.

Defect tracking against quality targets. Are the number of open and closed defects tracked from project inception?

People aware project management. Staff turnover.