Requirements engineering is difficult. It’s not
just a simple matter of writing down what the customer says he wants. A
fundamental problem in business is that requirements are inherently dynamic;
they will change over time as our understanding
of the problem we are trying to solve changes. The importance of good
requirements and the underlying dynamic nature of the process mean that we must
be as accurate as possible, and yet be flexible. Flexible does not mean “weak,”
but rather than we have a process
for developing requirements and
accommodating changed requirements as we clarify the real requirements of
customers. Ineffective requirements practices are an industry wide problem.
This is an area in which you can have a major positive impact. A more
disciplined approach to requirements development and management is needed in
order to improve project success rates. An alarming 53% of industry’s
investment in technical development projects is a casualty of cost overruns and
failed projects.
Sunday 22 July 2012
Sunday 8 July 2012
Implementation(SDLC)
Implementation
The final phase in
the SDLC is the implementation phase, during which the system is
actually built (or purchased, in the case of a packaged software design). This
is the phase that usually gets the most attention, because for most systems it
is the longest and most expensive single part of the development process. This
phase has three steps:
1. System construction
is the first step. The system is built and tested to ensure it performs as
designed. Because the cost of bugs can be immense, testing is one of the most
critical steps in mplementation.Most organizations give more time and attention
to testing than to writing the programs in the first place.
2. The system is
installed. Installation is the process by which the old system is turned
off and the new one is turned on. It may include a direct cutover approach (in which
the new system immediately replaces the old system), a parallel conversion approach
(in which both the old and new systems are operated for a month or two until it
is clear that there are no bugs in the new system), or a phased conversion strategy
(in which the new system is installed in one part of the organization as an initial
trial and then gradually installed in others). One of the most important aspects
of conversion is the development of a training plan to teach users how
to use the new system and help manage the changes caused by the new system.
3. The analyst team
establishes a support plan for the system. This plan usually includes a
formal or informal post-implementation review as well as a systematic way for
identifying major and minor changes needed for the system.
Ref:
System Analysis and Design
Saturday 7 July 2012
SDLC(Design)
Design
The
design phase decides how
the system will operate, in terms of the hardware, software,
and network infrastructure; the user interface, forms and reports; and the
specific programs, databases, and files that will be needed. Although most of
the strategic decisions about the system were made in the development of the
system concept during the analysis phase, the steps in the design phase
determine exactly how the system will operate. The design phase has four steps:
1.
The design strategy is
first developed. It clarifies whether the system will be developed by the
company’s own programmers, whether the system will be outsourced to another
firm (usually a consulting firm), or whether the company will buy an existing
software package.
2.
This leads to the development of the basic architecture
design for the system, which describes the
hardware, software, and network infrastructure to be used. In most cases, the
system will add or change the infrastructure that already exists in the
organization. The interface design specifies
how the users will move through the system (e.g., navigation methods such as
menus and on-screen buttons) and the forms and reports that the system will
use.
3.
The database and file specifications are
developed. These define exactly what data will be stored and where they will be
stored.
4.
The analyst team develops the program
design, which defines the programs that need to be
written and exactly what each program will do.
This
collection of deliverable s (architecture design, interface design, database and
file specifications, and program design) is the system
specification that is handed to the programming team for
implementation. At the end of the design phase, the feasibility analysis and
project plan are reexamined and revised, and another decision is made by the
project sponsor and approval committee about whether to terminate the project
or continue.
Ref: System Analysis and Design
Sunday 1 July 2012
(SDLC) Analysis
The analysis
phase answers the questions of who
will use the system, what the
system will do, and where and when
it will be used. During this phase, the project team
investigates any current system(s), identifies improvement opportunities, and
develops a concept for the new system.
This
phase has three steps:
1.
An analysis strategy is
developed to guide the project team’s efforts. Such a strategy usually includes
an analysis of the current system (called the as-is
system) and its problems, and then ways to
design a new system (called the to-be system).
2.
The next step is requirements
gathering (e.g., through interviews or
questionnaires). The analysis of this information—in conjunction with input
from project sponsor and many other people—leads to the development of a
concept for a new system. The system concept is then used as a basis to develop
a set of business analysis models, which
describe how the business will operate if the new system is developed. The set
of models typically includes models that represent the data and processes
necessary to support the underlying business process.
3.
The analyses, system concept, and models are combined into a
document called the system proposal, which
is presented to the project sponsor and other key decision makers (e.g.,
members of the approval committee) who decide whether the project should
continue to move forward.
The
system proposal is the initial deliverable that describes what business
requirements the new system should meet. Because it is really the first step in
the design of the new system, some experts argue that it is inappropriate to
use the term analysis as the name for this phase; some argue a better name
would be analysis and initial design. Most organizations continue use to the
name analysis for this
phase, however, so we use it in this book as well. Just keep in mind that the
deliverable from the analysis phase is both an analysis and a high-level
initial design for the new system.
Ref : System Analysis and Design
Subscribe to:
Posts (Atom)