chapter 9 identifying tasks - etsmtl.ca
TRANSCRIPT
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
Chapter 9 - Identifying the Tasks and Activities
2 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
3 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
4 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
5 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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.
Chapter 9 - Identifying the Tasks and Activities
6 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
7 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
8 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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.
Chapter 9 - Identifying the Tasks and Activities
9 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
10 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
11 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
12 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
Chapter 9 - Identifying the Tasks and Activities
13 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
• 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
Chapter 9 - Identifying the Tasks and Activities
14 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
o Operate the system o Provide technical assistance and consulting o Maintain support request log
• 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 � 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 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
Structured Evolutionary Rapid Prototyping Model Activities
Chapter 9 - Identifying the Tasks and Activities
15 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
Chapter 9 - Identifying the Tasks and Activities
16 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
Chapter 9 - Identifying the Tasks and Activities
17 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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.
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 new 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
• 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
• 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
Chapter 9 - Identifying the Tasks and Activities
18 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
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
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
Chapter 9 - Identifying the Tasks and Activities
19 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
Chapter 9 - Identifying the Tasks and Activities
20 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
• 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 �
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
Chapter 9 - Identifying the Tasks and Activities
21 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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)
Chapter 9 - Identifying the Tasks and Activities
22 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
� Select or develop algorithms (if applicable) � Perform detailed design
Chapter 9 - Identifying the Tasks and Activities
23 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
o Code Process - transforming the software design description into a software product, producing source code and revised databases
� Create test data � Create source code � Generate object code
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
� 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 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
� 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 revised databases
� Create test data � Create source code � Generate object code
o Integration Process – combine elements into a working component system, integrated into the existing incremental systems
� Plan integration
Chapter 9 - Identifying the Tasks and Activities
24 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
� 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) • Retirement process – removing the 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
Chapter 9 - Identifying the Tasks and Activities
25 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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
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
Chapter 9 - Identifying the Tasks and Activities
26 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
• 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
Chapter 9 - Identifying the Tasks and Activities
27 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
• Evaluate Alternatives, Identify and Resolve Risks - evaluating alternatives relative to the objectives and constraints; identifying and resolving risks
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
specifications for the critical parts of the envisioned system regarding performance, functionality, ability to accommodate change, hardware/software interface, critical success factors, etc.
Chapter 9 - Identifying the Tasks and Activities
28 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
• Evaluate Alternatives, Identify and Resolve Risks - evaluating alternatives relative to the objectives and constraints; identifying and resolving risks
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 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
� Design the User Interface –define how the software should interact with the user
• 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
Chapter 9 - Identifying the Tasks and Activities
29 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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
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 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
• Evaluate Alternatives, Identify and Resolve Risks - evaluating alternatives relative to the objectives and constraints; identifying and resolving risks
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
� 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
� Database Creation – (if applicable) identify the database elements • Refine architectural design • Refine the database design
� Design the User Interface –define how the software should interact with the user
• Refine interface design � Design the Algorithmic Functions – (if applicable)
• 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
Chapter 9 - Identifying the Tasks and Activities
30 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
• 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
• Plan Next Phase – Use information from the Next Level Product Phase step to perform transition planning for the next project phase step
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
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 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
• Evaluate Alternatives, Identify and Resolve Risks - evaluating alternatives relative to the objectives and constraints; identifying and resolving risks
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
Chapter 9 - Identifying the Tasks and Activities
31 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
• Analyze System Allocation Further o Analyze functions further o Develop product system architecture further
� Database Creation – (if applicable) identify the database elements • Refine architectural design • Refine the database design
� Design the User Interface –define how the software should interact with the user
• Refine interface design � Design the Algorithmic Functions – (if applicable)
• 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
• Plan Next Phase – Use information from the Next Level Product Phase step to perform transition planning for the next project phase step
o Evaluate System –review operational prototype
Chapter 9 - Identifying the Tasks and Activities
32 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� 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 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
o Software Configuration Management � Plan configuration management � Develop configuration identification � Perform configuration control � Perform status accounting
o Documentation Development � Plan documentation
Chapter 9 - Identifying the Tasks and Activities
33 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
� Implement documentation � Produce and distribute documentation
o Training � Plan the training program � Develop training materials � Validate the training program � Implement the training program
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
Chapter 9 - Identifying the Tasks and Activities
34 of 34 Quality Software Project Management Copyright 2002 © Prentice Hall
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.