Information Technology Reference
In-Depth Information
• Question eliciting: Possible speculation on what kind of information structure is
needed for team-solutions; to those problems based on design in conjunction
with a model-based object-oriented software engineering methodology.
• Question eliciting's other aspects: What observations and comments do you
have about the project that were either concerning or perceived as positive.
Think about your expectations at the beginning of the project and how they
improved/evolved.
• Open-ended catch-all question: In addition to the above questions, please feel
free to discuss any other issues and proposed solutions that you feel are relevant.
It is difficult to anticipate all information needs and plan everything in advance.
Issues resulting from a combination of seemingly isolated facts from different
areas of the project are difficult to anticipate since no participants have a global
view of all the facts and workings. Consequently, a project should be prepared to
deal with unexpected situations, often under pressure. We call the communication
resulting from such crises unplanned communication events.
11.3.2 Release Management
New versions of a system may be created to fix reported faults or as part of the
development process. In general, creating a new system version involves creating
new source code and building the system. Creating a release, however, is more
complex and expensive. As well as creating new source code and building a
system, data and configuration files may have to be prepared and new documen-
tation written. The release must be packaged and distributed to customers (Som-
merville
1996
).
Over the lifetime of a system, changes are likely to be proposed on a fairly regular
basis. Corrective changes are intended to fix faults. Perfective changes are intended
to implement new requirements or to improve system maintainability. Adaptive
changes are intended to change the system to make it operate in a new environment.
The Configuration manager must decide how often the components affected by these
changes should be rebuilt into a new version or release of the system.
Sometimes, this decision is forced on management by faults that have been dis-
covered by customers. If these problems cause data corruption or system crashes, the
customers must be provided with a fix promptly. Sometimes, these faults are repaired
by object-code patching. Object-code patching involves modifying the object code
of the current version. The faulty code is replaced by an unconditional branch to the
corrected code which then branches back to the end of the code being replaced.
However, this is an error-prone approach to problem repair. A better approach
is to create a new system version (or interim release) which incorporates repairs to
the critical faults. This interim release may be distributed without new docu-
mentation as there is no new functionality to be described.
