Information Technology Reference
In-Depth Information
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
Search WWH ::
Custom Search