1. Implementation

2. Software Implementation Tools The implementation of a system will require a range of software implementation tools –modelling (or CASE) tools allow analysts and designers to produce models of the system diagrams, textual and structured descriptions, code generation – compilers, interpreters and run-time support –visual editors to produce GUIs –integrated development environment (IDE) file management, links to compiler, debugger, version control

3. Software Implementation Tools –configuration management keep track of the dependencies between components and versions of source code and resource files –class browsers provide a visual way of navigating the class hierarchy –component managers –DBMS –CORBA –testing tools –installation tools

4. Software Implementation Tools –conversion tools to extract and format data from an existing system so it can be transferred to the new system –documentation generators generate technical and user documentation

5. Coding and Documentation Standards Agreed standards for the naming of classes, attributes, operations, etc. are essential –A typical OO standard classes named with an initial capital letter, words are concatenated with capital letters for each word, e.g. SalesOrder –attributes are named with an initial lower case letter, words are concatenated with capital letters for each remaining word, e.g. customerOrderRef –operations are named in the same way as attributes, e.g. getOrderTotal()

6. Coding and Documentation Standards Consistent naming standards make it easier to trace requirements Document the code –standards should be enforced for the way that comments are added to a program e.g. include a block at the start of each class describing the purpose of the class, details of author and date operations should begin with a comment describing their purpose User documentation also requires standards

7. Component Diagrams Component diagrams show the dependencies between software components such as files, in the system –such dependencies exist at compile-time, link-time, run-time Components –rectangles with a component icon in the top right- hand corner –may provide or require interfaces Dependencies

8. Notation of Component Diagrams

9. Dependency

10. Deployment Diagrams Deployment diagrams show the configuration of run-time processing elements and the software components and processes that are located on them –nodes rectangular prisms represent processors, devices or other resources –communication associations lines between nodes can be stereotyped represent communication between nodes

11. Notation for Deployment Diagrams

12. Notation of Deployment Diagrams

14. Software Testing Who tests? –Ideally specialist test teams with access to software to build and execute test scripts –Often the analysts who have carried out the initial requirements gathering and analysis –In eXtreme Programming (XP) programmers are expected to write test harnesses for classes before they write the code –Users of the system, who will test against requirements and do user acceptance testing

15. Data Conversion Data from existing systems will have to be entered into the new system when it is introduced –data from existing manual systems needs to be collated and entered into the new system there is a cost associated with keying data into a new system –data from existing computer systems must be extracted from existing files and databases and reformatted special programs may be written to perform this work

16. Data Conversion Tasks Create and validate the new files, tables or database Check for and correct any formatting errors Prepare the existing data for conversion –verify the existing data for correctness –resolve any discrepancies between data items from different sources –collate data in special forms for input –obtain or create programs to convert and enter the data Import or input the data Verify the data after it has been imported or input

17. User Documentation and Training User manuals –Training manuals organized around the tasks the users carry out –On-line computer-based training (CBT) that can be delivered when the users need it –Reference manuals to provide complete description of the system in terms the users can understand –On-line help replicating the manuals

18. User Documentation and Training User Training –Set clear learning objectives for trainees –Training should be practical and geared to the tasks the users will carry out –Training should be delivered ‘just in time’ not weeks before the users need it –CBT can deliver ‘just in time’ training –Follow up after the introduction of the system to make sure users haven’t got into bad habits through lack of training or having forgotten what they had been told

19. Implementation Strategies

20. Direct Changeover –On a date the old system stops and the new system starts + brings immediate benefits + forces users to use the new system + simple to plan – no fallback if problems occur – contingency plans required for the unexpected – the plan must work without difficulties Suitable for small-scale, low-risk systems

21. Implementation Strategies Parallel Running –Old system runs alongside the new system for a period of time + provides fallback if there are problems + outputs of the two systems can be compared, so testing continues into the live environment – high running cost including staff for dual data entry – cost associated with comparing outputs of two systems – users may not be committed to the new system Suitable for business-critical, high-risk systems

22. Implementation Strategies Phased Changeover –The new system is introduced in stages, department by department or geographically + attention can be paid to each sub-system in turn + sub-systems with a high return on investment can be introduced first + thorough testing of each stage as it is introduced – if there are problems rumours can spread ahead of the implementation – there can be a long wait for benefits from later stages Suitable for large systems with independent sub- systems

23. Implementation Strategies Pilot Project –Complete system is tried out in one department or at one site + can be used as a learning experience + can feed back into design before system is launched organization-wide + decision on whether to go ahead across the whole organization can depend on the pilot outcome + reduces risk – there is an initial cost without benefits across the whole organization Suitable for smaller systems and packaged software

24. Review Post-implementation review Review the system – whether it is delivering the benefits expected –whether it meets the requirements Review the development project –record lessons learned –use actual time spent on project to improve estimating process Plan actions for any maintenance or enhancements

25. Evaluation Report Cost benefit analysis—Has it delivered? Compare actuals with projections Functional requirements—Have they been met? Any further work needed? Non-functional requirements—Assess whether measurable objectives have been met User satisfaction—Quantitative and qualitative assessments of satisfaction with the product Problems and issues—Problems during the project and solutions so lessons can be learned

26. Evaluation Report Positive experiences—What went well? Who deserves credit? Quantitative data for planning—How close were time estimates to actuals? How can we use this data? Candidate components for reuse—Are there components that could be reused in other projects in the future? Future developments—Were requirements left out of the project due to time pressure? When should they be developed? Actions—Summary list of actions, responsibilities and deadlines