Beruflich Dokumente
Kultur Dokumente
Ans –
A) Change Management
The change management process should come into effects when the
software or associated documentation is put under the control of the
configuration management team. Change management procedures
should be designed to ensure that the costs and benefits of change are
properly analyzed and that changes to a system are made in a controlled
way.
(1) Configuration files defining how the release should be configured for
particular installations.
(2) Data files which are needed for successful system operation.
A) Principles of Testing
· Testing should begin “in the small” and progress toward “in
the large”. The first tests planned and executed generally focus on
individual components. As testing progresses, focus shifts in an attempt
to find errors in integrated clusters of components and ultimately in the
entire system.
A) Unit Testing
B) Top-down Integration
Top-down integration testing is an incremental approach to
construction of program structure. Modules are integrated by moving
downward through the control hiearchy, beginning with the main control
module (main program). Modules subordinate (and ultimately
subordinate) to the main control module are incorporated into the
structure in either a depth-first or breadth-first manner.
It has even been argued that the entire discipline of software engi-
neering emerged as a reaction against this assumption and represented
an attempt to view software development from a broader perspective.
Examples range from the emergence of requirements engineering to the
spiral model to human–computer interaction (HCI). Nonetheless, these
developments still viewed non-software-focused factors such as ancillary
or external drivers and failed to place software development in a com-
prehensive, interdisciplinary context. Because software development
problems are highly interdisciplinary in nature, they can only be
understood using interdisciplinary analysis and capabilities. In fact, no
purely technical software problems or products exist because every
software product is a result of multiple factors related to people, money,
knowledge, etc., rather than only to technology.
Consequently, the software process has two related roles. The first
role is internal: to assure software project payoff with better return on
the information system investment, as discussed earlier. The second is
external: the software process should make an actual difference in
business performance. The first role has been addressed extensively in
the software development and project management literature. However,
few research efforts have been dedicated to the study of the external
impact of the software process on business performance. In fact, these
roles should always be combined because external impacts cannot be
studied without considering internal impacts. Figure 6.2 depicts this dual
approach.
· Software applications that do not create value will not survive in the
marketplace.
A) Investing in Diversification
Partial Knowledge
This refers to aspects of an issue that have not been revealed (so-
called in-breadth ignorance) or information about a specific aspect of an
issue that is left incomplete (so-called in-depth ignorance). This type of
ignorance may even derive from a complacent or self-satisfied attitude
—“ what we do not know does not exist.”
Lack of Communication
Interorganizational Ignorance
· Technically based ignorance. This refers to the lack of reliable tools that
enable us to see, understand, and interpret phenomena correctly.
Ignorance is strongly tied to such lack of tool support. One cannot be
expected to make sense of data without reliable tools. When tools are
unavailable, one should anticipate that the data may not be processed at
all; may not be processed on time; may not be processed accurately;
may be lost or destroyed due to lack of storage tools; may be used only
at lower levels of management; or may not be recognized as enabling
decision-making processes.