chapter 9 identifying tasks - etsmtl.ca

Chapter 9 - Identifying the Tasks and Activities

1 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall

Chapter 9 Identifying the Tasks and Activities

As described in chapter 8, building a product-oriented work breakdown structure (WBS) involves decomposing a large activity (the whole project) into successively smaller activities (top down approach) until the work is described in detail to manage properly. Alternatively, it involves brainstorming everything that needs to be done as detailed activities and arranging them until enough are present to carry out and manage the work (bottom up approach). In either case, identifying the right activities for the work is paramount.

The Triple Constraint for any project (Scope, Schedule, Cost) is largely dependent on getting the scope right, as it usually drives the schedule and cost of a software development project. In chapter 10, we’ll see how the product-oriented WBS is the primary determinant of the scope and cost portions for software projects, as product size is the primary determinant of effort for software, an intellectual product. In this chapter, we explore the identification of tasks and activities that software engineers use to produce the elements of a product-oriented WBS, and consider how to arrange them for best effect in the life cycle models described in chapter 4.

Where We Are in the Product Development Life Cycle

Where are we in the Basic Software Life Cycle Model that serves as our map? As shown in Figure 4-1 and in Figure 9-1, we are still at the beginning of the Software Life Cycle, and are deeply involved in the What step of project planning, as shown in Figure 9-1.

Figure 9-1. Product Development Life Cycle

C o n c e p tE xp lo ra tio n S ys te m

E xp lo ra tio nR equ irem ents

D es ig n

Im p lem e n t

In s ta llatio nO p e ra tio n s &

S u p p o rtM a in te n a n ce

R etirem e n t

� S tatem en t o f ne ed

� S ys te m In te rfa ceS pe cific a tion

� S oftw areR e qu irem e ntsS p ec ific a t ion

� S o ftw are D e signD es cr ip t ioo n

� S o ftw are V a lida t ion /V e rifica t ion R ep ort

� U se rD oc um en ta tion

� M ain ten an ceD oc um e nta tio n

� A rc h iv e R e port

� S oftw a re V a lida tio n /V erif ica tio n P la n

M a p tas ksto S L C

using IE E E10 74

A llo ca teR e so urc es

� S LC

� B udg et

Iden tifyS LC 's� S LC 's

S ele ctM od el

� S LC M od el

So ftw a re Life C y c le M o d e l Se le c tio n

Product Processes



Figure 9-2: Project Process Framework

Relation to the 34 Competencies

This chapter concerns the competencies shown below. For identifying tasks and activities, the key product development technique needed is an awareness of the processes of software development using different life cycles. Life cycles must be evaluated and tailored to the individual needs of each project. A general understanding of software development activities (software engineering) and how to define the software product are competencies needed for task and activity identification.

The project management skills needed here are a continuation of those needed for building the WBS, such as documenting plans in an arranged structure, and finding tasks and activities that can be used to create a schedule. Activity ID requires the People skills of leadership, interface and communication, and presenting ideas effectively throughout the identification process.

Product Development Techniques

1. Assessing Processes—Defining criteria for reviews 3. Defining the Product—Identifying customer environment and product requirements 4. Evaluating Alternative Processes—Evaluating various approaches 9. Tailoring Processes—Modifying standard processes to suit a project 11. Understanding Development Activities—Learning the software development cycle

Project Management Skills

12. Building a WBS—Building a work breakdown structure for a project 13. Documenting Plans—Identifying key components 18. Scheduling—Creating a schedule and key milestones

People Management Skills

Project Steps

Why What

How Do It

Did It

• Charter

• ROI

• SPMP

• Life Cycle

• PPA

Task ID



26. Interaction and Communication—Dealing with developers, upper management, and other teams 27. Leadership—Coaching project teams for optimal results 31. Presenting Effectively—Using effective written and oral skills

Learning Objectives

Upon completion of this chapter, the reader should be able to: • Define a task and an activity, describe the difference between, and tell which is used where • Prepare a meaningful activity label • List several sources for software engineering activities • Demonstrate the ability to map activities to each of the life cycles discussed in chapter 4 • Identify the characteristics of a useful and meaningful activity for a WBS • List at least three common types of activities found in every software project • Explain how to construct a customized WBS • Find at least five uses of the same activity among the life cycles presented in chapter 4

Characteristics of Tasks and Activities

How hard can it be to identify the work that needs to done for a software project? It’s mostly common sense, isn’t it? What seems like a straightforward assignment can be riddled with opportunities for poor results. The first thing to address is what tasks and activities are. These were first visited in chapter 1, where we introduced some of the important definitions for understanding software project management. The PMBOK® offers these definitions:

Activity An element of work performed during the course of a project. An activity normally has an expected duration, an expected cost, and expected resource requirements. Activities can be subdivided into tasks. Task A generic term for work that is not included in the work breakdown structure, but potentially could be a further decomposition of work by the individuals responsible for that work. Also, the lowest level of effort on a project.

This means that, technically, a WBS is composed only of activities, and those activities are composed of task effort. The task effort is what a professional is educated for, and is expected to know how to do. For software engineers, task effort would be things like designing, coding, compiling, debugging, and documenting. Skills in various programming languages and with an assortment of software development tools fall into the task realm for a software project. Those are things you would expect a skilled software practitioner to already know how to do. In this chapter, we are going to focus on the activities that take place in a software development project.

Whether considered tasks or activities, the characteristics of activity identification that we will discuss are:

• Label • Size • Source



Meaningful Label

Many developers seem to believe that the software project management plan is just one large task called “Do It”. But that is not a very descriptive label, and we know that software development is more than that (a lot more). So we want to describe the work with more accuracy and meaning. The most obvious requirement for an activity ID is that it clearly describes the work to be done. However, too many developers and managers don’t use enough verbs in their activity labels that are supposed to describe processes. Instead of an activity label such as “Build a ‘C’ Compiler”, it might appear as just “C Compiler”. This leaves ambiguity as to exactly what is meant by the label. Is it to build the whole thing, or just some parts? Does it include the test suite and documentation or not? Or does it really mean “Completed ‘C’ Compiler” as a major deliverable? Try to avoid a whole WBS with nothing but a hierarchy of nouns. There have to be some verbs somewhere as the verbs supply the action to get the work done. Of course, putting too many words in an activity label is also not a good practice as it makes the WBS unwieldy. It is best to keep the labels as short, simple sentences with a verb and a noun. Many people call this “bullet language” referring to the abbreviated wording for presentation slides. This is accepTable since further explanation and qualification can occur in notes about the activity, or in the work package information for it.

Optimal Activity Size

Just how big is a unit of work? “Optimal” for software development projects means whatever fits the scale and scope of the current project. There is no one number for this. As mentioned in chapter 8 concerning building the WBS, activities should be chunks of work that can reasonably be done by “one unit of resource” in a “relatively short period of time.” “One unit of resource” could mean any reasonable organizational segment down to the individual, and “relatively short period of time” could mean any time period that provides adequate measurement for goal achievement, and the project team is willing to measure.

Initially, your best guess, or “gut feel”, provides a guide for determining how big a chunk of work should be. Later, when the requirements for the software product are refined (chapter 16) and the software size can be estimated (chapter 10) which helps determine the effort needed (chapter11), a more accurate sizing of activities can occur.

Remember that one of the characteristics of a project is “progressive elaboration of characteristics.” This means that you cannot be expected to have all the detail needed for the project plans at the start of the project. You learn as you go, increasing the amount of detail in near-term plans. So, a large activity may be further broken down into smaller activities, as the detail becomes known. For example, at the beginning of the project, the activity may be “Design interfaces”. As more information is known about the requirements and design, it may be broken into the sub-activities “Design Main Functions Menu” and “Design Utility Menu.” Again, only break work down as far is practical for the work to be understood and manageable for the organizational maturity of the project’s environment.

Source



From where do you get a list of activities and tasks to run a software development project and build a software product? The source depends on whether there is any prior project precedent or not. If neither you nor your organization have done a project like this before, or haven’t any other history to draw from, then the detailed work steps to create it must be invented. An approach to invention of product development activities using brainstorming with the project team and stakeholders is described later. If there is a project precedent, then reviewing the activities used on it can provide some guidance for activity identification. Even if no precedent exists, there are professional organizations such as the SEI, ISO, or IEEE that provide sources for software development activities. The SEI models have been discussed elsewhere. ISO/IEC 12207 lists twelve engineering activities following Process Implementation that are similar to the phases in a typical software life cycle model:

1. System requirement analysis 2. System architectural design 3. Software requirements analysis 4. Software architectural design 5. Software detailed design 6. Software coding and testing 7. Software integration 8. Software qualification testing 9. System integration 10. System qualification testing 11. Software installation 12. Software acceptance test

The IEEE publishes a standard for life cycle model definitions that contains 17 processes of 65 activities that cover the essential activities of software development. These will be studied in the next section.

The Activity ID Process

There are really only two ways that tasks and activities are identified for a project: they are part of a pre-existing WBS for a software development life cycle, or they are invented anew for a unique development project situation. Either way, customization occurs. We’ll look at both approaches and explore how to select and organize tasks for a software development project. First, in this chapter, let’s look at how we use these sources as a guide to activity identification for a given software project. Then, in chapter 14, we’ll look at ways to invent them where no guide exists already.

Adapting Life Cycle Activities for Common Situations

IEEE 1074 provides a set of 17 processes and 65 activities that software projects may need to carry out the work of software engineering organized by where they fit in the Basic Product Development Life Cycle that serves as our map (Figure 4-1). These are shown in Table 9-1, which is a tabular form of Figure 4-1, with activities added. The 34 competencies that every software project manager should know directly relate to the 65 software development project activities shown, and are explained in more detail elsewhere in this book.



Development (product) activities may include analysis, high level design, low level design, coding, testing, etc., which occur in the life cycle phases. Managerial activities may include project planning, tracking, control, risk analysis, etc. Support activities may include documentation of deliverables such as users' manual, operations' guides, network communications, etc. All of these kinds of activities are part of a product-oriented project WBS. We call Managerial, Administrative and Support tasks “Integral Tasks”, traversing one or more (sometimes all) of the development tasks. Other Integral Tasks include: configuration management procedures, software quality assurance practices, risk analysis and management, software development tools and techniques, methods of conducting reviews of in-process deliverables, metrics to be collected and analyzed, definition and documentation of standards (rules for in-process deliverables), and any other activities required to meet customer requirements, such as creation of documents, training programs, tool development or acquisition.

Development Phase

Life Cycle Processes Activities

Software Life Cycle Model Planning

1. Map Software Life Cycle Model to Project Needs

1. Identify candidate Software Life Cycle Models

2. Select project model 2. Project Initiation 3. Map activities to Software Life

Cycle Model 4. Allocate project resources 5. Establish project environment 6. Plan project management

3. Project monitoring and control

7. Analyze risks 8. Perform contingency planning 9. Manage the project 10. Retain records 11. Implement problem reporting

method

Project Management

4. Software quality management

12. Plan software quality management

13. Define metrics 14. Manage software quality 15. Identify quality improvement

needs 5. Concept Exploration 16. Identify ideas or needs

17. Formulate potential approaches 18. Conduct feasibility studies 19. Plan system transition (if

applicable) 20. Refine and finalize the idea or

need

Pre-development

6. System Allocation 21. Analyze functions 22. Develop system architecture 23. Decompose system requirements

Development 7. Requirements 24. Define and develop software requirements

25. Define interface requirements 26. Prioritize and integrate software

requirements



Development Phase

Life Cycle Processes Activities

8. Design 27. Perform architectural design 28. Design data base (if applicable) 29. Design interfaces 30. Select or develop algorithms (if

applicable) 31. Perform detailed design

9. Implementation 32. Create test data 33. Create source code 34. Generate object code 35. Create operating documentation 36. Plan integration 37. Perform integration

10. Installation 38. Plan installation 39. Distribute software 40. Install software 41. Accept software in operational

environment 11. Operation and Support 42. Operate the system

43. Provide technical assistance and consulting

44. Maintain support request log 12. Maintenance 45. Reapply software life cycle

Post-Development

13. Retirement 46. Notify user(s) 47. Conduct parallel operations (if

applicable) 48. Retire system

14. Verification and Validation

49. Plan verification and validation 50. Execute verification and

validation tasks 51. Collect and analyze metric data 52. Plan testing 53. Develop test requirements 54. Execute the tests

15. Software Configuration Management

55. Plan configuration management 56. Develop configuration

identification 57. Perform configuration control 58. Perform status accounting

16. Documentation Development

59. Plan documentation 60. Implement documentation 61. Produce and distribute

documentation

Integral

17. Training 62. Plan the training program 63. Develop training materials 64. Validate the training program 65. Implement the training program

Table 9-1: IEEE 1074 Software Development Product Life Cycle Processes and Activities



The challenge for every software development project manager is to map the activities in Table 9-1 into a life cycle model that fits the current project situation, and describe them in enough detail for the organization’s personnel to understand and execute. Each of the activities in the Table may need further breakdown to be useful to your project team. For example, “Plan configuration management” may be all that is needed for a project in an organization where a sophisticated configuration management (CM) system and process is in place and the staff is trained for its proper use. The activity may only need a minimal work package description like “Arrange for CM support from Department Coordinator.” No separate Software Configuration Management Plan (SCMP) document is needed. It may instead just be a section in the project’s Software Project Management Plan (SPMP). However, for a new organization, this activity may involve considerably more work, and involve the design of a CM system, and the selection, purchasing, installation and training for a supporting software configuration management toolset. This would imply that a separate (and probably very detailed) SCMP be developed. The scope of these two activity extremes is very different as is the effort to carry them out.

One other thing to note about the activities in Table 9-1 is that all the activities follow the guidelines mentioned earlier for a proper activity label. The action levels have verbs and nouns, making their meaning more precise.

Software Development Life Cycle Activities

The actual construction of customized software development life cycles is covered in chapter 4. Here, we will look at the common types of life cycle models derived from different arrangements of the activities in Table 9-1. We will look at the activities and corresponding descriptions for the following software development life cycles described in more detail in chapter 4:

• Waterfall Model • V-Shaped Model • Structured Evolutionary Rapid Prototyping Model • Rapid Application Development (RAD) Model • Incremental Model • Spiral Model

You will note that in many of these life cycles derived from sources like IEEE 1074 include both product development and ongoing maintenance operations in their design. Recall Figure 7.5, Generic Business Life cycle Relationships. Do not lose sight of the fact that the actual development project ends when the software products are developed, and ongoing operations and maintenance activities begin. Operations and maintenance activities (sometimes called “sustaining”) typically occupy a much larger portion of the lifetime of the average software product, and should not be included when referring to the development project. This conforms to the relative sizes of the cost curve areas in Figure 7.9.



Maintenance67%

Requirements3%

Specification4%

Design6%

Integration6%

Testing7%

Coding5%

Planning2%

Source: Stephen Schach, Practical Software Engineering, Irwin and Aksen Associates, 1992, p. 5.

Project Work Operations Work

Figure 9-3. Typical Software Maintenance Lifecycle Cost Distribution

In most organizations, software maintenance activities are often more than meets the eye. There are at least three types of maintenance activities:

• Corrective (about 20%) - removing defects in the product deliverables (software, manuals, training, etc.)

• Adaptive (about 20%) - accommodating changing environments (platform changes, rules and regulation changes such as tax rates and laws governing official data reporting)

• Perfective (about 60%) - adding capabilities or changing features as requested by users

The sum of these types of maintenance activities constitutes about 2/3 of the total costs for an average software product during its lifetime. Since perfection at initial release is unlikely for most software products, some corrective maintenance can be expected to occur in any operations phase of a product’s full life cycle. This should be factored into the operations budget for the sustaining organization. The Adaptive and Perfective types, however, could probably be treated as a separate development project to prepare a major release of the software product. These are the types of maintenance that result from changing environments and increased problem knowledge during the course of the original software product development project. Some of the life cycle models below include these operations and maintenance activities in their descriptions, and some do not.

Another thing to note about the activity arrangements for a WBS in the models below is that even though some models are depicted as circular, they must be “straightened” for representation in a project WBS. Their circular, looping, iterative nature comes from repeating certain activities repeatedly. For instance, the Spiral Model can be thought of as being straight line if it is “uncoiled” and flattened. The project planner must use judgment and experience to decide how many loops through the spiral to plan for.

Waterfall Model Activities



As described in chapter 4 and depicted in Figure 4-9 Classic Waterfall with Feedback, the waterfall model is a linear arrangement of most of the activities in Table 9-1. These are arranged into phases using the processes and activities shown below, typically executed in the order shown, with integral activities performed throughout, and the life cycle mapping and project initiation activities performed prior to entering the model:

• Concept exploration – examining requirements at the system level to determine feasibility o Identify ideas or needs o Formulate potential approaches o Conduct feasibility studies o Plan system transition (if applicable) o Refine and finalize the idea or need

• System allocation process – mapping functions to software or hardware based on the overall system architecture

o Analyze functions o Develop system architecture o Decompose system requirements

• Requirements process – defining software requirements for the system’s information domain and function, behavior, performance and interfaces

o Define and develop software requirements o Define interface requirements o Prioritize and integrate software requirements

• Design process – developing and representing a coherent, technical specification of the software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail

o Perform architectural design o Design the database (if applicable) o Design interfaces o Select or develop algorithms (if applicable) o Perform detailed design

• Implementation process –transforming the software design description into a software product, producing source code, databases and documentation, whether developed, purchased, or a blend

o Create test data o Create source code o Generate object code o Create operating documentation o Plan integration o Perform integration

• Installation process –installing and checking out the software in the operational environment, and getting formal customer acceptance of the software

o Plan installation o Distribute software o Install software



o Accept software in operational environment • Operation and support process – involving user operation of the system and ongoing support,

including providing technical assistance, consulting with the user, recording user requests for enhancements, changes, and corrections or errors.

o Operate the system o Provide technical assistance and consulting o Maintain support request log

• Maintenance process – resolving requests to address software errors, faults, failures, enhancements, and changes generated by the support process

o Reapply a software life cycle (initiate a development project) • Retirement process – removing an existing system from its active use, either by ceasing its

operation, replacing it with a completely new system, or replacing it with an upgraded version of the existing system

o Notify user(s) o Conduct parallel operations (if applicable) o Retire system

• Integral Activities – support activities occurring throughout the life cycle o Project monitoring and control

� Analyze risks � Perform contingency planning � Manage the project � Retain records � Implement problem reporting method

o Software quality management � Plan software quality management � Define metrics � Manage software quality � Identify quality improvement needs

o Verification and Validation � Plan verification and validation � Execute verification and validation tasks � Collect and analyze metric data � Plan testing � Develop test requirements � Execute the tests

o Software Configuration Management � Plan configuration management � Develop configuration identification � Perform configuration control � Perform status accounting

o Documentation Development



� Plan documentation � Implement documentation � Produce and distribute documentation

o Training � Plan the training program � Develop training materials � Validate the training program � Implement the training program

V-Shaped Model Activities

The V-shaped model described in chapter 4 and shown in Figure 4-10 V-Shaped Model, is a linear arrangement of most of the activities in Table 9-1, similar to the waterfall model. The V-Shaped Model’s processes and activities are shown below:

• Project and requirements planning – determining the system requirements, and how the resources of the organization will be allocated to meet them.

o Initiate the Project � Map activities to Software Life Cycle Model � Allocate project resources � Establish project environment � Plan project management

o Explore the Concept � Identify ideas or needs � Formulate potential approaches � Conduct feasibility studies � Plan system transition (if applicable) � Refine and finalize the idea or need

o Manage Software Quality � Plan software quality management � Define metrics

• Product requirements and specification analysis –analysis and specification of the expected external behavior of the software system to be built

o Analyze System Allocation � Analyze functions � Develop system architecture � Decompose system requirements

o Identify Software Requirements � Define and develop software requirements � Define interface requirements � Prioritize and integrate software requirements



• Architecture or high-level design – defining how the software functions are to implement the design

o Perform High-Level Design o Perform architectural design o Design the database (if applicable) o Design interfaces

• Detailed design – defining and documenting algorithms for each component that was defined during the Architecture phase.

o Select or develop algorithms (if applicable) o Perform detailed design

• Coding – transforming the algorithms defined during the Detailed Design phase into software o Create source code o Generate object code o Create operating documentation

• Unit testing – checking each coded module for errors o Plan testing o Develop test requirements o Create test data o Execute the tests

• Integration and testing – interconnecting the sets of previously unit-tested modules to ensure that the sets behave as well as the independently tested modules did during the Unit Testing Phase

o Plan integration o Perform integration o Plan testing o Develop test requirements o Create test data o Execute the tests

• System testing – checking whether the entire software system (fully integrated) embedded in its actual hardware environment behaves according to the software requirements specification

o Plan testing o Develop test requirements o Create test data o Execute the tests

• Acceptance testing – allowing the users to test the functionality of the system against the original requirements. After final testing, the software and its surrounding hardware become operational. Maintenance of the system follows

o Plan installation o Distribute software o Install software o Plan testing o Develop test requirements



o Create test data o Execute the tests o Accept software in operational environment

• Production, Operation, and Maintenance – putting software into production and providing for enhancement and corrections


• Integral Activities - support activities occurring throughout the life cycle o Project monitoring and control


o Software quality management � Manage software quality � Identify quality improvement needs

