1 Introduction

Objectives

The objectives of this chapter are to introduce software engineering and to provide a framework for understanding the rest of the book. When you have read this chapter, you will:

■ understand what software engineering is and why it is important;

■ understand that the development of different types of software system may require different software engineering techniques;

■ understand ethical and professional issues that are important for software engineers;

■ have been introduced to four systems, of different types, which are used as examples throughout the book.

이 장의 목적은 소프트웨어 공학을 소개하고 책의 나머지 부분을 이해하기 위한 틀을 제공하는 것이다. 이 장을 읽으면 다음과 같이 된다.

■ 소프트웨어 엔지니어링이 무엇이며 중요한 이유를 이해한다.

■ 다양한 유형의 소프트웨어 시스템을 개발하려면 다른 소프트웨어 엔지니어링 기법이 필요할 수 있음을 이해한다.

■ 소프트웨어 엔지니어에게 중요한 윤리적 및 전문적 이슈 이해

■ 책 전반에 걸쳐 예시로 쓰이는 다양한 유형의 네 가지 시스템에 도입되었다.

Contents

1.1 Professional software development

1.2 Software engineering ethics

1.3 Case studies

1.1 전문 소프트웨어 개발

1.2 소프트웨어 엔지니어링 윤리

1.3 사례 연구

Software engineering is essential for the functioning of government, society, and national and international businesses and institutions. We can’t run the modern world without software. National infrastructures and utilities are controlled by computer-based systems, and most electrical products include a computer and controlling software. Industrial manufacturing and distribution is completely computerized, as is the financial system. Entertainment, including the music industry, computer games, and film and television, is software-intensive. More than 75% of the world’s population have a software-controlled mobile phone, and, by 2016, almost all of these will be Internet-enabled.

Software systems are abstract and intangible. They are not constrained by the prop- erties of materials, nor are they governed by physical laws or by manufacturing pro- cesses. This simplifies software engineering, as there are no natural limits to the potential of software. However, because of the lack of physical constraints, software systems can quickly become extremely complex, difficult to understand, and expensive to change.

There are many different types of software system, ranging from simple embed- ded systems to complex, worldwide information systems. There are no universal notations, methods, or techniques for software engineering because different types of software require different approaches. Developing an organizational information system is completely different from developing a controller for a scientific instru- ment. Neither of these systems has much in common with a graphics-intensive com- puter game. All of these applications need software engineering; they do not all need the same software engineering methods and techniques.

There are still many reports of software projects going wrong and of “software failures.” Software engineering is criticized as inadequate for modern software development. However, in my opinion, many of these so-called software failures are a consequence of two factors:

소프트웨어 공학은 정부, 사회, 국내외 기업 및 기관의 기능을 위해 필수적이다. 소프트웨어 없이는 현대 세계를 운영할 수 없다. 국가 기반 시설과 유틸리티는 컴퓨터 기반 시스템에 의해 제어되며, 대부분의 전기 제품에는 컴퓨터와 제어 소프트웨어가 포함된다. 산업 제조와 유통은 금융 시스템과 마찬가지로 완전히 전산화된다. 음악 산업, 컴퓨터 게임, 영화와 텔레비전을 포함한 엔터테인먼트는 소프트웨어 집약적이다. 세계 인구의 75% 이상이 소프트웨어로 제어되는 휴대폰을 가지고 있으며, 2016년까지 거의 모든 것이 인터넷이 가능하게 될 것이다.

소프트웨어 시스템은 추상적이고 무형의 것이다. 그들은 재료의 제공에 구속되지 않으며, 물리법칙이나 제조법규에 의해 지배되지 않는다. 이것은 소프트웨어의 잠재력에 자연적인 제한이 없기 때문에 소프트웨어 공학을 단순화한다. 그러나 물리적 제약조건이 없기 때문에 소프트웨어 시스템은 빠르게 극도로 복잡해지고 이해하기 어렵고 변경 비용이 많이 들 수 있다.

단순한 내장형 시스템에서부터 복잡하고 전 세계적인 정보 시스템에 이르기까지 다양한 유형의 소프트웨어 시스템이 존재한다. 서로 다른 유형의 소프트웨어가 다른 접근방식을 요구하기 때문에 소프트웨어 엔지니어링에는 보편적인 표기법, 방법 또는 기법이 없다. 조직 정보 시스템의 개발은 과학적 근거를 위한 제어장치를 개발하는 것과는 완전히 다르다. 이 두 시스템 중 어느 것도 그래픽 집약적인 콤퍼 게임과 공통점이 별로 없다. 이 모든 어플리케이션들은 소프트웨어 공학을 필요로 한다; 그들은 모두 같은 소프트웨어 공학의 방법과 기술을 필요로 하지 않는다.

여전히 소프트웨어 프로젝트가 잘못되고 “소프트웨어 고장”에 대한 많은 보고가 있다. 소프트웨어 공학은 현대 소프트웨어 개발에 부적합하다는 비판을 받고 있다. 그러나, 내 생각에, 이러한 소위 소프트웨어 실패의 상당수는 다음의 두 가지 요인의 결과물이다.

1. Increasing system complexity: As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; and systems have to have new capabilities that were previously thought to be impossible. New software engineering techniques have to be developed to meet new the challenges of delivering more complex software.

2. Failure to use software engineering methods: It is fairly easy to write computer programs without using software engineering methods and techniques. Many companies have drifted into software development as their products and ser- vices have evolved. They do not use software engineering methods in their every- day work. Consequently, their software is often more expensive and less reliable than it should be. We need better software engineering education and training to address this problem.

3. 시스템 복잡성 증가: 새로운 소프트웨어 엔지니어링 기법이 우리가 더 크고 더 복잡한 시스템을 구축하는 데 도움을 줄수록 수요는 변화한다. 시스템은 더 빨리 구축되고 전달되어야 하고, 더 크고, 더 복잡한 시스템이 요구되어야 하며, 시스템은 이전에는 불가능하다고 생각되었던 새로운 기능을 가져야 한다. 새로운 소프트웨어 엔지니어링 기법은 더 복잡한 소프트웨어를 제공하는 새로운 도전에 대처하기 위해 개발되어야 한다.

4. 소프트웨어 엔지니어링 방법 사용 실패: 소프트웨어 엔지니어링 방법 및 기법을 사용하지 않고 컴퓨터 프로그램을 작성하는 것은 상당히 쉽다. 많은 회사들이 그들의 제품과 서비스가 진화하면서 소프트웨어 개발에 뛰어들었다. 그들은 일상 업무에서 소프트웨어 공학 방법을 사용하지 않는다. 결과적으로, 그들의 소프트웨어는 종종 더 비싸고 신뢰성이 떨어진다. 우리는 이 문제를 해결하기 위해 더 나은 소프트웨어 엔지니어링 교육과 훈련이 필요하다.

Software engineers can be rightly proud of their achievements. Of course, we still have problems developing complex software, but without software engineering we would not have explored space and we would not have the Internet or modern tele- communications. All forms of travel would be more dangerous and expensive. Challenges for humanity in the 21st century are climate change, fewer natural resources, changing demographics, and an expanding world population. We will rely on software engineering to develop the systems that we need to cope with these issues.

소프트웨어 엔지니어들은 당연히 그들의 업적을 자랑스러워 할 수 있다. 물론, 우리는 여전히 복잡한 소프트웨어를 개발하는 데 문제가 있지만, 소프트웨어 공학이 없었다면 우리는 공간을 탐험하지 못했을 것이고 인터넷이나 현대 텔레커뮤니케이션도 하지 않았을 것이다. 모든 형태의 여행은 더 위험하고 비쌀 것이다. 21세기의 인류에 대한 도전은 기후 변화, 천연자원의 감소, 인구통계 변화, 그리고 세계인구의 팽창이다. 우리는 소프트웨어 공학에 의존해서 우리가 이러한 문제들에 대처하기 위해 필요한 시스템을 개발할 것이다.

History of software engineering

The notion of software engineering was first proposed in 1968 at a conference held to discuss what was then called the software crisis (Naur and Randell 1969). It became clear that individual approaches to program devel- opment did not scale up to large and complex software systems. These were unreliable, cost more than expected, and were delivered late.

Throughout the 1970s and 1980s, a variety of new software engineering techniques and methods were developed, such as structured programming, information hiding, and object-oriented development. Tools and standard notations were developed which are the basis of today’s software engineering.

소프트웨어 공학의 역사

소프트웨어 공학의 개념은 1968년 당시 소프트웨어 위기(Naur and Randell 1969)라고 불리던 것을 논의하기 위해 열린 회의에서 처음 제안되었다. 프로그램 개발에 대한 개별 접근방식이 크고 복잡한 소프트웨어 시스템까지 확장되지 않았다는 것이 명백해졌다. 이것들은 믿을 수 없고, 예상보다 비용이 많이 들고, 늦게 배달되었다.

1970년대와 1980년대 내내, 구조화된 프로그래밍, 정보 은닉, 객체지향적 개발 등 다양한 새로운 소프트웨어 엔지니어링 기술과 방법이 개발되었다. 도구와 표준 표기법은 오늘날의 소프트웨어 공학의 기초가 된다.

http://software-engineering-book.com/web/history/

1.1 전문 소프트웨어 개발(Professional software development)

Lots of people write programs. People in business write spreadsheet programs to simplify their jobs; scientists and engineers write programs to process their experi- mental data; hobbyists write programs for their own interest and enjoyment. However, most software development is a professional activity in which software is developed for business purposes, for inclusion in other devices, or as software prod- ucts such as information systems and computer-aided design systems. The key dis- tinctions are that professional software is intended for use by someone apart from its developer and that teams rather than individuals usually develop the software. It is maintained and changed throughout its life.

Software engineering is intended to support professional software development rather than individual programming. It includes techniques that support program specification, design, and evolution, none of which are normally relevant for per- sonal software development. To help you to get a broad view of software engineer- ing, I have summarized frequently asked questions about the subject in Figure 1.1.

Many people think that software is simply another word for computer programs. However, when we are talking about software engineering, software is not just the programs themselves but also all associated documentation, libraries, support web- sites, and configuration data that are needed to make these programs useful. A pro- fessionally developed software system is often more than a single program. A system may consist of several separate programs and configuration files that are used to set up these programs. It may include system documentation, which describes the struc- ture of the system, user documentation, which explains how to use the system, and websites for users to download recent product information.

This is one of the important differences between professional and amateur soft- ware development. If you are writing a program for yourself, no one else will use it

많은 사람들이 프로그램을 작성한다. 비즈니스에 종사하는 사람들은 일을 단순화하기 위해 스프레드시트 프로그램을 작성하고, 과학자들과 엔지니어들은 그들의 경험적 데이터를 처리하기 위한 프로그램을 작성하며, 취미 활동가들은 그들 자신의 흥미와 즐거움을 위해 프로그램을 작성한다. 그러나, 대부분의 소프트웨어 개발은 소프트웨어를 사업 목적으로, 다른 기기에 포함시키기 위해, 또는 정보 시스템이나 컴퓨터 보조 설계 시스템과 같은 소프트웨어 prod- uct로 개발하는 전문적인 활동이다. 중요한 단점은 전문 소프트웨어는 개발자와는 별개로 누군가가 사용하기 위한 것이며 개인보다는 팀이 소프트웨어를 개발한다는 것이다. 그것은 일생 동안 유지되고 변화된다.

소프트웨어 엔지니어링은 개별 프로그래밍보다는 전문적인 소프트웨어 개발을 지원하기 위한 것이다. 여기에는 프로그램 사양, 설계 및 진화를 지원하는 기법이 포함되며, 일반적으로 개인적인 소프트웨어 개발에 관련된 기법은 없다. 소프트웨어 엔지니어를 폭넓게 볼 수 있도록 돕기 위해, 나는 그림 1.1에 주제에 대한 자주 묻는 질문을 요약했다.

많은 사람들은 소프트웨어가 단순히 컴퓨터 프로그램의 다른 단어라고 생각한다. 그러나 우리가 소프트웨어 공학에 대해 이야기할 때, 소프트웨어는 프로그램 자체뿐만 아니라 이러한 프로그램을 유용하게 만드는 데 필요한 모든 관련 문서, 라이브러리, 지원 웹 사이트 및 구성 데이터도 된다. 전문적으로 개발된 소프트웨어 시스템은 종종 단일 프로그램 이상이다. 시스템은 이러한 프로그램을 설정하는 데 사용되는 몇 개의 개별 프로그램과 구성 파일로 구성될 수 있다. 여기에는 시스템의 구성을 설명하는 시스템 설명서, 시스템 사용 방법을 설명하는 사용자 설명서 및 사용자가 최신 제품 정보를 다운로드할 수 있는 웹 사이트가 포함될 수 있다.

이것은 프로와 아마추어 소프트웨어 개발의 중요한 차이점 중 하나이다. 당신이 스스로 프로그램을 쓰고 있다면, 아무도 그것을 사용하지 않을 것이다.

Question Answer

What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.

What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.

What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production from initial conception to operation and maintenance.

What are the fundamental software engineering activities? Software specification, software development, software validation and software evolution.

What is the difference between software engineering and computer science? Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.

What are the key challenges facing software engineering? Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software.

What are the costs of software engineering? Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

What are the best software engineering techniques and methods? While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. There are no methods and techniques that are good for everything.

What differences has the Internet made to software engineering? Not only has the Internet led to the development of massive, highly distributed, service-based systems, it has also supported the creation of an “app” industry for mobile devices which has changed the economics of software.

소프트웨어란 무엇인가? 컴퓨터 프로그램 및 관련 문서. 소프트웨어 제품은 특정 고객을 위해 개발되거나 일반 시장을 위해 개발될 수 있다.

좋은 소프트웨어의 속성은 무엇인가? 우수한 소프트웨어는 사용자에게 필요한 기능 및 성능을 제공해야 하며 유지보수가 가능하고 신뢰할 수 있어야 하며 사용할 수 있어야 한다.

소프트웨어 엔지니어링이란 무엇인가? 소프트웨어 엔지니어링(Software Engineering)은 초기 구상부터 운영 및 유지관리에 이르기까지 소프트웨어 생산의 모든 측면과 관련된 공학 분야다.

기본적인 소프트웨어 엔지니어링 액티비티는 무엇인가? 소프트웨어 사양, 소프트웨어 개발, 소프트웨어 검증 및 소프트웨어 진화.

소프트웨어 공학과 컴퓨터 과학의 차이점은 무엇인가? 컴퓨터 과학은 이론과 기초에 초점을 맞추고 있다; 소프트웨어 공학은 유용한 소프트웨어를 개발하고 전달하는 것의 실용성과 관련이 있다.

소프트웨어 엔지니어링과 시스템 엔지니어링의 차이점은 무엇인가? 시스템 엔지니어링은 하드웨어, 소프트웨어, 프로세스 엔지니어링을 포함한 컴퓨터 기반 시스템 개발의 모든 측면과 관련이 있다. 소프트웨어 공학은 보다 일반적인 과정의 일부분이다.

소프트웨어 엔지니어링이 직면한 주요 과제는 무엇인가? 다양성 증가에 대응하여 배송 시간 단축 및 신뢰할 수 있는 소프트웨어 개발.

소프트웨어 공학의 비용은 얼마인가? 소프트웨어 비용의 대략 60%는 개발 비용이고 40%는 시험 비용이다. 사용자 정의 소프트웨어의 경우, 진화 비용은 종종 개발 비용을 초과한다.

최고의 소프트웨어 엔지니어링 기술과 방법은 무엇인가? 모든 소프트웨어 프로젝트는 전문적으로 관리되고 개발되어야 하지만, 다른 종류의 시스템에는 다른 기법이 적합하다. 예를 들어 게임은 항상 일련의 프로토타입을 사용하여 개발되어야 하는 반면, 안전 중요 제어 시스템은 완전하고 분석 가능한 사양을 개발해야 한다. 모든 것에 좋은 방법과 기술은 없다.

인터넷이 소프트웨어 공학에 어떤 차이를 만들어냈는가? 인터넷은 대규모의 고도로 분산된 서비스 기반 시스템의 개발을 이끌었을 뿐만 아니라, 소프트웨어의 경제성을 변화시킨 모바일 장치를 위한 “앱” 산업의 창설을 지원했다.

[Figure 1.1 Frequently asked questions about software engineering]

and you don’t have to worry about writing program guides, documenting the pro- gram design, and so on. However, if you are writing software that other people will use and other engineers will change, then you usually have to provide additional information as well as the code of the program.

Software engineers are concerned with developing software products, that is, software that can be sold to a customer. There are two kinds of software product:

프로그램 가이드 작성, 프로그람 디자인 문서화 등에 대해 걱정할 필요가 없다. 그러나 다른 사람이 사용할 소프트웨어를 작성하고 다른 엔지니어가 변경될 경우 대개 프로그램의 코드뿐만 아니라 추가 정보를 제공해야 한다.

소프트웨어 엔지니어들은 소프트웨어 제품, 즉 고객에게 판매할 수 있는 소프트웨어를 개발하는 것에 관심이 있다. 소프트웨어 제품에는 두 가지 종류가 있다.

1. Generic products These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Examples of this type of product include apps for mobile devices, software for PCs such as databases, word processors, drawing packages, and project management tools. This kind of software also includes “vertical” applications designed for a specific market such as library information systems, accounting systems, or systems for maintaining dental records.

2. Customized (or bespoke) software These are systems that are commissioned by and developed for a particular customer. A software contractor designs and implements the software especially for that customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process, and air traffic control systems.

3. 일반 상품 이것들은 개발 조직이 생산하여 그것을 구입할 수 있는 어떤 고객에게도 공개 시장에서 판매하는 독립형 시스템이다. 이러한 유형의 제품으로는 모바일 기기용 앱, 데이터베이스, 워드 프로세서, 도면 패키지, 프로젝트 관리 도구 등의 PC용 소프트웨어 등이 있다. 이러한 종류의 소프트웨어는 또한 도서관 정보 시스템, 회계 시스템 또는 치과 기록의 유지를 위한 시스템과 같은 특정 시장을 위해 설계된 “수직” 애플리케이션을 포함한다.

4. 맞춤형(또는 맞춤형) 소프트웨어 이것들은 특정 고객을 위해 의뢰하고 개발되는 시스템이다. 소프트웨어 계약자는 특히 그 고객을 위해 소프트웨어를 설계하고 구현한다. 이러한 유형의 소프트웨어에는 전자 장치용 제어 시스템, 특정 업무 프로세스를 지원하기 위해 작성된 시스템 및 항공 교통 관제 시스템이 포함된다.

The critical distinction between these types of software is that, in generic prod- ucts, the organization that develops the software controls the software specification. This means that if they run into development problems, they can rethink what is to be developed. For custom products, the specification is developed and controlled by the organization that is buying the software. The software developers must work to that specification.

However, the distinction between these system product types is becoming increas- ingly blurred. More and more systems are now being built with a generic product as a base, which is then adapted to suit the requirements of a customer. Enterprise Resource Planning (ERP) systems, such as systems from SAP and Oracle, are the best examples of this approach. Here, a large and complex system is adapted for a company by incorporating information about business rules and processes, reports required, and so on.

When we talk about the quality of professional software, we have to consider that the software is used and changed by people apart from its developers. Quality is therefore not just concerned with what the software does. Rather, it has to include the software’s behavior while it is executing and the structure and organization of the sys- tem programs and associated documentation. This is reflected in the software’s qual- ity or non-functional attributes. Examples of these attributes are the software’s response time to a user query and the understandability of the program code.

The specific set of attributes that you might expect from a software system obvi- ously depends on its application. Therefore, an aircraft control system must be safe, an interactive game must be responsive, a telephone switching system must be reliable, and so on. These can be generalized into the set of attributes shown in Figure 1.2, which I think are the essential characteristics of a professional software system.

이러한 유형의 소프트웨어 간에 중요한 차이는 일반적인 prod- uct에서 소프트웨어를 개발하는 조직이 소프트웨어 사양을 통제한다는 것이다. 개발 문제에 부닥치면 무엇을 개발해야 할지 재고할 수 있다는 얘기다. 사용자 정의 제품의 경우, 그 사양은 소프트웨어를 구입하는 조직에 의해 개발되고 제어된다. 소프트웨어 개발자는 반드시 그 규격에 따라 작업해야 한다.

그러나 이러한 시스템 제품 유형의 구별은 점점 모호해지고 있다. 이제는 일반 제품을 기반으로 하여 점점 더 많은 시스템이 구축되고 있으며, 이는 고객의 요구 사항에 맞게 조정된다. SAP 및 Oracle의 시스템과 같은 ERP(Enter Enterprise Resource Planning) 시스템이 이 접근 방식의 가장 좋은 예다. 여기서, 비즈니스 규칙과 프로세스, 필요한 보고서 등에 관한 정보를 통합하여 기업에 맞게 크고 복잡한 시스템을 개조한다.

우리가 전문적인 소프트웨어의 품질에 대해 이야기할 때, 우리는 소프트웨어가 개발자들과는 별개로 사람들에 의해 사용되고 변화된다는 것을 고려해야 한다. 그러므로 품질은 소프트웨어가 하는 일에만 관계되는 것이 아니다. 오히려 실행 중인 소프트웨어의 동작과 시스템 및 관련 문서의 구조와 구성을 포함해야 한다. 이는 소프트웨어의 기능적 특성과 비기능적 속성에 반영된다. 이러한 속성의 예로는 사용자 쿼리에 대한 소프트웨어의 응답 시간과 프로그램 코드의 이해가능성이 있다.

일반적으로 소프트웨어 시스템에서 기대할 수 있는 특성의 세트는 응용 프로그램에 따라 달라진다. 따라서 항공기 제어 시스템은 안전해야 하고, 상호작용 게임은 반응해야 하며, 전화 교환 시스템은 신뢰할 수 있어야 한다. 이것들은 그림 1.2에 나타낸 속성 집합으로 일반화할 수 있는데, 전문 소프트웨어 시스템의 본질적인 특징이라고 생각한다.

1.1.1 소프트웨어 엔지니어링(Software engineering)

Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:

소프트웨어 엔지니어링(Software Engineering)은 시스템 사양 초기 단계부터 시스템 사용 후 유지에 이르기까지 소프트웨어 생산의 모든 측면에 관계하는 공학 분야다. 이 정의에는 다음과 같은 두 가지 핵심 문구가 있다.

1. Engineering discipline Engineers make things work. They apply theories, meth- ods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no appli- cable theories and methods. Engineers also recognize that they must work within organizational and financial constraints, and they must look for solutions within these constraints.

2. All aspects of software production Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software development.

3. 공학 훈련 기술자들은 일을 잘하게 만든다. 그들은 이론, 필로폰, 그리고 이것들이 적절한 곳에 도구를 적용한다. 그러나 그들은 그것들을 선택적으로 사용하고, 케이블 이론과 방법이 없을 때에도 항상 문제에 대한 해결책을 찾으려고 노력한다. 엔지니어들은 또한 그들이 조직적, 재정적 제약 안에서 일해야 하고, 그들은 이러한 제약 안에서 해결책을 찾아야 한다는 것을 인식한다.

4. 소프트웨어 생산 소프트웨어 엔지니어링의 모든 측면은 소프트웨어 개발의 기술적 프로세스에만 관계되는 것이 아니다. 소프트웨어 프로젝트 관리, 소프트웨어 개발을 지원하기 위한 도구, 방법, 이론의 개발 등의 활동도 포함한다.

[Figure 1.2 Essential attributes of good software]

Engineering is about getting results of the required quality within schedule and budget. This often involves making compromises—engineers cannot be perfection- ists. People writing programs for themselves, however, can spend as much time as they wish on the program development.

In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. However, engineering is all about selecting the most appropriate method for a set of circumstances, so a more creative, less formal approach to development may be the right one for some kinds of software. A more flexible software process that accom- modates rapid change is particularly appropriate for the development of interactive web-based systems and mobile apps, which require a blend of software and graphi- cal design skills.

Software engineering is important for two reasons:

엔지니어링은 일정과 예산 내에서 필요한 품질의 결과를 얻는 것이다. 이것은 종종 타협을 수반한다. 엔지니어들은 완벽할 수 없다. 하지만, 스스로 프로그램을 작성하는 사람들은 프로그램 개발에 그들이 원하는 만큼 많은 시간을 쓸 수 있다.

일반적으로 소프트웨어 엔지니어는 자신의 작업에 대해 체계적이고 조직적인 접근방식을 채택하는데, 이는 종종 고품질 소프트웨어를 생산하기 위한 가장 효과적인 방법이기 때문이다. 그러나 공학은 일련의 상황에 가장 적합한 방법을 선택하는 것이 전부이므로, 개발에 대한 좀 더 창의적이고 덜 형식적인 접근이 어떤 종류의 소프트웨어에 적합한 방법이 될 수 있다. 신속한 변화를 수용하는 보다 유연한 소프트웨어 프로세스는 소프트웨어와 그래피칼 설계 기술이 혼합된 인터랙티브 웹 기반 시스템과 모바일 앱 개발에 특히 적합하다.

소프트웨어 엔지니어링은 두 가지 이유로 중요하다.

1. More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly.

2. It is usually cheaper, in the long run, to use software engineering methods and techniques for professional software systems rather than just write programs as

3. 개인과 사회는 점점 더 진보된 소프트웨어 시스템에 의존한다. 우리는 믿을 수 있고 믿을 수 있는 시스템을 경제적으로 그리고 빠르게 생산할 수 있어야 한다.

4. 프로그램을 단순히 로 작성하는 것보다 장기적으로 전문 소프트웨어 시스템에 소프트웨어 엔지니어링 방법과 기술을 사용하는 것이 보통 더 저렴하다.

a personal programming project. Failure to use software engineering method leads to higher costs for testing, quality assurance, and long-term maintenance.

개인 프로그래밍 프로젝트 소프트웨어 엔지니어링 방법을 사용하지 않으면 테스트, 품질 보증 및 장기 유지 보수 비용이 증가하게 된다.

The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product. Four fundamental activities are common to all software processes.

소프트웨어 공학에 이용되는 체계적인 접근방식을 소프트웨어 프로세스라고 부르기도 한다. 소프트웨어 프로세스는 소프트웨어 제품의 생산으로 이어지는 일련의 활동이다. 모든 소프트웨어 프로세스에는 네 가지 기본 활동이 공통적이다.

1. Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.

2. Software development, where the software is designed and programmed.

3. Software validation, where the software is checked to ensure that it is what the customer requires.

4. Software evolution, where the software is modified to reflect changing customer and market requirements.

5. 소프트웨어 사양, 고객과 엔지니어가 생산해야 할 소프트웨어와 그 운용상의 제약조건을 규정하는 소프트웨어 사양.

6. 소프트웨어를 설계하고 프로그래밍하는 소프트웨어 개발.

7. 소프트웨어 검증(Software Validation), 고객이 요구하는 사항인지 확인하기 위해 소프트웨어를 점검하는 위치.

8. 소프트웨어 진화 - 변화하는 고객 및 시장 요구 사항을 반영하기 위해 소프트웨어를 수정한다.

Different types of systems need different development processes, as I explain in Chapter 2. For example, real-time software in an aircraft has to be completely speci- fied before development begins. In e-commerce systems, the specification and the program are usually developed together. Consequently, these generic activities may be organized in different ways and described at different levels of detail, depending on the type of software being developed.

Software engineering is related to both computer science and systems engineering.

내가 2장에서 설명했듯이, 다른 유형의 시스템들은 다른 개발 과정을 필요로 한다. 예를 들어 항공기의 실시간 소프트웨어는 개발이 시작되기 전에 완전히 구체화되어야 한다. 전자상거래 시스템에서는 대개 사양과 프로그램이 함께 개발된다. 결과적으로, 이러한 일반적인 활동은 개발되는 소프트웨어의 유형에 따라 다른 방식으로 구성될 수 있고 다른 수준의 세부사항으로 기술될 수 있다.

소프트웨어 공학은 컴퓨터 공학과 시스템 공학과 관련이 있다.

1. Computer science is concerned with the theories and methods that underlie computers and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of com- puter science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers. Computer science theory, however, is often most applicable to relatively small programs. Elegant theories of computer science are rarely relevant to large, complex problems that require a software solution.

2. System engineering is concerned with all aspects of the development and evolu- tion of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design, and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system.

3. 컴퓨터 과학은 컴퓨터와 소프트웨어 시스템의 기초가 되는 이론과 방법들에 관심이 있는 반면, 소프트웨어 공학은 소프트웨어 생산의 실질적인 문제들에 관심을 갖는다. 물리학에 대한 약간의 지식은 전기 공학자들에게 필수적인 것과 같은 방식으로 소프트웨어 공학자들에게 필수적이다. 그러나 컴퓨터 과학 이론은 종종 비교적 작은 프로그램에 가장 적용된다. 컴퓨터 과학에 대한 우세한 이론은 소프트웨어 솔루션이 필요한 크고 복잡한 문제와 거의 관련이 없다.

4. 시스템 엔지니어링은 소프트웨어가 중요한 역할을 하는 복잡한 시스템의 개발 및 진화의 모든 측면과 관련이 있다. 그러므로 시스템 엔지니어링은 소프트웨어 엔지니어링뿐만 아니라 하드웨어 개발, 정책 및 프로세스 설계 및 시스템 구축에 관한 것이다. 시스템 엔지니어들은 시스템을 명시하고, 그것의 전체적인 구조를 정의한 다음, 완성된 시스템을 만들기 위해 다른 부분들을 통합하는 일에 관여한다.

As I discuss in the next section, there are many different types of software. There are no universal software engineering methods or techniques that may be used. However, there are four related issues that affect many different types of software:

다음 섹션에서 논의했듯이, 많은 종류의 소프트웨어가 있다. 사용될 수 있는 보편적인 소프트웨어 엔지니어링 방법이나 기법은 없다. 그러나 많은 다른 유형의 소프트웨어에 영향을 미치는 4가지 관련 문제가 있다.

1. Heterogeneity Increasingly, systems are required to operate as distributed sys- tems across networks that include different types of computer and mobile devices. As well as running on general-purpose computers, software may also have to execute on mobile phones and tablets. You often have to integrate new software with older legacy systems written in different programming languages. The challenge here is to develop techniques for building dependable software that is flexible enough to cope with this heterogeneity.

2. Business and social change Businesses and society are changing incredibly quickly as emerging economies develop and new technologies become availa- ble. They need to be able to change their existing software and to rapidly develop new software. Many traditional software engineering techniques are time consuming, and delivery of new systems often takes longer than planned. They need to evolve so that the time required for software to deliver value to its customers is reduced.

3. Security and trust As software is intertwined with all aspects of our lives, it is essential that we can trust that software. This is especially true for remote soft- ware systems accessed through a web page or web service interface. We have to make sure that malicious users cannot successfully attack our software and that information security is maintained.

4. Scale Software has to be developed across a very wide range of scales, from very small embedded systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community.

5. 이기성 점차적으로, 시스템은 다른 종류의 컴퓨터와 모바일 기기를 포함하는 네트워크 전체에 분산된 시스템으로서 작동되어야 한다. 소프트웨어는 범용 컴퓨터에서 실행될 뿐만 아니라 휴대전화와 태블릿에서도 실행되어야 할 수 있다. 당신은 종종 새로운 소프트웨어를 다른 프로그래밍 언어로 쓰여진 오래된 레거시 시스템과 통합해야 한다. 여기서 당면한 과제는 이러한 이질성에 충분히 대처할 수 있을 만큼 유연한 신뢰할 수 있는 소프트웨어를 구축하는 기술을 개발하는 것이다.

6. 신흥국들이 발전하고 새로운 기술이 이용 가능하게 되면서 기업과 사회는 믿을 수 없을 정도로 빠르게 변화하고 있다. 그들은 기존의 소프트웨어를 바꿀 수 있어야 하고 새로운 소프트웨어를 빠르게 개발할 수 있어야 한다. 많은 전통적인 소프트웨어 공학 기술은 시간이 많이 소요되며, 새로운 시스템의 전달은 종종 계획보다 더 오래 걸린다. 그들은 소프트웨어가 고객에게 가치를 전달하는 데 필요한 시간을 줄일 수 있도록 진화할 필요가 있다.

7. 보안과 신뢰 소프트웨어는 우리 삶의 모든 측면과 얽혀 있기 때문에, 우리가 그 소프트웨어를 믿을 수 있는 것은 필수적이다. 특히 웹 페이지나 웹 서비스 인터페이스를 통해 액세스하는 원격 소프트웨어 시스템의 경우 그러하다. 악의적인 사용자가 우리의 소프트웨어를 성공적으로 공격할 수 없도록 하고 정보보안이 유지되도록 해야 한다.

8. 스케일 소프트웨어는 휴대형 또는 웨어러블 장치의 매우 작은 임베디드 시스템에서부터 글로벌 커뮤니티에 서비스를 제공하는 인터넷 규모의 클라우드 기반 시스템에 이르기까지 매우 광범위한 규모에 걸쳐 개발되어야 한다.

To address these challenges, we will need new tools and techniques as well as innovative ways of combining and using existing software engineering methods.

이러한 과제를 해결하기 위해서는 기존의 소프트웨어 엔지니어링 방법을 결합하고 사용하는 혁신적인 방법뿐만 아니라 새로운 도구와 기법이 필요할 것이다.

1.1.2 소프트웨어 엔지니어링 다양성(Software engineering diversity)

Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers. The specific methods, tools, and techniques used depend on the organization developing the software, the type of software, and the people involved in the development process. There are no universal software engineering methods that are suitable for all systems and all companies. Rather, a diverse set of software engineering methods and tools has evolved over the past 50 years. However, the SEMAT initiative (Jacobson et al. 2013) proposes that there can be a fundamental meta-process that can be instantiated to create different kinds of process. This is at an early stage of development and may be a basis for improving our current software engineering methods.

Perhaps the most significant factor in determining which software engineering methods and techniques are most important is the type of application being devel- oped. There are many different types of application, including:

소프트웨어 엔지니어링은 소프트웨어 고객 및 생산자의 요구뿐만 아니라 실질적인 비용, 일정, 신뢰성 문제를 고려한 소프트웨어 생산에 대한 체계적인 접근이다. 사용되는 구체적인 방법, 도구, 기법은 소프트웨어를 개발하는 조직, 소프트웨어의 종류, 개발 과정에 관여하는 사람에 따라 달라진다. 모든 시스템 및 모든 회사에 적합한 범용 소프트웨어 엔지니어링 방법은 없다. 오히려, 다양한 소프트웨어 엔지니어링 방법과 도구들이 지난 50년 동안 진화해왔다. 그러나 SEMAT 이니셔티브(Jacobson et al. 2013)는 다양한 종류의 프로세스를 만들기 위해 인스턴스화할 수 있는 근본적인 메타 프로세스가 있을 수 있다고 제안한다. 이것은 개발 초기 단계에 있으며 우리의 현재 소프트웨어 엔지니어링 방법을 개선하기 위한 기초가 될 수 있다.

아마도 어떤 소프트웨어 엔지니어링 방법과 기법이 가장 중요한지 결정하는 가장 중요한 요소는 개발 중인 애플리케이션의 유형일 것이다. 애플리케이션에는 다음과 같은 다양한 유형이 있다.

1. Stand-alone applications These are application systems that run on a personal computer or apps that run on a mobile device. They include all necessary func- tionality and may not need to be connected to a network. Examples of such applications are office applications on a PC, CAD programs, photo manipula- tion software, travel apps, productivity apps, and so on.

2. Interactive transaction-based applications These are applications that execute on a remote computer and that are accessed by users from their own computers, phones, or tablets. Obviously, these include web applications such as e-commerce applications where you interact with a remote system to buy goods and services. This class of application also includes business systems, where a business provides access to its systems through a web browser or special-purpose client program and cloud-based services, such as mail and photo sharing. Interactive applications often incorporate a large data store that is accessed and updated in each transaction.

3. Embedded control systems These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded sys- tems than any other type of system. Examples of embedded systems include the software in a mobile (cell) phone, software that controls antilock braking in a car, and software in a microwave oven to control the cooking process.

4. Batch processing systems These are business systems that are designed to pro- cess data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples of batch systems are periodic billing systems, such as phone billing systems, and salary payment systems.

5. Entertainment systems These are systems for personal use that are intended to entertain the user. Most of these systems are games of one kind or another, which may run on special-purpose console hardware. The quality of the user interaction offered is the most important distinguishing characteristic of enter- tainment systems.

6. Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many separate, interacting objects. These are often computationally intensive and require high-performance parallel systems for execution.

7. Data collection and analysis systems Data collection systems are systems that collect data from their environment and send that data to other systems for pro- cessing. The software may have to interact with sensors and often is installed in a hostile environment such as inside an engine or in a remote location. “Big data” analysis may involve cloud-based systems carrying out statistical analysis and looking for relationships in the collected data.

8. Systems of systems These are systems, used in enterprises and other large organ- izations, that are composed of a number of other software systems. Some of these may be generic software products, such as an ERP system. Other systems in the assembly may be specially written for that environment.

9. 독립형 응용 프로그램 이것들은 개인용 컴퓨터에서 실행되는 응용 시스템이나 모바일 기기에서 실행되는 응용 프로그램이다. 그것들은 필요한 모든 기능을 포함하며 네트워크에 연결될 필요가 없을 수 있다. 이러한 애플리케이션의 예로는 PC의 사무실 애플리케이션, CAD 프로그램, 사진 조작 소프트웨어, 여행 앱, 생산성 앱 등이 있다.

10. 대화형 트랜잭션 기반 응용 프로그램 원격 컴퓨터에서 실행되고 사용자 자신의 컴퓨터, 전화 또는 태블릿에서 액세스하는 응용 프로그램이다. 분명히, 이것들은 당신이 상품과 서비스를 사기 위해 원격 시스템과 상호 작용하는 전자상거래 애플리케이션과 같은 웹 애플리케이션을 포함한다. 이 등급의 애플리케이션은 또한 기업이 웹 브라우저나 특수 목적 클라이언트 프로그램 및 메일 및 사진 공유와 같은 클라우드 기반 서비스를 통해 시스템에 대한 액세스를 제공하는 비즈니스 시스템을 포함한다. 인터랙티브 애플리케이션은 종종 각 트랜잭션에서 액세스하고 업데이트하는 대형 데이터 저장소를 통합한다.

11. 임베디드 제어 시스템 이것들은 하드웨어 장치를 제어하고 관리하는 소프트웨어 제어 시스템이다. 수치적으로, 아마도 다른 어떤 유형의 시스템보다 더 많은 임베디드 시스템들이 있을 것이다. 임베디드 시스템의 예로는 휴대 전화(셀)의 소프트웨어, 자동차의 안티록 브레이크를 제어하는 소프트웨어, 요리 과정을 제어하는 전자레인지의 소프트웨어가 있다.

12. 일괄처리시스템 이것들은 데이터를 대규모 일괄처리하도록 설계된 비즈니스 시스템이다. 그들은 해당하는 출력을 만들기 위해 많은 수의 개별 입력을 처리한다. 일괄결제 시스템의 예로는 전화요금제, 급여결제제 등 주기적인 과금제 등이 있다.

13. 엔터테인먼트 시스템 이것들은 사용자를 즐겁게 하기 위한 개인적인 사용을 위한 시스템이다. 이러한 시스템의 대부분은 특수 목적의 콘솔 하드웨어에서 실행될 수 있는 이런저런 종류의 게임이다. 제공되는 사용자 상호작용의 품질은 진입 시스템의 가장 중요한 구별 특성이다.

14. 모델링과 시뮬레이션을 위한 시스템 이것들은 과학자와 엔지니어가 물리적인 프로세스나 상황을 모델링하기 위해 개발한 시스템인데, 여기에는 많은 분리된 상호작용하는 물체가 포함된다. 이것들은 종종 계산적으로 집약적이며 실행을 위해 고성능 병렬 시스템이 필요하다.

15. 데이터 수집 및 분석 시스템 데이터 수집 시스템은 환경으로부터 데이터를 수집하고 그 데이터를 다른 시스템으로 전송하여 예방하는 시스템이다. 소프트웨어는 센서와 상호 작용해야 할 수 있으며, 엔진 내부나 원격 위치와 같은 적대적인 환경에 설치되는 경우가 많다. “빅 데이터” 분석은 통계 분석을 수행하고 수집된 데이터에서 관계를 찾는 클라우드 기반 시스템을 포함할 수 있다.

16. 시스템 시스템 이것들은 기업 및 기타 대규모 조직에 사용되는 시스템으로서, 다수의 다른 소프트웨어 시스템으로 구성되어 있다. 이들 중 일부는 ERP 시스템과 같은 일반적인 소프트웨어 제품일 수 있다. 어셈블리의 다른 시스템은 해당 환경을 위해 특별히 작성될 수 있다.

Of course, the boundaries between these system types are blurred. If you develop a game for a phone, you have to take into account the same constraints (power, hard- ware interaction) as the developers of the phone software. Batch processing systems are often used in conjunction with web-based transaction systems. For example, in a company, travel expense claims may be submitted through a web application but processed in a batch application for monthly payment.

Each type of system requires specialized software engineering techniques because the software has different characteristics. For example, an embedded control system in an automobile is safety-critical and is burned into ROM (read-only memory) when installed in the vehicle. It is therefore very expensive to change. Such a system needs extensive verification and validation so that the chances of having to recall cars after sale to fix software problems are minimized. User interaction is minimal (or perhaps nonexistent), so there is no need to use a development process that relies on user interface prototyping.

For an interactive web-based system or app, iterative development and delivery is the best approach, with the system being composed of reusable components. However, such an approach may be impractical for a system of systems, where detailed specifications of the system interactions have to be specified in advance so that each system can be separately developed.

Nevertheless, there are software engineering fundamentals that apply to all types of software systems:

물론 이러한 시스템 유형의 경계는 모호하다. 전화용 게임을 개발하면 전화 소프트웨어의 개발자와 동일한 제약(전력, 하드웨어 상호작용)을 고려해야 한다. 일괄 처리 시스템은 종종 웹 기반 거래 시스템과 연계하여 사용된다. 예를 들어, 회사의 경우, 여행 경비 청구서는 웹 애플리케이션을 통해 제출될 수 있지만 매달 지불을 위해 일괄적으로 처리될 수 있다.

각각의 시스템은 특별한 소프트웨어 공학 기술을 필요로 한다. 왜냐하면 소프트웨어는 다른 특성을 가지고 있기 때문이다. 예를 들어 자동차의 내장형 제어 시스템은 안전에 중요하며 차량에 설치할 때 ROM(읽기 전용 메모리)에 탑재된다. 그러므로 바꾸는 것은 매우 비싸다. 이러한 시스템은 소프트웨어 문제를 해결하기 위해 판매 후 자동차를 리콜해야 할 가능성을 최소화하기 위해 광범위한 검증과 검증이 필요하다. 사용자 상호작용은 최소(또는 없을 수도 있음)이므로 사용자 인터페이스 시제품 제작에 의존하는 개발 프로세스를 사용할 필요가 없다.

인터랙티브 웹 기반 시스템이나 앱의 경우, 시스템이 재사용 가능한 구성요소로 구성되는 등, 반복적인 개발과 전달이 최선의 접근법이다. 그러나 그러한 접근방식은 시스템 상호작용의 상세 규격을 미리 명시하여 각 시스템을 별도로 개발할 수 있도록 해야 하는 시스템 시스템에는 비현실적일 수 있다.

그럼에도 불구하고 모든 유형의 소프트웨어 시스템에 적용되는 소프트웨어 엔지니어링 기본 원칙이 있다.

1. They should be developed using a managed and understood development pro- cess. The organization developing the software should plan the development process and have clear ideas of what will be produced and when it will be com- pleted. Of course, the specific process that you should use depends on the type of software that you are developing.

2. Dependability and performance are important for all types of system. Software should behave as expected, without failures, and should be available for use when it is required. It should be safe in its operation and, as far as possible, should be secure against external attack. The system should perform efficiently and should not waste resources.

3. Understanding and managing the software specification and requirements (what the software should do) are important. You have to know what different custom- ers and users of the system expect from it, and you have to manage their expec- tations so that a useful system can be delivered within budget and to schedule.

4. You should make effective use of existing resources. This means that, where appropriate, you should reuse software that has already been developed rather than write new software.

5. 그것들은 관리되고 이해된 개발 과정을 이용하여 개발되어야 한다. 소프트웨어를 개발하는 조직은 개발 과정을 계획해야 하고, 어떤 것이 생산될 것인지 그리고 언제 그것이 완성될 것인지에 대한 명확한 생각을 가져야 한다. 물론 사용해야 하는 특정 프로세스는 개발 중인 소프트웨어의 유형에 따라 달라진다.

6. 의존성과 성능은 모든 종류의 시스템에 중요하다. 예상대로 소프트웨어, 실패 없이, 그리고 필요하다 사용할 수 있어야 한다 행동해야 한다. 운용 시 안전해야 하며, 가능한 한 외부 공격에 대해 안전해야 한다. 시스템은 효율적으로 수행되어야 하며 자원을 낭비해서는 안 된다.

7. 소프트웨어 사양 및 요건(소프트웨어가 어떻게 해야 하는가를)의 이해와 관리가 중요하다. 당신은 시스템의 다른 사용자와 사용자들이 그것으로부터 무엇을 기대하는지를 알아야 하고, 당신은 유용한 시스템이 예산 내에서 그리고 스케줄에 따라 전달될 수 있도록 그들의 외관을 관리해야 한다.

8. 기존 자원을 효과적으로 활용해야 한다. 즉, 적절한 경우 새로운 소프트웨어를 작성하기보다는 이미 개발된 소프트웨어를 재사용해야 한다는 것이다.

These fundamental notions of process, dependability, requirements, manage- ment, and reuse are important themes of this book. Different methods reflect them in different ways, but they underlie all professional software development.

These fundamentals are independent of the program language used for software development. I don’t cover specific programming techniques in this book because these vary dramatically from one type of system to another. For example, a dynamic language, such as Ruby, is the right type of language for interactive system develop- ment but is inappropriate for embedded systems engineering.

프로세스, 신뢰성, 요구사항, 관리 및 재사용에 대한 이러한 기본적인 개념은 이 책의 중요한 주제들이다. 다른 방법들은 그것들을 다른 방식으로 반영하지만, 그것들은 모든 전문적인 소프트웨어 개발의 기초가 된다.

이러한 기초는 소프트웨어 개발에 사용되는 프로그램 언어와 무관하다. 나는 이 책에서 특정한 프로그래밍 기법을 다루지 않는다. 왜냐하면 이것들이 시스템마다 극적으로 다르기 때문이다. 예를 들어, 루비와 같은 동적 언어는 상호작용 시스템 개발에 적합한 언어 유형이지만 임베디드 시스템 엔지니어링에는 적합하지 않다.

1.1.3 인터넷 소프트웨어 엔지니어링(Internet software engineering)

The development of the Internet and the World Wide Web has had a profound effect on all of our lives. Initially, the web was primarily a universally accessible information store, and it had little effect on software systems. These systems ran on local computers and were only accessible from within an organization. Around 2000, the web started to evolve, and more and more functionality was added to browsers. This meant that web-based systems could be developed where, instead of a special-purpose user interface, these systems could be accessed using a web browser. This led to the development of a vast range of new system products that delivered innovative services, accessed over the web. These are often funded by adverts that are displayed on the user’s screen and do not involve direct payment from users.

As well as these system products, the development of web browsers that could run small programs and do some local processing led to an evolution in business and organizational software. Instead of writing software and deploying it on users’ PCs, the software was deployed on a web server. This made it much cheaper to change and upgrade the software, as there was no need to install the software on every PC. It also reduced costs, as user interface development is particularly expensive. Wherever it has been possible to do so, businesses have moved to web-based inter- action with company software systems.

The notion of software as a service (Chapter 17) was proposed early in the 21st century This has now become the standard approach to the delivery of web-based system products such as Google Apps, Microsoft Office 365, and Adobe Creative Suite. More and more software runs on remote “clouds” instead of local servers and is accessed over the Internet. A computing cloud is a huge number of linked com- puter systems that is shared by many users. Users do not buy software but pay according to how much the software is used or are given free access in return for watching adverts that are displayed on their screen. If you use services such as web- based mail, storage, or video, you are using a cloud-based system.

The advent of the web has led to a dramatic change in the way that business soft- ware is organized. Before the web, business applications were mostly monolithic, single programs running on single computers or computer clusters. Communications were local, within an organization. Now, software is highly distributed, sometimes across the world. Business applications are not programmed from scratch but involve extensive reuse of components and programs.

This change in software organization has had a major effect on software engi- neering for web-based systems. For example:

인터넷과 월드와이드웹의 발전은 우리의 모든 삶에 지대한 영향을 끼쳤다. 처음에 웹은 주로 보편적으로 접근할 수 있는 정보 저장소였고, 소프트웨어 시스템에는 거의 영향을 미치지 않았다. 이러한 시스템은 로컬 컴퓨터에서 실행되며 조직 내에서만 액세스할 수 있었다. 2000년경부터 웹이 진화하기 시작했고, 브라우저에 점점 더 많은 기능이 추가되었다. 이는 특수 목적 사용자 인터페이스 대신 웹 브라우저를 사용하여 이러한 시스템에 접근할 수 있는 웹 기반 시스템을 개발할 수 있음을 의미했다. 이로 인해 웹을 통해 액세스하고 혁신적인 서비스를 제공하는 광범위한 새로운 시스템 제품이 개발되었다. 이것들은 종종 사용자 화면에 표시되고 사용자로부터의 직접 지불을 포함하지 않는 광고에 의해 자금 지원을 받는다.

이러한 시스템 제품들뿐만 아니라, 작은 프로그램을 실행하고 어느 정도 로컬 처리를 할 수 있는 웹 브라우저의 개발은 비즈니스와 조직 소프트웨어의 발전을 이끌었다. 소프트웨어를 작성하여 사용자의 PC에 배치하는 대신, 웹 서버에 소프트웨어를 배치했다. 이로 인해 모든 PC에 소프트웨어를 설치할 필요가 없었기 때문에 소프트웨어를 변경하고 업그레이드하는 것이 훨씬 저렴해졌다. 그것은 또한 사용자 인터페이스 개발이 특히 비싸기 때문에 비용을 절감했다. 어디에서든 그렇게 할 수 있었던 기업들은 회사 소프트웨어 시스템과 웹 기반의 상호 작용으로 이동했다.

소프트웨어의 서비스화 개념(17장)은 21세기 초에 제안되었다. 이것은 이제 구글 앱, 마이크로소프트 오피스 365, 어도비 크리에이티브 스위트 같은 웹 기반 시스템 제품의 전달에 대한 표준 접근법이 되었다. 점점 더 많은 소프트웨어가 로컬 서버 대신 원격 “클라우드”에서 실행되고 인터넷을 통해 액세스된다. 컴퓨팅 클라우드는 많은 사용자가 공유하는 엄청난 수의 링크드 컴퍼 시스템이다. 사용자는 소프트웨어를 구입하지 않고, 자신의 화면에 표시되는 광고를 시청하는 대가로 소프트웨어가 얼마나 사용되는지에 따라 요금을 지불하거나 무료 접속이 가능하다. 웹 기반 메일, 저장소 또는 비디오와 같은 서비스를 사용하는 경우 클라우드 기반 시스템을 사용하는 경우

웹의 등장은 비즈니스 소프트 웨어의 조직 방식에 극적인 변화를 가져왔다. 웹 이전에 비즈니스 애플리케이션은 대부분 단일 컴퓨터 또는 컴퓨터 클러스터에서 실행되는 단일 프로그램이었다. 의사소통은 지역적으로 조직 내에서 이루어졌다. 현재, 소프트웨어는 고도로 보급되어 있으며, 때로는 전 세계에 걸쳐 보급되기도 한다. 비즈니스 애플리케이션은 처음부터 프로그래밍되어 있지 않지만 구성 요소와 프로그램의 광범위한 재사용이 수반된다.

이러한 소프트웨어 조직의 변화는 웹 기반 시스템의 소프트웨어 개발에 큰 영향을 미쳤다. 예를 들어 다음과 같다.

1. Software reuse has become the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from preexisting software components and systems, often bundled together in a framework.

2. It is now generally recognized that it is impractical to specify all the require- ments for such systems in advance. Web-based systems are always developed and delivered incrementally.

3. Software may be implemented using service-oriented software engineering, where the software components are stand-alone web services. I discuss this approach to software engineering in Chapter 18.

4. Interface development technology such as AJAX (Holdener 2008) and HTML5 (Freeman 2011) have emerged that support the creation of rich interfaces within a web browser.

5. 소프트웨어 재사용이 웹 기반 시스템 구축의 지배적인 접근방식이 되었다. 이러한 시스템을 구축할 때 기존 소프트웨어 구성 요소와 시스템에서 이들을 결합할 수 있는 방법에 대해 생각해 보십시오.

6. 이제 그러한 시스템에 대한 모든 요구 사항을 사전에 명시하는 것은 비현실적이라고 일반적으로 인식되고 있다. 웹 기반 시스템은 항상 개발되고 점진적으로 전달된다.

7. 소프트웨어는 소프트웨어 구성요소가 독립형 웹 서비스인 서비스 지향 소프트웨어 엔지니어링을 사용하여 구현할 수 있다. 나는 18장에서 소프트웨어 공학에 대한 이 접근법에 대해 논한다.

8. 웹브라우저 내 리치 인터페이스 창출을 지원하는 AJAX (Holdener 2008), HTML5 (Freeman 2011) 등의 인터페이스 개발 기술이 등장했다.

The fundamental ideas of software engineering, discussed in the previous section, apply to web-based software, as they do to other types of software. Web-based sys- tems are getting larger and larger, so software engineering techniques that deal with scale and complexity are relevant for these systems.

앞 절에서 논의된 소프트웨어 공학의 기본 아이디어는 다른 유형의 소프트웨어와 마찬가지로 웹 기반 소프트웨어에 적용된다. 웹 기반 시스템들은 점점 더 커지고 있기 때문에, 규모와 복잡성을 다루는 소프트웨어 공학 기법은 이러한 시스템과 관련이 있다.

1.2 소프트웨어 엔지니어링 윤리(Software engineering ethics)

Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of people working in that area. As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills. You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer.

It goes without saying that you should uphold normal standards of honesty and integrity. You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession. However, there are areas where standards of acceptable behavior are not bound by laws but by the more tenuous notion of professional responsibility. Some of these are:

다른 공학 분야와 마찬가지로, 소프트웨어 공학은 그 분야에서 일하는 사람들의 자유를 제한하는 사회적, 법적 프레임워크 내에서 수행된다. 소프트웨어 엔지니어로서, 당신은 당신의 직업이 단순한 기술 기술의 적용보다 더 넓은 책임을 수반한다는 것을 받아들여야 한다. 만약 당신이 전문 기술인으로서의 존중되어야 하또한, 도덕적으로 책임 있는 윤리적 방식으로 행동해야 한다.

정직과 청렴의 정상적인 기준을 지켜야 한다는 것은 두말할 나위도 소프트웨어 공학 직업에 불명예를 안겨줄 부정한 방법이나 방법으로 행동하기 위해 당신의 기술과 능력을 사용해서는 안 된다. 그러나, 허용 가능한 행동의 기준이 법에 의해 구속되는 것이 아니라 직업적 책임이라는 보다 완고한 개념에 의해 좌우되는 영역이 있다. 이 중 일부는 다음과 같다.

1. Confidentiality: You should normally respect the confidentiality of your employ- ers or clients regardless of whether or not a formal confidentiality agreement has been signed.

2. Competence: You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence.

3. Intellectual property rights: You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected.

4. Computer misuse: You should not use your technical skills to misuse other peo- ple’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine) to extremely serious (dissemination of viruses or other malware).

5. 기밀성: 당신은 일반적으로 공식적인 비밀 유지 협정이 체결되었는지 여부에 관계 없이 고용인 또는 고객들의 기밀성을 존중해야 한다.

6. 역량: 자신의 능력 수준을 잘못 해석해서는 안 된다. 자신의 능력 밖의 일을 고의로 받아서는 안 된다.

7. 지적재산권: 당신은 특허와 저작권 같은 지적 재산의 사용을 규제하는 지방법을 알아야 한다. 고용주와 고객의 지적재산이 보호받을 수 있도록 주의해야 한다.

8. 컴퓨터 오용: 당신은 다른 사람들의 컴퓨터를 오용하기 위해 당신의 기술력을 사용해서는 안 된다. 컴퓨터 오용은 비교적 사소한 것(고용주의 기계에서 게임하는 것)에서부터 극히 심각한 것(바이러스나 다른 악성코드의 보급)에 이르기까지 다양하다.

Software Engineering Code of Ethics and Professional Practice

ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices

PREAMBLE

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as soft- ware engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, test- ing, and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety, and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC — Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT — Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT — Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION — Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues.

8. SELF — Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

소프트웨어 엔지니어링 윤리 및 전문 관행 법규

ACM/IEEEE-CS 소프트웨어 엔지니어링 윤리 및 전문가 사례 공동 태스크포스

준비 가능

코드의 짧은 버전은 추상화의 높은 수준에서 포부를 요약한다; 풀버전에 포함된 조항들은 우리가 소프트 제품 엔지니어링 전문가로서 행동하는 방식을 어떻게 변화시키는지에 대한 사례와 세부사항을 제공한다. 열망이 없다면, 세부적인 것들은 합법적이고 지루해질 수 있고, 세부적인 것들이 없다면, 포부는 높게 들릴 수 있지만 공허해질 수 있다; 포부와 세부적인 것들은 함께 응집력 있는 코드를 형성한다.

