[소프트웨어 공학] 기획부터 개발까지

jaypyon·2021년 10월 22일
0

프로세스 모델

Waterfall, Prototyping, Spiral, Evolutionary 모델에 대해서는 생략한다.

Unified Process

  1. inception : 도입 과정으로 유스케이스의 개요를 작성, 프로젝트 계획을 작성, 소프트웨어 구조를 작성한다.
  • 유스케이스 : 현금인출기로 예를 들자면 해당하는 비즈니스 프로세스인 입금, 출금, 잔고조회 등을 정의하고 모델링하는 것이다.
  1. elaboration : UML 다이어그램, 유스케이스를 작성한다.
  2. construction : 유스케이스에 대해 구현하고 시스템에 통합한다.
  3. transition : 사용자를 교육하고 베타테스팅을 하여 유지보수한다. 시스템을 배치하는 작업을 일컫는다.

Agile

XP 모델 (익스트림 프로그래밍)

  1. 사용자 스토리
  2. 매일 빌드하고 통합
  3. 테스트 주도 개발(TDD) :
  • 코딩에 앞서 요구사항을 검증하는 테스트 시나리오의 작성.
  • 최소한의 코드 생성으로 해당 테스트 시나리오를 통과.
  • 표준에 맞도록 리팩토링.
  1. 페어 프로그래밍 : 코딩과 검증을 동시에 진행한다.

스크럼 모델

  1. 백로그(할 일) 정의 및 우선순위 부여
  2. 스프린트라는 짧은 반복 출시 주기(2~4주)를 이용하여 소통하고 시스템을 향상시킨다.

개발 방법론

구조적 방법론

모듈(함수) 위주의 설계 방법

  1. 실세계의 문제를 Process 관점으로 모델링한다. Data flow Diagram을 사용하여 엔티티, 프로세스, 데이터베이스를 노드로 표현하고 간선으로 관계를 나타낸다.
  2. 분할 정복 원리를 적용하고, DFD(최상위 레벨의 프로세스 배경도)로부터 단순한 프로세스로 분할한다. 또한 말단 프로세스의 자료구조, 입력, 출력, 알고리즘을 명시한다.

총평 : 분석에서 설계과정에 대한 전환이 쉽지 않다.

정보공학 방법론

엔티티(자료)위주의 설계 방법

  1. 정보전략 계획
  2. 비즈니스 영역 분석
  3. 비즈니스 시스템 설계 : 데이터, 프로세스 설계 : 논리ERD, 프로세스 흐름도 산출
  4. 시스템 구축 : 데이터 상세 설계, 코딩 : 물리ERD, UI, 코드 산출

3번과 4번을 할 때엔 결국 구조적 방법론을 재적용해야 하는 것과 비슷한 논리로 흘러가는 것 같다. 왜냐하면 구조적 방법론에서 산출한 DFD는 프로세스와 데이터의 흐름을 정의한 것이고, 위 방법론에서 산출한 ERD와 프로세스의 흐름도는 해당 DFD를 둘로 쪼갠 것과 같은 역할을 수행하기 때문이다.

총평 : 시간이 오래 소요된다.

객체지향 방법론

객체(클래스) 위주의 설계 방법

  1. 유스케이스 접근법, Booch 방법론, OMT(객체 모델링 기법) 세가지 방법론이 저명하다.
  2. 위 세가지 방법론을 거쳐 탄생한것이 UML(Unified Modeling Language)와 UP(Unified Process)이다.

총평 : 프로그래머의 숙련도에 따라서 크게 효용이 갈린다.

요구 분석

요구란 고객의 요청을 확정한 것이다. 기능적 요구(동사)와 비기능적 요구(형용사)로 분류된다.

요구

기능 요구

  1. 동사로 표현되는 요구사항이다.
  • "시스템은 항공편을 검색할 수 있어야 한다"와 같이 입력,처리,출력이라는 일련의 과정에서 시스템이 해야하는 동작에 관한 내용이다.
  1. IEEE830에 따르면 입력의 검증, 정확한 작업순서, 에러처리, 파라미터의 유효성, 입출력 관계와 같은 사항이 포함되어야 한다.

