Spread Knowledge

CS615 - Software Project Management - Lecture Handout 35

User Rating:  / 0
PoorBest 

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management

Work Breakdown Structure

WBS- A Mandatory Management Tool

Sample WBS

Sample 1: These two graphics illustrate approaching the WBS as a parts list or as a process list

Sample WBS

Sample 2: WBS of Manufacturing of a Mountain Bike

WBS of Manufacturing of a Mountain Bike

Sample 3: This illustrates an example of Ordnance System WBS

Ordnance System WBS

The list of activities is often called a Work Breakdown Structure (WBS). The goal is to integrate the WBS, the schedule, and the budget into a written plan.

The WBS reflects activities associated with overall project management, requirements, design, implementation, transition management, testing, training, installation, and maintenance. The project manager is responsible for defining all top level tasks associated with a project and then further decomposing them as planning continues.

An activities list is typically shown in one of two ways. It can be shown as an outline or it can be graphically presented. Two samples of an activities list (WBS) are shown below.

MANAGEMENT

  1. Plan Project
  2. Develop Project Plan
  3. Update Project Plan
  4. Track Project
  5. Prepare status reports
  6. Collect/analyze project metrics
  7. Perform Quality Activities
  8. Prepare QA Plan
  9. Conduct Reviews
  10. Conduct Audits
  11. Perform Configuration Management
  12. Prepare CM Plan
  13. Develop Project Library
  14. Manage Change Board
  15. Maintain Configuration Items

DESIGN

  1. Prepare Preliminary Design
  2. Develop Enterprise Architecture
  3. Prepare Data Flow Diagrams
  4. Prepare Logical Data Model
  5. Prepare Detailed Design
  6. Prepare Physical Data Model
  7. Prepare Data Dictionary
  8. Document Design
  9. Develop Design Specification
  10. Review Design

DEVELOPMENT/INTEGRATION

  1. Develop Software
  2. Develop Server Application
  3. Develop User Interface
  4. Develop XYZ Interface
  5. Procure Hardware
  6. Procure Server
  7. Procure Workstations
  8. Procure Software Packages
  9. Procure Database
  10. Procure User Interface Building Tool
  11. Procure Operating System
  12. Perform Integration Testing
  13. Convert Data
  14. Develop Conversion Plan
  15. Develop User Manual
  16. Transition Management

ACCEPTANCE TESTING

  1. Plan Acceptance Test
  2. Conduct Acceptance Test
  3. Develop Test Report

INSTALLATION

  1. Develop Installation Plan
  2. Site Preparation
  3. Install at Locations
  4. Headquarters
  5. Site 1

MAINTENANCE

  1. Hardware Maintenance
  2. Software Maintenance

Sample 4: Sometimes, instead of depicting the WBS as an outline, it is shown graphically, as below:

Work Breakdown

Sample 4: Chart WBS

Chart WBS

Sample WBS - Outline Example-1

  1. Retail Web Site
  2. Project Management
  3. Requirements Gathering
  4. Analysis & Design
  5. Site Software Development
    1. HTML Design and Creation
    2. Backend Software
      1. Database Implementation
      2. Middleware Development
      3. Security Subsystems
      4. Catalog Engine
      5. Transaction Processing
    3. Graphics and Interface
    4. Content Creation
  6. Testing and Production

Sample WBS - Outline Example-2

MANAGEMENT

  1. Plan Project
    1. Develop Project Plan
    2. Update Project Plan
  2. Track Project
    1. Prepare status reports
    2. Collect/analyze project metrics
  3. Perform Quality Activities
    1. Prepare QA Plan
    2. Conduct Reviews
    3. Conduct Audits
  4. Perform Configuration Management
    1. Prepare CM Plan
    2. Develop Project Library
    3. Manage Change Board
    4. Maintain Configuration Items

DESIGN

  1. Prepare Preliminary Design
    1. Develop Enterprise Architecture
    2. Prepare Data Flow Diagrams
    3. Prepare Logical Data Model
  2. Prepare Detailed Design
    1. Prepare Physical Data Model
    2. Prepare Data Dictionary
  3. Document Design
    1. Develop Design Specification
  4. Review Design

DEVELOPMENT/INTEGRATION

  1. Develop Software
    1. Develop Server Application
    2. Develop User Interface
    3. Develop XYZ Interface
  2. Procure Hardware
    1. Procure Server
    2. Procure Workstations
  3. Procure Software Packages
    1. Procure Database
    2. Procure User Interface Building Tool
    3. Procure Operating System
  4. Perform Integration Testing
  5. Convert Data
    1. 3.5.1 Develop Conversion Plan
  6. Develop User Manual
  7. Transition Management

ACCEPTANCE TESTING

  1. Plan Acceptance Test
  2. Conduct Acceptance Test
  3. Develop Test Report

INSTALLATION

  1. Develop Installation Plan
  2. Site Preparation
  3. Install at Locations
    1. Headquarters
    2. Site 1

