Objectives

2. Objectives • Describe implementation activities • Describe various types of Software Tests and explain how and why each is used • Explain the importance of the Configuration and Change Management discipline to the Implementation, Testing, and Deployment of a System • List various approaches to Data Conversion and System Deployment and describe the advantages and disadvantages of each • Describe Training and User support requirements for new and Operational Systems Object-Oriented Analysis and Design with the Unified Process

3. Overview • Activities from additional UP disciplines are needed to bring a system into being • Implementation • Testing • Deployment • Configuration and change management • Describe each activity in isolation and then discuss the interrelationships among the disciplines Object-Oriented Analysis and Design with the Unified Process

4. IMPLEMENTATION Implementation is complex because it consists of many interdependent activities, including Building Software components, acquiring Software components, and integrating Software components.. (A Component is a Software modules that are fully assembled, ready to use, and have well-defined interfaces for connection to Clients or other pars of the System.) • Any System or Interchangeable Components requires standards that describe how the Components interact. There are several Component Interaction Standards. • Some of the Components Interaction Standards:- • Common Object Request Broker Architecture (CORBA) • Java 2 Enterprise Edition (J2EE)*, • Simple Object Access Protocol (SOAP)* • Common Object Model (COM)* (J2EE) and SOAP employ Web Protocols such as XML to encode messages, response and transport the messages with ordinary Internet Protocols. - A Web Server provides the “Front Line” interface to Application Components. This approach is referred to asService-Oriented Architecture Object-Oriented Analysis and Design with the Unified Process

5. IMPLEMENTATION Building and Deploying Modern Application Software is essentially a process of:- • Choosing a Component Interaction Standard, • Implement the Classes of an Object-oriented Design • Package Classes into Executable units compatible with the chosen Standard, • Installing Application Software with the Supporting Hardware and System Software infrastructure.. Object-Oriented Analysis and Design with the Unified Process

6. IMPLEMENTATION • Implementation is difficult to manage because activities must be properly sequenced and progress must be continuously monitored. • Implementation is also risky because it requires significant time and resources and because it often affects Systems vital to the daily Operation of an Organization. • Implementation and Testing are two of the most interdependent UP disciplines. • Software Components must be constructed in an order that minimizes the use of development resources and maximizes the ability to test the system and correct errors. • Unfortunately those two goals often conflict. Thus, a Program Development Plan is a trade-off among available resources , available time, and the desire to detect and correct errors prior to System Deployment. Object-Oriented Analysis and Design with the Unified Process

7. Implementation DisciplineActivities Object-Oriented Analysis and Design with the Unified Process

8. TESTING • Testing is a process of examining a product to determine what defects it contains. • Developers can test Software by reviewing its Construction and Composition or by Designing and Building the Software, exercising its functions and examining results. • If the results indicate an error, developers cycle through Design, Construction, Exercise and Evaluation until no errors are found . • An important part of Developing Tests is specifying “Test Cases” and “Test Data.” Object-Oriented Analysis and Design with the Unified Process

9. TESTING A Test Case is a formal description of:- • A Starting State • One or more Events to which the Software must respond • The Expected Response or Ending State • The Starting and Ending States and the Events are represented by a set of Test. e.g The Starting of a System may represent a particular set of data, such as the existence of a particular Customer and Order for that Customer. • The Event may be represented by a set of Input data items such as Customer Account No. and Order No. used to query Order Status. • The Expected Response may be described behavior, such as the display of curtain information or a specific state of stored data such as cancelled order. Object-Oriented Analysis and Design with the Unified Process

10. TESTING • Test Cases must be prepared for each Use Case and Scenario • Preparing Test Cases and Test Data is a tedious and time consuming process since every instruction must be executed at least once both at the Component and Method level. • Ensuring that every instructions are executed during the Testing is a complex problem • Automated Testing tools on proven mathematical techniques are available to generate a complete set of Test Cases. • Developers and Users typically prepare Test Cases and Scenarios as Requirements discipline activities are completed. • Many Test Cases representing both normal and exceptional processing situations should be prepared for each Scenario.TEST TYPES • Unit Testing • Integration Testing • Usability Testing • User Acceptance Testing Object-Oriented Analysis and Design with the Unified Process

