소프트웨어 프로세스
소프트웨어 공학 활동
- 소프트웨어 명세화
- 기능과 운영상의 제약조건 정의
- 기능과 운영상의 제약조건 정의
- 소프트웨어 개발
- 명세를 만족하는 소프트웨어 개발
- 명세를 만족하는 소프트웨어 개발
- 소프트웨어 검증
- 고객의 요구와 일치하는지 검증
- 고객의 요구와 일치하는지 검증
- 소프트웨어 진화
- 변화하는 고객의 요구 충족시키기 위해 진화
프로세스 설명 시 중요한 항목
- 프로세스 활동의 결과물
- 제품과 산출물(아키텍처 설계 활동의 결과물 : 소프트웨어 아키텍처 모델)
- 제품과 산출물(아키텍처 설계 활동의 결과물 : 소프트웨어 아키텍처 모델)
- 역할
- 프로세스 참여하는 사람들의 역할(프로젝트 관리자, 형상 관리자, 프로그래머 등)
- 프로세스 참여하는 사람들의 역할(프로젝트 관리자, 형상 관리자, 프로그래머 등)
- 사전/사후 조건
- 프로세스 활동 또는 제품 제작 완료 전과 후에 만족해야 하는 조건
- 아키텍처 프로세스 예시
- 사전조건(설계 전) : 사용자가 모든 요구사항을 승인해야 함
- 사후조건(설계 후) : 아키텍처를 나타내는 UML모델에 대한 리뷰를 완료해야 함
프로세스 활동
— 특정 목표를 기술적이고 관리적인 측면을 가진 공동의 활동이 중첩되어 진행
— 목표 : 소프트웨어 시스템을 명세, 설계, 구현, 테스팅하는 것
— 기본 프로세스 활동은 개발 프로세스 종류에 따라 다른 방식으로 구성
→ 활동 수행 방법은 소프트웨어의 유형, 개발자의 경험, 역량, 조직의 유형에 따라 달라짐
소프트웨어 명세화( = 요구공학)
- 어떤 서비스가 필요한지를 이해 및 정의, 시스템 운영과 개발에 대한 제약사항을 찾아냄
- 소프트웨어 프로세스에서 특히 중요한 단계 ← 실수하면 설계와 구현에서의 문제로 이어짐
- 이해당사자들의 요구사항을 만족시키는 시스템을 명세하기 위한 요구사항 문서를 통해
합의점을 도출하는 것이 목적- 요구사항 : 대부분 두 단계의 상세화 수준으로 표현(고수준의 문장 vs상세한 시스템 명세)
소프트웨어 명세화 프로세스
세 가지 주요 활동
도출 및 분석: 이해당사자들과 상호작용을 통해 요구사항을 발견하는 것명세화: 요구사항을 표현 형태로 바꾸는 것검증: 요구사항이 실제로 고객이 원하는 시스템을 정의하고 있는지 점검하는 것- 분석, 정의 및 명세화 활동은 서로 중첩
← 계속되는 요구사항 분석을 통해 새로운 요구사항을 발견할 수 있음 - 애자일 방법에서 요구사항 명세화는 시스템 개발의 일부로 간주
- 평상시 각각의 시스템 증가분 개발 직전에 증가분의 요구사항을 명세
- 사용자의 우선순위를 고려하여 이뤄짐
- 평상시 각각의 시스템 증가분 개발 직전에 증가분의 요구사항을 명세
소프트웨어 설계 및 구현
- 고객에게 전달하는 실행 가능한 시스템을 개발하는 프로세스
- 소프트웨어 설계와 프로그래밍이라는 개별 활동으로 나누기도 함
- 애자일 개발 접근법의 경우 설계와 구현 활동이 중첩
- 소프트웨어 설계
- 구현해야 하는 소프트웨어 구조, 시스템이 사용하는 데이터 모델과 구조,
시스템 컴포넌트들 사이의 인터페이스와 알고리즘을 기술한 것
- 여러 단계를 걸쳐 반복해서 작성
- 상세한 내용 추가되고 이전 설계 수정하는 작업을 끊임없이 반복
- 구현해야 하는 소프트웨어 구조, 시스템이 사용하는 데이터 모델과 구조,
소프트웨어 개발 도구
- 소프트웨어 공학 프로세스 활동을 지원하는 프로그램
- 특정 프로세스 활동 자동화, 개발하는 소프트웨어 정보 제공하는 방식으로 프로세스 지원
- 그래픽 시스템 모델의 개발 : 요구사항 명세화나 소프트웨어 설계의 일부
- 코드 생성 : 그래픽 시스템 모델을 활용
- 사용자 인터페이스 생성 : 사용자가 상호 작용을 통해 만드는 그래픽 인터페이스 명세 활용
- 프로그램 디버깅 : 실행 프로그램에 대한 정보 제공
- 자동 번역 : 구식보단 최신 버전의 언어로 해라
- 특정 프로세스 활동 자동화, 개발하는 소프트웨어 정보 제공하는 방식으로 프로세스 지원
- IDE는 해당 도구들을 통합된 방식으로 커뮤니케이션하고 쉽게 사용하도록 여러 가지 공통 기능 제공
소프트웨어 설계 프로세스의 일반적 모델
- 설계 프로세스 활동은 서로 중첩되면서 상호 의존적
- 설계에 대한 새로운 정보는 이전 설계에 영향을 줌 → 어쩔 수 없이 재설계 작업
- 설계에 대한 새로운 정보는 이전 설계에 영향을 줌 → 어쩔 수 없이 재설계 작업
- 소프트웨어 플랫폼 환경 정보는 설계 프로세스 과정에 필수적
소프트웨어 플랫폼: 소프트웨어가 실제로 실행되는 환경- 운영체제, 데이터베이스, 미들웨어와 다른 애플리케이션 시스템들로 구성
- 소프트웨어는 위에 언급된 다른 소프트웨어 시스템들과 인터페이스로 연결
- 설계자는 플랫폼 환경 정보를 가지고 시스템 통합을 위한 최선의 의사 결정을 해야 함
정보 시스템을 설계하기 위한 네 가지 활동
— 개발하는 시스템의 유형에 따라 다양함 → 생략되는 설계 단계도 있음
아키텍처 설계- 시스템의 전체적 구조, 주요 컴포넌트와 그 관계를 찾음
- 구성요소들이 어떤 방식으로 분산될지 알아냄
데이터베이스 설계- 시스템 데이터 구조 설계 및 데이터베이스에서의 표현 방식 결정
- 데이터베이스 재사용 여부에 따라 달라짐
인터페이스 설계- 시스템 컴포넌트들 사이의 인터페이스 정의
- 인터페이스 명세서는 명확해야 함
- 정확하면 특정 컴포넌트의 구현 내용을 알 필요 없이 사용 가능
- 정확하면 특정 컴포넌트의 구현 내용을 알 필요 없이 사용 가능
- 인터페이스 명세서는 명확해야 함
- 인터페이스 명세가 확정된 컴포넌트는 개별적으로 설계 및 개발이 가능
- 시스템 컴포넌트들 사이의 인터페이스 정의
컴포넌트 선택 및 설계- 재사용할 컴포넌트를 찾고, 없으면 새로운 소프트웨어 컴포넌트를 설계
- 단순히 컴포넌트에 대한 설명만 작성하고, 구현은 프로그래머한테 맡김
- 재사용 컴포넌트나 UML로 표현한 상세 설계 모델에 대한 변경 목록을 작성하기도 함
- 재사용할 컴포넌트를 찾고, 없으면 새로운 소프트웨어 컴포넌트를 설계
설계 프로세스 산출물
- 상세 설계 문서
- 설계 프로세스 산출물
- 시스템을 명확하고 정확히 기술
- 산출물 예시
- 모델 주도 접근법 경우 : 설계 다이어그램
- 애자일 방법 경우 : 개별적인 명세 문서가 아닌 프로그램 코드가 될 수 있음
시스템 구현
- 시스템 설계를 기반으로 수행
- But, 설계와 프로그램 개발이 중첩되는 경우가 더 많음
- But, 설계와 프로그램 개발이 중첩되는 경우가 더 많음
- 준수해야 할 일반적인 프로세스가 없음
- But, 테스팅은 어떠한 형태로든 수행함
- But, 테스팅은 어떠한 형태로든 수행함
- 테스팅과 디버깅의 차이
- 테스팅 : 결함의 존재 확인 작업
- 디버깅 : 프로그램의 결함을 찾아서 고치는 작업
→ 디버깅 시 프로그램 동작에 대한 가설을 세우고 결함을 찾기 위해 테스트를 수행
소프트웨어 검증(Verification and Validation)
- 시스템이 주어진 명세를 잘 따르고, 고객이 원하는 대로 잘 만들고 있다는 걸 검증하는 것
프로그램 테스팅: 실제처럼 제작한 테스트 데이터를 사용하여 시스템 실행 ← 주요 기법
- 검증 : 각각의 프로세스 단계에서 이루어지는 확인 프로세스와 관련
- 요구사항 정의 단계부터 프로그램 개발에 이르는 전 범위
- 요구사항 정의 단계부터 프로그램 개발에 이르는 전 범위
- 프로그램 테스팅이 검증 및 확인 작업의 대부분을 차지
테스팅의 단계
컴포넌트 테스팅: 각각의 컴포넌트들을 개별적으로 테스트- 컴포넌트는 함수나 객체 클래스, 서로 관련된 구성 요소들의 그룹일 수도 있음
- 컴포넌트는 함수나 객체 클래스, 서로 관련된 구성 요소들의 그룹일 수도 있음
시스템 테스팅: 전체 시스템의 테스팅 수행- 컴포넌트 간의 의도치 않은 상호작용이나 인터페이스 문제 등 오류 확인
- 컴포넌트 간의 의도치 않은 상호작용이나 인터페이스 문제 등 오류 확인
고객 테스팅: 시스템 고객이 직접 시스템을 테스트- 시스템 요구사항 정의에서의 오류를 찾거나 빠뜨린 부분을 알 수 있음
- <참고> 계획 주도 소프트웨어 프로세스에서 테스팅 단계계획
주도 소프트웨어 프로세스에서의 테스팅 단계
소프트웨어 진화
- 소프트웨어는 언제든지 상대적으로 저렴하게 변경 가능
- 시스템 하드웨어 변경하는 경우 대비 훨씬 저렴하게 변경 가능
- 시스템 하드웨어 변경하는 경우 대비 훨씬 저렴하게 변경 가능
- 개발과 유지보수는 연속적인 활동으로 보는 것이 더 맞음
- 기존에는 개발 = 창의적 활동, 유지보수 = 지루한 활동
- 요구사항과 고객의 요구가 바뀌면서, 이를 지속적으로 반영 → 소프트웨어가 변화
변경 처리
- 모든 대규모 소프트웨어 프로젝트에서 변경은 피할 수 없다
- 요구사항의 변경 : 외압이나 경쟁의 의한 사업적 대응과 경영 우선순위의 변화
- 새로운 기술 도입 : 설계나 구현에 대한 새로운 접근 가능
- 플랫폼의 변경
- 변경 작업은 소프트웨어 개발 비용을 증가
- 완료된 작업을 재수 행해야 하는 경우가 많음
- 새로운 요구사항을 도출하는 경우
(전체 요구사항 분석의 반복, 시스템 재설계, 개발한 프로그램 수정 후 다시 테스트)
- 새로운 요구사항을 도출하는 경우
- 완료된 작업을 재수 행해야 하는 경우가 많음
재작업 비용을 줄이는 접근법
- 변경 예측(Change anticipation)
- 가능한 변경을 미리 예측하는 활동을 수반하는 소프트웨어 프로세스
- 예) 프로토 타입 시스템 개발(시스템의 주요 특성을 고객에게 미리 보여줌)
- 변경 허용(Change tolerance)
- 시스템에 쉽게 변경을 가할 수 있도록 프로세스와 소프트웨어를 설계
- 예) 점증적 개발
- 제안한 변경을 아직 개발하지 않은 증가분에 포함시켜 구현
- 불가능하면 제안한 변경의 포함을 위해 단일 증가분을 수정
시스템 요구사항을 바꾸기 위한 방법
- 시스템 프로토타이핑
- 시스템의 한 버전이나 부분을 빠르게 개발
→ 고객의 요구사항 및 결정한 설계의 타당성 확인 - 변경 예측의 한 기법 ← 사용자가 시스템을 사용해서 미리 요구사항 개선 가능
- 인도 이후에 발생하는 요구사항 변경 요청의 수가 감소하는 경향
- 시스템의 한 버전이나 부분을 빠르게 개발
- 점증적 인도
- 의견을 받거나 사용할 수 있도록 시스템 증가분을 고객에게 전달
- 변경 회피와 허용을 모두 제공
- 전체 시스템에 대한 요구사항의 성급한 적용 방지 가능
- 비교적 낮은 비용으로 후반 증가분에도 변경 포함 가능
프로토타이핑
- 프로토타입
- 아이디어를 시연하고 디자인 선택사항들을 시도해 보는 소프트웨어 시스템의 초기버전
- 소프트웨어 개발 프로세스는 다음과 같이 사용 가능
- 요구공학 프로세스 : 요구사항 도출과 검증에 도움
- 시스템 설계 프로세스 : 소프트웨어 해결 방안 탐색, 사용자 인터페이스 개발에 활용
프로토타이핑의 이점 및 모델
- 시스템 사용성 향상
- 사용자의 실제 요구 사항에 더 맞출 수 있음
- 디자인 품질 향상
- 유지 보수성 향상
- 개발에 드는 노력 감소
점증적 인도
- 소프트웨어 시스템을 여러 개의 증가분으로 나누어 순차적으로 전달
- 서비스 우선순위에 따라 증가분에 할당할 서비스 결정
- 가장 높은 우선순위 - 제일 먼저 구현
- 가장 높은 우선순위 - 제일 먼저 구현
- 증가분 개발이 시작되면 해당 증가분의 요구사항 변경 불가
- 추가적인 요구사항은 적용 가능
점증적 인도의 장점
- 시스템 증가분에 대한 요구사항에 대한 힌트를 얻기 쉬움
- 초기 증가분을 프로토타입과 같이 사용 가능
- 초기 증가분을 프로토타입과 같이 사용 가능
- 고객이 전체 시스템이 전달될 때까지 기다릴 필요 없음
- 첫 증가분은 고객이 가장 중요하게 생각하는 요구 충족
- 첫 증가분은 고객이 가장 중요하게 생각하는 요구 충족
- 시스템에 반영할 변경 사항을 비교적 쉽게 통합
- 점증적 개발의 이점 활용
- 점증적 개발의 이점 활용
- 가장 중요한 시스템 서비스를 가장 많이 테스트 ← 가장 높은 우선순위 서비스를 먼저 전달
점증적 인도의 단점
- 기존 시스템을 신규 시스템으로 대체하려는 경우 문제 발생
- 기존 시스템의 모든 기능이 필요
- 대부분의 경우 불완전한 새로운 시스템을 사용하지 않으려는 경향
- 여러 기본 기능을 필요로 하는 시스템(대부분의 시스템)의 경우엔 적합하지 않음
- 주어진 증가분을 구현할 때까지 요구사항을 상세하게 정의하지 않음
→ 모든 증가분이 필요로 하는 공통 기능(기본 기능)을 찾기 어려움
- 주어진 증가분을 구현할 때까지 요구사항을 상세하게 정의하지 않음
- 여러 기관의 조달 방식과 맞지 않는 방식
- 조달 과정에는 시스템 개발 계약에 완전한 시스템 명세를 포함해야 함
→ 점증적 인도는 반복 프로세스를 사용하기 때문에 큰 조직에는 부적합
→ 새로운 형태의 계약이 필요
- 조달 과정에는 시스템 개발 계약에 완전한 시스템 명세를 포함해야 함
프로세스 개선
- 기존 프로세스를 바꾸어서 제품 품질을 향상하거나 비용과 개발 시간을 단축하는 활동
- 프로세서 개선과 변경 방법
프로세스 성숙도 접근법- 프로세스와 프로젝트 관리 기법 개선과 바람직한 소프트웨어 공학 실무를 조직에 소개하는 것이 중점
- 목표 : 제품 품질과 프로세스 예측 가능성 향상
애자일 접근법- 반복적 개발과 오버헤드의 감소에 중점
- 목표 : 가장 적은 오버헤드를 가지고 고객의 요구 사항 변경에 대응
일반적인 프로세스 개선 작업(프로세스 성숙도 접근법)
프로세스 측정- 프로세스나 제품의 한 가지 이상의 속성을 측정
- 측정한 기준 값이 프로세스 개선 효과의 평가 기준
프로세스 분석- 프로세스의 약점과 방해물을 찾음
- 프로세스를 설명하는 프로세스 모델 개발
프로세스 변경- 찾아낸 약점을 다루기 위한 프로세스 변경을 제안
- 변경 후, 변경 효과성에 대한 데이터를 수집 재시작
프로세스 평가 기준
- 프로세스 활동을 완료하는데 소요되는 시간
- 활동 또는 프로세스를 완료하기 위해 필요한 시간 또는 노력
- 활동 또는 프로세스를 완료하기 위해 필요한 시간 또는 노력
- 프로세스 혹은 활동에 필요한 자원
- 인원-일(person-days)로 표현한 총 노력
- 인원-일(person-days)로 표현한 총 노력
- 특정 이벤트의 발생 횟수
- 발견된 함수의 결함
- 발견된 함수의 결함
프로세스 역량 성숙도 모델 수준
초기(Initial): 관리되지 않음관리(Managed): 제품 관리 절차가 정의되고 사용됨정의(Defined): 프로세스 관리 절차와 전략이 정의되고 사용됨정량적 관리(Quantiatively managed): 품질 관리 전략이 정의되고 사용됨최적화(Optimizing): 프로세스 개선 전략이 정의되고 실제로 사용됨