Module 4: The systems development process

Transcription

1 Course Schedule Course Modules Review and Practice Exam Preparation Resources Module 4: The systems development process Overview Organizations rely heavily on their information systems. They operate in a changing, highly competitive environment, and their information systems must respond to, or anticipate, those changes. The process of modifying existing systems, or acquiring or developing new ones, is an important aspect of information systems. First, business problems or opportunities must be identified, analyzed, and translated into new business objectives. Information systems are established to support the achievement of business objectives. The problem or opportunity must then be thoroughly understood, and alternative solutions identified and designed. Decisions have to be made on selecting the right system. The system must then be acquired or developed, and finally implemented. After implementation, the system must be maintained and reviewed. These above stages are included as project management phases and are known as the systems development life cycle (SDLC). As accountants, you also know that information system projects may need to be audited. The process of systems development may utilize various techniques and participants other than systems personnel. When implementing a new system, they follow a set of guidelines for the steps that must be performed and the documentation that must be produced. The SDLC methodology used recommends the use of particular investigation, analysis, design, and implementation techniques. This module introduces the SDLC and the first steps in the process, from the initiation of a systems project through the systems investigation and systems analysis phases. Module 5 continues with the design phase, including the selection of the best alternative out of the solutions available. Module 6 completes the SDLC with the implementation, maintenance, and review phases, concluding with the systems audit. At the end of this module, you will learn how to use Microsoft Excel to draw data flow diagrams. Test your knowledge Begin your work on this module with a set of test-your-knowledge questions designed to help you gauge the depth of study required. Topic outline and learning objectives 4.1 Introduction to systems development Identify the key participants in the systems development process and the major reasons for initiating a systems project. (Level 1) 4.2 Information systems planning Define the term "information systems planning" and explain the objectives of systems development. (Level 1) 4.3 Systems development life cycle Describe the major stages, advantages, and disadvantages of the traditional systems development life cycle. (Level 1) 4.4 Alternatives to the traditional SDLC Describe the features, advantages, and disadvantages of alternative approaches to the traditional approach, including prototyping, rapid application development, outsourcing, and end-user systems development life cycles. (Level 1) 4.5 Factors affecting systems development success Identify several factors that influence the success or failure of a systems development project. (Level 1) 4.6 Systems investigation State the purpose of systems investigation, and describe technology, operational,

2 schedule, economic, and legal feasibility assessments. (Level 1) 4.7 Systems analysis Explain the purpose of systems analysis and describe some of the tools and techniques used in this phase of systems development. (Level 1) 4.8 Data flow diagrams Use data flow diagrams for systems analysis and design. (Level 1) 4.9 Using Excel as a data flow diagram drawing tool Use Excel for data flow diagramming. (Level 1) Module summary Print this module

3 Course Schedule Course Modules Review and Practice Exam Preparation Resources Module 4: Test your knowledge 1. What are two data collection techniques used during systems analysis? Solution a. Direct observation, cost/benefit analysis b. Data flow diagrams, questionnaires c. Interviews, hands-on evaluation d. Ends-means analysis, statistical sampling 2. Chapter 12, Review question 12, page 518 Solution 3. What is the purpose of requirements analysis? Solution 4. Chapter 12, Review question 4, page 518 Solution 5. The following is a partial description of a point-of-sale system, which is designed to handle cash or credit card sales after the total purchase has been calculated. If the customer pays cash, the cashier enters the cash amount tendered into the cash register, and the cash register automatically calculates and displays the change required. The cashier then hands the change to the customer. If the customer pays by credit card, the customer's credit card is scanned by the cash register, which initiates a call to the credit card company for credit checking and authorization. If the credit card is accepted, the cashier records the credit authorization number on the credit card slip, and the customer signs the credit card slip. If the credit card is rejected because the customer has over-extended the credit limit, the customer is asked to pay cash. Draw a physical data flow diagram for the preceding description. Solution

4 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.1 Introduction to systems development Learning objective Identify the key participants in the systems development process and the major reasons for initiating a systems project. (Level 1) Required reading LEVEL 1 Chapter 12, pages The opening case in Chapter 12 described Nordmilch's approach to managing the replacement of its existing older systems. Another example is the impact of the year 2000 on software and the rush to develop new systems that could handle Y2K. Y2K had provided an impetus and budget for information systems and had enabled many organizations to develop systems that addressed other problems. In Canada, the federal government (as did all levels of government) not only spent substantial sums on its own systems, but also made grants available to businesses for upgrades of hardware and software. The new systems did more than fix the Y2K bug large organizations embarked on new and ambitious systems projects. Just as every professional must understand the importance of information systems to the organization, it is also important to understand the systems development process. Systems development can make or break a company and/or a career. At some point in your career, you may well be part of, or even be responsible for, a systems development project. Participants in systems development Any systems development project requires a team. Stakeholders are those with a stake in the outcome of the project, and as individuals or as representatives of their organizational unit, they will be materially affected by the results. Users are people who interact with the system on a regular basis. A systems analyst is the coordinator, communicator, and architect who interacts with the various technical and non-technical participants. The business analyst is responsible for providing input and analysis of the existing and proposed systems based on his knowledge of the business and its processes. For small businesses, the development team may consist of the systems analyst and the business owner, although in many cases, the accountant or comptroller will also be a participant. While the text mentions outside participants such as consultants as members of a development team, it neglects to mention auditors. In many organizations, auditors are stakeholders and are participants in some aspect of the development team or a steering committee. The text also fails to mention other interested parties such as employees, shareholders, and members of the public, who may be seriously affected by systems development. For example, a company's customers or its employees may have their data stored on a system; they will be adversely affected if a new system does not provide sufficient data protection. While these individuals are not part of the design team, it is important that their interests be adequately represented in the design process. Projects, particularly large projects, need a project manager responsible for running the project to ensure it achieves its objective(s). Very large projects may also have a project sponsor who is responsible for the overall project and acts as the champion for the project. The project manager should be at an organizational level and from an organizational area appropriate to the nature of the project. For example, the project manager for a project that concerns primarily new technology would be from the IS department, while a project that involves new financial systems would have a project manager from the finance department, and someone in senior

5 management would be the project manager for a project that impacts the entire organization. Sometimes the project manager is an external consultant, and specialists may also be contracted externally. Participants in projects deal with many other people as part of the change process, so it is important that the project manager have good communication skills. Ideally, the project manager should be a Project Management Institute (PMI) certified professional. Initiating systems development One of the main reasons for initiating systems development is to enhance a firm s competitive advantage. Figure 12.2 on page 481 of the textbook presents other major reasons for initiating systems development. Governments may also provide stimulus to develop new or improved systems to meet the needs of that government. (The Sarbanes-Oxley Act is of particular interest to accountants.) In Canada, various levels of government funds encourage organizations to change or update their systems in order to meet standards or policies set by governments. For example, Ontario ministries have provided funds to municipalities for developing systems for waste management, sewer information, geographical information, and intergovernmental systems. Systems development involves change. Sometimes it's up to you, as an individual or group, to initiate change. If you see that there is a need to change but are not in a position to initiate the change, you must present your rationale for the change to an advocate, usually someone in management, to effect the change.

