UNIT-1 Chapter-1: Introduction FAQs about software engineering What is software? Many people equate the term software with computer programs. However, software is not just the programs but also all associated documentation and configuration data that is needed to make programs operate correctly. A software system usually consists of a number of separate programs, configuration files, which are used to set up these programs, system documentation, which describes the structure of the system, and user documentation, which explains how to use the system and web sites for users to download recent product information. There are two fundamental types of software product: 1. Generic products: These are stand-alone systems that are produced by a development organisation and sold on the open market to any customer who is able to buy them. Examples of this type of product include software for PCs such as databases, word processors, drawing packages and project management tools. 2. Customised (or bespoke) products: These are systems which are commissioned by a particular customer. A software contractor develops the software especially for that customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process and air traffic control systems. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use. In this definition, there are two key phrases: Engineering discipline Engineers make things work. They apply theories, methods and tools where these are appropriate, but they use them selectively
Abstract functional requirements The basic functions that the system must provide are defined at an abstract level. More detailed functional requirements specification takes place at the sub-system level. System properties These are non-functional emergent system properties such as availability, performance and safety. Characteristics that the system must not exhibit It is sometimes as important to specify what the system must not do as it is to specify what the system should do. An important part of the requirements definition phase is to establish a set of overall objectives that the system should meet. These should not necessarily be expressed in terms of the system’s functionality but should define why the system is being procured for a particular environment. Figure 2.3 The system design process A fundamental difficulty in establishing system requirements is that the problems that complex systems are usually built to help tackle are usually ‘wicked problems’. A ‘wicked problem’ is a problem that is so complex and where there are so many related entities that there is no definitive problem specification. System design System design (Figure 2.4) is concerned with how the system functionality is to be provided by the components of the system. The activities involved in this process are: 1. Partition requirements:You analyse the requirements and organise them into related groups. There are usually several possible partitioning options, and you may suggest a number of alternatives at this stage of the process. 2. Identify sub-systems:You should identify sub-systems that can individually or collectively meet the requirements. Groups of requirements are usually related to so this activity and requirements partitioning may be amalgamated. However, sub-system identification may also be influenced by other organisational or environmental factors.
inconsistent. While you may intend to document the change in the requirements and design, additional emergency fixes to the software may then be needed. These take priority over documentation. Eventually, the original change is forgotten and the system documentation and code never become consistent. Figure 8.6: The emergency repair process System re-engineering Software re-engineering is concerned with re-implementing legacy systems to make them more maintainable. Re-engineering may involve re-documenting the system, organising and restructuring the system, translating the system to a more modern programming language, and modifying and updating the structure and values of the system’s data. The functionality of the software is not changed and, normally, the system architecture also remains the same. Re-engineering a software system has two key advantages over more radical approaches to system evolution: 1. Reduced risk: There is a high risk in re-developing business-critical software. Errors may be made in the system specification, or there may be development problems. Delays in introducing the new software may mean that business is lost and extra costs are incurred. 2. Reduced cost: The cost of re-engineering is significantly less than the cost of developing new software Figure 8.7: Forward engineering and re-engineering Forward engineering starts with a system specification and involves the design and implementation of a new system. Re-engineering starts with an existing system and the development process for the replacement is based on understanding and transforming the original system. Figure 8.8: The reengineering process Figure above illustrates the re-engineering process. The input to the process is a legacy program and the output is a structured, modularised version of the same program. During program the data for the system may also be reengineered. The activities in this re-engineering process are: