1. Systems Investigation and Analysis
How Do We Do Systems Development?
Systems development involves creating new systems or modifying existing business systems. After studying this chapter, you should be able to address the objectives on the next 3 slides.

2. Dilbert – 3/21/03

3. The Systems Analyst’s View
Information systems are developed by teams of people with a variety of skills, called the development team. Stakeholders are individuals who will benefit directly or indirectly from the information system. Users are the people who will regularly interact with the system. Users and stakeholders can be from inside or outside the organization, such as employees, customers, or suppliers.
Systems analysts study the requirements of the information system and design a new or modified system. Systems analysts are similar to an architect developing plans for a house, although they specify new or modified information systems. Programmers create or modify programs to meet the specifications the systems analysts developed.
There may be additional technical specialists on the development team, include database and telecommunications experts or hardware engineers. One or more system development roles or tasks may also be outsourced to contractors or consultants.

4. Project Leadership
The development team can range from a couple of people to dozens, depending on the size of the system being built. Each team has a team leader, although different types of leaders are recommended for different types of projects, as shown in Table Team leader are not always IS specialists. For example, if a system will re-engineer business processes in a specific area, a manager from that area should lead the team. If a project is large and complex, it may be wise to have a project management specialist lead the team. Although it can get complex, sometimes team leadership is shared by an IS person and an individual from a functional area.

5. Where Do Projects Come From?
Systems development starts when an individual or group with the ability to initiate organizational change sees the need or benefit from a new or modified system. Although systems development initiatives can start from all levels of an organization, not everyone in all companies has the status, power, or authority to initiate organizational change – and implementing an information systems ultimately means change to some degree. Often systems development is initiated by managers. Even if it is not, support of senior managers for a systems development effort is critical for its success, since senior managers control resources and can influence employee opinion.
Figure 12.2 shows some of the reasons development projects are initiated. Problems with the existing system, new opportunities or growth, or seeking a competitive advantage are clearly reasons. Mergers are an increasingly frequent motivation to initiate systems development. When companies merge, they often have incompatible information systems that must be bridged or modified. Systems development may also be started by forces outside the firm, such as market changes or new laws or regulations.

6. Strategic Alignment Model
Business
Strategy
External
I/T Strategy
Strategic Fit
Organizational
Processes
IT Infrastructure
& Processes
Internal
Functional Integration
Henderson, J. C. & Venkatraman, N. (1999) Strategic Alignment: Leveraging
information technology for transforming organizations. IBM Systems Journal Vol. 32, No. 1, P. 476

7. Trends in Systems Development & ERP
Make or Buy Decision
ERP vendor as one-stop provider
Applications to integrate with ERP systems
External consulting
Not only is enterprise resource planning, ERP, software used to automate and integrate business processes, but it is also influencing systems development. Not only are systems plans including ERP software, but after ERP software is installed, IS planners explore different kinds of systems to interact with the ERP systems. The use of ERP systems also may decrease the amount of internal software development that is done.
Many companies want to use their ERP vendor, such as Oracle or SAP, to handle their data warehousing and other application needs, rather than doing the work in-house or seeking a different vendor. Many software vendors are also developing packages that work in conjunction with the various modules of ERP systems, eliminating the need for a company to develop them in-house. Finally, after successfully implementing ERP in-house, an increasing number of companies are consulting for others implementing ERP.

8. Project Scheduling
Figure 12.4 shows the steps involved in strategic planning.

9. Systems Development Life Cycles
Since it is an ongoing process, the systems development process is also called the systems development life cycle, or SDLC. While a system is built, there are various deadlines and deliverables. But even after it is installed and accepted, the life of the system continues as it is maintained. Eventually, most information systems will be retired, and the cycle starts over to replace them.

10. Cost of Making Changes
The later in the SDLC that an error is found, the more it costs to correct. Generally, the more carefully the first stages of the SDLC, including analysis, are done, the fewer errors there will be later. There are four common systems development life cycles: traditional, prototyping, rapid application development (RAD), and end-user development. In some organizations, these are formalized and well documented; in others, less formalized approaches are used.