6 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.2 Information systems planning Learning objective Define the term "information systems planning" and explain the objectives of systems development. (Level 1) Required reading LEVEL 1 Chapter 12, pages Some systems development projects arise from changes that are unplanned, such as new legislation. However, an organization's strategic plan should be the basis for all systems development. Information systems planning is the translation of strategic and organizational goals into systems development initiatives. All major initiatives must be prioritized by senior management based on predetermined criteria, including alignment with corporate goals, in addition to the competition for resource dollars from other projects and investment opportunities. A major project that provides a competitive advantage will receive a high priority. This requires thinking competitively, which involves two processes. Creative analysis requires you to look at problems or processes in new and different ways, often looking beyond a process and finding out what is the purpose of that process, to arrive at a new approach. It means determining whether the problem that the process is designed to solve still exists or has changed. Critical analysis requires discarding predetermined notions and examining what is being done and why, and involves the following: Going beyond automating manual systems. Don't just automate what is being done; consider better and more effective ways of doing things. Questioning statements and assumptions. Users may specify systems requirements based on a limited view of a system or process, which may improve that piece of the system but may leave a root problem unresolved or a major opportunity unexplored. Identifying and resolving objectives and orientations that conflict. Two or more organizational units may have objectives that are mutually exclusive (if you achieve one, you can't achieve the other), and these objectives must be identified and resolved in the light of overall organizational objectives. Ideally, the corporate objectives are used to develop a corporate strategic plan from which the information systems strategic plan is derived. The information systems strategic plan is then used to determine which information systems projects should be pursued. In real life, however, systems analysts may sometimes be required to find systems solutions in the absence of a clearly defined information systems strategic plan or corporate strategic plan. Establishing objectives for systems development When setting priorities for systems development, senior management will consider which are mission-critical, that is, key to the organization's operations and success. When setting objectives for a system, critical success factors by which functional areas are measured must be translated into systems objectives and form part of its functional requirements. In addition to these requirements, specific performance objectives and cost objectives must be defined at the outset. These objectives should be stated in measurable terms, that

7 is, they need to be quantified. Performance objectives include such factors as the quality or usefulness of the output, the quality or usefulness of the format of the output, the speed at which output is generated, and the scalability of the system. Cost factors include development costs, costs related to the uniqueness of the application, investments in hardware and other equipment, and ongoing operating costs. The costs of the new system will vary according to the level of performance. In order to set a cost objective for the new system, it is necessary to subtract the costs of the current system at a given level of performance from those of the proposed system at the same level of performance. What is really desired is a more costeffective system one whose performance should be significantly better than the current system and whose cost should be lower than modifying the current system. In some cases, a system is being developed to meet new requirements for which no current system exists (for example, when new requirements are legislated or when the organization undertakes new activities). In these circumstances, there is no choice but to develop a new system; however, it is important to set systems objectives. The actual cost and performance factors when the system is operative will be measured against the objectives in the systems review phase of the systems development life cycle. Systems development and e-commerce Systems development for e-commerce requires additional technology, special skills, and tools. In Modules 8 and 10, you will learn more about the growth of e-commerce and special considerations for Internet use. Trends in systems development and enterprise resource planning The growth in the use of ERP has meant that users look to ERP software for answers to business problems, and ERP drives planners to explore different types of systems. Some clients want to use the ERP vendor as a single source for all software; however, an ERP software vendor may not be able to develop software for all applications. An organization may choose to acquire software from different vendors to obtain the best overall solution, such as buying the customer relationship management (CRM) application from a different vendor due to its better capabilities.

8 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.3 Systems development life cycle Learning objective Describe the major stages, advantages, and disadvantages of the traditional systems development life cycle. (Level 1) Required reading LEVEL 1 Chapter 12, pages Managers use a formal process management technique called systems development life cycle (SDLC) to solve a business problem that requires the development of a new information system. SDLC provides a structured framework to conduct systems analysis, design, implementation, and maintenance. The methods and techniques used to control the systems development life cycle and the implementation of a computerized information system are collectively referred to as a systems development methodology. The primary reason for the traditional SDLC is that it allows for a large degree of management control over the development of the new software system. Organizations use systems development methodologies to impose some form of discipline on the development of information systems. Various systems development methodologies are used by organizations. A typical systems development methodology must include distinct phases for the project, with specific deliverables formalized methods for project review project management software to plan and track the project reports and other deliverables to assess progress data flow diagrams and other tools for analysis and design data dictionaries or repositories for project documentation structured design and programming techniques Traditional SDLC stages There are equally valid ways of organizing the stages of a SDLC other than those used in the text. Here is a commonly accepted version (the equivalent phases used by the text are enclosed in parentheses): 1. preliminary analysis (systems investigation) 2. systems analysis (systems analysis) 3. systems design (systems design) 4. programming and testing (systems implementation software acquisition) 5. acquisition (systems implementation acquisition) 6. installation (systems implementation installation, testing, startup, and acceptance) 7. post-implementation review (systems maintenance and review) 8. maintenance (systems maintenance and review) Note that not all projects require new hardware and software, and in that case, the acquisition stage will not be necessary. The text, however, includes internal software development as part of the software acquisition stage of implementation, whereas most organizations include software development as a separate phase. At the end of each phase, most systems development methodologies require some form of management approval before development can proceed to the next stage. Often, management requires a report. The

9 following are the typical reports required at the end of each stage: preliminary analysis report (preliminary analysis) analysis report (systems analysis) design specifications document or report (systems design) programs and status report (programming and testing) acquisition proposal (acquisition) project completion report (installation) post-implementation review report (post-implementation review) request for maintenance (maintenance) The major strength of the traditional SDLC is its structured approach to the development of information systems. This structured approach is also its major weakness. In the competitive and dynamic business world, the highly structured traditional SDLC is often not sufficiently responsive to the changing business environment in terms of its inflexibility and inability to meet changes in user requirements. However, in the real world, some of the problems and disadvantages are based on earlier environments, where the IS department tended to be isolated and the users were not involved in the development process. This has changed considerably over the years, and IS people have learned that users need to be involved throughout the process. One of the major roles of the lead user or business analyst is to overcome some of the listed disadvantages, not only by representing the end-users and knowing the users' needs, but also by understanding the tools used by the technical people. For example, the business analyst understands DFDs or flow charts and can identify errors or omissions in them. The business analyst and other users are involved throughout the process, so that what the users get is a system as understood not only by the developers but also by the business analyst. However, there is still a certain degree of inflexibility in the traditional SDLC although there is also room for change.

10 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.4 Alternatives to the traditional SDLC Learning objective Describe the features, advantages, and disadvantages of alternative approaches to the traditional approach, including prototyping, rapid application development, outsourcing, and end-user systems development life cycles. (Level 1) Required reading LEVEL 1 Chapter 12, pages Systems development techniques used to address the lack of responsiveness of the traditional SDLC prototyping, rapid applications development (RAD) (includes joint application development), end-user development, and outsourcing (under some circumstances) are amongst the ones available in the industry, and the only techniques addressed in this course. The text implies that these four techniques cannot be combined with SDLC, but this is not the case. Prototyping is often used in the SDLC to expedite design and implementation. Similarly, fourth-generation development techniques using fourth-generation languages (used in RAD) are often incorporated into the SDLC. Prototyping Prototyping is sometimes used as an approach during the analysis phase of the traditional SDLC to speed up development. The key to prototyping is to develop a working model quickly without detailed analysis and design. There are two ways prototyping can be accomplished: 1) by the analyst working in conjunction with users, or 2) by the users directly, and revised and enhanced by analysts. The latter is becoming more popular as more user-friendly software becomes available for prototyping. Sometimes, prototyping results in a simplified working model, which programmers can then implement using more traditional computer languages. This is often the case when prototyping techniques are used in conjunction with the traditional SDLC. This is done either to facilitate long-term maintenance or to improve processing efficiency. (Prototyping languages are designed for ease of prototyping, not efficient processing.) Numerous tools can be used for prototyping in addition to end-user programming languages, including spreadsheet programs such as Microsoft Excel and database languages such as Microsoft Access. Report generators are also often used for prototyping. Even word-processing programs can be used to develop prototypes of reports. Risks of prototyping One major weakness of prototyping is weak internal controls and data integrity safeguards. Examples include input edit procedures, access control to sensitive information, error checking, and back-up and recovery procedures. These controls and safeguards are ignored for a variety of reasons, the most common being that the focus of prototyping is to develop a working system, not security and data integrity. In fact, these issues can get in the way because the prototype may be changing on an hourly basis. Thus one real risk of using prototyping is the lack of appropriate controls and safeguards. The best time to implement these measures is at (or just before) the final step, just before the prototype is declared completed. Example 4.1 highlights some of the risks of prototyping.

