Systems Analysis II Making the system operational

1. Systems Analysis IIMaking the system operational INFO 355 Glenn Booker Week #9

2. Implementation and Deployment • Most of this course has focused on two middle ‘core processes’ of the SDLC • Identify problem and obtain approval • Plan and monitor the project • Discover and understand details • Design system components • Build, test, & integrate system components • Complete system tests, deploy solution Week #9

3. Implementation and Deployment • Now outline the activities in the last two core processes • Build, test, & integrate system components • Complete system tests, deploy solution • We won’t focus on the actual building of system components (see INFO 15x courses for that) Week #9

4. Testing • Testing helps to determine if a component, subsystem, or system works as intended and whether it contains any defects • Based on the functional and non-functional requirements of the system, testing helps uncover defects Week #9

5. Testing • Types of testing include: • Unit • Integration • Usability • Regression • System and stress • For each test, define test cases • Starting state • Events which take place • Response or ending state Week #9

6. Testing • Test data must be defined as well; could be • Contrived data to test handling extreme cases and errors • Data from typical normal fake inputs • Real data samples from the existing system • Consider using testing automation tools! Week #9

7. Unit testing • Tests individual modules, functions, classes, or components • Does this piece work in isolation? • May write a driver method to call the target unit for various test case input values • May have a stub to simulate code not written yet Week #9

8. Integration testing • Tests a group of related methods, classes, or components • Checks interfaces between units, parameter values, looks for run-time exceptions, and unexpected interactions • Trace problems to a unit and fix Week #9

9. Integration testing • OO issues in integration testing can include • Which method called the defective method? • Inherited methods and variables • Dynamic choice of method used based on inputs • Retained data values between method calls Week #9

10. Usability testing • Determine if a method, class, component, subsystem, or system meets user requirements • Often based on user interface assessment • Does the system work? • Is it easy to use? If not, why? • May be repeated often during development Week #9

11. Regression testing • Not mentioned in the book, but iterative development also depends heavily on regression testing • Makes sure that new functionality didn’t break stuff that worked before! • Is repeated at the end of every iteration on functions implemented in all previous iterations Week #9

12. System Testing • Tests the entire system or at least an independent subsystem • Typically near the end of the project (waterfall) or each iteration • During development, a daily or frequent system test might be a “build and smoke” test to look for obvious problems Week #9

13. Performance testing • A performance or stress test checks for non-functional requirements such as throughput, response time, capacity, etc. • Often need large data sets or many simulated system users • Look for performance bottlenecks or inadequate hardware Week #9

14. Performance testing • Fixing problems in performance testing can be challenging • Fix or re-implement software • Replace or reconfigure hardware or network equipment • Upgrade or replace inadequate components Week #9

15. User Acceptance Testing (UAT) • Done at the end of system testing • User tests system to see if it fulfills the requirements defined in the project’s RFP and contract • Successful UAT results in payment and approval for deployment of the system Week #9

16. Deployment activities • Deployment takes the system from the lab to the operational setting where it will spend most of its life • By the end of deployment, the system is fully operational (“live”) for executing day-to-day business functions, and we’ve reached the end of the SDLC Week #9

17. Converting and initializing data • One major activity is getting preexisting data into the system • Sometimes called DCL (data conversion and loading), it can be a major effort all by itself • DCL might include data from a legacy system, manual (paper) records that have to be digitized, and data from other related systems Week #9

18. Converting and initializing data • Might have to • Restructure data from another database • Convert a flat file database to relational • Normalize data • Modify or add tables & attributes • Or could reload the existing data, often using some intermediate data structure and import/export utilities Week #9

19. Training users • All of the system actors may need training specific to their needs and the functions they use on the system • End users and system operators may have very different skills and perform different functions • Need to define training scope, goals, materials, format, etc. Week #9

20. Training users • Training could be self-paced, instructor-led, etc. • Very large scale systems may need training for those who will train the end users • Train the trainer • Timing of training is key – not too long before system deployment or they’ll forget everything Week #9

21. Documentation • Related to training, system documentation is generally needed • User manuals • System description • Debugging and maintenance guide • Need to write documentation to the intended audience • Level of computer skills, education • Terminology known Week #9

22. Configure production environment • Before system software can be installed, the backbone of the system must be assembled and tested • Servers, routers, firewalls, etc. • Install operating systems and other support software • Often maintain a production system and a test (sandbox) system Week #9

23. Planning & managing deployment • Those are the specific activities of deployment • More generally, a plan needs to be developed of the implementation, testing, and deployment sequence • What do you implement first? • This feeds the iteration plan Week #9

24. Development order • Three common approaches for deciding the implementation order • IPO – develop Inputs first, then Processing modules, then Outputs • Top down – start with the highest level routine (Main?) then develop each piece below that • Bottom up – opposite of top down! Start with modules that call nothing Week #9

25. Development order • Also consider customer needs, project risks, staff utilization, security, or other considerations • Use a source code control system (SCCS, such as RCS) • Controls check in and check out of code and documentation Week #9

26. Deployment approaches • Before deployment you’re at point A – the old system does everything • At some point you’ll be at point B – the old system is gone, and the new system does everything • How get from point A to point B? • Choose a deployment approach Week #9

27. Deployment approaches • Direct deployment (immediate cutover) has minimal time where both systems are in use – days or a few weeks • Simple but risky • No fallback position if new system fails Week #9

28. Deployment approaches • Parallel deployment keeps both systems running in parallel longer (weeks to months) and new functions are taken over by the new system gradually • Less risk but higher cost • Good when system failure is very expensive or dangerous Week #9

29. Deployment approaches • Phased deployment implements new system functionality in specific phases, e.g. • Phase A cuts over manufacturing processes • Phase B cuts over accounting processes • Phase C cuts over human resources processes • Low risk but complex to manage Week #9

30. Change and version control • Throughout system development and deployment, need processes in place to manage change and version control • Part of configuration management (CM) • Versioning keeps track of exactly what went into each version of the system Week #9

31. Versioning • Copies of the system released to the customer (production environment) might be a production release, release version, or production version • Minor production releases might be called a maintenance release Week #9

32. Versioning • Every file (source code, data, script, documentation) needs to be tracked over time so you know exactly which version went into every release • Need this for recreating bugs Week #9

33. Versioning • As deployment nears, alpha releases can go to favored customers to get initial feedback, bug reports, etc. • Later beta releases go to wider distribution to check system stability before production release Week #9

34. Change control processes • With versioning, need a change control process to assess possible changes to the system before they are implemented • For an FAA change control process example, see here Week #9

35. Change control processes • Key change control ideas include • Standard reporting methods for both bug reports and new feature ideas • Systematic review of incoming reports • Planning and control over changes to the system (estimate, plan, assign, fix, test, approve) • Accommodation of normal and emergency changes Week #9