11. Traditional SDLC Define the project Study existing work processes
Define system requirements
Technical specifications, Hardware,
software, database, telecomm….
Creating, developing the system
Testing the system
Putting system into operations
Ensure system will continue to meet
the needs of the business
Although the steps in a traditional SDLC may vary, most include 5 common phases: investigation, analysis, design, implementation, and maintenance and review.
In the investigation stage, the problem is identified and studied to determine whether an information system is part of the solution. The result of the investigation phase is a defined information system project to which organizational resources have been committed.
Systems analysis describes what the information system must do to solve the problem. Existing systems and work processes are studied, and requirements for the new system are defined.
The object of the design stage is to determine how the information system will work to do what it is required to do. The main result of the design stage are technical specifications that detail the system’s inputs, outputs, interfaces, hardware, software, database, telecommunications, personnel and procedures and how these components are related.
Systems implementation includes creating or acquiring all the components specified in the design, assembling them, and putting the new system into operation. Users are trained during the implementation stage. The implementation stage results in an operational system.
After the information system is operational, the systems maintenance and review stage starts – and continues until the system is retired. The purpose of maintenance and review is to ensure that the system continues to meet business needs and work correctly.

12. Typical Room Layout for JAD
Retrieved 3/5/03,

13. JAD and Determining Requirements
Joint Application Design (JAD)
Brings together key users, managers and systems analysts
Purpose: collect system requirements simultaneously from key people
Conducted off-site
Prototyping
Repetitive process
Rudimentary version of system is built
Replaces or augments SDLC
Goal: to develop concrete specifications for ultimate system
Retrieved 3/5/03,

14. Factors Affecting Systems Development Success
A successful systems development process is completed on time and within budget and the resulting system meets organizational and user needs. Factors contributing to project success have been identified through experience. These include the degree of change the new system brings, the quality of project planning, use of project management tools, the use of formal quality assurance practices, and the use of sound development methods and tools. We’ll discuss several of these in the next few slides.

15. Changing Requirements
The greater the change a systems project brings, the greater its chance of failure. Figure 12.9 shows that continuous improvement projects involve minor improvements and don’t bring much risk. However, reengineering projects involve fundamental changes to work processes and roles, bringing an increased risk of failure. Top management support, clearly defined goals, and careful change management improve the chance of success for such projects. Keeping stakeholders informed of the process and its goals, as well as listening to their concerns, is an important part of change management.

16. Issue Management
The greater the change accompanying a project, or the larger the scope or complexity of the project, the more important good project planning becomes. Important components of project planning include ensuring adequate care to early stages of the SDLC – that is, requirements definition and system design - and insuring top management support and user involvement.

17. Project Management Planning Scheduling Directing Controlling
Project milestone
Project deadline
Critical path
Directing
Controlling
Project management involves planning, scheduling, directing, and controlling resources for a task to accomplish to specific objectives. A project schedule details activities, personnel and other resources allocated to each activity, and expected completion date. A project milestone is a critical date for the completion of a major part of the project. The project deadline is the date the entire project will be completed and the system will be operational. Large projects can be very complex and involve scheduling & managing thousands of different activities – some can be worked on at the same time, some must be done before others can be started. Each activity has an earliest start time, earliest completion time, and slack time. Slack time is the amount of time an activity can be delayed without delaying the whole project. The critical path contains all activities with no slack – that is, all activities that would delay the whole project if they were delayed.

18. Project Management – Gantt Chart
Formalized project management methods have been developed to help ensure critical path activities are completed on schedule.
Program Evaluation and Review Technique, or PERT, involves creating three time estimates for each activity: the shortest and longest possible times and the most likely time. A formula is then used to calculate a single time estimate. A Gantt Chart, as shown in Figure 12.10, is a graphical tool to plan and monitor projects. A Gantt Chart lists activities and deadlines. Completed tasks are marked with a darkened line.

