(CST309 MANAGEMENT OF SOFTWARE SYSTEMS Module 1: Introduction to Software Engineering (7 hours) Introduction to Software Engineering - Professional software development, Software Engineering ethics. Software process models - The waterfall model, Incremental development. Process activities - Software specification, Software design and implementation, Software validation, Software evolution. Coping with change - Prototyping, Incremental delivery, Boehm's Spiral Model. Agile software development - Agile methods, agile manifesto - values and principles. Agile development techniques, Agile Project Management. Case studies: An insulin pump control system. Mentcare - a patient information system for mental health care. Introduction to Software Engineering Software engineering is e international b infrastructures and utilities are controlled by computer-based system: include a computer and controlling software. Entertainment, including the music industry, computer games, and film and television, is software-intensive. More than 75% of the world’s population have a software-controlled mobile phone, and, by 2016, almost all of these will be Internet-enabled. ‘There are many different types of software system, ranging from simple embedded systems to complex, worldwide information systems. Developing an organizational information system is completely different from developing a controller for a scientific instrument. Many of these so-called software failures are a consequence of two factors: ntial for the functioning of government, society, and national and ‘inesses and institutions. We can’t run the modern world without software. National and most electrical products 1. Increasing stem complexity. As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; and systems have to have new capabilities that were previously thought to be impossible. 2. Failure to use software engineering methods. [tis fairly easy to write computer programs without using software engineering methods and techniques. Many companies have drifted into software development as their products and services have evolved. They do not use software engineering methods in their everyday work. Consequently, their software is often more expensive and less reliable than it should be. 1 Professional software development Lots of people write programs. People in business write spreadsheet programs to simplify their jobs; scientists and engineers write programs to process their experimental data; hobbyists write programs for their own interest and enjoyment. However, most software development is a professional activity in which software is developed for business purposes, for inclusion in other devices, or as software produets such as information systems and computer-aided design systems. The key distinetions are that professional software is intended for use by someone apart from its developer and that teams rather than individuals usually develop the software. It is maintained and changed throughout its life. Software engineering is intended to support professional software development rather than individual programming. It includes techniques that support program specification, design, and evolution, none of which are normally relevant for personal software development. ‘Many people think that software is simply another word for computer programs. However, when we are talking about software engineering, software is not just the programs themselves but also all associated documentation, libraries, support websites, and configuration data that are needed to makethese programs usefull, A profe progra jonally developed sofiware system is often more than a single ‘This is one of the important differences between professional and amateur software development. If you are writing a program for yourself, no one else will use it and you don't have to worry about writing program guides, documenting the program design, and so on, However, if you are writing software that other people will use and other engineers will change, then you usually have to provide additional information as well as the code of the program, Software engineers are concerned with developing software products, that is, software that ean be sold to a customer. There are two kinds of software product: 1. Generic products. These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Examples are databases, word processors, drawing packages, and project management tools. 2. Customized (or bespoke) software. These are systems that are commissioned by and developed for a particular customer. A software contractor designs and implements the software especially for that customer. Examples are control systems for electronic devices, systems written to support a particular business process, and air traffic control systems. tion ‘The critical distinction between these types of software is that, in generic products, the organi that develops the software controls the software specification. This means that if they run into development problems, they can rethink what is to be developed. For custom products, the specification is developed and controlled by the organization that is buying the software. The software developers must work to that specification 1.1 Software engineering Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phy ses 1. Engineering discipline Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods 2. All aspects of software production Software engineering is not just concerned with the technical processes of software development. It also includes activities software project management and the development of tools, methods, and theories to support software development. such a Engineering is about getting results of the required quality within schedule and budget. This often involves making compromises—engineers cannot be perieetionists. People writing programs for themselves, however, can spend as much time as they wish on the program development. In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. Software engineering is important for two reasons: 1. More and more, individuals and society rely on advanced software s} produce reliable and trustworthy systems economically and quickly. 2. It is usually cheaper, in the long run, to use software engineering methods and techniques f professional software systems rather than just write programs as a personal programming project. Failure to use software engineering method leads to higher costs for testing, quality assurance, and long-term maintenance tems. We need to be able to‘The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product. Four fundamental activities are common to all software processes. 1. Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation. 2. Software development, where the software is designed and programmed. 45, Software validation, where the software is checked to ensure that itis what the customer requires, J to reflect changing customer and market 4. Software evolution, where the software is modi require ex Different types of systems need different development processes. Fo an aircraft has to be completely specified before development begins specification and the program are usually developed together. ample, real-time software in In e-commerce systems, the ‘There are four related issues that affect many different types of software: 1. Heterogeneity Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices 2. Business and social change Businesses and society are changing incredibly quickly as emerging economies develop and new technologies become available, They need to be able to change their existing software and to rapidly develop new software. 9. Security and trust. As software is intertwined with all aspects of our lives, it is essential that we ean trust that software. We have to make sure that malicious users cannot successfully attack our software and that information security is maintained. 4. Scale Software has to be developed across a very wide range of scales, from very small embedded systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community. 1.2 Software engineering diversity Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability i producers. The specific methods, tools, and techniques used depend on the organization developing the software, the type of software, and the people involved in the development process Perhaps the most significant factor in determining which software engineering methods and techniques are most important is the type of application being developed. ues, as well as the needs of software customers and ‘There are many different types of application, including: 1 Stand-alone applications. These are application systems that run on a personal computer or apps that run on a mobile device. They include all necessary functionality and may not need to be connected to anetwork. Examples are office applications on a PC, CAD programs, travel apps, and so on. 2. Interactive transaction-based applications. These are applications that execute on a remote computer and that are accessed by users from their own computers, phones, or tablets. Example is ane commerce application where you interact with a remote system to buy goods and services. 3. Embedded control systems, These are software control systems that control and manage hardware devices. Examples of embedded systems include the software in a mobile (cell) phone.4. Batch processing systems. These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples are periodic billing systems, such as phone billing systems, and salary payment systems. 5. Entertainment systems, These are systems for personal use that are intended to entertain the user. Most of these systems are games of one kind or another, which may run on special-purpose console hardware. 6. Systems for modeling and simulation. These are systems that are developed by scientists and engineers to model physical processes or situations, which include many separate, interacting objects. These are often computationally intensive and require high-performance parallel systems for execution. 7. Data collection and analysis systems Data collection sare systems that collect data from th environment and send that data to other systems for processing. 8. Systems of systems, These are systems, used in enterprises and other large organiz composed of a number of other software systems. Some of these may be generic software products, ich as an ERP system. tions that are Each type of system requires specialized software engineering techniques because the software has different characteristics. 2 Software Engineering ethics Like other engineering disciplines, software engineering framework that limits the freedom of people wor accept that your job involves wider respons must also behave in an ethical and morally responsible way engineer. You should uphold normal standards of honesty and integrity. You should not use your ski and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession Some of the professional responsibilities are: 1. Confidentiality You should normally respect the confidentiality of your employers or clients regardless of whether or not a formal confidentiality agreement has been signed. 2. Competence You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence. 3. Intellectual property rights. You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected 4. Computer misuse, You should not use your technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer's machine) to extremely serious (dissemination of viruses or other malware) rried out within a social and legal Asa software engineer, you must ply the application of technical skills. You if you are to be respected as a professional 8. Software Process Models As [ explained, a software process model (sometimes called a Software Development Life Cycle or SDLC model) is a simplified representation of a software process. Each process model represents a process from a particular perspective and thus only provides partial information about that process For example, a process activity model shows the activities and their sequence but may not show the roles of the people involved in these activities “These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more specific software engineering processes.‘The general process models that I cover here are: 1. The waterfall model This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, and testing. 2. Incremental development This approach interleaves the activities of specification, development, and validation, ‘The system is developed as a series of versions (increments), with each version adding functionality to the previous version. Integration and configuration This approach relies on the availability of reusable components, or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system. There is no universal process model that is right for all kinds of software development. The right process depends on the customer and regulatory s, the environment where the software will be used, and the type of software being developed. For example, safety-critical software is usually developed using a waterfall process as lots of analysis and documentation is required before implementation begins. Software products are now always developed using an incremental process model. Business systems are increasingly being developed by configuring existing int tems and ing these to create a new system with the functionality that is required For large systems, it makes sense to combine some of the best features of all of the general processes, You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop this incrementally. Subsystems within a larger system may be developed using different approaches. Parts of the system that are well understood can be specified and developed using a waterfall-based process or may be bought in as off-the-shelf systems for configuration, Other parts of the system, which are difficult to specify in advance, should always be developed using an i proach. In both cases, software components are likely to be reused, 3.1 The waterfall model ‘The first published model of the software development process was derived from engineering process models used in large military systems engineering (Royce 1970). It presents the software development process as a number of stages, as shown in Figure 2.1. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The waterfall model is an example of a plan-driven process. In principle at least, you plan and schedule all of the process activities before starting software development. The stages of the waterfall model directly reflect the fundamental software development activities: 1. Requirements analysis and definition The system’s services, s, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2. System and software design The systems design process allocates the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 3. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. 4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.5. Operation and maintenance Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system's 's as new requirements are discovered. Requirements definition ‘System and software design implementation and unit testing In principle, the result of approved (“signed off’), Th For hardware development, where high manufacturing costs are involved, this makes sense. However, for software development, these stages overlap and feed information to each other. During design, problems with requirements are identified; during coding design problems are found, and so on. The software process, in practice, is never a simple linear model but involves feedback from one phase to another. As new information emerges in a process stage, the documents produced at previous stages should be modified to reflect the required system changes. For example, if it is discovered that a requirement is too expensive to implement, the requirements document should be changed to remove that requirement. However, this requires customer approval and delays the overall development process. During the final life-cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered, ‘h phase in the waterfall model is one or more documents that are hed, following phase should not start until the previous phase has fi In reality, software has to be flexible and accommodate change as it is being developed. The need for carly commitment and system rework when changes are made means that the waterfall model is only appropriate for some types of system: 1. Embedded systems where the software has to interface with hardware systems. Because of the inflexibility of hardware, it is not usually possible to delay decisions on the software's functionality until it is being implemented. 2. Critical systems where there is a need for extensive safety and security analysis of the software specification and design. In these systems, the specification and design documents must be complete so that this analysis is possible. Safety related problems in the specification and design are usually very expensive to correct at the implementation stage. 3. Large software systems that are part of broader engineering systems developed by several partner companies. The hardware in the systems may be developed using a similar model, and companies find it easier to use a common model for hardware and software. Furthermore, where several companies are involved, complete specifications may be needed to allow for the independent development of different subsystems.‘The waterfall model is not the right process model in situations where informal team communication is possible and software requirements change quickly. Iterative development and agile methods are better for these systems. 3.2 Incremental development Incremental development is based on the idea of developing an initial implementation, getting feedback from users and others, and evolving the software through several versions until the required system has been developed (Figure 2.2). Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities (in) — Le] T Sj + nme) 7 deception Development versions. = | Incremental development in some form is now the most common approach for the development of application systems and software products. This approach can be cither plan-driven, agile or, more usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified in advance; if an agile approach is adopted, the early increments are identified, but the development of later increments depends on progress and customer priorities. Incremental software development, which is a fundamental part of agile development methods, is better than a waterfall approach for systems whose requirements are likely to change during the development process. This is the case for most business systems and software products. Incremental development reflects the way that we solve problems. We rarely work out a complete problem solution in advance but move toward a solution in a series of steps, backtracking when we realize that we have made a mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed. Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer or user can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments. Incremental development has three major advantages over the waterfall model: 1, The cost of implementing requirements changes is reduced. The amount of analysis and documentation that has to be redone is significantly less than is required with the waterfall model 2. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. 3. Early delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall proceFrom a management perspective, the incremental approach has two problems: 1. The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost effective to produce documents that reflect every version of the system, 2. System structure tends to degrade as new increments are added. Regular change leads to messy code as new functionality is added in whatever way is possible. It becomes increasingly difficult and costly to add new features to a system ‘The problems of incremental development become particularly me systems, where different teams develop different parts of the system. Large systems need a stable framework or architecture, and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture. ‘This has to be planned in advance rather than developed incrementally. cute for large, complex, long-life 4 Process activities Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software Generally, processes are now tool-supported. 1 of software tools to help them, such as requirements management program editors, automated testing tools, and debuggers. ‘The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved tem, his means that software developers may use a range stems, design model editor 4.1 Software specification Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the system's operation and development. Requirements engineering is a particularly critical stage of the software process, as mistakes made at this stage inevitably lead to later problems in the system design and implen entation. Before the require marketing study to not it is technically and financially realistic to develop the software required The requirements engineering process (Figure 2.4) aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. Requirements are usually presented at two levels of detail. End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification. nents engineering process starts, a company may carry out a feasibility or sess whether or not there is a need or a market for the software and whether or ‘There are three main activities in the requirements engineering process 1. Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. 2. Requirements specification Requirements specification is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the systems system requirements are a more detailed description of the functionality to be provided.3. Requirements validation This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems. Requirements system descriptions Requirements analysis continues during definition and specification, and new requirements come to light throughout the process. Therefore, the activities of analysis, definition, and specification are interleaved. In agile methods, requirements specification is not a separate activity but is seen as part of system development. 4.2 Software design and implementation ‘The implementation stage of software development is the process of developing an executable system for delivery to the customer. Sometimes this involves separate activities of software design and programming. However, if an agile approach to development is used, design and implementation are interleaved, with no formal design documents produced during the process. A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. Designers do not arrive at a finished design immediately but develop the design in stages. They add detail as they develop their design, with constant backtracking to modify earlier designs Figure 2.5 shows four activities that may be part of the design process for information 1. Architectural design, where you identify the overall structure of the system, the principal components. (sometimes called subsystems or modules), their relationships, and how they are distributed 2. Database design, where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created. 3. Interface design, where you define the interfaces between system components. This interface specification must be unambiguous. With a precise interface, a component may be used by other components without them having to know how it is implemented. Once interface specifications are agreed, the components can be separately designed and developed. 4. Component selection and design, where you search for reusable components and, if no suitable components are available, design new software components.