소프트웨어 개발 단계 : 설계 / 구현 / 테스트

소프트웨어 설계

- 분석 단계(What) : 사용자의 요구사항으로 요구분석 명세서 작성

- 설계 단계(How) : 비기능적 요구사항과 제약사항 고려. 운영체제/미들웨어/프레임워크 등의 플랫폼 결정

- 설계 : 어떻게 구축할지. 설계를 평가할 정량적 기준 명시.

 

 

설계의 종류

- 상위 설계

• 아키텍처(구조) 설계 : 시스템의 전체적인 구조

• 데이터 설계 : 시스템에 필요한 정보를 자료구조와 데이터베이스 설계에 반영

• 시스템 분할 : 전체 시스템을 여러 개의 서브시스템으로 나눈다.

• 인터페이스 정의 : 시스템의 구조와 서브시스템들 사이의 인터페이스가 명확히 정의

• UI 설계 : 사용자가 익숙하고 편리하게 사용할 수 있도록 사용자 인터페이스설계

- 하위 설계

• 각 모듈의 실제적인 내부를 알고리즘(pseudo-code) 형태로 표현

• 인터페이스에 대한 설명, 자료구조, 변수 등에 대한 상세한 정보를 작성

 

소프트웨어 아키텍처

: 개발할 소프트웨어 대한 전체적인 구조를 다룬다.

: 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룬다.

: 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지를 정의해야 한다.

: 세부 내용보다는 중요한 부분만을 다룬다.

: 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 한다.

 

시스템 품질 속성

- 가용성(availability) : 시스템이 운용될 수 있는 확률로, 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력. 가용성을 높이려면, 하드웨어 이중화처럼 여분의 구성 요소를 포함하도록 설계

- 변경 용이성(modifiability) : 변경 요구 사항을 받았을 때 쉽게 변경할 수 있는 능력. 빈번하게 변경할 가능성이 높은 소프트웨어는 변경 용이성을 고려하여 아키텍처를 결정

- 성능(performance) : 사용자 요청과 같은 이벤트가 발생했을 때, 빠르고 적절하게 반응할 수 있는 능력. 공유 자원을 어떻게 사용하는지, 어떤 알고리즘을 사용해 구현하는지 등의 요소와 밀접

- 보안성(security) : 허용되지 않은 접근에 대응할 수 있는 능력

- 사용성(usability) : 소프트웨어를 사용할 때 혼란스러워하거나 사용하는 순간에 고민하지 않게 하는 편의성

- 테스트 용이성(testability) : 사용자가 요구하는 기능을 만족스럽게 잘 수행하고 있는지, 얼마나 쉽고 철저하게 테스트할 수 있는지 나타냄

 

비즈니스 품질 속성

- 시장 적시성(time to market) : 정해진 날짜에 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도

- 비용과 이익(cost and benefit) :비용을 더 들여 사용하고 효과를 볼 것인지, 아니면 비용을 절약하는 데 중심을 둘 것인지. 

       아키텍처를 설계 시: 비용을 더 많이 들여 유연한 설계를 할 것인지, 비용을 절감하는데 초점을 맞출 것인지 판단해야 함

- 예상 시스템 수명(predicted lifetime of the system) : 수명이 중요한 경우라면 변경 용이성, 확장성, 이식성을 더 중요하게 고려

- 목표 시장(targeted market) : 패키지 소프트웨어 -> 기능성 및 다양한 플랫폼에서 작동되어야 하므로, 이식성을 고려한 설계 필요

- 신규 발매 일정 또는 공개 일정(rollout schedule) : 현재 버전에서는 기본 기능만 제공하고, 추후에 배포할 차기 버전에서 기능을 추가하여 완성도를 높일 예정이라면 유연성과 확장성을 고려한 설계 필요

- 기존 시스템과의 통합(integration with legacy system) : 아키텍처 설계 시 기존 시스템과의 통합 방법을 충분히 고려한 설계 필요

 