11 Example 4.1 Prototyping risks Family Services of Greater Kamloops (FSGK) provides counselling and support to families in distress, particularly to victims of family violence and sexual abuse. FSGK has a team of 15 professional psychologists and counsellors helping a large number of clients. Until now, all counselling information was kept manually in paper files. While paper files are clinically adequate, they are completely unsatisfactory for administrative purposes. Barbara Wallace, the executive director of FSGK, was often unable to answer simple queries from funding agencies and the provincial government. This would be easy to do if computer records were kept. As it is, the data required to answer a simple question such as how many family violence cases in the past year also involved substance abuse can take hours to assemble manually. In two months' time, Barbara will be meeting with the funding agencies, and she knows that she'd better have quick answers to their queries this time, or else FSGK might lose a significant portion of its funding. Maiko Ito, the programmer working for FSGK, suggested using Access to prototype an information system so that statistics can quickly be obtained using Access's Report Writer. To Barbara's delight, Maiko created a prototype within a week that could accept data input, and a massive data conversion effort was immediately started. Four clerks were hired to enter the manual files into four Access databases, which were later merged to form a master database. Reports were created as the data conversion proceeded. In less than a month, the prototype was completed, and the reports were all satisfactory to Barbara. Maiko was then assigned to other projects. Unfortunately, the week prior to Barbara's meeting with the funding agencies, the FSGK office was broken into, and among the items stolen was the computer with the Access prototype containing highly-sensitive clinical data. Maiko had not implemented any safeguards to protect the Access applications. The RCMP was called, but according to the RCMP officer in charge of the case, the chances of recovering the stolen computer are slim because it is one of the easiest items to sell. Maiko told Barbara that anyone who knows how to use Access could browse the confidential data files. To make matters worse, upon review of the clinical files to assess potential exposure to FSGK, Barbara discovered the names of several high-ranking government bureaucrats and ministers in the clinical database. Q: What went wrong here? What should have been done? Solution Rapid application development and joint application development Rapid application development (RAD) is a method of speeding up systems development and having systems operational more quickly than the traditional SDLC. This is done by dividing large projects or systems into subsystems and projects that can be completed in six months or less, thus producing usable deliverables and attaining some benefits at an early date using agile development techniques, which entails interaction between developers and users to make modifications during development making extensive use of joint application development (JAD), which entails group meetings of users, stakeholders, and IS personnel working on requirements analysis an approach that uses the synergy of groups to establish requirements in line with corporate goals using software designed to speed up development, such as fourth-generation languages (4GL), or products designed for particular platforms, such as Linux The use of RAD requires that the users (middle and senior management) be closely involved. This can be both

12 an advantage and a disadvantage. Projects that tend to benefit most from JAD are management information systems and decision support systems rather than transaction processing systems. End-user SDLC The widespread use of microcomputers, workstations, and the accompanying software such as Excel and Access has given end-users powerful tools. For many years, end-users who are frustrated with the backlog of projects in the information systems department have developed systems on their own. Some of the systems work well, while others do not. Generally, they meet the needs of the end-users who developed them. However, systems developed by end-users have their problems: Few are well documented. Different end-users with similar needs often develop systems independently. End-user systems may be incompatible with each other or with the corporate systems. They are not supported. They may be difficult or impossible to upgrade. They may be dependent on the end-user who developed it, so that when that person leaves, the system cannot be maintained. In recent years, many organizations have recognized the problems associated with end-user developed systems and have developed approaches that offset these problems, while taking advantage of the end-users' knowledge of their own business areas and willingness to spend time and effort on systems that they need and want. To this end, some organizations have encouraged staff members within the user departments to be groomed as business analysts. They will have a good knowledge of their organizational unit as well as some systems and technical skills. Whether this position exists or not, end-users should be supported by information systems staff who can offer training in skills, concepts, technical support, and expertise; publish and communicate corporate systems standards; and promote user-developed systems that can be used in more than one department. Outsourcing Outsourcing is becoming more common as an approach to systems development, particularly in North America and international organizations. The major reason is economics. It is sometimes cheaper to pay programmers in another country, say in Asia, than in North America, even when the costs of communication and travel are included. However, outsourcing has its problems, especially in communicating needs and requirements, because there may be a lack of understanding of what the users really want. This has led some companies to bring systems development back in-house. The SDLC and its alternatives apply to large businesses and major projects. Solving a simple problem does not require such rigid and formal procedures. Topic 5.2 will illustrate how to solve a simple information systems problem using Excel. In addition, very few small businesses develop a major system. They do not have the resources to do so, nor do they generally have the ability to develop requirements or specifications properly. In most cases, their needs can be served by acquiring off-the-shelf packages. If they need help in doing so, they might use an outside consultant. The general steps will be explained further in Topic 5.8. The problem facing Barbara in Example 4.1 illustrates one of the major weaknesses of prototyping. The lack of discipline in prototyping and the emphasis on quick results have put FSGK at major risk. The prototype should not be considered finished until proper internal controls and data security measures have been implemented. If the Access databases had been encrypted, then even if the computer was stolen, FSGK would not have exposed its clients' sensitive data. Other measures, such as software that locks the hard drive using password control, could also have been put in place.

13 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.5 Factors affecting systems development success Learning objective Identify several factors that influence the success or failure of a systems development project. (Level 1) Required reading LEVEL 1 Chapter 12, pages A successful system can be defined as one that meets user and organizational needs, including the performance measures. A successful systems development project delivers a successful system on time and within budget. Many factors affect the degree of success or contribute to the failure of a system. Challenges in managing IS projects Proper project management and risk management techniques are important for the success of projects. One main risk of systems development is the big uncertainty associated with systems design and programming activities. It is difficult at the start of a project to estimate the time and resources required at each stage of the project. An organization should implement standardized project management policies and procedures to help manage the risks inherent in developing new information systems. The main task is to try to manage the uncertainties by implementing detailed project plans and cost estimates. Some of the techniques include managing the impact of change through open and continuous communication throughout the organization, obtaining senior management support, and staffing the project with the right resources. Utilizing project management software also helps in identifying new risks and changes in scope that may affect the project timelines. Once issues are identified, the organization should have an established process on how to handle and resolve any issues. Degree of change Any new system will bring changes. The change resulting from different projects will range from minor enhancements to major restructuring and reengineering. Those involved in developing new systems need to understand the degree of change and how to manage change. The ability of a new system to integrate with other existing systems may also affect the success of the new system. Managing change The project team must be prepared to deal with the concerns of users and stakeholders at the outset. Project personnel must be sensitive to the feelings of the workers and gain their cooperation and acceptance at the development stage, well before implementing the new system. It is usually too late to involve users and try to obtain their acceptance at the conversion stage. If users do not accept the changes, they can sabotage the new system consciously or subconsciously. One result of introducing a new information system is often staff layoffs not only clerical workers but also managers. Even if a new information system does not result in staff layoffs, this fear is still very real and it may lead to key people exiting the organization well before jobs are terminated. Organizations should deal with this issue as early as possible in the systems development process. If jobs are affected, the impact should be carefully explained to the employees affected. If the organization includes unions, then the collective agreement will be affected, and union representatives need to be included in early discussions. Where possible,

14 there should be a good-faith effort to provide relocation help to staff facing layoffs. This may include providing information about publicly-provided services, counselling, and placement services. In other words, it makes sense from both an ethical and a business perspective to manage downsizing in a thoughtful and humane manner. The introduction of a new information system often changes the power structure of an organization. Information is power, and new systems often change who has access and control over certain information. The new system may affect how jobs are done and reassign responsibilities, resulting in significant structural changes in the organization. Such impacts should be carefully assessed and clearly explained to the affected parties prior to implementation. Changes are often disruptive. Some workers have a legitimate fear of the unfamiliar environment introduced by the new system. The best way to deal with such fears is comprehensive training, tailored to individual needs if possible. The best way to alleviate fears associated with change is to find out what concerns people have and address them. Managers, stakeholders, and members of the project team all need to be involved in this process. Involving users in the project and having a person represent each type of worker or organizational unit that will be affected is often a successful approach. The use of business analysts who are members of user groups and not systems staff should provide assurance that the new system will be developed according to user needs. A recurring problem is that of managing expectations, both positive and negative. Sometimes, poorly-designed systems are loved by the users and well-designed systems are hated and not used. Some people are overly optimistic and expect the new system to do far more than was intended. Others expect difficulties and may become instruments of self-fulfilling prophecies. Managing expectations during the development, especially in terms of time, is important. In reality, few systems are delivered perfectly on time. Continual involvement of all stakeholders and constant communication with them is the best way to handle this problem. Quality of project planning and project manager A successful project usually has the right project manager who has excellent communications, negotiating, and interpersonal-relationship skills. Project management consists of planning, directing, scheduling, and controlling human, financial, and technological resources for a fixed-term task that will result in the achievement of specific goals and objectives. Simply stated, a manager gets things done by providing leadership and working with people. Learning from previous experience with systems development can be a key factor in the success of future projects. Use of project management tools All projects need to be managed. You should understand the terms project schedule, project milestone, and project deadline, be able to explain the term critical path and how it is derived, and understand the concept and methodology of program evaluation and review technique (PERT). You are not expected to be able to develop a PERT diagram or to calculate critical path in this course. However, you should be able to describe a Gantt chart, which is a simple graphic chart that shows progress on project activities during calendar periods. All of these tools can be automated, and the text lists some project management software in Table 12.6(page 500), most of which includes these tools. An example of a Gantt Chart follows:

15 Notes: 1. Period can be day, week, quarter, or month. 2. Lines show expected start and end dates for each task. 3. Some tasks can be done concurrently. 4. Some tasks can start before other tasks are completed. 5. Some tasks cannot start until other tasks are completed. 6. Actual task status can be shown by drawing a line of a different colour below the expected task start and finish. For every form of project management tool, the team needs to identify all the activities that are required to complete a project. In order to manage a project, the project leader or project manager must also identify the resources required to accomplish each activity and the people responsible for each activity, estimate the time each activity will take to complete, and identify the relationships between activities. Some activities are sequential one cannot commence until another has been completed (for example, hardware cannot be installed until it has been ordered and delivered) while others can be done concurrently (for example, hardware can be installed while software is being developed). Schedules are not written on tablets of stone some flexibility is required. The various project management tools help the project manager (and others) see quickly and early in the development when and where the project is falling behind or likely to miss target dates. Through discussion with the appropriate people, the project manager will determine the appropriate or acceptable action to take, which might mean adding resources, changing the time frame, or changing the scope. Use of formal quality assurance processes Software developers typically maintain the time and cost budgets and sacrifice quality (scope). ISO 9000 standards were developed to assist organizations to document their quality assurance procedures. Many IS groups have incorporated ISO 9000 and other techniques into their software development process, and may even have a quality assurance group to work with project teams. Use of computer-aided software engineering (CASE) tools Computer-aided software engineering (CASE) is becoming increasingly important to manage and automate the systems development process. CASE is the application of computer technology to systems

16 development activities. CASE tools are computer programs designed to automate or support one or more phases of a systems development life cycle. It is not an alternative to systems development techniques but a software tool used to assist in the project development, regardless of the techniques that may be used in the project. CASE tools require training and discipline. Most CASE tools provide the means to create a central repository for project information, such as the results of systems analysis, systems design, data flow diagrams, data dictionary, structure charts, and systems flowcharts. CASE can provide many benefits to a systems development project, including Increased productivity. Because CASE automates many of the tedious, routine activities of systems analysts and programmers, it can reduce the time needed to complete such tasks. For example, if data flow diagrams are developed using a CASE tool, updating the DFDs is a relatively simple task. However, if the DFDs are hand-drawn, making changes can require an extensive amount of rework. Improved quality. CASE can reduce or eliminate errors and omissions in systems specifications and design because of the discipline it imposes on analysts and programmers. Also, using CASE to manage the project information ensures that current information is accessible to everyone on the project at all times. Improved documentation. CASE tools make it easier to keep project documentation current, thus reducing the chance of misunderstanding and errors arising from the use of obsolete information. Reduced system maintenance costs. Project and systems documentation maintained in CASE tools can reduce the cost of system maintenance by reducing the amount of effort required to keep documentation current. Review Table 12.8 on page 500 for the advantages and disadvantages of CASE tools. Object-oriented systems development Object-oriented programming (OOP) speeds up the programming and modelling tasks. By combining the power of OOP with the logic of an SDLC, object-oriented systems development (OOSD) can accelerate systems development through accelerating the systems design, implementation, and maintenance phases of the SDLC. The six phases for an OOSD are listed on page 501. They are similar to the SDLC.

17 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.6 Systems investigation Learning objective State the purpose of systems investigation, and describe technology, operational, schedule, economic, and legal feasibility assessments. (Level 1) Required reading LEVEL 1 Chapter 12, pages Systems investigation is the first phase in the traditional SDLC. Regardless of how a systems development project was initiated, systems investigation identifies problems or opportunities and attempts to determine what system components will be required, the costs, and the risks. Initiating systems investigation A commonly used method of formally initiating a systems development project the systems request form provides enough information to enable managers to determine if and when to initiate systems investigation. Participants in systems investigation Participants in a systems development project often vary from phase to phase (for example, programmers do not participate until the implementation phase), and the first task is to identify who should participate in the investigation phase. It is imperative that members of the functional units participate closely together with those who understand the financial and technical implications, ideally at the managerial level. At the end of this phase, the group will present a report to senior management. Feasibility analysis A major task for the investigation team is to conduct a feasibility analysis that will evaluate the technical, operational, schedule, economic, and legal feasibility of the project (using the mnemonic TELOS will help you remember the different types of feasibility). Each aspect may require a separate study, depending on the complexity of the project. The purpose of each is as follows: Technical feasibility: Does technology exist to solve the identified problem? Can the necessary components be acquired or developed? Economic feasibility: Can the organization afford the changes? Do benefits outweigh costs? How long will it take to obtain benefits? What is the ROI? Legal feasibility: Are there legal implications in implementing the project? Is there current or proposed future legislation that could result in legal action? Operational feasibility: Do users have the skill levels required to operate the new information system, or can they be trained to acquire the skills? What is the degree of change and how will it be accepted? What is the effect on the organizational structure and on people s jobs? How are collective agreements affected? Are there ethical issues involved? Schedule feasibility: How long will this take to complete? What other projects are competing

18 for resources? In assessing the operational feasibility of a project, be aware of organizational and personnel limitations. Many mistakes arise because organizational and personnel limitations are not properly understood. For the same type of problem, a particular technological solution may work well for one organization but fail miserably in another, simply due to the differences in personnel in the two organizations. The text focuses on the economic feasibility of solutions, and as an accountant, you would be expected to understand this. But other factors should be considered. A solution can be technically and economically feasible, but should still not be implemented if the organization does not have the capacity, expertise, or corporate culture to support the solution. Take, for example, a centrally-controlled organization with centralized decision making. This organization would be ill-advised to implement an information system that encourages or enables distributed decision making, unless the organization is prepared to change its mode of decision making to adapt to the technology. Example 4.2 demonstrates the elements of critical thinking in problem analysis and problem understanding. Example 4.2 Problem solving Computer system upgrade Pacific Exports Limited (PEL) is an international trading conglomerate whose head office is located in Vancouver. The head office has 40 staff and has been using a turnkey minicomputer system with thin client terminals for many years. The users are happy with the application programs, which were custom-designed for PEL by an external systems development firm over a 10-year period. However, the minicomputer is running out of capacity. PEL has hired Fred Silverman, a management consultant, to investigate the problem. Until now, the PEL staff has been relying on an external systems development firm for all technical support. The application programs require little training because transaction entries and report generation are performed using custom-designed menus. Most PEL employees have been with the company for over 20 years, and they are comfortable with the computer systems. Indeed, most of them are part owners of PEL, having invested heavily over the years through stock options and payroll contributions. They have also built a strong network of business contacts throughout the Pacific Rim. Because personal contact is integral to successful business dealings with Pacific Rim countries, these staff members have become an invaluable human asset to the firm. After analyzing PEL s requirements, Fred has recommended installing a LAN to replace the aging minicomputer. He determined that all of PEL s computing needs could readily be met by purchasing off-the-shelf computer software. Fred dismissed the option of upgrading the minicomputer and continuing to run the current software because the LAN solution is significantly cheaper in terms of hardware and maintenance costs. He believes that the technological momentum supports LAN systems, not minicomputers, and that a LAN solution will provide better flexibility to PEL in responding to its future computing needs. Q: What has Fred overlooked in his recommendation? What would you recommend to Fred in this case? Solution To be successful, an information system requires the application of appropriate technology. Technology, however, should not be selected in isolation. How the technology fits in the organization and how the people in the organization can use it are equally important considerations. Net present value is the preferred method of weighing the economic value of one project against other projects competing for investment funds, and for determining the economic feasibility of a project. However, other methods such as return on investment (ROI), internal rate of return (IRR), and total cost of ownership (TCO) could also be used. As accounting students, you are expected to understand net present value and why it would be the preferred method. For example, it factors in the cost of capital and the passage of time.

19 Object-oriented systems investigation Although the text states that OOPS case diagram is part of the systems investigation stage, it is actually part of the systems analysis stage. Systems investigation report The major deliverable resulting from the systems investigation phase is the systems investigation report. The first section of a typical report addresses goals and objectives. The first step in systems investigation is to establish the objectives of the new system according to corporate goals. The importance of this cannot be overemphasized. If an information system is designed and implemented without a proper understanding of the organization's objectives, even if it is flawless, it would at best be ineffective, and at worst undermine the organization's goals. Within the corporate framework, specific objectives for the solution must be established. The report is presented to a group called a steering committee, which consists of representatives of IS and major functional areas. The report will be assessed and a decision taken to proceed as recommended modify the project, such as changing the focus or scope cancel the project defer the project, a decision that may be made based on factors of which the project team is unaware, such as a pending merger or acquisition The steering group decisions are guided by 1) whether the recommended solution meets the organization's objectives, and 2) whether the organization has, or can, acquire the required resources to implement the solution. Many organizations follow formal procedures in the funding of information systems development. An example is capital budgeting, in which the information systems development requests are considered with other capital budget requests, and each request is analyzed on its own merit. This is one reason that economic feasibility is so important, especially the cost/benefit analysis. Although Fred has concluded that a LAN solution is both technically and economically feasible for PEL, he has not considered whether PEL has the organizational abilities to adapt to the LAN environment. In this case, if a LAN is installed, PEL's staff may be unable to cope with the new technology. Although a LAN may be economically and technically superior, it may not fit the corporate culture at PEL. In this case, Fred should consider the option of upgrading the existing minicomputer. He should explore this option along with the LAN option in consultation with PEL staff. The minicomputer application programs are providing effective service. Therefore, replacing the minicomputer with a more powerful and current unit seems to be the optimum solution for PEL. The LAN solution may be too disruptive and foreign to PEL

20 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.7 Systems analysis Learning objective Explain the purpose of systems analysis and describe some of the tools and techniques used in this phase of systems development. (Level 1) Required reading Chapter 12, pages Textbook erratum: On page 511, the third sentence of the second paragraph under Requirements Analysis should read: "For example, an accounts receivable manager may want a better procedure for tracking the amount owed by customers." LEVEL 1 If the systems investigation report results in the steering committee s approval to proceed with the project (either as recommended or in a modified form), the next phase of the SDLC systems analysis can begin. Systems analysis entails determining more precisely what the information system must do to solve the problem or realize the opportunity that initiated the project in the first place. In order to do this, the existing system and the organizational environment must be studied. This involves defining more precisely what a new system needs to do, determining what processes need to be reengineered, what constraints exist for possible new systems, what alternatives exist, and which is most appropriate. The key deliverable of the systems analysis phase is a complete list of user and organizational requirements, prioritized as to what is essential and what is desirable but not essential. These are the functional requirements of the system. General considerations Although it is desirable to use the formal approach for every system design, the size of the project, not the size of the organization, dictates the degree of formality. Generally speaking, a small company may not require the more formalized process that is needed to evaluate a complex system in a large company because it tends to implement off-the-shelf applications. Participants in systems analysis The analysis team will include some or all of the members of the investigation team. The initial task in systems analysis is to plan the analysis phase in more detail than was done in the investigation phase, especially in regard to assignment of tasks and scheduling of activities. In most cases, when a steering committee approves a project, it also approves the budget for the systems analysis phase. The project manager is responsible for establishing project management techniques that monitor the budget as well as progress in activities. Data collection Detailed analysis requires an understanding of the functions, limitations, and constraints of the existing system. The first step in this phase is to identify the sources of data, which can be both internal and external. Systems analysis must look into the organization from both internal and external viewpoints. Sometimes a

21 problem is the result of an outdated culture; sometimes it is caused by an organization failing to respond to changing external factors. To be complete, an analysis must include a detailed and sometimes soul-searching analysis of the organizational culture and operations. Then the changes that may be necessary need to be identified. The external factors are equally important. With increasing global competition, no industry or organization can be shielded from competitive pressure. What worked perfectly a decade ago may cause the organization to go bankrupt now. This is particularly true of businesses in declining sectors of the economy. In collecting data about the existing system, analysts use a number of techniques. These include questionnaires, interviews, hands-on evaluation, and observation of the current method and procedures. The following is a description of these techniques. Interviews Regardless of whether a system is manual or computerized, the interview technique can yield valuable results. Workers who follow the manual procedures or use the existing information system are interviewed in a group setting and on a one-to-one basis. During the interviews, a skilful analyst can learn much about the strengths and weaknesses of the existing procedures or system. Experienced analysts, like physicians, react to the information from the interviews and explore areas that they may not have been aware of prior to the interview. Most interviews are conducted in the absence of the supervisor or manager so that the workers can freely discuss the strengths and weaknesses of the procedures or system. Interviews may be structured, where questions are carefully planned in advance, or unstructured, which allows the interviewee to speak about matters that had not been thought of by the team. The latter approach relies upon the skill of the interviewer to gather data from the flow of the interview and to follow up on or clarify questions immediately. While it is best to conduct interviews face-to-face, it is sometimes possible to substitute with telephone calls, especially when dealing with individuals at remote locations or external to the organization. Questionnaires An analyst can obtain valuable information about an existing system by using carefully designed questionnaires. These questionnaires are sent to management and workers for feedback on the existing procedures or system. They are asked about their experience with the procedures or system and to make suggestions for improvements. Questionnaires are often used prior to interviews, seldom in isolation. This is because the questionnaires may not be all-inclusive areas that the analyst is not yet aware of will not have been included in the questionnaire. Where personnel are widely dispersed geographically, questionnaires may be substituted for interviews. Questionnaires may also be structured or unstructured, with the structured questionnaire asking a series of carefully planned questions about specific topics and the unstructured questionnaire allowing the respondent to discuss areas that may not have been thought of by the questionnaire designer. Each type has its uses and proponents. Structured questionnaires are easier to tabulate and analyze but may omit important facts. Statistical sampling Where there are large volumes of documents, an analyst can take random samples. Hands-on evaluation Although not described in the text, if an existing system is in place, one very effective analysis technique is to conduct a hands-on evaluation of the system to gain insight into its strengths and weaknesses. Also, the analyst should be able to assess the system directly and form an opinion on the system. One method of performing this is to design input data that will test how the system handles a variety of situations and transactions, including erroneous data or data that is not in accordance with company policies and procedures. Direct observation

22 Another important technique is the actual observation of the procedures or system. Analysts must not interfere with the procedures or system under observation. They should also be aware of the influence of the Hawthorn effect (illustrated in Example 4.3 following) on the observation. Through observation, the analyst confirms or modifies the information gained through questionnaires and interviews. Example 4.3 The Hawthorn effect From 1927 to 1932, a series of experiments were conducted at the Hawthorn plant of the Western Electric Company. These experiments were designed to study the behaviour of workers in organizations, the impact of the workplace environment on productivity, and the relationship between compensation methods and productivity. In one particular experiment, researchers wanted to study the effect of the level of light on performance. The workplace lighting was manipulated (increased and decreased) on an experimental group of employees, while that for the control group was unchanged. As expected, when the lighting was increased for the experimental group, its performance increased as expected. However, to the surprise of the researchers, when the lighting was decreased for the same experimental group, its productivity continued to improve until it became too dark to perform the work. The surprising result from these experiments was that the workers reacted to the attention paid to them by the observers more than to the particular factor introduced in the experiment, such as changes in the workplace environment. Workers became more productive simply because they were given special attention during the experiment. Q: Why should an analyst be concerned about the Hawthorn effect while observing the behaviour of the users during the analysis phase? Solution Data analysis The data collected must be tabulated and manipulated to determine the requirements of the new system. This manipulation is called data analysis. In analyzing the existing system, project team members use a number of techniques. These include data modelling, activity modelling via data flow diagrams, application flowcharts, grid charts, and CASE tools. You should understand what these techniques are and how they are used, but this course will focus on data flow diagrams. The following is a description of these techniques. Data modelling Data modelling is used to show the relationships and associations between objects. The tool used most often is called an entity-relationship diagram (ERD). Activity modelling It is not enough to simply show relationships between objects. In order to analyze systems and develop new and improved ones, you need to know events or activities that take place. One of the easiest tools to use that will accomplish this is the data flow diagram (DFD). At the end of this topic, DFDs will be explained more fully, including how to draw them. Application flowcharts Application flowcharts are a simple method of showing how different applications or subsystems relate to each other. This is a useful way of getting a clear picture of applications within the system under review, or

23 between the system under review and other systems. The team needs to know this when developing a new system, so that applications outside of the system under review receive the data that they require, or changes can be made to those applications also. Grid charts A grid chart is another readily usable tool that shows relationships among various aspects of systems. The example used in the text shows which applications share databases. This is important to know when designing the new system because what happens in one application affects other applications sharing that database. CASE tools CASE tools can be used to generate many of the diagrams and charts used in systems analysis. Furthermore, the data analysis phase is when the team starts to develop the CASE repository (also known as a project directory). Requirements analysis The requirements analysis task is undertaken to determine the needs of the users, stakeholders, and the organization, and to translate these into detailed systems requirements. Some of the techniques used in this activity are as follows: Asking directly: Users and stakeholders are asked what they need or want, and their responses are translated into system requirements. Critical success factors: These can be used to develop detailed requirements and specifications. IT plan: An IT plan ensures that the new system will both meet organizational objectives and fit in with the framework for systems development and technological architecture in the future. Screen and reports layout: Although these tools may be used in the systems analysis stage, in real life, they are usually part of detailed systems design. What is generally done is to identify what information users and stakeholders need, what reports may be required, and the contents of those reports, rather than detailed layouts. Requirements analysis tools: These are generally the same tools used for systems analysis, with CASE tools and the CASE repository often used extensively. Object-oriented analysis The object-oriented approach can be a useful tool for analysis. Although the text implies that it replaces DFDs and other tools, in fact, these other tools are still useful because they enable the analyst to determine policies, procedures, and work flows. Systems analysis report The systems analysis phase has as its major deliverable a formal systems analysis report that completes this phase of the SDLC. Most reports include a section that updates the costs and benefits of the new system, because during this phase, the team has discovered data that had been unknown or omitted from the investigation phase. The systems analysis report takes into consideration changes to the environment, the organization, and technology that have occurred since the systems investigation report was produced. Included in the recommendations are how to proceed and an estimate of the cost and resources required to undertake the next phase systems design. Once again, senior management has several options open to them:

24 proceed as recommended modify the project, such as changing the focus or scope cancel the project defer the project, based on factors of which the project team is unaware One of the options, cancelling the project, may be an outcome of the systems analysis phase, whereby the project team has identified other systems that need to be changed. Management may decide that another system should be developed instead of this one, and authorize a systems investigation into that other system. They may also decide to defer this project until the other is developed.

25 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.8 Data flow diagrams Learning objective Use data flow diagrams for systems analysis and design. (Level 1) Required reading LEVEL 1 Chapter 12, page 509 Data flow diagrams as a systems analysis tool Now that you have studied the analysis stage, you will learn how to use data flow diagrams in more detail. A variety of tools are used in systems analysis and design. Perhaps the most popular tool is the data flow diagram. A data flow diagram (DFD) illustrates graphically the flow of data through a set of procedures or system and the work performed by the workers or the system. A data flow diagram (physical or logical) comprises only four symbols: data flow, data store, process, and external entity. A data flow, representing the flow of information, is shown as a line with an arrowhead and a label along the line. The label for a data flow must be a unique name describing the data. A data store is shown as a narrow rectangle, often open-ended, with a label inside. It represents a collection or repository of information, such as a filing cabinet or a computer file or database. A process is shown as a rectangular box with rounded corners, with a label inside. This symbol represents the action that transforms data. The label inside a process should always start with a verb to describe the transformation of data from incoming data to outgoing data. Alternately, a process can be shown as a circle. An external entity is shown as a square box with a label inside, and represents the source or destination of data. DFDs are suitable for both manual and computerized procedures. Because of its pictorial form, it is easy to understand, and the analyst and workers can easily detect errors and omissions. You do not need prior training to learn how to read a DFD and to follow its flows. Because of its simplicity, the DFD has become a commonly accepted technique used by analysts in documenting existing procedures or systems. DFDs facilitate user participation and increase productivity. They can also be broken down ("decomposed") into different levels of detail for clarification. There are two types of data flow diagrams: physical and logical. Physical data flow diagrams show how the current procedures or systems operate. Logical data flow diagrams show how the data should flow, regardless of the physical implementation. For example, a physical DFD may show a disc file, a database, or a filing cabinet, but a logical DFD would simply show a data store. A physical DFD would identify a specific source document such as a customer purchase order, but a logical DFD would only show the data on that document (parts order). A physical DFD would show who or what does the processing (for example, the order clerk verifies customer information), while a logical DFD simply identifies the process (verify customer information). A physical DFD would show temporary storage, such as a file containing orders that have been verified to be picked up by the next person who might be checking the inventory, but the logical DFD would show the data flowing to the next process as if there were no delays. When analyzing a new system, there is generally a current (and usually automated) system. In such cases, it is usually a good practice to start with physical DFDs, which describe the current system in detail. Detailed analysis then starts with converting the physical DFDs to logical DFDs or obtaining the logical DFD of the existing system. The purpose of this is to focus on what the existing system is designed to accomplish. One of the major advantages of DFDs is that users readily understand them, and therefore, they can more fully

26 participate in the analysis and review of the information flow. With a set of logical DFDs describing the current system (manual or computerized), the detailed analysis of the new system can proceed. The current logical DFDs are modified to incorporate the changes desired for the new system. Users and management then review the new logical DFDs to ensure that the new logical design is complete and appropriate. Example 4.4 illustrates how a physical DFD for an order entry system is drawn. Example 4.4 Drawing a physical data flow diagram An order entry subsystem is used to enable sales staff to enter purchase orders phoned in or mailed in by customers and to process the customer order. When a salesperson enters an order, the inventory file is checked to determine if there is sufficient quantity of the product on-hand. If so, the order is confirmed. A database program updates the inventory record in the inventory file and prints a picking slip for the warehouse. Based on the information from the picking slip, the warehouse staff picks the goods off the racks and sends the package of goods, including a packing slip, to the customer. Lastly, the accounting department sends a copy of the invoice to the customer. If the quantity on-hand is insufficient, the order is not confirmed, and the database program prints a backorder notice that is then sent to the customer. Exhibit 4-1 is a physical data flow diagram for this order entry subsystem. Exhibit 4-1 Physical data flow diagram for an order entry subsystem

