1. PHASE 4 SYSTEMS IMPLEMENTATION Application Development SYSTEMS ANALYSIS & DESIGN

2. PHASE 4 2 SYSTEMS ANALYSIS & DESIGN 3E SDLC Phases Phase 4: Systems Implementation Objectives  Learn about application development, including designing, writing, testing, and documenting programs and code modules  Perform installation and evaluation tasks, including user training, file conversion, system changeover, and evaluation of the results

3. PHASE 4 3 SYSTEMS ANALYSIS & DESIGN 3E Chapter 10 Application Development

4. PHASE 4 4 SYSTEMS ANALYSIS & DESIGN 3E Objectives  Describe the major tasks and activities that are completed during the systems implementation phase  Discuss the role of the systems analyst during application development  Explain the importance of quality assurance and the role of software engineering in software development

5. PHASE 4 5 SYSTEMS ANALYSIS & DESIGN 3E Objectives  Describe the different types of documentation the systems analyst must prepare  Explain the different phases of testing including unit testing, link testing, and system testing  Describe top-down design and modular design and the advantages of these approaches

6. PHASE 4 6 SYSTEMS ANALYSIS & DESIGN 3E Introduction  During the systems implementation phase, the development team uses the system design specification as a blueprint for constructing the new system  Analysts and programmers have different roles during application development  An analyst's main task is to deliver clear, accurate specifications to a programmer

7. PHASE 4 7 SYSTEMS ANALYSIS & DESIGN 3E Quality Assurance  Quality assurance is vitally important in all business areas, including IS functions  The main objective of quality assurance is to detect and avoid problems as early as possible  Quality assurance can detect  Inaccurate requirements  Design or coding errors  Faulty documentation  Ineffective testing

8. PHASE 4 8 SYSTEMS ANALYSIS & DESIGN 3E Quality Assurance  Software engineering  Stresses quality in software design  Solid design  Effective structure  Accurate documentation  Careful testing Click to see Figure 10-1

9. PHASE 4 9 SYSTEMS ANALYSIS & DESIGN 3E Quality Assurance  Software engineering  Stresses quality in software design  Solid design  Effective structure  Accurate documentation  Careful testing  Software Engineering Institute (SEI)  Mission is to improve quality of software- based systems  Capability Maturity Model is designed to improve quality, reduce development time, and cut costs Click to see Figure 10-2b Click to see Figure 10-2a

10. PHASE 4 10 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Planning the overall design strategy  Use top-down (modular) approach and partition the system into subsystems and modules  Develop programs and modules  Design, code, test, and document  Test the system  Link test  System test  Complete all documentation Click to see Figure 10-3

11. PHASE 4 11 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Documentation review and application design  Program designs are based on  System design specification  Prior phase documentation  DFDs  Process descriptions  Screen layouts  Report layouts  Source documents  Data dictionary entries

12. PHASE 4 12 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Documentation review and application design  Structure (hierarchy) charts  Show the organization of program modules and the functions they perform Click to see Figure 10-4

13. PHASE 4 13 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Documentation review and application design  Structure (hierarchy) charts  Show the organization of program modules and the functions they perform  Program flowcharts  Show the internal logic needed to perform program tasks and provide output Click to see Figure 10-5

14. PHASE 4 14 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Documentation review and application design  Structure (hierarchy) charts  Show the organization of program modules and the functions they perform  Program flowcharts  Show the internal logic needed to perform program tasks and provide output  Pseudocode  Documents the program’s logical steps Click to see Figure 10-6

15. PHASE 4 15 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Coding  Process of turning program logic into specific instructions that can be executed by the computer system  Many programming languages exist  Visual C++  Access Basic  Visual Basic  SQL  HTML  Java Click to see Figure 10-7

16. PHASE 4 16 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Testing the application  Testing is necessary to ensure that all programs function correctly  First step is to detect syntax errors and obtain a clean compilation  Next step is to eliminate logic errors  Techniques include desk checking, structured walkthrough, and code review  Final step is testing  Unit, link, and systems testing Click to see Figure 10-9 Click to see Figure 10-8

17. PHASE 4 17 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Testing the application  Unit testing  Involves an individual program  Objective is to identify and eliminate execution errors and any remaining logic errors  Stub testing is a technique of using stubs to represent entry or exit points that will be linked later to another program or data file

18. PHASE 4 18 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Testing the application  Link testing  Involves two or more programs that depend on each other  Also called string testing, series testing, or integration testing  Link testing ensures that the job streams are correct  Test data is necessary to simulate actual conditions and test the interface between programs

19. PHASE 4 19 SYSTEMS ANALYSIS & DESIGN 3E Application Development  Testing the application  System testing  Involves the entire information system and includes all typical processing situations  Requires users to verify all processing options and outputs  Uses live data  Involves a final test of all programs  Ensures that proper documentation is ready  Verifies that all system components work correctly  Confirms that the system can handle predicted data volumes in a timely and efficient manner

