1. 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 24 Delivering the System

2. 2 CS 501 Spring 2002 Administration

3. 3 CS 501 Spring 2002 Ethics: Safety Critical Software A software system fails and several lives are lost. An inquiry discovers that the test plan did not consider the case that caused the failure. Who is responsible: (a) The testers for not noticing the missing cases? (b) The test planners for not writing the complete test plan? (c) The managers for not having checked the test plan? (d) The customer for not having done a thorough acceptance test?

4. 4 CS 501 Spring 2002 From Lecture 1: Professional Responsibility Organizations put trust in software developers: Competence: Software that does not work effectively can destroy an organization. Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data). Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity). Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm).

5. 5 CS 501 Spring 2002 Client Responsibility Organization culture that expects quality (Lecture 21) Appointment of suitably qualified people to vital tasks (e.g., technical team that will build a critical system) Reviewing requirements and design carefully Establishing and overseeing the acceptance process Providing time and incentives that encourage quality work Working closely with the software team Accepting responsibility for the resulting product

6. 6 CS 501 Spring 2002 Computing Management Responsibility Organization culture that expects quality (Lecture 21) Appointment of suitably qualified people to vital tasks (e.g., testing safety-critical software) Establishing and overseeing the software development process Providing time and incentives that encourage quality work Working closely with the client Accepting responsibility for work of team

7. 7 CS 501 Spring 2002 Software Developers and Testers: Responsibilities Carrying out assigned tasks thoroughly and in a professional manner Being committed to the entire project -- not just tasks that have been assigned Resisting pressures to cut corners on vital tasks Alerting colleagues and management to potential problems early

8. 8 CS 501 Spring 2002 Delivery of Software: Categories of Product Shrink-Wrapped Package Installation scripts -- automatic -- varieties of hardware and operating systems -- uninstall, reinstall, etc. Support (very expensive because 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

9. 9 CS 501 Spring 2002 Delivery of Software: Categories of Product Data Processing System Acceptance -- 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

10. 10 CS 501 Spring 2002 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

11. 11 CS 501 Spring 2002 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 less than the pain of putting a bad system into operation.) Services, such as installation, training, configuration, etc. may be paid for separately.

12. 12 CS 501 Spring 2002 Training Time and money spent on training is usually well spent: one-on-one in-house training training courses distance education online tutorials Software development team needs to provide training: users (perhaps several categories) system administrators system maintainers trainers

13. 13 CS 501 Spring 2002 Lecture 11: Levels of Usability interface design functional design data and metadata computer systems and networks conceptual model

14. 14 CS 501 Spring 2002 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

15. 15 CS 501 Spring 2002 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

16. 16 CS 501 Spring 2002 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

17. 17 CS 501 Spring 2002 Categories of Documentation Software engineering Requirements, design Source code, test plans and results User Introductory (various audiences) User manual System administrator and operator System manuals Business License, contract, etc.

18. 18 CS 501 Spring 2002 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

19. 19 CS 501 Spring 2002 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