27 Notes: 1. The square is an EXTERNAL ENTITY a person or an object that is outside the system but provides input or receives output from the system. 2. The lines are flow lines with the arrow showing direction of flow. In the physical DFD, the object that carries the information is described, such as "packing slip," but in the logical DFD, the information is described, such as "shipped good information." 3. The rounded rectangle (also depicted as a circle) identifies a process or subprocess. Here in a physical DFD, the first process is identified by the thing that does the process (salesperson) and what the thing does (enter order), whereas a logical DFD would only show the process (order entry). 4. The open rectangle represents storage. In a physical DFD, it is described as an "inventory file," but in a logical DFD, it would only show "inventory" without stating the physical method of storage.

28 Each of the processes in Exhibit 4-1 can be described in more detail using one or more DFDs, a process called decomposition. For example, the process "Enter order" can be depicted in another DFD, which shows details on how data is entered. As you can see from Exhibit 4-1, the data flows and various processes and data stores are not detailed. To compensate for this lack of detail, a data dictionary is often used. A data dictionary is a repository of information about each of the data flows, processes, and data stores. If a user or analyst wants to know more about a particular aspect of a data flow diagram, the data dictionary is consulted. Example 4.5 illustrates an entry in a data dictionary. Example 4.5 An entry in a data dictionary The following is a possible data dictionary entry for one of the items the invoice in the physical data flow diagram in Exhibit 4-1: An INVOICE consists of the following data elements: INVOICE NUMBER INVOICE DATE CUSTOMER ACCOUNT NUMBER CUSTOMER NAME CUSTOMER ADDRESS BILL TO ADDRESS SHIP TO ADDRESS PURCHASE ORDER NUMBER 1 to 20 lines made up of: PRODUCT NUMBER PRODUCT DESCRIPTION QUANTITY ORDERED AND SHIPPED UNIT PRICE EXTENDED PRICE SUBTOTAL DISCOUNT FREIGHT PROVINCIAL SALES TAX GOODS AND SERVICES TAX TOTAL INVOICE AMOUNT PAYMENT TERMS Q: Why is a data dictionary description necessary for each of the items in a data flow diagram? Solution

29 Course Schedule Course Modules Review and Practice Exam Preparation Resources 4.9 Using Excel as a data flow diagram drawing tool Learning objective Use Excel for data flow diagramming. (Level 1) LEVEL 1 In Computer illustration 4-1 following, you will learn how to draw a data flow diagram using Microsoft Excel. Computer illustration 4-1: Using Excel to draw DFDs Learning objective Required Use Excel to draw data flow diagrams. Use Excel to complete a partially drawn data flow diagram. Once done, the completed data flow diagram should be similar to that in Exhibit 4-1. Procedure Start Microsoft Excel and open the workbook MS1M4P1. This file contains two worksheets: M4P1 (partially completed for you to work on) and M4P1S (solution worksheet). Symbols Although Excel is not designed to be a charting application, its drawing capabilities provide it with sufficient functionality to create simple DFDs and other charts. On the Insert tab, under Illustrations, select Shapes. You can see all the basic symbols needed to draw a DFD. For the data store symbol, simply use a narrow rectangle. To draw the connectors, choose from the subpanel for Lines. Exhibit 4-2 Drawing a physical data flow diagram

30 Drawing a symbol Compare carefully the partially completed diagram with Exhibit 4-1 in Topic 4.8. You will notice that the process with the Process ID "Database PGM" and the label "Print notice" is missing from the diagram. To add this process to the diagram: 1. Select the Rounded rectangle tool from the Shapes subpanel. 2. Move the mouse pointer to the desired location in the drawing area. Don't be overly concerned about the exact location; you can move the symbol easily afterwards. 3. Click and hold down the left mouse button, then drag the mouse until the symbol has the desired size (use the other process symbols on the diagram as a guide). Don't be overly concerned about the exact size; you can easily resize symbols afterwards. 4. From the Insert tab, choose the Text Box tool icon. 5. Click inside the process symbol that you just created to activate the area for typing. 6. Type Database PGM and Print notice into the process symbol. You may format your text using the standard formatting features (highlight the text you want to format, then apply format), and

31 press ENTER to move to a new line. Editing a symbol Notice that the process with the Process ID "Salesperson" in Exhibit 4-1 has not been properly labelled in the partially completed diagram. You can change the Process ID or label of a symbol as follows: 1. From the Drawing toolbar, choose the Text Box tool icon. 2. Click inside the process symbol that you want to edit. 3. Type Salesperson and Enter order into the process symbol. Format the text for clarity, as per step 6, above. Note: You may need to resize the symbol in order for the text to fit inside. If this is the case, click and hold down the left mouse button on one of the white squares on the edge of the symbol, then drag the mouse until the symbol has the desired size. The process is now properly labelled. Drawing a data flow Notice that the data flow between the "Enter order" process and the "Print notice" process is missing. To draw a data flow between two symbols in the DFD, link the symbols together as follows: 1. Choose the Elbow Arrow Connector from the Lines subpanel. 2. Move the mouse pointer to the symbol where the data flow starts ("Enter order" process). You will notice that small squares appear at the available connection points for the symbol. Over the connection point that is closest to the "Print notice" process, click and hold down the left mouse button, then drag the mouse to the appropriate connection point on the "Print notice" process symbol. Available connection points on the "Print notice" symbol will appear when the mouse pointer rolls over the symbol. You will notice that the connector will snap to these points automatically. Simply release the mouse button when you have chosen the connection point you want. 3. To label the data flow, select a cell that is adjacent to the data flow you just created and type Unconfirmed order. 4. Repeat steps 1 to 3 to draw a data flow between the "Print notice" process and the "Customer" entity. Type Backorder notice to label this data flow. The completed diagram should look like Exhibit 4-1. If it does not, you can click the sheet tab M4P1S to review the solution. There are some other common functions you need to know. Editing a data flow The links between symbols can be changed as follows: 1. Click on the connector that you want to edit. Notice that the ends of the connector are highlighted with red circles these are referred to as editing handles. 2. Click on one of the handles and hold down the left mouse button, then drag the mouse to the new connection point you desire. If the connector contains multiple line segments, yellow editing handles will appear at segment midpoints. Click and drag these handles to change line segment

32 positions. 3. If you want to change a label, simply select the cell that contains the label and type in a new label. Deleting a symbol or data flow Symbols and data flows can be deleted as follows: 1. Click on the symbol or data flow that you want to delete. 2. Press the Delete key. Also remember to delete any labels for data flows you delete. Copying the diagram to Word After you have completed the diagram, if you need to submit it for an assignment, you can copy it to a Word document using these steps: 1. Select the area of the worksheet that you want to copy by selecting it. 2. On the Home tab, choose the Copy icon. 3. Start Word and open the document on which you need to paste the diagram. 4. Click where you want to insert the diagram. Choose Paste, Paste Special, then choose Picture from the list, and click OK. The diagram is pasted into the Word document as a picture. You can move and resize the diagram as desired. Note that the pasted diagram is not linked to the Excel file this way. If you edit the original diagram in Excel, you will need to delete the pasted diagram in Word and paste the updated diagram again. Note also that the diagram can be done directly in Word, rather than in Excel and then pasted into Word. Summary Excel's drawing functionality can be used to draw DFDs and flowcharts. In this computer illustration, you learned the basics of drawing data flow diagrams using this tool. For further help on using the program, you can use the Help function.

33 Course Schedule Course Modules Review and Practice Exam Preparation Resources Module 4 summary The systems development process When systems analysts implement a new system using the systems development methodology, they follow a set of guidelines for the steps that must be performed and the documentation that must be produced. In addition, the methodology recommends the use of particular analysis, design, and implementation techniques. In this module, you are introduced to these problem-solving processes. You also learn how to use Excel to draw data flow diagrams. Identify the key participants in the systems development process and the major reasons for initiating a systems project. Participants in systems development are stakeholders to whom the outcome is important users who will interact with the system systems analysts who coordinate development and liaise between technical and non-technical people business analysts who represent a key department and coordinate with technical and non-technical persons outside consultants and auditor steering committee of senior management for overall direction team leader for large projects (for a small business) the systems analyst and business owner/accountant or comptroller The major reasons for initiating systems development are problems with existing systems desire to exploit new opportunities, such as e-commerce increasing competition desire to make more effective use of information organizational growth merger or acquisition change in market or external environment new laws or regulations government incentives Define the term "information systems planning" and explain the objectives of systems development. Information systems planning While some systems changes are unplanned (for example, new legislation), most should result from the organization's strategic plan. Information systems planning is the translation of strategic and organizational goals into systems development initiatives. Projects must compete for limited resources. Higher priority is given to those that present a competitive advantage, shown by creative analysis viewing problems/processes in new and different ways critical analysis throwing out predetermined notions, examining what is being done and why

