Software Engineering Principles PDF

SOFTWARE ENGINEERING PRINCIPLES IGIS01_E SOFTWARE ENGINEERING PRINCIPLES MASTHEAD Publisher: IU Internationale Hochschule GmbH IU International University of Applied Sciences Juri-Gagarin-Ring 152 D-99084 Erfurt Mailing address: Albert-Proeller-Straße 15-19 D-86675 Buchdorf [email protected] www.iu.de IGIS01_E Version No.: 001-2023-1107 N.N. © 2023 IU Internationale Hochschule GmbH This course book is protected by copyright. All rights reserved. This course book may not be reproduced and/or electronically edited, duplicated, or dis- tributed in any kind of form without written permission by the IU Internationale Hoch- schule GmbH (hereinafter referred to as IU). The authors/publishers have identified the authors and sources of all graphics to the best of their abilities. However, if any erroneous information has been provided, please notify us accordingly. 2 TABLE OF CONTENTS SOFTWARE ENGINEERING PRINCIPLES Introduction Signposts Throughout the Course Book............................................. 6 Suggested Readings............................................................... 7 Learning Objectives............................................................... 9 Unit 1 Structure and Organization of Information Systems 11 1.1 0 and 1 as the Basis of All IT Systems........................................... 12 1.2 Von Neumann Architecture................................................... 14 1.3 Distributed Systems and Communication Networks............................. 17 1.4 Enterprise Information Systems............................................... 22 Unit 2 Risks and Challenges of Enterprise Software Engineering 25 2.1 Properties of Enterprise Software Systems..................................... 26 2.2 Software Engineering........................................................ 29 2.3 Risks and Typical Problems................................................... 30 2.4 Root Cause Analysis.......................................................... 31 2.5 Challenges in Software Engineering............................................ 33 Unit 3 Software Life Cycle: From Planning to Replacement 39 3.1 The Software Life Cycle at a Glance............................................ 40 3.2 Planning.................................................................... 41 3.3 Development................................................................ 43 3.4 Operation................................................................... 44 3.5 Maintenance................................................................ 45 3.6 Shutdown................................................................... 46 Unit 4 Requirements Engineering and Specification 51 4.1 Requirements Engineering.................................................... 52 4.2 Specification................................................................ 55 3 Unit 5 Architecture and Implementation 63 5.1 Architecture................................................................. 64 5.2 Implementation............................................................. 70 Unit 6 Testing, Operation, and Evolution 75 6.1 Testing...................................................................... 76 6.2 Operation................................................................... 81 6.3 Evolution................................................................... 83 Unit 7 Roles in Software Engineering 85 7.1 Idea of the Role-Based Approach.............................................. 86 7.2 Typical Roles................................................................ 88 Unit 8 Organization of Software Projects 93 8.1 From Process Paradigm toward Software Process............................... 95 8.2 Process Paradigms........................................................... 96 Unit 9 Software Process Model Frameworks 103 9.1 V-Modell XT................................................................ 104 9.2 Rational Unified Process (RUP)............................................... 106 9.3 Scrum..................................................................... 107 Appendix List of References............................................................... 114 List of Tables and Figures........................................................ 117 4 INTRODUCTION WELCOME SIGNPOSTS THROUGHOUT THE COURSE BOOK This course book contains the core content for this course. Additional learning materials can be found on the learning platform, but this course book should form the basis for your learning. The content of this course book is divided into units, which are divided further into sec- tions. Each section contains only one new key concept to allow you to quickly and effi- ciently add new learning material to your existing knowledge. At the end of each section of the digital course book, you will find self-check questions. These questions are designed to help you check whether you have understood the con- cepts in each section. For all modules with a final exam, you must complete the knowledge tests on the learning platform. You will pass the knowledge test for each unit when you answer at least 80% of the questions correctly. When you have passed the knowledge tests for all the units, the course is considered fin- ished and you will be able to register for the final assessment. Please ensure that you com- plete the evaluation prior to registering for the assessment. Good luck! 6 SUGGESTED READINGS GENERAL SUGGESTIONS Pohl, K., & Rupp., C. (2015). Requirements engineering (2nd ed.). Rocky Nook. Sommerville, I. (2016). Software engineering (10th ed.). Pearson. Sommerville, I. (2019). Engineering software products: An introduction to modern soft- ware engineering. Pearson. Jacobson, I., Lawson, H., & Ng, P.-W. (2019). The essentials of modern software engineer- ing. ACM Books. UNIT 1 Tanenbaum, A. S. (2013). Structured computer organization (6th ed.). Pearson. Chapters 2 & 3.1 UNIT 2 Gruhn, V., & von Brisinski, N. S. (2020). How to reduce risk effectively in fixed price software development. In 2020 IEEE/ACM 42nd international conference on software engineer- ing: Software engineering in practice (pp. 132—141). Association for Computing Machinery. UNIT 3 Kneuper, R. (2017). Sixty years of software development life cycle models. IEEE Annals of the History of Computing, 39(3), 41—54. UNIT 4 Glinz, M., van Loenhoud, H., Staal, S., & Bühne, S. (2020). Handbook for the CPRE founda- tion level according to the IREB standard (pp. 1—139). International Requirements Engineering Board. UNIT 5 Schmidt, R. F. (2013). Software engineering: Architecture-driven software development (pp. 43—54). Elsevier. 7 UNIT 6 Agutter, C. (2019). ITIL® foundation essentials—ITIL 4 edition: The ultimate revision guide. ITGP. Chapters 1, 2, 8, & 9 UNIT 7 Kruchten, P. (2003). The rational unified process: An introduction. Addison-Wesley. Chapter 3 UNIT 8 Kruchten, P. (2003). The rational unified process: An introduction. Addison-Wesley. Chapter 2 UNIT 9 Rubin, K. S. (2013). Essential Scrum. Addison-Wesley. Chapters 1 & 2 8 LEARNING OBJECTIVES The aim of this course is to give students an insight into the technical and theoretical basics of Software Engineering Principles. This course will first cover Boolean algebra, enabling students to work on simple calculations. In addition to the general structure of computer systems, common challenges in the development of enterprise information sys- tems are discussed. Students will be able to describe the structure of computer systems and communication networks, as well as different programming paradigms and their applications. The software life cycle is an important focus; students will learn how to dis- tinguish between its phases, and how to describe the different process models of software development. Furthermore, the course book will cover the typical phases and activities in software engineering. These phases and activities will provide possible solutions and actions that can be used to address these risks. 9 UNIT 1 STRUCTURE AND ORGANIZATION OF INFORMATION SYSTEMS STUDY GOALS On completion of this unit, you will be able to… – explain what it means to encode information using binary code. – name the units that make up a Von Neumann computer. – identify the typical elements in distributed systems. – name the elements of communication networks. – understand the types of enterprise information systems. 1. STRUCTURE AND ORGANIZATION OF INFORMATION SYSTEMS Introduction To fully understand most of the principles of software engineering described hereafter, knowledge about the fundamental ways that information systems store and process infor- mation is required. Knowing the main components that comprise information system architectures is also essential. This unit will introduce the binary coding system and describe the basic components of contemporary computer system architecture. There will also be a discussion of typical elements of distributed systems and communication net- works. The unit will close by giving insights into selected kinds of enterprise information systems. 1.1 0 and 1 as the Basis of All IT Systems Digital systems store and process information in binary form, i.e., in the form of sequences Bit of 0 and 1. One bit corresponds to the amount of information in an answer to a question This is the smallest possi- with only two possibilities, for example, “Is the sun shining?” Binary coding designates 0 ble unit of information. or 1 to each of the two possible answers. 1 means, for example, “yes,” and 0 means “no.” Obviously, there are more than two possible answers to some questions. The coding can then no longer be completed in one bit; it will require bit sequences. These are used for storing information amounts that are greater than one bit. The values 0 and 1 can be simulated relatively easily, both physically and using electrical engineering. The binary coding thus forms the transition from the world of digital comput- ers to the real world. Some real world applications of binary are explained in the follow- ing: A light switch can hold two positions, “on” and “off,” so information up to one bit can be “stored” in a light switch. A simple flashlight can be switched on or off, so the light beam can be used to transmit information up to one bit. Optical storage media, such as CDs, DVDs, and Blu-Ray discs, have a spiral track made up of small peaks and valleys. Every change (an increase or decrease) means 1, and every non-change means 0. This way, up to 25 gigabytes of data can be stored in one track on a Blu-Ray disc (single layer), and up to 128 gigabytes can be stored when using the BD-XL quad layer standard from 2010 (Risska, 2010). 12 Magnetic storage media, such as hard drives, stores data on disks that are made of a magnetizable material and divided into many small areas. With a special write head, these areas can be set to one of two possible magnetic states. One state is spoken as “one” and the other as “zero.” All data stored in a computer system, as well as all programs that are executed on a com- puter system, manifest themselves as sequences of 0 and 1. Only in this form can they be processed by the technical components, such as the central processing unit (CPU) or main memory. Boolean Operations The foundations of processing sequences consisting of 0 and 1 were laid in the nineteenth century by mathematician George Boole (The Editors of Encyclopaedia Britannica, n.d.). Today, the term Boolean algebra is used to describe an algebraic structure with the two elements, 0 and 1, and the logical operations AND, NOT, and OR. The functionality of these operations can be implemented easily with electrotechnical assemblies and combined to form complex circuits. Today, all processing units are constructed on the basis of these simple operations. The table below gives an overview of the most important Boolean operations. The Boolean operation “AND” is a two-digit operation. It evaluates two Boolean values, X and Y, to 1 if both values are 1. Otherwise, AND evaluates to 0. That is, if a lamp is connec- ted to two light switches via an AND circuit, the lamp only lights up when both switches are in the “on” position. If a switch is in the “off” position, the lamp does not light up. The Boolean operation “OR” is also a two-digit operation. It evaluates two Boolean values, X and Y, to 1 if at least one of the values is 1. If a lamp is connected to two light switches via an OR circuit, the lamp lights up as soon as one of the two switches is in the “on” posi- tion. If both switches are in the “off” position, the lamp does not light up. The operation “NOT” has only one input digit. It negates the value X to the other. The value 1 is evaluated as 0, the value 0 as 1. If a lamp is connected to a light switch via a NOT circuit, the lamp lights up when the switch is in the “off” position. The lamp does not light up when the switch is in the “on” position. Table 1: Truth Table for the Boolean Operations AND, OR, and NOT X Y AND (X, Y) OR (X, Y) NOT(X) 0 0 0 0 1 0 1 0 1 1 1 0 0 1 0 1 1 1 1 0 Source: Created on behalf of IU (2023). 13 Storing Numbers and Letters As described above, all digital data are stored as a bit sequence, but computer systems can also calculate ordinary numbers, and store and display letters and other characters. There are defined mappings and standards for this, for example, ASCII or UTF-8. In UTF-8, the sequence 01010011 is specified for the letter “S.” In order to store letters and digits in binary, one only has to look up which sequences of 0 and 1 are defined for each. This information can be found in the UTF-8 table (FileFormat.Info, n.d.). Table 2: Excerpt from the UTF-8 Encoding Table Character Binary encoding according to UTF-8 A 01000001 B 01000010 a 01100001 b 01100010 @ 01000000 Source: Benner-Wickner (2021), based on FileFormat.Info (n.d.). To perform mathematical calculations, the numbers from our conventional decimal sys- tem (with the digits 0, 1, 2, 3, 4, 5, 6, 7, 8, 9) are first converted into the binary system (using the digits 0, 1). The values are then calculated in the binary system and transferred back to the decimal system. The conversion is necessary because computer systems can only calculate with 0 and 1. 1.2 Von Neumann Architecture To fully comprehend the functionality of information systems, it is vital to know some key details about the basic composition of a computer system. This is especially true for per- formance issues in information systems. The basic functionality of all current computer systems was introduced in 1945 by John von Neumann (1903–1957) (The Centre of Computing History, n.d.) and is now called “von von Neumann archi- Neumann architecture.” Before 1945, computer programs could not be called “software” tecture because they were hardwired in, for example, electrical circuits or punch cards. Von Neu- This is a general architec- tural concept for the con- mann developed the idea of storing the computer programs in a shared memory (the struction of universal main memory) of the computer, together with the data being processed. Thus, the instruc- computers. tions for processing the data could now be easily changed, which made (re-)programming computers possible. The von Neumann architecture still serves as a conceptual template for the construction of universal computer systems. Almost every common computer sys- tem produced today follows the von Neumann architecture (The Centre of Computing His- tory, n.d.). The spectrum of von Neumann computers ranges from huge mainframes to 14 laptops, game consoles, and smartphones. However, there is a technology emerging that breaks with this kind of architecture for the first time: the quantum computer. It can han- dle simultaneous operations using quantum phenomena, such as superposition. For now, this technology is not applicable for information systems discussed in this unit. Units of the Von Neumann Architecture The von Neuman architecture comprises five units: memory, control, input/output (I/O), the arithmetic logical unit (ALU), and a bus system connecting the units (Shipley & Jodis, 2003). In contemporary implementations of this architecture, most of the components— besides mass storage—are integrated into a central processing unit (CPU). Even graphical processing units (GPU) are integrated into modern processors. Each of the five basic units is described in detail as follows. Figure 1: Von Neumann Architecture Source: Created on behalf of IU (2023). Memory The memory of a von Neumann computer is used to store binary coded data and pro- grams; there is only one type of memory. The available memory is divided into small areas that are numbered consecutively with a unique address. Data that are stored in a memory cell can be called up via their address. When accessing memory, the memory area in the storage medium is located and then read out or changed. Control unit The control unit and the ALU are essential elements of the computer’s CPU. The control unit assumes the role of coordinator in the CPU. It is responsible for first loading the com- mands of a program to be executed from the memory into the CPU in the correct order and interpreting them. Then, the source and destination of the data to be processed must be interconnected with the ALU. Finally, the calculator must be informed as to which cal- culation it should carry out with the data. 15 Arithmetic logical unit Like the control unit, the ALU is part of the CPU. It is the only component of the architec- ture that does calculations. The ALU has a number of executable arithmetic and logical functions. As previously mentioned, all operations in computer systems are carried out in the binary system. The available set of commands of the ALU is therefore mapped to sim- ple binary operations that can be carried out very quickly (e.g., AND, OR, NOT). Input output units The I/O units are the interface between the system and its surrounding environment. They are responsible for the flow of incoming and outgoing data and programs. This includes communication with the user, for example, via screen, keyboard, and mouse, and commu- nication with other systems via system interfaces. Bus system The bus is a data transmission system used by all units for communication. In a von Neu- mann computer, all data are transferred over the bus. Since both the provision of the data and the provision of the programs take place via the bus, the transmission capacity and the speed of the bus significantly determine the speed of the computer. Modern bus sys- tems (e.g., PCI-Express for external devices or advanced micro devices [AMDs] HyperTran- sport for on-chip communication) work more like a point-to-point network than a bus sys- tem. Unlike that which was common for computing systems at the time, the von Neumann architecture was not designed to solve a specific problem. With a von Neumann computer, all calculable problems can theoretically be solved because the internal structure of the computer does not determine how the data are processed. Since the programs are also in a changeable memory, the rules and instructions for how the data are processed can be adapted without having to exchange the hardware components of the computer system. The invention of the von Neumann computer has been an important paradigm shift, and has made programming software possible. How the von Neumann Computer Works In a von Neumann computer, the program commands are stored in successive memory cells within the memory. When a program is started, the control unit causes the first com- mand to be loaded into the ALU. A command contains instructions for loading data from the memory into the ALU. carrying out calculations on data already loaded into the ALU. storing data. After the command has been loaded into the calculator, it is executed. After the execution of the first command, the next instruction is loaded into the ALU by the control unit. This sequence is repeated until the program has ended. 16 Each command is executed within one step of the CPU clock. Today, the time spent adding two values within the ALU is less than 0.0000000001 s (1 nanosecond) (Leach et al., 2011). Imagine that, in this very small amount of time, even objects traveling at the speed of light can only move 0.3 m. 1.3 Distributed Systems and Communication Networks Another important evolution concerning the structure and organization of information systems is the switch from single mainframes to distributed software systems, which Distributed software communicate autonomously using a (global) network infrastructure. Their underlying system This is a software system hardware and software components are located on computers that are connected by a that can only be used in communication network and communicate by exchanging messages via that network. For conjunction with several example, every online shop is a distributed software system: The customer’s device is con- computers connected via a communication net- nected to the online retailer’s computers via the internet. Searching for items, placing work. items in the shopping cart, ordering, and paying are examples of actions that are carried out via messages between the customer’s computer and the online retailer’s computer. Typical Elements in Distributed Systems A distributed system consists of, at a minimum, a server, a client, a communication net- work, and an agreement on the structure of the messages to be sent. The figure below schematically shows the structure of a distributed system. Figure 2: Illustration of a Distributed System Source: Created on behalf of IU (2023). 17 Server Servers are computers that make functions accessible to other computers via a communi- cation network. The functions offered by servers are also called services. The following is a list of servers and their functions: Search engine servers enable information to be found on the internet. Weather service servers provide information on the current weather situation. Online retailers’ servers offer search functions in the inventory. Email providers’ servers enable the sending and receiving of emails. Client Computers using services are called clients, which are not to be confused with customers. If, for example, a browser is used to order something in an online shop, the computer on which the browser is installed takes on the role of the client. A network printer is a server that offers the printing services to the local network. Every computer that prints out a document via this printer is a client of the network printer. Please note that both roles only relate to the offering and requesting of services, and not to the required hardware of the devices. Every laptop and smartphone can also become a server, i.e., a service provider, by installing and starting the appropriate software systems. Most systems within an enterprise network act as a server as well as a client, depending on the service considered. For example, the customer relationship management (CRM) system acts as a server, providing customer address data to the enterprise resource plan- ning (ERP) system, which then becomes the client. The ERP system also acts as a server providing daily turnovers of every customer to the CRM system. Communication network A communication network connects clients and servers. It consists of physical components for data transmission, such as wires or radio antennas. technical components for routing and transferring data, such as routers, switches, repeaters, and bridges. network interfaces to connect a device to a communication network, such as an ether- net interface card or a Bluetooth chip. Network interface A network interface enables a computer to communicate with other computers. In addi- tion to establishing the physical connection using a cable socket or a built-in radio chip (i.e., the hardware), support from the operating system (the software) is required. The components for data transmission ensure that information is transferred physically over a certain distance. The components of the data exchange ensure that the data are transpor- ted in a communication network using the optimal route from sender to recipient. 18 Message Computers exchange information using messages. For example, the search term must be transmitted from the client to the search engine and the results from the search engine are sent back to the client. The structure and content of the message are application-spe- cific and usually defined by the server. A message is defined as logically related informa- tion that is sent by an application. The network interface of a computer must transform the message into a bit sequence, which is then split for transmission into smaller data packets with a predetermined length. For example, a typical data packet transmitted through the internet via a digital subscriber line (DSL) connection can transport 1452 bytes of user data (Nozero, 2015). To send an image file with a size of 500 kilobytes from one computer to another computer, at least 353 data packets must be generated and sent over the communication network. Conceptual Models for Communication The messages must be transformed into data packets before they leave a computer. This transformation takes place in several steps. The type of message and communication net- work determine what happens in the individual steps. Both the internet protocol suite (TCP/IP) model and the open systems interconnection (OSI) reference model describe net- work architectures that encode the messages in a cascade of different layers in packets that are suitable for the transmission channel. They also decode received packets to com- bine them into a message. Please note that the OSI model has never been implemented fully in practice, but is still used to explain important steps in computer communication. The functions used for coding and decoding in a layer are called protocol. Each layer is Protocol responsible for a very specific aspect of the message exchange between computers. A set of conventions that govern the interaction of processes, devices, and The figure below illustrates the differences between the two reference models. The OSI other components within reference model consists of seven different layers, while the TCP/IP protocol has four (in a system is a protocol. literature such as Tanenbaum , TCP/IP has five layers because some authors add a physical layer). Thus, the OSI reference model is more detailed, and the functions descri- bed in the layers generally describe the architecture of networks. The TCP/IP reference model is essentially limited to the definitions in the transport and internet layers. Although it is less detailed, it is used almost everywhere. 19 Figure 3: Comparison of Conceptual Models Source: Created on behalf of IU (2023). 20 Application layer The functions (protocols) of the application layer in both reference models contain appli- cation-specific definitions for the structure and exchange of messages. For example, the Hypertext Transfer Protocol (HTTP) for calling up and transferring websites, and the Sim- ple Mail Transfer Protocol (SMTP) for transferring emails are located. Presentation and session layer Elements of the presentation layer in the OSI model contain the definition of syntax and semantics of the information to be transmitted. They are responsible for tasks such as character encoding, data compression, and encryption and decryption of information. The session layer enables sessions to be set up between remote computers. With one ses- sion, the actions of both computers can be controlled and synchronized in a targeted manner, which enables smooth interaction, especially with long transfers or interruptions. Sessions are used, for example, when you log in to a web application or when you open a connection to a database. Transport layer In the transport layer, messages from the higher layers are divided into smaller units and passed on to the network or internet layer. In addition, the protocols use appropriate security functions in the transport layer to ensure that all data packets that have been sent arrive at the recipient. The transport layer of the sender communicates directly with the transport layer of the recipient, so there is a logical end-point-to-end-point connection in this layer, even if, from a technical point of view, there are many interconnected compo- nents for data transfer between sender and receiver. When the packets arrive in the wrong order—which can happen from time to time—the transport layer is capable of lining them up correctly using a sequence number. Network layer or internet layer The technical components for data transfer in networks (e.g., routers) work at the level of the network layer and the layers below. The network layer of the OSI model is responsible for the operation of the communication network. It takes care of the selection of the route through the network that a data packet travels, from the sender to the recipient. Depend- ing on the geographical distance, there are several nodes on the path of a data packet from the sender to the recipient. In simplified terms, the network layer works like the post office: You can put letters into any mailbox, and, at some (end)point, letters will arrive at the correct destination address. The postal stations, distribution centers, and streets through which the letter was transported are not transparent for either the sender or the recipient. The network layer also controls the quality of the transmission, which is useful if, for example, more data are sent on a route than the capacity of the transmission path allows. The internet layer in the TCP/IP reference model is very similar to the network layer in the OSI reference model. It is also responsible for the correct delivery of data packages and the avoidance of overload. 21 (Data) link layer In the OSI reference model, the network layer is followed by the data link layer. With an appropriate protocol, it ensures that the data are transferred completely and without errors from one computer to the next in the route. In particular, the tasks of the data link layer are the flow control when the transmission speed is too high and error-handling due to physical transmission errors. In the TCP/IP model, this layer corresponds to the link layer. Physical layer According to the OSI model, the bit transmission layer is responsible for transmitting the binary coded digital data packets over the physical communication channel. This means mapping the bit sequences to be transported to the properties (electricity, light, and radio waves), transmitting them, and converting them back into bit sequences. This layer is not defined in the TCP/IP model, so all of the mechanisms described in the OSI physical layer are implicitly assumed to exist. 1.4 Enterprise Information Systems Enterprise information In the following, the term “enterprise information system” is used to refer to commer- system cially used software systems and their system context. With the restriction to commercial This is a commercially used software system that use, the software systems that are used directly or indirectly to achieve business goals are is used to achieve busi- placed in the foreground. The system context contains interfaces to the users of the sys- ness goals. tem and technical interfaces to other systems. Almost every medium and large organization depends on the use of information systems to achieve its goals. In particular, sectors with a fully digital value chain, such as banks, insurance companies, and media companies, depend on information technology (IT) sup- port. In addition, every business model with the internet as a medium for marketing, sales, trade, or delivery needs information systems. This is also true for business models that include communication, networking, or data exchange via computer systems. There are often attempts to classify enterprise information systems into categories. Unfortunately, there is no recognized, generally valid, and complete classification of sys- tems. In this unit, we distinguish between four different kinds of systems: 1. Communication systems 2. Cross-sectional systems 3. Functional area information systems 4. Management information systems Communication systems 22 Communication systems support interpersonal communication using email, video tele- phone, chat, or social networks. Microsoft Outlook, Zoom, and Slack are typical examples of this type of system. Cross-sectional systems All systems that are not communication systems but are also used as standard software are referred to as cross-sectional systems. Typical examples of cross-sectional systems are word processing, spreadsheets, and presentation systems, such as Word, Keynote, Power- Point, or LibreOffice. Both communication and cross-sectional systems are usually maintained by the software companies that developed them—essentially the “Big Five”: Amazon, Apple, Google, Face- book, and Microsoft (Jones, 2019). These systems are used around the world, and are usu- ally not customized to specific sectors or organizations. They are either standard products for which licenses must be acquired, or they are available as open source for download. Functional area information systems Functional area information systems (FAIS) specifically support business processes and activities in organizations. Some FAIS are industry-neutral applications, such as content management systems, accounting systems, and human resources management systems. A FAIS can also be an industry-specific solution; for example, for logistics companies, banks, or insurance companies. When no common, off-the-shelf system fits the organiza- tional needs, FAIS are individually developed solutions. Of all the system classes, FAIS are most customized to the value-adding and supporting business processes. Enterprise Resource Planning (ERP) systems, such as those produced by System Analysis Program Development (SAP), can also be counted among the FAIS. In order to support work steps and processes in organizations as efficiently as possible, FAIS are often the subject of software projects. The projects range from the organization- specific adaptation of industry-neutral and industry-specific solutions to the development of a completely new solution. Management information systems Management information systems are used to support planning and decision-making pro- cesses. Typical management information systems are data warehouse and business intel- ligence solutions. Purposefully cleaned and compressed data from the FAIS on proce- dures, processes, and business transactions are stored in these systems. These data can be summarized in the systems and prepared for the respective target group. In contrast to FAIS, the focus is not on business processes, but on data that are collected when the busi- ness processes are processed. As for FAIS, tools and solutions are available on the market for selected applications. However, since FAIS are often individualized, management infor- mation systems must also be customized for targeted use in the company as part of soft- ware projects. 23 SUMMARY Before getting involved with complex enterprise software projects, we have to understand the very fundamentals of how information systems operate. Since information systems are digital systems, they store and process information as bit sequences (in the form of sequences of 0 and 1). Because the values 0 and 1 can be simulated relatively easily, both physically and electronically, binary coding represents the transition to the world of digital computers into the real world. Boolean algebra with the operations AND, OR, and NOT enables the calculation with the two elements 1 and 0. Today, all processors and chips are constructed on this basis. The basic functionality of all of today’s typical computer systems can be described with the von Neumann architecture. The core idea here is the common storage of computer programs and the data to be processed in a common memory of the computer. The architecture developed by von Neumann consists of five core elements: memory, control, input/output, the arithmetic logical unit (as part of the CPU), and the bus system. Enterprise information systems are usually distributed software sys- tems. They are located on computers that are connected by a communi- cation network, and communicate by exchanging messages over that network. Typical elements of distributed systems are servers, clients, the communication network, and messages. The communication net- works consist of the physical components for data transmission, the technical components for data transfer, and network interfaces to con- nect computers to a communication network. The architecture of com- munication networks is described with the help of reference models. The OSI reference model provides a complete and detailed description, but the TCP/IP reference model has become the underlying technical foundation for the internet. The term enterprise information system refers to commercially used software systems and their system context. This summarizes systems that are used to achieve the goal of an organization and have interfaces to the users and technical interfaces to other systems. Information sys- tems can be divided into the system classes’ communication systems, cross-sectional systems, functional area information systems, and man- agement information systems. 24 UNIT 2 RISKS AND CHALLENGES OF ENTERPRISE SOFTWARE ENGINEERING STUDY GOALS On completion of this unit, you will be able to … – identify the typical properties of enterprise software systems. – understand the typical risks and problems that arise when carrying out software devel- opment projects. – explain the causes of those risks and problems. – identify which challenges of enterprise software projects can be derived from typical problems and causes. 2. RISKS AND CHALLENGES OF ENTERPRISE SOFTWARE ENGINEERING Introduction Software development projects in which enterprise information systems are to be created utilize processes that can basically be controlled with typical project management meth- ods. However, compared to other manufacturing processes, there are relevant differences that result from the very specific properties of software systems. Therefore, this unit intro- duces the typical properties of software systems, explains the typical risks and problems that can be observed in software projects, and analyzes the causes that are primarily responsible for the problems. Building on this, the most important challenges in software engineering are presented. 2.1 Properties of Enterprise Software Systems A common characteristic of all software systems is their complexity. An enterprise soft- ware system must support a wide range of functions. is part of a complex application landscape, and is connected to many other software systems via technical interfaces. is used by many users. should work on as many devices as possible under different operating systems. should be easily maintainable after it has been put into operation. is created by many people. consists of many different components and subsystems. In contrast to industrial machines, for example, software is not tangible, but rather imma- terial. A completed software system manifests itself as a very long series of 0 and 1 on a storage medium. This is another challenge in many ways: Defects cannot be seen, and you can never look directly at the components and their dependencies during the planning, construction, and use of software. Neither the project manager nor the customer can get an idea of the actual “construction progress” of the software by inspecting a construction site. In enterprise software engineering, complex, expensive, and business-critical systems are created that you can neither touch nor represent in a natural way (Sommerville, 2016, p. 18). 26 Figure 4: Software System versus Machine Source: Created on behalf of IU (2023). According to international standards, such as ISO/IEC 25010, enterprise software systems shall fulfill the following quality requirements (The International Organization for Stand- ardization [ISO], 2011). Quality Requirements Functional suitability When completely developed, software should match its (intended) specification. It is sup- posed to do exactly what was stated in the specification. If a system is inaccurately speci- fied, whether the software created is correct cannot be determined. One important aspect of functional suitability is interoperability. A software system is interoperable if it can be merged or integrated with other systems with little effort. In fact, a business application that works in isolation from other applications no longer exists. Cross-application interfaces (e.g., web services) are available in almost every company information system. Reliability The software is available and the user can use it in the context of their business activities. The “reliability” property is relevant depending on how critical the application of the soft- ware is and the height of the potential damage due to failure or malfunction. Fault tolerance If the software is not used as originally intended, or if a connected system does not behave as originally planned, a software system should behave tolerantly and not produce any uncontrolled errors or inconsistent data. 27 Usability Software is usable when users find it easy to use. Since the success of Apple’s products and the introduction of small, easy-to-use apps, usability has become increasingly impor- tant and often determines the success or failure of systems. A broader view on usability is given by the term “user experience,” which also includes users’ feelings when interacting with the software system. Performance efficiency Performance refers to how the system complies with requirements such as response time and resource consumption. Typically, the performance is either in distributed systems on which a large number of users work at the same time (e.g., Amazon, Facebook), or in sys- tems that have to process large amounts of data at very specific times (e.g., banks, insur- ance companies). In short, this property can be checked by measuring, calculating, and simulating. Maintainability Enterprise software systems are often used over a period of several years, sometimes even decades. To be compliant with changing legal requirements and to react to changes in market or emerging technologies, new functions must be continuously implemented in existing systems. The ability of software to be changed in an economically viable way is known as maintainability. Maintainability depends heavily on the internal structure of the software and its documentation. In practice, maintainability decreases with increasing service life, so it makes more economic sense to completely replace or develop a system than continuing to maintain an existing system. An important aspect of maintainability is reusability. It describes the probability with which a software system or parts of a system can be reused in a different context. Reusa- bility must be carefully planned and considered when designing a software system archi- tecture. It does not arise by chance. Portability The portability of software results from the effort required to make software executable on a different platform (e.g., database, operating system, mobile device) compared to the (new) development effort for software. Portability is a relevant property, especially for applications that are intended for the end user and therefore must work on as many device classes and operating systems as possible. 28 2.2 Software Engineering The term software engineering describes the structured and methodical planning, crea- Software engineering tion, and evolution of software systems, as well as their operation. According to ISO/IEC/ This is the application of engineering approaches IEEE 24765:2017, software engineering is defined as the “application of a systematic, disci- to the development of plined, quantifiable approach to the development, operation, and maintenance of soft- software. ware; that is, the application of engineering to software” (ISO, 2017, p. 8). Smaller programs or apps for private use, or for highly specialized industrial applications, are sometimes created with little effort by one person. However, several dozen to a hun- dred people are often involved in implementing complex enterprise information systems over a period of several years. In order to implement and operate such systems reliably, software engineering must be applied. This means that such systems cannot simply be created according to the intuition of the project manager, but principles, methods, and tools must be used for this. Otherwise, software projects would be hopelessly lost in chaos. Compared to other engineering disciplines, software engineering is a young discipline. Research into methods and principles with which the “software crisis” should be over- come was started in the 1960s (Cohane, 2017). At the same time, software systems became more complex, and they continue to do so. Supported by increasingly powerful hardware, more expressive programming languages, the networking of computer systems, the expansion of transmission capacities, the mobilization of computer systems, and resourceful development tools, newly created software systems are more powerful and more complex in their structure. Integrating artificial intelligence in software is a highlight of this development. Because software systems are immaterial, their size and diversity are not limited by natu- ral or physical laws. In contrast to other disciplines, such as architecture or electrical engi- neering, there are almost no natural restrictions (gravity, friction, or resistance). The power of software systems is therefore strongly limited by the ability to abstract—that is, the ability to develop abstract, logical structures—as well as the communication abilities of the people involved in the software project. Many recognized principles and methods of software engineering are therefore based on experience and knowledge in the develop- ment of complex information systems. A core principle of software engineering is the division of the software project into differ- ent activities and the distribution of members of the software team into distinct roles, each with their own typical activities, responsibilities, and conflicting goals. Another core principle is the use of “patterns,” i.e., the use of organizational and technical structures that have proven themselves in several projects. Please note that the current state of research and technology in the field of software engi- neering is only a snapshot of a continuously evolving environment. Since there is no end in sight for the possibilities for further technological development, future technological developments will result in further tools and methods of software engineering that are not 29 known today. Therefore, software engineering research is concerned with the evolution of existing methods and tools, as well as with the development and evaluation of new meth- ods. 2.3 Risks and Typical Problems The complexity of enterprise software systems, together with the immateriality of soft- ware and the expectations of the client and user regarding the aforementioned properties of software, leads to a number of typical risks of software projects. In practice, you can find the following typical risks, among others, when working on software projects. Project Termination Risks The following is a list of risks that could lead to the termination of the project: Requirements turn out to be unrealizable in the course of the project. Typical causes for this are constantly changing key requirements, excessive expectations of the system, or technical, organizational, and compliance conditions that were recognized too late. The costs for the project go over budget even before the system is ready for use, and the project team cannot provide any reliable information about future costs. Members or different organizational units within the project have fundamentally differ- ent opinions or are at odds. They no longer trust each other and constructive coopera- tion is no longer possible. Software Applicability Risks The following is a list of risks to the software applicability: During deployment of the software, it turns out that important business functions are missing or have been implemented incorrectly. Quality requirements stated by the customer are not met. The system reacts too slowly when there are high numbers of users, the transmission of critical data is not ade- quately secured, or the time window for nightly jobs processing large amounts of data cannot be adhered to. The system is not accepted by users because, for example, data input takes too long, operation is too cumbersome and complicated, or the user interface has been rede- signed so that familiar elements are difficult or even impossible to find. Maintenance Risks The following is a list of risks related to maintenance: The team responsible for maintenance cannot realize the consequences of its actions. Dependencies and relationships within the system cannot be recognized based on the documentation. 30 The internal structure of the system has degenerated over the years due to ongoing small maintenance work and adjustments. Even simple maintenance work requires enormous effort that is disproportional to the economic benefit. There is no knowledge available about the technologies used in the legacy system. The original developers of this system have retired, and there are no specialists who have experience with the old programming languages and operating systems. If you are interested in practical, cutting-edge discussions in the context of maintenance risks, please consider the proceedings of the International Conference on Technical Dept (TechDebt) published by The Association for Computing Machinery (ACM) (ACM, n.d.). 2.4 Root Cause Analysis Compared to industrial processes producing mostly material goods, in which many work steps can be precisely planned in terms of duration and resource requirements, precise planning is usually not possible in software engineering projects. In particular, the exact costs, the specific scope of functions, and the technical design of a software system can only be precisely determined at the end of a project, which is, of course, too late. The main influencing factors for software project risks are the complexity and immaterial- ity of software systems. In addition, software development is a very knowledge-driven process. We will illustrate this using an example: Complex software projects are often star- ted with an overarching business goal, e.g., “introduction of a self-care portal for custom- ers of an insurance company.” However, which specific functions the system has to fulfill in detail which screen dialogs are required and how other software systems can be integra- ted cannot be precisely specified at the beginning of the project. Participants will only learn these aspects as the project progresses. A key feature of software engineering is that system requirements are only recognized in the course of the software process. Unfortunately, these requirements form the starting point for all further activities within a software project. As a rule, relevant requirements are only recognized by users and customers after they have seen a first version of the sys- tem. A software engineer is now faced with the following dilemma: If you start to develop a sys- tem for which the requirements are not clear, you run a high risk that the created applica- tion does not implement the desired functions. However, at the beginning, users often cannot name needed functions. This is because they usually only recognize important and relevant functions when they test a first version of the system. The figure below schemati- cally shows the interaction between recognized requirements and the software process. 31 Figure 5: Software Engineering is Strongly Knowledge-Driven Source: Created on behalf of IU (2023). The dilemma of being driven by knowledge is exacerbated in practice by the fact that there is usually not just one stakeholder who makes requirements for the system, but many stakeholders, often spread over several organizational units. This, in turn, means that many stakeholders may recognize additional requirements during the software proc- ess. In addition to the stakeholders, new legal (compliance) requirements, technological developments, and the market situation can also have a significant influence on the requirements for software systems during a software project. This leads directly to a typi- cal cause of failed software projects: changing and conflicting requirements. In addition to commercial off-the-shelf software (COTS), such as word-processing soft- ware, there are also industry-specific software systems that are only relevant for very spe- cific branches of industry, such as a specific integrated development environment (IDE) for mobile software development or a computer-aided design (CAD) tool for architects. More- over, highly specialized custom software exists that is specifically designed and developed by individual companies for certain activities in the value chain. The share of this kind of software is steadily increasing due to the digital transformation of business processes. A lack of business knowledge on the part of software developers is a further cause of failed projects, especially for industry or company-specific software. The development team must have a business understanding of the requirements formula- ted by the stakeholders so that it can deliver a usable software system. Because today’s enterprise software systems are usually integrated into complex enterprise architecture via many interfaces, the development team must also be able to recognize the conceptual relationships across system boundaries. In addition, a project team with domain knowl- edge can cope more reliably with unclear requirements, as it can independently identify gaps or errors in the requirements and offer the stakeholders targeted solutions. If too much focus is placed on the technology used in software projects and the benefits for the user take a backseat, this is called technology-centricity. Software projects that focus on technology issues and problems also carry a high risk of project failure. It is often more exciting and convenient for developers to talk about technical topics and to concen- trate on the use of the latest technologies than to actively deal with the users’ technical 32 problems. As a result, a system is delivered that has possibly picked up on all new technol- ogy trends, but has been programmed beyond the actual needs of the user. Concepts such as human-centered design and design thinking address these issues. Finally, the lack of communication or the lack of coordination among participants should be mentioned as a typical cause of failed projects. Different departments are usually involved in development projects for enterprise software systems, for example, marketing, sales, auditing, software development, operations, external consultants, the staff council, and the legal department. Each organizational unit has its own ideas and objectives with regard to the software system; there may already be differences within individual depart- ments. This diversity is often supplemented by areas of responsibility that are not clearly defined and a lack of professional competence. In addition, most units use their own expert language. As a result, many terms are understood differently. Neglected communi- cation management in such software projects quickly leads to different objectives, post- poning or failing to make important decisions, and complication of the resolution of per- sonal conflicts. This also increases the project risk. 2.5 Challenges in Software Engineering The aforementioned risks, problems, and causes result in a number of challenges that apply, in particular, to software development projects for enterprise information systems. In this section, we will discuss the following challenges in software engineering: economic uncertainty technological uncertainty communication conflicting goals complexity Economic Uncertainty A central challenge in enterprise software projects is dealing with and taking into account uncertainty throughout the course of the project. To illustrate the economic uncertainty, the figure below shows the “cone of uncertainty,” determined using statistical methods (Bauman, 1958). The vertical axis (y-axis) represents the degree of uncertainty, while the horizontal axis (x-axis) indicates the course of a software project over time. The project starts on the left and is finished on the right. The graph shown in the figure below has the shape of a cone rotated by 90°. The earlier the total costs are estimated in a project, the higher the deviation from the actual effort at the end of the project. As the process pro- gresses, an estimate of the total costs becomes more precise, but it is only at the end of the project that it is possible to precisely determine the level of effort. In contrast to pro- duction processes, in which the consumption of resources and the duration of the individ- ual work steps can be calculated, a comparable precise forecast is usually not possible in software projects. 33 Figure 6: Cone of Uncertainty Source: Brückmann (2021), based on Bauman (1958). Technological Uncertainty Somewhat comparable to economic uncertainty, a technological vision can be created at the beginning of a software project, but the actual technical solution can only be precisely determined at the end of the project. The figure below schematically illustrates the course of technical uncertainty in a software project. At the beginning of a project, there is still a lot of freedom to decide which technologies to use. Technical decisions are made by the software architect on the basis of the current knowledge in order to support the require- ments known at that point in time as well as possible. However, since requirements are only recognized in the course of the project, the interim results must be checked continu- ously. The technical solution can then be further adapted and expanded within the scope of all constraints. As a rule, the possible scope for decision-making with regard to the tech- nical solution becomes smaller as the project progresses, until a concrete solution has been worked out at the end of the project. This also means that, comparable to the eco- nomic uncertainty during the project, technical uncertainty must also be endured by the project team. 34 Figure 7: Technological Uncertainty Source: Created on behalf of IU (2023). Communication The inclusion of various stakeholders, each with different individual backgrounds, knowl- edge, and interests, represents a further important challenge for enterprise software projects. Particular care must be taken here to establish and maintain willingness to coop- erate. Furthermore, new findings and, if necessary, changes to the plan, must be commu- nicated to all relevant stakeholders in a manner that they can understand. In addition, the relevant stakeholders must be actively involved in making decisions and in quality assur- ance of artifacts generated in the software process. Conflicting Goals Even with software projects, customer satisfaction is the top priority, but decisions within software projects also range between quality, time, and costs. The figure below illustrates a typical decision dilemma with the help of the magic triangle: If you improve one target Magic triangle parameter, this is usually at the cost of the other two target parameters. The magic triangle illus- trates competing goals. For example, if quality is very important to a project, quality assurance activities are at the expense of timely completion and budget. If the focus is on project costs and all deadlines are met, then fewer resources remain for quality assurance. However, if a high quality project is to be delivered on time, then the budget will not be kept. Due to the uncertainty presented, together with the ongoing gain in knowledge during the project, the sizes of the “magic triangle” also change continuously in software projects. This results in frequent coordination and decision-making processes between the project team and the stakeholders. 35 Figure 8: The Magic Triangle: Quality, Time, and Cost Source: Created on behalf of IU (2023). Complexity The physical complexity of enterprise software systems (many technical components, many interfaces to other systems, and many implemented functions), in combination with the immateriality of software, places high demands on human abstraction. Because the internals of finished software are not visible, the relationships are illustrated with the help of graphical models (e.g., using standardized notations like the Unified Modeling Lan- guage [UML]). Inferring the structure and behavior of the software from a graphic model requires intense intellectual capabilities. The use of software models is a key practice in software engineering to which there are currently no sensible alternatives. Various types of models have been developed to master complexity, which illustrate static and dynamic aspects of software systems in varying degrees of detail. Under the premise of uncertainty and knowledge gain during a software project, both the organizational planning (resources and activities) and the technical plan- ning (specification and graphic software models) should only be created to the extent that is appropriate for the current phase of the project. In software projects, attempts are often made to compensate for uncertainties by creating a plan that is as precise as possible, or a model that is as detailed as possible with all potential eventualities. Either an exaggeratedly detailed project plan is drawn up, which is intended to predict, for the entire project, which activities are to be carried out by whom and with what effort. The business requirements and solutions of the software system are analyzed on a very detailed level and documented in the form of extensive models. This Analysis paralysis phenomenon is called “analysis paralysis.” Complexity paired with uncertainty harbors This is a phenomenon of the risk of inappropriately expensive analysis activities. The attempt is made to hide the inappropriately complex analysis activities. uncertainty by producing complex analysis results, for example, in the form of large and complex software models. The team often does not just try something, but first analyzes 36 everything in detail. The danger of “analysis paralysis” is that many resources are tied up, which are then missing when implementing an initial software version. However, the anal- ysis models that were elaborately created at the beginning often become obsolete due to newly gained knowledge during the implementation and presentation of the first software version. SUMMARY In addition to their complexity, a typical property of enterprise software systems is, in particular, their immateriality. Software is neither visible nor tangible. Of course, you can still review the code, but imagine that even the software running in a ten-year-old car contains close to 100 mil- lion lines of code. In addition to supporting business functions, software systems also require the following properties: functional suitability, reli- ability, fault tolerance, usability, performance efficiency, maintainability, and portability. Software engineering describes the structured and methodical planning, creation, and evolution of software systems and their operation. A core principle of software engineering is the division of the software project into various activities, the assignment of team members to responsibili- ties for certain activities, and the use of organizational and technical patterns that have proven themselves over several projects. The complexity of enterprise software systems, together with the imma- teriality of software and the expectations of the client and user with regard to the aforementioned properties of software, lead to a number of typical risks in software projects. One factor influencing project risks is that software development is a highly (domain-)knowledge-driven process, and the requirements for the system in development can change in the course of a project. A lack of business knowledge in the development team or a lack of communication and coordination are typical causes of failed software projects. Derived from typical risks and their causes, the following fundamental challenges are found in enterprise software engineering: dealing with economic and technological uncertainty during the project, communica- tion between those involved in the project, dealing with conflicting goals, and the technological complexity of enterprise software systems. 37 UNIT 3 SOFTWARE LIFE CYCLE: FROM PLANNING TO REPLACEMENT STUDY GOALS On completion of this unit, you will be able to… – explain the phases of the software life cycle. – identify the characteristics of each phase. – understand the activities within the life cycle phases. 3. SOFTWARE LIFE CYCLE: FROM PLANNING TO REPLACEMENT Introduction Software systems go through a life cycle, which consists of different phases. Each phase is characterized by typical activities, people involved, risks, and challenges. In this unit, we will examine the details of each phase. Beginning with the planning phase, we will show how basic customer needs are determined. The development phase continues, applying all of the constructive activities required, from the initial order to the deployment and implementation of the system. After the development work has been completed, the soft- ware system must be deployed to the operational environment and integrated into the existing application landscape within the operation phase. The maintenance phases include all activities concerning the management of problems and incidents, as well as the functional evolution of the operational application. At the end of the software life cycle, the application is taken out of service. 3.1 The Software Life Cycle at a Glance Software life cycle As shown in the figure below, the software life cycle can be roughly divided into five indi- This is a software system vidual phases (The International Organization for Standardization, & The Institute of Elec- or software product cycle initiated by a user need or trical Engineers, Inc., 2017): a perceived customer need, and terminated by 1. Planning, which includes the activities before the start of a software project discontinued use of the product or when the soft- 2. Development, which includes the activities between the start of the project and the ware is no longer availa- deployment of the finished system ble for use. 3. Operation, which is the start-up and operation of the system in the target environ- ment 4. Maintenance, which is the maintenance and evolution after deployment 5. Shutdown, which includes the activities used to take the system out of operation The software life cycle model and its phases are used for medium- and long-term project planning. Hundreds of applications are often used in large companies. Based on the cur- rent phase in the life cycle, information technology (IT) management can get an overview of the current status of its system landscape and draw up personnel, resource, and invest- ment planning. Furthermore, based on the determination of the current phase in the life cycle, certain activities and methods of software engineering can be derived. 40 Figure 9: Software Life Cycle Source: Created on behalf of IU (2023). The life cycle is run through in order, from planning to shutdown. In practice, the phases of the life cycle cannot always be clearly separated, but flow into one another. The operation and maintenance phases can be run several times in succession before the system is switched off. 3.2 Planning The initial phase of a software life cycle is planning. In this phase, all activities that are carried out before the start of software development activities can be determined. This phase is initiated by IT management, who are actively involved in the planning phase, and make the decisions relevant to the structure of the project. Starting with the determina- tion of the requirements, through to the financial planning to the procurement, the condi- tions for all further phases of the project are identified and determined. Determination of Needs The reason for introducing a software system is the realization that there is a need for a system. The specific reasons for the need for a new software system are very diverse and depend on the area of application of the IT organization. Typical occasions include 41 the replacement of existing legacy systems. business demands. technological evolution. Replacement of existing legacy systems IT systems are subject to aging and therefore have a limited lifespan. After the initial com- missioning, software systems evolve, and they are usually revised and reworked several times, either to correct software errors or add functions to the system. Depending on the lifetime and the frequency of adjustment, the maintenance costs are disproportional to the benefit achieved, so it makes more sense to replace an existing system with a new sys- tem. In addition to the technical aging process, the know-how for the maintenance of existing systems is often unavailable, for example, because the technology used is no lon- ger supported by the manufacturer, or the developers have left the company. Business demands Enterprise software systems play a key role in value-adding processes (particularly in com- panies in the insurance, media, and logistics sectors). Companies in these industries develop competitive advantages using highly specialized software systems. For this rea- son, corporate IT must react quickly to new business requirements and support the busi- ness departments with suitable systems in a targeted manner. If business requirements cannot be covered by existing systems, new software systems must be provided. Technological evolution Continuous technological evolution enables new fields of application and business that must be supported by appropriate IT solutions. Therefore, changing technical constraints also lead to a need for software systems. For example, it was only with the spread of web browsers that the large-scale provision of web applications became possible and thus, location-independent work. Likewise, the spread of smartphones is creating a need for a new class of application, the “apps.” Make-or-Buy Decision After the need for a new software system has been identified, the following questions must be answered: Are software solutions already available that cover the need (e.g., content management systems, e-mail systems, word processing)? Are there standard products that can be customized to company-specific requirements (e.g., SAP Business Suite, Oracle E-Business Suite, IBM WebSphere)? Does new software need to be developed? Make-or-buy decision This is called a make-or-buy decision. Depending on how relevant the required software This is deciding whether is for the company’s business activities and how serious the possible consequences of a an existing system is to be procured or a new system wrong decision are, preliminary studies, test installations, or initial application prototypes is to be developed. are created and tried out as part of a make-or-buy decision. 42 Depending on the result of the make-or-buy decision, more specific time and resource planning takes place. A first project plan is defined up to the introduction, and the required resources are determined and planned. Procurement If a new software system is to be created or a standard solution is to be customized, a cor- responding order must be placed. Whether the order will be carried out by an external service provider or an internal IT department must be decided. If it is a public IT organiza- tion, usually, the contract must be advertised publicly according to each country’s law. In the case of public tenders for the development by external service providers, typical activities from the “development” phase must be carried out in the “planning” phase when the requirements for the new system are determined. To bring about a decision dur- ing hand-over as to whether the service provider fulfills all contractual obligations, the results of the requirements determination must already be documented when the con- tract is awarded. 3.3 Development When the decision has been made that a new system should be created or a standard sol- ution should be customized, the development phase follows. This phase is where all of the constructive activities required from the order to the deployment of the system take place, and the system is implemented. The activities are also summarized under the terms “application development” and “software development.” During the development phase, more people work on the system at the same time than during any other phase. The soft- ware development activities described below are the core activities of software engineer- ing. Requirements Engineering and Specification Based on the broad business requirements determined in the planning, business require- ments are further detailed and refined. This is called requirements engineering. All rele- vant stakeholders of the system are involved. After the business requirements have been determined, the required properties of the system in development are documented by a specification. Software Architecture and Implementation The internal structure of the software system (the software architecture) is determined based on the specification. For this purpose, the needs of the stakeholders are analyzed and weighed against each other, and an architecture definition is developed through sev- eral decisions and design activities. The program code of the system is implemented according to these specifications, and the system is created accordingly. The source code of a system is programmed during implementation, and the system is thus constructed. 43 Quality Assurance All artifacts generated during creation (e.g., software architecture, source code, and test cases) are checked to determine whether they meet specified requirements. Measures and activities for quality assurance are already being carried out during all activities. However, the system can only be tested completely after implementation and integration has been finished. The program code is therefore tested in different test stages, depending on the status of the project. IT organizations often have their own departments (e.g., application development) that are responsible for creating software. After the software has been implemented and tes- ted, it is handed over to the department responsible for operating the system. 3.4 Operation After the development work has been completed, the software system must be deployed in the operational environment and integrated into the existing application landscape. The security and availability of the system must then be guaranteed so that all users can work productively with the system as expected. This phase in the software life cycle is called “operation.” Operational Environment Provisioning During the development phase, many people are busy designing the system at the same time, and the system is not yet involved in a company’s value-adding activities. In the operation phase, this relationship is reversed: Work on the program code is stopped and the system is used intensively by its users. In large companies, systems are used by several thousand users at the same time. If customers or end users are involved (e.g., Amazon, Netflix, Facebook), the system can be operated by as few as ten users, or over one hundred thousand users at the same time. This means that the security risk also increases. The more people that have access to a system via the internet, the greater the risk of system attacks or fraud. In addition, no data should be lost in the event of a hardware failure or the occurrence of a software error. At the same time, the system should be able to cope with load peaks if necessary, but should only use as many resources as it truly needs when operating under normal requirements. The aim in operation is to ensure the application’s quality requirements, such as security, availability, and scalability. This means that the department responsible for operation must provide the appropriate infrastructure, for example, in a data center. Typical ele- ments of this infrastructure are special hardware systems (rack servers), software systems (operating systems, monitoring systems, and virtualization systems), networks (ethernet, WiFi, and mobile), storage systems (databases and backup systems), and security systems (firewall, virus scanner, and cryptography systems). This also includes securing the power supply, air conditioning, and the connection to external networks (internet), as well as user administration and allocation of access rights. 44 In contrast to development, which aims to quickly add functions to software systems, long-term stability must be ensured during operation. This results in a conflict of objec- tives between development and operation. On the one hand, there must be a quick reac- tion to business requirements, but on the other hand, the system should run reliably and safely. Current interdisciplinary approaches, such as development operation (DevOps), address these issues. Integration After development, enterprise software systems must be deployed in the operational envi- ronment. In addition to being installed in that environment, the system must be integra- ted into the application landscape. This means that it must be connected to existing sys- tems using the technical interfaces provided by the developers. For example, an insurance company’s existing system must be connected to the collection and disbursement system so that premium invoices can be sent automatically. Another example is a system for fund management that must be connected to a service providing current exchange and stock exchange rates. CRM systems have to be connected to a system for the automatic valida- tion of addresses. The new system is only connected to other systems in the operational environment after all tests have been completed, so that real data in operational systems are not acciden- tally changed during development Provisioning After the integration is complete, a new system can be put into operation. At this point, all technical interfaces of existing systems must be converted to the new system. For web applications, for example, it must be ensured that entering the uniform resource locator (URL) allows the user to access the new application. To ensure availability and security, the new application must also be connected to techni- cal monitoring systems that continuously provide management with information about resource consumption (central processing unit [CPU], main memory, data storage, and network access). In addition, IT security must include the new application in the list of monitored applications. 3.5 Maintenance When software systems are provisioned for the first time, the development phase has already been concluded. Nevertheless, change requests by the user must also be imple- mented for applications during operation. Necessary changes may include correcting spelling errors in the application interface, importing version and security updates, or adding completely new functions. This phase in the software life cycle is called “mainte- nance.” It includes all activities concerning the management of problems and incidents, as well as the functional evolution of the operational application. 45 Maintenance Upkeep versus Evolution This is the totality of activities required to pro- vide cost-effective sup- Maintenance includes the upkeep and corrective adjustment of software systems, which port to a software system. mainly involves the elimination of detected errors. Enterprise information systems are not perfect when they are delivered. Despite the quality assurance measures, it is to be expec- ted that there will be residual errors in the system. In addition to eliminating errors, adjustments with the aim of better runtime behavior or more economical use of resources are also maintenance tasks. Furthermore, maintenance incorporates the functional evolution of the system. If a soft- ware system is to be expanded with functions, or if functions have to be changed, these are activities for the future development of the system. In the case of a planned system lifetime of ten years or longer, future developments in the design of the system must be considered when creating software. Cross-Cutting Activities Both upkeep and evolution mean that the program code of a system that is already in operation must be changed. This means that activities of the development phase are car- ried out in the maintenance phase. The adapted system must then be put into operation, so activities of the operation phase must also be carried out. After the initial provisioning of a software system, the phases of maintenance and operation alternate in relatively short cycles. In the release plans, dates are given for each application at which an update of the appli- cation will be made available. These plans help with the cooperation of business depart- ments (which have change requests), application development (which implement the change requests), and IT operations (which bring the changed application into productive operation). For software systems, it can be observed that the effort for maintenance over the entire life cycle approximately doubles the effort for creation. With a development effort of 500,000 euros for an application, maintenance costs of one million euros or more can be expected. The actual effort differs greatly from application to application. For periods of 15 years or more, the maintenance costs can be significantly higher than the develop- ment. 3.6 Shutdown At the end of the software life cycle, the application is taken out of service. This final phase in the life cycle is called shutdown or disposal (The International Organization for Stand- ardization, 2017). As part of maintaining the application landscape, IT management decides whether and when an application is to be shut down. Typical reasons for a shut- down include the replacement of existing legacy systems with new systems. 46 the consolidation or standardization of applications when merging IT organizations. giving up business areas or outsourcing activities from the company. Similar to the provisioning, the system and its technical and organizational environment must be taken into account during the shutdown. Removal Since systems within an application landscape are connected to one another via technical interfaces, all dependencies of the application being switched off must be identified and resolved. Every actively used technical interface of the old system must either be covered by a new or existing alternative system. Under certain circumstances, each system connec- ted to the legacy system must be adapted. Particularly in the case of very old systems with obsolete technologies and outdated docu- mentation, the extraction is a critical activity. Technical dependencies must be identified, and the system behavior at the interfaces must be reproduced in the event of a system replacement. The basis for this is usually the system documentation. However, if the docu- mentation is incomplete or outdated, dependencies can only be identified by reverse engineering or testing the system context while the legacy system is detached. If there is no current documentation on the implementation of the function within the leg- acy system, the program code must be analyzed and the behavior of the new system must be specified with the results. However, this requires expert knowledge of the technologies used in the legacy system. Unfortunately, there is a high risk that those knowledgable about the old technologies have already left the company. Data Migration If data are stored in the legacy system, they might be migrated as part of the shutdown. This means that the data in the old system must be transferred to another system for fur- ther use. Unfortunately, systems are getting very old, especially when they are used for the storage and management of company-critical data, for example, the inventory system of life insurance companies or the system for managing bank accounts. One challenge when migrating data is finding an appropriate mapping of the old data schema to the new data schema. Another challenge is the amount of data to be migrated. Even when transfer- ring several million contract data—a number quite common for health or life insurance companies—there must be no mistake. Sometimes it is more economical for the company to dissolve old contracts or to have customers switch to a new contract version by giving them a discount than to migrate the data from the old system to a new system (internet providers, for example, do this). Contract Termination In order to operate a software system, an appropriate operational environment must be provided and maintained. The infrastructure required for the legacy system must be ana- lyzed to determine whether term-based licenses and usage rights have been acquired. There are often application- and user-dependent

Software Engineering Principles PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue