CHAPTER 3: SYSTEMS DEVELOPMENT LIFE CYCLE In our life we encounter different problems.

There are problems that are very easy to solve and other problems take a little more time and effort. Businesses have problems too, and they range from simple to complex, from those easily dealt with to those that are insoluble. Analysts and business managers take their time and effort on solving this diversity of problems. In this chapter we will study problem-solving techniques and look at the systematic approaches that analysts use in dealing with problems. The chapter discusses traditional and structured systems analysis techniques and how to apply the scientific method to solving business problems. CUASE AND EFFECT RELATIONSHIP

Cause and effect is the foundation of systems work. If a cause and effect relationship exists, the cause will always generate the effect. This certainty allows scientists, business managers, systems analysts and others to bring order and structure out of chaos. For many years businesses relied upon hunches, guesses, intuition, or tradition to guide them in problem-solving. It was philosopher John Dewey who outlined the steps of a logical approach for developing sound solutions problems. The scientific method is a procedure for solving problems that systematically deals with causes and effects, evaluating the results. It is useful for solving a problem with the least expenditure of time and effort. THE SCIENTIFIC METHOD

The scientific method of problem solving, an important part of the systems analysts repertoire, is used to develop solutions for a wide range of information flow problems. Its major characteristics are: 1. Reproducibility of results. There is a good deal of assurance that procedures, operations, or tests carried out according to the scientific method will produce the same results each time they are performed. 2. Accuracy of results. Conclusions based on the application of factual knowledge, reproducible experiences, and intellectual proficiency rather than on guesswork or chance, are more accurate. 3. Efficient expenditure of time and effort. Since procedures are executed logically, there is more assurance that the activities of the systems analysts will achieve specified goals with the least effort. 4. Plan of action. The scientific method gives the systems analyst a reliable and tangible plan to follow when handling a complicated problem with many diverse factors. It ensures that all relevant procedures, elements, and data are considered and that none is omitted accidentally.

5. Transferability of results. Because results obtained from the scientific method are reproducible, the systems analyst can expect similar results to occur in similar like situations without having to repeat the steps in the process, or to retest data. The following is a list of the key aspects of the scientific method: Precise statement of problem Careful attention to detail Objectivity in making observations Precision in analyzing data and reporting results Use of mathematics and statistical techniques Systematic, logical plan for solving problems Evaluation of results Readjustments of system to bring it more in line with objectives

Recognize the Problem Before we can solve a problem, if there is one, we must identify its causes. In this step, the systems analyst describes and isolates the factors pertinent to a particular problem and tries to determine the causes. The analyst investigates the nature of the problem to decide if it is a unique situation, whether it is indicative of other problems, or whether it masks a deeper problem. The problem cannot be solved if the wrong causes are attacked or the wrong solution is implemented. If the problem is caused by inadequate keyboarding skills, rearranging the office furniture will not increase output. The real elements of the problem must be identified before a solution can be found.

In this case the systems analyst decides that the level of output from the data entry department is below what can reasonably be expected. The problem cannot be solved if the wrong causes are attacked or the wrong solution is implemented. The real elements of the problem must be identified before a solution can be found. Express Problem In Quantitative Terms The next step in the scientific method involves reducing the problem into quantitative terms. It is done by transform observation in numbers so that it could be easy to formulate result in the problem and solution are determined and measured. For example: our variable is the volume of sales however during this past few days it decline through slow moving periods. But the person in-charge of such sale measure it 11,500 pesos a day. There is amount involve so analyst can express it to quantitative terms. Analyze Choices and Select an Alternative In this phase, the systems analyst develops alternative solutions to the problem after studying various methods of improving the situation. In selection a plan of

action, the analyst uses if-then logic if a given solution is implemented then this will happen. If-then Logic

Implement the Solution This phase may involve a considerable expenditure of time and money. Sometimes equipment vendors are called in, employees hired, training courses developed, new forms printed, computers installed, and so on. Patterns of information flow may be changed and new procedures instituted or old ones altered. Evaluate Results and Optimize Probably the most important phase of the scientific method is evaluating the results. In this step, the analyst determines whether the implementation solution actually solved the problem and whether desired goals were reached. Few solutions produce perfect results the first time they are implemented. If the original expectations were not met, the analyst must return to earlier steps in the problem-solving procedure. He or she must repeat the activities of the steps, usually with some modifications, in an attempt to adjust the outcomes. This process of reentering the problem-solving loop at the point indicated by the called optimation.

