More than ever, business success depends on information technology.

IT is drivin g a new economy, where advances in hardware, software, and connectivity are prov iding enormous benefits to businesses and individuals around the world. As IBM stated in its 2007 annual report, The basic computing model has changed. T he PC model of the 1980s has receded in importance to clients, and has been repl aced by a new paradigm, based on openness, networks, powerful new technology and the integration of digital intelligence into the fabric of work and life. Although economic trends affect IT spending levels, most businesses give IT budg ets a relatively high priority, in good times or bad. The reason is simple durin g periods of growth, companies cannot afford to lag behind the IT curve. Convers ely, when the economy slows down, firms often use IT to reduce operating costs a nd improve efficiency. Systems analysis and design is a step-by-step process for developing high-qualit y information systems. An information system combines information technology, pe ople, and data to support business requirements. For example, information system s handle daily business transactions, improve company productivity, and help man agers make sound decisions. The IT department team includes systems analysts who plan, develop, and maintain information systems. Systems analysts must know how to use a variety of techniques, such as modeling, prototyping, and computer-aided systems engineering tools to plan, design, and implement information systems. Systems analysts work with these tools in a team environment, where input from users, managers, and IT staff contributes to the s ystem design. Modeling produces a graphical representation of a concept or process that system s developers can analyze, test, and modify. A systems analyst can describe and s implify an information system by using a set of business, data, object, network, and process models. A business model, or requirements model, describes the information that a system must provide. A data model describes data structures and design. An object mode l describes objects, which combine data and processes. A network model describes the design and protocols of telecommunications links. A process model describes the logic that programmers use to write code modules. Although the models might appear to overlap, they actually work together to describe the same environmen t from different points of view. Prototyping tests system concepts and provides an opportunity to examine input, output, and user interfaces before final decisions are made. A prototype is an e arly working version of an information system. Just as an aircraft manufacturer tests a new design in a wind tunnel, systems analysts construct and study inform ation system prototypes. A prototype can serve as an initial model that is used as a benchmark to evaluate the finished system, or the prototype itself can deve lop into the final version of the system. Either way, prototyping speeds up the development process significantly. A possible disadvantage of prototyping is that important decisions might be made too early, before business or IT issues are understood thoroughly. A prototype based on careful fact-finding and modeling techniques, however, can be an extrem ely valuable tool. Computer-aided systems engineering (CASE), also called computer-aided software e ngineering, is a technique that uses powerful software, called CASE tools, to he lp systems analysts develop and maintain information systems. CASE tools provide an overall framework for systems development and support a wide variety of desi gn methodologies, including structured analysis and object-oriented analysis.

Because CASE tools make it easier to build an information system, they boost IT productivity and improve the quality of the finished product. After developing a model, many CASE tools can generate program code, which speeds the implementati on process. The benefits of using CASE are numerous. With CASE tools, tasks are much faster to complete and alter; development information is centralized; and information i s illustrated through diagrams, which typically are easier to understand. Potent ially, CASE can reduce maintenance costs, improve software quality, and enforce discipline; and some project teams even use CASE to assess the magnitude of chan ges to the project. AN OVERVIEW OF SYSTEMS DEVELOPMENT METHODS Many options exist for developing information systems, but the most popular alte rnatives are structured analysis, which is a traditional method that still is wi dely used, object-oriented analysis (O-O), which is a more recent approach that many analysts prefer, and agile methods, also called adaptive methods, which inc lude the latest trends in software development. 1. Structured Analysis Represents the system in term of data and the processes that act upon that data. System development is organized into phases, with deliverables and milestones t o measure progress. The SDLC waterfall model typically consists of five phases. Iteration is possible among the phases. Structured analysis uses a set of process models to describe a system graphicall y. Structured analysis also addresses data organization and structure, relationa l database design, and user interface issues. Process modeling identifies the da ta flowing into a process, the business rules that transform the data, and the r esulting output data flow. Modeling tools for structured analysis are the data flow diagrams (DFDs) and pro cess descriptions. Pros: Traditional method, which has been very popular over time. Relies heavily on wri tten documentation. Frequent phase iteration can provide flexibility comparable with other methods.Well-suited to project management tools and techniques. Cons: Changes can be costly, especially in later phases. Requirements are defined earl y, and can change during development. Users might not be able to describe their needs until they can see examples of features and functions. Structured analysis is a traditional systems development technique that is timetested and easy to understand. Structured analysis uses a series of phases, call ed the systems development life cycle (SDLC), to plan, analyze, design, implemen t, and support an information system. Although structured analysis evolved many years ago, it remains a popular systems development method. Structured analysis is based on an overall plan, similar to a blueprint for constructing a building, so it is called a predictive approach. Waterfall Development ( Traditional Waterfall SDLC ) One phase begins when another completes, with little backtracking and looping.

