Project Management

Chapter 5, PG 92

Introduction

Why is software management particularly difficult? The product is intangible

Cannot be seen or touched Managers cannot see progress

There are no standard software processes Processes vary drastically between different organizations

Large software projects are often “one-off” projects Changing technology can make managements experience

obsolete Lessons learned are not always transferable to new projects

Management Activities

Proposal writing Project Planning and Scheduling Project Cost Project Monitoring and Reviewing Personnel Selection and Evaluation Report Writing and Presentations

Management Activities (cont’d)

Settling for a less-than-ideal staff Project budget may not cover the use of

highly paid staff Staff with appropriate experience may

already be assigned to other projects Inexperienced staff may be assigned to a

project to lean and gain experience

Project Planning

Pseudo-code for the project planning process

Establish the project constraintsMake initial assessments of the project parametersDefine project milestones and deliverablesWhile project has not been completed or cancelled Loop

draw up project scheduleinitiate activities according to schedulewait ( for a while)review project progressrevise estimates of project parametersupdate the project schedulerenegotiate project constraints and deliverablesIf (problems arise) Then

initiate technical review and possible revisionEnd If

End Loop

Project Plan

Has the following parts: Introduction Project Organization Risk Analysis Hardware and Software Resource Requirements Work Breakdown Project Schedule Monitoring and Reporting Mechanisms

Project Planning - Introduction

The Introduction should provide a brief description of the objectives of the project

It will also set out constraints Time Budget Technology Others?

Project Plan – Project Organization

This area describes the way in which the development team is organized, the people involved, and their roles in the team

Things to consider Team Structure

Democratic Chief Programmer Model Modified Chief Programmer Hierarchical Model Others?

Project Plan – Risk Analysis

Describes possible project risks, likelihood of occurring, and possible ways to mitigate

Possible risks Staff turnover Management change Hardware unavailability Requirements change Specification delays Size underestimate CASE tool underperformance Technology change Product competition

Project Plan – Risk Analysis (cont’d)

Possible Risk Types Technology

Database cannot process enough requests as originally thought People

Illnesses, training for staff not available Organizational

Restructured organization, new management over project Tools

CASE Tools cannot be integrated, perform inefficiently Requirements

Changes to requirements Estimation

Time required to complete and early activity is extended or deadlines not met

Project Plan – HW/SW Resource Requirements

Specifies HW and support SW required to carry out the development

Possibilities Viso Visual Studio Dia Compiling programs CASE TOOLS

Project Plan – Work Breakdown

Sets out the breakdown of the project into activities and identifies milestones and deliverables with each activity

Milestone It might be a module Or a subsystem

Deliverables What all needs delivered to the client, upper-

level management, etc.

Project Plan – Project Schedule

This shows the dependencies between activities, estimated time for each, and person responsible for activity

Example: Requirements Elicitation Requirements Definitions Requirements Specification

Project Plan – Monitoring and Reporting Mechanisms

Defines management reports that should be produced, when they should be produces, and project monitoring mechanisms used

Example: Weekly report of progress to manager Check list of completed functionality

Project Plan Template

Due: February 1, 2007 11:00AM

Requirements Elicitation

Requirements Elicitation

Why is it important? What possible problems could arise?

Requirements Elicitation - Rules

Should provide a list of questions 24 -72 hours in advance This helps the client have time to be prepared for the

questions going to be asked and will speed up the process

No session should last more than 30-60 minutes After this timeframe, the clients attention is lost

Should provide a summary of the meeting within 24-72 hours after the meeting has taken place While fresh in everyone’s mind, problems or discrepancies

between what was said by the client and what was heard by the developers can probably be cleared up quickly

Exercise

Brainstorm on Coliseum Management System

Focus on: Scheduling Concessions Workers

Coliseum Management System

Now lets come up with questions we might ask a client that has asked us to develop this system.

Security

During the Design Phases

Security Problems

What are some ways to ensure security in a system?

What are the main principles we are trying to accomplish with security?

Security

Confidentiality Integrity Availability

Security

How can these items be addresses during design?

What are common security issues you see in systems you use everyday?

Are there ways to document in a design security concerns or issues?