MAINTENANCE

  1. Hardware Maintenance
  2. Software Maintenance

Sample WBS - Outline Example-3

Step Description Estimate
1. Preparation  
1.1. Developer orientation TBD
1.2. Requirements gathering  
1.2.A. Use Cases TBD
1.2.B. Changes to data model TBD
1.2.C. Non-functional requirements TBD
1.2.D. Requirements validation TBD
1.3. Design  
1.3.A. Software architecture TBD
1.3.B. User interface design TBD
1.4. Development tools TBD

 

2. Construction  
2.1.A. System implementation  
2.1.A.1 Unit tests TBD
2.1.A.2 Production code TBD
2.1. A.3. Integrate Components
(mostly done during component implementation)
TBD
2.1.B. Maintenance documentation TBD
2.1.C. User documentation TBD
3. Quality assurance  
3.1. Fixing defects reported by users TBD
3.2. Testing  

 

3.2. D.1. Test planning TBD
3.2. D.2. Test implementation TBD
3.2. D.3. Test execution TBD
3.3. Reviews of design and code TBD
3.4. Fixing defects found by testing and review TBD
4. Transition  
4.A. Release packaging TBD
4.B. Documentation for other groups TBD
5. Reflection  
5.1. Postmortem report TBD
  Total fixed costs TBD

Tasks shown as blue are fixed costs of the project. These should be estimated soon.

Tasks shown as black are proportional to the size of the requirements. A more detailed work breakdown structure will be produced for these tasks when the requirements are better known.

Tasks shown as red depend on the defect rate in the delivered code. These will be estimated after 12 months experience.

TIP: Label each step uniquely to show its position in the WBS, e.g., Step 1.1.4.A. Use numbers for steps that you intend to do in sequence, and use letters for steps that you intend to do in parallel.
E.g., Step 1.1 comes before Steps 1.2.A and 1.2.B, but those two steps may be done in parallel, and Step 1.3 will be done after all 1.2.* steps have been finished. Don't worry about renumbering if you delete a step.

WBS- Major Steps

Project Decomposition

Many complex objects can be viewed as a collection of numerous simpler objects.
An appropriate example would be a complex chemical compound that is formed by various molecules, each of which is formed by combining various atoms. The atom, though itself divisible, can be regarded as the smallest particle of a chemical substance.

In a similar way, a complex project can be divided into simpler components.
While the full project may be difficult to manage, each component will be easier to handle. Software projects can be decomposed into smaller components in order to provide better estimates of the amount of work involved, or in order to monitor the activities of the various development teams.

The decomposition of a software project is one of the software project manager's first tasks. However, the method of decomposition may differ, depending on the project manager's actual objective. A functional decomposition of a project may not be the same as design decomposition. A functional decomposition divides the project into its basic components from a user's perspective, while design decomposition divides a project into its basic programming components or modules.

Intuitively, it would not appear reasonable to attempt to identify all project components in a single step. Clearly, an iterative procedure that would gradually provide more detail would be easier to use. Iterative methods of this kind are
called stepwise refinement, as the decomposition is further refined in each succeeding step.

Figure 1 presents a general illustration of stepwise refinement. The system is initially divided into three top level components. In turn each top level component is further divided into lower level components, and so forth, until the lowest decomposition level is reached.

In a stepwise decomposition of a project, each component decomposes into the components directly below it, so that each step of the decomposition describes the full system, but at a different level of detail. In Fig.1, components 1, 2 and 3 comprise the complete system. For more detail we take the next decomposition step, and find that components 1.1, 1.2, 2.1, 2.2, 2.3, 3.1 and 3.2 now represent the whole system.

Software decomposition

Figure 1: Software decomposition by stepwise refinement

A stepwise refinement diagram looks similar to a hierarchical system chart.
However, it is important to understand that stepwise refinement is basically different because the diagram's building blocks are different A hierarchical system diagram describes the hierarchical relationship between components, so that each component in the diagram actually corresponds to a real component in the system. However, in a stepwise refinement diagram, a higher level component is only a name conveniently given to a group of real components that appear below it.

In Fig. 2(a) the Controlled access system software has five low level software components:

Visitor identification, Door lock-control, Access file-manager, Illegal access identification and Alarm activation. Each of these five modules may correspond to an actual software module1. The two high level components, Access control and Alarm system, do not exist as actual software modules, and only appear as names given to the two groups of lower level components.

Figure 2(b) describes the same Controlled access system software, but this time it is represented as a hierarchical chart. Here, each component in the diagram represents a real software component.

The System executive main Loop component calls three other components:

Visitor identification, Door lock control and Alarm activation: The Visitor identification component calls two components: Illegal access identification and Access file manager

Figure 2: (a) Decomposition of high level components into low level components; (b) a hierarchical structure chart

hierarchical structure chart

Just like any other large complex task, the development of a software project is more easily managed with the divide and conquer approach.