o Verification and Validation � Plan verification and validation � Execute verification and validation tasks � Collect and analyze metric data


o Documentation Development � Plan documentation � Implement documentation � Produce and distribute documentation


Structured Evolutionary Rapid Prototyping Model Activities



The Structured Evolutionary Rapid Prototyping Model described in chapter 4 and illustrated in Figure 4-11 Structured Evolutionary Rapid Prototyping Model, is a circular arrangement of most of the activities in Table 9-1, but done linearly several times, with more robust deliverables each time. One version of the Structured Evolutionary Rapid Prototyping Model’s processes and activities are shown below (many variations are possible):

• Joint project planning - user and designer jointly developing a preliminary project plan outlining rough schedules and deliverables.

o Initiate the Project � Map activities to Software Life Cycle Model � Allocate project resources � Establish project environment � Plan project management

o Explore the Concept � Identify ideas or needs � Formulate potential approaches � Conduct feasibility studies � Plan system transition (if applicable) � Refine and finalize the idea or need

• Develop Paper Prototype - user and designer work together to define the requirements and specifications for the critical parts of the envisioned system to produce an intentionally incomplete, high-level paper model

o Rapid Analysis– user and designer jointly designing from preliminary requirements � Analyze System Allocation

• Analyze functions • Develop preliminary system architecture • Decompose preliminary system requirements

� Identify Preliminary Software Requirements • Conduct preliminary user interviews • Define and develop preliminary software requirements • Define preliminary interface requirements • Prioritize and integrate software requirements

o Database Creation – (if applicable) jointly identify the preliminary database elements � Perform preliminary architectural design � Design the preliminary database

o Design the User Interface – jointly define how the software should interact with the user

� Design preliminary interfaces o Design the Algorithmic Functions – (if applicable)

� Select or develop algorithms (on paper only) o Create partial requirements specification - used to build the initial prototype

• Produce Software Prototype of System – using the rapid analysis requirements specification o Implement System – building software from specifications and evaluation results

� Create test data



� Create source code � Generate object code � Plan installation � Install software

o Evaluate System – jointly review software prototype • Repeat Production of Software Prototype –incorporating changes learned during evaluation

(if necessary). This step may be repeated several times. Use judgment to plan for cycles of learning.

o Update requirements specification - used to build the revised prototype o Repeat Rapid Analysis– user and designer jointly redesigning from revised

requirements � Analyze System Allocation � Identify Revised Software Requirements

• Conduct preliminary user interviews • Refine and further develop software requirements • Define revised interface requirements • Prioritize and integrate software requirements

o Revise Database– (if applicable) jointly identify the revised database elements � Perform revised architectural design (if needed) � Revise the database design (if needed)

o Revise the User Interface – jointly redefine how the software should interact with the user

� Design preliminary interfaces (if needed) o Revise the Algorithmic Functions – (if applicable)

� Select or develop algorithms (if needed) • Accept Prototype Software Functionality -user formally approves the prototype’s

functionality • Derive Production Software Detailed Design – detailed design is derived from the accepted

rapid prototype o Refine algorithms (if applicable) o Perform detailed design o Produce Production System Design Document

• Implement Production System –transform the Production Software Design description into a software product, producing source code, databases and documentation, whether developed, purchased, or a blend

o Coding – transforming the Detailed Design into a production system � Create source code � Generate object code � Create operating documentation

o Integration – combining software components � Plan integration � Perform integration



o Testing – validating the production design implementation � Plan testing � Develop test requirements � Create test data � Execute the tests

• Install Production System –install and check out the software in the operational environment, tuning as necessary to get formal customer acceptance of the production software

o Plan installation o Distribute software o Install software o Accept software in production operational environment

• Operation and support process – involving user operation of the system and ongoing support, including providing technical assistance, consulting with the user, recording user requests for enhancements, changes, and corrections or errors.


• Maintenance process – resolving requests to address software errors, faults, failures, enhancements, and changes generated by the support process

o Reapply a software life cycle (initiate a new development project) • Retirement process – removing an existing system from its active use, either by ceasing its



• Operation and Maintenance – moving the software into a production state o Distribute software o Install software o Accept software in operational environment o Operate the system o Provide technical assistance and consulting o Maintain support request log



o Software quality management



� Plan software quality management � Define metrics � Manage software quality � Identify quality improvement needs





Rapid Application Development (RAD) Model Activities

The RAD model described in chapter 4 and shown in Figure 4-12 The Rapid Application Development Model, is a special case of a linear model. In the RAD model, the emphasis is on an extremely short development cycle using component-based construction. It is used mainly for information systems applications, especially for client-server architectures.

The activities in Table 9-1 are still used populate the RAD WBS. A typical Rapid Application Development Model’s processes and activities are shown below:

• Plan and Activate the Project – o Initiate the Project

� Map activities to Software Life Cycle Model � Allocate project resources � Establish project environment � Plan project management

• Requirements Planning Phase o Concept exploration – examining requirements at the system level to determine

feasibility, using the Joint Requirements Planning (JRP) approach



� Identify ideas or needs � Formulate potential approaches � Conduct feasibility studies (if applicable) � Plan system transition (if applicable) � Refine and finalize the idea or need

o System allocation process – mapping functions to software or hardware based on the overall system architecture, using the Joint Requirements Planning (JRP) approach

� Analyze functions � Develop system architecture � Decompose system requirements

o Requirements process – defining software requirements for the system’s information domain and function, behavior, performance and interfaces, using the Joint Requirements Planning (JRP) approach