20. PHASE 4 20 SYSTEMS ANALYSIS & DESIGN 3E TRADEOFF  How far should you go with system testing?  Tradeoff: pressure for the new system from users and managers vs. the need to avoid major errors  Typical issues to consider  What is the judgment of analysts, programmers, IS management, and the project manager?  Do potential problems exist that might affect the integrity or accuracy of data?  Can minor changes be treated as future maintenance items?

21. PHASE 4 21 SYSTEMS ANALYSIS & DESIGN 3E A KEY QUESTION  During the first two weeks of system testing, a number of minor problems were detected and fixed  One department manager insists on a “no- risk” guarantee, while other users are clamoring for the new system to become operational  How do you respond? Click to see Figure 10-10

22. PHASE 4 22 SYSTEMS ANALYSIS & DESIGN 3E Documentation  Explains the system and helps people interact with it  Types of documentation  Program documentation  System documentation  Operations documentation  User documentation

23. PHASE 4 23 SYSTEMS ANALYSIS & DESIGN 3E Documentation  Program documentation  Begins in the systems analysis phase and continues during systems implementation  Includes process descriptions and report layouts  Programmers provide documentation with comments that make it easier to understand and maintain the program  An analyst must verify that program documentation is accurate and complete

24. PHASE 4 24 SYSTEMS ANALYSIS & DESIGN 3E Documentation  System documentation  System documentation describes the system’s functions and how they are implemented  Most system documentation is prepared during the systems analysis and systems design phases  Documentation consists of  Data dictionary entries  Data flow diagrams  Screen layouts  Source documents  Initial systems request

25. PHASE 4 25 SYSTEMS ANALYSIS & DESIGN 3E Documentation  Operations documentation  Typically used in a minicomputer or mainframe environment with centralized processing and batch job scheduling  Documentation tells the IS operations group how and when to run programs  Common example is a program run sheet, which contains information needed for processing and distributing output

26. PHASE 4 26 SYSTEMS ANALYSIS & DESIGN 3E Documentation  User documentation  Typically includes the following items  System overview  Source document description, with samples  Menu and data entry screens  Reports that are available, with samples  Security and audit trail information  Responsibility for input, output, processing  Procedures for handling changes/problems  Examples of exceptions and error situations  Frequently asked questions (FAQ)  Explanation of Help & updating the manual Click to see Figure 10-11

27. PHASE 4 27 SYSTEMS ANALYSIS & DESIGN 3E Documentation  User documentation  Written documentation material often is provided in a user manual  Analysts prepare the material and users review it and participate in developing the manual Click to see Figure 10-12

28. PHASE 4 28 SYSTEMS ANALYSIS & DESIGN 3E Documentation  User documentation  Written documentation material often is provided in a user manual  Analysts prepare the material and users review it and participate in developing the manual  Online documentation can empower users and reduce the need for direct IS support  Context-sensitive Help  Interactive tutorials  Hints and tips  Hypertext  On-screen demos Click to see Figure 10-13

29. PHASE 4 29 SYSTEMS ANALYSIS & DESIGN 3E Management Approval  After system testing is complete, the results are presented to management  Test results  Status of all required documentation  Input from users who participated  Detailed time schedules, cost estimates, and staffing requirements  If approved, a schedule for system installation and evaluation will be established

30. PHASE 4 30 SYSTEMS ANALYSIS & DESIGN 3E SOFTWEAR, LIMITED  The ESIP development team reviewed True Blue Systems’ design recommendation Click to see Figure 10-14

31. PHASE 4 31 SYSTEMS ANALYSIS & DESIGN 3E SOFTWEAR, LIMITED  The ESIP development team reviewed True Blue Systems’ design recommendation  The team then used a top-down approach to partition the system into a set of modules  Each module represented a program or function to be performed by one or more macros or code procedures  The team carefully reviewed all ESIP system tasks and prepared a structure chart Click to see Figure 10-15

32. PHASE 4 32 SYSTEMS ANALYSIS & DESIGN 3E SOFTWEAR, LIMITED  Mainframe interface  Extract module tasks  Prepare a design for the extract module  Write the commands, using Visual Basic  Unit test the ESIP program module with test data, using stubs to indicate inputs and outputs  Verify the results  Create a procedure for downloading the deduction file from the mainframe to the ESIP server  Test the download procedure and update the documentation

33. PHASE 4 33 SYSTEMS ANALYSIS & DESIGN 3E SOFTWEAR, LIMITED  ESIP server  Database development tasks  Finish switchboard and screen designs, with user input, including custom menus & icons  Design all necessary reports  Verify ERDs record designs  Define data tables, identify primary keys, and link tables into a relational structure  Load test data  Design and test queries  Design and test macros and code modules  Complete work on security features

34. PHASE 4 34 SYSTEMS ANALYSIS & DESIGN 3E SOFTWEAR, LIMITED  Completing application development  ESIP design and unit testing was completed in three weeks  Link testing was performed successfully  System testing revealed that several minor changes and corrections were necessary  All changes received user approval and were documented carefully  A user manual was developed, with substantial input and participation from users themselves