Chapter 1 The Product

1
Chapter 1The Product
2
What is Software?

• ? Pressman
• Instruction (computer programs)
• Data Structures
• Documents
• ? Sommerville
• Software is computer programs and associated
• documentation

3
Software Characteristics

• Software is both a product and a vehicle for
  developing a product.
• Software is engineered not manufactured.
• Software does not wear out, but it does
  deteriorate.
• Currently, most software is still custom-built.

4
Wear vs. Deterioration
5
The Cost of Change
6
Software Failures

• Standish Group, CHAOS Report 2000
• 26 of Software Project succed
• 74 failed!!!
• Common Problem
• Poor requirement
• Unrealistic schedule
• Inadequate testing
• Featuritis
• Miscommunication (between team customer, among
  team)

7
Software Failures Examples

• Oct. 1999 ? 125 million NASA Mars Climate
  Orbiter spacecraft was believed to be lost in
  space due to a simple data conversion error. S/W
  used English units that should be metrics units.
• Early 2000, error new computer system in a large
  suburban US public school district with 100,000
  students, problem included erroneous report cards
  and failed to registration system. The Districts
  CIO was fired and use the 25-year old system for
  at least a year until bugs fixed.
• January 2001, a major European railroad was hit
  by Y2K bugs.
• Software bugs caused the bank accounts of 823
  customers of a major US bank to be credited with
  924,844,208.32 each in May 1996
• Dsb.

8
Software Applications

• system software (OS components, driver,etc )
• real-time software (ticket online, control radar)
• business software (SAP, Oracle, etc)
• engineering/scientific software (Mathlab,
  AutoCAD, etc)
• embedded software (keypad control for microwave
  oven)
• PC software (Word processing, Spreadsheet, etc)
• AI software (NN, Pattern Recognition, etc)
• Web applications (HTML, CGI, PHP, etc)

9
Software Myths (1)

• Software standards provide software engineers
  with all the guidance they need. The reality is
  the standards may be outdated and rarely referred
  to.
• People with modern computers have all the
  software development tools. The reality is that
  CASE tools are more important than hardware to
  producing high quality software, yet they are
  rarely used effectively.
• Giving software projects to outside parties to
  develop solves software project management
  problems. The reality is people who cant manage
  internal software development problems will
  struggle to manage or control the external
  development of software too.

10
Software Myths (2)

• A general statement of objectives from the
  customer is all that is needed to begin a
  software project. The reality is without constant
  communication between the customer and the
  developers it is impossible to build a software
  product that meets the customer's real needs.
• Project requirements change continually and
  change is easy to accommodate in the software
  design. The reality is that every change has
  far-reaching and unexpected consequences. Changes
  to software requirements must be managed very
  carefully to keep a software project on time and
  under budget.
• Once a program is written, the software
  engineer's work is finished. The reality is that
  maintaining a piece of software is never done,
  until the software product is retired from
  service.

11
Software Myths (3)

• There is no way to assess the quality of a piece
  of software until it is actually running on some
  machine. The reality is that one of the most
  effective quality assurance practices (formal
  technical reviews) can be applied to any software
  design product and can serve as a quality filter
  very early in the product life cycle.
• The only deliverable from a successful software
  project is the working program. The reality is
  the working program is only one of several
  deliverables that arise from a well-managed
  software project. The documentation is also
  important since it provides a basis for software
  support after delivery.

12
Software Myths (4)

• Software engineering is all about the creation of
  large and unnecessary documentation. The reality
  is that software engineering is concerned with
  creating quality. This means doing things right
  the first time and not having to create
  deliverables needed to complete or maintain a
  software product. This practice usually leads to
  faster delivery times and shorter development
  cycles.