Requirement specification

Very often, especially in the case of product-driven projects, the objectives of the project are carefully defined in terms of functional requirements, quality requirements, and resource requirements.

• Functional requirements These define what the system that will be the end product of the project is to do. Systems analysis and design methods, such as SADT and Information Engineering, are designed primarily to provide functional requirements.

• Quality requirements There will be other attributes of the system to be implemented that do not relate so much to what the system is to do but how it is to do it. These are still things that the user will be able to experience. They include, for example, response time, the ease of using the system and its reliability.

• Resource requirements A record of how much the organization is w illing to spend on the system. There will usually be a trade-off between this and the time it takes to implement the system. In general it costs disproportionately more to implement a system by an earlier date than a later one. There might also be a trade-oft" between the functional and quality requirements and cost. We would all like exceptionally reliable and user-friendly systems that do exactly what we want but we might not be able to afford them.

1.12 Information and control in organizations

Hiernrchic.il information and control systems

With small projects, the project leaders are likely to be working very closely with the other team members and might even be carrying out many non-managerial tasks themselves. Therefore they should have a pretty good idea of what is going on. When projects are larger, many separate teams will be working on different aspects of the project and the overall managers of the project are not going to have day-to-day direct contact with all aspects of the work.

I-arger projects are likely to have a hierarchical management structure (Figure 1.3). Project team members will each have a group leader who allocates them work and to whom they report progress. In turn the group leader, along with several other group leaders, will report to a manager at the next higher level. That manager might have to report to another manager at a higher level, and so on.

There might be problems that cannot be resolved at a particular level. For example, additional resources might be needed for some task, or there might be a disagreement with another group. These will be referred to the next higher level of management.

At each higher level more information will be received by fewer people. There is thus a very real danger that managers at the higher levels might be overloaded with too much information. To avoid this, at each level the information will have to be summarized.

The larger the proiect. the b«gger the communication problems

The referral of disagreements to a higher level is sometimes known as escalation.

Figure 1.3 Management information flows up the organizational structure ami control flows down.

As a result of examining the progress information and comparing it against what was planned, some remedial action might need to he taken. Instructions may be formulated and passed down to a lower level of management. The lower level managers will have to interpret what needs to be done and formulate more detailed plans to fulfil the directive. As the directives filter down the hierarchy, they will be expanded into more detail at each level.

Not all information flows concerning a project will be going up and down the hierarchy. There will also be lateral flows between groups and individuals on the same level.

Levels of decision ma king and information

Each decision made in a project environment should be based on adequate information of the correct sort. The type of information needed depends on the level of decision making. Decisions can be grouped at three levels: strategic, tactical, and operational.

Strategic decision making is essentially about deciding objectives. In the case of the Brightmouth College payroll, the decision to become administratively independent could be regarded as a strategic decision. In our example we were interested only in the payroll, but this might have been part of a wider programme which may have affected many other administrative functions.

Tactical decision making is needed to ensure that the objectives will be fulfilled. The project leader who has the responsibility for achieving objectives will have to formulate a plan of action to meet those objectives. The project leader will need to monitor progress to see whether these objectives are likely to be met and to take action where needed to ensure that the things remain on course.

Operational decisions relate to the day-to-day work of implementing the project. Deciding the content of the acceptance tests might come under this heading.

Differences in types of information

Table I. I gives some idea of the differences in the kind of information needed. There is a kind of continuum for most of the qualities suggested and what is needed for tactical decision making comes somewhere in the middle.

Effectiveness is concerned with doing the right thing. Efficiency is carrying out a task making the best possible use of the resources.

Measurement

The quantification of The leader of a small project will have direct contact with many aspects of the measures of effectiveness project. With larger projects, project leaders would have to depend on information reduces ambiguity. being supplied to them, litis information should not be vague and ideally should be quantitative. This ties in with our need for unambiguous measures of effectiveness.

Software development deals largely with intangibles and does not easily lend itself to quantitative measures, but attempts are increasingly being made to introduce measurement into the software process.

For example, a programmer will receive a specification from an analyst and might then seek clarification.

Table I. I The types of information required for decision making

Characteristic

Operational

Strategic orientation focus detail motivation efficiency internal effectiveness internal and external specific to organization summarized not so fast flexible desirable approximate often predictive more subjective often qualitative specific to a function response access paths up-to-dateness accuracy certainty objectivity information type detailed fast standard essential essential essential high mainly quantitative

Software measurements can be divided into performance measures and predictive measures.

• Performance measures These measure the characteristics of a system that has been delivered. They are important when we are trying to specify unambiguously the quality requirements of a proposed system.

• Predictive measures The trouble with performance measures is that you need to have a system actually up and running before you can take measurements. As a project leader, what you want to be able to do is to get some idea of the likely characteristics of the final system during its development. Predictive measures are taken during development and indicate what the performance of the final system is likely to be.

l-'or example, the errors found per KI.OC (that is. thousand lines of code) at different stages of the project might help to predict the correctness and reliability of the final system. Keystrokes required to carry out a particular transaction might help predict what the operator time to carry out the transaction is likely to be. Modularity, the degree to which the software is composed of self-contained manageable components, helps predict how easy changes to the final system will be.

1.13 Conclusion

This chapter has laid a foundation for the remainder of the book by defining what is meant by various terms such as 'software project' and 'management'. Among some of the more important points that have been made are the following.

• Projects are by definition non-routine and therefore more uncertain than normal undertakings.

Performance measures include mean time between failures (reliability) and time to learn an application (usability).

• Software projects are similar to other projects, but have some attributes that present particular difficulties, for example, the relative invisibility of many of their products.

• A key factor in project success is having clear objectives. Different stakeholders in a project, however, are likely to have different objectives. This points to the need for a recognized overall project authority.

• For objectives to be effective, there must be practical ways of testing that the objectives have been met. Hence there is a need for measurement.

• Where projects involve many different people, effective channels of information have to be established. Having objective measures of success helps unambiguous communication among the various parties to a project.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment