IS 556 Project Management

1. IS 556 Project Management Week 9 HOW TO HANDLE LARGE PROJECTS: Divide and Conquer Readings: On Time Within Budget - Ch.6 No 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

2. Objectives • Requirements/Design Issues • Stepwise refinement • Functional Decomposition • Design Decomposition • Task Decomposition • Component based development

3. 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?

4. Stepwise Refinement • Not 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 This is called stepwise refinement. System Continuously refine components Comp 1 Comp 2 Comp 2

5. More on Hierarchy Charts System Comp 1 Comp 3 Comp 2 Overall subsystem name 2.1 2.2 2.3 Each item is logically part of sub-system. However, when built individual modules might be grouped differently. 2.1.1 2.1.2 2.1.3 2.2.1 2.2.2

6. 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

7. Functional Decomposition • Decomposition 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

8. Automatic Teller System:Functional Decomposition Diagram Even though this component is on the “grey” edge of being design info, it is included here

9. Functional decomposition of large systems • Sometimes functional decomposition is not clear • A large inventory system might functionally include • human interface, database, report generator, Update logic • Might 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)

10. 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

11. A Design Decomposition of ATM 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. These may correspond to actual software modules

12. A fully decomposed design diagram Might be the high level design. Might review this separately 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

13. 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)

14. 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

15. 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

16. 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 system • Training • Staffing

17. Work Breakdown Structure: Task Designation At lowest level, includes all project tasks.

18. Individual Task Assignment

19. Large Projects and Subsystems • Subsystem contains most characteristics of main system • For example, ATM might have • Main computer subsystem • Automatic 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.

20. Component Based Development • CBD- 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 hardware • Teams develop modules with standard API to hardware • Hardware team develop drivers as components.

21. From On-time

22. 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

23. 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