1. Design Completion A Major Milestone System is Presented to Users and Management for Approval

2. Data Storage First, select the storage format Then optimize: – data storage efficiency – access speed

3. A good data model Simple, straightforward Minimize wasted space Nonredundant (data integrity) Flexible, adaptable to future needs

4. Physical ERDs Entities become tables Attributes become fields Add primary keys Add foreign keys Add system related components

5. Optimizing Access Speed Tradeoff between storage efficiency and speed – denormalization – archiving – indexing

6. Programming and Testing a New System The Most Potentially Difficult Phase - ‘Reality Time’ – Key Tradeoff: Development versus Maintenance Effort – Lead Programmer Has to Synthesize Many Members’ Work – End Users Assume Ownership of the Project

7. Planning the Programming Effort Careful Selection of Milestones and Modularity of Programming Tasks are Important

8. Planning the Programming Effort Programs Evolve in Stages: – program specifications – prototype – functional units – alpha test system – beta test system – production system

9. System Programming and Testing Can You Ever Expect a System to be Error Free? Objectives at This Phase – Identify Flaws Operational Technical Economic ‘If we didn’t release the program before it was completely tested, the machines would be obsolete - and so would the program - before they were delivered...’ Herbert Schorr, IBM

10. System Programming and Testing – Rigorously Test the System – Prepare the Site for Conversion – Prepare to Release the System to the Users

11. Implementation Planning Testing: F Stub Tests F test individual routines with dummy linkages F Unit Tests  individual modules

12. Implementation Planning Testing: Program Tests – program tests with test data – loading in real data

13. Implementation Planning Testing: F Integration Tests F related modules working together F System Tests  interfaces between program modules and other programs  data access and updating

14. Implementation Planning Testing: F Acceptance Tests  user’s most critical role  system functions as expected  documentation sufficient  personnel adequately trained  operating procedures clear  appropriate liaisons with technical support staff

15. System Testing The focus here is on ERROR AVOIDANCE The testing focus then migrates to ERROR DETECTION then to ERROR ELIMINATION

16. System Tests Peak Load Test: extreme conditions User - Hardware Interface: common usage problems Recovery Test: simulate emergencies Average Turnaround Time: verify processing levels

17. System Tests Documentation: user’s manuals Storage: system’s ability to handle interim files Communications: speed, security, accuracy Use: gauge impact of user’s actions

18. Conversion and Implementation Parallel – Evolutionary – ‘Safest’ – Not Always Feasible Phased by Subsystems – Piecewise implementation of logically divisible components Phased by Location (Single Location) – partial implementation in modules, such as divisions or outlets

19. Conversion and Implementation Phased by Data Characteristic – Phased in functionality for a select subset of accounts Crash (Direct) – worst for systems objectives, but often necessary – requires the most planning Day One Changeover – minimal data conversion – restart company data base from ‘day one’

20. Training A Function of the Conversion Process – Pilot cycle users through the new system – Phased Implement around training schedule

21. Training Crash – hopefuly, train on a prototype – alternately, train the trainers (cascading) Parallel – several options, depends on temporary support work beside the ne system and switch over work with trainers running old system

22. Issues to Consider for Conversion Approach Risk Timing of Benefits Development Time Personnel Resource Requirements Computer Resource Requirements Current System Maintenance

23. Issues to Consider for Conversion Approach Project Management Complexity Ease of Verification Training Impact Fallback Feasibility