CABRERA, ROMELYN R.

DESIGN PHASE The information gathered in the preceding phases allows the analyst to put down on paper the elements of a new or improved system. In the design phase, the analyst identifies and considers alternatives. At some point, he or she will select an alternative and conceive a design. During the design phase, input and output records are prepared, forms laid out, and the file specifications written. A major aspect of system design is the structure, organization, and format of the information that will be contained in its database. Time and effort are spent in designing the database, specifying the content of records and files that will be included in it, and describing procedures for entering data and searching, updating, or querying the files. The primary objective of the design phase is to create a design that satisfies the agreed application requirements. In the design phase the SDLC process continues to move from the "what" questions of the analysis phase to the "how" questions. The requirements prototype that was developed earlier during the analysis phase is gradually improved and extended to include all the specified functions of the application. Also, the planning of the system documentation process should be started.

Figure 3.9 Input Screen Design

DEVELOPMENT PHASE In the development phase, the new system is actually built. The analyst concentrates on identifying vendors and suppliers who will be able to provide the necessary equipment or facilities at a reasonable price. Equipment and machines are ordered and set up, computer programs written or purchased, and communication lines leased and installed.

IMPLEMENTATION PHASE

The last step of the cycle, the implementation phase, deals with the changeover to a new or improved system. After the facilities have been installed, programs, software, and hardware must be tested to ensure that they meet design specifications. Final changes and modifications are incorporated in the new system at this stage. The objective is to optimize and fine-tune the system. During this final step, systems documentation, which was begun early on, is completed and reports, paperwork and diagrams are prepared describing the system now in place. In practice, the analyst may repeat one or more of the previous steps. Through a repeated series of problem-solving efforts, he or she will reach the goal of designing and engineering a better system.

WATERFALL MODEL The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington pointing out that the process was not in fact performed in strict top-down, but depended on a prototype.

STRENGTHS AND WEAKNESSES

Few people in the modern computing world would use a strict waterfall model for their systems development life cycle (SDLC) as many modern methodologies have superseded this thinking. Some will argue that the SDLC no longer applies to models like Agile computing, but it is still a term widely in use in technology circles. The SDLC practice has advantages in traditional models of software development that lends itself more to a structured environment. The disadvantages to using the SDLC methodology is when there is need for iterative development or (i.e. web development or e-commerce) where stakeholders need to review on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed. A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC Strengths Control. Monitor large projects. Detailed steps. Documentation. Well defined user input. Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing. Weaknesses Increased development time. Increased development cost. Systems must be defined up front. Hard to estimate costs, project overruns. User input is sometimes limited.

Evaluate costs and completion targets. Rigidity.