Overview

• Software is designed and built by software engineers.
• Software is used by virtually everyone in society.
• Software engineers have a moral obligation to build reliable software that does no harm to other people.
• Software engineers view computer software, as being made up of the programs, documents, and data required to design and build the system.
• Software users are only concerned with whether or not software products meet their expectations and make their tasks easier to complete.

Software

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

Software Application Types

• System software
• Real-time software
• Business software
• Engineering and scientific software
• Embedded software
• Personal computer software
• Web-based software
• Artificial intelligence software

Software Crisis

• Software failures receive a lot more publicity than software engineering success stories.
• The software crisis predicted thirty years ago has never materialized and software engineering successes outnumber the failures.
• The problems that afflict software development are associated more with how to develop and support software properly, than with simply building software that functions correctly.

Software Myths

• 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.
• Adding people is a good way to catch up when a project is behind schedule. The reality is that adding people only helps the project schedule when is it done in a planned, well-coordinated manner.
• 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.
• 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.
• 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.
• 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.