CS 501: Software Engineering
Lecture 24
Delivering the System
1
CS 501 Spring 2002
Administration
2
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?
3
CS 501 Spring 2002
From Lecture 1:
Professional Responsibility
Organizations put trust in software developers:
4
•
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).
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
5
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
6
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
7
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
8
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
9
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
10
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.
11
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:
•
•
•
•
12
users (perhaps several categories)
system administrators
system maintainers
trainers
CS 501 Spring 2002
Lecture 11: Levels of Usability
interface design
conceptual
model
functional design
data and metadata
computer systems and networks
13
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
14
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 (timesaving, 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
15
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
16
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.
17
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
18
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
19
CS 501 Spring 2002