Project Management in Software Engineering, Lecture notes of Software Engineering

The challenges of project management in software engineering. It highlights the importance of planning, contingency planning, progress tracking, and final analysis. The document also explains the agile approach to project management and provides examples of time estimates. It also discusses project planning tools such as critical path method and Gantt charts. useful for students studying software engineering and project management.

Typology: Lecture notes

2021/2022

Uploaded on 05/11/2023

anahitay
anahitay 🇺🇸

4.7

(16)

255 documents

1 / 36

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Cornell'University!
Compu1ng'and'Informa1on'Science
CS#5150#So(ware#Engineering#
5.##Project#Management#
William#Y.#Arms
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24

Partial preview of the text

Download Project Management in Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity!

Cornell University

Compu1ng and Informa1on Science

CS 5150 So(ware Engineering

5. Project Management

William Y. Arms

Project Management: OS 360

The operaDng system for the IBM 360 was two years late.

Ques%on: How does a project get two years behind schedule?

Answer: One day at a Dme!

Fred Brooks Jr., The Mythical Man Month, 1972

The Challenge of Project Management

Clients wish to know:

Will the system do what was promised?

When will it be delivered? If late, how late?

How does the cost compare with the budget?

O@en the so@ware is part of a larger ac1vity

  • If the system is a product, markeDng and development must be combined

(e.g., Microso( Office)

  • If the system has to work with other systems, developments must be

coordinated (e.g., embedded systems in an automobile)

(con%nued on next slide)

The Challenge of Project Management (conDnued)

BUT:

Every so(ware system is different.

Most systems are not well specified, or the requirements change during

development.

EsDmaDng Dme and effort is full of errors, even when the system is well

understood.

Terminology

Deliverable

  • Work product that is provided to the client (mock-up, demonstraDon,

prototype, report, presentaDon, documentaDon, code, etc.)

  • Release of a system or subsystem to customers and users

Milestone

CompleDon of a specified set of acDviDes (e.g., delivery of a deliverable,

compleDon of a process step, end of a sprint)

Terminology

Ac1vity

Part of a project that takes place over Dme (also known as a task )

Event

The end of a group of acDviDes, e.g., agreement by all parDes on the

budget and plan

Dependency

An acDvity that cannot begin unDl some event is reached

Resource

Staff Dme, equipment, or other limited resource required by an acDvity

Agile Approach to Project Management

  • Planning is divided into high level release forecasDng and low level

detailed planning.

  • Release planning is a best guess, high level view of what can be achieved

in a sequence of Dme-boxes.

  • Release plans are conDnually modified, perhaps daily.
  • Clients and developers take joint control of the release plans and choice

of sprints.

  • For each Dme-box, the team plans what it can achieve. The team may use

Gan` charts or other convenDonal planning tools.

EsDmaDng the Time for an AcDvity

With experienced staff, esDmaDng the actual Dme to carry out a

single task is usually fairly accurate, but ...

The li`le bits and pieces are underesDmated.

  • The Dme from almost "done" to completely "done" is much longer than

anDcipated. (There's just one thing to %dy up. I need to put the comments

into beGer shape. I really should get rid of that patch.)

  • The distracDons are not planned for. (My system crashed and I decided to

upgrade the soIware. My child's school was closed because of snow. I

spent the day interviewing job candidates.)

  • Some things have to be done twice.

Team EsDmaDng

Agile approach to project management

  • (^) Different teams work at different speeds.
  • (^) The team has the best understanding of what it can achieve in a

single Dme-box or sprint.

  • (^) The team commits to the outcome of a sprint.

Within the Dme box, the team must have an internal schedule.

With your CS 5150 project, you will need to commit to the outcome

and have a schedule to manage your progress.

Start-up Time

On a big project, the start-up Dme is typically three to six months:

  • Personnel have to complete previous projects (faDgue) or be

recruited.

  • Hardware and so(ware has to be acquired and installed.
  • Staff have to learn new domain areas and so(ware (slow while

learning).

  • (^) Clients may not be ready.

New companies have parDcular difficulDes since they may have to hire

staff, find office space, etc.

A Simple Gan` Chart

Source: Advanced SoIware Engineering Limited

Gan` Charts

Used for small projects, single 1me-boxes, and sprints

  • Dates run along the top (days, weeks, or months).
  • Each row represents an acDvity. AcDviDes may be sequenDal, in parallel or

overlapping.

  • The schedule for an acDvity is a horizontal bar. The le( end marks the

planned beginning of the task. The right end marks the expected end date.

  • The chart is updated by filling in each acDvity to a length proporDonal to the

work accomplished. This is o(en difficult.

  • Progress to date can be compared with the plan by drawing a verDcal line

through the chart at the current date.

Most CS 5150 projects use Gan` charts to plan their work.

AcDvity Graph

An acDvity (task)

A dummy acDvity (dependency)

An event

A milestone

A group of scheduling techniques that emphasizes dependencies

Example: AcDvity Graph for first Part of a Distance

Learning Course

START

Slides 1

Suggest projects

Approve

projects

Slides 2

Dra( test

Print test

Write test

instrucDons

Release

Plan

projects

Plan 1

Dra( 1

Plan 2

Plan test

Dra( 2

Audio 1

Audio 2

Mount dependency

dependency