Systems thinking is the process of understanding how things influence one another within a whole. In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization healthy or unhealthy. Systems Thinking has been defined as an approach to problem solving, by viewing "problems" as parts of an overall system, rather than reacting to specific part, outcomes or events and potentially contributing to further development of unintended consequences. Systems thinking is not one thing but a set of habits or practices within a framework that is based on the belief that the component parts of a system can best be understood in the context of relationships with each other and with other systems, rather than in isolation. Systems thinking focuses on cyclical rather than linear cause and effect. Structured Systems Analysis Methodology For many years system analyst applied the scientific method to problem solving in a traditional way , defining the inputs and the outputs of a system and describing how the information would be processed. This could be a difficult and time-consuming effort because it required spending many hours preparing flowcharts and writing lengthy textual descriptions of the information-handling process. Flowcharts were major tool of the systems analyst for many years. This was unstructured way of describing steps in a solution. Virtually all problems were perceived as being sequential and linear in nature. The traditional systems analysis methodology became inadequate, however, as businesses and organizations overtook solving more complex and interrelated problems. The task of describing all inputs, outputs, processing steps, and contacts with vendors, customers, programmers managers and others, using only flowcharts and textual narratives, was too difficult. The new method for solving system problems and describing their solutions was developed by Larry Constantine, Edward Yourdon , Chris Gane , Trish Sarson and others. This methodology, known as structured systems analysis, replaced lengthy textual descriptions with diagrams that substituted words for figures and flowlines for written narratives. Structured analysis enabled analysis to visualize a system graphically, as an interrelated group of elements, rather than merely as a sequence of steps. Thus it became possible to visualize an overall system and its structure in a clear form. Structured systems analysis has become the preferred method of analyzing and describing systems.

Structured Systems Analysis, This method visualizes the overall system in diagram form. STRUCTURED SYSTEMS ANALYSIS METHODOLOGY For many years systems analysts applied the scientific method to problem solving in a traditional way, defining the outputs of a system and describing how the information would be processed. This could be a difficult and time-consuming effort because it required spending many hours preparing flow charts and writing lengthy textual descriptions of the information-handling process. Flow charts were a major tool of the systems analyst for many years. This was an unstructured way of describing steps in a solution. Virtually all problems were perceived as being sequential and linear in nature. The traditional systems analysis methodology became inadequate, however, as businesses and organizations undertook solving more complex and interrelated problems. The task of describing all inputs, outputs, processing steps and contacts with vendors

, customers, programmers, managers, and others, using only flowcharts and textual narratives was too difficult. Structured systems analysis

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) Systems analysts have refined the scientific method into a logical strategy that can be applied to many kinds of problems. The five phases are somewhat arbitrary and often overlap. Some analysts prefer to view the process as having six or more phases. The Systems development life cycle (SDLC), or Software development process in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process. History The systems life cycle (SLC) is a methodology used to describe the process for building information systems, intended to develop information systems in a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The systems development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the 1960's,to develop large scale

functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines". Several systems development frameworks have been partly based on SDLC, such as the structured systems analysis and design method(SSADM) produced for the UK government Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the traditional life cycle approaches to systems development have been increasingly replaced with alternative approaches and frameworks, which attempted to overcome some of the inherent deficiencies of the traditional SDLC".

PLANNING PHASE In the planning phase, analysts recognize, diagnose, and define the problem. During this phase, they may conduct a study to assess and overall scope of the problem and determine whether more money and time should be expended in solving it. They prepare a plan of attack and select the individuals who will direct a project or serve on a committee. This phase lays the groundwork for further study and the stages that will follow. ANALYSIS PHASE During the analysis phase, the analyst reviews data and information on the inplace-system. He or she takes measurements, conducts audits, gathers information, interviews individuals, samples work, and documents the kinds and types of information to be processed by the system. The objective is to clearly

understand the present system, learn what is needed, and discover the shortcomings or faults that must be corrected or modified. A new method for solving system problems and describing their solutions was developed by Larry Constantine, Edward Yourdon, Chris Gane, Trish Sarson, and others. This methodology, known as structured systems analysis, replaced lengthy textual descriptions with diagrams that substituted words for figures and flowlines for written narratives. Structured analysis enabled analysts to visualize a system graphically, as an interrelated group of elements, rather than merely as a sequence of steps. Thus, it became possible to visualize an overall system and its structure in a clearer form. Structured systems analysis has become the preferred method of analyzing and describing systems. 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 afterthe-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. Evaluate targets. costs and completion Weaknesses Increased development time. Increased development cost. Systems must be defined up front. Rigidity. Hard to estimate costs, project overruns. User input is sometimes limited.

Documentation. Well defined user input. Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing.