[Software Engineering] 4주차 (1)

The Iterative Model - RUP

 

Rational Unified Process(* RUP) or UP

A software development approach that is:

해당 프로세스 모델은 다음과 같은 특성을 갖습니다:

• Iterative(* Incremental and Evolutionary)

Iterative모델입니다. 이는 Incremental하며 Evolutionary한 모델이라는 의미로, 조금씩 만들고(* Incremental) 반복하면서 요구사항을 계속 수정해 나간다는(* Evolutionary) 의미입니다.

 

• Risk-driven / Client-driven / Architecture-centric

The UP encourage a combination of risk-driven and client-driven iterative planning to identify and drive down the high risks(* architecturally), and to build visible features that clients care most about.

UP는 (* 소프트웨어 디자인적으로, 아키텍처를 생각했을 때) 높은 리스크들을 줄이고, 고객이 가장 신경쓰고 중요하다고 생각하는 특성들을 보여줍니다. 이는 UP가 (구조적)리스크와 고객으로 기준으로 움직임을 알 수 있습니다.

 

UP를 개발할 때, 소프트웨어 공학자들이 생각한 소프트웨어를 만들때의 가장 큰 위협은 크게 두 가지였습니다. UI/UX 측면에서의 Client요구사항 변경; 이는 앞서 말한 고객이 중요하다고 생각하는 특성에 해당합니다. 그리고 소프트웨어 구조의 변경이 있었습니다; 만약 소프트웨어의 구조가 마지막단계에서 변경된다면, 아에 처음부터 다시 소프트웨어를 만들어야하는 상황이 발생합니다.

 

이를 해결하기 위해 UP는 elaboration단계에서 SRS를 확정합니다. 이 단계는 여러개의 waterfall모델로 이루어지며, 고객과 적극적인 소통을 통해 requirements들을 변경하고 확정해나갑니다. 이 단계는 waterfall이 반복되며 requirements가 변경되니 Incremental하고 Evolutionary한 iterative모델이라 볼 수 있습니다.

 

이 단계에서 Architecture측면에서의 요구사항도 확정합니다. client의 요구사항에 맞는 architecture후보들 중 가장 cost-effective하고 다른 architecture들과 충돌하지 않는 architecture를 확정짓습니다.

 

• Use-Case-driven

그렇습니다...

 

A Well-defined and well structured software engineering process and A de-facto industry standard for developing OO software.

그리고 이는 잘 정의된 소프트웨어 공학적 프로세스이며, 이는 객체지향 소프트웨어의 개발 표준입니다.

 

RUP

 

앞서 설명했듯이, elaboration단계에서는 requirements의 확정을 위한 단계입니다. 이를 위해 각 반복마다 프로토타입을 만들어 고객에게 보여줍니다. 위에서 봤던 building visible featrues를 위한 프로토타입인 것입니다.

 

milestone단계가 지나면 requirements의 변경은 끝입니다. 그 후 construction단계에서는 구현과 디자인을 본격적으로 수행합니다. 이때는 요구사항이 매 반복마다 변경하지 않으므로, Evolutionary하지는 않다고 볼 수 있습니다.

 

RUP

 

이는 각 phase마다 집중하는 부분을 보여줍니다.

 

Waterfall vs Iterative

 

The waterfall process(= Plan-driven)

• All process activities are planned in advance.
• Progress is measured against this plan

폭포수 모델은 모든 프로세스 활동이 계획되어 있고, 계획에 의해 평가됩니다.

 

The Iterative process(= Agile, UP)

• Planning is incremental and iterative
• Easier to change the process to reflect changing customer requirements

반복형 모델은 계획이 점차적으로 진행되며, 반복적입니다. 또한 고객의 요구사항 변경에 대응하여 계획을 변경하기 쉽습니다.

 

Process Activities

 

The 4 basic process activities of specification, development, validation and evolution are organized differently in different development processes.

specification, development, validation과 evolution의 기본 4단계는 각자 다른 개발 프로세스로 구조화됩니다.

 

Requirements Engineering Process

 

RE(* Requirements Engineering)

The process of establishing what services are required and the constraints on the system's operation and development.

요구 공학은 어떤 서비스가 필요하고, 시스템의 동작이나 개발에 있어서 어떤 제약들이 있는지 설계하는 과정입니다. 이때, 어떤 서비스를 만들지는 Functional Requirements(* FR)이라고 하고, 제약들은 Non-functional(quality) Requirements(* NFR)이라고 합니다.

 

Requirements engineering process는 다음과 같은 단계로 구성됩니다. 이는 3단계가 서로 돌아가고 반복되며 최종적으로 SRS(* Software Requirements Specification)을 만듭니다:

• Requirements elicitation and analysis: What do the system stakeholders require or expect from the system

이해 관계자들이 어떤 시스템, 소프트웨어를 원하고 그 시스템, 소프트웨어로부터 어떤것을 기대하는지를 정합니다. 이 Requirements elicitation and analysis단계라고 합니다.

 

• Requirements specification: Defining the requirements in detail

디테일한 요구사항들을 결정합니다. 이를 요구 명세단계 Requirements specification단계라고 합니다. 이 단계에서 위에서 설명했던 FR과 NFR을 결정합니다.

 

• Requirements validation: Checking the validity of the requirements

요구사항들을 확인하는 단계를 Requirements validation단계라고 합니다. 이 단계에서는 각 요구사항들이 충돌하지 않는지, 실제로 달성가능한 요구사항인지를 평가합니다.

 

이를 그림으로 나타내면 다음과 같습니다.

RE

https://www.geeksforgeeks.org/software-engineering-requirements-engineering-process/

Requirements Engineering Process in Software Engineering - GeeksforGeeks

 

Software Design and Implementation

 

The process of converting the system specification into an executable system.

이전 단계에서 만들어진 SRS를 기반으로 실행가능한 파일을 만드는 과정입니다. 이 단계는 크게 두 가지의 단계로 구성됩니다:

•  Software design: Design a software structure that realizes the specification

요구 명세를 실현할 수 있는 소프트웨어 구조를 디자인하는 단계입니다. 디자인 단계는 또 크게 두 단계로 나누어지는데, High-level design으로 불리는 단계와, Low-level design으로 불리는 단계입니다. high-level은 조금 더 추상적인 단계로 프로그래밍 언어를 몰라도 수행할 수 있습니다. 이 단계에서는 Architecture나 Interface들을 정의합니다. low-level은 high-level에 비해 프로그램에 더 가까이 위치해있습니다. 이는 Implementation단계와 밀접하게 관련이 있기에 프로그래밍 언어를 알아야 수행할 수 있습니다.

 

• Implementation: Translate this structure into an executable program

앞선 단계에서 만들어진 구조를 실행가능한 프로그램으로 만드는 단계입니다.

 

디자인과 관련된 활동으로는 다음과 같은 활동들이 있습니다:

• Architectural design: Identify the overall structure of the system, the principal components (subsystem or modules), their relationships, and how they are distributed → AD(* Architecture Description): ISO/IEC/IEEE 42010:2011 - System and software Engineering - Architecture Description

아키텍처 디자인입니다. 이는 시스템의 전체적인 구조, 부분 시스템이나 모듈들과 같은 기본적인 컴포넌트들, 그들 사이의 관계와 얼마나 분산되어있는지를 정의합니다. 이는 AD를 통해 표현할 수 있습니다.

 

• Interface design: Define the interfaces between system components

인터페이스 디자인입니다. 이는 시스템 컴포넌트들 사이의 인터페이스들을 정의합니다.

 

• Component selection and design: Search for reusable components. If unavailable, you design how it will operate

컴포넌트 선택과 디자인입니다. 재사용 가능한 컴포넌트들을 찾고, 만약 적용할 수 없다면 어떻게 작동시킬지 디자인합니다.

 

• Database design: Design the system data structures and how these are to be represented in a database

데이터베이스 디자인입니다. 시스템의 데이터 구조를 디자인하고, 어떻게 데이터베이스 내에서 데이터가 표현되는지를 디자인합니다.

 

design activities

 

위 디자인 단계에서의 활동을 그림으로 나타내면 다음과 같습니다.

 

소프트웨어는 프로그램을 개발하고, 적용가능한 시스템들을 구성함으로써 구현됩니다. 구현과 관련된 활동으로는 다음과 같은 활동들이 있습니다:

• Programming(=coding): An individual activities with no standard process, Clean code + Refactoring + Unit Testing

프로그래밍, 코딩입니다. 어떤 프로세스 기준이 없는 개인적인 활동입니다. clean code와 리팩토링, 유닛 테스트가 포함됩니다. 이때 unit testing은 print를 찍는 등의 활동으로 하나의 unit이 executable한 상태여야합니다. 그 실행의 결과가 unit spec이나 원래 목표했던 결과와 같으면 test성공입니다.

 

• Debugging: An activities of finding (locating) program faults and correcting these faults, != Testing: An activities of detecting program faults.

디버깅입니다. 이는 프로그램의 결함을 찾고 이를 수정하는 활동입니다. 이 점에서 test와는 다른데, test는 그냥 프로그램의 결함을 탐지하는 것을 말하지만, 디버깅은 수정하는 활동까지 포함합니다.

 

Design and implementation are interleaved activities for most types of software system.

디자인과 구현은 거의 대부분의 소프트웨어 시스템의 종류에 들어가는 활동입니다.

 

Software Validation

 

Verification and Validation (* V&V) intends to show that a system conforms to its specification(* Verification) and meets the requirements of the system customer(* Validation); involves (static) code checking, review and system (dynamic) testing.

확인 및 검증 단계는 그것의 명세를 충족하는지(* 검증), 시스템이나 소프트웨어의 고객들의 요구사항에 충족하는지(* 확인)를 검사합니다. 이는 정적인 테스트인 code checking, review와 동적인 테스트인 dynamic testing을 포함합니다. 정적 테스트와 동적 테스트는 실행의 유무로 구분됩니다.

 

+ static test를 통해서 overflowm out of range등의 오류를 찾을 수 있고, dynamic test를 통해 runtime 오류를 찾을 수 있습니다.

 

Testing is the most commonly used V&V activitiy

Testing은 V&V에서 가장 많이 쓰이는 활동입니다.

 

Testing, V&V에 대한 기준으로 가장 많이 쓰이는 것은 IEEE 101-2016 - IEEE Standard for System, Software, and Hardware Verification and Validation입니다. 이는 (거의) 모든 상황에 대한 기준입니다.