Characteristics of Tasks and Activities

Characteristics of Tasks and Activities

How difficult 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 deal with is what tasks and activities are. These were first visited in "Introduction", 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 WBS but that 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 include designing, coding, compiling, debugging and documenting. Skills in various programming languages and with a collection of software development tools fall into the task realm for a software project. Those are things that you would expect a skilled software practitioner to already know how to do. In this section, we 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 the label, size, and source.

Meaningful Label

Many developers seem to believe that the SPMP 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 explain the work with more accuracy and meaning. The most obvious requirement for an activity ID is that it should clearly explain the work to be done. However, too many developers and managers don't use enough verbs in their activity labels that are supposed to explain processes. Instead of an activity label such as "build a C compiler", it might appear as just "C compiler". This leaves uncertainty 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 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 because 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 because 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 because further explanation and qualification can take place 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 "Creating the Work Breakdown Structure", 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 sufficient measurement for goal achievement and that the project team is willing to measure.

At first, 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 ("Eliciting Requirements") and the software size can be estimated ("Software Size and Reuse Estimating") to help determine the effort required ("Estimating Duration and Cost"), a more precise sizing of activities can happen.

Keep in mind 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 required 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 instance, 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 subactivities "design main functions menu" and "design utility menu". Again, break down work only as far as is practical for the work to be understood and manageable for the organizational maturity of the project's environment.


From where do you get a list of activities and tasks to run a software development project and make a software product? The source depends on whether there is any project precedent. If neither you nor your organization has done a project like this before or has 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 explained later. If there is a project precedent, reviewing the activities used on it can provide some guidance for activity identification. Even if no precedent exists, professional organizations such as the SEI, ISO, or IEEE provide sources for software development activities. The SEI models have been discussed elsewhere. ISO/IEC 12207 lists 12 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 testing

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


spmp, development tools, software project, life cycle
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 2018 SPMInfoBlog.
Designed by TechPlus