19. Analysis Team
Functional managers should be involved with the systems investigation team. Users and managers can study the business situation and determine the merits of the proposed system.

20. Requirements Analysis
To determine user, stakeholder and organizational needs:
Critical success factors (CSFs)
Asking directly
The IS plan
Screen & report layout
Requirements analysis identifies user, stakeholder, and organizational needs for the new or modified system. This involves studying problems they are having with the current system and improvements they suggest.
When a system is clear-cut and users clearly understand their needs for the new system, asking them to tell you works well. However, when needs aren’t so clear, the systems analyst must find other ways to elicit requirements.
One approach asks mangers to list factors that are absolutely critical to the success of their mission – such as availability of raw materials, a customer list, or knowing the location of each technician reporting to him. The analyst can use these critical success factors to determine the outputs the system should provide. Inputs, processing, and performance details could then be determined.
The IS plan addresses long-term IS requirements. If this is referred to when identifying requirements for a specific system, it is more likely that the system will fit into the long-term plan.

21. Feasibility Analysis Can this project be done here & now?
Technical feasibility
Operational feasibility
Schedule feasibility
Economic feasibility
Legal feasibility
Cost – Net Present Value
Benefits – ROI
Are any of these show stoppers?
An important part of systems investigation is feasibility analysis, which essentially asks the question “Can this project be done here & now?”.
Technical feasibility asks whether the hardware, software, and other technologies needed for the project exist in the organization or can be acquired or developed. For example, if a project requires programming in a rarely used programming language and no one on your staff knows the language, you must consider the feasibility of training existing personnel or hiring contractors. If these options prove too costly or take too long, the project may not be technically feasible.
Operational feasibility addresses whether this project can be done here, in this organization, at this time. Operational feasibility looks at the motivation of individuals to have or use the system, as well as the amount of senior management support for it.
Schedule feasibility determines whether the project can be completed in a reasonable amount of time, subject to all resource constraints. Economic feasibility determines whether the benefits of the proposed system outweigh the costs. Legal feasibility identifies laws or regulations that may prevent, or limit the project or that may require it to be done or to be done in a certain way. If a systems development project is found to be feasible, then systems investigation continues.

22. Systems Analysis
After the system has been approved for further study, systems analysis begins. During systems analysis, the development team describes what the proposed system must do to solve the problem or exploit the opportunity. The entire system is evaluated, along with associated business processes, since it is often not wise to automate existing processes. The analysis team, consisting of IS and functional area staff and managers, studies the existing system, determines requirements for the new system, and evaluates alternative solutions. Systems analysis includes data analysis and requirements analysis. The main output of systems analysis is a description of systems requirements in order of their priority.

23. Data Collection Process
Methods
Structured Interview
Unstructured Interview
Direct Observation
Questionnaires
After data sources are identified, data collection starts. Data is collected in a variety of ways, using different tools and techniques. Interviewing managers, users ,and stakeholders of the system is a primary data collection technique. In structured interviews, questions are written in advance. In unstructured interviews, the interviewer asks open ended questions based on experience, sometimes asking follow-up questions for more detail.
In direct observation, members of the analysis team watch the existing system in action. This helps the team understand work procedures, data used as input, and reports produced. Direct observation can find problems that other methods cannot. For example, while watching accounts receivable clerks use paper reports to look up past due balances, rather then get the amount from the customer’s record on the computer monitor, an analyst would be prompted to ask why hardcopy was being used. Without the observation, he may not have discovered that the current screen format was hard to use and the clerks felt paper reports were quicker.
If users or other data sources are geographically dispersed, questionnaires can be used instead of interviews.

24. Sources of Data
During systems analysis, additional data is collected about the system needs and situations identified during investigation. Data is collected from both internal and external sources, as summarized in Figure Data sources include people, documents, and organizations.