소프트웨어 엔지니어는 소프트웨어의 분석, 사양, 설계, 개발, 시험 및 유지보수를 유익하고 존경받는 직업으로 만들 것을 약속해야 한다. 소프트웨어 엔지니어는 공공의 보건, 안전 및 복지에 대한 약속에 따라 다음 8원칙을 준수해야 한다.

1. 공중 — 소프트웨어 엔지니어들은 지속적으로 그 공공의 이익에 행동해야 한다.

2. CLIENT 및 EMPLOYER — 소프트웨어 기술자들은 그들의 클라이언트와 사업주는 공공 이익에 부합하는 가장 이익이 되는 방법으로 행동해야 한다.

3. 제품 — 소프트웨어 엔지니어는 제품 및 관련 변경이 가능한 최고 전문 표준을 충족하는지 확인해야 한다.

4. JUDGMENT — 소프트웨어 엔지니어는 전문적 판단에서 무결성과 독립성을 유지해야 한다.

5. 관리 — 소프트웨어 엔지니어링 관리자 및 리더는 소프트웨어 개발 및 유지 관리에 대한 윤리적 접근방식에 가입하고 이를 촉진해야 한다.

6. 권장 — 소프트웨어 엔지니어는 공공의 이익과 일치하는 직업의 진실성과 평판을 발전시켜야 한다.

7. COLLEAGUES — 소프트웨어 엔지니어는 동료에게 공평하고 지지해야 한다.

8. SELF — 소프트웨어 엔지니어는 자신의 직업에 관한 평생학습에 참여해야 하며, 직업의 관행에 대한 윤리적 접근을 촉진해야 한다.