� Define and develop software requirements � Define interface requirements � Prioritize and integrate software requirements

• User Description Phase o Design process – developing and representing a coherent, technical specification of the

software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail, using the Joint Application Design (JAD) approach

� Perform architectural design � Design the database (if applicable) � Design interfaces � Select or develop algorithms (if applicable)

• Construction Phase o Design process – developing and representing a coherent, technical specification of the

software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail, done within a strict time-box

� Perform architectural design � Design the database (if applicable) � Design interfaces � Select or develop algorithms (if applicable) � Perform detailed design

o Implementation process –transforming the software design description into a software product, producing source code, databases and documentation, whether developed, purchased, or a blend

� Create test data � Create source code � Generate object code � Create operating documentation � Plan integration



� Perform integration � Plan testing � Develop test requirements � Execute the tests

• Cut-Over Phase o Installation process –installing and checking out the software in the operational

environment, and getting formal customer acceptance of the software � Plan installation � Distribute software � Install software � Accept software in operational environment




o Verification and Validation � Plan verification and validation � Execute verification and validation tasks � Collect and analyze metric data �



o Training � Plan the training program � Develop training materials



� Validate the training program � Implement the training program

Incremental Model Activities

The Incremental Model described in chapter 4 and shown in Figure 4-13 The Incremental Model is another linear model using the activities in Table 9-1. Actually, it can be a more or less standard life cycle using one of the other models (waterfall, V-shaped, RAD, spiral, etc.). However, in incremental models the complete system is designed early in the project, and the system is delivered and implemented in discrete component releases, typically with ever increasing functionality. Often, the development activities for each discrete component overlap. The number of components to build is decided early in the project. The processes and activities for an example Incremental Model delivering three components for a complete system are shown below:

• Plan and Activate the Project – o Initiate the Project

� Map activities to Software Life Cycle Model � Allocate project resources � Establish project environment � Plan project management

• System Feasibility o Concept exploration – examining requirements at the system level to determine

feasibility � Identify ideas or needs � Formulate potential approaches � Conduct feasibility studies � Plan system transition (if applicable) � Refine and finalize the idea or need

o System allocation process – mapping functions to software or hardware based on the overall system architecture

� Analyze functions � Develop system architecture � Decompose system requirements

• Software plans and requirements o Requirements process – defining software requirements for the system’s information

domain and function, behavior, performance and interfaces � Define and develop software requirements � Define interface requirements � Prioritize and integrate software requirements

o Design process – developing and representing a coherent, technical specification of the software system, including data structures, software architecture, interface representations and some procedural (algorithmic) detail

� Perform architectural design � Design the database (if applicable)



� Design interfaces � Select or develop algorithms (if applicable)

• Product Design – Increment 1 o Design process – developing and representing a coherent, technical specification of the

software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail

� Select or develop algorithms (if applicable) � Perform detailed design

o Code Process - transforming the software design description into a software product, producing source code and databases

� Create test data � Create source code � Generate object code

o Integration Process – combine elements into a working component system � Plan integration � Perform integration

o Implementation process –transforming the software components into an initial installed software product release, with documentation. Installing and checking out the software in the operational environment, and getting formal customer acceptance of the software for increment 1

� Create operating documentation � Plan installation � Distribute software � Install software � Accept software in operational environment

o Operation and Maintenance Process – involving user operation of the system and ongoing support, including providing technical assistance, consulting with the user, recording user requests for enhancements, changes, and corrections or errors.

� Operations Process – use the system in production • Operate the system • Provide technical assistance and consulting • Maintain support request log

� Maintenance process – resolving requests to address software errors, faults, failures, enhancements, and changes generated by the support process

• Reapply a software life cycle (initiate a development project) • Product Design – Increment 2

o Design process – developing and representing a coherent, technical specification of the software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail




o Code Process - transforming the software design description into a software product, producing source code and revised databases


o Integration Process – combine elements into a working component system, integrated into the existing incremental systems

� Plan integration � Perform integration

o Implementation process –transforming the software components into an installed software incremental product release, with documentation. Installing and checking out the software in the operational environment, and getting formal customer acceptance of the software





• Reapply a software life cycle (initiate a development project) • Product Design – Increment 3

o Design process – developing and representing a coherent, technical specification of the software system, including data structures, software architecture, interface representations and procedural (algorithmic) detail


o Code Process - transforming the software design description into a software product, producing source code and revised databases


o Integration Process – combine elements into a working component system, integrated into the existing incremental systems

� Plan integration



� Perform integration o Implementation process –transforming the software components into an installed

software incremental product release, with documentation. Installing and checking out the software in the operational environment, and getting formal customer acceptance of the software





• Reapply a software life cycle (initiate a development project) • Retirement process – removing the existing system from its active use, either by ceasing its









� Plan testing � Develop test requirements � Execute the tests




Spiral Model Activities

As discussed in chapter 4, there are several variations of the Spiral model. All are similar to the rapid prototyping model described earlier in this chapter. One of the Spiral Models described and illustrated in Figure -14 The Spiral Model, is used here as an example. All the Spiral Models are a circular arrangement of most of the activities in Table 9-1, but done linearly several times, with more robust deliverables each time. One version of the Spiral Model’s processes and activities are shown below (many variations are possible):

1st Pass: Project Definition Cycle • Determine Objectives, Alternatives and Constraints - defining the requirements and

specifications for the critical parts of the envisioned system regarding performance, functionality, ability to accommodate change, hardware/software interface, critical success factors, etc.

o Project Definition - developing a preliminary objective and project plan outlining rough schedules and deliverables.

� Initiate the Project • Map activities to Software Life Cycle Model • Allocate project resources • Establish project environment • Plan project management

� Explore the Concept • Identify ideas or needs • Formulate potential approaches • Conduct feasibility studies



• Plan system transition (if applicable) • Refine and finalize the idea or need

• Evaluate Alternatives, Identify and Resolve Risks - evaluating alternatives relative to the objectives and constraints; identifying and resolving risks

o Develop Conceptual Prototype of Selected System Portion - define the requirements and specifications for the riskiest parts of the envisioned system to enable evaluation and a risk assessment – separate into portions by risk

� Design Analysis–designing from preliminary requirements • Analyze System Allocation

o Analyze functions o Develop preliminary system architecture o Decompose preliminary system requirements

• Identify Preliminary Software Requirements o Conduct preliminary user interviews o Define and develop preliminary software requirements o Define preliminary interface requirements o Prioritize and integrate software requirements

• Develop Next Level Product – build a prototype using the information gained in the previous phase

o Create partial requirements specification at system level– includes concept of operation that will be used to build the demonstration prototype design

• Plan Next Phase – Use information from the Develop Next Level Product Phase to plan for the next project phase step

o Re-plan project management o Reformulate potential approaches o Re-plan system transition (if applicable) o Refine the idea or need o Conduct System-Level Concept Review - Accept the demonstration prototype system

concept 2nd Pass: Requirements Review Cycle

• Determine Objectives, Alternatives and Constraints - defining the requirements and specifications for the critical parts of the envisioned system regarding performance, functionality, ability to accommodate change, hardware/software interface, critical success factors, etc.

o Analyze functions for system/product level o Develop system architecture o Decompose system requirements o Define and develop software requirements o Define interface requirements o Prioritize and integrate software requirements for system/product level




o Develop Demonstration Prototype of Selected System Portion - refine the requirements and specifications for the riskiest parts of the envisioned system to enable evaluation and a risk assessment – separate into portions by risk

� Conduct feasibility studies – Perform simulations and benchmarks � Design Analysis–designing from preliminary requirements

• Analyze risks • Perform contingency planning • Analyze System Allocation Further

o Analyze functions further o Develop preliminary system architecture further o Decompose preliminary system requirements further

• Identify Product Software Requirements Further o Conduct user interviews further o Define and develop software requirements further o Define interface requirements further o Prioritize and integrate software requirements further

� Database Creation – (if applicable) identify the preliminary database elements • Perform preliminary architectural design • Design the preliminary database

� Design the User Interface –define how the software should interact with the user

• Design preliminary interfaces � Design the Algorithmic Functions – (if applicable)

• Select or develop algorithms (on paper only) • Develop Next Level Product – build a prototype using the information gained in the previous

phase o Create complete requirements specification – includes detail that will be used to build

the design assessment prototype design • Plan Next Phase – Use information from the Next Level Product Phase step to perform

transition planning for the next project phase step o Re-plan project management o Reformulate potential approaches o Re-plan system transition (if applicable) o Refine the idea or need o Conduct Requirements Review - Accept the design assessment prototype design

3rd Pass: Design Review Cycle • Determine Objectives, Alternatives and Constraints - defining the requirements and




o Analyze functions for design level o Develop system architecture further o Decompose system requirements further o Define and develop software requirements further o Define interface requirements further o Prioritize and integrate requirements for the design level



� Conduct feasibility studies – Perform simulations and benchmarks � Design Analysis–designing from accepted requirements

• Analyze risks • Perform contingency planning • Analyze System Allocation Further

o Analyze functions further o Develop preliminary system architecture further o Decompose preliminary system requirements further

• Identify Product Software Requirements Further o Conduct user interviews further o Define and develop software requirements further o Define interface requirements further o Prioritize and integrate software requirements further

� Database Creation – (if applicable) identify the database elements • Refine architectural design • Refine the database design


• Refine interface design � Design the Algorithmic Functions – (if applicable)

• Refine algorithms (on paper only) • Develop Next Level Product – build a prototype using the information gained in the previous

phase o Derive Software Detailed Design – detailed design is derived from the accepted

requirements � Refine algorithms (if applicable) � Perform detailed design � Produce System Design Document (SDD)

• Plan Next Phase – Use information from the Next Level Product Phase step to perform transition planning for the next project phase step

o Re-plan project management



o Reformulate potential approaches o Re-plan system transition (if applicable) o Refine the idea or need o Conduct Design Review - Accept the operational prototype design

4th Pass: Initial Operational Capability (IOC) Product Review Cycle • Determine Objectives, Alternatives and Constraints - defining the requirements and


o Analyze functions for product level o Develop system architecture further o Decompose system requirements further o Define and develop software requirements further o Define interface requirements further o Prioritize and integrate requirements for the operational level



� Design Analysis–designing from accepted product design • Analyze risks • Perform contingency planning • Analyze System Allocation Further

o Analyze functions further o Develop product system architecture further




• Refine algorithms • Develop Next Level Product – build a prototype using the information gained in the previous

phase o Create an Operational Prototype–transform the Software Design Document

description into the Initial Operational Capability (IOC) software product, producing source code, databases and documentation, whether developed, purchased, or a blend

� Conduct feasibility studies – Perform simulations and benchmarks � Coding – transforming the Detailed Design into an operational system

