The Software Development Life Cycle
2.5 THE PRELIMINARY INVESTIGATION STAGE
We will now describe each stage of the PDM.
Figure 2.6 The general systems model of the firm
A similar framework is the model of the fi rm in its environment in Figure 2.7.
This diagram shows eight elements that exist in the fi rm’s environment. The fi rm is connected to the elements by resource fl ows of personnel, materials, machines, money, data, and information. This model enables the developers to recognize all of the environmental elements and consider their relationships within the fi rm.
With this understanding of the enterprise and its environment, the developers can turn their attention to the system and project at hand.
2.5.2 Define System Goals, Objectives, and Performance Criteria
System goals are conditions or situations of great business importance that are to be attained. They are the reason for the project and take such forms as improved responsiveness, increased quality, and improved decision making. System objectives are more specifi c targets that, when achieved, should lead to accomplishment of the goals.
Figure 2.7 The firm in its environment
2.5 The Preliminary Investigation Stage 39
Figure 2.8 is a goal analysis form that the developers can complete to address three main goal categories:
system quality,
project management, and
relevance of the system to the organization.[13]
The left-hand side of the form lists these main goals and their subgoals. In the center column, the developers can enter notes that describe the current situation and/or the requirements to be met by the system and project. In the right-hand column, the developers can enter actions that will be needed to meet the goals. This example contains only entries for a sampling of the cells. For a project, the developers make entries in all cells.
It is always a good idea to identify quantitative measures of the new system per- formance so as to avoid the risk of failing to create a system that satisfi es the users’
perception of the system goals. The term performance criteria is used to describe these quantitative measures for specifi c objectives. For example, if a goal of the new system is to process customer sales orders faster, then a performance criterion could be to process a customer sales order within 3 hours after receipt in the sales depart- ment if it currently takes 4 hours. With the goals quantifi ed in such a specifi c way, it will be relatively easy to test the extent to which the system meets these objectives during development. If the system achieves the performance criteria objectives, then achievement of the more general goals is assured.
1.
2.
3.
Current context and requirements
Actions needed to meet goals System quality
Frequent out-of-stock Functionality
conditions, excessive inventory costs.
Implement computed - reorder points and economic order quantiy.
Maintainability Portability/Scalability
Project management
Timeliness Management wants new
inventory system as soon as possible.
Manage project with Gantt chart and milestone dates report.
Cost
Client commitment Organizational relevance Decision-making
effectiveness
Buyers have incomplete information for supplier selection.
Maintain data for each supplier on cost, quality, and shipping response.
Operations efficiency Competitive advantage Figure 2.8 A goal analysis form
2.5.3 Evaluate System and Project Risk
As the developers embark on the project, they should identify any risks that they might face in terms of project or system failure. The project risk evaluation form in Figure 2.9 shows how attention can be directed at four categories that can infl uence risk:
characteristics of the organization, the information system being developed, the developers, and
the users.
1.
2.
3.
4.
Factors affecting project risk
Rating
(–1, 0, +1) Comments Organization
Has well-defined objectives? +1 Has strategic business plan
Is guided by a strategic information system plan?
Proposed system supports achievement of organizational objectives?
Information system
Existing model? Clear requirements? +1 Existing system well documented Automates routine, structured procedures?
Affects only a single business area?
Uses proven technology?
Can be implemented in less than 3 months?
Installation at only a single site?
The developers
Are experienced in the chosen methodology? –1 First time to use object- oriented methodology Are skilled at determining functional
requirements?
Are familiar with information technology?
The users
Have business area experience? 0 Some are experienced;
some are new to the area Have development experience?
Are committed to the project?
Total points +1
Figure 2.9 Project risk evaluation form
2.5 The Preliminary Investigation Stage 41
The form lists specifi c characteristics for each category that are rated and described by the developers. When a characteristic (such as the absence of well- defi ned objectives) is considered to offer a risk, it receives a rating of 1. When it does not offer a risk (such as the presence of well-defi ned objectives), it is rated 1. When the situation is borderline, it receives a rating of 0. In this ex- ample, only a sampling of the cells is completed. The rating points are summed, and the total provides an indication of the degree of risk to be faced. This total is not an absolute indicator: if the total points are positive, there may still be unacceptable business risk in the project, or if the total points are negative, the business risk may be acceptable. It usually takes the tracking and comparison of risk evaluation and actual risk results from several projects to be able to accu- rately interpret the meaning of the total risk points for a particular development organization for future projects.
The developers should address any characteristics receiving a rating of 0 or 1 by specifying one or more risk reduction strategies to be taken. Good risk reduction strategies are matched resources and skills with project needs, realistic completion schedules, suffi cient budget, milestone reports, prototyping, documentation, educa- tion, training, and software testing.
2.5.4 Evaluate System and Project Feasibility
At this point the developers seek to confi rm that the system and its project are feasible. Feasibility studies are conducted to
evaluate technical feasibility (Does the required technology exist? Does the fi rm know how to develop in that technology?),
economic feasibility (Can the system and project be justifi ed economically from the additional revenue it will provide?),
operational feasibility (Is the system workable considering the skills and attitudes of the people who must make it work?),
legal and ethical feasibility (Does the system fi t within legal and ethical constraints of the business? Does the system conform to local and international trade agreements?), and
schedule feasibility (Can the system be developed in the allotted time with the proposed resources and budget?).
2.5.5 Conduct Joint Application Design (JAD) Sessions to Confirm Preliminary Findings
Having gathered much information to guide the remainder of the project, the developers must share their fi ndings with the users before proceeding. This sharing
•
•
•
•
•
can be accomplished by means of a JAD session. A JAD session is a joint meeting of developers and users, directed by a trained facilitator, where project-related fi nd- ings and questions are openly discussed, making liberal use of visual aids. [14] JAD sessions are a good risk mitigation process.
The purpose of this particular JAD session is to get the information from the preliminary investigation out on the table so that developers and users agree on what the system will do (requirements) and how it will be developed (specifications).
2.5.6 Receive Approval to Proceed
The fi rm’s top-level managers and those managers who have been directly involved with the project determine whether to proceed. Three choices are available:
proceed to the analysis stage;
repeat some of the preliminary investigation steps to provide better informa- tion for the decision; or
scrap the project.
When the approval to proceed is received, the next stage is analysis.