SW설계

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

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

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

요구사항의 정의및 단계

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

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

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

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

요구사항 기법

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

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

요구사항 분석 및 관리

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

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

[SW프로세스 표준간 관계도]

[SW프로세스 표준간 관계도]

프로젝트 관점에서의 프로세스 컨설팅은 프로젝트를 진행할 때 필요한 방법론을 정의하고 그에 따른 WBS를 작성하고 관리하게 된다. 또한 방법론에서 정의한 각 단계(요구사항, 분석, 설계 구현, 시험, 배포)에 대한 가이드라인을 제공하고 작성된 산출물에 대해 리뷰와 인스펙션을 주관하며 개발자와 관리자간의 조화로운 커뮤니케이션을 할 수 있도록 지원하기도 한다. 프로젝트의 이해당사자들이 합리적으로 일할 수 있는 기반을 제공하는 것이 바로 프로젝트 관점에서의 프로세스 컨설팅이다.

CMMI(Capability Maturity Model Integration)란 미국방성의 요청에 의해 카네기멜론 대학의 SW공학연구소가 개발한 성숙도 평가모델을 기준으로 여러 CMM모델을 포함한 통합모델이다. 국제적 권위를 가진 인증을 통해 회사의 프로세스 및 제품에 대한 신뢰성을 보장하고 CMMI 심사를 통해 부족한 프로세스에 대해 외부검토를 수행하고 개선사항을 도출할 수 있는 모델이다.

SW프로세스 개선 모델

[SP인증 획득 기업 수(2014년 기준)]

2013년부터 정부(정보통신산업진흥원 소프트웨어공학센터)에서 인증을 획득한 기업을 대상으로 심사비의 50%를 되돌려 주겠다고 하자 인증 신청기업이 늘어났다. 이는 그동안 심사비용 문제로 SW기업들이 고민을 했다는 반증이기도 하다.2) 또한 전테 인증기업들의 규모별 분포를 살펴보면 64개 기업이 중소기업으로 분석되고 있다.

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

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

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

2)SP인증제도, 1년간 인증획득 10건에 불과.. 개선필요 지적, 전자신문, '13년 10월

[Agile 프로세스 특징과 설계원칙]

 Agile 프로세스는 변화하는 비즈니스 가치에 맞는 품질 좋은 SW를 계속해서 전달하는 것으로 1990년대 중반부터 폭포수 모델로 대표되는 전통적인 방식에 반대의 움직임을 보여 왔다. 급변하는 e비지니스 환경에서 SW개발 분야의 다양한 변화를 수용하고 대응할 수 있는 여러 방법론의 통칭이기도 하다.

[Agile 프로세스 특징과 설계원칙]

기존의 고전적 프로세스가 절차와 산출물을 중시하는데 반해 Agile은 협력과 수행 가능한 SW, 현장고객, 테스트 기법을 중시하고 있다.