- 개발 비용은 소프트웨어 프로세스에서 적은 비중을 차지
- 유지 보수 비용이 개발 비용보다 크다.
- 요구사항은 지속적으로 바뀐다.
소프트웨어 제품의 유형
- 일반 소프트웨어 → 어떤 고객이던 구매 가능, 현재는 맞춤식 SW도 반영
- 맞춤식 소프트웨어 → 특정 고객에게 맞춤, 고객이 SW 명세를 개발하고 통제
좋은 소프트웨어의 특성
- 수용성 : 설계 목적에 부합하는 사용자를 수용할 수 있어야 한다.
- 확실성 : 시스템에 장애가 발생하더라도 경제적 피해를 야기하면 안된다.
- 보안성 : 악의적인 사용자가 시스템에 피해를 입힐 수 없어야한다.
- 효율성 : 시스템 자원을 낭비하면 안된다.
- 유지보수성 : 고객의 요구를 충족시킬 수 있도록 진화할 수 있어야한다.
공통의 기본 소프트웨어 프로세스 활동
1. 소프트웨어 명세(Specification) : 기능, 제약사항 정의
2. 소프트웨어 개발(Development) : 명세를 충족하는 설계 및 구현
3. 소프트웨어 검증(Validation) : 고객의 요구에 일치하는지 검증
4. 소프트웨어 진화(Evolution) : 고객 요구의 변화에 따라 수정
소프트웨어 프로세스 모델 → 프로세스를 추상적으로 표현
- 폭포수 모델 (The waterfall model)
- 계획주도 모델 (plan-driven model) → 개발 시작 전 모든 활동 및 일정을 계획
- 각 단계 별 결과로 하나 이상의 문서가 산출
- 각 단계 결과물을 점검하여 다음 단계 이전에 피드백
- 요구사항이 명확한 설계일 때 관리가 쉽다.
- 프로세스가 엄격하여 변화 대응이 어렵다.
- 단계
- 요구사항 분석 및 정의 : 서비스, 제약조건, 목표를 설정하고 구체화하여 명세서로 사용
- 시스템/소프트웨어 설계 : 요구사항을 통해 전체 시스템 아키텍처와 관계를 파악
- 구현 및 단위 테스트 : 여러 기능과 각 기능 별 단위 테스트 진행
- 통합 및 시스템 테스트 : 프로그램을 통합하고 요구사항에 만족하는지 전체 시스템 검사
- 운영 및 유지보수 : 오류 수정 및 개선, 새로운 요구사항 발견
- V-model
- 폭포수 모델에서 파생
- 각 단계 별 테스트 강화, 변화 대응 불가
- 점증적 개발 (Incremental development)
- 여러 버전을 거쳐 소프트웨어를 진화시킴
- 변화 대응 비용과 폭포수 대비 재작업 비중이 낮아진다.
- 고객의 피드백 반영이 보다 쉽고 빠른 소프트웨어 개발 및 배포가 가능하다.
- 결과물 판단이 어려워 일정 관리에 문제가 있다. → 정기적 산출물 필요
- 증가분이 반영되면 시스템 구조의 품질이 낮아진다. → 정기적 리팩토링이 필요
- 단계
- 개요 설명 : 시스템 요구사항을 대략적으로 정의
- 주기적 반복
- 명세화
- 개발
- 검증
- 통합 및 환경 설정 (Integration and configuration)
- 기존의 코드를 찾아 수정하고 새로운 코드와 통합한다. (재사용)
- 소프트웨어 개발 비용 및 위험 감소
- 빠른 개발 및 배포(전달) 가능
- 요구사항을 명확하게 만족하지 못하고 실 수요를 위해 계속 변경해야할 수 있다.
- 시스템 진화의 주도권 상실
- 사용할 수 있는 컴포넌트
- 통합 가능한 컴포넌트나 패키지
- 스탠드얼론 시스템
- 표준 웹 서비스
- 단계
- 요구사항 명세화 : 시스템에 대한 초기 요구사항 제안, 간략한 설명
- 소프트웨어 발견 및 평가 : 필요한 기능을 가지는 후보군 평가
- 요구사항 정제 : 발견한 컴포넌트를 통해 요구사항을 수정 및 재정의, 필요한 경우 컴포넌트 재탐색
- 어플리케이션 시스템 설정 : 요구사항을 만족하는 독립 시스템이 있다면 설정하여 사용
- 컴포넌트 수정과 통합 : 없다면 재사용 가능한 컴포넌트를 수정하여 통합
프로세스 액티비티
- 소프트웨어 명세
- 서비스가 요구하는 바가 무엇인지 확립
1. 요구사항 도출과 분석 : 이해관계자의 요구 파악
2. 요구사항 명세화 : 분석 결과로 상세한 문서 작성
3. 요구사항 검증 : 현실성 및 일관성 검사
- 소프트웨어 설계 및 구현
- 구현할 구조, 사용할 데이터 모델, 컴포넌트 간 인터페이스 및 알고리즘
- 아키텍처 설계 : 전체 구조, 주요 컴포넌트 및 그 관계
- 데이터베이스 설계 : 시스템 데이터 구조 설계
- 인터페이스 설계 : 컴포넌트 간 인터페이스 정의
- 컴포넌트 선택 및 설계 : 재사용 컴포넌트 발견 및 새로운 컴포넌트 설계
- 소프트웨어 검증
- 소프트웨어 명세와 고객 요구사항 반영을 검증
- V & V (verification & validation) 과정은 대부분 테스팅
- 컴포넌트 테스트 : 개별 컴포넌트 테스트
- 시스템 테스트 : 전체 및 상호작용 테스트
- 고객 테스트 : 고객 요구사항 확인 및 오류 탐색
- 소프트웨어 진화
- 개발과 유지보수의 구분이 모호 → 연속적 활동
- 기존 시스템 평가 → 변경 제안 및 수정 → 기존 시스템으로 통합
변화 대응 (Copying with change)
- 큰 SW일 수록 보수가 필요하다.
- 비즈니스 환경 변화가 시스템 요구사항에 영향을 미친다.
- 재작업에 대한 비용 감소 방안
- 변경 예측 : 프로토타입을 통해 미리 요구사항 변화를 예측하고 개선
- 프로토타입 (Prototype)
- 고객은 개발 결과를 모름
- 시스템의 일부나 한 버전을 빠르게 개발하여 사용자에게 인도
- 요구 공학에서 요구사항 도출 및 검증에 도움을 줄 수 있다.
- UI 개발에 사용할 수 있다.
- 프로토타입의 목표와 기능을 명확히 해야한다.
- 유용성, 설계 품질, 유지보수성 향상
- 실수요 충족 및 개발 비용 감소
- 기능 요구사항에 초점을 맞춰 품질이 저하 → 검증 이후 폐기
- 설계 문서 X
- 변경 허용 : 점증적 개발을 통해 시스템 변경이 쉽도록 설계
- 점증적 인도 (Increment delivery)
- 변경 회피와 허용 모두 제공
- 높은 우선 순위의 서비스 우선 구현 및 전달
- 개발을 마친 증가분을 고객에게 전달 (점증적 개발과의 차이점)
- 추가 요구사항 분석 및 다음 증가분에 적용
- 우선 사용으로 재학습 비용 감소 및 빠른 이용
- 중요한 서비스를 많이 테스트하여 오류 감소
- 기존 시스템의 대체에는 부적절
- 최종 증가분을 명세할 때 까지 완전한 시스템 명세 확보 불가 → 입찰 불가
- 단계
- 요구사항 정의 → 요구사항 배정 → 설계 → 개발 → 기능 검증 → 기능 병합 → 시스템 검증 → 배포 → 개발 지속 or 완료
애자일 기법
- 계획 주도 개발은 신속한 개발에 부적합 → 애자일 주목
- 계획, 설계, 문서화의 오버헤드가 크다.
- 계획 > 개발
- 애자일 기법 특징
- 명세 - 설계 - 구현이 중첩 → 요구사항와 설계가 분리되지 않고 함께 발전
- 문서를 최소화하여 개발 품질에 집중
- 이해 당사자가 개발에 참여
- 증가분의 연속으로 개발 (점증적 개발)
- 여러 도구 사용
- 중소 규모 개발, 외부 영향이 적은 조직에 적절
- 애자일 기법 원칙
- 고객 참여
- 변화 수용
- 점증적 인도
- 단순성
- 사람 우선
- 사용자 스토리
- 요구사항 대신 사용
- 여러 카드로 표현, 카드는 태스크로 분할
- 태스크 별 일정 및 비용 측정
- 고객이 스토리를 선택하여 우선순위 결정
- 리팩토링
- 변경 및 코드 개선을 위해 리팩토링을 꾸준히 함
- 다만 리팩토링이 전체에 영향을 주는 경우도 있다.
- 테스트 우선 개발
- 시나리오 기반의 점증적 테스트 개발
- 테스트 자동화
- 테스트 개발 및 검증에서 고객이 참여 (실 사례 기반)
- 테스트 작성이 시스템을 암묵적으로 명세
- 애자일 프로젝트 관리
- 스크럼 애자일
- 소규모 개발팀
- 스크럼 회의
- 스프린트
- 백로그 : 할 일 목록
- 스크럼 장점
- 진척 사항 판단이 어려운 애자일에 유용
- 불안정한 요구사항으로 인한 지연이 없다.
- 의사소통 향상
- 고객이 증가분을 제때 전달받고 피드백을 줄 수 있다.
- 애자일의 단점
- 법적 계약 등에 부적절
- 유지보수에 부적절
- 소규모에 적절
- 제품 문서의 부족
- 고객 참여나 개발팀이 지속적으로 유지될 때만 유용 → 장기 프로젝트에 부적절
요구 공학
- 사용자 요구사항 : 고객이 충분히 이해할 수 있어야 한다.
- 시스템 요구사항 : 시스템 기능이나 제약사항을 상세히 기술해야 한다.
- 시스템 이해 당사자
- 실 사용자
- 시스템 관리자, 소유자
- 법, 규제
- 기능적 요구사항
- 시스템이 동작 해야하는 방식 기술 (무엇을?)
- 이해가 쉬운 자연어로 작성
- 시스템 입출력, 예외상황 설명
- 완전성과 일관성 필요 → 자세하고 모순없이
- 비 기능적 요구사항
- 일반적인 목표 제시 → 모호하고 어려움 → 최소한의 척도를 제공
- 서비스와 기능에 대한 제약 조건 (성능 등)
- 개발 언어 및 방법을 명세할 수도 있다.
- 시스템 전체의 속성이나 제약에 대해 정의
- 성능, 보안, 신뢰도 등
- 비기능적 요구사항에서 기능적 요구사항 파생 가능
- 제품 요구사항 : 성능, 신뢰성, 보안, 사용성
- 조직 요구사항 : 조작, 개발 언어 및 프로세스, 표준, 운영 환경
- 외부 요구사항 : 규제, 법, 윤리
- 요구공학 프로세스
- 요구사항 도출(elicitation)
- 이해관계자는 일반적 용어, 자기들의 용어로 표현
- 서로 다른 요구사항, 정치적 요소
- 경제-비즈니스 환경에 따라 바뀌는 요구사항
- 프로세스
1. 요구사항 발견 (이해 당사자들과의 상호작용)
1. 인터뷰
- 개방적 인터뷰, 폐쇄적 인터뷰 혼용
2. 관찰 또는 문화기술적 연구
- 사람들의 실제 일하는 방식 연구 → 잘 드러나지 않는 요구사항 발견
3. 스토리와 시나리오
- 실생활의 사례와 연관짓기
- 스토리 : 이야기하는 방식으로 작성(고수준)
- 시나리오 : 입출력, 정상흐름, 예외흐름, 시작 및 종료 등의 정보를 구조화
2. 요구사항 분류 및 구성 (정리 및 조직화)
3. 요구사항 우선순위 결정 및 협상
4. 요구사항 문서화
- 요구사항 명세(specification)
- 사용자 및 시스템 요구사항을 문서로 작성
- 설계 문서가 아님 → 시스템이 무엇을 할지 기술(어떻게X)
- 사용자 요구사항 : 이해가 쉽고 기술적 배경 없음
- 시스템 요구사항 : 기술적 정보를 자세히 작성
- 계약에 사용될 수 있다 → 최대한 완벽하게 작성
- 작성법
- 자연어 명세
- 표현력이 높고 직관적, 범용적
- 전문용어를 피하고 기준 용어를 사용
- 요구사항의 근거 및 출처 기록
- 문제점
- 모호할 수 있다.
- 기능적, 비기능적 요구사항이나 여러 다른 요구사항이 혼합될 수 있다.
- 구조적 명세
- 표준화돤 방식을 따라 작성
- 기능 정의, 입출력 설명, 동작, 사전-사후조건, 부작용 등
- 시각적 자료, 수치표
- 보조 형태로 사용
- 테이블, 유즈케이스 다이어그램(상호작용)
- 요구사항 검증(validation)
- 점검 항목
- 유효성 : 사용자의 실제 요구를 반영하는지?
- 일관성 : 요구사항에 모순이 없는지?
- 완전성 : 모든 기능과 제약사항이 포함되어 있는지?
- 실현성 : 기술, 예산, 시간의 부족함이 없는지?
- 검증가능성 : 문서 및 테스트로 검증 가능한지?
- 점검 기법
- 요구사항 검토
- 프로토타입
- 테스트 케이스
- 요구사항 리뷰
- 정기적으로 이해관계자를 포함하여 의사소통
- 정형적 or 비정형적
시스템 모델링
- 요구공학 중에 사용
- UML 사용
- 엔지니어에게 설명하기 위해 사용
- 모델
- 컨텍스트 모델(외부 관점)
- 시스템의 경계를 결정 → 시스템 요구사항에 영향을 미침
- 시스템 동작, 기능의 범위를 결정
- 사회-조직적 관심에 따라 달라질 수 있다.
- 시스템과 연관된 다른 시스템 간의 관계
- 액티비티 다이어그램
- 상호작용 모델(상호작용 관점)
- 유저, 시스템 간, 컴포넌트 간 상호작용 존재
- 시스템 성능, 의존성을 충족시킬 수 있는지?
- 유스케이스 다이어그램, 시퀀스 다이어그램
- 구조적 모델(구조 관점)
- 내부 컴포넌트 간의 관계 표현
- 정적 모델, 동적 모델
- 시스템 아키텍처 설계
- 클래스 다이어그램
- 행동 모델(동작 관점)
- 시스템이 자극에 대해 반응할 때 무엇이 일어나는지, 무엇이 의도되었는지
- 자극 : 데이터, 이벤트
- 데이터 주도 모델링
- 데이터 처리에 중점
- 데이터 입력에 영향 액션의 순서(연속적으로)로 표현
- 직관적, 이해당사자들의 접근 용이
- 액티비티 다이어그램, 시퀀스 다이어그램
- 이벤트 주도 모델링
- 유한한 수의 상태의 전이를 기반으로 한다.
- 내부-외부 이벤트에 대한 반응을 표현
- 실시간 시스템에 유용
- 상태 다이어그램
- 다이어그램
- 액티비티 : 프로세스, 데이터 처리
- 액션으로 이루어진 state
- 분기
- 경계
- 유즈케이스 : 시스템과 환경 간의 상호작용
- 상호작용을 개략적으로 표현
- 시퀀스 : 액터, 시스템 컴포넌트 간 상호작용
- 유즈케이스를 액터, 객체 기반으로 순서대로 자세히 표현
- 클래스 : 클래스 간 연관
- 객체 지향 시스템에서 사용
- 1대1, 1대다, 다대다 관계
- 클래스, 속성, 오퍼레이션
- 일반화 관계 : 상속
- 집합 관계 : 독립적 구성요소
- 복합 관계 : 종속적 구성요소
- 상태 : 내-외부 이벤트 반응
- 상태 변화를 표현
- 이벤트를 선택하지 않고 그 선택에 반응
- 노드 = 현재 상태
- 행동 결과를 표현
- 모델 주도 계획
