#02장 소프트웨어 프로세스
최초 작성일 -
Ian Sommerville의 소프트웨어공학 책을 읽고 정리하였습니다.
1장 정리와 2장 도입부
1장 정리
프로세스가 영향을 받는 요인들.
개발되는 소프트웨어의 유형
고객의 요구사항
개발자들의 능력
기본이 되는 SW 엔지니어링 활동(1장)
명세 / 개발 / 평가 / 진화
위 4 큰틀 안에, requirements validation, architectural design, and unit testing 서브 액티비티들도 들어있다.
도입부
큰시스템 plan-driven과 agile processes 균형 필요
UML modeling과 test-driven개발 도입하면 회사 프로세스가 개선
이번장에서 간단히 소프트웨어 프로세스에 대해 보고 26장에서 자세히보자.
2.1 소프트웨어 프로세스 모델
software process model = SDLC model
general process models = process paradigms
폭포수 모, 점진적개발, 통합과 설정
항상저자가 말하기를, 모든 소프트웨어 개발에 쓰이는 유니버셜한 프로세스 모델은 없다! 시도는 있었는데, 가장 유명한 것이 general models를 기반으로 하여 개발한 RUP(Rational Unified Process, 2003)가 있다. 이 모델은 IBM 채택하였었지만, 현실에서는 많이 안쓰이고 있다.
safety-critical 소프트웨어 폭포수 모형으로 주로 개발 -
구현하기 전 많은 분석과 서류화 작업이 필요
실제 큰시스템들의 소프트웨어 프로세스들은 general model을 기반이 되고 종종 다른 모델들의 특징을 가져와 포함.
어떤 SW를 개발할지 이해가 명확히 경우 폭포수-기반의 프로세스를 사용해 개발하고, 설정으로 위해 기존 사용 시스템을 살 수 있다. 하지만 명확하지 않다면, 점진적 기법을 사용한다.
2.1.1 폭포수 모형
기본적인 프로세스 액티비티인 명세, 개발, 검증 및 진화를 내재해 요구사항분석, 디자인, 구현, 테스팅으로분리된 단계
1970년 군대 시스템 개발 엔지니어링 모델로 처음 사용
plan-driven 유형 중 하나
소프트웨어 개발 전 모든 활동 계획
요구사항 정의 - 서비스들, 제약조건, 목표를 시스템 유저들과 이야기를 나눠 요구사항을 정립한다.
시스템과 소프트웨어 디자인 - 하드웨어와 소프트웨어 모든 시스템 구조를 설계. 근본적인 소프트웨어 시스템 추상화와 그들의 관계를 명시해야 한다.
구현과 유닛 테스팅 - 디자인이 프로그램들의 집합이나 유닛들로 인지되어야 하고, 유닛테스팅은 각 유닛이 정해진 명세에 맞춰 개발됐는가 확인한다.
통합과 시스템 테스팅 - 요구사항이 모두 충족이 되는지 전체 시스템관점에서 테스트가 진행되어야 한다.
운영과 유지보수 - 가장 긴 생명주기 단계로, 조기에 발견되지 않은 에러나 omission들을 고치고 시스템유닛들에 대한 구현을 개선하며 새로운 요구가 생길시 서비스를 증가시킨다.
어떤경우에 폭포수모형을 사용할까?
소프트웨어와 하드웨어 사이의 인터페이스인 임베디드 시스템 개발할 때
안전 및 보안 분석이 필요한 중요한 시스템
하청업자들의 부분 개발들로 만들어지는 대형시스템
어떤경우에 폭포수모형을 사용하지 말아야 할까?
정형적(formal)인 팀 대화가 필요한 곳
요구사항이 계속변하는 곳
이런경우, iterative 개발이나 애자일 방법들이 현명
정형의 장단점
장
안전하고 신뢰성과 보안성이 뛰어남을 가졌다
단
고비용, critical systems에만 쓰인다.
2.1.2 점진적 개발
재사용 가능한 컴포넌트나 시스템의 이용가능성에 많이 의존하는 기법. 명세, 개발, 평가가 interleaved되어있다.
특징
오는날? 응용시스템과 소프트웨어 제품 개발하는데 가장 흔한 접근법이다.
계획주도(plan-driven)와 애자일 또는 두개를 섞어 진행한다.
애자일의 근본적인 부분을 담고 있다.
개발 도중 요구사항에 맞춰 변경하기가 싸고 쉽다.
폭포모형과 비교해본 점진법의 이점
비용이 저렴하.
폭포수는 서류화하고 분석하는데 다시하는 비용이 다.
개발할때 고객들의 피드백을 받기 쉽다.
이른 인도와 배포(delivery and deployment)가 가능하다.
관리 관점에서 본 두가지 문제
진행사항이 비가시적이다.
새로운 추가(increment)가 나올때마다 시스템 구조가 퇴화되어 간다. structural degradation과 code messiness를 해결하기 위해, 주기적인 리팩토링으로 해결해 나가야 한다.
2.1.3 통합과 구성
재사용 가능한 소프트웨어 컴포넌트들과 이 컴포넌트들로 만들어진 프레임워크를 사용한다.
현재 기능을 구현한 기존 코드를 찾고, 필요하다면 수정하는 방법.
2000년 이후 자주 사용되고 있다.
개발 속도가 빠르지만 기존에 있던것을 사용할라는 성격때문에 사용자들의 니즈를 만족시키기 어렵다.
Configuration Management = 형상관
아래는 통합과 구성을 기반으로 한 재사용지향 소프트웨어 엔지니어링.
재사용 지향 엔지니어링
요구사항 명세 - 초기 요구사항이 제안
SW 발견과 진화 - 샘플 컴포넌트들과 시스템들의 후보들이 평가된다.
요구사항 정제 - 발견된(기존에 존재하는) 재사용가능한 컴포넌트들과 애플리케이션들로 시스템 명세와 컴포넌트들을 재정의한다.
응용시스템 구성 - 기존 응용시스템이 요구을 만족한다면 그것으로 새로운 시스템을 구성한다.
컴포넌트 채택과 통합 - 재사용가능한 기존 시스템이나 개별 컴포넌트들이 없으면 거기서 수정하던가 새로운 컴포넌트를 개발한다.
자주 재사용 되는 컴포넌트 특징들
특정환경에 맞춰 설계된 Stand-alone 응용 시스템
컴포넌트로써 or 스프링프레임워크와 같은 컴포넌트 프레임워크와 함께 통합된 패키지들로 개발된, 객체들의 컬렉션들
서비스 표준에 맞게 개발되었고 원격 호출(invocation)이 가능한 웹서비스
2.2 프로세스 액티비티들
requirements engineering -> software development -> testing -> evolution
2.2.1 명세
2.2.2 디자인과 구현
아키텍처 디자인
데이터베이스 디자인
인터페이스 디자인
컴포넌트 디자인
2.2.3 평가
컴포넌트 테스팅
시스템 테스팅
고개 테스팅
2.2.4 진화
소프트웨어 유연성 갖기. 소프트웨어의 유여성은 하드웨어와는 다르다.
2.3 변화에 대응하기
리팩토링도 change tolerance를 익히 방법 중 하나.
2.3.1 시스템 프로토타입핑
요구사항 설계 프로세스 단계에서, 시스템 요구사항의 도출과 평가에 도움이 된다.
시스템 디자인 프로세스에서, 소프트웨어 솔루션들을 탐색하거나 유저 인터페이스 개발에 사용될 수 있다.
2.3.2 점진적 인도(Delivery)
프로토타이핑과 다르게 실제 시스템으로 완벽한 시스템이 이용가능해질때 다시배울 필요가 없고, 고객들이 전체 시스템이 인도될때 까지 기다릴 필요가 없으며(첫번째 increment만으로 보통 고객의 가장 우선순위를 만족시킴), 가장 우선순위가 되는것이 먼저 incremented 됬음으로 중요한 부분이 여러 단계에 걸쳐 계속 테스트 될 수 있다.
2.4 프로세스 개선
두가지 접근법
성숙도에 따른 접근
개선된 제품과 진행 예측가능성을 주요 목표. 프로세스, 프로젝트 관리, 그리고 좋은 소프트웨어 엔지리어링 관습의 개선을 중점으로 둔다.
애자일 접근
iterative 개발과 소프트웨어 프로세스에서 오버헤드 감소를 중점으로 둔다. 기능들의 빠른 인도, 고객요구사항에 대응적(responsiveness)
2.5 정리
SW 프로세스 모델
SW 시스템 개발 관련된 활동를 추상적으로 표현한 것
일반 프로세 모델 (General process)
폭포수 모형, 점진적 개발 그리고 재사용 가능한 컴포넌트 설정과 통합을 포함
요구사항 개발 (Requirements engineering)
고객이 원하는 소프트웨어 사양에 대해 수
디자인과 구현 (Design and implementation)
요구 사항 사양을 executable한 시스템으로 변환
소프트웨어 유효성 검사 (Validation)
시스템이 사양을 준수(conform)하고 시스템 사용자의 실제 요구를 충족하는지 확인
소프트웨어 진화 (Evolution)
기존 소프트웨어 시스템을 변경하면서 유용한 소프트웨어로 발전
프로세스들은 변화에 대응해야 한다. 요구사항과 디자인에서 잘못된 결정으로 생기는 문제를 미연에 방지하기 위해 a prototyping phase를 사용할 수 있고, iterative한 개발과 인(delivery) 를 사용하여 각 변화가 전체 시스템에 지장을 주지 않아야 한다.
프로세스 개선 (improvement)
기존 SW를 개선하면 소프트웨어 질, 개발비용 감소, 개발시간 단축 효과 만들어 낸다. 개선 순환적인 프로세스로 현 프로세스에 대한 측정, 분석 그리고 변화가 필요하다.
2.6 문제풀이
# 1
다음 시스템들에 사용되어야 할 프로세스들은 무엇일까?
자동차의 antilock braking을 조하기 위해 필요한 시스템
소프트웨어 유지보수를 지원하기 위한 가상현실 시스템
대학의 기존 회계 시스템을 대체하기 위한 시스템
사용자들의 여행이 환경적으로 영향을 적게 미치, 인터랙티브한 여행 계획 시스템
# 2
점진적 소프트웨어 개발은 고객의 요구사항이 명확하지 않을때 유용하게 사용될 수 있는 프로세스이다. 이에 논의해보자.
# 3
위 통합과 설정 프로세스 모델에 대해 생각해보고, 왜 요구사항 엔지니어링이 꼭 필요한 지에 대해 설명해보자.
# 4
requirements engineering process에서 왜 고객의 요구사항과 개발 시스템 요구사항 사이에 차이를 만드는 것이 중요한지에 대해 제안해보자.
# 5
아키텍처 디자인 활동 DB 디자인, 인터페이스 디자인, 컴포넌트 디자인이 interdependent한 이유를 사례를 들어 설명해보자.
# 6
왜 SW 테스팅시 incremental, staged한 활동이 되어야 하는지를 설명해보자. 그리고 프로그램을 테스팅하는데 있어서 항상 그 프로그램을 개발한 프로그래머들이 가장 적격인 사람들인지에 대해 생각해보자.
# 7
우리나라 정부에서 방대한 자원의 이용상황을 추적하는 소프트웨어를 만든다고 가정해보자. 정부가 내어놓은 요구사항이 명확하지 않은 상태로 개발회사에 개발 프로토타입만 주었다. 그리고 개발회사는 이 프로토타입이 충분해보여 프로토타입에서 확장하며 실제시스템으로 개발하기로 했다. 이에 대한 찬반에 대해 토의해보자.
# 8
소프트웨어 시스템의 프로토타입을 개발했으며 관리자가 이 프로토타입 깊은 인상을 받았다. 이 프로토타입에, 필요에 따라 새로운 기능을 추가하여 프로덕션 시스템으로 사용하도록 제안했다. 이로써 시스템 개발 비용을 줄이고 새로운 기능으로 시스템도 유용하게 만든다고 생각했다. 하지만, 프로토 타입 시스템이 일반적으로 프로덕션 시스템으로 사용되지 않는다. 따라서 관리자에게 이에 대한 보고서를 작성해보자.
# 9
SEI’s Capability Maturity framework에 embodied된 프로세스 측정과 개선의 장단점 2가지씩 적어보자.
# 10
역사적으로 기술의 도입은 노동 시장에 중대한 변화를 일으켰고 적어도 일시적으로 사람들을 직장에서 쫓아 냈습니다. 광범위한 프로세스 자동화 도입이 소프트웨어 엔지니어에게 동일한 결과를 가져올 가능성이 있는지 논의해보. 만약 직업 기회를 줄일 것이라고 생각한다면, 영향을받는 엔지니어들이 자동화 도입에 수동적이거나 능동적으로 저항하는 것이 윤리적인지에 대해서도 생각해보자.
2.7 정답
# 1
# 2
# 3
# 4
# 5
# 6
# 7
# 8
# 9
# 10
Last updated