CMIS 470 Structured Systems Design

1. CMIS 470Structured Systems Design SDLC, DFD, ERD, Installation, Maintenance Review, Week 3

2. Plan for Tonight • Quick review of SDLC • Quick review of DFDs and ERDs • Drill down on Implementation and Maintenance phases

3. Quick Review of SDLC • ??? • ??? • ??? • ??? • ??? • ??? • ???

4. DFDs • What do you remember? • 4 parts of DFD • 1. • 2. • 3. • 4. • What is DFD showing?

5. ERDs • What do you remember? • What part of the ERD must match with what part of the DFD? • What is ERD showing?

6. Delineating VI and VII • Implementation • Activities that occur before the system is turned over to its users • Maintenance/Support • Activities that occur after the system becomes operational

7. Managing Implementation • Analogy to building a house • Architecture (analysis/design) • Construction (implementation) • Large number of people • Myriad interdependent activities • Program development • Quality assurance • Physical installation • Documentation • Training

8. Managing Implementation • MAJOR ISSUES: • Order of program development • Source code control & versioning • Quality assurance and testing • Installation • Documentation and training

9. Order of Program Development • IPO (1-Input, 2-Process, 3-Output) • Advantages: • Simplifies testing • Input programs can be used to enter test data • User interfaces are developed early • Allows for early user evaluation of interfaces • Head start on user documentation and training materials • Disadvantages: • Late implementation of outputs • Outputs are helpful in testing process modules

10. Order of Program Development • TOP-DOWN • Create “stub” versions of subordinate modules • Primary advantage: • Always a working version of a program • Primary disadvantage: • Use of programming personnel at beginning can be inefficient

12. Order of Program Development • BOTTOM-UP • Create “driver” versions of calling programs • Advantages: • Efficient use of programmers from the get-go • Lower-level modules often most complex, so this allows more time for development and testing of them • Disadvantages: • Writing a large number of “driver” programs • Adds complexity to developing and testing process

13. Order of Program Development • Is just one part of the overall development and test plan • Development and testing go hand-in-hand • Plan should be created before beginning program development, covering: • Development order • Testing order • Generation of test data • Test cases • Acceptance criteria • Personnel and other resource needs

14. Source Code Control and Versioning • SCCS • Automated tool for tracking source code files and controlling changes to those files • Allows only 1 programmer to check out a file to update • Prevents multiple programmers from updating same file at same time

15. Example of SCCS

16. Versioning • For development, testing, and maintenance of large complex systems • Used in development: • Alpha version(s) • Test version that is incomplete but ready for some level of rigorous testing • Lifetime is usually short (days or weeks)

17. Versioning • Used in testing: • Beta version(s) • Test version that is stable enough to be tested by end users (to do real work) • Produced after one or more alpha versions have been “perfected” • Typically evaluated over period of weeks or months

18. Versioning • Used in production/maintenance: • Production version (or release) • Formally distributed to users • Considered the final product • Multiple production versions are used to add features and fix bugs discovered after releasing original production version

19. Source Code Control and Versioning • Versioning control is a part of most sophisticated SCCS’s • New programs and system versions move along this general landscape: Development and Unit Testing Integration and Systems Testing Production

20. QA and Testing • Quality Assurance (QA) • Process of ensuring that an IS meets minimal quality standards • QA during Analysis phase: • Identifying gaps or inconsistencies in system requirements • QA during Design phase: • Satisfying stated requirements and making appropriate design decisions • QA during Implementation phase: • Applying QA tools to program design and coding, and then Testing

21. QA and Testing • QA tools used throughout SDLC: • Technical review • Formal or informal review of analysis, design, or development details by a group of analysts, developers, and/or users • Walkthough is one type of technical review • Two or more people review the accuracy and completeness of a model or program • Developer of model or program leads the walkthrough, describing assumptions, key decisions, and operation