25. Data Analysis Data modeling Activity modeling Application flowcharts
Grid charts
CASE tools
After the data is collected, it must be studied to determine the efficiency and effectiveness of the existing system and changes that are needed. In data analysis, the development team puts the data into a usable form to study the flow of data, the objects, and the relationships in the system. Many tools and techniques exist to do this – we’ll look at several, including data modeling, activity modeling, and applications flow charts.

26. Systems Design How the information system will function
to meet its requirements
System outputs
Inputs
Interfaces
Hardware
Software
Databases
Telecommunication
Personnel
Policies & procedures
After the requirements of a system have been described in systems analysis, systems design begins. The purpose of systems design is to describe how the information system will function to meet its requirements. The primary deliverable of systems design is a technical specification document that details system outputs, inputs, interfaces, hardware, software, databases, telecommunications, personnel, and procedures.

27. System Design Considerations
Interactive dialog
Clarity
Response Time
Consistency
Format
Avoid Jargon
Respect

28. Emergency Alternate Procedures & Disaster Recovery
Causes of System Errors
As mentioned in the last chapter, the best, easiest, and least expensive time to deal with potential errors is early in the SDLC. Good systems design generally reduces maintenance since fewer errors are found in a well-designed information system. However, many types of errors should be planned for in the design phase. Table 13.2 lists some major causes of errors in information systems, including human, natural, and technical. Attention to security, control, and procedures design will minimize human error. Disaster recovery planning, as well as backup system design, minimizes the impact of natural disasters. And careful hardware, software, database, network and facility design will control technical errors.

29. Emergency Alternate Procedures & Disaster Recovery
Hardware backup
Software & database backup
Telecommunications backup
Personnel backup
There must be emergency alternate procedures for users to follow when an information system is not usable. These may be manual work procedures to use until the system is working again or may involve assessing a remote computer. Designing fault-tolerant networks, that is, networks with redundant nodes and paths, is a safeguard against network malfunctions. IS personnel must also have backup. Cross-training people in multiple job functions is often done. The company could also have an agreement with an outside company to provide specifically qualified IS personnel.
You need ALL of these!

30. System Controls Deterrence controls Input controls Processing controls
Output controls
Database controls
Telecommunications controls
Personnel controls
Controls help maintain data security and prevent computer misuse, as well as computer crime and fraud.
Deterrence controls are designed to prevent problems by physically excluding unauthorized personnel from operating computers.
Input controls maintain the security and integrity of input data. Some of these controls involve sign-on procedures covered above, others try to reduce the number of errors in the data.
Processing controls address processing and storage. Fault tolerance and backup procedures are processing controls, as are mechanisms to ensure output is correct.
Output controls ensure output is secure and properly handled. Some installations create a log of all output produced and its destination.
Many database controls - Passwords and user views are two that have already been discussed.
Telecommunications controls involve hardware and software to insure the security and integrity of transmitted data. Use of encryption is an example of a telecommunications control.
Personnel controls are intended to ensure that only authorized personnel have access to systems and data. Logins, passwords, ID badges, or smart cards are examples of controls used to keep unauthorized personnel from gaining access.

31. Make vs Buy Request for Proposal
When hardware or software from an outside vendor are needed for a system, a request for proposal, or RFP, is made. The RFP formally describes the hardware, software or services needed as well as the time frame, and requests bids.

32. Stages of Evaluation Meets Requirements Cost Performance Delivery
Flexibility
Support
The final stage is to evaluate alternatives and select the best design. A preliminary evaluation is done to eliminate unwanted proposals. This results in a “short list” of proposals that best meet all previously established evaluation criteria. These vendors are normally asked to make a presentation to the development team. References are also contacted.
In the final evaluation, proposals of the remaining vendors are studied in detail. The vendors are asked to make a final presentation and fully demonstrate their system. A variety of factors are considered when making the final choice, although it is very important to determine whether the proposed systems meet the company’s objectives. Cost, performance, delivery dates, flexibility, and vendor support are a few of the other factors considered.