Stepwise refinement, when applied to a software project, produces all the low level work tasks and includes

  • development tasks
  • managerial tasks
  • support tasks and
  • administrative tasks

The WBS list of project tasks is derived from the project's statement of work (the SOW) that defines the scope of the project. The SOW is usually prepared before the official launching of the project, and is often part of the project contract
between the customer and the developer.

For internal projects, when an organization is funding its own development work, the SOW becomes synonymous with the Project definition specification or a similar document that defines the scope of work for the software project manager.

Functional Decomposition

The functional decomposition of a software project is a division of the system into its operational components as they are seen by the user. Functional decomposition is part of the requirements phase of a project. The objective of this phase is to define air the characteristics of the system from the user's perspective.

Let us consider an automatic bank teller system. The ability to communicate online between the remote automatic tellers and the bank's central computer in order to provide updated account information is a functional characteristic or the system.

This will usually be defined during the requirements phase of the development cycle. However, the method of transmission between the automatic teller and the central computer is not a functional characteristic of the system, as this is internal to the design and implementation of the system and is not apparent to the user.
The method of transmission, including the communications protocol, will usually be defined during the design phase of the development of the system.

Figure 3 presents an example of the functional decomposition of an automatic bank teller system into lower levels of functional components. In Fig. 3 we have determined that there will be a customer data base, which could be viewed as a design decision.

This is unavoidable. The functional decomposition is rarely completely devoid of all design considerations. As we will see, the functional decomposition is often a starting point for the initial design of the system.

Automatic teller system

Figure 3: Automatic teller system - functional decomposition diagram

Just as the requirements phase precedes the design phase, so the functional decomposition of a software system will usually precede the design decomposition

The functional decomposition will often provide much of the information necessary for the subsequent division of the system into the implementation components.

In fact, the functional decomposition is often a good place to start when designing a software system, as the major functional components of a system will often correspond to the initial division of the system into subsystems or high level
components.

Design Decomposition

The design decomposition of a software system is a division of the system into lower level components that coincide with the actual software components of the system. In a full design decomposition of a software system, the lowest components correspond to programming modules (usually procedures, subroutines or program functions).

The work breakdown structure (WBS) is the decomposition of a software project into low level work tasks.

An important point to remember is that in design decomposition, only the lower level components are actually implemented. Higher level components represent a group of lower level components.

Design decomposition basically produces two types of system component:

  • high level components and
  • low level modules

Different software development standards use different terminology to identify the various levels of decomposition.

Figure 4 presents an example of the design decomposition of an automatic bank teller system into lower levels of design components. On the third level, the Automatic teller component decomposes into the Hardware interfaces, and the Teller logic. The next level may then decompose the Hardware interfaces into the Keyboard driver, the Display driver, the Printer, driver and the Beeper. At this level, these drivers may represent actual software modules.

design decomposition diagram

Figure 4: Automatic teller system -design decomposition diagram

A fully decomposed system, with all its low level components, is not always easy to grasp. This is especially true during the presentation of the system at a project review, when the system needs to be quickly understood by people who have not been involved in its design.

On such occasions, the stepwise refinement technique is a convenient method for gradually presenting progressive detail by initially showing the first decomposition level, and then slowly revealing subsequent levels. This is demonstrated in figure 5.

At a convenient intermediate decomposition step we can divide the design in two:
the upper levels and the lower levels. This is used particularly when the design phase is implemented in two distinct stages: top level design and detailed design (see Fig.5).

Initial top level decomposition

Initial top level decomposition

Intermediate level decomposition

Intermediate level decomposition – top level design

Low level decomposition

Low level decomposition – detailed design

Figure 5: Software decomposition by stepwise refinement

Develop Project Tasks

WBS tasks are developed by asking, “What tasks need to be done to accomplish the project objective?” The choice of WBS structure is subjective and reflects the preferences and judgment of the project manager.

As levels of the WBS become lower, the scope, complexity, and cost of each subtask become smaller. The lowest level tasks, or work packages, are independent, manageable units that are planned, budgeted, scheduled, and controlled on their own.

As efforts of similar scope and type are planned, the basic WBS tasks remain fairly similar, but each project requires a specific set of tasks that address the uniqueness of the project's requirements. Certain top level elements, such as project management, are included in the WBS of every project, regardless of its type, size, or complexity. Other items, like installation, may not apply to every project.

The initially developed WBS evolves over the course of the planning. It is highly probable that it will look quite different as the scheduling, estimation, and resource allocation portions of the plan are completed.

One of the difficult parts of talking about IT projects generically is the wide range of such projects. Typically, in a small project, there is a single project development phase.

In large or complex systems, however, there are often multiple development phases, where different functional requirements are met.

Sometimes these phases are driven by the need to achieve certain levels of functionality prior to the availability of the complete system.

Other times, the phases are defined to partition the development effort and to reduce the risks associated with larger project efforts.