Ads
  

The Activity ID Process

The Activity ID Process

There are in fact 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 again for a unique development project situation. Either way, customization takes place. We'll consider both approaches and discover how to select and organize tasks for a software development project. First, in this section, let's consider how we use these sources as a guide to activity identification for a given software project. Then, in "Considering Dependencies", we'll look at ways to invent them when 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 ("Selecting Software Development Life Cycles " Figure ). These are shown in Table 1, which is a tabular form of "Selecting Software Development Life Cycles" Figure, with activities added. The 34 competencies that every software project manager should know directly relate to the 65 software development project activities shown, and they are explained in more detail elsewhere in this blog.

Development (product) activities may contain analysis, high-level design, low-level design, coding, testing, and other tasks that happen in the life cycle phases. Managerial activities may contain project planning, tracking, control, risk analysis, and so on. Support activities may contain documentation of deliverables such as a user's manual, operations guides, network communications, and so on. 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 contain 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.

The challenge for every software development project manager is to map the activities in Table 1 into a life cycle model that fits the current project situation, and then describe them in enough detail for the organization's personnel to understand and implement. Each of the activities in the table may need further breakdown to be useful to your project team. For instance, "plan configuration management" may be all that is required for a project in an organization in which a sophisticated configuration management (CM) system and process are in place and in which the staff is trained for its proper use. The activity may need only a minimal work package description, such as "arrange for CM support from department coordinator". No separate software configuration management plan (SCMP) document is required. 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 significantly more work, including 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 should be developed. The scope of these two activity extremes is very different, as is the effort to carry them out.
IEEE 1074 Software Development Product Life Cycle Processes and Activities


Another thing to note about the activities in Table 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 "Selecting Software Development Life Cycles". Here, we will study the common types of life cycle models derived from different arrangements of the activities in Table 1. We will consider the activities and corresponding descriptions for the following software development life cycles explained in more detail in "Selecting Software Development Life Cycles":

● Waterfall model

● V-shaped model

● Structured evolutionary rapid prototyping model

● Rapid application development (RAD) model

● Incremental model

● Spiral model

Each of these life cycle models has a different set of activities and tasks for the main development portions. The integral process activities (e.g., configuration management, verification, documentation) are all the same for each model. Table 2 shows the checklist for those common tasks and activities. It should be used as a companion to all of the other life cycle checklists.

Integral Activities for All Life Cycle Models

You will note that many of these life cycles derived from sources such as IEEE 1074 contain both product development and ongoing maintenance operations in their design. Recall "Project Planning" Figure (c). 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 (often called "sustaining") normally 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 (a).

Typical Software Maintenance Life Cycle 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 two-thirds of the total costs for an average software product during its lifetime. Because perfection at initial release is unlikely for most software products, some corrective maintenance can be expected to take place 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 discussed next contain these operations and maintenance activities in their descriptions, and some do not.

One other thing to note about the activity arrangements for a WBS in the models 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 doing certain activities repeatedly. For example, the spiral model can be thought of as a 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 explained in "Selecting Software Development Life Cycles" and depicted in "Software Development Life Cycle Models" Figure (b), the waterfall model is a linear arrangement of most of the activities in Table 1. These are arranged into phases using the processes and activities shown in Table 3.

Waterfall Model Checklist of Potential Activities and Tasks


V-Shaped Model Activities

The V-shaped model, explained in "Selecting Software Development Life Cycles" and shown in "The V-Shaped Software Development Life Cycle Model" Figure, is a linear arrangement of most of the activities in Table 1, similar to the waterfall model. The checklist for the V-shaped model's tasks and activities is shown in Table 4.

V-Shaped Model Checklist of Potential Activities and Tasks



Structured Evolutionary Rapid Prototyping Model Activities

The structured evolutionary rapid prototyping model, explained in "Selecting Software Development Life Cycles" and demonstrated in "The Prototype Software Development Life Cycle Model" Figure, is a circular arrangement of most of the activities in Table 1, but it is done linearly several times, with more robust deliverables each time. One version of the structured evolutionary rapid prototyping model's tasks and activities is shown in Table 5.

Rapid Prototyping Model Checklist of Potential Activities and Tasks




Rapid Application Development (RAD) Model Activities

The RAD model, explained in "Selecting Software Development Life Cycles" and shown in "The Rapid Application Development (RAD) Software Development Life Cycle Mod" Figure, 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 1 are still used to populate the RAD WBS. A typical RAD model's tasks and activities are shown in Table 6.

RAD Model Checklist of Potential Activities and Tasks


Incremental Model Activities

The incremental model, explained in "Selecting Software Development Life Cycles" and shown in "The Incremental Software Development Life Cycle Model" Figure, is another linear model using the activities in Table 1. In fact, it can be a more or less standard life cycle using one of the other models (waterfall, V-shap6ed, RAD, spiral, etc.). On the other hand, in incremental models, the complete system is designed early in the project, and the system is delivered and implemented in discrete component releases, usually with ever-increasing functionality. Sometimes, the development activities for each discrete component overlap. The number of components to build is decided early in the project. The tasks and activities for an example incremental model delivering three components for a complete system are shown in Table 7.

Incremental Model Checklist of Potential Activities and Tasks





Spiral Model Activities

As discussed in "Selecting Software Development Life Cycles", there are many variations of the spiral model. All are similar to the rapid prototyping model explained earlier in this section. The spiral model described and illustrated in "The Spiral Software Development Life Cycle Model" Figure (a) is used here as an example. All the spiral models are a circular arrangement of most of the activities in Table 1, but done linearly many times, with more robust deliverables each time. One version of the spiral model's tasks and activities is shown in Table 8.

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 rewording of the activities is not only possible, but also probable.

Spiral Model Checklist of Potential Activities and Tasks









For situations in which no framework already exists (which may be only for portions of one of the life cycles discussed), a brainstorming approach is required to invent the activities. Techniques for this are covered in "Considering Dependencies".



Tags

life cycle, checklists, maintenance activities, software products, deliverables, software project
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus