1 / 12

Chapter 1 The Product

Chapter 1 The Product. What is Software?.  Pressman Instruction (computer programs) Data Structures Documents  Sommerville Software is computer programs and associated documentation. Software Characteristics. Software is both a product and a vehicle for developing a product.

rhian
Download Presentation

Chapter 1 The Product

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 District’s 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 can’t 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.

More Related