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

Slides:



Advertisements
Similar presentations
Making the System Operational
Advertisements

Configuration management
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
CS CS 5150 Software Engineering Lecture 28 People 3.
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 25 Delivering the System Business Considerations.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 24 People 2.
CS CS 5150 Software Engineering Lecture 27 People 2.
CS CS 5150 Software Engineering Lecture 19 Acceptance and Delivery.
CS 501: Software Engineering
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 1 Introduction to Software Engineering.
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 26 People 1.
CS CS 5150 Software Engineering Lecture 25 People 1.
CS 501: Software Engineering Fall 2000 Lecture 1 Introduction to Software Engineering.
1 CS 501 Spring 2006 CS 501: Software Engineering Lecture 24 People 2.
APPLICATION DEVELOPMENT BY SYED ADNAN ALI.
CS CS 5150 Software Engineering Lecture 21 Reliability 3.
OHT 14.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software quality infrastructure components The need for procedures and.
CS CS 5150 Software Engineering Lecture 20 Acceptance and Delivery.
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 24 People 2.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 26 Delivering the System.
Introduction to Systems Analysis and Design
Software Documentation Written By: Ian Sommerville Presentation By: Stephen Lopez-Couto.
Ethics in Software Engineering
Ethical and Social...J.M.Kizza 1 Module 8: Software Issues: Risks and Liabilities Definitions Causes of Software Failures Risks Consumer Protection Improving.
Introduction to Information System Development.
CS3500 Software Engineering How does a “program” differ from a “software system”? Program System Tens to hundreds of lines of code Thousands to millions.
WEB ENGINEERING LECTURE 4 BY Kiramat Rahman. outline  In this Lecture you will learn about:  Term “Software” and its relationship with “Hardware” 
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp:// Applied Software Project Management Chapter 1: Introduction.
SIUE Injury Tracking System Project Plan. Team Members: Robbie Marsh Robbie Marsh –Project Manager/Webmaster Ken Metcalf Ken Metcalf –Lead Programmer.
From Research Prototype to Production
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Software engineering. What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software.
CS CS 5150 Software Engineering Lecture 3 Software Processes 2.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 23 Reliability III.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 1 Introduction to Software Engineering.
Slide 1 CS 310 Software Engineering Professor C. Shilepsky Spring Chapter 1 u define software engineering.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 7 Business Aspects of Software Engineering.
CS CS 5150 Software Engineering Lecture 2 Software Processes 1.
CS CS 5150 Software Engineering Lecture 24 People 2.
CS CS 5150 Software Engineering Lecture 26 People 2.
1 SWE 513: Software Engineering People II. 2 Future Experience What will you be doing one year from now? Ten years from now?
Configuration Management CSCI 5801: Software Engineering.
CS 360 Lecture 18.  Acceptance testing  The complete system, including documentation, training materials, installation scripts, etc. is tested against.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 25 People II.
1 Business Aspects of Software Engineering SWE 513.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.
Why? Software Engineers don’t communicate very well…
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill Stephen R. Schach 1.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission.
1 CP586 © Peter Lo 2003 Multimedia Communication Multimedia Development Team.
CS 501: Software Engineering Fall 199 Lecture 1 a) Administration b) Introduction to Software Engineering.
CS CS 5150 Software Engineering Lecture 26 Professionalism.
The Bachelor of Science in Information Technology (BSIT) program prepares students to be IT professionals who are able to perform installation, operation,
Can We Trust the Computer? FIRE, Chapter 4. What Can Go Wrong? What are the risks and reasons for computer failures? How much risk must or should we accept?
School of Business Administration Chap 3 Engineering of Software;

Software Configuration Management
Software Verification and Validation
Acceptance and Delivery
Software Documentation
CS 5150 Software Engineering
Software Engineering Software Engineering is the science and art of
Software Engineering Software Engineering is the science and art of
CS 501: Software Engineering
An Introduction to Software Engineering
Presentation transcript:

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

2 CS 501 Spring 2002 Administration

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 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 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 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 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 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 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 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 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 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 CS 501 Spring 2002 Lecture 11: Levels of Usability interface design functional design data and metadata computer systems and networks conceptual model

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