Objectives Describe implementation activities

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

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

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 as Service-Oriented Architecture Object-Oriented Analysis and Design with the Unified Process

IMPLEMENTATION Choosing a Component Interaction Standard,
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

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

Implementation Discipline Activities
Object-Oriented Analysis and Design with the Unified Process

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

A Test Case is a formal description of:-
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

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

Testing Discipline Activities

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

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 Method A 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

A Driver Module to test createOrdItem()

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

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

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

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

USABILITY TESTING USABILITY TEST Usability 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

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

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

Test Types And Detected Defects

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

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

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. To maintain 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

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

Configuration and Change Management Discipline Activities

VERSIONING Test Version
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

VERSIONING Alpha Version A Test 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 Version or (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

Keeping track of System Versions is complex.
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

A time line of Test and Production Versions

Description of RMO CSS Versions

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

A sample Change Request Form

A sample Change Review Form

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

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

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

DEPLOYMENT Costs The Need to main positive Customer relations
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

Deployment Discipline Activities

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

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

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

Automated Component Deployment under J2EE using Oracle JDeveloper.

TRAINING USERS The characteristics that affect Training include:-
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

System Operator 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 routine maintenance 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

Typical activities of End Users and System Operators

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

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

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

RELOADING DATABASES Complex changes to a Database Structure may require Reloading the data after the change. Two approaches of Reloading Databases. Initialize a new Database and copy the contents of the old Database into it (The Conversion Program translates data stored within the Former Database structure into the new modified Database Structure). 2. Use a Program or DBMS Utility to extract and delete data from an existing Database and store it in a Temporary data store and then use another Utility program to Reload the modified Database. (Many DBMSs provide Import/Export Utilities to extract and load data) The first approach is simpler but it requires sufficient Data storage to hold both Databases temporarily. The second approach is required if there is insufficient Data Storage to hold two complete set of Data. Object-Oriented Analysis and Design with the Unified Process

Two Approaches to Reloading Database content after a Structural Modification

CREATING NEW DATABASES
If the System being developed is entirely new or if it replaces only a Manual System then initial data must be obtained from Manual records or other automated Systems in the Organization. Data from Manual Records:- Can be entered using the same Data Entry Programs being developed for the Operational system. In that Case Data Entry Programs must be developed and tested as early as possible and also used as a User Training exercise. Manual records can be scanned into an Optic Character Reader (OCR) and then entered into the Database using Custom-developed Data Conversion Programs or a DBMS import Utility. Some Data may already be stored in other automated Systems within the Organization. Copying such Data to a new Database is similar to Reloading a modified Database from an old Database or from a Back- up Data store. In some large Systems Development Projects all three Data Conversion Methods are used together as part of Creating New Database. Object-Oriented Analysis and Design with the Unified Process

A Complex Data Conversion example

PLANNING AND MANAGING TESTING
The Interrelationships of Implementation, Testing, Deployment, and Configuration and Change Management urges the Developers to create an “Iteration Plan” to Manage the Implementation discipline. TESTING Since the UP distributes Requirements, Testing and Implementation activities throughout a Development Project, Testing activities must be distributed throughout the project Unit and integration testing occur whenever software is developed, acquired, or combined with other software Usability Testing occurs whenever requirements or design decisions need to be evaluated User Acceptance Tests are conducted as a final validation of Requirements, Design, and Implementation activities. Object-Oriented Analysis and Design with the Unified Process

IMPLEMENTATION One of the most basic decisions to be made about Software construction is the order in which Software Components will be developed, acquired, tested and Deployed. In UP these decisions are subsumed into Iteration Planning. Choosing which portions of the System to be implemented in which Iteration is difficult and thus Developers must consider many factors. Some of which arise from the software itself. Other factor such as the need to Validate Requirements and Design Decisions and the need to minimize Project Risk by resolving technical and other Risk as early as possible. A Development Order can be based directly on the Structure of the System itself and its related issues, such as Use Cases, Testing and Efficient use of Development Staff. Object-Oriented Analysis and Design with the Unified Process

Several Development Orders are possible and each project must adapt one or a combination of these approaches based on specific Project Requirements and Constraints. DEVELOPMEN ORDER APPROACHES Input, Process, Output Development Order (IPO) Top Down Development Order Bottom Up Development Order Object-Oriented Analysis and Design with the Unified Process

INPUT PROCESSING AND OUTPUT DEVELOPMENT ORDER
Based on Data Flow through a Program or System Programs or Modules that obtain External Input are developed first Programs or Modules that Process Input are developed next Programs or Modules that Produced Output are developed last. The key issue to analyze is DEPENDENCY – (that is which Classes and Methods capture or generate data that are needed by other Classes or Methods.) Dependency information is documented in Package Diagrams and may also be documented in a Class Diagram. Data Dependency among the Packages (Subsystems) implies data dependency among their embedded class. Implementation Order Decision can be guided either or both by Dependency Diagram and Class Diagram. Object-Oriented Analysis and Design with the Unified Process

INPUT PROCESSING AND OUTPUT DEVELOPMENT ORDER
ADVANTAGES It simplifies Testing (The need to write special-purpose program to genera Test data is reduced , thus it speeds up the development process Important User Interfaces are developed and thus facilitated early Testing and User evaluation If any changes to User Interfaces are needed, there is still plenty of time to make them. Also early development of User Interfaces provide head start for related activities such as Training Users and Writing Documentation. DISADVANTAGES A Disadvantage of IPO Development Order is the late Implementation of Outputs. (Since Output programs are useful for Testing Process-oriented modules and Programs. Helps Analyst to manually exam printed reports or displayed output to find error in Processing.) However, this Disadvantage can be substantially reduced by generating alternative test Outputs using Query Processing or Report-writing capabilities of a DBMS. INPUT PROCESSING AND OUTPUT DEVELOPMENT ORDER Object-Oriented Analysis and Design with the Unified Process

TOP-DOWN and BOTTOM-UP DEVELOPMENT ORDERS
Top-Down and Bottom-Up Development Orders are primarily Traditional Structured Design and Implementation approaches. Both approaches can also be applied to OO Designs and Programs, although a visual analog is not obvious with OO Diagrams. The key issue for both approaches in O-O is “Method Dependency” (Which Methods call which other Methods) Within an O-O Subsystem or a Class, Method Dependency can be examined in terms of Navigation Visibility. The arrows connects Package Diagrams in three Layer Design shows Navigation Visibility requirements . Methods in the View Layer (User Interface) call methods in the Domain Layer, which in turn call Methods in the Data Access Layer Method dependency is also documented in Sequence Diagrams. Object-Oriented Analysis and Design with the Unified Process

TOP-DOWN DEVELOPMENT ORDERS
A Development order that Implements top-level modules first. Top-Down Approach implementation will implement the View Layer Classes and Methods first, the Domain Layer Classes and Methods next and the Data Access Layer Classes and Methods last ADVANTAGE OF TOP DOWN DEVELOPMENT The primary advantage is that there is always a working version of a Program. (A partial or a complete version of a higher level program and Dummy (Stub) version of Lower level programs.) Once the Topmost Classes and Methods are completed, development proceeds downwards to the next level. As each method or Class is implemented, stubs for the Methods or Classes on the next lower level are added. DISADVANTAGE OF TOP-DOWN The primary Disadvantage of Top down development Order is that it does not use Programming personnel very efficiently at the beginning of Software Development. (Development has to proceed through two or three levels before a significant number of Classes and Methods can be developed simultaneously. However if the first few iterations of the program can be completed quickly, then the disadvantage is minimal. Object-Oriented Analysis and Design with the Unified Process

BOTTOM-UP DEVELOPMENT ORDERS
Bottom-up a development Order that implements low-level detailed modules developed first and works upward to the top module. Bottom-Up is reverses the Top-Down Implementation Order. ADVANTAGES The primary Advantage is that many Programmers can be put to work immediately on Classes that support a wide variety of Use Cases. Programmers start writing the most difficult Classes and Methods and hence early development of those classes allows more time for Development and Testing. DISADVANTAGES It will require writing a number of Driver Methods to test Bottom-level Classes and Methods which adds additional complexity to the implementation and Testing process. Integration and Testing for individual Use Cases are delayed because he entire System could not be assembled until the Topmost Classes are written. Object-Oriented Analysis and Design with the Unified Process

OTHER DEVELOPMENT ORDER CONSIDERASTIONS
IPO, TOP-Down and Bottom-up Development Orders are only starting point for creating a Software Development Plan. Other Factors that must also be considered such as: Use-Case Driven Development, User Feedback Training Documentation Testing. In most Projects Developers choose a set of related Use Cases for a single iteration and complete those requirements based on many factors, including minimizing Project risks, Efficiently using non-technical staff or Deploying some parts of the system earlier than others. User-feedback, Training and Documentation all depend heavily on the User Interfaces of the System. It also enables early gathering of feedback on the quality and usability of the Interface. Testing is also an important consideration when determining Development Order. An individual software components are constructed they must be tested in order to find and correct errors as soon as possible. It is important to identify portions of Software that are susceptible to serious errors that affect the system as a whole. These portion of Software must be built and tested early, regardless of where they fit within the basic approaches of IPO, Top-Down or Bottom-up development. Object-Oriented Analysis and Design with the Unified Process

Framework Development
When implementation a large O-O System it is not unusual to build an Object Framework (or a set of Foundation Classes).. Object Framework covers most or all of Domain and Data Access Layer Classes. Foundation Classes are typically Reused in many parts of the system and across applications. Foundation Classes are very Critical System Components. Errors in a Foundation Class can affect every program in the System. Later Changes in a Foundation Class may require significant changes throughout the System. Whenever possible, developers choose Use Cases for early iterations that rely on many Foundation Classes By front-loading the Project with the development of many Foundation Classes, developers can test those Classes early and frequently as subsequent parts of the system are developed. Early and through testing of Foundation Classes guarantees that bugs or other problems will be discovered before other code that depends on the Foundation Class has been written. Object-Oriented Analysis and Design with the Unified Process

TEAM BASED SOFTWARE DEVELOPMENT
A team of Programmers normally works on Software Development Team-based Program Development introduces its own set of Management Issues including:- Organization of Programming Teams Task assignment to specific Teams or members Members and Team communication and coordination There are many ways of organizing a Team. Some commonly used team organization models are:- Cooperating Peer team Chief Developer Team Collaborative Specialist team Object-Oriented Analysis and Design with the Unified Process

COOPERATING PEER TEAM A team with members of roughly equal skill and experience with overlapping areas of specialization. Members are considered equals, although they may be assigned tasks of varying importance or complexity Decisions are primarily made by consensus, and the team frequently meets to exchange information and build consensus. CHIEF DEVELOPER TEAM A team with a single leader who makes all important decisions. Assigned Leader performs a number of functions, including technical consulting, team coordination and task assignment. Chief Developer makes most of the important decisions COLLABORATIVE SPECIALIST TEAM A team with members who have wide variation in and minimal overlap of skills and experience. Team may be composed of members from different organizational subunits. Team may have an appointed leader with administrative responsibilities Technical decisions are made by consensus although members own are of expertise carry extra weigh. Object-Oriented Analysis and Design with the Unified Process

A comparison and summary of Development Team Types

SOME COMMON PRINCIPLES OF TEAM ORGANIZATION Team size should be kept relatively small (No more than 10 members) Large teams tend to be inefficient because of the inheriting complexity of communication and coordination in large groups. When more than 10 developers are assigned to a project it is best to break them into small teams approximately 5 members each in team Each team should be assigned a relatively independent portion of the Project and one member from each team should be designated to handle coordination and communication with other teams. Team Structure should be matched to the task and Project Characteristics. Teams with a well defined implementation task that does not push the limits of member knowledge or technical feasibility are usually best organized as Chief Programmers teams. Teams assigned to tasks that require experimentation or a high level of creativity are bettered served by a Cooperating peer team or Collaborative Specialist team Collaborative Specialist teams are best suited to projects that span a wide range of cutting-edge technology as well as projects that require integrated problem solving. Members skills must also be matched to tasks at hand. Skill matching is fairly easy with respect to technical skills but harder for non-technical skills. Object-Oriented Analysis and Design with the Unified Process

SOURCE CODE CONTROL SYSTEM (SCCS)
Source Code Control is an Automated tool for tracking Source Code Files and Controlling Changes to those files. SSCS stores files in a Repository and acts the way Librarian would:- It implements Check-in and Check-out procedures Tracks which programmer has which file Ensures that only authorized users have access to the Repository Programmers can manipulate files in three modes Check out a file in read-only mode Check out a file in read/write mode Check in a modified file SCCS allows only one Programmer to check out a file in read/write mode. The file must be checked back in before another programmer can check it out in read/write mode. SCCS prevents multiple Programmers updating the same file at the same time , thus preventing inconsistent changes to the Source Code. SCCS is absolutely necessary when programs are developed by multiple programmers. It prevents inconsistent changes and automates coordination among programmers and teams, SCCS Repository also serve as a common facility for Back up / Recovery Operations. Object-Oriented Analysis and Design with the Unified Process

Project Files Managed by a Source Code Control System

DEPLOYMENT Issues to consider when Planning Deployment
A System or Subsystem can not be Deployed before it has been Implemented and Tested. If a System or Subsystem is large and complex, it is typically Deployed in multiple stages or versions. Issues to consider when Planning Deployment Incurring Costs of Operating both Old and New Systems in parallel Detecting and correcting errors in the New system Potentially disrupting the company and its IS operations Training Personnel and familiarizing Customers with new procedures Different approaches to Deployment represent different Trade-offs among:- Cost, Complexity, Risk The most commonly used Deployment approaches are: Direct Deployment Parallel Deployment Phased Deployment Each Deployment approach has strengths and weaknesses and no one approach is best for all Systems Object-Oriented Analysis and Design with the Unified Process

DIRECT DEPLOYMENT Advantages Disadvantages
A Deployment method that Installs a New system, quickly makes it Operational, and immediately turns off any overlapping Systems. called “Immediate Cutover”. Advantages The primary Advantages is its Simplicity. Since the Old and New Systems are not operated in parallel, there are fewer Logistical issues to manage and fewer Resources required. Disadvantages The primary Disadvantage is its Risk. Because older Systems are not operated in parallel, there is no Backup in the event of the new System failures. The Magnitude of Risk depends on: The nature of the System - Cost of workarounds in the event of a System failure - Cost of System unavailability or less than - Optimal System function Direct Deployment is suitable :- when a New System is not replacing an Old System and / or Downtime can be tolerated for days or weeks. Object-Oriented Analysis and Design with the Unified Process

Direct Deployment and Cutover

PARALLEL DEPLOYMENT Advantages Disadvantage
A Deployment Method that operates both Old and New Systems for an extended time period (Typically weeks or months) The Old Systems continue to operate until the new System has been thoroughly tested and determined to be error free and ready to operate independently. The time allocated for Parallel Operation is often determined in advance and limited to minimize the Cost of dual Operation. Advantages The primary advantage is a relatively Low Risk of System failure and the negative consequences that might result from failure If both New and Old Systems operated completely then the Old System functions as a backup for the new System. Any failure in the New System can be mitigated by relaying on the Old System. Disadvantage The primary Disadvantage is Cost to operate both Old and New Systems. Extra cost associated with Operating Both old and new Systems in Parallel include:- - Hiring temporary Personnel or temporarily reassigning existing personnel Acquiring extra space for Computer equipment and Personnel - Increasing managerial and logistic complexity Object-Oriented Analysis and Design with the Unified Process

PARALLEL DEPLOYMENT The combined Operating cost of both Old and New Systems in parallel is typically 2.5 or 3 times of the Cost of operating the Old System alone. Parallel Operation is generally best when consequences of Failure are severe. Parallel Operation reduces the risk of a System failure which is especially important un “Mission-critical applications”. Full Parallel Operation may be impractical for any of the following reasons Inputs to one System may be unusable by the other System The New System may use the same equipment as the Old System, and there may not be sufficient capacity to operate both Systems. Staffing levels may be insufficient to Operate and Manage both Systems at the same time Partial Parallel Operation may be employed when Full Parallel Operation is not possible or feasible. Possible mode of Partial parallel Operation include the following: Processing only a subset of Input Data in one of the two Systems. Subset could be determined by Transaction type, Geography or sampling. Performing only a subset of Processing Functions Performing a combination of Input data and Processing function subsets. Partial Parallel Operation always entails the risk that significant errors or problems will go undetected. Object-Oriented Analysis and Design with the Unified Process

Parallel Deployment and Operation

PHASED DEPLOYMENT Advantages Disadvantages
A Deployment Method that installs a New System and makes it operational in a series of Steps and Phases. Each Phase adds components or functions to the Operational System During each Phase the System is tested to ensure that System is ready for next Phase. Phased Deployment can be combined with Parallel Deployment particularly when the New System will take over the Operation of Multiple Existing Systems. There is no single method for performing Phased Deployment. Deployment details such as Composition of specific phases and their order of deployment vary widely from one System to another. These specifics determine the number of Deployment Phases, the Order of Deployment and the parts of the new System that are operated in Parallel with Existing Systems Advantages The remarry Advantage is Reduced risk. Because failure of a singe Phase is less problematic than failure of an entire System. Disadvantages The primary Disadvantage is Increased complexity. Dividing the deployment into Phases creates more activates and milestones, thus making entire process more complex. Phased Deployment is useful when a System is large, complex, and composed of relatively independent subsystems. Object-Oriented Analysis and Design with the Unified Process

Phased Deployment with Direct Cutover and Parallel Operation

PERSONNEL ISSUES New System Deployment places significant demands on Personnel throughout an organization. Deployment involves demanding Schedules, rapid learning and adaptation and high stress. Often Development Personnel and Customer Support Personnel are reassigned to provide sufficient manpower to operate Both Old and New Systems. Reassignment of existing staff may reduce progress on other ongoing Projects and also reduce Support and Maintenance activities for other Existing Systems. Temporary and Contract Personnel such as System Operators and Personnel with experience in Hardware and/or Software Deployment and Configuration may be hired to increase manpower, especially during a Parallel Deployment. Hiring Temporary employees to operate the Old System during Parallel deployment has several Benefits:- It provides the extra manpower needed to operate both Old and New Systems It frees Permanent staff for training on New System operations Another issue to consider is Employee Productivity since the productivity decreases temporarily with a New System due to the learning curve, regardless of training !!!) Manpower utilization and the number of directly affected personnel generally peak during the Deployment activities Object-Oriented Analysis and Design with the Unified Process

Objectives Describe implementation activities

Similar presentations

Presentation on theme: "Objectives Describe implementation activities"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Objectives Describe implementation activities

Similar presentations

Presentation on theme: "Objectives Describe implementation activities"— Presentation transcript:

Similar presentations

About project

Feedback