22. QA and Testing • QA tools used throughout SDLC: • Inspection • More formal version of a walkthrough • Participants review and analyze materials before they meet as a group • Participants play specific roles: • Presenter – usually the developer, summarizes the material being inspected • Critics – describe errors and concerns found • Recorder – records all errors/concerns and the agreed-upon solution strategies

23. QA and Testing • Walkthroughs and inspections have been found to: • Reduce number of errors that reach testing by a factor of 5 to 10 • Reduce testing costs by approx. 50% • Goal is to catch as many errors as possible using these QA tools – prior to Testing

24. QA and Testing • TESTING • Process of examining a product to determine what defects it contains • TESTING in Implementation phase: • Unit • Testing individual programs or modules • Integration • Testing groups of programs/modules • Systems • Testing an entire system (including interfaces between application components)

25. QA and Testing • Test planning is not easy! • Should utilize QA tools (to ensure quality of test plan!) • Walkthrough test plans • Inspect test cases • Test plans and cases should be retained after Implementation • WHY?

26. QA and Testing • UNIT Testing • Testing of individual modules before they are integrated with other modules • Examines internal design of program • The goal: Every instruction should be executed at least once • Path testing: Design test cases that focus on small segments of code; aim to exercise a high percentage of the internal paths • Called “white box” testing

27. QA and Testing • INTEGRATION Testing • Testing of a group of modules • “Black box” testing – done without knowledge of programs’ internal design • Can elucidate problems such as: • Interface incompatibility • Incorrect data type or length being passed • Incorrect parameter values passed • Unexpected state interactions • States of 2 or more modules combine to create an unexpected situation

28. QA and Testing • SYSTEM Testing • Test the entire application system • First performed by developers or test personnel • After passing system tests by developers and test personnel: • ACCEPTANCE testing • Performed by users • To determine whether system fulfills user requirements • Uses a beta version • Usually treated as a very formal activity

29. QA and Testing • A common recommendation: “Separate Testing From Development” • Why? • Humans tend not to find own mistakes • But recommend keeping unit and integration testing with programmer • Why? • After unit and integration testing, transfer test responsibility to dedicated test group

30. Installation • Four approaches: • Direct (big-bang) installation • Parallel installation • Single location • Phased installation • Each approach has strengths and weaknesses related to: • Cost • Complexity • Risk

31. Documentation and Training • Documentation • System Documentation • Descriptions of system functions, architecture, and development details • Used by maintenance personnel and developers of future systems • User Documentation • For end users: Descriptions of how to interact with and utilize the system • For system operators: Descriptions of how to maintain the system and keep it operable

32. Documentation and Training • System Documentation includes: • DFD, ERD, Process Models • System Flow Chart, Structure Chart • Function Hierarchy Diagrams, CRUD Matrices • Database Schema code (SQL statements) • Program source code • Test data and cases

33. Documentation and Training • User Documentation • Is task-based • Describes functionalities • Contains how-to’s • Keystrokes, mouse, and commands to perform specific functions • Contains FAQ’s • Explains error messages • Contains an index and “getting started” section

34. Documentation and Training • User Training • Need to consider the same 2 groups: • End users • Use the system to achieve the business purpose • Creating, modifying, deleting records • Generating reports • Querying the data • System operators • Perform administrative functions and routine maintenance to keep the system operating • Starting and stopping the system • Running backup and recovery

35. Maintenance Phase • Maintenance: • Changes made to a system to fix or enhance its functionality • Why is this needed? • Corrective • Perfective • Adaptive • Preventive

36. Maintenance Phase • Start with “production copy” of modules to be changed • Check out production version of source code • Unit testing • REGRESSION testing • To ensure changes have not created new problems in the system • Accomplished by running a subset of previously executed integration and system tests • Smart IS shops keep a regression “test bucket” of selected test cases to run on a system when changes are made to any module in that system

37. For Next Class Meeting… • Review pages in text as noted on syllabus • Get ready for Object-Oriented Analysis and Design!