11-04-2013, 04:30 PM
Traditional System
Traditional System.doc (Size: 126.5 KB / Downloads: 20)
INTRODUCTION
System development methodologies are the process of altering or creating systems which people use to develop systems. It envisage the framework used for controlling and planning an information system.The logical process used to develop a system based on information includes - training, requirements and validation and ownership.
Traditional SDLC/Waterfall model, illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. It does not define the process to go back to the previous phase to handle changes in requirement. It is the earliest approach that was used for software development.
Phases
1. Conception: Triggers when a problem is perceived. This phase involves identifying goals to be achieved after the problem is solved, estimating benefits in the new system over the current system, and identifying other areas that are affected by the solution. This phase also involves and developing the business case for the project. A business case provides the information that a manger needs to decide whether to support a proposed project, before resources are committed to its development.
2. Initiation: Involves a macro level study of the customer requirements. This phase also involves defining alternative solutions to the customer requirements and cost-benefit justification of these alternatives.
3. Analysis: Involves carrying out detailed study of the customer requirements and arriving at the exact requirements of the proposed system. The phase involves freezing the requirements before the design phase begins.
4. Design: Involves translating the identified requirements into a logical structure, called design that can be implemented in a programming logic.
5. Construction: Involves integrating and testing all the modules developed in the previous phase as a complete system.
CRITISISM
• Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases.
• Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it.
• Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases.
• Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client.
• It is difficult to estimate time and cost for each phase of the development process.
• The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.