§ What was the effort on similar projects overall and by task?
§ How do the skills of the people on similar projects compare with those of the current project staff?
Finding Similar Projects A similar project may be one that has the same tasks that were done by the same people, used the same programming language, or met other criteria. A project history database must enable the search for similar projects. This implies that all projects must be performed using a standard set of tasks, just as accounting costs must be analyzed using a standard chart of accounts. If each
project manager makes up the names of the tasks on each project, how can projects be compared with one another? As discussed in the next section, a methodology should provide the enterprise with its chart of accounts.
Determining Past Effort and Skills Once the similar projects are chosen, the manager of the new project needs to know the effort on similar projects, overall and by task, and the skills of those who worked on these projects. The manager can find this information if the time and cost spent has been recorded in a standard way and if data is reasonably complete. To quote productivity expert Capers Jones, “The historical data for projects used internally by corporations is close to worthless for economic studies. Direct user costs are essentially never tracked, unpaid overtime is seldom tracked, and carelessness in charging time to the correct set of project accounts is rampant in the MIS domain.”[2]
Automated process management tools must make the recording of actual effort against standard categories inexpensive and easy for everyone putting in time on a project; then project history can become a meaningful aid to estimating.
Roll-Up of Estimates
Using experience to size a project from the top down has value because it can be done early in the project when only general knowledge about the physical design is available. Function point counting, however, is based on physical information about files, inputs, and outputs.
The most reliable method of estimating, although the most time -consuming, is to make an estimate for each piece of work jointly with the team member who is responsible for it and to combine the estimates from the bottom up. Bottom-up estimating involves answering three questions:
§ What tasks have to be done?
§ Who is going to do them?
§ How long will they take to complete? (Detailed estimates can be imposed on or negotiated with employees.)
A project leader talented in informal project management can negotiate tight but achievable estimates as well as obtain personal commitment from the staff members.
Firm commitment can only be made once the design is known at least in outline form.
Top-down estimates are made early in a project, done cheaply, and often changed.
Bottom-up estimates are set, costly to produce, and established later in a project.
[1 ]C. Jones, Applied Software Measurement, New York: McGraw-Hill, 1991.
[2 ]Jones, pp. 127–128.
METHODOLOGY: WHAT IT IS AND HOW IT HELPS
Methodology, a word with multiple meanings, is often used carelessly to make some simple technique or approach sound more impressive than it is. A precise definition of the term is:
A methodology is a generic knowledge base about tasks, techniques, deliverables, roles, tools, and tool use for carrying out some complex class of projects such as system development, plus a mechanism for adapting a generic knowledge base to each specific project.
Methodology Tasks At minimum, a methodology is a description of tasks to be done in developing a system. The scope of a methodology might be wider than just development and cover planning, enhancement, and maintenance. Tasks can include designing the database and coding the programs. Each task typically has one or more recommended steps to be done in sequence.
Methodology Techniques Some methodologies provide a somewhat detailed description of how to do tasks. However, these descriptions usually apply to more than one task. For example, a description of how to do a data flow diagram applies to the task of defining the process model as well as to the task of designing the transaction flow. Especially when a methodology is stored in a knowledge base on disk, it is convenient to separate the technique descriptions from the tasks and to provide a way (e.g., hypertext) to display a technique for a relevant task only when needed.
Deliverables Each task should produce some tangible output, usually called a deliverable or work product. For example, designing a database should produce a deliverable — database design — and the methodology should specify what a database design may contain.
Roles A methodology should also deal with the skills for each task. The most flexible way of doing this is to define roles. On a given project, one person may play several roles, or one role may be played by several people. The methodology should specify the role responsible for each task, and the other roles that may contribute to the task. Thus, for the task of designing the database, the prima ry role might be the DBMS specialist and the contributing role, the modeling specialist. For each role, a methodology should define the skills, experience, and background that are relevant.
Exhibit 1 shows an example of a task/deliverable description, with the names of the various roles and techniques associated with it.
Exhibit 1. A Simple Task/Deliverable Entry from the Knowledge Base Task
Carry out Discovery Prototyping Task- ID A0540
Purpose
If users find it difficult to describe their requirements in terms of data and logic, discovery prototyping can help clarify their needs by getting their feedback on generic prototypes. The technique prototyping gives details of three types:
Task
Carry out Discovery Prototyping Task- ID A0540
Discovery prototyping
Behavior prototyping
Production prototyping
Discovery prototyping is used as an aid to uncover requirements when users do not relate well to modeling techniques. It may consist of screen mockups, visits to other computerized offices, and product
demonstrations. The prime purpose is neither to build a system nor to determine in detail how the system will work; rather it is to determine what, exactly, are the requirements that users have.
Responsible Development Team Member
(Hypertext to Role Descriptions)
Contributors User Team Members
Need to
Development Project Manager Decision
start
Other
Any available data model or data requirements
inputs
Steps in
If the development project manager decides that this task is relevant, task
then:
An assigned development team member develops generic screen
or report layouts and exercises them with selected user team members.
Development team members must emphasize that what they are seeing is only a false front with no necessary similarity to the eventual system or interface. See Technique: Prototyping (Hypertext to Technique Description)
The development team member revises the generic layouts
based on user feedback and exercises them iteratively with user team members until no more requirements are identified.
The development team member revises the data model on the
basis of the discovery prototype findings.
This Task Produces:
Deliverable Discovery Prototype ID 1.40.05
Contents
Screens, screen-to-screen flow diagrams, or pointers to files where actual discovery prototypes can be found.
Exhibit 2. Methodology Metamodel
Roles are an important way to involve the right businesspeople in the project in the right way. Just as one of the principles of business process reengineering is to consider how the process adds value for its ultimate customer,[3] so the definition of roles that need to be played by various members of the business community helps to ensure that the application adds value to the business.
Task Dependencies If a methodology is to be useful for project planning, it should contain information about which tasks must be completed before other tasks can be started. For example, a methodology can stipulate that the task of designing the database is a predecessor to the task of specifying data security constraints.
Tools and Their Use Increasingly, deliverables are produced with software tools that often run on workstations. A methodology must describe each relevant tool and enable tools to be linked to tasks so that developers know which tools are recommended for which tasks. In many cases, a methodology also lists tips, tricks, and traps that are associated with using a specific tool to do a specific task.
It is convenient to store tool usage descriptions separately from the tool description itself. For example, in addition to a description of a spreadsheet tool, the tool usage of a methodology for the task define the users at various locations might read,
“Always list the locations down the y-axis of the spreadsheet and the types of user across the top.”
Phases and Deliverable Packages Tasks are usually grouped in phases, primarily for management control purposes. As development projects become more iterative, phases have less and less meaning, because the same tasks are being repeated for each iteration of the prototype or each version of the development application. It is often clearer to focus on packages of deliverables that may be grouped for management or user review. These deliverable packages may have such names as requirements package, discovery prototype package, and outline design package.