1 / 25

SYSTEMS ANALYSIS & DESIGN

SYSTEMS ANALYSIS & DESIGN. PHASE 4 SYSTEMS IMPLEMENTATION Application Development. Chapter 10. Application Development. Introduction. During the systems implementation phase, the development team uses the system design specification as a blueprint for constructing the new system

aleda
Download Presentation

SYSTEMS ANALYSIS & DESIGN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Chapter 10 Application Development

  3. 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

  4. 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

  5. Quality Assurance • Software engineering • Stresses quality in software design • Solid design • Effective structure • Accurate documentation • Careful testing

  6. Quality Assurance • Software engineering • Stresses quality in software design • Solid design • Effective structure • Accurate documentation • Careful testing • Software Engineering Institute (SEI) http://www.sei.cmu.edu • Mission is to improve quality of software-based systems • Capability Maturity Model is designed to improve quality, reduce development time, and cut costs

  7. 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

  8. Application Development

  9. 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

  10. 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

  11. Application Development • Programming the application • Process of turning program logic into specific instructions that can be executed by the computer system

  12. 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

  13. Application Development

  14. 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

  15. 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

  16. 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

  17. TRADEOFF • How far should you go with system testing? • Tradeoff: pressure for the new system from users and managersvs. 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?

  18. Documentation • Explains the system and helps peopleinteract with it • Types of documentation • Program documentation • System documentation • Operations documentation • User documentation

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

More Related