SW 설계의 핵심 이슈

SW설계는 크게 아키텍처 설계와 상세설계로 나누어 볼 수 있다. SW아키텍처 설계(Software Architectural Design)는 상위레벨 설계로 일반적은 설계의 개념과 SW 관점에서의 설계의 역할을 이해하고 프로세스를 인지하여 설계의 다양한 접근방법과 개념을 이해할 수 있게 된다. SW상세설계(Software Detailed Design)는 모든 SW설계에서 다루어져야 하는 핵심이슈를 분별하여 효과적으로 설계의 산출물을 작성하는 것이다.

SW설계를 통해 얻을 수 있는 이점은 SW설계에 대한 기본지식의 이해다. 일반적인 설계의 개념과 SW관점에서의 설계역할을 이해하고 그 프로세스를 인지하여 설계의 다양한 접근방법과 개념을 이해할 수 있게 된다.

또한 설계시 다루어져야할 핵심이슈 인식을 위해 모든 SW설계에서 다루어져야 하는 핵심이슈를 분별하여 효과적으로 설계의 산출물을 작성할 수 있게 되는 것이다. 아울러 다양한 관점에서 SW구조와 아키텍처를 고려함으로서 뷰(View)와 아키텍처 스타일, 설계 패턴 그리고 프로그램 계열(Family of Programs)의 다양한 관점에서 설계를 고려하여 설계를 통해 SW품질을 향상시킬 수 있다. 마지막으로 SW설계에 사용되는 표기법 및 전략을 분류하고 선택하여 공유하기 용이하게 된다.

SW설계시 핵심이슈는 병행성, 이벤트의 통제와 처리, 컴포넌트의 분배, 오류/예외처리/장애의 허용 등 아래의 표와 같다.

아키텍처 구조와 관점 중 뷰(View)라는 것은 SW시스템의 특정 특성들을 보여주는 SW아키텍처의 부분적인 면들을 묘사하는 것으로 특정한 뷰는 SW설계와 관련 있는 특정한 이슈와 연관이 있다. 특정한 뷰는 기능적 요구사항을 표현할 수 있는 논리적 뷰(Logical view), Concurrency 이슈를 표현한 프로세스 뷰(Process view), 분배이슈를 표현한 물리적인 뷰(Physical view), 설계의 구현단위를 표현한 개발 뷰(Development view), 행동적(Behavioral) 뷰, 기능적(Functional) 뷰, 구조적(Structural) 뷰, 데이터 모델링(Dat Modeling) 뷰로 나눌 수 있다.

SW설계는 설계 프로세스로 생성되는 다양한 면(Multi-faceted)들을 가진 산출물(Artifact)이며, 각각 비교적 독립적이며 다른 측에서 바라보는(Orthogonal) 뷰로 이루어진다.
SW아키텍처 구조와 관점은 특정 아키텍처에 대한 제약사항(Constraints)의 집합을 의미하며 SW의 상위 레벨의 구성(Macro-architecture)을 규정 지을수 있는 메타모델이다. 주요 아키텍처 스타일은 아래와 같다.

설계패턴(Micro-architecture patterns)은 아키텍처 스타일이 상위레벨 구성을 설명한다.
패턴이란 주어진 상황 속에서 공통된 문제에 대한 공통된 솔루션을 의미하며, 설계 패턴이란 SW의 하위 또는 조금 더 로컬수준에서 세부사항을 설명하는데 사용한다.

주요 설계패턴은 Creational 패턴, Structural 패턴, Behavioral 패턴으로 나눌 수 있다.

프로그램의 계통과 프레임워크(Families of Programs and Frameworks)는 계통의 구성요소 사이의 공통성을 파악하고 다양성(Variability)을 처리한다. 또한 재사용 가능(Reusable)하고 맞춤 가능(Customizable)한 컴포넌트 사용을 통해 이루어진다.

프레임워크는 객체지향 프로그래밍에서 재사용설계에 관련된 핵심 개념으로 특정 플러그인을 적절하게 인스턴스 생성하여 확장할 수 있는 부분적으로 완성된 SW서브시스템을 의미한다.

프레임워크는 비즈니스 프레임워크와 어플리케이션 프레임워크로 나뉘며 비즈니스 프레임워크는 특정 비즈니스 도메인의 지식을 포착하여 재사용 가능한 비즈니스 클래스와 비즈니스 프로세스를 프레임워크 형태로 가공하여 제공한다.

어플리케이션 프레임워크는 어플리케이션 개발과정에 공통으로 사용되는 기술적인 서비스, 패턴, 아키텍처 등을 기반으로 구성하여 제공하는 것을 의미한다. SW설계와 컴포넌트를 재사용할 수 있도록 접근하는 방법은 SW Product-Line의 설계를 의미하기도 한다.

SW설계의 품질분석과 평가(SW Design Quality Analysis and Evaluation)를 위한 품질속성은(Quality Attributes) 목적의 적합성, 유지보수성(Maintainability), 이식성(Portability), 테스트 가능성(Testability), 추적가능성(Traceability), 정확성(Correctness), 강건성(Robustness)을 의미하며, 운영시점에서 관련된 품질속성은 성능(Performance), 보안성(Security), 가용성(Availability), 기능성(Functionality), 사용성(Usability)이 있다. 개발 시점에 관련된 품질속성은 수정가용성(Modifiability),이식성(Portability), 재사용성(Reusability), 통합성(Integrability), 테스트가능성(Testability)이 있다.

또한 아키텍처에 내재된 품질속성은 개념적 무결성(Conceptual Integrity), 정확성(Correctness), 완전성(Completeness), 구축 용이성(Buildability)이 있다.

SW 요구사항과 설계의 적용 방향

요구사항이란 이용자가 어떤 문제를 해결하거나 목표를 달성하기 위해 필요로 하는 조건이나 능력을 의미하며 계약을 수행하거나 표준에 맞추거나 산출물을 만족하기 위해 시스템의 전체 혹은 일부가 갖추어야 하는 조건이나 능력, 요구의 총체를 의미하기도 한다.

이러한 요구사항을 구조적, 이론적, 논리적으로 접근하고 최종산출물에 보다 가깝게 구현할 수 있도록 지원하는 것이 바로 SW요구공학이다. 요구사항의 획득, 분석, 명세, 검증 및 변경관리 등에 대한 제반활동과 원칙, 요구사항 생성 및 관리를 체계적, 반복적으로 수행하고, 요구사항 관리에 포함되는 모든 생명주기활동과 이를 지원하는 프로세스, 시스템 요구사항 문서를 생성, 검증, 관리하기 위하여 수행되는 구조화된 활동의 집합이기도 하다. 아울러 요구사항 명세를 최종 산출물로 생성한다.

< SW요구사항 관련 지식체계 및 국제표준 >

요구공학은 이해관계자 사이에 효과적인 커뮤니케이션 수단을 제공하고 요구사항에 대한 공통 이해를 설정한다. 요구사항에 대한 손실을 방지하고 에러 감지로 불필요한 비용을 절감하고 구조화된 요구사항으로 요구사항 변경 추적을 가능하게 하는 것이다.

요구사항의 개발은 이해관계자와 개발자가 함께 이해관계자의 니즈와 시스템 개발시 제약사항을 발견하여 검토하고 명확화 하는 이해과정인 요구사항 추출단계에서부터 추출된 요구사항을 분석하고 요구사항을 구조화하여 각종 대안들을 결정하는 피드백 역할을 수행하는 분석단계를 지나 분석과정에서 선별된 기능을 기반으로 요구사항을 명세화하고 요구사항의 승인기준(문서화, 명확성, 간결성, 이해성, 시험성, 사용성, 추적성, 검증성 등)을 정의하여 요구사항을 확인하고 검증하는 단계로 이루어져 있다.

요구사항 기법은 가장 전통적인 방식으로 분석과 고객간의 인터뷰 내용을 바탕으로 요구를 추출하는 Interview가 있으나 이해관계자들의 비협조, 애매모호성 단어, 과장, 누락의 위험이 있다. 또한 What과 How에 대한 프레임을 작성하여 고객으로부터의 요구사항에 대한 스토리를 작성하는 시나리오방식이 있다. 유즈케이스가 대표적이며 이해관계자들이 제시하는 프레임을 이해하거나 시나리오를 작성해야 하는 추가 작업이 뒤따른다. 추가적으로 프로토타입(구체적이지 못한 요구사항에 대해 UI 또는 MOCKUP 등을 통해 고객과의 피드백으로 요구추출), Facilitated Meeting(이해관계자들의 모임을 구성하여 브레인스토밍을 통해 요구추출), Obervation(WBS를 통해 각 분석가별 분석대상 업무의 할당, 사용자의 비즈니스 수행, 현행시스템 이용 관찰 등을 통해 요구추출), JAD(PROTO를 통한 고객과 개발자간 밀접한 관계로 서로간 의사소통의 결과를 제시) 등이 있다.

요구사항의 관리기법은 시나리오/Goal 기반 요구사항 획득, 유즈케이스를 이용한 요구사항 모델링, 품질요구사항을 위한 자동분류, 유사도 측정을 이용한 요구사항 변경관리 등이 있다.

Business concern, critical success factor로 불리기도 하는 목표(goal)는 용어적으로 SW에 대한 전반적이고 상위레벨의 목적(objectives)들을 말한다. 목표는 SW에 대한 동기를 부여하지만, 간혹 체계적이지 않은 경우도 있다. SW 엔지니어는 목표의 가치(상대적인 우선순위)와 목표에 드는 비용을 평가하는데 많은 노력을 기울여야 한다.

SW 엔지니어는 어플리케이션 도메인에 대한 지식을 습득하거나 이해할 필요가 있다. 이것은 SW 엔지니어가 이해관계자가 표현하지 않는 암묵적인 지식이나 상충되는 요구사항 간의 필요한 조정을 하거나, 필요시 사용자의 대변자로서의 역할을 수행할 수 있게 한다.

특정 그룹만의 요구사항을 강조하려다 보면 다른 그룹의 요구사항은 희생되어 많은 SW들이 불만족스러운 주요 원인이 되기도 한다. 결국 사용하기 어렵거나 고객 조직의 문화적 또는 정치적 구조를 배제한 SW가 고객에게 인도 되었다면 SW 엔지니어는 다양한 타입의 이해관계자들의 관점을 인지하고 나타나며 다룰 필요가 있다.

요구사항은 SW가 구현되는 환경에서 발생할 수도 있다. 예를 들어 실시간 시스템의 경우 시간의 제약이 발생할 수도 있다. 이러한 제약조건들은 SW 운용성과 비용에 큰 영향을 미칠 수 있으며 계획에 대한 선택을 제한할 수 있기 때문에 반드시 능동적인 노력이 필요하다.

SW는 종종 조직의 문화, 구조, 내부 정책에 따른 선택과 같은 업무프로세스를 지원하기도 한다. 새로운 SW가 업무 프로세스 상에서 계획하지 않은 변화를 강요하지 않아야 함으로 SW 엔지니어는 이런 것에 영향을 받고 신경을 써야할 필요가 있다.

요구사항의 정의에 있어서 이슈가 될 수 있는 것은 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement)의 구분이다. 기능적 요구사항은 고객 요구사항중에 수행될 기능과 관련되어 있는 입력과 출력 및 그들 사이의 처리과정이나 목표로 하는 제품의 구현을 위해 SW가 가져야하는 기능적 속성을 의미한다.

비기능적 요구사항이란 제품의 품질 기준 등을 만족시키기 위해 SW가 가져야 하는 성능(응답시간, 처리량 등), 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안정성, 유지보수성 등과 같은 행위적 특성으로 시스템의 기능에 관련되지 않는 요구사항들을 의미한다.

요구사항의 정의는 요구사항 분석단계의 비즈니스 모델링을 통해 수집된 사용자의 기능적 요구사항을 정형화하고 비기능 요구사항에 대해 체계적으로 분류하고 명세화 해야 한다. 또한 구축할 시스템의 범위와 개발 우선순위를 정해야 한다.

요구사항 분석단계에서 가장 중요한 산출물은 요구사항 정의서다. 요구사항 정의서는 프로젝트의 생명주기 내내 사용됨으로 시스템의 목표에 대한 구체적인 내용이 기술되어야 한다. 또한 요구사항 정의서는 사용자와 프로젝트 팀의 중요한 의사소통도구로 사용됨으로 최대한 쉬운 용어로 기술되고 기술된 내용은 서로 합의 되어야 한다.

아울러, SWEBOK(Software Engineering Body of Knowledge)에 따르면 요구사항은 프로세스를 통해 추출되고 분석되어 명세한 후 확인한다고 되어 있다. 기본적으로 요구사항에 대한 정의와 제품과 프로세스에 대한 정의 기능과 비기능의 구분, 창발성 속성(Emergent Properties), 정량화, 시스템 요구사항과 SW요구사항의 분리를 정의한 후 요구사항의 단계를 밟아 나간다.

프로세스단계에서는 모델과 역할을 분배하고 지원과 관리에 대한 부분 그리고 품질 및 향상에 관한부분을 정의한 후 추출과 분석, 명세, 확인 단계를 거치게 되며, 프로세스 반복에 대한 부분이나 변화관리, 속성, 추적, 측정과 관련된 부분은 전체적인 고려사항에 포함시켜 도출해야한다.

SW프로세스 인증제도(이하 SP인증)

우리나라는 SW프로세스의 중요성이 인지되고 확대됨에 따라 정보통신산업진흥원 SW공학센터를 중심으로 한국형 중소기업 대상의 SW프로세스 인증제도(이하 SP인증)를 추진하고 있다.

SP인증은 SW기업과 개발조직을 대상으로 SW개발 프로세스 품질역량 수준을 심사해 등급을 판정하는 제도로 2009년부터 추진되어 왔다. 한국형 SW프로세스품질인증모델은 미국 카네기멜론에서 개발한 CMMI의 25% 비용으로 인증을 받을 수 있지만 영세 SW기업을 대상으로 하기엔 비용부담이 컸던게 사실이다. 심사비용은 저렴하지만 인증 획득을 준비하는 필요한 컨설팅 등 추가적인 비용들이 발생하기 때문이다. 또한 인증 획득율도 69% 수준으로 중소SW기업이 SP인증을 획득하기란 쉽지 않은 일이었다.

< SP인증 획득 기업 수(2013년 9월말 기준) >

2013년부터 정부(정보통신산업진흥원 SW공학센터)에서 인증을 획득한 기업을 대상으로 심사비의 50%를 되돌려 주겠다고 하자 인증 신청기업이 늘어났다. 이는 그동안 심사비용 문제로 SW기업들이 고민을 했다는 방증이기도 하다.

올해부터 SP인증을 기업의 관점이 아닌 발주자의 관점에서 가점을 주기로 결정함에 따라 안전행정부가 기술평가항목에 SP인증 획득여부를 반영했고, 방위사업청이 무기체계 연구개발사업 제안서에 SP인증 기업을 우대한다는 내용을 명시했다.

한국형 SW프로세스품질인증모델은 2006년 개발되어 시범사업을 통해 검증하고 SW산업진흥법 개정을 통해 SW프로세스 품질인증제도로 발전하게 되었다. SW가 타산업과 융복합화되며 보다 복잡해지고 있어 SW품질이 각종 제품이나 서비스의 경쟁력을 좌우하는 핵심요소로 부각되었기 때문이다.

SP인증모델은 프로젝트와 조직의 관점으로 구성되어 국내 SW기업의 환경특성에 적합한 SW프로세스 역량수준의 심사체계를 마련하고 프로세스 기반의 SW프로젝트 완성도 제고에 중점을 두고 있다. SP인증은 SW프로젝트의 효율적인 개발, 관리 능력을 심사(2등급)하고 조직 프로세스 표준화 및 관리, 프로세스 개선능력을 심사(3등급)하는 구조로 구성되어 있다.

< SP인증 등급별 평가요소 >

1등급은 SW프로세스 개선이 필요한 단계, 2등급은 개별 프로젝트를 수행하기 위해 필요한 프로젝트 차원의 프로세스가 수립되고, 이를 기반으로 프로젝트를 통하여 성공적으로 프로젝트를 수행 할 수 있는 역량수준으로 정의되며, 3등급은 조직의 프로세스 체계를 정의하고 정량적인 데이터 관리를 통해 조직 차원의 프로세스를 개선하고 발생되는 문제의 근본원인을 해결함으로써 일관된 품질수준의 프로젝트 수행이 가능하며 지속적으로 프로세스를 개선 할 수 있는 역량수준으로 정의되고 있다.

< SP인증모델 프레임워크 >

< SP인증모델의 주요내용 >