🎫소프트웨어 공학 part03~05. 사례연구 / Inception / 진화적요구사항

[3장 – 사례연구]

■ SDLC (Software Development Life Cycle)

• 소프트 웨어의 개발 주기

■ 객체지향 시스템의 3개의 구조적 계층(architectural layer)

사용자 인터페이스, 어플리케이션 로직 및 도메인 오브젝트, 테크니컬 서비스

• Application Logic and Domain Objects : 매출 등록 지불 등 문제 영역과 관련된 객체들
• Technical Services: 데이터 베이스 API, 오류 로그
  

■ Façade Pattern(파사드 패턴)

소프트웨어 내부의 서브시스템(크고 많은 코드들)에 각각 일일이 접근하기보다 facade 객체를 통하여 통합된 외부 인터페이스를 만들어 쉽게 내부에 접근할 수 있도록 한다.

[4장 – Inception은 타당성 검토다]

■ Inception

이 프로젝트의 비전과 비즈니스 케이스는 무엇인가?
실현가능성은 어느정도 되는가?
대강의 비용 산정 및 계속할지 말지를 결정한다.

■ Inception의 목적

프로젝트 목표에 대한 공통적인 초기 비전 설정
가능성 결정, 투자가치 판단

■ V&V

Validation - 분석이 옳은 것인가?
기능이 시장에서 Vaild한가 = Waht이 제대로 되었는가?
Verification - 설계 및 구현이 옳은 것인가?
제대로 기능이 구현되었는가 = How가 제대로 되었는가?

■ Inception의 특징

• 하루. 길어도 2주 안에 끝내야 한다.
• 완벽한 순서 (요구사항 정의->아키텍쳐 정의->구현)를 따라갈 수 없다. 완벽하지 않아도 진행된다.
• 유즈케이스의 10~20%정도는 상세히 쓰여야 한다.
• 신뢰할만한 추정과 계획은 elaboration 단계에서 반복적으로 만들어지는 것이지 Inception에서 할 일이 아니다.
• 요구사항을 전부 정의하는 것이 아니며, 이는 불가능하다. 중요한 건 타당성 검토다.
• 비즈니스 케이스나 비전 산출물이 있어야 한다.
• 핵심적인 유즈케이스 및 액터가 식별되어야 한다. (단, 모든 유즈케이스는 불가능하다)

[5장 – 진화적요구사항]

요구사항이 제대로 수립 되지않으면 쭉 진행되었다가 다시 돌아오게 된다.
따라서 지속적으로 변하는 요구사항에 대해서 요구사항의 관리가 필요하다.

■ 폭포수 모델 VS UP

폭포수 모델 : 프로젝트 초기에 모든 요구사항을 도출.
UP : 시스템에 대해 변화하는 요구사항을 조금씩 체계적으로 도출.
UP와 같은 진화적 요구사항에선 대부분의 요구사항이 확정되기 전 제품의 개발 및 테스트가 진행된다.
따라서 개발 업무가 대폭 감소되고, 주기적인 사용자와의 소통을 통해 만족감또한 올라간다.

■ FURPS+ 모델

모든 요구 사항을 다루었는지 확인하는 데 사용될 수 있는 체크리스트

• Functional Requirements : 기능적 요구사항
• Not-Functional Requirements : 편의성, 신뢰성, 성능, 지원성 등 (시스템 구조에 큰 영향을 미친다)

■ 요구사항이 포함되는 산출물

요구사항은 유즈케이스, 비전, 보충명세, 용어집(주민번호 유효 규칙 등)에 포함된다.