With waterfall development, analysts and users proceed sequentially from one pha se to the next. The key deliverables for each phase are typically voluminous (of ten, hundreds of pages) and are presented to the approval committee and project sponsor for approval as the project moves from phase to phase. Once the work pro duced in one phase is approved, the phase ends and the next phase begins. As the project progresses from phase to phase, it moves forward in the same manner as a waterfall. While it is possible to go backward through the phases (e.g., from design back to analysis), it is quite difficult. (Imagine yourself as a salmon t rying to swim upstream in a waterfall). Waterfall development methodologies have the advantages of identifying requireme nts long before programming begins and limiting changes to the requirements as t he project proceeds. The key disadvantages are that the design must be completely specified before pr ogramming begins, a long time elapses between the completion of the system propo sal in the analysis phase and the delivery of system, and testing is treated almost as an afterthought in the implementation phase. In addition, the deliverables are often a poor communication mechanism, so impor tant requirements may be overlooked in the volumes of documentation. If the proj ect team misses an important requirement, expensive post-implementation programm ing may be needed. Users may forget the original purpose of the system, since so much time has elapsed between the original idea and actual implementation. Also , in today s dynamic business environment, a system that met the existing environm ental conditions during the analysis phase may need considerable rework to match the environment when it is implemented. This rework requires going back to the initial phase and making needed changes through each of the subsequent phases in turn. There are two important variants of waterfall development. The parallel developm ent and the V-model. Parallel development methodologies evolved to address the lengthy time frame of waterfall development. Instead of doing the design and implementation in sequenc e, a general design for the whole system is performed. Then the project is divid ed into a series of subprojects that can be designed and implemented in parallel . Once all subprojects are complete, there is a final integration of the separat e pieces, and the system is delivered. Parallel development reduces the time required to deliver a system, so changes i n the business environment are less likely to produce the need for rework. The a pproach still suffers from problems caused by voluminous deliverables. It also a dds a new problem: If the subprojects are not completely independent, design dec isions in one subproject may affect another, and at the project end, integrating the subprojects may be quite challenging. The V-modelis another variation of waterfall development that pays more explicit attention to testing. The development process proceeds down the left-hand slope of the V, defining requirements and designing system components. At the base of the V, the code is written. On the upward-sloping right side of the model, test ing of components, integration testing, and, finally, acceptance testing are per formed. A key concept of this model is that as requirements are specified and co mponents designed, testing for those elements is also defined. In this manner, e ach level of testing is clearly linked to a part of the analysis or design phase , helping to ensure high quality and relevant testing. The V-model is simple and straightforward and improves the overall quality of sy stems through its emphasis on early development of test plans. It still suffers from the rigidity of the waterfall development process, however, and is not alwa

ys appropriate for the dynamic nature of the business environment. 2. Object-oriented analysis Views the system in terms of objects that combine data and processes. An object is a member of a class, which is a collection of similar objects. Objects posses s characteristics called properties, which the object inherits from its class or possesses on its own.The objects represent actual people, things, transactions, and events. Compared to structured analysis, O-O phases tend to be more interac tive. Can use the waterfall model or the model that stresses greater iteration. Modeling Tools: Various object-oriented diagrams depict system actors, methods, and messages. Pros: Integrates easily with object-oriented programming languages. Code is modular an d reusable, which can reduce cost and development time. Easy to maintain and exp and as new objects can be cloned using inherited properties. Cons: Somewhat newer method might be less familiar to development team members. Intera ction of objects and classes can be complex in larger systems. 3. Agile / Adaptive Method Stresses intense team-based effort. Breaks development process down into cycles, or iterations that add functionality. Each iteration is designed, built, and te sted in an ongoing process. Attempts to reduce major risks by incremental steps in short time intervals. Agile methods typically use a spiral model, which repr esents a series of iterations, or revisions, based on user feedback. Modeling Tools: Uses tools that facilitate team communication, such as collaborative software, i nteractive presentations, traditional whiteboards and face-to-face contact. Pros: Very flexible and efficient in dealing with change. Stresses team interaction an d reflects a set of community-based values. Frequent deliverables constantly val idate the project and reduce risk. Cons: Team members need a high level of technical and communications skills. Lack of s tructure and documentation can introduce risk factors. Overall project might be subject to scope change as user requirements change. Extreme Programming (XP)is another adaptive process that focuses on forceful int eraction between developers and users to define and achieve project goals. XP, l ike agile methods generally, stresses certain key values, such as communication, simplicity, feedback, courage, and respect among team members. When properly im plemented, its proponents believe that Extreme Programming can speed up developm ent, reduce costs, and improve software quality. Time will tell whether this inn ovative approach will be widely accepted. Although agile methods are becoming popular, analysts should recognize that thes e approaches have advantages and disadvantages. By their nature, agile methods c an allow developers to be much more flexible and responsive, but can be riskier than more traditional methods. For example, without a detailed set of system req uirements, certain features requested by some users might not be consistent with the company s larger game plan. Other potential disadvantages of agile methods can include weak documentation, b

lurred lines of accountability, and too little emphasis on the larger business p icture. Also, unless properly implemented, a long series of iterations might act ually add to project cost and development time. The bottom line is that systems analysts should understand the pros and cons of any approach before selecting a development method for a specific project. Other Development Methods joint application development (JAD) and rapid application development (RAD) Both JAD and RAD use teams composed of users, managers, and IT staff. The differ ence is that JAD focuses on team-based fact-finding, which is only one phase of the development process, whereas RAD is more like a compressed version of the en tire process.