Implementation

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

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

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

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()

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

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

Notation ofComponent Diagrams

Dependency

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

Notation for Deployment Diagrams

Notation of Deployment Diagrams

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

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

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

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

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

Implementation Strategies

Implementation Strategies

• 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

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

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

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

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

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

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