what is system development life cycle
As in any other engineering field, the software engineer must develop
skills that allow him or her to build a variety of models and to reason about
those models in order to guide choices of the many trade-offs faced in the
software development process. Different models are used in the requirements
phase, in the design of the software architecture, and in the implementation
phase. At some stage, the model might be used to answer questions about both
the behavior of the system and its performance.
The software engineer is a member of a team and therefore needs communication skills and interpersonal skills. The software engineer also needs the ability to schedule work, both his or her own and that of others.
As already mentioned, a software engineer is responsible for many things. Often, many organizations divide the responsibilities among several specialists with different titles.
For example, an analyst is responsible for deriving the requirements and for interacting with the customer and understanding the application area, while a performance analyst is responsible for analyzing the performance of the system. Sometimes the same engineer plays different roles in different phases of the
projector in different projects.
THE SOFTWARE LIFE CYCLE:
From the inception of an idea for a software system, until it is
implemented and delivered to a customer, and even after that, the system
undergoes gradual development and evolution. The software is said to have a
life cycle composed of several phases. Each phase results in the development of
either a part of the system or something associated with the system, such as a
test plan or a user manual. In the traditional life cycle model, called the
"waterfall model," each phase has well-defined starting and ending
points, with clearly identifiable deliverables to the next phase. In practice,
however, things are rarely so simple. A sample waterfall life cycle model comprises the following phases:
• Requirements analysis and specification. Requirements analysis is usually
the
first phase of a large-scale software development project. It is undertaken after a feasibility study has been performed to define the precise costs and benefits of a software system. The purpose of this phase is to identify and document the exact requirements for the system. Such a study may be performed by the customer, the developer, a marketing organization, or any combination of the three. In cases where the requirements are not clear (e.g., for a system that has never been
done before), much interaction must take place between the user and the developer. The requirements at this stage should be in end-user terms but often are not. Various software engineering methodologies advocate that this phase must also produce user manuals and even plans for the system test that will be performed eventually before the system is delivered.
System design and specification:
Once the requirements for a system have been documented, software
engineers design a software system to meet them. This phase is sometimes split
into two subphases: architectural or high-level design and detailed design.
Architectural design entails defining the overall organization of the system in
terms of high-level components and interactions
among them. As we move through increasingly detailed design levels,
components are decomposed into lower-level modules with precisely defined
interfaces. All design levels are documented in specification documents that
keep track of design decisions. Separating the requirements analysis phase from
the design phase is an instance of a fundamental "what-how” dichotomy that
we encounter quite often in computer science.
The general principle involves
making a clear distinction between what the problem is and how to solve the
problem. In this case, the requirements phase attempts to specify what the
problem is. That is why we said that the requirements should be stated in terms
of the needs of the end-user. Usually, there are many ways to satisfy the
requirements, sometimes including manual solutions that do not involve the use
of computers at all.
The purpose of the design phase is to specify a particular
software system that will meet the stated requirements. Again, usually, there
are many ways to build a specified system. In the coding phase, which follows
the design phase, a particular system is coded to meet the design
specification. We shall see many other instances of the what-how dichotomy
throughout this book.
Coding and module testing:
In this phase, the engineer produces the actual code that will be
delivered to the customer as the running system. The other phases of the life
cycle may also develop code, such as that for prototypes, tests, and test
drivers, but these are for use by the developers. Note that individual modules
developed in the coding phase are tested before being delivered to the next
phase. Integration and system testing.
All the modules that have been developed
before and tested individually are put together-integrated in this phase and are tested as a whole system.
• Delivery and maintenance. Once the system passes all the tests, it is
delivered
to the customer and enters the maintenance phase. Any modifications made to the system after the initial delivery are usually attributed to this phase. gives a graphical view of the software development life cycle and provides a visual explanation of the term “waterfall." Each phase yields results that "flow" into the next, and the process ideally proceeds in an orderly and linear fashion.
As presented here, the phases give a partial, simplified view of the conventional waterfall software life cycle. The process may be decomposed into a different set of phases, with different names, different purposes, and different granularity.
Entirely different life cycle schemes may even be proposed, not based on a strictly phased waterfall development. For example, it is clear that if any tests uncover defects in the system, we have to go back at least to the coding phase and perhaps to the design phase to correct some mistakes.
In general, any phase may uncover problems in previous phases, and when it does, that will necessitate going back to the previous phases and redoing some earlier work. For example, if the system design phase uncovers inconsistencies or ambiguities in the system requirements, the requirements analysis phase must be revisited
to determine what requirements were really intended.
Another implication in the preceding presentation is that it assumes that a phase is completed before the next one begins. In practice, it is often expedient to start.
No comments:
Post a Comment