• Create source code



• Generate object code • Create operating documentation

� Integration – combining software components • Plan integration • Perform integration

� Testing – validating the production design implementation • Plan testing • Develop test requirements • Create test data • Execute the tests

o Install Production System –install and check out the software in the operational environment, tuning as necessary to get formal customer acceptance of the production software

� Plan installation � Distribute software � Install software


o Evaluate System –review operational prototype o Re-plan project management o Reformulate potential approaches o Re-plan system transition (if applicable) o Refine the idea or need o Conduct Product Review - Accept the operational prototype

5th Pass: Final Operational Capability (FOC) Product Review Cycle • Determine Objectives, Alternatives and Constraints - defining the requirements and


o Analyze functions for FOC level o Develop system architecture further o Decompose system requirements further o Define and develop software requirements further o Define interface requirements further o Prioritize and integrate requirements for the final operational level


o Develop Final Operational Capability (FOC) System Design- refine the Operational Prototype for the specified system

� Design Analysis–designing from accepted product design • Analyze risks • Perform contingency planning



• Analyze System Allocation Further o Analyze functions further o Develop product system architecture further




• Refine algorithms • Develop Next Level Product – build a prototype using the information gained in the previous

phase o Create the Final Operational Capability (FOC) System–transform the Updated

Software Design Document description into the Final Operational Capability (FOC) software product, producing source code, databases, documentation and training whether developed, purchased, or a blend

� Conduct feasibility studies – Perform simulations and benchmarks � Coding – transforming the Updated Detailed Design into the FOC operational

system • Create source code • Generate object code • Create operating documentation

� Integration – combining software components • Plan integration • Perform integration

� Testing – validating the Final Operational Capability (FOC) design implementation

• Plan testing • Develop test requirements • Create test data • Execute the tests

o Install Production System –install and check out the software in the operational environment, tuning as necessary to get formal customer acceptance of the production software

� Plan installation � Distribute software � Install software � Perform training


o Evaluate System –review operational prototype



� Re-plan project management � Reformulate potential approaches � Re-plan system transition (if applicable) � Refine the idea or need � Conduct FOC Product Review - Accept the operational system

• Operation and Maintenance – moving the software into a production state o Distribute software o Install software o Accept software in operational environment o Operate the system o Provide technical assistance and consulting o Maintain support request log

• Retirement process – removing an existing system from its active use, either by ceasing its operation, replacing it with a completely new system, or replacing it with an upgraded version of the existing system







o Documentation Development � Plan documentation



� Implement documentation � Produce and distribute documentation


The activity lists shown here are only representative as a life cycle framework for the six common life cycles discussed. Each can (and should) be modified to fit the circumstances of an individual project. Other rearrangements or re-wording of the activities is not only possible but also probable.

For situations where no framework already exists (which may be only for portions of one of the life cycles discussed above), a brainstorming approach is needed to invent the activities. Techniques for this are covered in chapter 14.

Summary

In this chapter we have described the characteristics of tasks and activities that comprise a work breakdown structure for a project. We’ve explored the differences between a task and an activity, and how they relate to the WBS. We showed how the 65 activities from the 17 processes of IEEE 1074 could appear as life cycle templates of activities, ready for tailoring. And we explored the role of maintenance in the software development life cycle.

Problems / Questions

Problem #1

Explain the difference between a task and an activity for a software development project. Give an example of each.

Problem #2

Identify which activities are not present in which of the life cycle work breakdowns discussed.

Problem #3

Give an example of an “optimally sized” activity from your own work experiences.

Visit the Case Study



Dr. Zhou has reviewed your project plan with great thoroughness. She has discovered that your WBS is inconsistent. As a project manager, she assumes you are aware that the PMBOK™ definition of a task is “a generic term for work that is not included in the work breakdown structure.” You attached a copy of your project management plan’s network, Gantt and resource loading charts from Microsoft™ Project. All these charts refer to tasks that you are executing. Dr. Zhou, Mr. Lu and now Ms. Patel want to know why you are working on these things not included in your WBS when you say that the risk of schedule slippage is so high. Please explain this in a PowerPoint presentation to be given at tomorrow’s 7:00AM NetMeeting conference.

References

Additional Readings

Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling 5th Edition, Van Nostrand Reinhold, 1995.

Lewis, James P., Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Projects in on Time and on Budget, McGraw-Hill, 1995.

Paulk, Mark C. et al, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley SEI Series in Software Engineering, 1994, Section 7.2 Software Project Planning and Section 7.3, Software Project Tracking and Oversight.

Pressman, Roger S., Software Engineering: A Practitioner’s Approach, 5th Edition, McGraw-Hill, 2001, Chapter 5, “Software Project Planning,” and Chapter 7, “Project Scheduling and Tracking.”

Web References

http://www.worldbank.org/worldlinks/english/training/world/webproj/define/develop/develop2.htm Building a Collaborative Web Project,�W��Links for Development Program (WorLD) Training Materials

http://stsc.hill.af.mil/crosstalk/1996/apr/project.asp Lynn Satterthwaite, Software Technology Support Center “Project Management: Some Lessons Learned - April 1996”

http://www.pmi.org/standards/wbspractice.htm “Work Breakdown Structure Practice Standard Project—WBS vs. Activities” by Cindy Berg, and Kim Colenso, PM Network, April 2000

http://www.pmi.org/publictn/pmboktoc.htm PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Chapter 6.

chapter 9 identifying tasks - etsmtl.ca

Documents