Software Engineering (keynotes 2011_1)

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

Linear Sequential Model (old fashioned but reasonable approach when requirements are well understood) Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product) Rapid Application and Development (RAD) Model (makes heavy use of reusable software components with an extremely short development cycle) Incremental Model (delivers software in small but usable pieces, each piece builds on pieces already delivered) Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model) Win-Win Spiral Model (eliciting software requirements defined through negotiation between customer and developer, where each party attempts to balance technical and business constraints) Concurrent Development Model (similar to spiral model often used in development of client/server applications) Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes) Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems) Fourth Generation (4GT) Techniques (software tool is used to generate the source code for a software system from a high level specification representation)

Software Application Types

System software Real-time software Business software Engineering and scientific software Embedded software

Dolon Mukherjee

Software Engineering (keynotes 2011_1)

Personal computer software Web-based software Artificial intelligence software

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, wellcoordinated manner. 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. 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 wellmanaged 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.

Dolon Mukherjee