[Figure 1.3 The ACM/ IEEE Code of Ethics (ACM/IEEE-CS Joint

Task Force on Software Engineering Ethics and Professional Practices, short version. http:// www.acm.org/about/ se-code)

(© 1999 by the ACM, Inc. and the IEEE, Inc.)]

Professional societies and institutions have an important role to play in setting ethical standards. Organizations such as the ACM, the IEEE (Institute of Electrical and Electronic Engineers), and the British Computer Society publish a code of pro- fessional conduct or code of ethics. Members of these organizations undertake to follow that code when they sign up for membership. These codes of conduct are generally concerned with fundamental ethical behavior.

Professional associations, notably the ACM and the IEEE, have cooperated to produce a joint code of ethics and professional practice. This code exists in both a short form, shown in Figure 1.3, and a longer form (Gotterbarn, Miller, and Rogerson 1999) that adds detail and substance to the shorter version. The rationale behind this code is summarized in the first two paragraphs of the longer form:

전문적인 사회와 기관들은 윤리적 기준을 세우는 데 중요한 역할을 한다. ACM, IEEE(Institute of Electrical and Electronic Engineers), British Computer Society와 같은 단체들은 프로페셔널 행동 강령이나 윤리 강령을 발표한다. 이러한 조직의 구성원들은 그들이 회원 가입을 할 때 그 규정을 따를 의무가 있다. 이러한 행동 강령은 일반적으로 근본적인 윤리적 행동과 관련이 있다.

전문 협회, 특히 ACM과 IEEE는 공동 윤리규범과 전문적 관행을 만들기 위해 협력했다. 이 코드는 그림 1.3과 같이 짧은 형태와 더 긴 형태(Gotterbarn, Miller, Rogerson 1999) 둘 다로 존재하며, 더 짧은 버전에 세부 사항과 실질을 더한다. 이 코드의 근거는 더 긴 형태의 첫 두 단락에 요약된다.

Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, spec- ification, design, development, certification, maintenance and testing of software systems. Because of their roles in developing software systems, software engi- neers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. In accordance with that commitment, software engi- neers shall adhere to the following Code of Ethics and Professional Practice†.

The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. The Principles identify the ethically responsible relationships in which individuals, groups, and organizations participate and the primary obligations within these relationships. The Clauses of each Principle are illus- trations of some of the obligations included in these relationships. These obli- gations are founded in the software engineer’s humanity, in special care owed to people affected by the work of software engineers, and the unique elements of the practice of software engineering. The Code prescribes these as obliga- tions of anyone claiming to be or aspiring to be a software engineer†.

In any situation where different people have different views and objectives, you are likely to be faced with ethical dilemmas. For example, if you disagree, in principle, with the policies of more senior management in the company, how should you react? Clearly, this depends on the people involved and the nature of the disagreement. Is it best to argue a case for your position from within the organization or to resign in principle? If you feel that there are problems with a software project, when do you reveal these problems to management? If you discuss these while they are just a suspicion, you may be overreact- ing to a situation; if you leave it too long, it may be impossible to resolve the difficulties. We all face such ethical dilemmas in our professional lives, and, fortunately, in most cases they are either relatively minor or can be resolved without too much dif- ficulty. Where they cannot be resolved, the engineer is faced with, perhaps, another problem. The principled action may be to resign from their job, but this may well

affect others such as their partner or their children.

A difficult situation for professional engineers arises when their employer acts in an unethical way. Say a company is responsible for developing a safety-critical system and, because of time pressure, falsifies the safety validation records. Is the engineer’s responsibility to maintain confidentiality or to alert the customer or publicize, in some way, that the delivered system may be unsafe?

컴퓨터는 상업, 산업, 정부, 의학, 교육, 오락, 사회 전반에 걸쳐 중심적이고 성장하는 역할을 가지고 있다. 소프트웨어 엔지니어는 소프트웨어 시스템의 분석, 규격, 설계, 개발, 인증, 유지보수 및 시험에 직접 참여하거나 가르침에 의해 기여하는 사람을 말한다. 소프트웨어 시스템 개발에 있어서의 그들의 역할 때문에, 소프트웨어 기업은 다른 사람들이 선을 행하거나 해를 입히거나, 다른 사람들이 선을 행하거나 해를 입히도록 하거나, 다른 사람들에게 선을 행하거나 해를 입히도록 영향을 줄 수 있는 중요한 기회를 가진다. 가능한 한, 그들의 노력이 선한 일에 쓰이도록 하기 위해서, 소프트웨어 엔지니어들은 소프트웨어 공학을 유익하고 존경 받는 직업으로 만들기 위해 헌신해야 한다. 그 약속에 따라 소프트웨어 기업은 다음의 윤리 및 전문 관행 강령을 준수해야 한다.

이 강령에는 실무자, 교육자, 관리자, 감독자 및 정책 입안자뿐만 아니라 해당 직업의 훈련자 및 학생 등 전문 소프트웨어 엔지니어가 내린 행동과 결정과 관련된 8가지 원칙이 수록되어 있다. 원칙은 개인, 그룹 및 조직이 참여하는 윤리적으로 책임지는 관계와 이러한 관계 내의 일차적인 의무를 식별한다. 각 원칙의 조항은 이러한 관계에 포함된 의무의 일부 조항이다. 이러한 통계는 소프트웨어 엔지니어의 인간성, 소프트웨어 엔지니어의 업무로 영향을 받는 사람들에게 부여된 특별한 주의, 그리고 소프트웨어 엔지니어링의 실행의 독특한 요소에서 설립된다. 이 강령은 이러한 것들을 소프트웨어 엔지니어라고 주장하거나 희망하는 사람들의 의무로 규정한다.

다른 사람들이 다른 견해와 목표를 가지고 있는 어떤 상황에서, 당신은 윤리적인 딜레마에 직면하기 쉽다. 예를 들어, 원칙적으로 회사 내에서 더 많은 고위 경영진의 정책에 동의하지 않는다면 어떻게 대응해야 하는가? 분명히, 이것은 관련된 사람들과 의견 불일치의 성격에 달려있다. 조직 내에서 자신의 입장을 주장하는 것이 최선인가, 아니면 원칙적으로 사퇴하는 것이 최선인가? 소프트웨어 프로젝트에 문제가 있다고 생각되면 언제 이러한 문제를 경영진에게 공개하는가? 단지 의혹일 뿐인데 이것을 논한다면 어떤 상황에 과민하게 반응할 수도 있고, 너무 오래 두면 어려움을 해결하는 것이 불가능할 수도 있다. 우리 모두는 직업 생활에서 그러한 윤리적 딜레마에 직면하고 있으며, 다행히도, 대부분의 경우 그것들은 상대적으로 경미하거나 너무 많은 어려움 없이 해결될 수 있다. 그들이 해결할 수 없는 곳에서 엔지니어는 아마도 또 다른 문제에 직면하게 될 것이다. 원칙적인 조치는 그들의 직장에서 사임하는 것일 수도 있지만, 이것은 잘 될 수도 있다.

그들의 파트너나 그들의 자녀와 같은 다른 사람들에게 영향을 끼친다.

전문 기술자들에게 어려운 상황은 고용주가 비윤리적인 방식으로 행동할 때 발생한다. 회사가 안전 중요 시스템 개발에 책임이 있고, 시간 압력 때문에 안전 검증 기록을 변조한다고 하자. 기밀성을 유지하거나 고객에게 알리거나 전달된 시스템이 안전하지 않을 수 있음을 알리는 엔지니어의 책임이 있는가?

주석: †ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices, short version Preamble. http://www.acm.org/about/se-code Copyright © 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc.

EngineeringACM/IEEE-CS 소프트웨어 엔지니어링 윤리 및 전문 관행에 관한 공동 태스크포스, 쇼트 버전 Preamble. http://www.acm.org/about/se-code Copyright © 1999 by the Association for Computing Machinery, Inc. and Institute for Electrical and Electronics Engineers, Inc..

The problem here is that there are no absolutes when it comes to safety. Although the system may not have been validated according to predefined criteria, these criteria may be too strict. The system may actually operate safely throughout its life- time. It is also the case that, even when properly validated, the system may fail and cause an accident. Early disclosure of problems may result in damage to the employer and other employees; failure to disclose problems may result in damage to others.

You must make up your own mind in these matters. The appropriate ethical posi- tion here depends on the views of the people involved. The potential for damage, the extent of the damage, and the people affected by the damage should influence the decision. If the situation is very dangerous, it may be justified to publicize it using the national press or social media. However, you should always try to resolve the situation while respecting the rights of your employer.

Another ethical issue is participation in the development of military and nuclear systems. Some people feel strongly about these issues and do not wish to participate in any systems development associated with defense systems. Others will work on mili- tary systems but not on weapons systems. Yet others feel that national security is an overriding principle and have no ethical objections to working on weapons systems.

In this situation, it is important that both employers and employees should make their views known to each other in advance. Where an organization is involved in military or nuclear work, it should be able to specify that employees must be willing to accept any work assignment. Equally, if an employee is taken on and makes clear that he or she does not wish to work on such systems, employers should not exert pressure to do so at some later date.

The general area of ethics and professional responsibility is increasingly important as software-intensive systems pervade every aspect of work and everyday life. It can be considered from a philosophical standpoint where the basic principles of ethics are considered and software engineering ethics are discussed with reference to these basic principles. This is the approach taken by Laudon (Laudon 1995) and Johnson (Johnson 2001). More recent texts such as that by Tavani (Tavani 2013) introduce the notion of cyberethics and cover both the philosophical background and practical and legal issues. They include ethical issues for technology users as well as developers.

I find that a philosophical approach is too abstract and difficult to relate to every- day experience so I prefer the more concrete approach embodied in professional codes of conduct (Bott 2005; Duquenoy 2007). I think that ethics are best discussed in a software engineering context and not as a subject in its own right. Therefore, I do not discuss software engineering ethics in an abstract way but include examples in the exercises that can be the starting point for a group discussion.

여기서 문제는 안전에 관한 한 절대절차가 없다는 것이다. 시스템이 사전 정의된 기준에 따라 검증되지 않았을 수 있지만, 이러한 기준은 너무 엄격할 수 있다. 그 시스템은 실제로 평생 동안 안전하게 작동할 수 있다. 또한 제대로 검증된 경우에도 시스템이 고장나서 사고를 일으킬 수 있다. 문제를 조기에 공시하면 사업주와 그 밖의 종업원에게 손해를 입힐 수 있으며, 문제를 공시하지 않으면 타인에게 손해를 입힐 수 있다.

이런 일에는 스스로 마음을 정해야 한다. 여기서 적절한 윤리적 긍정은 관련된 사람들의 관점에 달려 있다. 피해의 잠재성, 피해 규모, 피해 대상자 등이 결정에 영향을 미칠 수밖에 없다. 만약 상황이 매우 위험하다면, 국가 언론이나 소셜 미디어를 이용하여 그것을 공표하는 것이 정당화될 수도 있다. 그러나, 당신은 항상 고용주의 권리를 존중하면서 그 상황을 해결하려고 노력해야 한다.

또 다른 윤리적 이슈는 군사 및 핵 시스템 개발에 참여하는 것이다. 어떤 사람들은 이러한 문제들에 대해 강하게 느끼고 방어 시스템과 관련된 어떤 시스템 개발에도 참여하기를 원하지 않는다. 다른 사람들은 무기체계에서 일하지만 무기체계는 하지 않을 것이다. 그러나 다른 사람들은 국가안보가 최우선 원칙이며 무기체계 개발에 대한 윤리적 반대가 없다고 생각한다.

이런 상황에서 고용주와 종업원 모두 사전에 서로의 견해를 밝히는 것이 중요하다. 조직이 군사 또는 핵 활동에 관여하는 경우, 직원들이 어떤 업무 할당에도 기꺼이 응해야 한다는 것을 명시할 수 있어야 한다. 마찬가지로, 종업원을 고용하여 그러한 시스템에서 일하기를 원하지 않는다는 것을 분명히 하는 경우, 고용주들은 나중에 그렇게 하도록 압력을 행사해서는 안 된다.

소프트웨어 집약적인 시스템이 일과 일상 생활의 모든 측면에 퍼지면서 윤리와 직업적 책임의 일반적인 영역이 점점 더 중요해지고 있다. 이러한 기본원칙을 참고하여 윤리의 기본원칙을 고려하고 소프트웨어 공학윤리를 논하는 철학적 관점에서도 생각할 수 있다. 로돈(Laudon 1995)과 존슨(Johnson 2001)이 취한 접근이다. 타바니(Tavani 2013)의 그것과 같은 보다 최근의 문헌들은 사이베레틱스의 개념을 소개하고 철학적 배경과 실용적, 법적 문제를 모두 다루고 있다. 여기에는 개발자뿐만 아니라 기술 사용자들을 위한 윤리적 문제가 포함된다.

나는 철학적인 접근법이 너무 추상적이고 매일의 경험과 연관되기 어렵다는 것을 발견했고 그래서 나는 전문적인 행동 규범에 구체화된 보다 구체적인 접근법을 선호한다(Bott 2005; Duquenoy 2007). 나는 윤리가 소프트웨어 공학적인 맥락에서 가장 잘 논의되고 그 자체로 주제가 아니라고 생각한다. 따라서 나는 소프트웨어 공학 윤리를 추상적으로 논하지 않고 그룹 토의의의 출발점이 될 수 있는 예를 연습에 포함시킨다.

1.3 사례 연구(Case studies)

To illustrate software engineering concepts, I use examples from four different types of system. I have deliberately not used a single case study, as one of the key messages in this book is that software engineering practice depends on the type of systems

being produced. I therefore choose an appropriate example when discussing con- cepts such as safety and dependability, system modeling, reuse, etc.

The system types that I use as case studies are:

소프트웨어 엔지니어링 개념을 설명하기 위해, 나는 네 가지 다른 유형의 시스템의 예를 사용한다. 이 책의 주요 메시지 중 하나는 소프트웨어 엔지니어링 관행이 시스템의 유형에 따라 다르다는 것이기 때문에 나는 의도적으로 단 하나의 사례 연구를 사용하지 않았다.

생산되는 그러므로 나는 안전과 신뢰성, 시스템 모델링, 재사용 등과 같은 문제를 논의할 때 적절한 예를 선택한다.

사례 연구로 사용하는 시스템 유형은 다음과 같다.

1. An embedded system This is a system where the software controls some hard- ware device and is embedded in that device. Issues in embedded systems typi- cally include physical size, responsiveness, and power management, etc. The example of an embedded system that I use is a software system to control an insulin pump for people who have diabetes.

2. An information system The primary purpose of this type of system is to manage and provide access to a database of information. Issues in information systems include security, usability, privacy, and maintaining data integrity. The example of an information system used is a medical records system.

3. A sensor-based data collection system This is a system whose primary purposes are to collect data from a set of sensors and to process that data in some way. The key requirements of such systems are reliability, even in hostile environ- mental conditions, and maintainability. The example of a data collection system that I use is a wilderness weather station.

4. A support environment. This is an integrated collection of software tools that are used to support some kind of activity. Programming environments, such as Eclipse (Vogel 2012) will be the most familiar type of environment for readers of this book. I describe an example here of a digital learning environment that is used to support students’ learning in schools.

5. 임베디드 시스템 이것은 소프트웨어가 일부 하드 제품 장치를 제어하고 그 장치에 내장되는 시스템이다. 임베디드 시스템의 문제 - 물리적인 크기, 반응성 및 전력 관리 등을 포함한다. 내가 사용하는 임베디드 시스템의 예는 당뇨병에 걸린 사람들을 위해 인슐린 펌프를 제어하는 소프트웨어 시스템이다.

6. 정보시스템 이 유형의 일차적인 목적은 정보의 데이터베이스에 대한 관리 및 접근을 제공하는 것이다. 정보시스템의 문제에는 보안, 사용성, 프라이버시, 데이터 무결성 유지 등이 포함된다. 이용되는 정보시스템의 예는 의료기록 시스템이다.

7. 센서 기반 데이터 수집 시스템 이것은 일련의 센서로부터 데이터를 수집하고 그 데이터를 어떤 방식으로 처리하는 것을 주된 목적으로 하는 시스템이다. 그러한 시스템의 핵심 요건은 심지어 적대적인 환경 조건에서도 신뢰성과 유지 가능성이다. 내가 사용하는 데이터 수집 시스템의 예는 황량한 기상 관측소다.

8. 지원 환경. 이것은 어떤 종류의 활동을 지원하는 데 사용되는 소프트웨어 도구들의 통합 모음입니다. Eclipse (Vogel 2012)와 같은 프로그래밍 환경은 이 책의 독자들에게 가장 친숙한 유형의 환경이 될 것이다. 나는 여기에서 학교에서 학생들의 학습을 지원하는 데 사용되는 디지털 학습 환경의 예를 설명한다.

I introduce each of these systems in this chapter; more information about each of them is available on the website (software-engineering-book.com).

나는 이 챕터의 각 시스템을 소개한다. 각각의 시스템에 대한 자세한 정보는 웹사이트 (software-engineering-book.com).에서 볼 수 있다.

1.3.1 인슐린 펌프 제어 시스템(An insulin pump control system)

An insulin pump is a medical system that simulates the operation of the pancreas (an internal organ). The software controlling this system is an embedded system that collects information from a sensor and controls a pump that delivers a controlled dose of insulin to a user.

People who suffer from diabetes use the system. Diabetes is a relatively common condition in which the human pancreas is unable to produce sufficient quantities of a hormone called insulin. Insulin metabolizes glucose (sugar) in the blood. The con- ventional treatment of diabetes involves regular injections of genetically engineered insulin. Diabetics measure their blood sugar levels periodically using an external meter and then estimate the dose of insulin they should inject.

The problem is that the level of insulin required does not just depend on the blood glucose level but also on the time of the last insulin injection. Irregular checking can lead to very low levels of blood glucose (if there is too much insulin) or very high levels of blood sugar (if there is too little insulin). Low blood glucose is, in the short term, a more serious condition as it can result in temporary brain malfunctioning and, ultimately, unconsciousness and death. In the long term, however, continual high levels of blood glucose can lead to eye damage, kidney damage, and heart problems.

Advances in developing miniaturized sensors have meant that it is now possible to develop automated insulin delivery systems. These systems monitor blood sugar levels and deliver an appropriate dose of insulin when required. Insulin delivery systems like this one are now available and are used by patients who find it difficult to control their insulin levels. In future, it may be possible for diabetics to have such systems permanently attached to their bodies.

A software-controlled insulin delivery system uses a microsensor embedded in the patient to measure some blood parameter that is proportional to the sugar level. This is then sent to the pump controller. This controller computes the sugar level and the amount of insulin that is needed. It then sends signals to a miniaturized pump to deliver the insulin via a permanently attached needle.

Figure 1.4 shows the hardware components and organization of the insulin pump. To understand the examples in this book, all you need to know is that the blood sensor measures the electrical conductivity of the blood under different conditions and that these values can be related to the blood sugar level. The insulin pump delivers one unit of insulin in response to a single pulse from a controller. Therefore, to deliver 10 units of insulin, the controller sends 10 pulses to the pump. Figure 1.5 is a Unified Modeling

인슐린 펌프는 췌장(내장기)의 작동을 시뮬레이션하는 의료 시스템이다. 이 시스템을 제어하는 소프트웨어는 센서로부터 정보를 수집하고 사용자에게 인슐린을 제어하는 펌프를 제어하는 임베디드 시스템이다.

당뇨병을 앓는 사람들은 이 시스템을 사용한다. 당뇨병은 인간의 췌장이 인슐린이라는 호르몬을 충분히 생산할 수 없는 비교적 흔한 질환이다. 인슐린은 혈당(당)을 대사시킨다. 당뇨병의 의도적인 치료는 유전공학 인슐린을 정기적으로 주사하는 것을 포함한다. 당뇨병 환자들은 외부 측정기를 사용하여 혈당 수치를 주기적으로 측정하고 그들이 주입해야 하는 인슐린의 양을 추정한다.

문제는 필요한 인슐린의 수치는 혈당 수치뿐만 아니라 마지막 인슐린 주사 시간에 따라 다르다는 것이다. 불규칙한 점검은 혈당 수치가 매우 낮거나(인슐린이 너무 많으면) 혈당 수치가 매우 높을 수 있다(인슐린이 너무 적으면). 저혈당 포도당은 단기적으로 일시적인 뇌 기능 장애와 궁극적으로는 무의식과 죽음을 초래할 수 있기 때문에 더 심각한 상태를 말한다. 그러나 장기적으로 볼 때 혈당 수치가 계속 높으면 눈의 손상, 신장 손상, 심장병을 일으킬 수 있다.

소형화된 센서 개발의 진전은 이제 자동화된 인슐린 전달 시스템을 개발하는 것이 가능하다는 것을 의미했다. 이러한 시스템은 혈당 수치를 모니터링하고 필요할 때 적절한 양의 인슐린을 공급한다. 이와 같은 인슐린 투약 시스템은 현재 이용가능하며, 인슐린 수치를 조절하기 어려운 환자들이 사용한다. 미래에는, 당뇨병 환자들은 자신의 몸에 영구적으로 그러한 시스템을 부착하는 것이 가능할 수도 있다.

소프트웨어로 제어되는 인슐린 전달 시스템은 환자에게 내장된 마이크로센서를 사용하여 당도에 비례하는 일부 혈중 파라미터를 측정한다. 그런 다음 펌프 컨트롤러로 전송된다. 이 제어기는 필요한 인슐린의 양과 당도를 계산한다. 그리고 나서 그것은 영구적으로 부착된 바늘을 통해 인슐린을 전달하기 위해 소형화된 펌프에 신호를 보낸다.

그림 1.4는 인슐린 펌프의 하드웨어 구성 요소와 구성을 보여준다. 이 책의 예를 이해하기 위해, 당신이 알아야 할 것은 혈액 센서가 다른 조건에서 혈액의 전기 전도도를 측정하고, 이 값들이 혈당 수치와 관련이 있을 수 있다는 것이다. 인슐린 펌프는 컨트롤러의 단일 펄스에 반응하여 1단위의 인슐린을 공급한다. 따라서 10단위의 인슐린을 공급하기 위해 제어기는 펌프에 10개의 펄스를 보낸다. 그림 1.5는 통합 모델링

[Figure 1.4 Insulin pump hardware architecture]

[Figure 1.5 Activity model of the insulin pump] - 안보이는부분 Log dose

[Figure 1.6 The organization of the Mentcare system]

Language (UML) activity model that illustrates how the software transforms an input blood sugar level to a sequence of commands that drive the insulin pump.

Clearly, this is a safety-critical system. If the pump fails to operate or does not operate correctly, then the user’s health may be damaged or they may fall into a coma because their blood sugar levels are too high or too low. This system must therefore meet two essential high-level requirements:

소프트웨어가 입력 혈당 수준을 인슐린 펌프를 구동하는 일련의 명령으로 변환하는 방법을 보여주는 언어(UML) 활동 모델.

분명히, 이것은 안전에 중요한 시스템이다. 펌프가 작동하지 않거나 제대로 작동하지 않으면 혈당치가 너무 높거나 낮아 사용자의 건강이 손상되거나 혼수상태에 빠질 수 있다. 따라서 이 시스템은 다음 두 가지 필수 상위 레벨 요건을 충족해야 한다.

1. The system shall be available to deliver insulin when required.

2. The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar.

3. 필요한 경우 인슐린을 공급할 수 있어야 한다.

4. 시스템은 현재 혈당 수치를 상쇄하기 위해 신뢰성 있게 수행되어야 하며 정확한 양의 인슐린을 전달해야 한다.

The system must therefore be designed and implemented to ensure that it always meets these requirements. More detailed requirements and discussions of how to ensure that the system is safe are discussed in later chapters.

그러므로 시스템은 항상 이러한 요구사항을 충족하도록 설계되고 구현되어야 한다. 시스템이 안전한지 확인하는 방법에 대한 자세한 요구사항과 논의는 뒷 장에서 논의된다.

1.3.2 정신 건강 관리를 위한 환자 정보 시스템(A patient information system for mental health care)

A patient information system to support mental health care (the Mentcare system) is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received. Most mental health patients do not require dedicated hospital treatment but need to attend special- ist clinics regularly where they can meet a doctor who has detailed knowledge of their problems. To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centers.

The Mentcare system (Figure 1.6) is a patient information system that is intended for use in clinics. It makes use of a centralized database of patient information but has also been designed to run on a laptop, so that it may be accessed and used from sites that do not have secure network connectivity. When the local systems have secure network access, they use patient information in the database, but they can download and use local copies of patient records when they are disconnected. The system is not a complete medical records system and so does not maintain informa- tion about other medical conditions. However, it may interact and exchange data with other clinical information systems.

This system has two purposes:

정신건강관리(Mental Health care)를 지원하는 환자정보시스템(Patient Information System)은 정신건강 문제로 고통받는 환자와 그들이 받은 치료법에 대한 정보를 보관하는 의료정보시스템이다. 대부분의 정신 건강 환자들은 전용 병원 치료를 필요로 하지 않지만, 그들의 문제에 대해 상세히 알고 있는 의사를 만날 수 있는 특별 병원에 정기적으로 가야 한다. 환자들이 더 쉽게 참석할 수 있도록 하기 위해, 이러한 클리닉들은 단지 병원에서만 운영되는 것이 아니다. 또한 지역 의료 관행이나 지역 사회 센터에서 개최될 수 있다.

멘탈 케어 시스템(그림 1.6)은 클리닉에서 사용하기 위한 환자 정보 시스템이다. 그것은 환자 정보의 중앙집중화된 데이터베이스를 이용하지만, 또한 안전한 네트워크 연결이 없는 사이트에서 접근하여 사용할 수 있도록 설계되었다. 로컬 시스템이 안전한 네트워크 접속을 할 때는 데이터베이스의 환자 정보를 이용하지만, 연결이 끊겼을 때는 환자 기록의 로컬 사본을 다운로드해 사용할 수 있다. 이 시스템은 완전한 의료 기록 시스템이 아니므로 다른 의료 조건에 대한 정보를 유지하지 않는다. 단, 다른 임상 정보 시스템과 상호 작용하고 데이터를 교환할 수 있다.

이 시스템은 두 가지 목적을 가지고 있다.

1. To generate management information that allows health service managers to assess performance against local and government targets.

2. To provide medical staff with timely information to support the treatment of patients.

3. 보건 서비스 관리자가 지방 및 정부 대상과 비교하여 성과를 평가할 수 있는 관리 정보를 생성한다.

4. 의료진에게 환자의 치료를 지원하기 위한 시기적절한 정보를 제공한다.

Patients who suffer from mental health problems are sometimes irrational and disorganized so may miss appointments, deliberately or accidentally lose prescriptions and medication, forget instructions and make unreasonable demands on medical staff. They may drop in on clinics unexpectedly. In a minority of cases, they may be a danger to themselves or to other people. They may regularly change address or may be homeless on a long-term or short-term basis. Where patients are dangerous, they may need to be “sectioned”—that is, confined to a secure hospital for treatment and observation.

Users of the system include clinical staff such as doctors, nurses, and health visi- tors (nurses who visit people at home to check on their treatment). Nonmedical users include receptionists who make appointments, medical records staff who maintain the records system, and administrative staff who generate reports.

The system is used to record information about patients (name, address, age, next of kin, etc.), consultations (date, doctor seen, subjective impressions of the patient, etc.), conditions, and treatments. Reports are generated at regular intervals for medi- cal staff and health authority managers. Typically, reports for medical staff focus on information about individual patients, whereas management reports are anonymized and are concerned with conditions, costs of treatment, etc.

The key features of the system are:

정신 건강 문제로 고통 받는 환자들은 때로 비이성적이고 체계적이지 못하기 때문에 약속을 놓치고, 고의적이거나 우발적으로 처방과 약을 잃어버리고, 지시를 잊어버리고 의료진에게 부당한 요구를 할 수도 있다. 그들은 예기치 않게 병원에 들를지도 모른다. 소수의 경우, 그들은 자신이나 다른 사람들에게 위험할 수 있다. 그들은 정기적으로 주소를 바꾸거나 장기 또는 단기적으로 노숙자가 될 수 있다. 환자가 위험한 경우, 치료와 관찰을 위해 안전한 병원에 격리되어야 할 수 있다.

이 시스템의 사용자에는 의사, 간호사, 건강 비주얼과 같은 의료진이 포함된다. 비의료 이용자는 진료 예약을 하는 접수원, 기록 시스템을 유지하는 의료기록 직원, 보고서를 작성하는 행정 직원 등이 있다.

이 시스템은 환자(이름, 주소, 나이, 혈연 등), 상담(날짜, 의사가 본 것, 환자의 주관적인 인상 등), 조건 및 치료에 관한 정보를 기록하는 데 사용된다. 중간 직원과 보건 당국 관리자를 위해 정기적으로 보고서가 생성된다. 일반적으로 의료진 보고서는 개별 환자에 대한 정보에 초점을 맞추고 있는 반면, 관리 보고서는 익명으로 되어 있고 조건, 치료 비용 등에 관심이 있다.

시스템의 주요 특징은 다음과 같다.

1. Individual care management Clinicians can create records for patients, edit the information in the system, view patient history, and so on. The system supports data summaries so that doctors who have not previously met a patient can quickly learn about the key problems and treatments that have been prescribed.

2. Patient monitoring The system regularly monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected. Therefore, if a patient has not seen a doctor for some time, a warning may be issued. One of the most important elements of the monitoring system is to keep track of patients who have been sectioned and to ensure that the legally required checks are carried out at the right time.

3. Administrative reporting The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, the number of patients sectioned, the drugs prescribed and their costs, etc.

4. 개별 진료 관리 클리닉은 환자 기록 작성, 시스템 내 정보 편집, 환자 기록 열람 등을 할 수 있다. 이 시스템은 이전에 환자를 만나지 않은 의사들이 처방된 주요 문제와 치료에 대해 신속하게 알 수 있도록 데이터 요약을 지원한다.

5. 환자감시시스템은 치료와 관련된 환자의 기록을 정기적으로 모니터링하고, 문제가 발견될 경우 경보를 발령한다. 따라서 환자가 한동안 의사를 보지 못한 경우에는 경고가 내려질 수도 있다. 모니터링 시스템의 가장 중요한 요소 중 하나는 분할된 환자를 추적하고 법적으로 요구되는 검사가 적시에 수행되는지 확인하는 것이다.

6. 행정신고제도는 각 진료소에서 진료받은 환자 수, 진료시스템에 출입한 환자 수, 구획된 환자 수, 처방받은 약품 및 비용 등을 보여주는 월별 관리보고서를 생성한다.

Two different laws affect the system: laws on data protection that govern the con- fidentiality of personal information and mental health laws that govern the compul- sory detention of patients deemed to be a danger to themselves or others. Mental health is unique in this respect as it is the only medical speciality that can recommend the detention of patients against their will. This is subject to strict legislative safe- guards. One aim of the Mentcare system is to ensure that staff always act in accord- ance with the law and that their decisions are recorded for judicial review if necessary. As in all medical systems, privacy is a critical system requirement. It is essential that patient information is confidential and is never disclosed to anyone apart from authorized medical staff and the patient themselves. The Mentcare system is also a safety-critical system. Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff

about potentially suicidal or dangerous patients.

The overall design of the system has to take into account privacy and safety requirements. The system must be available when needed; otherwise safety may be compromised, and it may be impossible to prescribe the correct medication to patients. There is a potential conflict here. Privacy is easiest to maintain when there is only a single copy of the system data. However, to ensure availability in the event of server failure or when disconnected from a network, multiple copies of the data should be maintained. I discuss the trade-offs between these requirements in later chapters.

두 가지 다른 법률이 시스템에 영향을 미친다. 즉, 개인 정보의 기밀성을 지배하는 데이터 보호에 관한 법률과 자신이나 다른 사람에게 위험하다고 여겨지는 환자에 대한 법적 구금을 지배하는 정신 건강법에 관한 법률이다. 정신건강은 그들의 의지에 반하여 환자의 구금을 권고할 수 있는 유일한 의학적인 특수성이기 때문에 이런 점에서 독특하다. 이것은 엄격한 법률상의 안전요원의 적용을 받는다. 의료 시스템의 한 가지 목표는 직원들이 항상 법에 따라 행동하고 필요한 경우 그들의 결정이 사법 검토를 위해 기록되도록 하는 것이다. 모든 의료 시스템에서와 마찬가지로 사생활은 중요한 시스템 요건이다. 환자 정보는 기밀이며 공인된 의료진과 환자 자신 외에는 누구에게도 절대로 공개되지 않는 것이 필수적이다. 멘탈 케어 시스템도 안전에 중요한 시스템이다. 어떤 정신 질환은 환자들이 자살하거나 다른 사람들에게 위험하게 만든다. 시스템은 가능하면 의료진에게 경고해야 한다.

자살하거나 위험한 환자에 대해서 말이야

시스템의 전체적인 설계는 프라이버시와 안전 요건을 고려해야 한다. 시스템은 필요할 때 사용할 수 있어야 한다. 그렇지 않으면 안전성이 저하될 수 있으며 환자에게 올바른 약을 처방하는 것이 불가능할 수 있다. 여기에는 잠재적인 갈등이 있다. 프라이버시는 시스템 데이터의 복사본이 한 개뿐일 때 유지하기가 가장 쉽다. 그러나 서버 장애 발생 시 또는 네트워크와의 연결이 끊어진 경우 가용성을 보장하기 위해 데이터 사본을 여러 개 유지해야 한다. 나는 이 요구사항들 사이의 절충에 대해 뒷 장에서 논한다.

1.3.3 황야 기상대(A wilderness weather station)

To help monitor climate change and to improve the accuracy of weather forecasts in remote areas, the government of a country with large areas of wilderness decides to deploy several hundred weather stations in remote areas. These weather stations col- lect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed and wind direction.

Wilderness weather stations are part of a larger system (Figure 1.7), which is a weather information system that collects data from weather stations and makes it available to other systems for processing. The systems in Figure 1.7 are:

기후변화를 감시하고 먼 지역의 일기예보의 정확성을 향상시키기 위해, 황무지가 넓은 나라 정부는 멀리 떨어진 지역에 수백 개의 기상 관측소를 배치하기로 결정한다. 이러한 기상 관측소는 온도와 압력, 햇빛, 강우량, 풍속 및 풍향을 측정하는 일련의 기구로부터 데이터를 수집한다.

와일더니스 기상 관측소는 더 큰 시스템(그림 1.7)의 일부로서 기상 관측소로부터 데이터를 수집하여 다른 시스템에서 처리할 수 있게 하는 기상 정보 시스템이다. 그림 1.7의 시스템은 다음과 같다.

1. The weather station system This system is responsible for collecting weather data, carrying out some initial data processing, and transmitting it to the data management system.

2. The data management and archiving system This system collects the data from all of the wilderness weather stations, carries out data processing and analysis, and archives the data in a form that can be retrieved by other systems, such as weather forecasting systems.

3. The station maintenance system This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and pro- vide reports of problems. It can update the embedded software in these systems. In the event of system problems, this system can also be used to remotely con- trol the weather station.

4. 기상 관측소 시스템 이 시스템은 기상 데이터를 수집하고, 초기 데이터 처리를 실시하며, 이를 데이터 관리 시스템에 전송하는 시스템이다.

5. 데이터 관리 및 보관 시스템 이 시스템은 모든 황무지 기상 관측소에서 데이터를 수집하여 데이터 처리 및 분석을 수행하고 기상 예보 시스템 등 다른 시스템에서 검색할 수 있는 형태로 데이터를 보관한다.

6. 정거장 정비 시스템 이 시스템은 모든 야생 기상 관측소와 위성으로 통신하여 이러한 시스템의 상태를 감시하고 문제의 비디오 보고를 할 수 있다. 그것은 이러한 시스템에 내장된 소프트웨어를 업데이트할 수 있다. 시스템 문제가 발생할 경우, 이 시스템은 또한 기상 관측소를 원격으로 연결하는 데 사용될 수 있다.

[Figure 1.7 The weather station’s environment]

In Figure 1.7, I have used the UML package symbol to indicate that each system is a collection of components and the separate systems are identified using the UML stereotype «system». The associations between the packages indicate there is an exchange of information but, at this stage, there is no need to define them in any more detail.

The weather stations include instruments that measure weather parameters such as wind speed and direction, ground and air temperatures, barometric pressure, and rainfall over a 24-hour period. Each of these instruments is controlled by a software system that takes parameter readings periodically and manages the data collected from the instruments.

The weather station system operates by collecting weather observations at fre- quent intervals; for example, temperatures are measured every minute. However, because the bandwidth to the satellite is relatively narrow, the weather station carries out some local processing and aggregation of the data. It then transmits this aggre- gated data when requested by the data collection system. If it is impossible to make a connection, then the weather station maintains the data locally until communica- tion can be resumed.

Each weather station is battery-powered and must be entirely self-contained; there are no external power or network cables. All communications are through a relatively slow satellite link, and the weather station must include some mechanism (solar or wind power) to charge its batteries. As they are deployed in wilderness areas, they are exposed to severe environmental conditions and may be damaged by animals. The station software is therefore not just concerned with data collection. It must also:

그림 1.7에서 나는 UML 패키지 기호를 사용하여 각 시스템이 구성요소의 집합이고 UML 고정관념인 «시스템 »를 사용하여 별도의 시스템을 식별했음을 표시했다. 패키지 사이의 연관성은 정보 교환이 있음을 나타내지만, 이 단계에서는 더 이상 그것들을 상세히 정의할 필요가 없다.

기상 관측소에는 풍속과 방향, 지면과 공기 온도, 기압, 24시간 동안의 강우량과 같은 기상 변수를 측정하는 기구가 포함되어 있다. 이러한 각 계측기는 정기적으로 파라미터를 판독하고 계측기에서 수집한 데이터를 관리하는 소프트웨어 시스템에 의해 제어된다.

기상 관측소 시스템은 기상 관측을 자유자재로 수집하여 작동한다. 예를 들어, 온도는 매 분마다 측정된다. 그러나 위성까지의 대역폭이 비교적 좁기 때문에 기상국은 데이터의 국지적 처리와 집계를 어느 정도 수행한다. 그런 다음 데이터 수집 시스템의 요청에 따라 이 애그리게이트된 데이터를 전송한다. 연결이 불가능할 경우, 기상국은 통신이 재개될 때까지 데이터를 국지적으로 유지한다.

각 기상 관측소는 배터리로 작동하며, 외부 전원이나 네트워크 케이블이 없기 때문에 완전히 자체 수용되어야 한다. 모든 통신은 비교적 느린 위성 링크를 통해 이루어지며, 기상 관측소는 배터리를 충전하기 위한 몇 가지 메커니즘(솔라 또는 풍력 발전)을 포함해야 한다. 황무지에 배치되기 때문에 심각한 환경 조건에 노출되어 동물에 의해 훼손될 수 있다. 그러므로 스테이션 소프트웨어는 데이터 수집에만 관심이 있는 것이 아니다. 또한 다음을 수행해야 한다.

1. Monitor the instruments, power. and communication hardware and report faults to the management system.

2. Manage the system power, ensuring that batteries are charged whenever the environmental conditions permit but also that generators are shut down in potentially damaging weather conditions, such as high wind.

3. Allow for dynamic reconfiguration where parts of the software are replaced with new versions and where backup instruments are switched into the system in the event of system failure.

4. 계측기, 전력, 통신하드웨어를 모니터링하여 관리시스템에 고장을 보고한다.

5. 시스템 전원을 관리하여 환경 조건이 허락될 때마다 배터리를 충전하고 강풍과 같은 악천후에서 발전기가 정지되도록 한다.

6. 소프트웨어의 일부가 새 버전으로 교체되는 동적 재구성을 허용하고, 시스템 고장 시 백업 기기를 시스템으로 전환하는 경우.

Because weather stations have to be self-contained and unattended, this means that the software installed is complex, even though the data collection functionality is fairly simple.

기상 관측소는 자급자족하고 무인화되어야 하기 때문에 데이터 수집 기능이 상당히 간단하지만 설치된 소프트웨어가 복잡하다는 것을 의미한다.

1.3.4 학교를 위한 디지털 학습 환경(A digital learning environment for schools)

Many teachers argue that using interactive software systems to support education can lead to both improved learner motivation and a deeper level of knowledge and understanding in students. However, there is no general agreement on the ‘best’ strategy for computer-supported learning, and teachers in practice use a range of dif- ferent interactive, web-based tools to support learning. The tools used depend on the ages of the learners, their cultural background, their experience with computers, equipment available, and the preferences of the teachers involved.

A digital learning environment is a framework in which a set of general-purpose and specially designed tools for learning may be embedded, plus a set of applica- tions that are geared to the needs of the learners using the system. The framework provides general services such as an authentication service, synchronous and asyn- chronous communication services, and a storage service.

The tools included in each version of the environment are chosen by teachers and learners to suit their specific needs. These can be general applications such as spread- sheets, learning management applications such as a Virtual Learning Environment (VLE) to manage homework submission and assessment, games, and simulations. They may also include specific content, such as content about the American Civil War and applications to view and annotate that content.

Figure 1.8 is a high-level architectural model of a digital learning environment (iLearn) that was designed for use in schools for students from 3 to 18 years of age. The approach adopted is that this is a distributed system in which all compo- nents of the environment are services that can be accessed from anywhere on the Internet. There is no requirement that all of the learning tools are gathered together in one place.

The system is a service-oriented system with all system components considered to be a replaceable service. There are three types of service in the system:

많은 교사들은 교육을 지원하기 위해 대화형 소프트웨어 시스템을 사용하는 것이 학습자의 동기를 향상시키고 학생들에게 더 깊은 수준의 지식과 이해를 가져다 줄 수 있다고 주장한다. 그러나, 컴퓨터 지원 학습을 위한 ‘최상의’ 전략에 대한 일반적인 동의는 없으며, 실제로 교사들은 학습을 지원하기 위해 다양한 쌍방향, 웹 기반 도구를 사용한다. 사용되는 도구는 학습자의 연령, 문화적 배경, 컴퓨터 사용 경험, 사용 가능한 장비, 관련 교사들의 선호도에 따라 달라진다.

디지털 학습 환경은 시스템을 사용하는 학습자의 요구에 맞는 범용 및 특수하게 설계된 도구 세트가 포함될 수 있는 프레임워크다. 프레임워크는 인증 서비스, 동기식 및 동기식 통신 서비스, 스토리지 서비스와 같은 일반적인 서비스를 제공한다.

환경의 각 버전에 포함된 도구는 교사나 학습자가 자신의 특정 요구에 맞게 선택한다. 이는 스프레드시트, 숙제 제출 및 평가, 게임, 시뮬레이션을 관리하기 위한 VLE(Virtual Learning Environment)와 같은 학습 관리 애플리케이션과 같은 일반적인 애플리케이션이 될 수 있다. 또한 미국 남북전쟁에 관한 내용과 그 내용을 보고 주석을 달기 위한 응용 프로그램과 같은 특정 내용을 포함할 수 있다.

그림 1.8은 3세에서 18세 사이의 학생들을 위해 학교에서 사용하도록 설계된 디지털 학습 환경(iLearn)의 높은 수준의 건축 모델이다. 채택된 접근법은 환경의 모든 구성 요소가 인터넷 어디에서나 액세스할 수 있는 서비스인 분산 시스템이라는 것이다. 모든 학습 도구들이 한 곳에 모일 필요는 없다.

이 시스템은 교체 가능한 서비스로 간주되는 모든 시스템 구성요소를 갖춘 서비스 지향 시스템이다. 시스템에는 세 가지 유형의 서비스가 있다.

1. Utility services that provide basic application-independent functionality and that may be used by other services in the system. Utility services are usually developed or adapted specifically for this system.

2. Application services that provide specific applications such as email, conferencing, photo sharing, etc., and access to specific educational content such as scientific films or historical resources. Application services are external services that are either specifically purchased for the system or are available freely over the Internet.

3. Configuration services that are used to adapt the environment with a specific set of application services and to define how services are shared between students, teachers, and their parents.

4. 기본적인 애플리케이션 독립적 기능을 제공하고 시스템의 다른 서비스에서 사용할 수 있는 유틸리티 서비스. 유틸리티 서비스는 대개 이 시스템을 위해 특별히 개발되거나 조정된다.

5. 이메일, 회의, 사진 공유 등 특정 어플리케이션을 제공하고 과학영화나 역사자원 등 특정 교육 콘텐츠에 접속하는 어플리케이션 서비스 애플리케이션 서비스는 시스템을 위해 특별히 구매하거나 인터넷을 통해 자유롭게 이용할 수 있는 외부 서비스다.

6. 특정 애플리케이션 서비스로 환경을 적응시키고, 학생, 교사, 부모 사이에 서비스가 어떻게 공유되는지를 정의하는 데 사용되는 구성 서비스.

[Figure 1.8 The architecture of a digital learning environment (iLearn)]

The environment has been designed so that services can be replaced as new ser- vices become available and to provide different versions of the system that are suited for the age of the users. This means that the system has to support two levels of ser- vice integration:

환경은 새로운 서비스를 이용할 수 있게 되면서 서비스를 교체할 수 있도록 설계되었으며, 사용자의 연령에 맞는 다른 버전의 시스템을 제공하도록 설계되었다. 이는 시스템이 다음과 같은 두 가지 수준의 ser-vi 통합을 지원해야 한다.

1. Integrated services are services that offer an API (application programming interface) and that can be accessed by other services through that API. Direct service-to-service communication is therefore possible. An authentication ser- vice is an example of an integrated service. Rather than use their own authenti- cation mechanisms, an authentication service may be called on by other services to authenticate users. If users are already authenticated, then the authentication service may pass authentication information directly to another service, via an API, with no need for users to reauthenticate themselves.

2. Independent services are services that are simply accessed through a browser interface and that operate independently of other services. Information can only be shared with other services through explicit user actions such as copy and paste; reauthentication may be required for each independent service.

3. 통합 서비스는 API(응용프로그램 프로그래밍 인터페이스)를 제공하고, 그 API를 통해 다른 서비스에서 접속할 수 있는 서비스다. 그러므로 서비스 간 직접 통신이 가능하다. 인증 ser-voice는 통합 서비스의 한 예다. 자체 인증 메커니즘을 사용하는 대신, 다른 서비스에서 사용자를 인증하기 위해 인증 서비스를 요청할 수 있다. 사용자가 이미 인증된 경우, 인증 서비스는 사용자가 직접 인증할 필요 없이 API를 통해 다른 서비스에 인증 정보를 직접 전달할 수 있다.

4. 독립적 서비스는 브라우저 인터페이스를 통해 간단히 접속하여 다른 서비스와 독립적으로 동작하는 서비스다. 정보는 복사 및 붙여넣기 같은 명시적 사용자 행동을 통해서만 다른 서비스와 공유할 수 있다. 각 독립적 서비스에 대해 재인증이 필요할 수 있다.

If an independent service becomes widely used, the development team may then integrate that service so that it becomes an integrated and supported service.

독립적 서비스가 널리 사용될 경우, 개발팀은 그 서비스를 통합하여 그것이 통합되고 지원되는 서비스가 되도록 할 수 있다.

Key Points

■ Software engineering is an engineering discipline that is concerned with all aspects of software production.

■ Software is not just a program or programs but also includes all electronic documentation that is needed by system users, quality assurance staff, and developers. Essential software product attributes are maintainability, dependability and security, efficiency, and acceptability.

■ The software process includes all of the activities involved in software development. The high-level activities of specification, development, validation, and evolution are part of all software processes.

■ There are many different types of system, and each requires appropriate software engineering tools and techniques for their development. Few, if any, specific design and implementation techniques are applicable to all kinds of system.

■ The fundamental ideas of software engineering are applicable to all types of software system. These fundamentals include managed software processes, software dependability and security, requirements engineering, and software reuse.

■ Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues but should be aware of the ethical issues that affect their work.

■ Professional societies publish codes of conduct that embed ethical and professional standards. These set out the standards of behavior expected of their members.

■ 소프트웨어 엔지니어링은 소프트웨어 생산의 모든 측면과 관련된 공학 분야 입니다.

■ 소프트웨어는 프로그램이나 프로그램뿐 아니라 시스템 사용자, 품질보증 직원, 개발자가 필요로 하는 모든 전자문서를 포함한다. 필수 소프트웨어 제품 속성은 유지관리성, 신뢰성 및 보안성, 효율성 및 수용성이다.

■ 소프트웨어 프로세스에는 소프트웨어 개발에 관련된 모든 활동이 포함된다. 사양, 개발, 검증 및 진화의 높은 수준의 활동은 모든 소프트웨어 프로세스의 일부분이다.

■ 시스템 종류는 다양하며, 각각 적절한 소프트웨어 엔지니어링 도구와 기술이 필요하다. 모든 종류의 시스템에 적용할 수 있는 특정 설계 및 구현 기법은 거의 없다.

■ 소프트웨어 공학의 기본이념은 모든 종류의 소프트웨어 시스템에 적용된다. 이러한 기본 원칙에는 중앙 관리 소프트웨어 프로세스, 소프트웨어 신뢰성 및 보안, 요구사항 엔지니어링 및 소프트웨어 재사용 등이 포함된다.

■ 소프트웨어 엔지니어는 엔지니어링 직업과 사회에 대한 책임을 진다. 그들은 단순히 기술적인 문제에만 관심을 가질 것이 아니라 그들의 일에 영향을 미치는 윤리적 문제를 알아야 한다.

■ 윤리적·전문적 기준을 담은 행동강령을 전문사회에서 발표한다. 이것은 회원들이 기대하는 행동의 기준을 제시한다.

Further reading

“Software Engineering Code of Ethics Is Approved.” An article that discusses the background to the development of the ACM/IEEE Code of Ethics and that includes both the short and long form of the code. (Comm. ACM, D. Gotterbarn, K. Miller, and S. Rogerson, October 1999). http://dx.doi. org/10.1109/MC.1999.796142

“A View of 20th and 21st Century Software Engineering.” A backward and forward look at software engineering from one of the first and most distinguished software engineers. Barry Boehm identifies timeless software engineering principles but also suggests that some commonly used practices are obsolete. (B. Boehm, Proc. 28th Software Engineering Conf., Shanghai. 2006). http://dx.doi. org/10.1145/1134285.1134288

“Software Engineering Ethics.” Special issue of IEEE Computer, with several papers on the topic (IEEE Computer, 42 (6), June 2009).

Ethics for the Information Age. This is a wide-ranging book that covers all aspects of information technology (IT) ethics, not simply ethics for software engineers. I think this is the right approach as you really need to understand software engineering ethics within a wider ethical framework (M. J. Quinn, 2013, Addison-Wesley).

The Essence of Software Engineering: Applying the SEMAT kernel. This book discusses the idea of a universal framework that can underlie all software engineering methods. It can be adapted and used for all types of systems and organizations. I am personally skeptical about whether or not a universal approach is realistic in practice, but the book has some interesting ideas that are worth exploring. (I. Jacobsen, P-W Ng, P. E. McMahon, I. Spence, and S. Lidman, 2013, Addison-Wesley)

“소프트웨어 엔지니어링 윤리 강령 승인” ACM/IEEEE 윤리강령의 개발 배경에 대해 논의하고 코드의 짧고 긴 형식을 모두 포함하는 기사. (Comm. ACM, D. Gotterbarn, K. Miller, S. 로거슨, 1999년 10월). http://dx.doi 조직/10.1109/MC.1999.796142

“20, 21세기 소프트웨어 엔지니어링의 전망” 최초이자 가장 뛰어난 소프트웨어 엔지니어 중 한 명의 소프트웨어 엔지니어링을 역방향 및 전진적으로 살펴본다. 배리 보옴은 시대를 초월한 소프트웨어 엔지니어링 원칙을 확인하지만, 또한 일반적으로 사용되는 일부 관행이 쓸모없음을 시사한다. (B. Boehm, Proc. 28th Software Engineering Conf., 상하이. 2006) http://dx.doi 조직/10.1145/1134285.1134288

“소프트웨어 엔지니어링 윤리” IEEE Computer의 특별 발행(IEEE Computer, 42(6), 2009년 6월).

정보화 시대의 윤리. 단순한 소프트웨어 기술자의 윤리가 아니라 정보기술(IT) 윤리의 모든 측면을 아우르는 광범한 책이다. 나는 이것이 올바른 접근이라고 생각한다. 왜냐하면 당신이 소프트웨어 공학 윤리를 더 넓은 윤리적 틀 안에서 진정으로 이해할 필요가 있기 때문이다(M. J. Quinn, 2013, Addison-Wesley).

소프트웨어 엔지니어링의 정수: SEMAT 커널 적용. 이 책은 모든 소프트웨어 공학 방법의 기초가 될 수 있는 보편적 프레임워크의 아이디어를 논하고 있다. 그것은 모든 종류의 시스템과 조직에 적응하고 사용될 수 있다. 나는 개인적으로 보편적 접근법이 실제적인지에 대해 회의적이지만, 이 책은 탐구할 가치가 있는 몇 가지 흥미로운 아이디어를 가지고 있다. (I. Jacobsen, P-W Ng, P. E. McMahon, I. Spence, 2013, Addison-Wesley)

Web Site

PowerPoint slides for this chapter: www.pearsonglobaleditions.com/Sommerville Links to supporting videos:

http://software-engineering-book.com/videos/software-engineering/ Links to case study descriptions:

http://software-engineering-book.com/case-studies/

Exercises

1.1. Explain why professional software that is developed for a customer is not simply the programs that have been developed and delivered.

1.2. What is the most important difference between generic software product development and custom software development? What might this mean in practice for users of generic software products?

1.3. Briefly discuss why it is usually cheaper in the long run to use software engineering methods and techniques for software systems.

1.4. Software engineering is not only concerned with issues like system heterogeneity, business and social change, trust, and security, but also with ethical issues affecting the domain. Give some examples of ethical issues that have an impact on the software engineering domain.

1.5. Based on your own knowledge of some of the application types discussed in Section 1.1.2, explain, with examples, why different application types require specialized software engineering techniques to support their design and development.

1.6. Explain why the fundamental software engineering principles of process, dependability, requirements management, and reuse are relevant to all types of software system.

1.7. Explain how electronic connectivity between various development teams can support software engineering activities.

1.8. Noncertified individuals are still allowed to practice software engineering. Discuss some of the possible drawbacks of this.

1.9. For each of the clauses in the ACM/IEEE Code of Ethics shown in Figure 1.4, propose an appropriate example that illustrates that clause.

1.10. The “Drone Revolution” is currently being debated and discussed all over the world. Drones are unmanned flying machines that are built and equipped with various kinds of software systems that allow them to see, hear, and act. Discuss some of the societal challenges of building such kinds of systems.

1.1. 고객을 위해 개발된 전문 소프트웨어가 단순히 개발되고 전달된 프로그램이 아닌 이유를 설명하십시오.

1.2. 일반적인 소프트웨어 제품 개발과 사용자 정의 소프트웨어 개발 사이의 가장 중요한 차이점은 무엇인가? 이것이 실제로 일반적인 소프트웨어 제품 사용자들에게 무엇을 의미할까?

1.3. 소프트웨어 시스템에 소프트웨어 엔지니어링 방법과 기술을 사용하는 것이 왜 장기적으로 더 저렴한지 간략하게 논하라.

1.4. 소프트웨어 엔지니어링은 시스템 이질성, 비즈니스 및 사회 변화, 신뢰 및 보안과 같은 문제뿐만 아니라 도메인에 영향을 미치는 윤리적 문제에도 관여한다. 소프트웨어 엔지니어링 영역에 영향을 미치는 윤리적 문제의 몇 가지 예를 들어보십시오.

1.5. 섹션 1.1.2에서 논의된 일부 응용 프로그램 유형에 대한 사용자 자신의 지식을 바탕으로 다양한 응용 프로그램 유형이 설계 및 개발을 지원하기 위해 전문 소프트웨어 엔지니어링 기법을 필요로 하는 이유를 예를 들어 설명하십시오.

1.6. 프로세스, 신뢰성, 요건 관리 및 재사용과 같은 기본적인 소프트웨어 엔지니어링 원칙이 모든 유형의 소프트웨어 시스템과 관련이 있는 이유를 설명하십시오.

1.7. 다양한 개발 팀 간의 전자 연결이 어떻게 소프트웨어 엔지니어링 활동을 지원할 수 있는지 설명하십시오.

1.8. 인증되지 않은 개인들은 여전히 소프트웨어 공학을 연습할 수 있다. 이것의 가능한 단점들 중 몇 가지를 논하라.

1.9. 그림 1.4에 표시된 ACM/IEEE 윤리 강령의 각 절에 대해 해당 조항을 설명하는 적절한 예를 제안하십시오.

1.10. “드론 혁명”은 현재 전세계에서 논의되고 있다. 드론은 보고 듣고 행동할 수 있는 다양한 종류의 소프트웨어 시스템을 구축하여 갖추고 있는 무인 비행 기계다. 그러한 종류의 시스템을 구축하는 데 있어 사회적 난제 중 몇 가지를 논하라.

2. Software processes(소프트웨어 프로세스)

Objectives

The objective of this chapter is to introduce you to the idea of a software process—a coherent set of activities for software production. When you have read this chapter, you will:

■ understand the concepts of software processes and software process models;

■ have been introduced to three general software process models and when they might be used;

■ know about the fundamental process activities of software requirements engineering, software development, testing, and evolution;

■ understand why processes should be organized to cope with changes in the software requirements and design;

■ understand the notion of software process improvement and the factors that affect software process quality.

이 장의 목적은 소프트웨어 프로세스의 개념, 즉 소프트웨어 생산을 위한 일관성 있는 일련의 활동을 여러분에게 소개하는 것이다. 이 장을 읽으면 다음과 같이 된다.

■ 소프트웨어 프로세스 및 소프트웨어 프로세스 모델의 개념을 이해한다.

■ 세 가지 일반 소프트웨어 프로세스 모델을 도입했으며 언제 사용할 수 있는지 여부

■ 소프트웨어 요구사항 엔지니어링, 소프트웨어 개발, 테스트 및 진화의 기본 프로세스 활동에 대해 알고 있다.

■ 소프트웨어 요구사항 및 설계의 변화에 대처하기 위해 프로세스를 구성해야 하는 이유를 이해한다.

■ 소프트웨어 프로세스 개선의 개념과 소프트웨어 프로세스 품질에 영향을 미치는 요인을 이해한다.

Contents

2.1 소프트웨어 프로세스 모델(Software process models)

2.2 프로세스 액티비티(Process activities)

2.3 변경 사항 복사???(Coping with change)

2.4 프로세스 개선(Process improvement)

A software process is a set of related activities that leads to the production of a soft- ware system. As I discussed in Chapter 1, there are many different types of software systems, and there is no universal software engineering method that is applicable to all of them. Consequently, there is no universally applicable software process. The process used in different companies depends on the type of software being devel- oped, the requirements of the software customer, and the skills of the people writing the software.

However, although there are many different software processes, they all must include, in some form, the four fundamental software engineering activities that I introduced in Chapter 1:

소프트웨어 프로세스는 소프트웨어 시스템의 생산으로 이어지는 일련의 관련 활동이다. 1장에서 논의한 바와 같이, 소프트웨어 시스템의 종류는 매우 다양하며, 그 모든 것에 적용할 수 있는 범용 소프트웨어 엔지니어링 방법은 없다. 결과적으로, 보편적으로 적용할 수 있는 소프트웨어 프로세스는 없다. 다른 회사에서 사용되는 프로세스는 개발 중인 소프트웨어의 유형, 소프트웨어 고객의 요구 사항, 그리고 소프트웨어를 작성하는 사람들의 기술에 따라 달라진다.

그러나 소프트웨어 프로세스는 여러 가지가 있지만 모두 어떤 형태로든 1장에서 소개한 4가지 기본적인 소프트웨어 엔지니어링 활동을 포함해야 한다.

1. Software specification The functionality of the software and constraints on its operation must be defined.

2. Software development The software to meet the specification must be produced.

3. Software validation The software must be validated to ensure that it does what the customer wants.

4. Software evolution The software must evolve to meet changing customer needs.

5. 소프트웨어 사양 소프트웨어의 기능성과 그 운용상의 제약이 규정되어야 한다.

6. 소프트웨어 개발 규격에 부합하는 소프트웨어는 반드시 생산되어야 한다.

7. 소프트웨어 유효성 확인 소프트웨어는 고객이 원하는 대로 작동하는지 확인해야 한다.

8. 소프트웨어 진화 소프트웨어는 변화하는 고객 요구에 맞게 진화해야 한다.

These activities are complex activities in themselves, and they include subactivi- ties such as requirements validation, architectural design, and unit testing. Processes also include other activities, such as software configuration management and project planning that support production activities.

When we describe and discuss processes, we usually talk about the activities in these processes, such as specifying a data model and designing a user interface, and the ordering of these activities. We can all relate to what people do to develop soft- ware. However, when describing processes, it is also important to describe who is involved, what is produced, and conditions that influence the sequence of activities:

이러한 활동은 그 자체로 복잡한 활동이며, 요구사항 검증, 아키텍처 설계 및 단위 시험과 같은 하위 활동을 포함한다. 프로세스에는 생산 활동을 지원하는 소프트웨어 구성 관리 및 프로젝트 계획과 같은 다른 활동도 포함된다.

프로세스를 기술하고 논의할 때, 데이터 모델을 지정하고 사용자 인터페이스를 설계하는 등 이러한 프로세스의 활동과 이러한 활동의 순서에 대해 주로 이야기한다. 우리는 모두 사람들이 소프트 웨어 개발을 위해 무엇을 하는지 공감할 수 있다. 단, 프로세스를 기술할 때, 활동의 순서에 영향을 미치는 사람, 생산되는 것, 조건을 기술하는 것도 중요하다.

1. Products or deliverables are the outcomes of a process activity. For example, the outcome of the activity of architectural design may be a model of the software architecture.

2. Roles reflect the responsibilities of the people involved in the process. Examples of roles are project manager, configuration manager, and programmer.

3. Pre- and postconditions are conditions that must hold before and after a process activity has been enacted or a product produced. For example, before architec- tural design begins, a precondition may be that the consumer has approved all requirements; after this activity is finished, a postcondition might be that the UML models describing the architecture have been reviewed.

4. 제품 또는 결과물은 프로세스 활동의 결과물이다. 예를 들어, 구조 설계 활동의 결과는 소프트웨어 아키텍처의 모델이 될 수 있다.

5. 역할은 그 과정에 관련된 사람들의 책임을 반영한다. 역할의 예로는 프로젝트 매니저, 구성 매니저, 프로그래머 등이 있다.

6. 전·후조건은 공정활동이 성립되기 전·후에 반드시 지켜야 할 조건 또는 생산물을 말한다. 예를 들어, 구획 설계가 시작되기 전에 소비자가 모든 요건을 승인하는 것이 전제조건일 수 있다. 이 활동이 완료된 후, 구조를 설명하는 UML 모델이 검토되는 것이 사후 조건일 수 있다.

Software processes are complex and, like all intellectual and creative processes, rely on people making decisions and judgments. As there is no universal process that is right for all kinds of software, most software companies have developed their own

development processes. Processes have evolved to take advantage of the capabilities of the software developers in an organization and the characteristics of the systems that are being developed. For safety-critical systems, a very structured development process is required where detailed records are maintained. For business systems, with rapidly changing requirements, a more flexible, agile process is likely to be better.

As I discussed in Chapter 1, professional Professional software development is a managed activity, so planning is an inherent part of all processes. Plan-driven pro- cesses are processes where all of the process activities are planned in advance and progress is measured against this plan. In agile processes, which I discuss in Chapter 3, planning is incremental and continual as the software is developed. It is therefore eas- ier to change the process to reflect changing customer or product requirements. As Boehm and Turner (Boehm and Turner 2004) explain, each approach is suitable for different types of software. Generally, for large systems, you need to find a balance between plan-driven and agile processes.

Although there is no universal software process, there is scope for process improve- ment in many organizations. Processes may include outdated techniques or may not take advantage of the best practice in industrial software engineering. Indeed, many organizations still do not take advantage of software engineering methods in their software development. They can improve their process by introducing techniques such as UML modeling and test-driven development. I discuss software process improvement briefly later in thischapter text and in more detail in web Chapter 26.

소프트웨어 프로세스는 복잡하며 모든 지적 및 창조적 프로세스와 마찬가지로 사람들이 의사결정과 판단을 내리는 데 의존한다. 모든 종류의 소프트웨어에 적합한 보편적 프로세스가 없기 때문에, 대부분의 소프트웨어 회사들은 그들 자신의 것을 개발했다.

개발 과정 프로세스는 조직에서 소프트웨어 개발자의 역량과 개발 중인 시스템의 특성을 활용하도록 진화했다. 안전에 중요한 시스템의 경우 상세 기록이 유지되는 경우 매우 구조화된 개발 프로세스가 필요하다. 비즈니스 시스템의 경우 요구사항이 빠르게 변경되면 보다 유연하고 민첩한 프로세스가 더 나을 수 있다.

1장에서 논의한 바와 같이 전문적 프로페셔널 소프트웨어 개발은 관리되는 활동이므로 기획은 모든 프로세스의 본질적인 부분이다. 계획 주도형 추진은 모든 공정 활동을 사전에 계획하여 이 계획에 대비하여 진행상황을 측정하는 공정이다. 3장에서 논하는 민첩한 프로세스에서 계획 수립은 소프트웨어가 개발될 때 점진적이고 지속적으로 이루어진다. 따라서 변화하는 고객 또는 제품 요구 사항을 반영하기 위해 프로세스를 변경하는 것이 더 쉽다. Boehm과 Turner (Boehm과 Turner 2004)가 설명하듯이, 각각의 접근방식은 다른 유형의 소프트웨어에 적합하다. 일반적으로 대형 시스템의 경우 계획 중심 프로세스와 민첩한 프로세스 간의 균형을 찾아야 한다.

보편적인 소프트웨어 프로세스는 없지만, 많은 조직에서 프로세스 개선의 여지가 있다. 프로세스는 구식 기법을 포함하거나 산업 소프트웨어 엔지니어링의 모범 사례를 이용하지 않을 수 있다. 실제로, 많은 조직들은 여전히 그들의 소프트웨어 개발에서 소프트웨어 공학 방법을 이용하지 않는다. UML 모델링, 테스트 기반 개발 등의 기법을 도입해 공정을 개선할 수 있다. 나는 이 장 뒷부분에서 소프트웨어 프로세스 개선에 대해 간략하게 그리고 웹 26장에서 더 자세히 논한다.

2.1 소프트웨어 프로세스 모델(Software process models)

As I explained in Chapter 1, a software process model (sometimes called a Software Development Life Cycle or SDLC model) is a simplified representation of a soft- ware process. Each process model represents a process from a particular perspective and thus only provides partial information about that process. For example, a pro- cess activity model shows the activities and their sequence but may not show the roles of the people involved in these activities. In this section, I introduce a number of very general process models (sometimes called process paradigms) and present these from an architectural perspective. That is, we see the framework of the process but not the details of process activities.

These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more specific software engineering processes.

The general process models that I cover here are:

1장에서 설명했듯이 소프트웨어 프로세스 모델(Software Development Life Cycle 또는 SDLC 모델이라고도 함)은 소프트웨어 프로세스의 단순화된 표현이다. 각 프로세스 모델은 특정 관점에서 프로세스를 나타내며 따라서 해당 프로세스에 대한 부분적인 정보만 제공한다. 예를 들어, 예비 활동 모델은 활동과 그 순서를 보여주지만 이러한 활동에 관련된 사람들의 역할은 보여주지 않을 수 있다. 이 절에서 나는 많은 매우 일반적인 프로세스 모델(프로세스 패러다임이라고도 함)을 소개하고 이것을 건축적 관점에서 제시한다. 즉, 프로세스의 프레임워크를 보지만 프로세스 활동의 세부 사항은 보지 않는다.

이러한 일반적인 모델은 소프트웨어 개발에 대한 다른 접근법을 설명하는 데 사용될 수 있는 높은 수준의 추상적인 소프트웨어 프로세스 설명이다. 당신은 그것들을 더 구체적인 소프트웨어 엔지니어링 프로세스를 만들기 위해 확장되고 조정될 수 있는 프로세스 프레임워크라고 생각할 수 있다.

여기서 다루는 일반적인 프로세스 모델은 다음과 같다.

1. The waterfall model This takes the fundamental process activities of specifica- tion, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implemen- tation, and testing.

2. Incremental development This approach interleaves the activities of specifica- tion, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.

3. Integration and configuration This approach relies on the availability of reus- able components or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system.

4. 폭포수 모델 이것은 구체화, 개발, 검증 및 진화의 기본 프로세스 활동을 취하며, 요구사항 사양, 소프트웨어 설계, 임플란트 및 시험과 같은 별도의 프로세스 단계로 표현한다.

5. 증분적 개발 이 접근방식은 특정, 개발 및 검증의 활동을 방해한다. 시스템은 일련의 버전(증가)으로 개발되며, 각 버전은 이전 버전에 기능을 추가한다.

6. 통합 및 구성 이 접근법은 재사용 가능한 구성 요소 또는 시스템의 가용성에 의존한다. 시스템 개발 프로세스는 이러한 구성요소를 새로운 설정에서 사용하도록 구성하고 이를 시스템으로 통합하는 데 초점을 맞추고 있다.

The Rational Unified Process

The Rational Unified Process (RUP) brings together elements of all of the general process models discussed here and supports prototyping and incremental delivery of software (Krutchen 2003). The RUP is normally described from three perspectives: a dynamic perspective that shows the phases of the model in time, a static perspective that shows process activities, and a practice perspective that suggests good practices to be used in the process. Phases of the RUP are inception, where a business case for the system is established; elaboration, where requirements and architecture are developed; construction where the software is implemented; and transition, where the system is deployed.

합리적 통합 프로세스

RUP(Rational Unified Process)는 여기에서 논의된 모든 일반 프로세스 모델의 요소를 통합하고 소프트웨어의 프로토타이핑 및 증분 제공을 지원한다(Krutchen 2003). RUP는 일반적으로 세 가지 관점에서 설명된다. 즉, 시간 내에 모델의 단계를 보여주는 동적 관점, 프로세스 활동을 보여주는 정적 관점, 프로세스에서 사용할 수 있는 모범 사례를 제시하는 실천적 관점이다. RUP의 단계는 시스템을 위한 비즈니스 사례가 수립되는 개시, 요구사항과 아키텍처가 개발되는 정교함, 소프트웨어가 구현되는 시공 및 시스템이 전개되는 전환이다.

http://software-engineering-book.com/web/rup/

As I have said, there is no universal process model that is right for all kinds of software development. The right process depends on the customer and regulatory requirements, the environment where the software will be used, and the type of soft- ware being developed. For example, safety-critical software is usually developed using a waterfall process as lots of analysis and documentation is required before implementation begins. Software products are now always developed using an incre- mental process model. Business systems are increasingly being developed by con- figuring existing systems and integrating these to create a new system with the functionality that is required.

The majority of practical software processes are based on a general model but often incorporate features of other models. This is particularly true for large systems engineering. For large systems, it makes sense to combine some of the best features of all of the general processes. You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop this incrementally. Subsystems within a larger system may be developed using different approaches. Parts of the system that are well understood can be specified and developed using a waterfall-based process or may be bought in as off-the-shelf systems for configuration. Other parts of the system, which are dif- ficult to specify in advance, should always be developed using an incremental approach. In both cases, software components are likely to be reused.

Various attempts have been made to develop “universal” process models that draw on all of these general models. One of the best known of these universal models is the Rational Unified Process (RUP) (Krutchen 2003), which was developed by Rational, a U.S. software engineering company. The RUP is a flexible model that can be instantiated in different ways to create processes that resemble any of the general process models discussed here. The RUP has been adopted by some large software companies (notably IBM), but it has not gained widespread acceptance.

내가 말했듯이, 모든 종류의 소프트웨어 개발에 적합한 보편적 프로세스 모델은 없다. 올바른 프로세스는 고객과 규제 요건, 소프트웨어가 사용될 환경, 개발 중인 소프트웨어 유형에 따라 달라진다. 예를 들어, 구현을 시작하기 전에 많은 분석과 문서화가 필요하기 때문에 안전성에 중요한 소프트웨어는 보통 폭포 프로세스를 사용하여 개발된다. 소프트웨어 제품은 이제 항상 정신 프로세스 모델을 사용하여 개발된다. 비즈니스 시스템은 기존 시스템을 파악하여 이를 통합하여 필요한 기능을 갖춘 새로운 시스템을 구축함으로써 점점 더 발전하고 있다.

대부분의 실용적인 소프트웨어 프로세스는 일반 모델에 기초하지만 종종 다른 모델의 특징을 포함한다. 이것은 특히 대형 시스템 엔지니어링에 적용된다. 대형 시스템의 경우, 모든 일반 프로세스의 가장 좋은 기능 중 일부를 결합하는 것이 타당하다. 이러한 요구사항을 지원하기 위해 소프트웨어 아키텍처를 설계하기 위해 필수적인 시스템 요구 사항에 대한 정보가 필요하다. 너는 이것을 점진적으로 발전시킬 수 없다. 더 큰 시스템 내의 하위 시스템은 다른 접근방식을 사용하여 개발될 수 있다. 잘 이해되는 시스템 부품은 폭포 기반 공정을 사용하여 지정 및 개발할 수 있거나 구성을 위해 기성 시스템으로 구입할 수 있다. 시스템의 다른 부분은 미리 명시하기 어려운 부분은 항상 증분 접근법을 사용하여 개발해야 한다. 두 경우 모두 소프트웨어 구성요소를 재사용할 가능성이 높다.

이러한 모든 일반 모델에 그린 “범용” 공정 모델을 개발하기 위한 다양한 시도가 있었다. 이러한 보편적 모델 중 가장 잘 알려진 것 중 하나는 미국의 소프트웨어 엔지니어링 회사인 Rational이 개발한 Rational Unified Process (RUP) (Krutchen 2003)이다. RUP는 다양한 방법으로 인스턴스화할 수 있는 유연한 모델로서, 여기에서 논의된 일반 프로세스 모델 중 하나와 유사한 프로세스를 만들 수 있다. RUP는 일부 대형 소프트웨어 회사(특히 IBM)에 의해 채택되었지만 널리 받아들여지지 않았다.

[Figure 2.1 The waterfall model]

2.1.1 폭포 모형(The waterfall model)

The first published model of the software development process was derived from engineering process models used in large military systems engineering (Royce 1970). It presents the software development process as a number of stages, as shown in Figure 2.1. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The waterfall model is an example of a plan-driven process. In principle at least, you plan and schedule all of the process activities before starting software development.

The stages of the waterfall model directly reflect the fundamental software devel- opment activities:

소프트웨어 개발 프로세스의 첫 번째 공개된 모델은 대규모 군사 시스템 엔지니어링에 사용되는 엔지니어링 프로세스 모델에서 도출되었다(Royce 1970). 그림 2.1과 같이 소프트웨어 개발 프로세스를 여러 단계로 제시한다. 이 모델은 한 단계부터 다른 단계까지의 계단식 때문에 폭포수 모델 또는 소프트웨어 라이프 사이클로 알려져 있다. 폭포수 모델은 계획적으로 추진되는 과정의 한 예다. 최소한 소프트웨어 개발을 시작하기 전에 모든 프로세스 활동을 계획 및 예약하는 것이 원칙이다.

폭포수 모델의 단계는 기본적인 소프트웨어 개발 활동을 직접적으로 반영한다.

1. Requirements analysis and definition The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification.

2. System and software design The systems design process allocates the require- ments to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the funda- mental software system abstractions and their relationships.

3. Implementation and unit testing During this stage, the software design is real- ized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.

5. Operation and maintenance Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system’s services as new requirements are discovered.

6. 요구사항 분석 및 정의 시스템 사용자와의 협의에 의해 시스템의 서비스, 제약 및 목표를 설정한다. 그런 다음 세부적으로 정의되며 시스템 사양으로 기능한다.

7. 시스템 및 소프트웨어 설계 시스템 설계 프로세스에서는 요구 사항을 하드웨어 또는 소프트웨어 시스템에 할당한다. 전체 시스템 아키텍처를 구축한다. 소프트웨어 설계에는 기금-정신 소프트웨어 시스템 추상화 및 이들의 관계를 파악하고 기술하는 것이 포함된다.

8. 구현 및 유닛 테스트 이 단계에서는 소프트웨어 설계를 프로그램이나 프로그램 유닛의 집합으로 현실화한다. 유닛 테스트는 각 유닛이 사양을 충족하는지 확인하는 것을 포함한다.

9. 통합 및 시스템 테스트 개별 프로그램 유닛 또는 프로그램을 통합하여 완전한 시스템으로 테스트하여 소프트웨어 요구 사항을 충족하는지 확인한다. 테스트 후 소프트웨어 시스템이 고객에게 전달된다.

10. 정상운전 및 유지보수는 가장 긴 수명주기 단계다. 그 시스템은 설치되고 실용화된다. 유지보수는 라이프 사이클의 초기 단계에서 발견되지 않았던 오류를 수정하고, 시스템 유닛의 구현을 향상시키며, 새로운 요구사항이 발견됨에 따라 시스템의 서비스를 향상시키는 것을 포함한다.

Boehm’s spiral process model

Barry Boehm, one of the pioneers in software engineering, proposed an incremental process model that was risk-driven. The process is represented as a spiral rather than a sequence of activities (Boehm 1988).

Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be con- cerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on. The spiral model combines change avoidance with change tolerance. It assumes that changes are a result of project risks and includes explicit risk management activities to reduce these risks.

Boehm의 나선형 공정 모델

소프트웨어 공학의 선구자 중 한 명인 배리 빔은 위험 중심의 증분 프로세스 모델을 제안했다. 그 과정은 일련의 활동보다는 나선형으로 표현된다(Boehm 1988).

나선형의 각 루프는 소프트웨어 프로세스의 단계를 나타낸다. 그러므로 가장 안쪽 루프는 시스템 실현 가능성, 요구사항 정의가 있는 다음 루프, 시스템 설계가 있는 다음 루프 등과 연계될 수 있다. Spiral 모델은 변경 회피와 변경 허용오차를 결합한다. 그것은 변경이 프로젝트 위험의 결과라고 가정하고 이러한 위험을 줄이기 위한 명시적인 위험 관리 활동을 포함한다.

http://software-engineering-book.com/web/spiral-model/

In principle, the result of each phase in the waterfall model is one or more docu- ments that are approved (“signed off”). The following phase should not start until the previous phase has finished. For hardware development, where high manufactur- ing costs are involved, this makes sense. However, for software development, these stages overlap and feed information to each other. During design, problems with requirements are identified; during coding design problems are found, and so on. The software process, in practice, is never a simple linear model but involves feed- back from one phase to another.

As new information emerges in a process stage, the documents produced at previ- ous stages should be modified to reflect the required system changes. For example, if it is discovered that a requirement is too expensive to implement, the requirements document should be changed to remove that requirement. However, this requires customer approval and delays the overall development process.

As a result, both customers and developers may prematurely freeze the software specification so that no further changes are made to it. Unfortunately, this means that problems are left for later resolution, ignored, or programmed around. Premature freezing of requirements may mean that the system won’t do what the user wants. It may also lead to badly structured systems as design problems are circumvented by implementation tricks.

During the final life-cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered.

원칙적으로 폭포수 모델에서 각 단계의 결과는 승인된 하나 이상의 (“서명 꺼짐”)이다. 다음 단계는 이전 단계가 완료될 때까지 시작하지 않아야 한다. 높은 제조 비용이 수반되는 하드웨어 개발의 경우, 이는 타당하다. 그러나, 소프트웨어 개발을 위해서, 이러한 단계들은 중복되어 서로 정보를 공급한다. 설계 중에 요구사항과 관련된 문제를 식별하고, 코딩 설계 문제 등을 발견한다. 실제로 소프트웨어 프로세스는 단순한 선형 모델이 아니라 한 단계에서 다른 단계로 피드백을 하는 것이다.

프로세스 단계에서 새로운 정보가 등장함에 따라, 필요한 시스템 변경을 반영하여 기존 단계에서 생산된 문서를 수정해야 한다. 예를 들어, 요구사항이 이행하기에 너무 비용이 많이 든다는 사실이 밝혀진 경우, 요구사항 문서를 변경하여 요구사항을 제거해야 한다. 그러나 이를 위해서는 고객의 승인이 필요하며 전체 개발 과정이 지연된다.

결과적으로 고객과 개발자 모두 소프트웨어 사양을 조기에 동결하여 더 이상 변경하지 않도록 할 수 있다. 불행하게도 이것은 문제가 나중에 해결되도록 방치되거나 무시되거나 프로그래밍되어 있다는 것을 의미한다. 요구사항의 조기 동결은 시스템이 사용자가 원하는 것을 하지 않는다는 것을 의미할 수 있다. 또한 설계 문제가 구현 요령에 의해 회피되기 때문에 잘못 구성된 시스템으로 이어질 수 있다.

최종 수명 주기 단계(작동 및 유지보수) 동안 소프트웨어를 사용한다. 원래의 소프트웨어 요구 사항의 오류와 누락은 발견된다.

Program and design errors emerge, and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.

In reality, software has to be flexible and accommodate change as it is being developed. The need for early commitment and system rework when changes are made means that the waterfall model is only appropriate for some types of system:

프로그램 및 설계 오류가 나타나고, 새로운 기능의 필요성이 확인된다. 그러므로 시스템은 유용하게 유지되도록 진화해야 한다. 이러한 변경(소프트웨어 유지 관리)은 이전 프로세스 단계를 반복하는 것을 포함할 수 있다.

실제로 소프트웨어는 개발되는 대로 유연하고 변화를 수용해야 한다. 변경이 이루어졌을 때 초기 약속과 시스템 재작업이 필요하다는 것은 폭포 모델이 일부 시스템 유형에만 적합하다는 것을 의미한다.

1. Embedded systems where the software has to interface with hardware systems. Because of the inflexibility of hardware, it is not usually possible to delay deci- sions on the software’s functionality until it is being implemented.

2. Critical systems where there is a need for extensive safety and security analysis of the software specification and design. In these systems, the specification and design documents must be complete so that this analysis is possible. Safety- related problems in the specification and design are usually very expensive to correct at the implementation stage.

3. Large software systems that are part of broader engineering systems developed by several partner companies. The hardware in the systems may be developed using a similar model, and companies find it easier to use a common model for hardware and software. Furthermore, where several companies are involved, complete specifications may be needed to allow for the independent develop- ment of different subsystems.

4. 소프트웨어가 하드웨어 시스템과 인터페이스해야 하는 임베디드 시스템. 하드웨어의 유연성이 떨어지기 때문에, 일반적으로 소프트웨어의 기능성에 대한 결정을 구현할 때까지 지연시키는 것은 불가능하다.

5. 소프트웨어 사양 및 설계에 대한 광범위한 안전 및 보안 분석이 필요한 중요 시스템. 이러한 시스템에서는 이 분석이 가능하도록 규격 및 설계 문서를 작성해야 한다. 규격과 설계의 안전 관련 문제는 일반적으로 구현 단계에서 수정하는 데 매우 비용이 많이 든다.

6. 여러 협력업체가 개발한 광범위한 엔지니어링 시스템의 일부인 대형 소프트웨어 시스템. 시스템의 하드웨어는 유사한 모델을 사용하여 개발될 수 있으며, 회사들은 하드웨어와 소프트웨어에 공통 모델을 사용하는 것이 더 쉽다고 생각한다. 더욱이, 여러 회사가 관련된 경우, 다른 서브시스템의 독립적 개발을 허용하기 위해 완전한 규격이 필요할 수 있다.

The waterfall model is not the right process model in situations where informal team communication is possible and software requirements change quickly. Iterative development and agile methods are better for these systems.

An important variant of the waterfall model is formal system development, where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Formal development processes, such as that based on the B method (Abrial 2005, 2010), are mostly used in the development of software systems that have strin- gent safety, reliability, or security requirements. The formal approach simplifies the production of a safety or security case. This demonstrates to customers or regulators that the system actually meets its safety or security requirements. However, because of the high costs of developing a formal specification, this development model is rarely used except for critical systems engineering.

폭포 모델은 비공식적인 팀 커뮤니케이션이 가능하고 소프트웨어 요구사항이 빠르게 변화하는 상황에서 올바른 프로세스 모델이 아니다. 이러한 시스템에는 반복적인 개발과 민첩한 방법이 더 좋다.

폭포수 모델의 중요한 변형은 시스템 사양의 수학적 모델이 생성되는 공식 시스템 개발이다. 이 모델은 그 일관성을 유지하는 수학적 변환을 이용하여 실행 코드로 개선된다. B 방법에 기초한 것과 같은 공식 개발 프로세스(Abrial 2005, 2010년)는 안전, 신뢰성 또는 보안 요건을 갖춘 소프트웨어 시스템의 개발에 주로 사용된다. 공식적인 접근방식은 안전 또는 보안 사례의 생산을 단순화한다. 이는 고객이나 규제당국에 시스템이 실제로 안전 또는 보안 요건을 충족한다는 것을 증명한다. 그러나, 이 개발 모델은 공식 규격 개발에 드는 비용이 높기 때문에 중요한 시스템 엔지니어링을 제외하고는 거의 사용되지 않는다.

2.1.2 증분 개발(Incremental development)

Incremental development is based on the idea of developing an initial implementa- tion, getting feedback from users and others, and evolving the software through several versions until the required system has been developed (Figure 2.2). Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities.

증분 개발은 초기 구현을 개발하고, 사용자 등의 피드백을 받고, 필요한 시스템이 개발될 때까지 여러 버전을 통해 소프트웨어를 진화시키는 아이디어에 기초한다(그림 2.2). 사양, 개발 및 검증 활동은 별도의 활동이 아닌 인터리브되며, 활동 전반에 걸쳐 신속한 피드백을 제공한다.

[Figure 2.2 Incremental development]

Incremental development in some form is now the most common approach for the development of application systems and software products. This approach can be either plan-driven, agile or, more usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified in advance; if an agile approach is adopted, the early increments are identified, but the development of later increments depends on progress and customer priorities.

Incremental software development, which is a fundamental part of agile development methods, is better than a waterfall approach for systems whose requirements are likely to change during the development process. This is the case for most business systems and software products. Incremental development reflects the way that we solve problems. We rarely work out a complete prob- lem solution in advance but move toward a solution in a series of steps, back- tracking when we realize that we have made a mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed.

Each increment or version of the system incorporates some of the functional- ity that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer or user can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the cur- rent increment has to be changed and, possibly, new functionality defined for later increments.

Incremental development has three major advantages over the waterfall model:

어떤 형태로든 증분적 개발은 이제 애플리케이션 시스템과 소프트웨어 제품의 개발을 위한 가장 일반적인 접근방식이 되었다. 이 접근방식은 계획 지향적이고 민첩하거나 더 일반적으로 이러한 접근방식의 혼합일 수 있다. 계획 중심 접근법에서 시스템 증분을 미리 식별한다. 민첩한 접근법을 채택하면 초기 증분을 확인하지만, 이후 증분의 개발은 진행률과 고객 우선순위에 따라 달라진다.

민첩한 개발 방법의 기본 부분인 증분 소프트웨어 개발이 개발 프로세스 중에 요구사항이 변경될 가능성이 있는 시스템의 경우 폭포수 접근보다 낫다. 대부분의 비즈니스 시스템과 소프트웨어 제품이 그렇다. 점진적 발전은 우리가 문제를 해결하는 방법을 반영한다. 우리는 사전에 완전한 조사 해결책을 찾는 일은 거의 없지만, 실수를 깨달았을 때, 일련의 단계를 거쳐 해결책을 향해 나아간다. 소프트웨어를 점진적으로 개발함으로써, 소프트웨어를 개발하면서 변경하기가 더 저렴하고 쉽다.

시스템의 각 증분 또는 버전은 고객이 필요로 하는 기능성의 일부를 포함한다. 일반적으로 시스템의 초기 증분에는 가장 중요하거나 가장 긴급하게 요구되는 기능성이 포함된다. 이는 고객이나 사용자가 비교적 초기 개발 단계에서 시스템을 평가하여 필요한 것을 전달할 수 있는지를 확인할 수 있다는 것을 의미한다. 그렇지 않은 경우, 임대료 인상만 변경해야 하며, 가능한 경우 차후 증분에 대해 새로운 기능이 정의되어야 한다.

증분 발전은 폭포 모델에 비해 크게 세 가지 장점을 가지고 있다.

1. The cost of implementing requirements changes is reduced. The amount of analysis and documentation that has to be redone is significantly less than is required with the waterfall model.

2. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. Customers find it difficult to judge progress from software design documents.

3. Early delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

4. 요구사항 변경 구현 비용을 절감한다. 다시 작성해야 하는 분석 및 문서화의 양은 폭포 모델에 필요한 것보다 상당히 적다.

5. 이미 이루어진 개발 작업에 대한 고객의 피드백을 받는 것이 더 쉽다. 고객은 소프트웨어의 시연에 대해 의견을 개진하고 얼마나 구현되었는지 확인할 수 있다. 고객은 소프트웨어 설계 문서에서 진행 상황을 판단하기 어렵다.

6. 모든 기능이 포함되지 않았더라도 고객에게 유용한 소프트웨어를 조기에 전달하고 배포할 수 있다. 고객은 폭포를 통해 가능한 한 빨리 소프트웨어를 사용하고 가치를 얻을 수 있다.

Problems with incremental development

Although incremental development has many advantages, it is not problem free. The primary cause of the difficulty is the fact that large organizations have bureaucratic procedures that have evolved over time and there may be a mismatch between these procedures and a more informal iterative or agile process.

Sometimes these procedures are there for good reasons. For example, there may be procedures to ensure that the software meets properly implements external regulations (e.g., in the United States, the Sarbanes Oxley accounting regulations). Changing these procedures may not be possible, so process conflicts maybe unavoidable.

증분 개발 문제

점진적인 발전은 많은 이점을 가지고 있지만, 문제가 없는 것은 아니다. 이러한 어려움의 주된 원인은 대규모 조직들이 시간이 지남에 따라 진화한 관료적 절차를 가지고 있으며 이러한 절차와 보다 비공식적인 반복 또는 민첩한 프로세스 사이에 불일치가 있을 수 있다는 사실이다.

때때로 이러한 절차들은 좋은 이유로 존재한다. 예를 들어 소프트웨어가 외부 규정을 적절하게 이행하는지 확인하는 절차가 있을 수 있다(예: 미국에서는 Sarbanes Oxley 회계 규정). 이러한 절차를 변경할 수 없을 수 있으므로 프로세스 충돌은 피할 수 없을 것이다.

http://software-engineering-book.com/web/incremental-development/

From a management perspective, the incremental approach has two problems:

경영진의 관점에서, 증분 접근방식은 두 가지 문제를 가지고 있다.

1. The process is not visible. Managers need regular deliverables to measure pro- gress. If systems are developed quickly, it is not cost effective to produce docu- ments that reflect every version of the system.

2. System structure tends to degrade as new increments are added. Regular change leads to messy code as new functionality is added in whatever way is possible. It becomes increasingly difficult and costly to add new features to a system. To reduce structural degradation and general code messiness, agile methods sug- gest that you should regularly refactor (improve and restructure) the software.

3. 과정이 보이지 않는다. 관리자들은 프로그레스 측정을 위해 정기적인 결과물을 필요로 한다. 시스템이 빨리 개발된다면, 시스템의 모든 버전을 반영하는 제품을 생산하는 것은 비용 효율적이지 않다.

4. 시스템 구조는 새로운 증분이 추가될수록 저하되는 경향이 있다. 어떤 방식으로든 새로운 기능이 추가됨에 따라 규칙적인 변경은 지저분한 코드로 이어진다. 시스템에 새로운 기능을 추가하는 것은 점점 더 어렵고 비용이 많이 든다. 구조적인 저하와 일반적인 코드 지저분함을 줄이기 위해, 민첩한 방법들은 당신이 정기적으로 소프트웨어를 리팩터(개선 및 재구성)해야 한다고 암시한다.

The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system. Large systems need a stable framework or architecture, and the responsi- bilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture. This has to be planned in advance rather than developed incrementally.

Incremental development does not mean that you have to deliver each increment to the system customer. You can develop a system incrementally and expose it to customers and other stakeholders for comment, without necessarily delivering it and deploying it in the customer’s environment. Incremental delivery (covered in Section 2.3.2) means that the software is used in real, operational processes, so user feedback is likely to be realistic. However, providing feedback is not always possi- ble as experimenting with new software can disrupt normal business processes.

증분 개발의 문제는 다른 팀들이 시스템의 다른 부분을 개발하는 크고 복잡한 긴 수명 시스템의 경우 특히 심각해진다. 대형 시스템은 안정된 프레임워크나 구조를 필요로 하며, 시스템의 일부에서 일하는 다른 팀들의 책임들은 그 구조에 관해서 명확하게 정의될 필요가 있다. 이것은 점진적으로 개발되기 보다는 미리 계획되어야 한다.

증분 개발이라고 해서 각 증분을 시스템 고객에게 전달해야 하는 것은 아니다. 시스템을 점진적으로 개발하여 고객 및 기타 이해당사자에게 설명하기 위해 이를 반드시 전달하고 고객 환경에 구축하지 않고 공개할 수 있다. 증분 전달(섹션 2.3.2에서 다룬다)은 소프트웨어가 실제 운영 프로세스에서 사용된다는 것을 의미하므로 사용자 피드백이 현실적일 수 있다. 그러나 새로운 소프트웨어로 실험하면 정상적인 비즈니스 프로세스를 방해할 수 있기 때문에 피드백을 제공하는 것이 항상 적절한 것은 아니다.

[Figure 2.3 Reuse- oriented software engineering]

2.1.3 통합 및 구성(Integration and configuration)

In the majority of software projects, there is some software reuse. This often happens informally when people working on the project know of or search for code that is similar to what is required. They look for these, modify them as needed, and integrate them with the new code that they have developed.

This informal reuse takes place regardless of the development process that is used. However, since 2000, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a base of reusable software components and an integrating framework for the compo- sition of these components.

Three types of software components are frequently reused:

대부분의 소프트웨어 프로젝트에서, 약간의 소프트웨어 재사용이 있다. 이것은 종종 프로젝트에서 일하는 사람들이 필요한 것과 유사한 코드를 알거나 검색할 때 비공식적으로 발생한다. 그들은 이것들을 찾고 필요에 따라 수정하고 그들이 개발한 새로운 코드와 통합한다.

이러한 비공식적 재사용은 사용되는 개발 프로세스와 무관하게 이루어진다. 그러나 2000년부터는 기존 소프트웨어의 재사용에 중점을 두는 소프트웨어 개발 프로세스가 널리 이용되고 있다. 재사용 지향 접근방식은 재사용 가능한 소프트웨어 구성요소의 기초와 이러한 구성요소의 구성을 위한 통합 프레임워크에 의존한다.

자주 재사용되는 세 가지 유형의 소프트웨어 구성 요소:

1. Stand-alone application systems that are configured for use in a particular envi- ronment. These systems are general-purpose systems that have many features, but they have to be adapted for use in a specific application.

2. Collections of objects that are developed as a component or as a package to be integrated with a component framework such as the Java Spring framework (Wheeler and White 2013).

3. Web services that are developed according to service standards and that are available for remote invocation over the Internet.

4. 특정 환경에서 사용하도록 구성된 독립형 애플리케이션 시스템. 이러한 시스템은 여러 가지 특징을 가지고 있는 범용 시스템이지만, 특정 용도에 사용하도록 조정되어야 한다.

5. Java Spring 프레임워크 (Wheeler and White 2013)와 같은 구성요소 프레임워크와 통합될 구성요소 또는 패키지로 개발된 객체의 집합.

6. 서비스 표준에 따라 개발되고 인터넷을 통한 원격 호출에 사용할 수 있는 웹 서비스

Figure 2.3 shows a general process model for reuse-based development, based on integration and configuration. The stages in this process are:

그림 2.3은 통합 및 구성에 기초한 재사용 기반 개발을 위한 일반 프로세스 모델을 보여준다. 이 프로세스의 단계는 다음과 같다.

1. Requirements specification The initial requirements for the system are pro- posed. These do not have to be elaborated in detail but should include brief descriptions of essential requirements and desirable system features.

2. Software discovery and evaluation Given an outline of the software require- ments, a search is made for components and systems that provide the func- tionality required. Candidate components and systems are evaluated to see if they meet the essential requirements and if they are generally suitable for use in the system.

3. Requirements refinement During this stage, the requirements are refined using information about the reusable components and applications that have been discovered. The requirements are modified to reflect the available compo- nents, and the system specification is re-defined. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions.

4. Application system configuration If an off-the-shelf application system that meets the requirements is available, it may then be configured for use to create the new system.

5. Component adaptation and integration If there is no off-the-shelf system, indi- vidual reusable components may be modified and new components developed. These are then integrated to create the system.

6. 요구사항 명세서 시스템의 초기 요건이 제시된다. 여기에는 세부적으로 설명할 필요는 없지만 필수 요건과 바람직한 시스템 특징에 대한 간략한 설명이 포함되어야 한다.

7. 소프트웨어 검색 및 평가 소프트웨어 요구 사항의 개요를 고려할 때 필요한 기능성을 제공하는 구성 요소와 시스템에 대한 검색을 수행한다. 후보 구성품 및 시스템은 필수 요건을 충족하는지, 그리고 일반적으로 시스템에 사용하기에 적합한지 여부를 평가한다.

8. 요구사항 정제 이 단계에서는 재사용 가능한 구성요소 및 발견된 용도에 대한 정보를 사용하여 요구사항을 개선한다. 요구사항은 이용 가능한 컴포넌트를 반영하도록 수정되고 시스템 사양은 다시 정의된다. 변경이 불가능한 경우, 대체 해결책을 찾기 위해 요소 분석 활동을 재입력할 수 있다.

9. 애플리케이션 시스템 구성 요구 사항을 충족하는 기성 애플리케이션 시스템을 사용할 수 있는 경우 새 시스템을 생성하기 위해 구성할 수 있다.

10. 부품 적응 및 통합 기성 시스템이 없는 경우, 개별 재사용 가능한 구성 요소를 수정하고 새로운 구성 요소를 개발할 수 있다. 그런 다음 이것들은 시스템을 만들기 위해 통합된다.

Software development tools

Software development tools are programs that are used to support software engineering process activities. These tools include requirements management tools, design editors, refactoring support tools, compilers, debuggers, bug trackers, and system building tools.

Software tools provide process support by automating some process activities and by providing information about the software that is being developed. For example:

■ The development of graphical system models as part of the requirements specification or the software design

■ The generation of code from these graphical models

■ The generation of user interfaces from a graphical interface description that is created interactively by the user

■ Program debugging through the provision of information about an executing program

■ The automated translation of programs written using an old version of a programming language to a more recent version

Tools may be combined within a framework called an Interactive Development Environment or IDE. This provides a common set of facilities that tools can use so that it is easier for tools to communicate and operate in an integrated way.

소프트웨어 개발 도구

소프트웨어 개발 도구는 소프트웨어 엔지니어링 프로세스 활동을 지원하기 위해 사용되는 프로그램이다. 이러한 도구에는 요구사항 관리 도구, 설계 편집기, 재인쇄 지원 도구, 컴파일러, 디버거, 버그 추적기 및 시스템 구축 도구가 포함된다.

소프트웨어 도구는 일부 프로세스 활동을 자동화하고 개발 중인 소프트웨어에 대한 정보를 제공함으로써 프로세스 지원을 제공한다. 예를 들어 다음과 같다.

■ 요구사항 명세서 또는 소프트웨어 설계의 일환으로 그래픽 시스템 모델의 개발

■ 이러한 그래픽 모델에서 코드 생성

■ 사용자가 대화식으로 생성하는 그래픽 인터페이스 설명에서 사용자 인터페이스 생성

■ 실행 중인 프로그램에 대한 정보 제공을 통한 프로그램 디버깅

■ 이전 버전의 프로그래밍 언어를 사용하여 작성된 프로그램을 보다 최신 버전으로 자동 변환

공구는 상호작용 개발 환경 또는 IDE라고 하는 프레임워크 내에서 결합될 수 있다. 이것은 도구들이 통합적으로 의사소통하고 작동하기 더 쉽도록 도구들이 사용할 수 있는 일반적인 시설들을 제공한다.

http://software-engineering-book.com/web/software-tools/

Reuse-oriented software engineering, based around configuration and integra- tion, has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable, and this may lead to a system

that does not meet the real needs of users. Furthermore, some control over the sys- tem evolution is lost as new versions of the reusable components are not under the control of the organization using them.

Software reuse is very important, and so several chapters in the third I have dedi- cated several chapters in the 3rd part of the book to this topic. General issues of software reuse are covered in Chapter 15, component-based software engineering in Chapters 16 and 17, and service-oriented systems in Chapter 18.

구성과 통합에 기반한 재사용 지향 소프트웨어 엔지니어링은 개발될 소프트웨어의 양을 줄이고 비용과 위험을 줄이는 분명한 이점을 가지고 있다. 그것은 또한 보통 소프트웨어의 빠른 전달을 이끈다. 그러나 요구사항의 타협은 불가피하며, 이로 인해 시스템이 손상될 수 있다.

그것은 사용자의 실제 요구를 충족시키지 못한다. 더욱이, 재사용 가능한 요소의 새로운 버전이 그것들을 사용하는 조직의 통제 하에 있지 않기 때문에 시스템 진화에 대한 일부 제어는 상실된다.

소프트웨어 재사용은 매우 중요하며, 그래서 세 번째의 여러 장은 이 주제에 대해 이 책의 세 번째 부분의 여러 장을 추론했다. 소프트웨어 재사용의 일반적인 문제는 15장, 16장과 17장의 구성요소 기반 소프트웨어 엔지니어링, 18장의 서비스 지향 시스템에서 다룬다.

2.2 프로세스 액티비티(Process activities)

Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system. Generally, processes are now tool-supported. This means that software developers may use a range of software tools to help them, such as requirements management systems, design model editors, program editors, auto- mated testing tools, and debuggers.

The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the water- fall model, they are organized in sequence, whereas in incremental development they are interleaved. How these activities are carried out depends on the type of software being developed, the experience and competence of the developers, and the type of organization developing the software.

실제 소프트웨어 프로세스는 소프트웨어 시스템을 지정, 설계, 구현 및 테스트하는 전체적인 목표를 가진 기술, 협업 및 관리 활동의 인터리브 시퀀스다. 일반적으로 프로세스는 현재 툴이 지원된다. 이는 소프트웨어 개발자가 요구사항 관리 시스템, 설계 모델 편집자, 프로그램 편집자, 자동 짝짓기 시험 도구 및 디버거와 같은 다양한 소프트웨어 도구를 사용하여 이를 지원할 수 있음을 의미한다.

사양, 개발, 검증 및 진화의 4가지 기본 프로세스 활동은 서로 다른 개발 프로세스에서 다르게 구성된다. 워터 폴 모델에서는 순차적으로 구성되는 반면, 증분 개발에서는 인터리브(interleaved)된다. 이러한 활동이 어떻게 수행되는가는 개발 중인 소프트웨어의 유형, 개발자의 경험과 역량, 그리고 소프트웨어를 개발하는 조직의 유형에 따라 달라진다.

2.2.1 소프트웨어 사양(Software specification)

Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the con- straints on the system’s operation and development. Requirements engineering is a particularly critical stage of the software process, as mistakes made at this stage inevitably lead to later problems in the system design and implementation.

Before the requirements engineering process starts, a company may carry out a feasibility or marketing study to assess whether or not there is a need or a market for the software and whether or not it is technically and financially realistic to develop the software required. Feasibility studies are short-term, relatively cheap studies that inform the decision of whether or not to go ahead with a more detailed analysis.

The requirements engineering process (Figure 2.4) aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. Requirements are usually presented at two levels of detail. End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification.

소프트웨어 사양 또는 요건 엔지니어링은 시스템에서 요구되는 서비스를 이해하고 정의하며 시스템의 운영 및 개발에 미치는 영향을 식별하는 과정이다. 요구사항 엔지니어링은 소프트웨어 프로세스의 특히 중요한 단계로서, 이 단계에서 발생한 실수는 시스템 설계와 구현의 나중의 문제로 이어질 수밖에 없기 때문이다.

기업은 요건 엔지니어링 프로세스가 시작되기 전에 소프트웨어의 필요성이나 시장이 있는지, 그리고 필요한 소프트웨어를 개발하는 것이 기술적으로나 재정적으로 현실적인지를 평가하기 위하여 실현 가능성이나 마케팅 연구를 수행할 수 있다. 타당성 연구는 보다 상세한 분석을 진행할 것인지 여부를 결정하는 데 도움이 되는 단기적이고 비교적 저렴한 연구들이다.

요건 엔지니어링 프로세스(그림 2.4)는 이해관계자 요건을 충족하는 시스템을 지정하는 합의된 요건 문서를 작성하는 것을 목표로 한다. 요구사항은 보통 두 가지 세부사항으로 제시된다. 최종 사용자와 고객은 요구사항의 높은 수준의 명세서가 필요하다. 시스템 개발자는 보다 상세한 시스템 규격을 필요로 한다.

[Figure 2.4 The requirements engineering process]

There are three main activities in the requirements engineering process:

요구사항 엔지니어링 프로세스에는 다음 세 가지 주요 활동이 있다.

1. Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with poten- tial users and procurers, task analysis, and so on. This may involve the develop- ment of one or more system models and prototypes. These help you understand the system to be specified.

2. Requirements specification Requirements specification is the activity of trans- lating the information gathered during requirements analysis into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided.

3. Requirements validation This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the require- ments document are inevitably discovered. It must then be modified to correct these problems.

4. 요구사항 도출 및 분석 기존 시스템의 관찰, 권한 있는 사용자 및 조달자와의 논의, 업무 분석 등을 통해 시스템 요건을 도출하는 과정이다. 여기에는 하나 이상의 시스템 모델과 프로토타입의 개발이 수반될 수 있다. 이것들은 당신이 명시되어야 할 시스템을 이해하는 데 도움이 된다.

5. 요구사항 규격 요구사항 명세서는 요구사항 분석 중에 수집된 정보를 일련의 요구사항을 정의하는 문서로 변환하는 활동이다. 이 문서에는 두 가지 유형의 요건이 포함될 수 있다. 사용자 요구사항은 시스템 고객 및 최종 사용자에 대한 시스템 요구사항의 추상적 설명이며, 시스템 요구사항은 제공될 기능에 대한 보다 상세한 설명이다.

6. 요구사항 유효성 확인 이 활동은 사실성, 일관성 및 완전성에 대한 요구사항을 확인한다. 이 과정에서 요구 사항 문서의 오류가 발견될 수밖에 없다. 그런 다음 이러한 문제를 수정해야 한다.

Requirements analysis continues during definition and specification, and new requirements come to light throughout the process. Therefore, the activities of analy- sis, definition, and specification are interleaved.

In agile methods, requirements specification is not a separate activity but is seen as part of system development. Requirements are informally specified for each increment of the system just before that increment is developed. Requirements are specified according to user priorities. The elicitation of requirements comes from users who are part of or work closely with the development team.

요건 분석은 정의와 규격에서 계속되며, 프로세스 전체에 걸쳐 새로운 요구사항이 밝혀진다. 따라서 분석, 정의 및 규격의 활동은 상호연관된다.

민첩한 방법에서 요구사항 명세서는 별도의 활동이 아니라 시스템 개발의 일부로 간주된다. 요구사항은 시스템 증가가 개발되기 직전에 시스템의 각 증분에 대해 비공식적으로 지정된다. 요구사항은 사용자 우선순위에 따라 지정된다. 요구사항의 도출은 개발팀의 일부이거나 개발팀과 긴밀히 협력하는 사용자로부터 발생한다.

[Figure 2.5 A general model of the design process]

2.2.2 소프트웨어 설계 및 구현(Software design and implementation)

The implementation stage of software development is the process of developing an executable system for delivery to the customer. Sometimes this involves sepa- rate activities of software design and programming. However, if an agile approach to development is used, design and implementation are interleaved, with no for- mal design documents produced during the process. Of course, the software is still designed, but the design is recorded informally on whiteboards and program- mer’s notebooks.

A software design is a description of the structure of the software to be imple- mented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. Designers do not arrive at a finished design immediately but develop the design in stages. They add detail as they develop their design, with constant backtracking to modify earlier designs.

Figure 2.5 is an abstract model of the design process showing the inputs to the design process, process activities, and the process outputs. The design process activ- ities are both interleaved and interdependent. New information about the design is constantly being generated, and this affects previous design decisions. Design rework is therefore inevitable.

소프트웨어 개발의 실행 단계는 고객에게 전달하기 위한 실행 시스템을 개발하는 과정이다. 때때로 이것은 소프트웨어 설계와 프로그래밍의 분리율 활동을 포함한다. 그러나, 개발에 대한 민첩한 접근법을 사용할 경우, 설계와 구현이 인터리빙되며, 프로세스 중에 악성 설계 문서가 생성되지 않는다. 물론 소프트웨어는 아직 설계되어 있지만 디자인은 화이트보드와 프로그램-메의 노트에 비공식적으로 기록된다.

소프트웨어 설계는 주입될 소프트웨어의 구조, 시스템에서 사용하는 데이터 모델과 구조, 시스템 구성요소 간의 인터페이스, 그리고 때로는 사용되는 알고리즘에 대한 설명이다. 설계자는 완성된 설계에 즉시 도달하지 않고 단계적으로 설계를 개발한다. 그들은 디자인을 발전시킬 때 세부사항을 추가하며, 이전 디자인을 수정하기 위한 지속적인 역추적을 가지고 있다.

그림 2.5는 설계 프로세스, 공정 활동 및 공정 산출물에 대한 입력을 보여주는 설계 프로세스의 추상적 모델이다. 설계 프로세스 활성화는 인터리브와 상호의존적이다. 설계에 관한 새로운 정보가 지속적으로 생성되고 있으며 이는 이전의 설계 결정에 영향을 미친다. 따라서 설계 재작업은 불가피하다.

Most software interfaces with other software systems. These other systems include the operating system, database, middleware, and other application systems. These make up the “software platform,’ the environment in which the software will execute. Information about this platform is an essential input to the design process, as designers must decide how best to integrate it with its environment. If the system is to process existing data, then the description of that data may be included in the platform specification. Otherwise, the data description must be an input to the design process so that the system data organization can be defined.

The activities in the design process vary, depending on the type of system being developed. For example, real-time systems require an additional stage of timing design but may not include a database, so there is no database design involved. Figure 2.5 shows four activities that may be part of the design process for information systems:

대부분의 소프트웨어는 다른 소프트웨어 시스템과 인터페이스한다. 이러한 다른 시스템에는 운영 체제, 데이터베이스, 미들웨어 및 기타 애플리케이션 시스템이 포함된다. 이것들은 소프트웨어가 실행될 환경인 “소프트웨어 플랫폼”을 구성하고 있다. 이 플랫폼에 대한 정보는 설계자가 그것의 환경과 가장 잘 통합하는 방법을 결정해야 하기 때문에 설계 프로세스에 필수적인 입력사항이다. 시스템이 기존 데이터를 처리하는 경우, 해당 데이터에 대한 설명이 플랫폼 규격에 포함될 수 있다. 그렇지 않으면 데이터 설명은 시스템 데이터 조직을 정의할 수 있도록 설계 프로세스에 입력되어야 한다.

설계 프로세스의 활동은 개발 중인 시스템의 유형에 따라 달라진다. 예를 들어 실시간 시스템은 타이밍 설계의 추가 단계가 필요하지만 데이터베이스를 포함하지 않을 수 있으므로 관련된 데이터베이스 설계는 없다. 그림 2.5에는 정보시스템 설계 프로세스의 일부일 수 있는 네 가지 활동이 표시된다.

1. Architectural design, where you identify the overall structure of the system, the principal components (sometimes called subsystems or modules), their relation- ships, and how they are distributed.

2. Database design, where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created.

3. Interface design, where you define the interfaces between system components. This interface specification must be unambiguous. With a precise interface, a component may be used by other components without them having to know how it is implemented. Once interface specifications are agreed, the compo- nents can be separately designed and developed.

4. Component selection and design, where you search for reusable components and, if no suitable components are available, design new software components. The design at this stage may be a simple component description with the imple- mentation details left to the programmer. Alternatively, it may be a list of changes to be made to a reusable component or a detailed design model expressed in the UML. The design model may then be used to automatically generate an implementation.

5. 시스템의 전체적인 구조, 주요 구성 요소(하위 시스템 또는 모듈이라고도 함), 이들의 관계, 그리고 그것들이 어떻게 분포되는지를 확인하는 건축 설계.

6. 데이터베이스 설계: 시스템 데이터 구조를 설계하고 이러한 구조를 데이터베이스에 표시하는 방법. 다시 말하지만, 여기서의 작업은 기존 데이터베이스를 재사용할 것인지 아니면 새로운 데이터베이스를 만들 것인지에 달려 있다.

7. 시스템 구성 요소 간의 인터페이스를 정의하는 인터페이스 설계. 이 인터페이스 사양은 명확해야 한다. 정확한 인터페이스로, 구성요소는 구현 방법을 알 필요 없이 다른 구성요소에 의해 사용될 수 있다. 인터페이스 규격이 합의되면 컴포넌트를 별도로 설계하고 개발할 수 있다.

8. 구성요소 선택 및 설계 - 재사용 가능한 구성요소를 검색하고 적합한 구성요소가 없는 경우 새 소프트웨어 구성요소를 설계하십시오. 이 단계에서의 설계는 프로그래머에게 남겨진 상세한 설명과 함께 단순한 구성요소 설명이 될 수 있다. 또는, 재사용 가능한 구성요소 또는 UML에 표현된 상세 설계 모델에 대한 변경사항의 목록일 수 있다. 그런 다음 설계 모델을 사용하여 구현을 자동으로 생성할 수 있다.

These activities lead to the design outputs, which are also shown in Figure 2.5. For critical systems, the outputs of the design process are detailed design documents setting out precise and accurate descriptions of the system. If a model-driven approach is used (Chapter 5), the design outputs are design diagrams. Where agile methods of development are used, the outputs of the design process may not be separate specification documents but may be represented in the code of the program. The development of a program to implement a system follows naturally from system design. Although some classes of program, such as safety-critical systems, are usually designed in detail before any implementation begins, it is more common for design and program development to be interleaved. Software development tools may be used to generate a skeleton program from a design. This includes code to

이러한 활동은 설계 산출물을 유도하며, 그림 2.5에도 나타나 있다. 중요한 시스템의 경우 설계 프로세스의 출력은 시스템에 대한 정확하고 정확한 설명을 규정한 상세 설계 문서다. 모델 중심 접근방식을 사용하는 경우(5장) 설계 출력은 설계도다. 민첩한 개발 방법을 사용하는 경우 설계 프로세스의 출력은 별도의 규격 문서가 아닐 수 있지만 프로그램의 코드에 표시될 수 있다. 시스템을 구현하기 위한 프로그램의 개발은 시스템 설계에서 자연스럽게 따르게 된다. 안전 중요 시스템과 같은 일부 프로그램의 등급은 대개 구현이 시작되기 전에 상세하게 설계되지만, 설계와 프로그램 개발이 상호 작용하는 것이 더 일반적이다. 소프트웨어 개발 도구는 설계에서 골격 프로그램을 생성하는 데 사용할 수 있다. 다음 코드는 다음과 같다.

[Figure 2.6 Stages of testing]

define and implement interfaces, and, in many cases, the developer need only add details of the operation of each program component.

Programming is an individual activity, and there is no general process that is usually followed. Some programmers start with components that they understand, develop these, and then move on to less understood components. Others take the opposite approach, leaving familiar components till last because they know how to develop them. Some developers like to define data early in the process and then use this to drive the program development; others leave data unspecified for as long as possible.

Normally, programmers carry out some testing of the code they have developed. This often reveals program defects (bugs) that must be removed from the program. Finding and fixing program defects is called debugging. Defect testing and debug- ging are different processes. Testing establishes the existence of defects. Debugging is concerned with locating and correcting these defects.

When you are debugging, you have to generate hypotheses about the observa- ble behavior of the program and then test these hypotheses in the hope of finding the fault that caused the output anomaly. Testing the hypotheses may involve trac- ing the program code manually. It may require new test cases to localize the prob- lem. Interactive debugging tools, which show the intermediate values of program variables and a trace of the statements executed, are usually used to support the debugging process.

인터페이스를 정의하고 구현하며, 많은 경우 개발자는 각 프로그램 구성요소의 작동에 대한 세부사항만 추가하면 된다.

프로그래밍은 개인의 활동이며, 일반적으로 따르는 일반적인 과정은 없다. 일부 프로그래머는 자신이 이해하는 구성 요소에서 시작하여 이를 발전시킨 다음 덜 이해되는 구성 요소로 이동한다. 다른 이들은 다른 요소들을 개발하는 방법을 알고 있기 때문에 친숙한 요소들을 마지막까지 남겨둔 채 정반대의 접근법을 취한다. 일부 개발자들은 프로세스 초기에 데이터를 정의한 다음 이를 사용하여 프로그램 개발을 추진하는 것을 좋아하고, 다른 개발자들은 가능한 한 오랫동안 데이터를 지정하지 않은 채로 둔다.

일반적으로 프로그래머들은 자신들이 개발한 코드에 대해 몇 가지 테스트를 수행한다. 이것은 종종 프로그램에서 제거되어야 하는 프로그램 결함(버그)을 드러낸다. 프로그램 결함을 찾아 고치는 것을 디버깅이라고 한다. 결함 테스트와 디버깅은 서로 다른 과정이다. 테스트는 결함의 존재를 입증한다. 디버깅은 이러한 결점을 찾아 수정하는 것과 관련이 있다.

디버깅을 할 때는 프로그램의 관찰 동작에 대한 가설을 생성한 다음 출력 이상을 유발한 결함을 찾기 위해 이러한 가설을 테스트해야 한다. 가설을 시험하는 것은 프로그램 코드를 수동으로 추적하는 것을 포함할 수 있다. 검사를 국소화하기 위해 새로운 테스트 사례가 필요할 수 있다. 프로그램 변수의 중간값과 실행된 문장의 추적을 보여주는 대화형 디버깅 도구는 대개 디버깅 프로세스를 지원하기 위해 사용된다.

2.2.3 소프트웨어 유효성 검사(Software validation)

Software validation or, more generally, verification and validation (V & V) is intended to show that a system both conforms to its specification and meets the expectations of the system customer. Program testing, where the system is executed using simulated test data, is the principal validation technique. Validation may also involve checking processes, such as inspections and reviews, at each stage of the software process from user requirements definition to program development. However, most V & V time and effort is spent on program testing.

Except for small programs, systems should not be tested as a single, monolithic unit. Figure 2.6 shows a three-stage testing process in which system components are individually tested, then the integrated system is tested. For custom software, cus- tomer testing involves testing the system with real customer data. For products that are sold as applications, customer testing is sometimes called beta testing where selected users try out and comment on the software.

소프트웨어 검증 또는 보다 일반적으로 검증 및 검증(V & V)은 시스템이 모두 사양에 부합하고 시스템 고객의 기대를 충족한다는 것을 보여주기 위한 것이다. 시뮬레이션된 테스트 데이터를 사용하여 시스템을 실행하는 프로그램 테스트는 주요 검증 기법이다. 유효성검사는 또한 사용자 요건 정의에서 프로그램 개발에 이르기까지 소프트웨어 프로세스의 각 단계에서 검사 및 검토와 같은 프로세스를 점검하는 것을 포함할 수 있다. 그러나 대부분의 V&V 시간과 노력은 프로그램 테스트에 소비된다.

작은 프로그램을 제외하고, 시스템은 단일 단위의 단일 단위로 시험해서는 안 된다. 그림 2.6은 시스템 구성품을 개별적으로 시험한 다음 통합 시스템을 시험하는 3단계 시험 과정을 나타낸다. 사용자 정의 소프트웨어의 경우, cus-tomer 테스트는 실제 고객 데이터로 시스템을 테스트하는 것을 포함한다. 애플리케이션으로 판매되는 제품의 경우, 고객 테스트는 선택된 사용자가 소프트웨어에 대해 시험해 보고 의견을 제시하는 베타 테스트라고 불리기도 한다.

The stages in the testing process are:

시험 프로세스의 단계는 다음과 같다.

1. Component testing The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components. Components may be simple entities such as functions or object classes or may be coherent groupings of these entities. Test automation tools, such as JUnit for Java, that can rerun tests when new versions of the component are created, are commonly used (Koskela 2013).

2. System testing System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems. It is also concerned with showing that the system meets its functional and non-functional requirements, and testing the emergent system properties. For large systems, this may be a multistage process where components are integrated to form subsystems that are individually tested before these subsystems are integrated to form the final system.

3. Customer testing This is the final stage in the testing process before the system is accepted for operational use. The system is tested by the system customer (or potential customer) rather than with simulated test data. For custom-built software, customer testing may reveal errors and omissions in the system requirements definition, because the real data exercise the system in different ways from the test data. Customer testing may also reveal requirements problems where the system’s facilities do not really meet the users’ needs or the system performance is unacceptable. For products, customer testing shows how well the software product meets the customer’s needs.

4. 구성품 시험 시스템을 구성하는 구성품들은 시스템을 개발하는 사람들에 의해 시험된다. 각 구성품은 다른 시스템 구성품 없이 독립적으로 시험한다. 구성요소는 기능이나 객체 클래스와 같은 단순한 실체일 수도 있고 이러한 실체의 일관성 있는 그룹일 수도 있다. 새로운 버전의 구성 요소가 생성될 때 테스트를 다시 실행할 수 있는 Java용 JUnit와 같은 테스트 자동화 도구가 일반적으로 사용된다(Koskela 2013).

5. 시스템 테스트 시스템 구성 요소를 통합하여 완전한 시스템을 만든다. 이 프로세스는 요소와 요소 인터페이스 문제 사이의 예상치 못한 상호작용에서 발생하는 오류를 발견하는 것과 관련이 있다. 또한 시스템이 기능 및 비기능 요건을 충족함을 보여주고, 비상계통 특성을 시험하는 것도 고려한다. 대형 시스템의 경우, 이것은 구성품이 최종 시스템을 형성하기 위해 통합되기 전에 개별적으로 시험되는 서브시스템을 형성하기 위해 통합되는 다단계 프로세스일 수 있다.

6. 고객시험 이것은 시스템이 운영용으로 인정되기 전 시험 프로세스의 마지막 단계다. 시스템은 시뮬레이션된 테스트 데이터가 아닌 시스템 고객(또는 잠재적 고객)에 의해 테스트된다. 맞춤 제작 소프트웨어의 경우, 실제 데이터는 테스트 데이터와 다른 방식으로 시스템을 실행하기 때문에 고객 테스트는 시스템 요구 사항 정의에 오류와 누락을 나타낼 수 있다. 고객 시험은 또한 시스템의 설비가 사용자의 요구를 실제로 충족시키지 못하거나 시스템 성능을 수용할 수 없는 요건 문제를 나타낼 수 있다. 제품의 경우, 고객 테스트는 소프트웨어 제품이 고객의 요구를 얼마나 잘 충족하는지 보여준다.

Ideally, component defects are discovered early in the testing process, and inter- face problems are found when the system is integrated. However, as defects are dis- covered, the program must be debugged, and this may require other stages in the testing process to be repeated. Errors in program components, say, may come to light during system testing. The process is therefore an iterative one with informa- tion being fed back from later stages to earlier parts of the process.

Normally, component testing is simply part of the normal development process. Programmers make up their own test data and incrementally test the code as it is developed. The programmer knows the component and is therefore the best person to generate test cases.

If an incremental approach to development is used, each increment should be tested as it is developed, with these tests based on the requirements for that incre- ment. In test-driven development, which is a normal part of agile processes, tests are developed along with the requirements before development starts. This helps the testers and developers to understand the requirements and ensures that there are no delays as test cases are created.

When a plan-driven software process is used (e.g., for critical systems develop- ment), testing is driven by a set of test plans. An independent team of testers works

이상적으로는 시험 프로세스 초기에 부품 결함이 발견되고, 시스템 통합 시 얼굴 간 문제가 발견되는 것이 바람직하다. 단, 결함이 있는 경우에는 반드시 프로그램을 디버깅해야 하며, 이로 인해 시험 프로세스의 다른 단계를 반복해야 할 수 있다. 예를 들어 시스템 테스트 중에 프로그램 구성 요소의 오류가 드러날 수 있다. 따라서 프로세스는 후기에서 프로세스의 초기 부분으로 피드백을 받는 반복적인 것이다.

일반적으로 구성품 시험은 단순히 정상적인 개발 과정의 일부분이다. 프로그래머들은 자체 테스트 데이터를 구성하고 코드를 개발하면서 점진적으로 테스트한다. 프로그래머는 구성요소를 알고 있으므로 시험 케이스를 생성하기에 가장 좋은 사람이다.

개발에 대한 증분 접근법을 사용하는 경우, 각 증분 접근법을 개발하면서 그러한 증분 요건에 기초한 시험을 실시해야 한다. 민첩한 프로세스의 정상적인 부분인 시험 구동 개발에서는 개발 시작 전 요건과 함께 시험이 개발된다. 이는 시험실무자와 개발자가 요구사항을 이해하고 시험사례가 생성될 때 지연이 발생하지 않도록 하는 데 도움이 된다.

계획 중심 소프트웨어 프로세스를 사용할 경우(예: 중요 시스템 개발), 테스트는 일련의 테스트 계획에 의해 구동된다. 독립된 시험관 팀이 작업한다.

[Figure 2.7 Testing phases in a plan-driven software process

from these test plans, which have been developed from the system specification and design. Figure 2.7 illustrates how test plans are the link between testing and develop- ment activities. This is sometimes called the V-model of development (turn it on its side to see the V). The V-model shows the software validation activities that corre- spond to each stage of the waterfall process model.

When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the sys- tem developers. This exposes the product to real use and detects errors that may not have been anticipated by the product developers. After this feedback, the software product may be modified and released for further beta testing or general sale.

시스템 사양 및 설계에서 개발된 이러한 테스트 계획으로부터. 그림 2.7은 시험 계획서가 시험 활동과 개발 활동 사이의 연관성을 보여준다. 이것을 개발의 V모형이라고 부르기도 한다(V를 보기 위해 옆으로 돌린다). V-모델은 폭포수 프로세스 모델의 각 단계에 따라 수행되는 소프트웨어 검증 활동을 보여준다.

시스템을 소프트웨어 제품으로 마케팅할 때는 베타 테스트라고 하는 테스트 프로세스를 사용하는 경우가 많다. 베타 테스트는 그 시스템을 사용하기로 동의하는 많은 잠재적 고객들에게 시스템을 제공하는 것을 포함한다. 그들은 시스템 개발자들에게 문제를 보고한다. 이것은 제품을 실제 사용으로 노출시키고 제품 개발자들이 예상하지 못했던 오류를 감지한다. 이 피드백 후, 소프트웨어 제품은 추가 베타 테스트 또는 일반 판매를 위해 수정 및 출시될 수 있다.

2.2.4 소프트웨어 진화(Software evolution)

The flexibility of software is one of the main reasons why more and more software is being incorporated into large, complex systems. Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design. However, changes can be made to software at any time during or after the system development. Even extensive changes are still much cheaper than corresponding changes to system hardware.

Historically, there has always been a split between the process of software development and the process of software evolution (software maintenance). People think of software development as a creative activity in which a software system is developed from an initial concept through to a working system. However, they sometimes think of software maintenance as dull and uninteresting. They think that software maintenance is less interesting and challenging than original soft- ware development.

This distinction between development and maintenance is increasingly irrelevant. Very few software systems are completely new systems, and it makes much more

소프트웨어의 유연성은 점점 더 많은 소프트웨어가 크고 복잡한 시스템에 통합되는 주된 이유 중 하나이다. 하드웨어 제조 결정이 내려지면 하드웨어 설계를 변경하는 것은 매우 비싸다. 단, 시스템 개발 도중이나 시스템 개발 후에 언제든지 소프트웨어에 대한 변경을 실시할 수 있다. 광범위한 변경도 시스템 하드웨어의 해당 변경보다 훨씬 저렴하다.

역사적으로, 소프트웨어 개발 과정과 소프트웨어 진화 과정(소프트웨어 유지 관리) 사이에는 항상 분열이 있었다. 사람들은 소프트웨어 개발을 초기 개념에서 작업 시스템에 이르기까지 소프트웨어 시스템이 개발되는 창조적인 활동으로 생각한다. 그러나 그들은 때때로 소프트웨어 유지보수를 둔하고 재미없다고 생각한다. 그들은 소프트웨어 정비가 원래의 소프트웨어 개발보다 덜 흥미롭고 도전적이라고 생각한다.

개발과 유지 사이의 이러한 구별은 점점 더 무관하다. 아주 적은 수의 소프트웨어 시스템만이 완전히 새로운 시스템이며, 훨씬 더 많은 것을 만든다.

[Figure 2.8 Software system evolution]

sense to see development and maintenance as a continuum. Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process (Figure 2.8) where software is continually changed over its lifetime in response to changing requirements and customer needs.

발전과 유지를 하나의 연속체로 보는 감각 두 개의 분리된 프로세스보다는 소프트웨어 공학을 변화하는 요구사항과 고객 요구에 대응하여 소프트웨어가 수명주기 동안 지속적으로 변화하는 진화 과정(그림 2.8)으로 생각하는 것이 더 현실적이다.

2.3 변경 사항 복사(Coping with change)

Change is inevitable in all large software projects. The system requirements change as businesses respond to external pressures, competition, and changed management priorities. As new technologies become available, new approaches to design and implementation become possible. Therefore whatever software pro- cess model is used, it is essential that it can accommodate changes to the software being developed.

Change adds to the costs of software development because it usually means that work that has been completed has to be redone. This is called rework. For example, if the relationships between the requirements in a system have been ana- lyzed and new requirements are then identified, some or all of the requirements analysis has to be repeated. It may then be necessary to redesign the system to deliver the new requirements, change any programs that have been developed, and retest the system.

Two related approaches may be used to reduce the costs of rework:

모든 대형 소프트웨어 프로젝트에서 변화는 불가피하다. 기업이 외부의 압력, 경쟁, 변화된 경영 우선순위에 대응함에 따라 시스템 요구사항이 변화한다. 새로운 기술을 이용할 수 있게 되면서 설계와 구현에 대한 새로운 접근법이 가능해진다. 따라서 어떤 소프트웨어 프로시저 모델을 사용하든, 개발 중인 소프트웨어에 대한 변경사항을 수용할 수 있는 것이 필수적이다.

변화는 대개 완료된 작업을 다시 해야 한다는 것을 의미하기 때문에 소프트웨어 개발 비용에 추가된다. 이것을 재작업이라고 한다. 예를 들어, 시스템의 요구사항들 사이의 관계가 제한되고 새로운 요구사항들이 확인되는 경우, 요구사항 분석의 일부 또는 전부를 반복해야 한다. 그런 다음 새로운 요구사항을 전달하고, 개발된 프로그램을 변경하고, 시스템을 다시 테스트하기 위해 시스템을 재설계해야 할 수 있다.

재작업 비용을 줄이기 위해 두 가지 관련 접근법을 사용할 수 있다.

1. Change anticipation, where the software process includes activities that can anticipate or predict possible changes before significant rework is required. For example, a prototype system may be developed to show some key features of the system to customers. They can experiment with the prototype and refine their requirements before committing to high software production costs.

2. Change tolerance, where the process and software are designed so that changes can be easily made to the system. This normally involves some form of incre- mental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have to be altered to incorporate the change.

3. 소프트웨어 프로세스에는 상당한 재작업이 요구되기 전에 가능한 변경을 예측하거나 예측할 수 있는 활동이 포함된 변경 예상. 예를 들어, 프로토타입 시스템은 고객에게 시스템의 일부 주요 특징을 보여주기 위해 개발될 수 있다. 그들은 높은 소프트웨어 생산 비용을 지불하기 전에 프로토타입으로 실험하고 그들의 요구 사항을 구체화할 수 있다.

4. 공정과 소프트웨어가 설계되어 시스템에 쉽게 변경될 수 있도록 허용오차를 변경한다. 이것은 보통 정신 발달의 어떤 형태를 포함한다. 제안된 변경은 아직 개발되지 않은 점진적으로 이행될 수 있다. 이것이 불가능한 경우, 단 하나

In this section, I discuss two ways of coping with change and changing system requirements:

이 절에서는 변화에 대처하는 방법과 시스템 요구사항의 변경에 대한 두 가지 방법에 대해 논한다.

1. System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This is a method of change anticipation as it allows users to experiment with the system before delivery and so refine their requirements. The number of requirements change proposals made after delivery is therefore likely to be reduced.

2. Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. It avoids the premature commitment to requirements for the whole system and allows changes to be incorporated into later increments at relatively low cost.

3. 시스템 프로토타이핑, 고객의 요구사항과 설계 결정의 타당성을 확인하기 위해 시스템 버전이나 시스템의 일부를 신속하게 개발한다. 이것은 사용자들이 전달 전에 시스템을 실험할 수 있게 해주며 그들의 요구 조건을 구체화시키기 때문에 변화를 기대하는 방법이다. 따라서 납품 후 제안하는 요구사항 변경 제안의 수는 감소할 가능성이 있다.

4. 증분 전달: 고객에게 설명 및 실험을 위해 시스템 증분 전달 이는 변경 회피와 변경 허용오차를 모두 지원한다. 그것은 전체 시스템에 대한 요건에 대한 조기 이행을 방지하고 비교적 낮은 비용으로 변경사항을 나중의 증분으로 통합할 수 있도록 한다.

The notion of refactoring, namely, improving the structure and organization of a program, is also an important mechanism that supports change tolerance. I discuss this in Chapter 3 (Agile methods).

리팩터링의 개념, 즉 프로그램의 구조와 구성을 개선하는 것도 변화 허용오차를 지원하는 중요한 메커니즘이다. 나는 이것을 제3장(아기법)에서 논한다.

2.3.1 프로토타이핑(Prototyping)

A prototype is an early version of a software system that is used to demonstrate con- cepts, try out design options, and find out more about the problem and its possible solutions. Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process.

A software prototype can be used in a software development process to help anticipate changes that may be required:

프로토타입은 소프트웨어 시스템의 초기 버전이며, 이를 통해 문제를 시연하고, 설계 옵션을 시험해 보고, 문제 및 가능한 해결책에 대해 자세히 알아볼 수 있다. 비용을 통제하고 시스템 이해당사자들이 소프트웨어 프로세스 초기에 프로토타입을 실험할 수 있도록 프로토타입을 빠르고 반복적으로 개발하는 것이 필수적이다.

소프트웨어 프로토타입을 소프트웨어 개발 프로세스에서 사용하여 필요할 수 있는 변경사항을 예측할 수 있다.

1. In the requirements engineering process, a prototype can help with the elicita- tion and validation of system requirements.

2. In the system design process, a prototype can be used to explore software solu- tions and in the development of a user interface for the system.

3. 요구사항 엔지니어링 프로세스에서 프로토타입이 시스템 요구 사항의 도출 및 검증에 도움이 될 수 있다.

4. 시스템 설계 프로세스에서 프로토타입을 사용하여 소프트웨어 솔루션을 탐구하고 시스템을 위한 사용자 인터페이스를 개발할 수 있다.

System prototypes allow potential users to see how well the system supports their work. They may get new ideas for requirements and find areas of strength and weak- ness in the software. They may then propose new system requirements. Furthermore, as the prototype is developed, it may reveal errors and omissions in the system requirements. A feature described in a specification may seem to be clear and useful. However, when that function is combined with other functions, users often find that their initial view was incorrect or incomplete. The system specification can then be modified to reflect the changed understanding of the requirements.

시스템 프로토타입을 통해 잠재적인 사용자는 시스템이 자신의 작업을 얼마나 잘 지원하는지 알 수 있다. 그들은 요구사항에 대한 새로운 아이디어를 얻을 수 있고 소프트웨어에서 강점과 약점이 있는 영역을 찾을 수 있을 것이다. 그런 다음 그들은 새로운 시스템 요구사항을 제안할 수 있다. 또한 프로토타입을 개발함에 따라 시스템 요구 사항의 오류와 누락이 드러날 수 있다. 규격에 기술된 특성은 명확하고 유용할 수 있다. 그러나, 그 기능이 다른 기능과 결합될 때, 사용자들은 종종 그들의 초기 관점이 부정확하거나 불완전하다는 것을 알게 된다. 시스템 사양은 요구사항의 변경된 이해를 반영하도록 수정될 수 있다.

[Figure 2.9 Prototype development]

A system prototype may be used while the system is being designed to carry out design experiments to check the feasibility of a proposed design. For example, a database design may be prototyped and tested to check that it supports efficient data access for the most common user queries. Rapid prototyping with end-user involve- ment is the only sensible way to develop user interfaces. Because of the dynamic nature of user interfaces, textual descriptions and diagrams are not good enough for expressing the user interface requirements and design.

A process model for prototype development is shown in Figure 2.9. The objec- tives of prototyping should be made explicit from the start of the process. These may be to develop the user interface, to develop a system to validate functional system requirements, or to develop a system to demonstrate the application to man- agers. The same prototype usually cannot meet all objectives. If the objectives are left unstated, management or end-users may misunderstand the function of the pro- totype. Consequently, they may not get the benefits that they expected from the prototype development.

The next stage in the process is to decide what to put into and, perhaps more importantly, what to leave out of the prototype system. To reduce prototyping costs and accelerate the delivery schedule, you may leave some functionality out of the prototype. You may decide to relax non-functional requirements such as response time and memory utilization. Error handling and management may be ignored unless the objective of the prototype is to establish a user interface. Standards of reliability and program quality may be reduced.

The final stage of the process is prototype evaluation. Provision must be made during this stage for user training, and the prototype objectives should be used to derive a plan for evaluation. Potential users need time to become comfortable with a new system and to settle into a normal pattern of usage. Once they are using the system normally, they then discover requirements errors and omissions. A general problem with prototyping is that users may not use the prototype in the same way as they use the final system. Prototype testers may not be typical of system users. There may not be enough time to train users during prototype evaluation. If the prototype is slow, the evaluators may adjust their way of working and avoid those system features that have slow response times. When provided with better response in the final system, they may use it in a different way.

제안된 설계의 타당성을 확인하기 위해 시스템이 설계 실험을 수행하는 동안 시스템 프로토타입을 사용할 수 있다. 예를 들어, 데이터베이스 설계는 가장 일반적인 사용자 쿼리에 대해 효율적인 데이터 액세스를 지원하는지 확인하기 위해 프로토타입화 및 시험될 수 있다. 최종 사용자가 참여하는 신속한 시제품 제작은 사용자 인터페이스를 개발하는 유일한 합리적인 방법이다. 사용자 인터페이스의 동적 특성 때문에, 텍스트 설명과 다이어그램은 사용자 인터페이스 요건과 설계를 표현하기에 충분하지 않다.

프로토타입 개발을 위한 프로세스 모델은 그림 2.9와 같다. 시제품 제작의 하위 단계는 공정의 시작부터 명시되어야 한다. 이는 사용자 인터페이스를 개발하거나, 기능적 시스템 요건을 검증하기 위한 시스템을 개발하거나, 또는 인력진에게 응용 프로그램을 시연하기 위한 시스템을 개발하기 위한 것일 수 있다. 동일한 프로토타입이 일반적으로 모든 목표를 충족할 수는 없다. 목표를 달성하지 못한 채로 두면, 경영진이나 최종 사용자가 프로-토타입의 기능을 오해할 수 있다. 결과적으로, 그들은 원형 개발에서 기대했던 이익을 얻지 못할 수도 있다.

이 과정의 다음 단계는 무엇을 넣을지 그리고 아마도 더 중요한 것은 시제품 시스템에서 무엇을 빼낼지 결정하는 것이다. 프로토타입 제작 비용을 절감하고 납품 일정을 단축하기 위해 일부 기능을 시제품에 포함시키지 않을 수 있다. 응답 시간 및 메모리 사용률과 같은 비기능적 요구 사항을 완화하기로 결정할 수 있다. 프로토타입의 목적이 사용자 인터페이스를 설정하는 것이 아니라면 오류 처리 및 관리는 무시될 수 있다. 신뢰성 및 프로그램 품질의 표준은 축소될 수 있다.

공정의 최종 단계는 시제품 평가다. 사용자 교육을 위해 이 단계에서 프로비저닝을 수행해야 하며, 시제품 목표는 평가 계획을 도출하는 데 사용되어야 한다. 잠재적 사용자는 새로운 시스템에 익숙해지고 정상적인 사용 패턴으로 정착할 시간이 필요하다. 시스템을 정상적으로 사용하고 나면 요구 사항 오류 및 누락 사항을 발견한다. 프로토타이핑의 일반적인 문제는 사용자가 최종 시스템을 사용하는 것과 동일한 방법으로 프로토타입을 사용할 수 없다는 것이다. 프로토타입 테스터는 시스템 사용자의 일반적인 것이 아닐 수 있다. 프로토타입 평가 중에 사용자를 훈련시킬 시간이 충분하지 않을 수 있다. 프로토타입이 느린 경우 평가자는 작업 방식을 조정하고 응답 시간이 느린 시스템 기능을 피할 수 있다. 최종 시스템에서 더 나은 응답을 제공할 경우, 그들은 다른 방법으로 그것을 사용할 수 있다.

[Figure 2.10 Incremental delivery]

2.3.2 증분배달(Incremental delivery)

Incremental delivery (Figure 2.10) is an approach to software development where some of the developed increments are delivered to the customer and deployed for use in their working environment. In an incremental delivery process, customers define which of the services are most important and which are least important to them. A number of delivery increments are then defined, with each increment pro- viding a subset of the system functionality. The allocation of services to increments depends on the service priority, with the highest priority services implemented and delivered first.

Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail and that incre- ment is developed. During development, further requirements analysis for later increments can take place, but requirements changes for the current increment are not accepted.

Once an increment is completed and delivered, it is installed in the customer’s normal working environment. They can experiment with the system, and this helps them clarify their requirements for later system increments. As new increments are completed, they are integrated with existing increments so that system functionality improves with each delivered increment.

Incremental delivery has a number of advantages:

증분 전달(그림 2.10)은 개발된 증분 중 일부가 고객에게 전달되어 작업 환경에서 사용하기 위해 배치되는 소프트웨어 개발에 대한 접근방식이다. 점진적인 제공 프로세스에서 고객은 어떤 서비스가 가장 중요하고 어떤 서비스가 그들에게 가장 중요하지 않은지 정의한다. 그런 다음 다수의 전달 증분을 정의하고 각 증분을 시스템 기능의 하위 집합을 지지한다. 증분에 대한 서비스 할당은 서비스 우선 순위에 따라 달라지며, 가장 높은 우선순위 서비스가 먼저 구현되고 제공된다.

일단 시스템 증가가 확인되면, 첫 번째 증분에서 제공될 서비스에 대한 요건이 상세하게 정의되고 그 증가가 개발된다. 개발 중에 이후 증분에 대한 추가 요건 분석이 이루어질 수 있지만 현재 증분에 대한 요구사항 변경은 허용되지 않는다.

증분이 완료되고 전달되면 고객의 정상적인 작업 환경에 설치된다. 그들은 시스템을 실험할 수 있고, 이것은 그들이 나중에 시스템 증분에 대한 그들의 요구사항을 명확히 하는데 도움을 준다. 새로운 증분이 완료될 때, 그것들은 기존의 증분과 통합되어 각각의 전달된 증분에 따라 시스템 기능이 향상된다.

증분 전달에는 다음과 같은 여러 가지 장점이 있다.

1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. Unlike prototypes, these are part of the real system, so there is no relearning when the complete system is available.

2. Customers do not have to wait until the entire system is delivered before they can gain value from it. The first increment satisfies their most critical require- ments, so they can use the software immediately.

3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.

4. As the highest priority services are delivered first and later increments then inte- grated, the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most impor- tant parts of the system.

5. 고객은 초기 증분을 프로토타입으로 사용할 수 있으며 이후의 시스템 증분에 대한 요구 사항을 알려주는 경험을 얻을 수 있다. 프로토타입과는 달리, 이것들은 실제 시스템의 일부분이기 때문에 완전한 시스템을 이용할 수 있을 때 다시 배우는 것은 없다.

6. 고객은 전체 시스템이 제공될 때까지 기다릴 필요가 없다. 첫 번째 증가는 그들의 가장 중요한 요구조건을 충족시켜, 그들은 즉시 소프트웨어를 사용할 수 있다.

7. 이 프로세스는 변경사항을 시스템에 비교적 쉽게 통합할 수 있어야 한다는 점에서 점진적 발전의 이점을 유지한다.

8. 가장 높은 우선순위 서비스가 먼저 제공되고 나중에 증분하여 제공되므로, 가장 중요한 시스템 서비스는 가장 많은 시험을 받는다. 이는 고객들이 시스템의 가장 자극적인 부분에서 소프트웨어 고장에 직면할 가능성이 적다는 것을 의미한다.

However, there are problems with incremental delivery. In practice, it only works in situations where a brand-new system is being introduced and the system evaluators are given time to experiment with the new system. Key problems with this approach are:

그러나 증분배달에는 문제가 있다. 실제로, 그것은 새로운 시스템이 도입되고 시스템 평가자들이 새로운 시스템을 실험할 시간이 주어지는 상황에서만 작동한다. 이 접근방식의 주요 문제는 다음과 같다.

1. Iterative delivery is problematic when the new system is intended to replace an existing system. Users need all of the functionality of the old system and are usually unwilling to experiment with an incomplete new system. It is often impractical to use the old and the new systems alongside each other as they are likely to have different databases and user interfaces.

2. Most systems require a set of basic facilities that are used by different parts of the system. As requirements are not defined in detail until an increment is to be imple- mented, it can be hard to identify common facilities that are needed by all increments.

3. The essence of iterative processes is that the specification is developed in con- junction with the software. However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. In the incremental approach, there is no complete system specification until the final increment is specified. This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate.

4. 새로운 시스템이 기존 시스템을 대체하려는 경우 반복적인 전달은 문제가 된다. 사용자들은 구식 시스템의 모든 기능을 필요로 하며 대개 불완전한 새로운 시스템으로 실험하기를 꺼린다. 기존 시스템과 새로운 시스템을 서로 다른 데이터베이스와 사용자 인터페이스를 가지고 있을 가능성이 높기 때문에 함께 사용하는 것은 종종 비현실적이다.

5. 대부분의 시스템은 시스템의 다른 부분에서 사용되는 기본 설비의 집합을 요구한다. 요건은 증분을 함축할 때까지 자세히 정의되지 않으므로, 모든 증분에 의해 필요한 공통 설비를 식별하기 어려울 수 있다.

6. 반복 프로세스의 본질은 소프트웨어와 연계하여 사양을 개발한다는 것이다. 그러나 이는 시스템 전체 사양이 시스템 개발 계약의 일부인 많은 조직의 조달 모델과 상충된다. 증분 접근법에서는 최종 증분을 명시할 때까지 완전한 시스템 규격이 없다. 이를 위해서는 새로운 형태의 계약이 필요하며, 정부 기관과 같은 대형 고객들은 이를 수용하기 어려울 수 있다.

For some types of systems, incremental development and delivery is not the best approach. These are very large systems where development may involve teams working in different locations, some embedded systems where the software depends on hardware development, and some critical systems where all the requirements must be analyzed to check for interactions that may compromise the safety or security of the system.

These large systems, of course, suffer from the same problems of uncertain and changing requirements. Therefore, to address these problems and get some of the benefits of incremental development, a system prototype may be developed and used as a platform for experiments with the system requirements and design. With the experience gained from the prototype, definitive requirements can then be agreed.

일부 시스템의 경우, 증분 개발과 제공은 최선의 접근방식이 아니다. 이러한 시스템들은 다른 위치에서 작업하는 팀, 소프트웨어가 하드웨어 개발에 의존하는 임베디드 시스템, 그리고 시스템의 안전이나 보안을 훼손할 수 있는 상호작용을 확인하기 위해 모든 요건을 분석해야 하는 매우 큰 시스템들이다.

물론 이러한 대형 시스템은 불확실한 요구사항과 변화하는 요구사항의 동일한 문제를 겪는다. 따라서 이러한 문제를 해결하고 증분 개발의 이점을 얻기 위해 시스템 프로토타입을 개발하여 시스템 요구사항과 설계를 가진 실험의 플랫폼으로 사용할 수 있다. 프로토타입에서 얻은 경험으로 최종 요건이 합의될 수 있다.

2.4 프로세스 개선(Process improvement)

Nowadays, there is a constant demand from industry for cheaper, better software, which has to be delivered to ever-tighter deadlines. Consequently, many software companies have turned to software process improvement as a way of enhancing the

오늘날, 더 싸고 더 나은 소프트웨어에 대한 업계의 요구가 끊임없이 제기되고 있는데, 이 소프트웨어는 더 빠른 마감 시점으로 전달되어야 한다. 결과적으로, 많은 소프트웨어 회사들은 소프트웨어 프로세스 개선으로 눈을 돌렸다.

[Figure 2.11 The process improvement cycle]

quality of their software, reducing costs, or accelerating their development pro- cesses. Process improvement means understanding existing processes and changing these processes to increase product quality and/or reduce costs and development time. I cover general issues of process measurement and process improvement in detail in web Chapter 26.

Two quite different approaches to process improvement and change are used:

소프트웨어 품질, 비용 절감 또는 개발 가속화 프로세스 개선이란 기존 프로세스를 이해하고 이러한 프로세스를 변경하여 제품 품질을 높이고 비용과 개발 시간을 단축하는 것을 의미한다. 나는 웹 26장에서 프로세스 측정과 프로세스 개선의 일반적인 이슈를 상세히 다룬다.

공정 개선 및 변경에 대해 두 가지 서로 다른 접근방식을 사용한다.

1. The process maturity approach, which has focused on improving process and project management and introducing good software engineering practice into an organization. The level of process maturity reflects the extent to which good technical and management practice has been adopted in organizational software development processes. The primary goals of this approach are improved prod- uct quality and process predictability.

2. The agile approach, which has focused on iterative development and the reduc- tion of overheads in the software process. The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing cus- tomer requirements. The improvement philosophy here is that the best processes are those with the lowest overheads and agile approaches can achieve this. I describe agile approaches in Chapter 3.

3. 프로세스와 프로젝트 관리를 개선하고 조직에 우수한 소프트웨어 엔지니어링 관행을 도입하는 데 주력해 온 프로세스 성숙도 접근법. 프로세스 성숙도 수준은 조직 소프트웨어 개발 프로세스에서 우수한 기술 및 관리 관행이 채택된 정도를 반영한다. 이 접근방식의 주요 목표는 향상된 품질 및 프로세스 예측 가능성이다.

4. 소프트웨어 프로세스에서 반복적인 개발과 오버헤드 감소에 초점을 맞춘 민첩한 접근 방식. 민첩한 방법의 주요 특성은 변화하는 cus-tomer 요건에 대한 기능성과 대응성을 신속하게 제공하는 것이다. 여기서 개선 원칙은 가장 낮은 오버헤드와 민첩한 접근방식을 가진 프로세스들이 이를 달성할 수 있다는 것이다. 나는 3장에서 민첩한 접근법을 설명한다.

People who are enthusiastic about and committed to each of these approaches are generally skeptical of the benefits of the other. The process maturity approach is rooted in plan-driven development and usually requires increased “overhead,” in the sense that activities are introduced that are not directly relevant to program develop- ment. Agile approaches focus on the code being developed and deliberately mini- mize formality and documentation.

The general process improvement process underlying the process maturity approach is a cyclical process, as shown in Figure 2.11. The stages in this process are:

이러한 접근방식에 열광하고 각 접근방식에 전념하는 사람들은 일반적으로 상대방의 이익에 대해 회의적이다. 프로세스 성숙도 접근방식은 계획 중심 개발에 뿌리를 두고 있으며 프로그램 개발과 직접 관련이 없는 활동이 도입된다는 점에서 대개 “오버헤드”를 증가시켜야 한다. 민첩한 접근법은 개발 중인 코드에 초점을 맞추고 의도적으로 형식과 문서를 축소한다.

프로세스 성숙도 접근법의 기초가 되는 일반적인 프로세스 개선 프로세스는 그림 2.11과 같이 주기적인 프로세스다. 이 프로세스의 단계는 다음과 같다.

1. Process measurement You measure one or more attributes of the software pro- cess or product. These measurements form a baseline that helps you decide if process improvements have been effective. As you introduce improvements, you re-measure the same attributes, which will hopefully have improved in some way.

2. Process analysis The current process is assessed, and process weaknesses and bottlenecks are identified. Process models (sometimes called process maps) that describe the process may be developed during this stage. The analysis may be focused by considering process characteristics such as rapidity and robustness.

3. Process change Process changes are proposed to address some of the identified process weaknesses. These are introduced, and the cycle resumes to collect data about the effectiveness of the changes.

4. 프로세스 측정 소프트웨어 process 또는 제품의 속성을 하나 이상 측정한다. 이러한 측정은 프로세스 개선이 효과적인지 여부를 결정하는 데 도움이 되는 기준선을 형성한다. 개선 사항을 소개하면서 동일한 특성을 재측정하게 되는데, 이 특성이 어떤 식으로든 개선되었으면 좋겠다.

5. 공정분석 현재 공정을 평가하고, 공정의 약점과 병목현상을 파악한다. 프로세스를 설명하는 프로세스 모델(프로세스 맵이라고도 함)이 이 단계에서 개발될 수 있다. 분석은 신속성, 견고성 등의 공정 특성을 고려하여 중점적으로 분석할 수 있다.

6. 프로세스 변경 확인된 프로세스 약점 중 일부를 해결하기 위해 프로세스 변경을 제안한다. 이러한 사항이 도입되고, 변경의 효과에 대한 데이터를 수집하기 위한 사이클이 재개된다.

Without concrete data on a process or the software developed using that process, it is impossible to assess the value of process improvement. However, companies starting the process improvement process are unlikely to have process data available as an improvement baseline. Therefore, as part of the first cycle of changes, you may have to collect data about the software process and to measure software product characteristics. Process improvement is a long-term activity, so each of the stages in the improve- ment process may last several months. It is also a continuous activity as, whatever new processes are introduced, the business environment will change and the new

processes will themselves have to evolve to take these changes into account.

The notion of process maturity was introduced in the late 1980s when the Software Engineering Institute (SEI) proposed their model of process capability maturity (Humphrey 1988). The maturity of a software company’s processes reflects the process management, measurement, and use of good software engineering prac- tices in the company. This idea was introduced so that the U.S. Department of Defense could assess the software engineering capability of defense contractors, with a view to limiting contracts to those contractors who had reached a required level of process maturity. Five levels of process maturity were proposed. as shown in Figure 2.12. These have evolved and developed over the last 25 years (Chrissis, Konrad, and Shrum 2011), but the fundamental ideas in Humphrey’s model are still the basis of software process maturity assessment.

The levels in the process maturity model are:

공정에 관한 구체적인 데이터나 그 공정을 이용하여 개발된 소프트웨어 없이는 공정 개선의 가치를 평가할 수 없다. 그러나 프로세스 개선 프로세스를 시작하는 기업은 프로세스 데이터를 개선 기준으로 사용할 수 있을 것 같지 않다. 따라서 첫 번째 변경 주기의 일부로 소프트웨어 프로세스에 대한 데이터를 수집하고 소프트웨어 제품 특성을 측정해야 할 수 있다. 프로세스 개선은 장기적인 활동이므로, 개선 과정의 각 단계는 몇 달 동안 지속될 수 있다. 새로운 프로세스가 도입되면 비즈니스 환경이 변화하고 새로운 프로세스가 등장하기 때문에 지속적인 활동이기도 하다.

프로세스 자체는 이러한 변화를 고려하기 위해 진화해야 할 것이다.

프로세스 성숙도 개념은 1980년대 후반 소프트웨어 엔지니어링 연구소(SEI)가 프로세스 능력 성숙도 모델을 제안하면서 도입되었다(Humphrey 1988). 소프트웨어 회사의 프로세스의 성숙도는 회사의 우수한 소프트웨어 엔지니어링 절차의 프로세스 관리, 측정 및 사용을 반영한다. 이 아이디어는 미국 국방부가 필요한 프로세스 성숙 수준에 도달한 계약자로 계약을 제한하기 위해 방위사업자의 소프트웨어 엔지니어링 능력을 평가할 수 있도록 도입되었다. 5가지 수준의 공정 성숙도가 제안되었다. 그림 2.12와 같이. 이것들은 지난 25년간 발전하고 발전해 왔으나(Chrissis, Conrad, Shrum 2011), 험프리 모델의 근본적인 아이디어는 여전히 소프트웨어 프로세스 성숙도 평가의 기초가 된다.

공정 성숙도 모델의 수준은 다음과 같다.

1. Initial The goals associated with the process area are satisfied, and for all pro- cesses the scope of the work to be performed is explicitly set out and communi- cated to the team members.

2. Managed At this level, the goals associated with the process area are met, and organ- izational policies are in place that define when each process should be used. There must be documented project plans that define the project goals. Resource manage- ment and process monitoring procedures must be in place across the institution.

3. Defined This level focuses on organizational standardization and deployment of processes. Each project has a managed process that is adapted to the project require- ments from a defined set of organizational processes. Process assets and process measurements must be collected and used for future process improvements.

4. Quantitatively managed At this level, there is an organizational responsibility to use statistical and other quantitative methods to control subprocesses. That is, col- lected process and product measurements must be used in process management.

5. Optimizing At this highest level, the organization must use the process and product measurements to drive process improvement. Trends must be analyzed and the processes adapted to changing business needs.

6. 초기 프로세스 영역과 관련된 목표를 달성하고, 모든 작업에 대해 수행될 작업의 범위를 명시적으로 설정하여 팀 구성원에게 통보한다.

7. 이 수준에서 관리 프로세스 영역과 관련된 목표를 충족하고, 각 프로세스를 언제 사용해야 하는지를 규정하는 조직적 정책들이 마련되어 있다. 프로젝트 목표를 정의하는 문서화된 프로젝트 계획이 있어야 한다. 자원 관리 및 프로세스 모니터링 절차는 기관 전체에 걸쳐 실시되어야 한다.

8. 정의 이 레벨은 조직 표준화 및 프로세스 구축에 초점을 맞춘다. 각 프로젝트는 정의된 일련의 조직 프로세스에서 프로젝트 요구 사항에 맞게 조정되는 관리 프로세스를 가지고 있다. 프로세스 자산과 프로세스 측정은 수집하여 향후 프로세스 개선을 위해 사용해야 한다.

9. 정량적으로 관리됨 이 수준에서 통계적 방법 및 기타 정량적 방법을 사용하여 하위 프로세스를 제어해야 하는 조직적 책임이 있다. 즉, 공정 관리에 공동 강의된 공정과 제품 측정값을 사용해야 한다.

10. 최적화 이 최고 수준에서 조직은 프로세스 개선을 추진하기 위해 프로세스와 제품 측정을 사용해야 한다. 트렌드를 분석하고 변화하는 비즈니스 요구에 적응하는 프로세스를 분석해야 한다.

The work on process maturity levels has had a major impact on the software industry. It focused attention on the software engineering processes and practices that were used and led to significant improvements in software engineering capabil- ity. However, there is too much overhead in formal process improvement for small companies, and maturity estimation with agile processes is difficult. Consequently, only large software companies now use this maturity-focused approach to software process improvement.

프로세스 성숙도 수준에 대한 작업은 소프트웨어 산업에 큰 영향을 미쳤다. 그것은 사용되었던 소프트웨어 엔지니어링 프로세스와 관행에 초점을 맞추었고 소프트웨어 엔지니어링 카바빌리티를 크게 향상시켰다. 그러나 중소기업의 공식 공정 개선에는 오버헤드가 너무 많고, 민첩한 공정으로 성숙도 추정이 어렵다. 결과적으로, 현재 대형 소프트웨어 회사들만이 소프트웨어 프로세스 개선에 대한 성숙도 중심의 접근법을 사용하고 있다.

[Figure 2.12 Capability maturity levels]

Key points

■ Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.

■ General process models describe the organization of software processes. Examples of these general models include the waterfall model, incremental development, and reusable component configuration and integration.

■ Requirements engineering is the process of developing a software specification. Specifications are intended to communicate the system needs of the customer to the system developers.

■ Design and implementation processes are concerned with transforming a requirements specifi- cation into an executable software system.

■ Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.

■ Software evolution takes place when you change existing software systems to meet new requirements. Changes are continuous, and the software must evolve to remain useful.

■ Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole.

■ Process improvement is the process of improving existing software processes to improve soft- ware quality, lower development costs, or reduce development time. It is a cyclic process involv- ing process measurement, analysis, and change.

■ 소프트웨어 프로세스는 소프트웨어 시스템 생산과 관련된 활동이다. 소프트웨어 프로세스 모델은 이러한 프로세스의 추상적 표현이다.

■ 일반 프로세스 모델에서는 소프트웨어 프로세스의 구성을 설명한다. 이러한 일반 모델의 예로는 폭포 모델, 증분 개발 및 재사용 가능한 구성 요소 구성 및 통합을 들 수 있다.

■ 요구사항 엔지니어링은 소프트웨어 사양을 개발하는 과정이다. 사양은 고객의 시스템 요구를 시스템 개발자에게 전달하기 위한 것이다.

■ 설계 및 구현 프로세스는 요구사항 규격을 실행 가능한 소프트웨어 시스템으로 전환하는 것과 관련이 있다.

■ 소프트웨어 유효성 검사는 시스템이 사양에 부합하고 시스템 사용자의 실제 요구를 충족하는지 확인하는 과정이다.

■ 소프트웨어 진화는 기존 소프트웨어 시스템을 새로운 요구사항에 맞게 변경할 때 발생한다. 변화는 연속적이며, 소프트웨어는 유용하게 이용되기 위해 진화해야 한다.

■ 프로세스에는 변화에 대처하는 활동이 포함되어야 한다. 여기에는 요구사항과 설계에 대한 잘못된 결정을 피할 수 있도록 도와주는 시제품 제작 단계가 포함될 수 있다. 프로세스는 시스템을 전체적으로 방해하지 않고 변경될 수 있도록 반복 개발 및 전달을 위해 구성될 수 있다.

■ 프로세스 개선은 기존 소프트웨어 프로세스를 개선하여 소프트웨어 품질을 향상시키고 개발 비용을 낮추거나 개발 시간을 단축하는 과정이다. 그것은 프로세스 측정, 분석 및 변경에 관계없이 순환 과정이다.

Further reading

“Process Models in Software Engineering.” This is an excellent overview of a wide range of software engineering process models that have been proposed. (W. Scacchi, Encyclopaedia of Software Engineering, ed. J. J. Marciniak, John Wiley & Sons, 2001) http://www.ics.uci.edu/~wscacchi/ Papers/SE-Encyc/Process-Models-SE-Encyc.pdf

Software Process Improvement: Results and Experience from the Field. This book is a collection of papers focusing on process improvement case studies in several small and medium-sized Norwegian companies. It also includes a good introduction to the general issues of process improvement. (Conradi, R., Dybå, T., Sjøberg, D., and Ulsund, T. (eds.), Springer, 2006).

“Software Development Life Cycle Models and Methodologies.” This blog post is a succinct sum- mary of several software process models that have been proposed and used. It discusses the advan- tages and disadvantages of each of these models (M. Sami, 2012). http://melsatar.wordpress. com/2012/03/15/software-development-life-cycle-models-and-methodologies/

“소프트웨어 엔지니어링 분야의 프로세스 모델” 이것은 제안된 광범위한 소프트웨어 엔지니어링 프로세스 모델의 훌륭한 개요다. (W. Scacchi, 소프트웨어 엔지니어링 백과사전, ed. J. Marciniak, John Wiley & Sons, 2001) http://www.ics.uci.edu/~wscacchi/ 종이/SE-Encyc/Process-Models-Enc.pdf

소프트웨어 프로세스 개선: 현장에서의 결과 및 경험 이 책은 노르웨이 여러 중소기업의 공정개선 사례 연구에 초점을 맞춘 논문 모음집이다. 또한 공정개선의 일반적인 문제에 대한 좋은 소개도 포함되어 있다.(콘라디, R, 다이보, T, Sjøberg, D, Ulsund, T. (eds), 스프링거, 2006).

“소프트웨어 개발 라이프 사이클 모델과 방법론” 이 블로그 게시물은 제안되고 사용된 몇몇 소프트웨어 프로세스 모델의 간결한 요약이다. 본 문서에서는 각 모델의 장단점과 단점에 대해 논의한다(M. Sami, 2012). http://melsatar워드프레스. com/2012/03/15/소프트웨어 개발-라이프 사이클 모델 및 방법론/

Web Site

PowerPoint slides for this chapter: www.pearsonglobaleditions.com/Sommerville

Links to supporting videos:

http://software-engineering-book.com/videos/software-engineering/

Exercises

2.1. Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems. Explain your answer according to the type of system being developed:

A system to control antilock braking in a car

A virtual reality system to support software maintenance

A university accounting system that replaces an existing system

An interactive travel planning system that helps users plan journeys with the lowest environmental impact

2.2. Incremental software development could be very effectively used for customers who do not have a clear idea about the systems needed for their operations. Discuss.

2.3. Consider the integration and configuration process model shown in Figure 2.3. Explain why it is essential to repeat the requirements engineering activity in the process.

2.4. Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.

2.5. Using an example, explain why the design activities of architectural design, database design, interface design, and component design are interdependent.

2.6. Explain why software testing should always be an incremental, staged activity. Are program- mers the best people to test the programs that they have developed?

2.7. Imagine that a government wants a software program that helps to keep track of the utiliza- tion of the country’s vast mineral resources. Although the requirements put forward by the government were not very clear, a software company was tasked with the development of a prototype. The government found the prototype impressive, and asked it be extended to be the actual system that would be used. Discuss the pros and cons of taking this approach.

2.8. You have developed a prototype of a software system and your manager is very impressed by it. She proposes that it should be put into use as a production system, with new features added as required. This avoids the expense of system development and makes the system immediately useful. Write a short report for your manager explaining why prototype systems should not normally be used as production systems.

2.9. Suggest two advantages and two disadvantages of the approach to process assessment and improvement that is embodied in the SEI’s Capability Maturity framework.

2.10. Historically, the introduction of technology has caused profound changes in the labor market and, temporarily at least, displaced people from jobs. Discuss whether the introduction of extensive process automation is likely to have the same consequences for software engi- neers. If you don’t think it will, explain why not. If you think that it will reduce job opportuni- ties, is it ethical for the engineers affected to passively or actively resist the introduction of this technology?

2.1. 다음 시스템의 개발을 관리하는 기준으로 사용할 수 있는 가장 적절한 일반 소프트웨어 프로세스 모델을 제안한다. 개발 중인 시스템의 유형에 따라 답변 설명:

자동차의 안티록 브레이크를 제어하는 시스템

소프트웨어 유지 보수를 지원하는 가상현실 시스템

기존 제도를 대체하는 대학 회계 제도

사용자가 환경 영향을 최소화하면서 여행을 계획할 수 있도록 지원하는 대화형 여행 계획 시스템

2.2. 증분 소프트웨어 개발은 운영에 필요한 시스템에 대해 명확한 생각을 가지고 있지 않은 고객들에게 매우 효과적으로 사용될 수 있다. 상의하다

2.3. 그림 2.3에 표시된 통합 및 구성 프로세스 모델을 고려하십시오. 프로세스에서 요구사항 엔지니어링 활동을 반복해야 하는 이유를 설명하십시오.

2.4. 요건 엔지니어링 프로세스에서 사용자 요구사항의 개발과 시스템 요구사항의 개발을 구별하는 것이 중요한 이유를 제시한다.

예를 들어, 건축 설계, 데이터베이스 설계, 인터페이스 설계 및 구성요소 설계의 설계 활동이 상호의존적인 이유를 설명한다.

2.6. 소프트웨어 테스트가 항상 점진적이고 단계적인 활동이 되어야 하는 이유를 설명하십시오. 프로그램은 그들이 개발한 프로그램을 테스트할 수 있는 최고의 사람들인가?

2.7. 정부가 방대한 광물 자원의 활용도를 추적하는 데 도움이 되는 소프트웨어 프로그램을 원한다고 상상해 보라. 정부가 제시한 요구사항은 그다지 명확하지 않았지만, 한 소프트웨어 회사가 시제품 개발을 담당했다. 정부는 이 원형이 인상적이라고 보고, 이 원형이 실제 사용될 시스템으로 확장될 것을 요청했다. 이 접근법을 취하는 것의 장단점을 논하라.

2.8. 당신은 소프트웨어 시스템의 프로토타입을 개발했고 당신의 매니저는 그것에 매우 감명을 받았다. 그녀는 필요에 따라 새로운 기능이 추가되어 생산 시스템으로 사용되어야 한다고 제안한다. 이렇게 하면 시스템 개발 비용을 피할 수 있고 즉시 시스템을 유용하게 사용할 수 있다. 시제품 시스템이 일반적으로 생산 시스템으로 사용되어서는 안 되는 이유를 설명하는 짧은 보고서를 작성하십시오.

2.9. SEI의 공정 능력 성숙도 프레임워크에 구현된 공정 평가 및 개선 접근방식의 2가지 장점과 2가지 단점을 제안한다.

2.10. 역사적으로 기술의 도입은 노동 시장에 심오한 변화를 가져왔고 적어도 일시적으로 실직자들을 실업자로 만들었다. 광범위한 프로세스 자동화의 도입이 소프트웨어 기업에 동일한 결과를 가져올 수 있는지 여부를 논의하십시오. 만약 당신이 그렇게 생각하지 않는다면, 왜 그렇게 하지 않는지 설명하라. 만약 그것이 일자리 기회를 감소시킨다고 생각한다면, 영향을 받은 엔지니어들이 수동적으로 또는 이 기술의 도입을 적극적으로 거부하는 것이 윤리적인가?