how to handle large projects

IS 556 Fall 2003 1

IS 556 Project Management

Week 9 HOW TO HANDLE LARGE PROJECTS: Divide and Conquer Readings: On Time Within Budget - Ch.6No presnter groupDL Group [Group 9 DL -BankIreland (DL)]

Medisys Health Group - Group [Group 8 (DL) Medisys (DL) ]DL Group 8 - local Group [group 13 DL Only - Medisys]

Presenter Group [Group 10 - Eclectic - Medisys]

David Lash

http://condor.depaul.edu/~dlash/extra/IS556/GroupDetailInfo.asp?ClassID=8155&GroupID=2739












2David LashCS 556 - Winter

Objectives

Requirements/Design Issues Stepwise refinement Functional Decomposition Design Decomposition

Task DecompositionComponent based development


Large Software Projects

Large Software Projects have extra challenges. Many tasks to coordinate and track How do you break apart the overall project

into smaller pieces? Are their pieces that can be reused?


Stepwise RefinementNot possible to figure out all task at once

Use and iterative method to refine each iteration Increasing level of detail

Not hierarchical components Not hierarchical calling relationship between higher and lower level modules Grouping items by logical order Coding modules exist at lowest level of detail

System

Comp 1 Comp 2 Comp 2

Continuously refine components

This is called stepwise refinement.


More on Hierarchy Charts

System

Comp 1 Comp 2 Comp 3

2.1 2.2 2.3

2.1.1 2.1.2 2.1.3

2.2.1 2.2.2

Overall subsystem name

Each item is logically part of sub-system. However, when builtindividual modules might be grouped differently.


System decomposition and hierarchal chart

Stepwise refinement diagram - Logical decomposition of high level into low level components.

Hierarchical decomposition each component corresponds to a “real” system component. (Shows real calling hierarchy.)

For example item logically here but might be physically implemented here


Functional DecompositionDecomposition into operational component as

seen by user Part of requirements phase Objective is to define system’s functional

characteristics as seen by user. Describe major functional operations of black

box but nothing inside black box. E.g., A function diagram for a bank ATM system

Might include • ability to update account information from central computer to

ATM Would not include

• communication method and/or protocol– (this is an internal


Automatic Teller System:Functional Decomposition Diagram

Even though this component is on the “grey” edge of being design info, it is included here


Functional decomposition of large systems

Sometimes functional decomposition is not clear A large inventory system might functionally include

human interface, database, report generator, Update logicMight not functionally include human interface as high level

• Since above leaves out important functions such as fail-over & backup

Functional decomposition should create foundation for design decomposition A functional decomposition team may meet to define and

select alternatives A good functional decomposition is selected based upon:

Reason (logical to divide a certain way)Ease of implementation (lead to a good design)

• Should mirror structured program (modules, independence, etc.)Comprehensiveness (everything covered)


Design Decomposition

Division into lower level components that coincide with software modules is usually done after functional decomposition

Done in a stepwise fashion Best used as a method for providing increasing

detail For example, might decide main functional

components of ATM system are The automatic teller terminal The main computer The computer network


A Design Decomposition of ATM

These may correspond to actual software modules

These are category names (may become susbsystem names). There is not one module that represents each of these but a set developed at the lower levels.


A fully decomposed design diagram

There can be huge sets of modules at lowest levels. If had to review design using only the lowest level modules could be very difficult to understand and grasp system

Might be the high level design. Might review this separately


Design Decomposition

Good design is basis for software structure

Software Engineering has lots to say about design decomposition Independent software components Simple interfaces (minimize coupling) Information hiding

Produce modules that hide their design and data structures (enable simple changes to data structure)


Determination of Project Tasks

Design decomposition => determine software design and modules

How determine the project tasks? Use WBS => A method of decomposing tasks Uses stepwise refinement Derived from statement of work Used to track status and assignment data


WBS and Decomposition. WBS and Design decomposition are general divide and

conquer approaches To understand and work with something so large need to divide up

pieces to understand it. Ishikawa (~1970s): “Categorization is the first part of

understanding”. Categories or subsystems provide method to understand and see

the big picture Details are developed one step at a time. Lowest levels represent module or in WBS case specific work tasks.

WBS Represents all work tasks (not software components) ALL work must be part of a task in this document

Over time the WBS is refined (tasks added) Use WBS to assign resources to tasks Many different tools exist to create project plans (e.g., Microsoft

Project) from WBS


WBS and Decomposition.Each low level design decomposition module

has 3 tasks: Design Coding Unit testing

We would also include non-development tasks Acquire development machines Install test machines Set up change control systemTraining

Staffing


Work Breakdown Structure: Task Designation

At lowest level, includes all project tasks.


Individual Task Assignment


Large Projects and Subsystems

Subsystem contains most characteristics of main system For example, ATM might have

Main computer subsystemAutomatic teller subsystem

But … a subsystem is not intended to work on its own

Massive projects require division into subsystems (each make be looked at as separate systems)

Often separate or sometime deputy PM is assigned to each subsystem Might have several PM that each manage separate

subsystem and overall release manager.


Component Based DevelopmentCBD- Reuse of previously built components

Particularly useful for large system development CBD are software building blocks Can be developed internal (inheirted) or purchase

(acquired) Might be :

Algorithm implementation (like a sort). Drivers (like hardware interface driver)Communication stacks

For example, Suppose develop graphical interfaces on wide variety of

hardwareTeams develop modules with standard API to hardware Hardware team develop drivers as components.


From On-time


Component Based Development

Standard 1420 (IEEE 1999) -> defines minimal set of information that items need to exchange Container => refers to the shared context of

interactions between components. Components advantages

Known commodity Refined over time Reuse saves time and money Effective on large projects Equivalent to “parts on a shelf” Example: Microsoft Windows plug and play

Application interfaces


In Conclusions Project Management is a leadership position We’ve spent a fair amount of time

Analyzing situations Figuring out what the real problem is

Project management wise. Need to know How to work with developers How to develop How to work with management

What do they expect? How to ask non-offending questions How to say no When to make consensus decisions The tools of your trade (scheduling, status reports) Communication skills (present, write, talk, think) Business issues (how to select projects, contracts) Estimation methods