Chapter 15 Systems Development I. Systems Development Life Cycle (SDLC)

1. Chapter 15 Systems DevelopmentI. Systems Development Life Cycle (SDLC)

2. 1. Planning (Chapter 14)2. Analysis • Initial investigation • Talk to users; is there a real problem? • Submit preliminary report • Detailed investigation • Feasibility study • Technical • Economic • Operational • Requirements definition • What does the system need to do so it will fulfill its goals? • Collection of information from users • Interviews • Questionnaires • Examination of documents • On-the-job observation

3. Figure 15.3 Estimated benefits and costs of an IS ($) Economic Feasibility: Cost/Benefit Analysis

4. 3. Design Design Phase I • Requirements Functions Components • Outputs Processing Inputs • Typical components • Input files, procedures, output files, user dialog (GUI), interfaces • Graphical tools used to model systems • Flowcharts • Data flow diagrams • Unified modeling language (UML)

5. Design Phase II • Evaluate alternatives • If a LAN is required, then what shape, what media? • Select programming language • Components: logical design versus physical design • Logical design includes specifications of input (design view) and output files (report design) • Physical design involves specifications related to the hardware components required of the system (e.g., 16 pcs with 4.8 GHz cpus and 80 GB hard drives, fiber optic cable with 8 mbps capacity)

6. Design Phase III • Construction • This is where the programming is done • Modular construction; modular testing • Evidence of modules in Windows applications • Systems Testing • Once modules are completed system is assembled • Systems testing where you purposely try to make the system fail; often rushed or omitted • Role of business people

7. Examples of Designer Specifications • OUTPUT • MEDIUM; CONTENT; TIMING • INPUT • ORIGINS; FLOW; DATA ENTRY • USER INTERFACE • SIMPLICITY; EFFICIENCY; LOGIC • FEEDBACK; ERRORS • DATABASE DESIGN • LOGICAL DATA RELATIONS • VOLUME, SPEED REQUIREMENTS • FILE ORGANIZATION & DESIGN • RECORD SPECIFICATIONS

8. Examples of Designer Specifications • PROCESSING • COMPUTATIONS • PROGRAM MODULES • REQUIRED REPORTS • TIMING OF OUTPUTS • MANUAL PROCEDURES • WHAT ACTIVITIES • WHO PERFORMS THEM • WHO PERFORMS THEM • HOW • WHERE

9. 4. Implementation • Training • Possible methods (in class on site, Web, distance learning, CD’s, in class off site), intranet • Coordination with conversion • Conversion • Parallel Conversion • Phased Conversion • Cut over (Cold Turkey) Conversion • Pilot Conversion

10. Figure 15.10 Strategies used to convert from one IS to another Conversion Strategies

11. 5. Support • Maintenance • Post-implementation debugging • System changes and additions • Support • Assist users and ensure that the system is operated in a satisfactory manner • Importance of good documentation in this phase • Paper books/manuals • Electronic documents • Commentary within programs • Longest of SDLC phases

12. Pros and Cons of SDLC • Pros • Thorough analysis and design • Well-defined phases to track progress • Tangible outputs at the end of each phase • Works well if requirements are well understood • Only reasonable method in large complex systems • Cons • Lengthy process • Requirements are frozen and difficult to change • Requires significant resources in time/people

13. II. Prototyping • Systems developed using an iterative process • Purpose is to develop a working model as quickly as possible, which can be revised • Requirements determined in an iterative manner • Significantly shortens systems development backlog • Can increase risk of incompatibility and other unforeseen mishaps • Prototyping is often used in conjunction with SDLC

14. Figure 15.12 In prototyping, refinement of the system continues until users are satisfied. Prototyping

15. Figure 15.13 When to prototype and when not to prototype Prototyping

16. III. Agile Methods • These methods try to deliver a useful IS to the user as quickly as possible without compromising features • In SDLC users are required to sign a contract agreeing on system requirements. This freezes the requirements • Characteristics of agile methods • Produce demo system in weeks • Get feedback from users • Design for simplicity so changes are quick and easy • Test constantly • Communicate with users informally and frequently • Encourage users to explain how they will use the system

17. IV. Systems Development Led by End Users • Motivation • Agile methods got users more involved but they did not lead projects: SDLU promotes the idea that better systems result when systems projects are lead by users • Joint application development (JAD) an example of SDLU • Planning phase – determines requirements in a workshop setting led by a user; top management presence; similar to analysis from SDLC • Design phase – determines how the system will work in a workshop setting; outputs include data flow diagrams, design views of tables, screen designs, etc.; lots of prototyping is used

18. Why End User Development • Backlog of MIS project • Available powerful and easy to use software tools • Suitable for small projects that involves user’s expertise. • Suitable for projects that support one-time decision-making. • Suitable for projects that can be completed by using off-shelf software.

19. V. Systems Integration • Takes a look at the information needs of an entire organization (or a major division) • Analysts integrate existing systems so that: • Data can flow more easily among business units. • Users can access different types of data via a single interface. • Examples of systems integration • Linking existing systems to Web sites • Linking databases to Web sites • Linking systems between two or more organizations

20. VI. Ethical and Societal IssuesShould IS Professionals Be Certified? • Malfunctioning ISs • Faulty systems may wreak havoc, causing financial damage or even death • Should IS professionals be certified based on the high investment and risk involved in their work?

21. Ethical and Societal IssuesShould IS Professionals Be Certified? • Certification Pros • Protect potential employers • Protect clients of consultants • Fewer software-related failures • Certification Cons • Difficult to measure software competence • May create a “closed shop:” decreased competition, decreased incentive to improve skills