비기능 요구

  1. 형용사로 표현되는 요구사항이다.
  2. 외부인터페이스, 메모리, 성능, 사용자의 특성 및 가정, 설치환경의 적합성과 같은 사항이 포함된다.

요구 추출

  1. 고객의 발표, 문헌 조사, 브레인스토밍, 인터뷰, 설문, 프로토타이핑을 통한 요구 취합

요구 분석

요구 품질이 원하는 특성

  1. 원자성(단일목적성) :
  • 나쁜 예 : 학생은 학사와 석사를 취득할 수 있다.
  • 좋은 예 : 학생은 학사를 취득할 수 있다. 학생은 석사를 취득할 수 있다.
  1. 완전성 : ~등 을 사용하여와 같은 표현이 아닌 완전한 정보를 포함해야만 한다.
  2. 비모호성과 통일성 : 단어의 일원화와 명확한 것을 기술해야 한다.
  3. 추적가능성 :
  • 나쁜 예 : 학생 정보의 갱신
  • 좋은 예 : 학생 정보의 갱신 - REFERENCE REQ 4.1과 연결됩니다.
  1. 우선순위화 : priority를 설정한다.
  2. 테스트 가능성 : 검증 가능한 요구사항을 기술한다.

유스케이스 다이어그램 작성

도메인 분석, 사용자 시나리오를 거쳐 유스케이스를 찾아낸다. 그 후 유스케이스 다이어그램을 작성한다.
1. 유스케이스 다이어그램은 유스케이스와 액터로 구분된다.
2. 액터(사람 또는 시스템)의 유스케이스(행위)를 다이어그램으로 나타내며 예시는 다음과 같다.

유스케이스 명세 작성

  1. 소프트웨어 요구 정의를 사용자 관점으로 바꾼 시나리오이다.
  2. 시작조건, 기본흐름, 대안흐름, 종료조건, 액터가 명시되고 해당 유스케이스의 이름이 명시된다.

유스케이스 간의 관계

  1. 포함관계 : 송금, 예금에는 인증 과정이 필요하다. 따라서 인증 과정 이벤트라는 공통적인 요소를 분리하여 포함관계로 나타낸다.
  2. 확장 관계 : 결제에는 멤버십 할인이라는 부가적인 유스케이스로 확장 될 수 있는 가능성이 있다.

요구 명세

  1. 시스템이 무엇(What)을 수행할 것인가에 대해 기술한다.
  2. 기술된 모든 요구사항은 검증이 가능하여야 하므로 원하는 시스템의 품질, 중요도, 측정, 검증 방법 및 기준을 명시한다.
  3. 시스템이 외부에서 보이는 행위를 기술하는 것이기 때문에 알고리즘이나 구조, 설계를 나타내지 않는다.

요구 모델링

UML Diagram


1. 구조 다이어그램(Structure Diagram)
객체 다이어그램, 복합체 구조 다이어그램,클래스 다이어그램, 배치 다이어그램, 컴포넌트 다이어그램, 패키지 다이어그램
2. 행위 다이어그램(Behavior Diagram)
활동 다이어그램, 상태 머신 다이어그램, 유즈 케이스 다이어그램, 상호작용 다이어그램

설계 원리

SOLID 설계 원칙

  1. 단일 책임의 원칙 : 클래스의 역할과 책임을 단일화
  2. 개방 폐쇄의 원리 : 클래스를 상속받아서 확장은 자유롭지만, 원 클래스에 대한 수정은 제한한다.
  3. 리스코프 교체의 원리 : 자식 클래스로 부모 클래스를 대체할 수 있다.
  4. 인터페이스 분리의 원리
  5. 의존관계 역전의 원리

추가예정
~256

아키텍쳐 설계와 패턴

추가예정
270-306

profile
DGU CSE

0개의 댓글