The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement them. Being a systems analyst is one of the most interesting, exciting, and challenging jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifically, they work with a team of systems analysts, programmers, and others on a common mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a significant business impact, knowing that they contributed unique skills to make that happen. However, the primary objective of a systems analyst is not to create a wonderful system; instead, it is to create value for the organization, which for most companies means increasing profits (government agencies and not-for-profit organizations measure value differently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fit with an organization’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so it can earn greater profits or serve its constituents more effectively. What Does a Systems Analyst Do? A systems analyst is a valued member of the IT department team who helps plan, develop, and maintain information systems. Analystsmust be excellent communicators with strong analytical and critical thinking skills. Because systems analysts transform business requirements into IT projects, they must be business-savvy as well as technically competent, and be equally comfortable with managers and programmers, who sometimes have different points of view, as Dilbert fans already know. Most companies assign .systems analysts to the IT department, but analysts also can report to a specific user area such as marketing, sales, or accounting. As a member of a functional team,an analyst is berter able to understand the needs of that group and how IT supports the department's mission. Smaller companies often use consultants to perform systems analysis work on an as-needed basis. On any given day, an analyst might be asked to document business processes, test hardware and software packages, design input screens, train users, and plan e-commerce Web sites. A systems analyst also manages IT projects, including tasks, resources, schedules, and costs. To keep managers and users informed, the analyst conducts meetings, delivers presentations, and writes memos,reports, and documentation. Systems Analyst Skills Systems Analyst Specialization As organizations and technology have become more complex, most large organizations now build project teams that incorporate several analysts with different, but complementary, areas of specialization.Here we presents a common list of project roles and specializations and briefly describe these specialties and how they contribute to the project. The systems analyst focuses on the IS issues surrounding the system. This person develops ideas and suggestions for ways that IT can improve business processes, helps design new business processes, designs the new information system, and ensures that all IS standards are maintained. The systems analyst will have significant training and experience in analysis and design and in programming. The business analyst focuses on the business issues surrounding the system. This person helps to identify the business value that the system will create, develops ideas for improving the business processes, and helps design new business processes and policies. The business analyst will have business training and experience, plus knowledge of analysis and design.
The project manager is often a highly experienced systems analyst. This individual ensures that the project is completed on time and within budget and that the system delivers the expected value to the organization. Skills Needed by the Systems Analyst other skills,knowledge, and traits to complete the job.These include: computer programming Experience and Expertise General knowledge of business processes and terminologyGeneral problem.solving SkillsGood Interpersonal communication skills Good Interpersonal relation skills Flexibility and AdaptabilityCharacter and ethics CONCEPTS A real-estate group in the federal government cosponsored a data warehouse with the IT department. In the formal proposal written by IT, costs were estimated at $800,000, the project duration was estimated to be eight months, and the responsibility for funding was defined as the business unit’s. The IT department proceeded with the project before it even knew if the project had been accepted.
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) The SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Different projects may emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. Each phase is itself composed of a series of steps, which rely upon techniques that produce deliverables (specific documents and files that provide understanding about the project). All system development projects follow essentially the same fundamental process called the system development life cycle (SDLC). The SDLC starts with a planning phase in which the project team identifies the business value of the system, conducts a feasibility analysis, and plans the project. The second phase is the analysis phase, in which the team develops an analysis strategy, gathers information, and builds a set of analysis models. In the next phase, the design phase, the team develops the design strategy, the physical design, architecture design, interface design, database and file specifications, and program design. In the final phase, implementation, the Phase 1: Systems Planning and Selection . Requests to deal with problems in current procedures . The desire to perform additional tasks . The realization that information technology could be used to capitalize on an existing opportunity
Phase 2: Systems Analysis Phase 3: Systems Design The third phase of the SDLC is called systems design. During systems design, analysts convert the description of the recommended alternative solution into logical and then physical system specifications. You must design all aspects of the system from input and output screens to reports, databases, and computer processes. Logical design is not tied to any specific hardware and systems software platform. Theoretically, the system you design could be implemented on any hardware and systems software. Logical design concentrates on the business aspects of the system; that is, how the system will impact the functional units within the organization. Figure 1-11 shows both the logical design for a product and its physical design, side by side, for comparison. You can see from the comparison that many specific decisions had to be made to move from the logical model to the physical product. The situation is similar in information systems design. In physical design, you turn the logical design into physical, or technical, specifications. For example, you must convert diagrams that map the origin, flow, and processing of data in a system into a structured systems design that can then be broken down into smaller and smaller units for conversion to instructions written in a programming language. You design the various parts of the system to perform the physical operations necessary to facilitate data capture, processing, and information output. During physical design, the analyst team decides which programming languages the computer instructions will be written in, which database systems and file structures will be used for the data, and which hardware platform, operating system, and network environment the system will run under. These decisions finalize the hardware and software plans initiated at the end of the analysis phase. Now you can acquire any new technology not already present in the organization. The final product of the design phase is the physical system specifications, presented in a form, such as a diagram or written report, ready to be turned over to programmers and other system builders for construction. Phase 4: Systems Implementation and Operation
The second part of the fourth phase of the SDLC is operation. While a system is operating in an organization, users sometimes find problems with how it works and often think of improvements. During operation, programmers make the changes that users ask for and modify the system to reflect changing business conditions. These changes are necessary to keep the system running and useful. The amount of time and effort devoted to system enhancements during operation depends a great deal on the performance of the previous phases of the life cycle. Inevitably, the time comes when an information system is no longer performing as desired, when the costs of keeping a system running become prohibitive, or when an organization’s needs have changed substantially. Such problems indicate that it is time to begin designing the system’s replacement, thereby completing the loop and starting the life cycle over again. Alternative Approaches to DevelopmentPrototyping, computer-aided software engineering (CASE) tools, joint application design (JAD), rapid application development (RAD), participatory design (PD), and the use of Agile Methodologies represent different approaches that streamline and improve the systems analysis and design process from different perspectives. Prototyping Designing and building a scaled-down but working version of a desired system is known as prototyping. A prototype can be developed with a CASE tool, a software product that automates steps in the systems development life cycle.CASE tools make prototyping easier and more creative by supporting the design of screens and reports and other parts of a system interface. CASE tools also support many of the diagramming techniques you will learn, such as data-flow diagrams and entity-relationship diagrams. Figure below illustrates prototyping. The analyst works with users to determine the initial or basic requirements for the system. The analyst then quickly builds a prototype. When the prototype is completed, the users work with it and tell theanalyst what they like and do not like about it. The analyst uses this feedback to improve the prototype and takes the new version back to the users. This iterative process continues until the users are relatively satisfied with what they have seen. The key advantages of the prototyping technique are: (1) it involves the user in analysis and design, and (2) it captures requirements in concrete, rather than verbal or abstract, form. In addition to being used as a stand-alone, prototyping may also be used to augment the SDLC. For example, a prototype of the final system may be developed early in analysis to help the analysts identify what users want. Then the final system is developed based on the specifications of the prototype. Computer-Aided Software Engineering (CASE) Tools . Diagramming tools that enable system process, data, and control structures to be represented graphically. . Computer display and report generators that help prototype how systems “look and feel” to users. Display (or form) and report generators also make it easier for the systems analyst to identify data requirements and relationships. . Analysis tools that automatically check for incomplete, inconsistent, or incorrect specifications in diagrams, forms, and reports. . A central repository that enables the integrated storage of specifications, diagrams, reports, and project management information. . Documentation generators that help produce both technical and user documentation in standard formats. . Code generators that enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms, and reports. Joint Application Design In the late 1970s, systems development personnel at IBM developed a newprocess for collecting information system requirements and reviewing system designs. The process is called joint application design (JAD). The idea Prototyping, CASE, and JAD are key tools that support rapid application development (RAD). The fundamental principle of any RAD methodology isto delay producing detailed system design documents until after user requirements are clear. The prototype serves as the working description of needs. RADinvolves gaining user acceptance of the interface and developing key system capabilities as quickly as possible. RAD is widely used by consulting firms. It isalso used as an in-house methodology by firms such as the Boeing Company. RAD sacrifices computer efficiency for gains in human efficiency in rapidlybuilding and rebuilding working systems. On the other hand, RAD methodologies can overlook important systems development principles, which may result in problems with systems developed this way. RAD grew out of the convergence of two trends: the increased speed and turbulence of doing business in the late 1980s and early 1990s, and the ready availability of high-powered computer-based tools to support systems development and easy maintenance. As the conditions of doing business in a changing, competitive global environment became more turbulent, management in many organizations began to question whether it made sense to wait two to three years to develop systems that would be obsolete upon completion. On the other hand, CASE tools and prototyping software were diffusing throughout organizations, making it relatively easy for end users to see what their systems would look like before they were completed. Why not use these tools to address the problems of developing systems more productively in a rapidly changing business environment? So RAD was born. As Figure below shows, the same phases followed in the traditional SDLC are also followed in RAD, but the phases are combined to produce a more streamlined development technique. Planning and design phases in RAD are shortened by focusing work on system functional and user interface requirements at the expense of detailed business analysis and concern for system performance issues. Also, usually RAD looks at the system being developed in isolation from other systems, thus eliminating the time-consuming activities of coordinating with existing standards and systems during design and development. The emphasis in RAD is generally less on the sequence and structure of processes in the life cycle and more on doing different tasks in parallel with each other and on using prototyping extensively. Notice also, that the iteration in the RAD life cycle is limited to the design and development phases, which is where the bulk of the work in a RAD approach takes place. Although it is possible in RAD to return to planning once design has begun, it is rarely done. Similarly, although it is possible to return to development from the cutover phase (when the system is turned over to the user), RAD is designed to minimize iteration at this point in the life cycle. The high level of user commitment and involvement throughout RAD implies that the system that emerges should be more readily accepted by the user community (and hence more easily implemented during cutover) than would a system developed using traditional techniques. Participatory Design
Adopting an adaptive rather than predictive methodology refers to the observation that engineeringbased methodologies work best when the process and product are predictive. Software tends not to be as predictive as, say, a bridge, especially in today’s turbulent business environment. More adaptive methodologies are needed, then, and the Agile Methodologies are based on the ability to adapt quickly. The focus on people rather than roles is also a criticism of engineering-based techniques, where people became interchangeable. An Agile approach views people as talented individuals, not people filling roles, each of whom has unique talents to bring to a development project. Finally, Agile Methodologies promote a self-adaptive software development process. As the methodologies are applied, they should also be adapted by a particular development team working on a particular project in a particular context. No single monolithic methodology effectively fits all developers on all projects at all times. |