SW공학의 변천사

1950년대는 SW공학에 대한 개념이 아직 정립되지 않은 시기로, 그 당시에는 SW개발을 위해 HW 공학적인 접근이 시도되었다. 1950년대 말에 추진되었던 대표적인 프로젝트인 SAGE (Semi-Automated Ground Environment) 프로젝트14)에는 레이더 공학자, 통신전문가, 컴퓨터 공학자, 초기 SW공학자 등이 대거 참여하였으며, 이들은 SW를 개발하는데 있어 기존의 HW공학 적인 개념을 적용한 SW공학을 적용하기 시작하였다. 

 

그림에서 보는 바와 같이 SAGE 프로젝트의 SW개발 프로세스는 연속적 폭포수 유형의 모델을 사 용하였으며, 프로젝트에 참여한 수천 명의 SW개발자들을 지원하기 위해 Lincoln Labs Utility System을 개발하여 라이브러리 및 빌드 관리와 테스트를 지원하기도 하였다.

SW공학 트렌드

이번 장은 Barry Boehm의 “A View of 20th and 21th Century Software Engineering”을 재 구성하여 SW공학의 도입 배경과 그 간의 시대적 요구에 따른 변화 과정, 그리고 앞으로 다가올 미래 전망에 대한 내용을 실었다. 어느 분야든 마찬가지겠지만 SW공학 분야에서도 가치 있는 과거 의 주요한 경험을 식별하여 향후 20~30년 내에 영향을 줄 수 있는 미래 변화에 발 빠르게 대응하 기 위해 변천사를 이해하는 것은 매우 중요하다. 

1950년대는 SW개발 프로젝트를 위해 HW공학과 유사한 SW공학 개념이 도입되기 시작하였지만 1960년대에 SW에 대한 수요가 급증하고 이를 구현하는 인력들의 경험과 능력, 수적인 부족이 원 인이 되어 ‘SW의 위기(SW Crisis)’가 발생하면서 본격적으로 SW공학이 도입되었다. 

이어 1970년대는 SW에 대한 수요가 급증하면서 SW개발인력이 부족하게 되었으며, 이를 해결하기 위해 SW전공자들이 아닌 비전공자들을 대거 투입하게 되고, 이러한 인력들은 SW개발 시 SW가 쉽게 수정될 수 있다는 점으로 인해 선코딩-후수정하는 접근방식을 택하게 되었다. 하지만 선코딩 -후수정에 대한 부작용으로 많은 결함들이 발견되면서 구조적 또는 정형적 기법들이 발생하였으 며, 분석, 설계, 구현 등을 순차적으로 진행하는 폭포수 모델을 개발하여 사용하기 시작하였다. 

하지만 정형적 기법은 일반 SW개발자들이 사용하기에는 사용성이 떨어지며, 폭포수 모델은 비용이 많이 소요되고, 진척도가 떨어진다는 점을 인식한 1980년대에는 재사용성을 높여 효율적으로 SW 를 개발하기 위해 SW개발 생산성을 높이기 위한 방법들을 연구하였다. 

1990년대는 시장에서 경쟁 우위를 점하기 위해 제품의 시장출시 시간을 단축해야 했다. 이로 인해 SW개발 생산성에 대한 연구가 활성화되었으며, 폭포수 모델에서 요구사항, 설계 및 구현 등을 동 시에 진행할 수 있는 동시공학(Concurrent Engineering)13)에 집중한 모델을 활용하였다. 

SW를 둘러싼 기술이나 시장 환경이 급속하게 변화하기 시작한 2000년대는 이러한 급속한 변화에 효과적으로 대응하기 위해 애자일 방법론이 본격적으로 도입되었다. 

더보기

SW개발자가 선택할 수 있는 미래의 직군

“개발자 미래에 대한 고민” SW개발이 좋아서 SW개발자가 된 사람들이 5~7년 개발을 하다 보면 미래에 대해서 생각하게 되고 불확실한 미래를 불안해한다. 대부분의 회사에서 개발자의 경력을 보 장해 주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다. 그러다 보니 전문 성 있고 가치가 높은 개발자의 경험과 지식은 묻혀버리고 회사는 기술력을 축적하지 못하게 된다. 

전사적 관점에서 프로젝트에서 개발자가 선택할 수 있는 미래 모습을 제시하는 것도 SW개발자들이 집중하여 역량을 발휘할 수 있는 계기가 된다. 하지만 현실은 그렇게 아름답지만은 않다. 

더보기

아키텍처 구조와 관점 중 뷰(View)

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

SW설계는 설계 프로세스로 생성되는 다양한 면(Multi-faceted)들을 가진 산출물(Artifact)이며, 각각 비교적 독립적이며 다른 측에서 바라보는(Orthogonal) 뷰로 이루어진다.

더보기

설계

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

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

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

더보기

요구사항분석및관리

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

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

 

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

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

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

더보기

SPICE모델 단계 및 프레임워크

SPICE는 SW프로세스 전반을 심사하여 조직의 SW개발 프로세스를 개선하고 개발자의 개발능력을 향상시킴으로서 개발위험을 통제하기 위한 목적으로 ISO에서 추진하는 SW품질 표준화심사평가 모 형으로 SW프로세스 전반을 심사하고 그 결과에 따른 조직의 프로세스를 개선해 나가는 활동에 대 한 표준화 방법이다. 

 

PRINCE2 모델은 영국정부(OGC; Office of Government Commerce)에 의해 개발되어 전 세계 적으로 사용되고 있는 관리방법론으로 주로 IT분야에서 많이 이용된다. PRINCE2는 다양한 산업계 와 기초 환경으로부터 가장 잘 입증된 경험들을 활용하며 문서들에는 항상 템플릿이 제공되고, 명확한 의사결정시기가 있는 것이 특징이다.
PRINCE2는 프로세스 기반의 접근방법을 이용하여 각 프로세스들이 프로젝트 수행동안에 수행되 어지는 관리활동을 정의하고 있다. 프로세스는 Starting up a Project(SU), Directing a Project(DP), Initiating a Project(IP), Managing Stage Boundaries(SB), Controlling a Stage(CS), Managing Product Delivery(MP), Closing a Project(CP), Planning(PL)로 구성 된다. 

더보기