280 likes | 290 Views
This chapter explores the implementation and support phases of system development, including program development, order of implementation, framework development, team-based program development, source code control, versioning, quality assurance, and testing.
E N D
Making the system operational Chapter 16
Tri-state heating oil • What project activities are described in this case? • What are unit and integration testing? • Why are ‘nasty surprises’ found in integration testing rather than unit testing? • What is the relationship between testing and training? Why not train with an untested system? • What do you think stress testing is?
Learning Objectives • Describe implementation and support activities • Choose an appropriate approach to program development…..’coding’ • Describe various types of software tests, and explain how and why each is used • List various approaches to data conversion and system installation, and describe the advantages and disadvantages of each • Describe different types of documentation and the processes by which they are developed and maintained • Describe training and user support requirements for new and operational systems
Overview • This chapter focuses on activities of implementation and support phases of systems development life cycle (SDLC) • Implementation activities occur before system is turned over to users • Implementation consumes more time and resources than other phases of the SDLC • Support activities occur after system becomes operational and may continue for years
Program Development • Program development is time consuming • One-third of development labor • One-third to one-half of project development schedule • Programming and testing considerations • Required resources • Managerial complexity • System quality
Order of Implementation • Input, process, output (IPO) development order • Based on data flow through system • Simplifies testing • User interfaces developed early to reduce change • Disadvantage is late implementation of outputs • Structured design – IPO order based on system flowchart and structure chart • OO design – IPO order in package diagrams • Key issue to be addressed is dependancy
Order of Implementation (continued) • Top-down and bottom-up order from traditional structured design and structured programming • Top-down begins with module at top of structure chart • Always a working version of program • Requires three or more iterations to complete • Bottom-up begins with modules at lowest level of structure chart • Many programmers can begin immediately • Requires driver programs to test • Remember: • Database needs to be there first
Package Diagrams for RMO Subsystems What’s the right order for subsystem development?
Framework Development • When developing large OO systems, object frameworks or foundation classes are often constructed • Foundation classes typically implemented first • Minimize impact of errors and changes • Reused in many parts of the system and across applications • Assigned to best programmers and thoroughly tested
Team-Based Program Development • Management issues • Organization of programming teams • Task assignment to specific teams or members • Member and team communication and coordination • Variety of different models used for teams • Cooperating peer, chief developer, collaborative specialist
Source Code Control • Source code control system (SCCS) • Automated tool for tracking source code files and controlling changes to those files • Repository of code and programmer actions • Check out file in read-only mode • Check out file in read/write mode • Check in a modified file
Versioning • Mechanism to manage systems changes • Complex systems developed, installed, and maintained in series of versions to simplify testing and support • Alpha version – incomplete testing version • Beta version – end-user testing version • Production release version – formally distributed to users or made operational • Maintenance release – bug fixes, small changes
Quality Assurance • Process of ensuring information system meets minimum quality standards • Determined by users, implementation staff, management • Identification of gaps or inconsistencies in system requirements • QA integrated into project throughout SDLC • Cost of fixing errors rise as project progresses • Technical and User Reviews vs. Testing
Technical Reviews • Formal or informal reviews of design or construction details by group of developers • Open design and construction process to input from other people • Other programmers can frequently see errors missed by original programmer • Similar to author writing and editor reviewing • Walkthroughs and inspections • Reduce number of errors by factor of 5 to 10 • Reduce testing costs by 50%
Testing • Process of examining a product to determine if any defects exist • Testing levels are related to specific SDLC phases • Testing activities spread throughout SDLC • Most of testing takes place following software construction and definition of defect standards
Correspondence Between SDLC Phases and Various Types of Testing (Figure 15-13)
SDLC Phases and Testing Activities Performed Within Each Phase (Figure 15-14)
Test Cases • Important part of testing is specifying test cases and test data • A test case is a formal description of • Starting state • Events to which software responds • Expected response or ending state • Analysis phase documentation is useful in preparing test cases (use-case driven) • Test data is defined to be used with a test case
Unit Testing • Tests individual modules of code or methods before integrating with other software • Driver module used for testing • Sets values of input parameters • Calls module to be tested and passes input parameters • Accepts return parameters from tested module • Stub testing – test module simulates module not yet developed
Integration Testing • Tests the behavior of a group of modules or methods • Tests both normal processing and exceptions • Errors can include • Interface incompatibility • Incorrect parameter values • Run-time exceptions • Unexpected state interactions
System Testing • Tests the behavior of the entire system • Complete system testing also performed before acceptance testing
Usability Testing • Usability testis a test to determine whether a module, method, class, subsystem, or system meets user requirements • Focus is usually on ease of use • Performance/Stress test checks time-based requirements • Response time • Throughput • Acceptance test is system test performed to determine whether system meets user requirements
Data Conversion • Data needed at system startup • Files or databases of system being replaced • Manual records • Files or databases of other systems • User feedback during normal system operation • Reuse of existing databases • Reloading database contents • Creating new databases • Large and complex programming effort