아키텍처 품질 속성

> 개념적 무결성(conceptual integrity)
: 개념적 무결성은 일관성이라고도 함. 전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정

> 정확성과 완전성(correctness and completeness)

: 사용자가 요구하는 기능을 충족시키는 정도로, 요구 분석 명세서와 일치하는 정도

> 개발 용이성(구축 가능성, buildability)

: 전체 시스템을 적절한 모듈로 분할한 후 개발 팀에 알맞게 분배하여 개발함으로써 정해진 기간 내에 완성하고, 개발 과정 중에도 쉽게 변경할 수 있는 능력

 

 

아키텍처 구축 절차

1. 요구 사항 분석

:소프트웨어 개발의 요구 사항 분석 단계와 같다. 품질 속성과 같은 비기능적인 요구 사항에 더 많은 관심을 둠

• 요구 사항 취득, 식별, 명세, 분류, 검증

• 기능적/비기능적 요구 사항 분류 및 명세

2. 아키텍처 분석

: 품질속성 식별 -> 우선순위 식별 -> 반영 방법 개발

3. 아키텍처 설계

: 관점 정의: 이해 관계자 파악, 이해 관계자별 관점 정의

: 아키텍처 스타일 선택: pipe-filter, mvc, layer 등의 스타일 혼용 적용

: 후보 아키텍처 도출: 배경도 및 각 관점별 다이어그램 작성, 아키텍처 명세서 기술검증 및 승인

4. 검증 및 승인

: 아키텍처 평가: 아키텍처 요구 사항 만족도, 적합성, 품질 속성간 절충 관계 등 평가

: 아키텍처 상세화(반복): 설계 방법 도출, 설계 패턴 고려

: 아키텍처 승인: 이해 관계자들이 최종 승인

 

 

 

아키텍처 모델

 

1. 데이터 중심형 모델

 

> Repository Model

- 주요 데이터가 repository에서 중앙 관리

- repository와 여기에 접근하는 서브시스템으로 구성 
- 대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용한 모델

- 데이터가 한 군데에 모여 있기 때문에 데이터를 모순되지 않고 일관성 있게 관리 가능
- 새로운 서브시스템의 추가 용이

- repository의 병목 현상 발생 가능

- 서브시스템과 repository 사이의 강한 결합 -> repository 변경 시 서브시스템에 영향을 줌

 

> Client-server 모델

- 네트워크를 이용하는 분산 시스템 형태
- 데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용

- 분산 아키텍처에 유용

     -> 서버 : 클라이언트(서브시스템)에 서비스 제공

     -> 클라이언트 : 서버가 제공하는 서비스를 요청(호출)하는 서브시스템

 

>  layering 모델

- 기능을 몇 개의 계층으로 나누어 배치
- 구성: 하위 계층은 서버, 상위 계층은 클라이언트 역할

 

> MVC 모델(Model/View/Controller)

- 중앙 데이터 구조
- 같은 모델의 서브시스템에 대하여 여러 뷰 서브시스템을 필요로 하는 시스템에 적합

- 3개의 서브시스템으로 분리하는 이유: 변경에 대한 영향을 덜 미치도록 하기 위해. 즉 UI부분이 자주 변경되더라도 모델 서브시스템에는 영향을 주지 않기 위해.

 

- 장점

: 관심의 분리

: 데이터를 화면에 표현(뷰)하는 디자인과 로직(모델)을 분리함으로써 느슨한 결합

: 가능구조 변경 요청 시 수정 용이

- 단점

: 기본 기능 설계로 인한 클래스 수의 증가로 복잡도 증가

: 속도가 중요한 프로젝트에 부적합

 

-> Model 서브시스템 : 뷰/제어 서브시스템과 독립되어 모든 데이터 상태와 로직을 처리. 특정 입/출력 방식에 영향을 받지 않고, 무언가의 호출에 응답만 함

-> View 서브시스템 : 사용자와 직접 대화가 이루어지는 부분으로 데이터를 사용자에게 보여주는 역할

- >Controller 서브시스템 : 뷰를 통한 사용자의 요청을 적절한 모델 쪽으로 넘겨주고, 모델로부터 받은 응답을 다시 뷰를 통해 사용자에게 돌려주는 역할

 

 

 

 디자인패턴

- 자주 사용하는 설계 형태를 정형화해서 이를 유형별로 설계 템플릿을 만들어둔 것
- 많은 개발자들이 경험상 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿

 

-> 여러 가지 문제에 대한 설계 사례를 분석하여 서로 비슷한 문제를 해결하기 위한 설계들을 분류하고, 각 문제 유형별로 가장 적합한 설계를 일반화해 패턴으로 정립한 것을 의미

-> 소프트웨어 설계에 대한 지식이나 노하우가 문제 유형별로 잘 구체화되어 있을 뿐 아니라, 동일한 문제 유형에 대해서는 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충분히 일반화된 것

 

장점

• 개발자(설계자) 간의 원활한 의사소통

• 소프트웨어 구조 파악 용이
• 재사용을 통한 개발 시간 단축

• 설계 변경 요청에 대한 유연한 대처

단점

• 객체지향 설계/구현 위주

• 초기 투자 비용 부담

 

> Gof 디자인 패턴

1. Creational Pattern

- 객체를 생성하는데 관련된 패턴들

- 객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함.

2. Structual Pattern

- 프로그램 구조에 관련된 패턴들

- 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조 설계에 활용될 수 있는 패턴들

3. Behavioral Pattern 

- 반복적으로 사용되는 갳게들의 상호작용을 패턴화

 

 

 

모듈화

 

- 모듈화 : 소프트웨어 개발에서 큰 문제를 작은 단위로 나누는 것

- 모듈 : ‘규모가 큰 것을 여러 개로 나눈 조각’

            ‘소프트웨어 구조를 이루는 기본적인 단위’

            ‘하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합’

             독립 프로그램도 하나의 모듈

             함수(메서드)들도 하나의 모듈

 

- 모듈화의 특징

• 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위이다.
• 유일한 이름이 있어야 한다.

• 독립적으로 컴파일이 가능하다.

• 모듈에서 또 다른 모듈을 호출할 수 있다.

• 다른 프로그램에서도 모듈을 호출할 수 있다.

 

- 모듈화의 형태

• 용도가 비슷한 것끼리 묶어놓은 라이브러리 함수, 그래픽 함수

• 추상화된 자료, subroutine, procedure, object, method

 

- 좋은 모듈 설계를 위한 원칙
• 모듈 간의 결합(coupling)은 느슨하게(loosely)

• 모듈 내 구성 요소들 간의 응집(cohesion)은 강하게(strongly)

 

- 모듈화의 장점

• 분할과 정복(divide and conquer)의 원리가 적용되어 복잡도 감소한다.

• 문제를 이해하기 쉽게 만든다.

• 변경하기 쉽고, 변경으로 인한 영향이 적다.

• 유지보수가 용이하다.

• 프로그램을 효율적으로 관리할 수 있다.

• 오류로 인한 파급효과를 최소화할 수 있다.

• 설계 및 코드를 재사용할 수 있다.

 

- 응집도

> 모듈 내부에 존재하는 구성 요소들 사이의 밀접한 정도

 

1. 기능적 응집 : = 함수적 응집. 응집도가 가장 높은 경우이며 단일 기능의 요소로 하나의 모듈을 구성

2. 순차적 응집 : A 요소의 출력을 B 요소의 입력으로 사용하므로, 두 요소가 하나의 모듈을 구성한 경우

3. 교환적 응집 : = 정보적 응집. 같은 입력을 사용하는 구성 요소들을 하나의 모듈로 구성. 구성 요소들이 동일한 출력을 생산.

4. 절차적 응집 : 순서가 정해진 몇 개의 구성 요소를 하나의 모듈로 구성.(순서에 따라서만 수행)

5. 시간적 응집 : 그 구성 요소들이 같은 시간대에 함께 실행된다는 이유로 하나의 모듈로 구성

6. 논리적 응집 : 요소들 간에 공통점이 있거나 관련된 임무가 존재하거나 기능이 비슷하다는 이유로 하나의 모듈로 구성

7. 우연적 응집 : 특별한 이유 없이, 크기가 커 몇 개의 모듈로 나누는 과정에서 우연히 같이 묶인 것

 

 

- 결합도

> 모듈과 모듈 사이의 관계에서 관련 정도

1. 데이터 결합

 : 가장 좋은 모듈 간 결합
 : 모듈들이 매개변수를 통해 데이터만 주고받음으로써 서로 간섭을 최소화하는 관계

 : 모듈 간의 독립성 보장

 : 관계가 단순해 하나의 모듈을 변경했을 때 다른 모듈에 미치는 영향이 아주 적음

2. 스탬프 결합 스탬프 결합stamp coupling
 : 두 모듈 사이에서 정보를 교환할 때 필요한 데이터만 주고받을 수 없고 스탬프처럼 필요 없는 데이터까지 전체를 주고받아야 하는 경우

 : 레코드나 배열 같은 데이터 구조, C 언어의 구조체(struct)

3. 제어 결합 제어 결합

 : 제어 플래그를 매개변수로 사용하여 간섭하는 관계
 : 호출하는 모듈이 호출되는 모듈의 내부 구조를 잘 알고 논리적 흐름을 변경하는 관계

 : 정보은닉을 크게 위배하는 결합으로, 다른 모듈의 내부에 관여하여 관계가 복잡해진다.

4. 공통 결합 공통 결합

 : 모듈들이 공통 변수(전역변수)를 같이 사용하여 발생하는 관계
 : 문제점은 변수 값이 변하면 모든 모듈이 함께 영향을 받는다는 것

5. 내용 결합 내용 결합
 : 모듈 간에 인터페이스를 사용하지 않고 직접 왔다 갔다 하는 경우의 관계

 : 상대 모듈의 데이터를 직접 변경할 수 있어 서로 간섭을 가장 많이 하는 관계

 : C 언어의 goto 문

 

 

- 바람직한 설계

> 모듈 간에는 꼭 필요한 데이터만 주고받도록 적은 인터페이스의 수를 통한 약한 결합 유지

> 매개변수로 제어 플래그보다 데이터를 사용

> 유지보수 용이성 향상

=> 낮은 결합도! 높은 응집도!

 

 

 

방법론

1. 프로세스 지향 방법

: 처리순서를 구조화하는 방법

: 대표적인 모델 기법: DFD(Data Flow Diagram)

 

프로세스 지향 방법의 구성
: 기능이 중심(우선)이 되고, 그 기능을 수행하는 데 필요한 데이터가 참조되는 형태로 구성

 

프로세스 지향 방법의 특징

- 프로세스와 데이터의 분리

- 실세계를 컴퓨터 처리 방식으로 표현
- 함수 중심(우선)으로 모듈 구성

 

2. 데이터 지향 방법
- 시스템이 취급하는 데이터에 관심

- 즉, 데이터가 중심(우선)이 되어 데이터를 구조화

- 대표적 소프트웨어 개발 방법론 : 정보공학 방법론

- DB 설계를 위한 대표적 모델 표기법 : E-REntity-Relationship 다이어그램

 

3. 프로세스 지향 방법과 데이터 지향 방법의 문제점
- 변경이 미치는 영향이 큼 : 프로세스와 데이터를 각각 별개의 것으로 파악하기 때문

- 프로그램의 복잡도 증가함수와 데이터가 분리되어 있기 때문

- 프로그램 변경 시 프로그램 구조 파악 필요 : 프로그래머는 프로그램의 구조와 영향을 미치는 곳도 파악해야 함

- 재사용의 어려움 : 프로세스와 데이터가 분리된 구조 때문

 

4. 객체 지향 방법
- 프로세스 지향 방법과 데이터 지향 방법의 문제점을 해결하기 위해 고안

- 기능이나 데이터 대신 객체가 중심이 되어 개발

- 데이터(속성)를 가장 먼저 찾고 그 데이터를 조작하는 메서드(함수)를 찾아 그 둘을 객체로 하여, 그 객체를 중심으로 모듈을 구성

객체지향 방법의 특징

• 실세계를 사람이 생각하는 방식으로 표현한다.
• 임의로 데이터에 접근할 수 없다.

• 시스템은 객체들의 모임이다

• 요구 사항 변경에 유연하게 대처할 수 있다

• 확장성과 재사용성이 높아진다.

• 추상화를 통해 생산성과 품질이 높아진다

 

 

구현

코딩 규칙

- 높은 가독성

- 간결하고 명확한 코딩

- 개발 시간의 단축

 

 

테스트

전문가들의 소프트웨어 정의

> IEEE
 : 테스트는 시스템이 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과가 어떤 차이를 보이는지 수동이나 자동으로 검사하고 평가하는 작업

> Zoha Manna

 : 테스트는 시스템의 명세까지 완벽하게 옳다고 확신할 수 없고, 테스트 시스템 그 자체가 맞다고 증명할 수 없기 때문에 프로그램을 완전히 테스트할 수 없다.

> Dahl, Dijkstra, Hoare

: 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다.

 

 

소프트웨어 테스트 정의

- 소프트웨어에 내에 존재하지만 드러나지 않고 숨어 있는 오류를 발견할 목적으로, 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업

- 오류를 찾아내 정상적으로 실행될 수 있도록 하는 정도이지, 소프트웨어에 오류가 없음을 확인시켜주지는 못한다.

- 테스트는 오류를 찾고 올바르게 수정하여 프로그램을 작동시킬 수는 있지만, 그 프로그램이 완전하고 정확하다고 증명할 수는 없다.

 

소프트웨어 테스트의 목표

- 작은 의미

: 원시 코드 속에 남아 있는 오류를 발견하는 것

: 결함이 생기지 않도록 예방하는 것

- 큰 의미
: 개발된 소프트웨어가 고객의 요구를 만족시키는지 확인시켜주는 것

: 개발자와 고객에게 사용하기에 충분한 소프트웨어임을 보여주는 것

: 개발된 소프트웨어에 신뢰성을 높여주기 위한 작업

 

 

테스트에서 결함관련 용어

오류(error) : 소프트웨어 개발자에 의해 만들어지는 실수로 결함의 원인이 된다.

결함(defect, bug, fault) : 오류에 의해 프로그램이 완전치 못한 것으로, 고장의 원인이 된다.

고장, 실패(failure), 문제(problem), 장애 : 시스템이 요구 사항대로 작동하지 않는 것을 말한다.

 

 

테스트의 분류

1. 시각에 따른 테스트

> 확인 테스트(Vertification test)

: 각 단계에서 개발자의 시각으로 테스트

: 설계도 대로 만들었는지 테스트

> 검증 테스트(validation test)

: 사용자의 요구 사항대로 만들었는지를 테스트

: 사용자의 시각에서 테스트

 

2. 사용 목적에 따른 테스트

: 운영 목적 적합성 테스트
: 수정 용이성 테스트

: 운영 지원 테스트

 

3. 프로그램 실행 여부에 따른 테스트

- 정적 테스트 : 프로그램을 실행하지 않고 코드를 검토하며 오류를 찾는 방법

- 동적 테스트 : 프로그램을 실행하며 오류를 찾는 방법