System procurement Software Engineering 9th ed (intro txt) I. Sommerville (Pearson, 2011)

276 Chapter 10 ■ Sociotechnical systems business processes may be advisable. For military systems, the need to improve capability in the face of new threats is an important reason for procuring new systems. 4. Business reorganization Businesses and other organizations frequently restruc- ture with the intention of improving efficiency andor customer service. Reorganizations lead to changes in business processes that require new systems support. 5. Available budget The budget available is an obvious factor in determining the scope of new systems that can be procured. In addition, new government systems are often procured to reflect political changes and political policies. For example, politicians may decide to buy new sur- veillance systems, which they claim will counter terrorism. Buying such systems shows voters that they are taking action. However, such systems are often procured without a cost-benefit analysis, where the benefits that result from different spending options are compared. Large, complex systems usually consist of a mixture of off-the-shelf and specially built components. One reason why more and more software is included in systems is that it allows more use of existing hardware components, with the software acting as ‘glue’ to make these hardware components work together effectively. The need to develop this ‘glueware’ is one reason why the savings from using off-the-shelf com- ponents are sometimes not as great as anticipated. Figure 10.6 shows a simplified model of the procurement process for both COTS system components and system components that have to be specially designed and developed. Important points about the process shown in this diagram are: 1. Off-the-shelf components do not usually match requirements exactly, unless the requirements have been written with these components in mind. Therefore, choosing a system means that you have to find the closest match between the system requirements and the facilities offered by off-the-shelf systems. You may then have to modify the requirements. This can have knock-on effects on other subsystems. Figure 10.6 System procurement processes Off-the-Shelf System Available Custom System Required Define Business Requirements Survey Market for Existing Systems Adapt Requirements Define Requirements Issue Request to Tender Select Tender Assess Existing Systems Choose System Supplier Negotiate Contract 10.3 ■ System procurement 277 2. When a system is to be built specially, the specification of requirements is part of the contract for the system being acquired. It is therefore a legal as well as a technical document. 3. After a contractor has been selected, to build a system, there is a contract nego- tiation period where you may have to negotiate further changes to the require- ments and discuss issues such as the cost of changes to the system. Similarly, once a COTS system has been selected, you may negotiate with the supplier on costs, licence conditions, possible changes to the system, etc. The software and hardware in sociotechnical systems are usually developed by a different organization the supplier from the organization that is procuring the overall sociotechnical system. The reason for this is that the customer’s business is rarely software development so its employees do not have the skills needed to develop the systems themselves. In fact, very few companies have the capabilities to design, manufacture, and test all the components of a large, complex sociotech- nical system. Consequently, the system supplier, who is usually called the principal contractor, often contracts out the development of different subsystems to a number of subcon- tractors. For large systems, such as air traffic control systems, a group of suppliers may form a consortium to bid for the contract. The consortium should include all of the capabilities required for this type of system. This includes computer hardware suppliers, software developers, peripheral suppliers, and suppliers of specialist equipment such as radar systems. The procurer deals with the contractor rather than the subcontractors so that there is a single procurersupplier interface. The subcontractors design and build parts of the system to a specification that is produced by the principal contractor. Once com- pleted, the principal contractor integrates these different components and delivers them to the customer. Depending on the contract, the procurer may allow the princi- pal contractor a free choice of subcontractors or may require the principal contractor to choose subcontractors from an approved list. Decisions and choices made during system procurement have a profound effect on the security and dependability of a system. For example, if a decision is made to procure an off-the-shelf system, then the organization has to accept that they have very limited influence over the security and dependability requirements of this sys- tem. These largely depend on decisions made by system vendors. In addition, off-the- shelf systems may have known security weaknesses or require complex configuration. Configuration errors, where entry points to the system are not properly secured, are a major source of security problems. On the other hand, a decision to procure a custom system means that significant effort must be devoted to understanding and defining security and dependability requirements. If a company has limited experience in this area, this is quite a difficult thing to do. If the required level of dependability as well as acceptable system per- formance is to be achieved, then the development time may have to be extended and the budget increased. 278 Chapter 10 ■ Sociotechnical systems

10.4 System development

The goals of the system development process are to develop or acquire all of the components of a system and then to integrate these components to create the final system. The requirements are the bridge between the procurement and the develop- ment processes. During procurement, business and high-level functional and non- functional system requirements are defined. You can think of this as the start of development, hence the overlapping processes shown in Figure 10.4. Once contracts for the system components have been agreed, more detailed requirements engineer- ing then takes place. Figure 10.7 is a model of the systems development process. This systems engi- neering process was an important influence on the ‘waterfall’ model of the software process that I discussed in Chapter 2. Although it is now accepted that the ‘waterfall’ model is not usually appropriate for software development, most systems develop- ment processes are plan-driven processes that still follow this model. Plan-driven processes are used in systems engineering because different parts of the system are being developed at the same time. For systems that include hardware and other equipment, changes during development can be very expensive or, some- times, practically impossible. It is essential therefore, that the system requirements are fully understood before hardware development or building work begins. Reworking the system design to solve hardware problems is rarely possible. For this reason, more and more system functionality is being assigned to the system soft- ware. This allows some changes to be made during system development, in response to new system requirements that inevitably arise. One of the most confusing aspects of systems engineering is that companies use different terminology for each stage of the process. The process structure also varies. Sometimes, requirements engineering is part of the development process and some- times it is a separate activity. However, there are essentially six fundamental activities in systems development: 1. Requirements development The high-level and business requirements identified during the procurement process have to be developed in more detail. Requirements may have to be allocated to hardware, software, or processes and prioritized for implementation. Subsystem Engineering System Design Requirements Development System Deployment System Testing System Integration Figure 10.7 Systems development 10.4 ■ System development 279