An outcome of project analysis will be the selection of the most appropriate methodologies and technologies. Methodologies include techniques like the various flavours of object-oriented (OO) development, SSADM and JSP (Jackson Structured Programming) while technologies might include an appropriate application-building environment, or the use of knowledge-based system tools.
As well as the products and activities, the chosen technology will influence the following aspects of a project:
• the training requirements for development staff;
• the types of staff to be recruited;
• the development environment - both hardware and software;
• system maintenance arrangements.
We are now going to describe some of the steps of project analysis.
Identify project as either objectives-driven or product-driven
You will recall from Chapter 1 that we distinguished between objectives-driven and product-driven projects. Very often a product-driven project will have been preceded by an objectives-driven project which chose the general software solution that is to be implemented.
There will be cases where things are so vague that even the objectives of the project are uncertain or are the subject of disagreement. People may be experiencing a lot of problems but no-one knows exactly what the solution to the problems might be. It could be that the IT specialists can provide help in some places but assistance from other specialisms is needed in others. In these kinds of situation a soft systems approach might need to be considered.
Analyse other project characteristics
The sorts of question that would need to be asked include the following.
• Is a data orientated or a control orientated system to be implemented?
'Data orientated* systems generally mean information systems that will have a considerable database. 'Control orientated' systems refer to embedded control systems. These days it is not uncommon to have systems with components of both types.
• Will the software that is to be produced be a general package or application specific? An example of a general package would be a spreadsheet or a word processing package. An application specific package could be, for example, an airline seat reservation system.
• Is the system to be implemented of a particular type for which specific tools have been developed? For example:
The soft systems approach is described in Checkland, P. and Scholes, J., Soft systems methodology in action, John Wiley and Sons, 1990.
We first introduced the difference between information systems and embedded systems in Chapter 1.
• does it involve concurrent processing? - if so the use of techniques appropriate to the analysis and design of such systems would be considered;
• will the system to he created he knowledge-based? - expert systems have a set of rules which result in some 'expert advice' when applied to a problem domain (sets of methods and tools have been developed to assist in the creation of such systems); or
• will the system to be produced make heavy use of computer graphics?
• Is the system to be created safety-critical? For instance, could a malfunction in the system endanger human life?
• What is the nature of the hardware/software environment in which the system will operate? It might be that the environment in which the final software will operate is different from that in which it will be developed. Embedded software may be developed on a large development machine that has lots of supporting software tools in the way of compilers, debuggers, static analysers and so on, but might then be down-loaded to a small processor in the larger engineered product. A system destined for a personal computer will need a different approach to one destined for a main-frame or a client-server environment.
Exercise 4.1 How would you categorize each of the following systems according to the classification above?
(a) a payroll system
(b) a system to control a bottling plant
(c) a system that holds details of the plans of plant used by a water company to supply water to consumers
(d) a software application to support project managers
(e) a system used by lawyers to get hold of case law relating to company taxation.
When we first embark on a project we might be expected to work out elaborate plans even though we are at least partially ignorant of many important factors that will affect the project. For example, until we do a detailed investigation of the users' requirements we will not be able to estimate how much effort will be needed to build a system to meet those requirements. The greater the uncertainties at the beginning of the project, the greater the risk that the project will be unsuccessful. Once we recognize a particular area of uncertainty we can, however, take steps to reduce its uncertainty.
One suggestion is that uncertainty can be associated with the products, processes, or resources associated with the project.
Chapter 3 has already touched on some aspects of risk, which are developed further in Chapter 8.
Product uncertainty Here we ask how well the requirements are understood. It might be that the users themselves are uncertain about what a proposed information system is to do. The government, say, might introduce a new form of taxation but the way this is going to operate in detail will not be known until a certain amount of case law has been built up. Some environments can change so quickly that what was a precise and valid statement of requirements rapidly becomes out of date.
Process uncertainty It might be that the project under consideration is the first OMT is an object-oriented where an organization has tried to use a method, such as SSADM or OMT, that is design approach, new to them. Perhaps a new application building tool is being used. Any change in the way that the systems are developed is going to introduce uncertainty.
Resource uncertainty The main area of uncertainty here will almost surely be the availability of staff of the right ability and experience. A major influence on the degree of uncertainty in a project will be the sheer size of a project. The larger the number of resources needed or the longer the duration of the project, the more inherently risky it is likely to be.
Euromethod, which is reviewed briefly in Appendix C, distinguishes between factors that increase uncertainty, for example, continually changing requirements, and those that increase complexity, for example, software size. This is because it suggests different strategies to deal with the two distinct types of risk.
At IOE, Amanda has identified possible staff resistance as a risk to the Exercise 4.2 maintenance group accounts project. Would you classify this as a product, process or resource risk? Perhaps it does not fit into any of these categories and some other is needed.
Brigette at Brightmouth College identified the possibility that no suitable payroll package would be available on the market as a risk. What other risks might be inherent in the Brightmouth College payroll project?
Take into account user requirements concerning implementation
A user organization lays down standards that have to be adopted by any contractor providing software for them. For example the UK Civil Service favours the SSADM standard where information systems are being developed.
It is common for organizations to specify that suppliers of software have BS EN Chapter 12, Software ISO 9001:1994 or TickIT accreditation. This will affect the way projects are quality, discusses BS EN conducted. ISO 9001 and TickIT.
Control systems A real-time system will have to be implemented using an appropriate methodology, for example, Mascot. Real-time systems that employ concurrent processing will use techniques such as Petri nets.
The implications of prototyping and the incremental approach are explored later in the chapter.
Information systems Similarly, an information system will need a methodology, such as SSADM or Information Engineering, that matches that type of environment. SSADM will be especially appropriate where the project will employ a large number of development staff whose work will need to be coordinated: the method lays down in detail what needs to be done and what products need to be created at each step. Team members would therefore know exactly what is expected of them.
General applications Where the software to be produced is for the general market rather than for a specific application and user, then a methodology such as SSADM would have to be thought about very carefully. This is because the framers of the method make the assumption that a specific user exists. Some parts in the method also assume that there is an existing system that can be analysed to yield the logical features of the new, computer-based, system.
Specialized techniques These have been invented to expedite the development of, for example, knowledge-based systems where there are a number of specialized tools and logic based programming languages that can be used to implement this type of system. Similarly a number of specialized techniques and tools have been developed to assist in the development of graphics-based systems.
Hardware environment The environment in which the system is to operate can put constraints on the way it is to be implemented. For instance, the need for a fast response time or for the software to take up only a small part of computer memory may mean that only low-level programming languages can be used - particularly in real-time and embedded systems.
Safety-critical systems Where safety and reliability are of the essence, it might be possible to justify the additional expense of a formal specification using a notation such as Z or VDM. Really critical systems call for expensive measures such as having independent teams develop parallel systems with the same functionality. The parallel systems can then run concurrently when the application is in operation so that the results of each of the parallel systems can be crosschecked.
Imprecise requirements Uncertainties or a novel hardware/software platform may mean that a prototyping approach should be considered. If the environment in which the system is to be implemented is a rapidly changing one, then serious consideration would need to be given to incremental delivery. If the users have uncertain objectives in connection with the project, then a soft systems approach might be desirable.
Exercise 4.3 Bearing in mind the discussion above, what, in broad outline, is the most suitable approach for each of the following?
(a) a system that calculates the amount of a drug that should be administered to a patient who has a particular complaint;
(b) a system to administer a student loans scheme;
(c) a system to control trains on a railway network.
The analysis described above will produce a number of practical requirements that will be fed into the next stage of the planning process. These requirements might add activities to the project and might involve the acquisition of items of software or hardware or the adoption of particular methodologies which might require staff training. As these recommendations imply certain costs, they should be recorded formally.
A preliminary version of this technical plan can be produced by a software house to help in the preparation of the bid for a contract. In some cases, it may actually be shown to the potential customer in order to show the basis for the bid price and generally to impress the customer with the soundness of the approach the software house intends to adopt. The technical plan is likely to have the following contents.
1. Introduction and summary of constraints:
(a) character of the system to be developed;
(b) risks and uncertainties of the project;
(c) user requirements concerning implementation.
2. Recommended approach:
(a) selected methodology or process model;
(b) development methods;
(c) required software tools;
(d) target hardware/software environment.
(a) required development environment;
(b) required maintenance environment;
(c) required training.
(a) project products and activities - these will have an effect on the schedule duration and overall project effort;
(b) financial - this report will be used to produce costings.
The word 'process' is sometimes used to emphasize the idea of a system in action. In order to achieve an outcome, the system will have to execute one or more activities: this is its process. This idea can be applied to the development of computer-based systems where a number of interrelated activities have to be undertaken to create a final product. These activities can be organized in different ways and we can call these process models.
A major part of the planning will be the choosing of the development methods to be used and the slotting of these into an overall process model.
The planner needs not only to select methods but also to specify how the method is to be applied. With methods such as SSADM, there is a considerable degree of choice about how it is to be applied: not all parts of SSADM are compulsory. Many student projects have the rather basic failing that at the planning stage they claim that, say, SSADM is to be used: in the event, all that is produced are a few SSADM fragments such as a top level data flow diagram and a preliminary logical data structure diagram. If this is all the particular project requires, it should be stated at the outset.
Was this article helpful?
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.