11. Testing Discipline Activities Object-Oriented Analysis and Design with the Unified Process

12. UNIT TESTING The process of Testing individual Methods, Classes, or Components before they are integrated with other Software • The Goal is to identify and fix as many errors as possible before Modules are combined into larger Software units such as Programs, Classes and Sub-systems. • Errors become much more difficult and expensive to locate and fix when many units are combined. Thus, Unit testing helps to detect errors at an early stage. • In reality few Units are designed to operate in isolation. Instead groups of Units are designed to execute as an integrated whole. • If a Method is considered a Unit, that Method may be called by messages sent from Methods in one or more Classes and may . In turn, send messages to other Methods in its own or other Classes. • The Two Types of Unit Testing Methods • Driver Unit Testing Method • Stub Unit Testing Method Object-Oriented Analysis and Design with the Unified Process

13. UNIT TESTING • DRIVER Unit Testing Method A Method or Class that simulates the behavior of a Method that sends a message to the Method being tested. • A Driver Module for createOrderitem () method implements the following functions: • Sets the value of Input Parameter • Calls the Tested unit, passing it the Input Parameters • Accepts Return Parameters from Tested unit and prints/displays results • STUB Unit Testing MethodA Method or Class that simulates the behavior of a Method that has not yet been written. (e.g. Unit Test of createOrderitem( ) would require Stub Methods getPrice( ) , getDescription( ) and updateQty( ). • Stubs are relatively simple Methods , usually have a few executable statements Object-Oriented Analysis and Design with the Unified Process

14. A Driver Module to test createOrdItem() Object-Oriented Analysis and Design with the Unified Process

15. INTEGRATION TESTING Evaluates the behavior of a group of Methods or Classes. • The purpose is to identify errors that were not or could not be detected by Unit Testing • PROBLEMS THAT CAUSE INTEGRATION ERRORS - Interface Incompatibility- Parameter values- Run time exceptions - Unexpected State interaction, • Interface Incompatibility may be caused when one Method passes a Parameter of the wrong Data type to other Method. • Parameter values may be caused when a Method is passed or returns a value that was unexpected, such as a negative number for a Price. • Run-time exception may be caused when a Method generates an error such as “Out Of Memory” or “File Already In Use” due to conflicting resource needs. • Unexpected State Interactions may be caused when the States of two or more Objects interact to cause a complex failures such as when an Order Class Method operates correctly for all possible Customer Object States except one. Object-Oriented Analysis and Design with the Unified Process

16. INTEGRATION TESTING The Person responsible for performing the Integration Test is generally also responsible for identifying the cause of the error. • Once the error has been traced down to particular Method, then the Programmer who wrote the Method is asked to rewrite it to correct the error. Object-Oriented Analysis and Design with the Unified Process

17. INTEGRATION TESTING (Continued) Why Integration Testing is very Complex? • O-O Program consists of a set of Interacting Objects that can be created and destroyed during execution, there is no clear hierarch of structure. Object interactions and Control Flow, as a result, are dynamic and complex. • Also there are additional factors that complicate OO Integration Testing The Additional Factors that complicate O-O Integration Testing:- • Methods can be called by many other Methods and calling Modules may be distributed across many Classes • Classes may inherit Methods and State variables from other Classes • The Specific Method to be called is dynamically determined at run-time based on the “Number and Type of Message Parameters” • Objects can retain internal variable values (Object state) between calls. • The combination of the above factors makes it difficult to determine an optimal Testing order. Object-Oriented Analysis and Design with the Unified Process

18. TYPES OF INTEGRATION TESTING SYSTEM TEST • System Test is a kind of Integration Test of the behavior of an entire System or Independent Sub-system • System Testing is normally first performed by System Developers or Test personnel to ensure that overall System does not malfunction and that the System fulfills the Developers understanding of the User Requirements. • Later Testing by Users confirms whether the System does indeed fulfill their requirements. System Testing is usually performed at the end of each iteration to identify significant issues such as performance problems that will need to be dealt with in the next Iteration. BUILD AND SMOKE TEST • Is a System Test that is performed daily or several times per week • The System is completely Compiled and Linked (Built) and a “Battery of Tests” is executed to see whether anything malfunctions in an obvious way (smokes) • Build and Smoke Test are valuable because they provide rapid feedback on significant problems. • Daily testing ensures that errors are found quickly and tracked to their sources. Object-Oriented Analysis and Design with the Unified Process

19. USABILITY TESTING USABILITY TESTUsability Test determines whether a Method, Class, Sub-system, or System meets User Requirements. • Since there are many types of Requirements, both Functional and Non-functional, many types of Usability Tests are performed at many different types. • The most common type of Usability Test evaluates Functional Requirements and the Quality of a User Interface. (i.e. Whether Interface makes the System easy to use. (This test is conducted frequently as User Interfaces are developed to provide rapid feedback to developers). Object-Oriented Analysis and Design with the Unified Process

20. USABILITY TESTING PERFORMANCE TEST Performance Test is an Integration and Usability Test that determines whether a System or Sub-system can meet time-based performance criteria such as “Response Time” or “Throughput. • Response Time specifies the desired or maximum allowable time limit for Software responses to queries and updates • Throughput specifies the desired or minimum number of queries and transactions that must be processed per minute or hour. • Performance Test is complex since they involve multiple Programs, sub-systems, Computer Systems and Network infrastructure. They also require large suite of Test Data to simulate System operation under normal or maximum load. • Diagnosis and correcting Performance test failure are also complex. We need to identify the Bottlenecks and underperforming components first. Corrective action may include:- - Application Software tuning or re-implementation, - Hardware / Software configuration, and update or - Replacement of underperforming Components. Object-Oriented Analysis and Design with the Unified Process

21. USER ACCEPTANCE TESTING User Acceptance is a System Test performed to determines whether the System fulfills User Requirements. • In some Project User Acceptance Testing may be the last round of Testing before a System is handed over to its Users. • In UP the User Acceptance Testing is usually broken down into a series of Tests that are conducted as part of the System are completed. • User Acceptance Testing is very formal activity in most Projects. • Details of User Acceptance Test are sometimes included in the Request For Proposal (RFP) and Procurement Contract when a new System is built or purchased from an external party. Object-Oriented Analysis and Design with the Unified Process

22. Test Types And Detected Defects Object-Oriented Analysis and Design with the Unified Process

23. WHO TESTS SOFTWARE? Many people participates in the Testing process, and their exact number and role depend on the size of the Project and other Project characteristics. Testing participant are drown from both technical and non-technical backgrounds: _ • Programmers • Users • Quality Assurance Personnel • Programmers are generally responsible for Unit Testing their own Modules they coded prior to Integrating it with modules written by other Programmers.. In some organization Programmers are assigned a “Testing Buddy” to help them test their own code. • Testing Buddy is a Programmer assigned to test code written by another Programmer. Having a different Programmer test the Code usually finds more errors. Object-Oriented Analysis and Design with the Unified Process

24. WHO TESTS SOFTWARE? (Continued) Users are primarily responsible for Usability and Acceptance Testing. • In some Projects Software is developed in a series of Versions, and the earlier versions are called “Beta Versions” • Beta Versions are distributed to group of Users for Testing over a period of days, weeks or months. • Volunteers are frequently used for Beta Testing , although they are not always desirable since they tend to be more computer literate and have a higher tolerance for malfunctions than ordinary Users. • Acceptance Testing is normally conducted by Users with assistance from I.T Development or Operations Personnel. • The rigor and importance of the Acceptance test require participation by a number of Users across a wide range of User levels i.e. Managers , Data entry clerks etc. Object-Oriented Analysis and Design with the Unified Process

25. WHO TESTS SOFTWARE? (Continued) A separated Quality Assurance (QA) Group or QA Organization may be formed for the testing of a large System Development Project. • The QA Group is responsible for all aspects of Testing except Unit Testing and Acceptance Testing. The Responsibilities and activities of a QA Group includes:- • Developing a Test Plan • Performing Integration and System Testing • Gathering and organizing User Feedback on Beta Software Version and identifying the needed changes to the System Design or Implementation. • Tomaintain objectivity and independence, the QA Group normally reports directly to the Project Manager or to a IT Manager. Object-Oriented Analysis and Design with the Unified Process

26. CONFIGURATION AND CHANGE MANAGEMENT Medium to large scale Systems are complex and constantly changing. These changes occur during Implementation and more slowly afterwards. • System complexity and rapid changes create a host of Management Problems – particularly for Testing and Post-deployment Support • The Configuration and Change Management discipline comes into play specially during Implementation, Testing and Post- Deployment Support activities. • Configuration and Change Management encompass activities that help control the complexity associated with Testing and Supporting a System through multiple Development and Operational versions. Object-Oriented Analysis and Design with the Unified Process

27. Configuration and Change Management Discipline Activities Object-Oriented Analysis and Design with the Unified Process

28. VERSIONING • Complex Systems are Developed, Installed and Maintained in a series of Versions to simplify Testing, Deployment and Support activities. • It is not unusual to Deploy multiple Versions of a System to End-users and yet more Versions in different stages of Development. • A System Version created during Development is called a “Test Version”. Test Version A Test version contains a well defined set of features and represents a concrete step towards final completion of the System. • Test Versions provide a static snapshot and a check point to evaluate the Project’s progress. • A Test Version can be an “Alpha Version” or “Beta Version”. Object-Oriented Analysis and Design with the Unified Process

29. VERSIONING • Alpha VersionATest version that is incomplete but ready for some level of rigorous Integration or Usability Testing. • Multiple Alpha versions may be built, depending on the size and complexity of the System. • The life of an Alpha version is short usually in days and weeks. • Beta Version A Test version that is stable enough to be tested by the End users for an extended period of time usually in weeks or months.End-users Test Beta versions by using them to do real work. Therefore, must be more complete and less prone to disastrous failures than the Alpha versions. • Production Versionor (Production) Release Version Is formally distributed to Users or made Operational for long-term use. • Production version is considered a Final product however, Software Systems are rarely finished in the usual sense of that term. • Maintenance release Maintenance Release is a System update that provides bug fixes and small changes to existing features. - Minor Production releases is also called Maintenance release . - Major Production releases add significant new functionality to the System and may be the result of Rewriting an Older release from the ground up. Object-Oriented Analysis and Design with the Unified Process

30. VERSIONING • Keeping track of System Versions is complex. • Each Version need to be uniquely identified for Users and Testers. • Controlling multiple version of the same System requires sophisticated “Version Control Software” • Capabilities are normally built into sophisticated Development tools or can be obtained through a separate Source Code and Version Control System • Beta Versions and Production Versions must be kept (stored) as long as they are installed on any User machines. • Stored Versions are used to evaluate future bug reports. Object-Oriented Analysis and Design with the Unified Process

31. A time line of Test and Production Versions Object-Oriented Analysis and Design with the Unified Process

32. Description of RMO CSS Versions Object-Oriented Analysis and Design with the Unified Process

33. CHANGE REQUEST AND ERROR REPORTS To manage the risk associated with change, most organizations adopt formal Control Procedures for all Operational Systems. • Typical Change Control Procedures include • Standard Change Request Forms • Review of requests by a Change Control Committee • Extensive Planning for Design and Implementation • A Change Request Form is completed by a User or a System Owner and submitted to Change Control Committee for consideration. • The Committee reviews the Change Request to assess the impact on existing Computer Hardware and Software, System performance and availability, security and Operating budget. • The recommendation of the Change Control Committee is formally recorded • Approved Changes has been assigned with a priority and added to the List of Pending Changes for Budgeting, Scheduling , Planning and Implementation. • Bugs reports can come from several sources, including Users, Operators, IT support staff etc. and routed to a single person or Organization for logging and follow up. • Bug reports are often reported separately because of the need for an immediate fix Object-Oriented Analysis and Design with the Unified Process

34. A sample Change Request Form Object-Oriented Analysis and Design with the Unified Process

35. A sample Change Review Form Object-Oriented Analysis and Design with the Unified Process

36. IMPLEMENTING A CHANGE Change implementation follows a miniature version of the UP Life Cycle although they may be reduced in Scope or sometimes completely eliminated. • Business Modeling and Requirements discipline activities are typically skimmed or skipped, Design activities are substantially reduced in Scope, and the entire Project is typically completed in one or two Iterations. • Planning a Change Includes the Following Activities • Identifying what parts of the System must be changed • Secure resources (Such as personnel) to implement change • Schedule Design and Implementation activities • Develop Test Criteria and Testing Plan for the changed System. - Design, Implementation, and Testing Staff review of the documentation is to determine the Scope of the Change. • Test Criteria and Plans for the Existing System are the starting point for evaluating the new System. Test plan is simply updated for the changes and added functions, then the modified plan and test data are achieved for use in future change Projects. Whenever possible, changes are Implemented on a “Copy of the Production System” , which is referred to as a Test Version. The Test Version is a copy of the Production System that is modified to test changes. Test System may be developed and tested on separate Hardware or on a redundant System. The Test System becomes Operational (Production) System only after complete and successful testing.. Object-Oriented Analysis and Design with the Unified Process

37. UPGRADING COMPUTING INFRASTRUCTURE Computer Hardware, System Software, and Networks must be periodically upgraded for many reasons:- • Software Maintenance releases • Software Version upgrades • Declining System performance • Like Application Software , System Software (Operating System, Network, and DBMS) must periodically be changed in accordance with the Maintenance releases to correct errors and add new functions. • System Software updates are risky. For this reason System Software Updates must be extensively tested before they are applied to Operational Systems. • In many cases, Maintenance and Version updates are ignored to reduce risk. Object-Oriented Analysis and Design with the Unified Process

38. UPGRADING COMPUTING INFRASTRUCTURE • Over the time Hardware and Network performance may also be decreased to unacceptable levels due to increased in transition volume or the Deployment of new Software. • An Infrastructure update to add capacity or address a performance related problem may be required. • However Computer and Network Performance is complex and highly technical issue. • Performance problems require careful diagnosis to determine the best approach to address the problem. • Usually, the Performance diagnosis are carried out by technical staff with an expertise in this area. • Hiring This technical consultants may be expensive but may prevent an organization from wasting larger amount of money buying new Hardware or Network capacity that isn’t really necessary. • Best practice for upgrades is:- • If an Operational System isn’t broken, don’t fix it! Object-Oriented Analysis and Design with the Unified Process

39. DEPLOYMENT Once the new System has been Developed and Tested, it must be Deployed and placed into Operations. • The Deployment discipline is the set of activities required to make a new System Operational. Deployment Activities involve many Conflicting Constraints such as. • Costs • The Need to main positive Customer relations • The Need to Support Employees • Logistical complexity • Overall risk to the Organization Object-Oriented Analysis and Design with the Unified Process

40. Deployment Discipline Activities Object-Oriented Analysis and Design with the Unified Process

41. Acquiring Hardware and System Software Modern Applications are built from Components based on Interaction Standards. Each Component Interaction Standard defines:- • Specific ways in which Components locate and communicate with one another. • A set of supporting System Software to provide needed services, such as enforcing Security Requirements, Encoding and Decoding messages across Networks and other Transport Protocols. • The exact System Software, its Hardware, and its Configuration Requirements vary substantially among the Component Interaction Standards. • Application Software must have a Supporting Infrastructure (which may already be in place), if not must be acquired. If an entire new Infrastructure must be acquired , the Developers work with IT Staff to choose and Acquire it. • Acquisition of an entirely new Infrastructure includes the following steps • Planning • Developing a Request For Proposal (RFP) • Evaluating results • Choosing one or more Vendors • Installation and Configuration • The most difficult task is to choose Appropriate Component Interaction Standard and Supporting System Software to satisfy present and future requirements. Object-Oriented Analysis and Design with the Unified Process

42. Infrastructure and Clients of a typical .NET Application (Unless all of these hardware and System Software Infrastructure already exist, they must be Acquired, Installed and Configured before Application Software can be installed and Tested.) Object-Oriented Analysis and Design with the Unified Process

43. PACKAGING AND INSTALLING COMPONENTS The specifics of Application Software Installation and Configuration vary depending on Components Interaction Standards. • .Components must be:- • Physically Installed on a Host Server • Added to a Component Registry (XML Files used to stores Registration and Access details) • Assigned one or more Network addresses to enable Client access. • Developers normally Deploy Components to a Test Server or Production Server as they are developed and tested. • Developers can Package and install Components using Utilities provided with Application Development Software. Object-Oriented Analysis and Design with the Unified Process

44. Automated Component Deployment under J2EE using Oracle JDeveloper. Object-Oriented Analysis and Design with the Unified Process

45. TRAINING USERS Training Users is an essential part of any System Development. Remember that the Users are part of the System too! Without training, Users would slowly work their own way up the learning curve, error rates would be high, and the System would operate well below peak efficiency. • Training allow Users to be productive as soon as the System becomes Operational. • The nature of Training varies with target Audience (ie. End-users, System Operators etc.) • The characteristics that affect Training include:- • Frequency and duration of System use • Need to understand the System’s business context • Existing Computer skills and proficiency • Number of Users Object-Oriented Analysis and Design with the Unified Process

46. TRAINING The two Type of Users that need training are End Users and System Operators.- End Users are people who use the System from day to day to achieve the System’s business purposes. - System Operators are people who perform administrative functions and routinemaintenance to keep the System operating. End-User Training • Hands-on training and One-on-One Tutorials or Face-to Face training for complex System training • Group Training Sessions System Operator Training • Less formal method of training generally Self-study or one-on-one training. Training materials must be developed as soon as the Interfaces are reasonably stable Object-Oriented Analysis and Design with the Unified Process

47. Typical activities of End Users and System Operators Object-Oriented Analysis and Design with the Unified Process

48. TRAINING When to start Formal User Training? Determining the best time for User Training can be difficult! • Training Users as part of the System are Developed and Tested, ensures that Users hit the ground running. • However, starting Training early can be frustrating both for Users and Trainers; because the System may not be stable enough or completed. End Users can become upset when trying to learn on a buggy, crash- prone System with features and Interfaces that are constantly changing. • In an ideal world, Training should begin when Interfaces are finalized and a Test Version of the System has been Installed and fully debugged. However, the typical end of Project crunch makes this approach a luxury that is often sacrificed. Training should begin as soon as possible after the Training materials are developed. • Training Materials are normally developed soon after the Interfaces are reasonably stable. Object-Oriented Analysis and Design with the Unified Process

49. CONVERTING AND INITIALIZING DATA An Operational System Requires a fully populated Database to support ongoing processing. • Developers must ensure that such information is present in the Database at the moment the System becomes operational. • Data needed at System startup can be obtained from: • Files or Databases of a System being replaced • Manual records • Files or Databases of other Systems in the Organization • User feedback during normal System operation Object-Oriented Analysis and Design with the Unified Process

50. CONVERTING AND INITIALIZING DATA REUSING EXISTING DATABASES Reusing of existing Database is fairly common because of the difficulty and expense of creating new Databases from scratch, especially when a single Database often supports multiple Information Systems as in Enterprise Resource Planning (ERP) Systems. • Existing Databases are commonly modified for reuse in new or upgraded Systems. • Modern DBMS usually allow Database Administrator to modify the structure of a fully populated Database. • Typical changes include adding new Class, new Attributes and modifying existing Attributes. Object-Oriented Analysis and Design with the Unified Process