1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

17
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System

Transcript of 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

Page 1: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

1 CS 501 Spring 2003

CS 501: Software Engineering

Lecture 26

Delivering the System

Page 2: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

2 CS 501 Spring 2003

Administration

Page 3: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

3 CS 501 Spring 2003

Maintenance

The objective of maintenance

• Add new functionality (e.g., new transaction types)

• Adapt to changing circumstances (e.g., organizational change)

• Fix problems (e.g., awkward user interface)

• Upgrades to hardware or system software (e.g., new operating system)

• Increases or changes in load

Page 4: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

4 CS 501 Spring 2003

Maintenance

The perils of maintenance

• Changes do not fit within the design of the system. The system becomes a mess of patches and changes that are almost impossible to comprehend.

• New bugs and errors are introduced.

• The documentation, training materials, etc. are not kept current.

• Expense.

Eventually almost every system reaches a stage where changes seem to create more problems than they solve.

Page 5: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

5 CS 501 Spring 2003

Maintenance

Good habits in maintenance

• Clean up as you go along

• Stay within the design framework

• Test thoroughly (regression testing)

• Keep documentation current

• Track current releases of system software

Page 6: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

6 CS 501 Spring 2003

Delivering the System: Themes

• Different categories of software product need different packaging and delivery procedures.

• Packaging, support, maintenance and major failures are expensive. Trade-offs must be made.

• Pressures to get products to market and in operation often lead to bad decisions.

(In my experience, the pain of being late is often less than the pain of putting a bad system into operation.)

• Services, such as installation, training, configuration, etc. may be paid for separately.

Page 7: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

7 CS 501 Spring 2003

Delivery of Software: Categories of Product

Shrink-Wrapped Package

• Installation scripts

-- automatic -- varieties of hardware and operating systems

-- uninstall, reinstall, etc.

• Support (very expensive when it requires staff)

-- staff training-- documentation (user, system administrator, expert user)

• Maintenance

-- client does not have source code-- no bug fixing except with new release

Page 8: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

8 CS 501 Spring 2003

Delivery of Software: Categories of Product

Data Processing System

• Acceptance

-- acceptance period may cover several months-- client should be comfortable with complete system

• Support

-- client should be self-sufficient-- documentation and training for system administrators

and operators-- well organized source code for maintenance-- maintenance and support contracts

Page 9: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

9 CS 501 Spring 2003

Delivery of Software: Categories of Product

Embedded System

• Acceptance

-- hardware and software developed together-- acceptance tests combination

• Maintenance

-- bug fixes require servicing the hardware-- errors may be expensive or dangerous

• Support

-- training for support personnel-- documentation and training for users

Page 10: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

10 CS 501 Spring 2003

Training

Time and money spent on training is usually well spent:

• one-on-one• in-house training • training courses• distance education• online tutorials

Development team needs to provide training materials:

• users (perhaps several categories)• system administrators• system maintainers• trainers

Page 11: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

11 CS 501 Spring 2003

Levels of Usability

interface design

functional design

data and metadata

computer systems and networks

conceptual model

Page 12: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

12 CS 501 Spring 2003

Training and Usability

A well-designed system needs less training

• good conceptual model

• intuitive interfaces

Different skill levels need different types of training

• skilled users work from the conceptual model

• less-skilled users prefer cook book sets of instructions

• occasional users will forget complex details, but remember general structure

Page 13: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

13 CS 501 Spring 2003

Help Systems

Resources

• A good help system is a major sub-project (time-consuming, expensive)

• A good help system saves user time and support staff (time-saving, cost-saving)

Help system design

• Users need many routes to find information (index by many terms, examples, mini-tutorials, etc.)

• Help systems need to be tested with real users

Page 14: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

14 CS 501 Spring 2003

Documentation

Online documentation

• Much cheaper than print

• Fewer restrictions on numbers of pages, colors, etc.

• Easy to update (e.g., over the Internet)

but... Cannot be used if the user's system is down

Page 15: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

15 CS 501 Spring 2003

Categories of Documentation

Software development

• Requirements, design• Source code, test plans and results

User

• Introductory (various audiences)• User manual

System administrator and operator

• System manuals

Business

• License, contract, etc.

Page 16: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

16 CS 501 Spring 2003

Installation Tools

Creating installation scripts may be a major sub-project

• Different scripts, tools and procedures for different categories of software

• Testing must be extensive with real users in their own environment

Page 17: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.

17 CS 501 Spring 2003

Delivery: Summary

A good delivery package results in:

• happy client

• happy users

• less expense in support or maintenance

but most projects rush the packaging, give it to the least experienced members of the team, do not test it properly, and generally neglect this part of the software process