33. Systems Implementation
Implementation occurs after systems design. Implementation includes all the activities necessary to convert the system specifications into an operational information system.

34. Implementation Steps

35. Programming Life Cycle
The programming life cycle is a series of activities. The early phases – investigation, analysis, and design - have already been completed. The programmers have the functional specifications that describe what the system should do and how it should work.
The next stage involves selecting a language. The difficulty of the problem, the type of processing, and desired adaptability are among the considerations involved in the selection. Also, the efficiency with which programs will execute and ease or programming or cost of development are also considerations. Often there are trade-offs between efficiency and ease of coding.
Program coding involves writing the program instructions according to the functional specifications. As the code is written, individual parts of a program, called modules, are tested and debugged. As programs are completed, they are tested. When a set programs is completed, they will be tested together to make sure they interoperate correctly.
Next, documentation is written. Technical documentation is used by computer operators to run and troubleshoot programs and by programmers to maintain and upgrade the program. In technical documentation variables used are defined and comments are inserted into the code explaining what each line does.
Implementation, or conversion, involves installing the software and making the system operational.

36. Additional Implementation Activities
Testing & Installation
Installation is the process of physically placing the hardware and software onsite and making it operational.
Testing is done to ensure an information system works as intended. Testing is best conducted at several levels. While they code, programmers test modules of a program individually and in groups to ensure they work.

37. Start Up
Acceptance testing is the last step before system start-up. The start-up process makes the system fully operational. Figure shows alternative start-up approaches.
Direct conversion, sometimes called plunge or direct cutover, involves completely stopping the old system and starting the new system on a given date. This is the riskiest start-up approach, since if problems occur with the new system, there is nothing to fall back on. For example, if its discovered after several hours that transactions have been stored incorrectly, unless those transactions exist in paper form, they have been lost.
In the phase-in approach, components of the old system are slowly replaced by components of the new system, application by application. When everyone is sure the new system is running as expected, the old system is completely phased out.

38. Start Up
A pilot start-up involves installing the system for one group of users, often by direct conversion. When everyone is confident all the problems have been fixed, the system can be implemented in the rest of the organization. For example, if a company has regional offices, a new purchasing system might be used in only one region at first. It is important when selecting a pilot site to use a site with a typical workload and typical users. A system that works in a site with a light workload or with exceptionally experienced users, might not scale up well and may fail when it goes live in the rest of the company.
In a parallel start-up, both the old and new systems are run concurrently until it is clear that all the problems have been worked out of the new system. Although this is the safest method, it is generally the costliest, since work must be done twice. Parallel conversion is usually reserved for mission critical systems.

39. Systems Maintenance
Systems maintenance involves monitoring, changing, fixing and enhancing an operational information system.

40. Maintenance Costs
The more a program is modified, the more maintenance it needs, and the harder it becomes to maintain. This happens since when changes are repeatedly made to a program, it loses its overall structure, making the program run less efficiently and have more problems.
Figure shows maintenance costs as a function of software age.

41. Factors to Consider During Systems Review
Mission
Goals
Hardware/ software
Database
Telecommunications
IS personnel
Control
Training
Costs
Complexity
Reliability
Efficiency
Response time
Documentation
Systems review should include many factors, including those listed here. For example, the system should continue to meet the needs and support the goals of the organization, particular departments, and the users. The hardware, software, database, and telecommunications system should be reviewed to ensure they are up-to-date and capable of supporting the system. There should be adequate personnel to support the system, rules, procedures, and controls should be adequate, and training for users and IS personnel should be provided.
Systems review often means monitoring the system, called system performance measurement. For example, in order to determine the efficiency of the information system, or determine the amounts of CPU time or memory the system uses, hardware or software monitors need to be used to take actual system measurements. System performance products exist to monitor and measure all components of an information system, including the hardware, software, database, and telecommunications.