34 Objectives of systems development Mission-critical systems that are key to the organization's operations and success will receive the highest priority. Critical success factors by which functional areas are measured must be translated into systems objectives and form part of its functional requirements. Performance objectives and cost objectives must be defined at the outset and stated in measurable terms. Performance objectives include the quality or usefulness of the output the speed at which output is generated Cost factors include development costs costs related to the uniqueness of the application investments in hardware and equipment ongoing operating costs Describe the major stages, advantages, and disadvantages of the traditional systems development life cycle. SDLC is used to impose some form of discipline on IT development. The text suggests five stages, but a commonly accepted SDLC (with the text equivalent in parenthesis) follows: 1. preliminary analysis (systems investigation) 2. systems analysis (systems analysis) 3. systems design (systems design) 4. programming and testing (systems implementation software acquisition) 5. acquisition (systems implementation acquisition) 6. installation (systems implementation installation, testing, startup, and acceptance) 7. post-implementation review (systems maintenance and review) 8. maintenance (systems maintenance and review) At the end of each stage, senior management decides whether to continue or take other action, based on a report. Typical reports for the eight stages of SDLC follow: 1. preliminary analysis report (preliminary analysis) 2. analysis report (systems analysis) 3. design document (systems design) 4. programs and status report (programming and testing) 5. acquisition proposal (acquisition) 6. project completion report (installation) 7. post-implementation review report (post-implementation review) 8. request for maintenance (maintenance) The major strength of the SDLC is its structured approach to the development of IT. The traditional SDLC, which is inflexible and unable to meet changes in user requirements, is often not sufficiently responsive to the changing business environment.

35 Describe the features, advantages, and disadvantages of alternative approaches to the traditional approach, including prototyping, rapid application development, outsourcing, and end-user systems development life cycles. Prototyping There are alternatives to the SDLC, which are not necessarily mutually exclusive, and may be incorporated into an SDLC: prototyping off-the-shelf software packages outsourcing Prototyping is the process of building an experimental system or part of a system rapidly for business specialists to interact with and evaluate. The process is highly interactive and iterative. Four steps to prototyping are identify preliminary requirements develop a working prototype use the prototype refine and enhance the prototype Systems development approaches Rapid application development (RAD) may be used to speed up systems development by breaking a project into smaller subprojects. RAD may use joint application development (JAD), which makes use of the synergy of groups. 4GL or platform-specific software may also speed up development. End-user development often occurs. In order to facilitate the process and ensure adherence to corporate goals and standards, some organizations support end-users via special staff or other means. Outsourcing development may be an economic alternative, but there are challenges in communications. Identify several factors that influence the success or failure of a systems development project. Degree of change New systems mean changes, and the change process must be properly managed. Quality of project planning Poorly planned projects generally go over budget, take longer, and may not solve the real problem. Use of formal quality assurance processes such as ISO 9000 and total quality management. Use of computer-aided software engineering (CASE) tools to manage the project. Use of project management tools These include project schedules, milestones, critical path, project evaluation and review techniques, and Gantt charts. Project management tools assist the project manager or team leader to manage the project, and facilitate communication among the participants.

36 Object-oriented systems development (OOSD) combines the power of object-oriented programming with the SDLC to accelerate systems development. State the purpose of systems investigation, and describe technology, operational, schedule, economic, and legal feasibility assessments. Systems investigation identifies problems or opportunities and attempts to determine what system components will be required, the costs, and the risks. Participants in the investigation phase must include members of the functional units, ideally at the managerial level, together with those who understand the financial and technical implications. At least one of these people should have good presentation skills, because at the end of this phase, the group will present a report to senior management. Systems investigation: feasibility analysis A major task for the investigation team is to conduct a feasibility analysis that will evaluate the feasibility of the project: Technical technology availability Operational impact on organization structure, people, collective agreements, degree of change Schedule time to complete and other projects ongoing Economic costs versus benefits and time to attain Legal current or future legislation that could affect the project Explain the purpose of systems analysis and describe some of the tools and techniques used in this phase of systems development. The purpose of systems analysis is to gather data, determine requirements, consider alternatives, and investigate feasibility. Data collection techniques include questionnaires structured or unstructured interviews structured or unstructured hands-on evaluation direct observation statistical sampling Data analysis techniques include data modelling entity-relationship diagram (ERD) activity modelling data flow diagram (DFD) application flowcharts grid charts CASE tools to start the project repository (project directory) The requirements analysis task is undertaken to determine the needs of the users, stakeholders, and the organization, and to translate these into detailed systems requirements. Techniques include asking directly critical success factors IT plan screen and report layouts The systems analysis report is the result of this phase and should include

37 strengths and weaknesses of the existing system user/stakeholder requirements functional specifications organizational requirements for the new system a description of what the system should do to solve the problem Use data flow diagrams for systems analysis and design. Logical DFDs show how the data should flow, regardless of physical implementation. Physical DFDs show what the processes and data are, how those processes are implemented, and how the data are represented. Four symbols on a DFD (logical or physical) are process shown as a rounded rectangle with a label inside; represents the action that transforms data data flow a line with an arrow-head and a label along the line showing the flow of information data store a narrow open-ended rectangle with a label inside; represents a collection or repository of information, such as a file cabinet or database external entity a square box with a label inside; represents the source or destination of data DFDs can be decomposed into different levels of detail for clarification. To supplement DFDs, a data dictionary is used to store information about each data flow, process, data store, and entity, so that a user or an analyst can find the meaning and other details of a particular element.

38 Course Schedule Course Modules Review and Practice Exam Preparation Resources Solution 1 c) Topic 4.7

39 Course Schedule Course Modules Review and Practice Exam Preparation Resources Solution 2 The following table summarizes five types of feasibility:

40 Course Schedule Course Modules Review and Practice Exam Preparation Resources Solution 3 Requirements analysis is undertaken to determine the needs of the users, stakeholders, and the organization, and to translate these into detailed systems requirements. User requirements can be difficult to articulate, so while the purpose seems straightforward, it can be difficult to achieve.

41 Course Schedule Course Modules Review and Practice Exam Preparation Resources Solution 4 Creative analysis involves investigating new approaches to existing problems, looking at problems in new or different ways, and introducing innovative methods to solve them.

42 Course Schedule Course Modules Review and Practice Exam Preparation Resources Solution 5 The following depicts the point-of-sale system. Physical data flow diagram for point-of-sale system

43 Course Schedule Course Modules Review and Practice Exam Preparation Resources The problem facing Barbara in Example 4.1 illustrates one of the major weaknesses of prototyping. The lack of discipline in prototyping and the emphasis on quick results have put FSGK at major risk. The prototype should not be considered finished until proper internal controls and data security measures have been implemented. If the Access databases had been encrypted, then even if the computer was stolen, FSGK would not have exposed its clients' sensitive data. Other measures, such as software that locks the hard drive using password control, could also have been put in place.

44 Course Schedule Course Modules Review and Practice Exam Preparation Resources Although Fred has concluded that a LAN solution is both technically and economically feasible for PEL, he has not considered whether PEL has the organizational abilities to adapt to the LAN environment. In this case, if a LAN is installed, PEL's staff may be unable to cope with the new technology. Although a LAN may be economically and technically superior, it may not fit the corporate culture at PEL. In this case, Fred should consider the option of upgrading the existing minicomputer. He should explore this option along with the LAN option in consultation with PEL staff. The minicomputer application programs are providing effective service. Therefore, replacing the minicomputer with a more powerful and current unit seems to be the optimum solution for PEL. The LAN solution may be too disruptive and foreign to PEL.