요구사항 확인

1. 소프트웨어 생명주기 모델 프로세스

요구사항 분석 ➡️ 설계 ➡️ 구현 ➡️ 테스트 ➡️ 유지보수

2. 소프트웨어 생명주기 모델 종류

1) 폭포수 모델 : 소프트웨어 개발시 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어가는 모델

• 장점 : 이해가 용이, 관리가 편리
• 단점 : 요구사항 변경이 어려움

2) 나선형 모델 : 시스템 개발 시 의험을 최소화 하기 위해 점진적으로 개발해 나가는 모델

• 장점 : 위험성이 감소, 변경에 유연한 대처 가능
• 단점 : 단계 반복으로 인해 관리가 어려움

3) 프로토타이핑 모델 : 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 피드백 반영하며 개발

• 장점 : 요구사항 분석 용이, 타당성 검증 가능
• 단점 : 프로토타입 폐기에 따른 비용 증가

4) 반복적 모델 : 증분방식으로 병행 개발하는 모델

• 장점 : 병해 개발로 인한 일정 단축 가능
• 단점 : 병행 개발에 따른 관리 비용 증가

3. 애자일 방법론

: 절차보다 사람이 중심이되어 변화에 신속하게 대처하며 효율적으로 개발하는 방법론

1) 스크럼 : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

2) 린 : 낭비요소를 제거해서 품질을 향상시킨 방법론

3) XP : 의사소통 개선과 즉각적피드백으로 sw품질 향상을 위한 방법론

cf)기타 방법론

• 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
• 정보공학 방법론 : 정보 시스템 개발에 필요한 관리 절차와 작업 기법ㅇ르 체계화한 방법론
• 객체지향 방법론 : 복잡한 현실세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
• 컴포지트 기반 방법론 : 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램 작성
• 제품계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

4. 객체지향 분석 방법론

: 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 속성과 연산, 관계를 정의하는 모델링 기법

1) OOSE : 유스케이스를 모든 모델의 간간으로 활용한 방법론, 기능적 요구사항 중심의 시스템, 만든이 야곱슨

2) OMT : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론

• 객체 모델링 : 요구하는 객체 찾고 객체간 관계 정의, ERD만드는 과정
• 동적 모델링 : 시간의 흐름에 따라 객체 사이 제어 흐름, 동작 순서 등 동적 행위 표현, 상태 다이어그램으로 표현
• 기능 모델링 : 프로세스들의 자료 흐름을 중심으로 처리과정 표현, 자료흐름도를 활용하여 표현

3) OOD : 설계 문서화를 강조해 개발, 분석과 설계 분리 불가능

5. 비용산정 모형

1) 하향식 산정방법 : 경험많은 전문가와 조력자를 통해 비용 산정

• 전문가 판단
• 델파이 기법 : 전문가의 경험 지식을 통한 문제 해결 및 미래예측 기법

2) 상향식 산정 방법 : 세부적인 요구사항과 기능에 따라 필요한 비용 산정

• LOC : 각 기능의 원시라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 비용 산정
• ManMonth : 한 사람이 1개월 간 할 수 있는 일의 양을 기준으로 프로젝트 비용산정
• CoCoMo : 프로그램 규모에 따라 비용 산정
  5만 라인 이하 ➡️ 조직형
  30만 라인 이하 ➡️ 반분리형
  30만 라인 이상 ➡️ 임베디드형
• 푸트남 모형 : 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
• 기능점수 모형 : 요구기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총기능 점수를 계산하여 비용 산정

6. 일정관리 모형

1) 주공정법 : 시작부터 종료까지 가장 긴 경로 계싼

2) PERT : 일의 순서를 계획적으로 정리하기 위한 기법으로 비관치, 낙관치, 중간치 3점 추정방식을 통해 일정 관리

3) 중요 연쇄 프로젝트 관리 : 주공정 연쇄기법으로 제약사항 고려해 일정 작성

7. 디자인 패턴

: 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

1) 생성 패턴 : 객체 인스턴스 생성 관여, 클래스 정의와 객체 생성방식 구조화, 캡슐화 하는 패턴

• Builder : 복합 객체 생성시 객체 생성과 구현을 분리해 동일한 생성 절차에서 다른 결과 내는 패턴
• Prototype : 처음부터 일반적인 원형을 만들어 두고, 필요시 복사하여 필요한 부분만 수정해 사용하는 패턴
• Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스 생성
• Abstract Factory : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체 조합해 만듬
• Singleton : 전역변수를 생성X, 객체를 하나만 생성O, 생성된 객체를 어디에서든지 참조가능하게 만듬

2) 구조 패턴 : 더 큰 구조 형성을 목적으로 클래스나 객체의 조합을 다루는 패턴

• Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 패턴
• Decorater : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해나가는 설계 패턴, 객체 결합으로 유연하게 확장
• Facade : 복잡한 시스템에 단순한 인터페이스를 제공해 사용자-인터페이스 간 결합도 낮추어 구조파악 용이
• Flyweight : 다수 객체 생성시 모두가 갖는 본질적 요소를 클래스화 하여 공유해 메모리 절약, 클래스 경량화
• Proxy : 실제 객체에 대한 대리 객체로 실제 객체 접근 전에 필요한 행동 취할 수 있게 만듬
• Compostie : 객체들간의 관계를 트리구조로 구성하여 부분-전체 계층을 표현하는 패턴
• Adapter : 기존에 생성된 클래스를 재사용할 수 있게 맞춰주는 인터페이스를 만드는 패턴

3) 행위 패턴 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

• Mediatater : 중간에 중재자를 두고 중재자에게 모든 것을 요구해 통신 빈도수 줄이는 패턴
• Interpreter : 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 크래스를 각각 작성해 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴
• Iterator : 내부 구조를 노출하지 않고 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 패턴
• Template Method : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 구조를 바꾸지 않으면서 특정 단계에서 수행하는 내역만을 바꾸는 패턴
• Observer : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에 연락이 가고 자동으로 내용이 갱신되는 일대 다 의존성을 지니며 상호 작용하는 객체 사이에선 가능하면 느슨하게 결합하는 패턴
• State : 객체 상태를 캡슐화하여 클래스화 함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여, 변경시 원시코드 수정을 최소화 할 수 있는 패턴
• Visitor : 각 클래스 ㅌ데이터 구조로 부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고, 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행하도록 만드는 패턴
• Command : 실행 기능을 캡슐화 하여 주어진 여러 기능을 재사용성이 높은 클래스로 설계하는 패턴
• Strategy : 행위를 클래스로 캡슈로하해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴
• Memento : 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴 (Undo기능)
• Chain of Responsibility : 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩 되어 있을 때 기능 처리의 연결이 불가능한데 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있게 연결

8. 소프트웨어 아키텍처

: 여러가지 소프트웨어 구성요소와 그 구성요소의 외부 특성, 그리고 구성요소 간의 관계를 표현하는 구조체

1) 소프트웨어 4+1뷰

• 유스케이스 뷰 : 유스케이스 or 아키텍처 도출 및 설계하고 다른 뷰를 섬증하는데 사용되는 뷰
• 논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
• 프로세스 뷰 : 시스템의 비기능적인 속성으로서 자원의 효율적 사용, 병행실행, 비동기, 이벤트 처리 뷰
• 구현 뷰 : 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
• 배포 뷰 : 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는 가를 매핑해서 보여주는 뷰

2) 소프트웨어 아키텍처 패턴

• 계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴, 서로 마주보는 두 계층 사이에서만 상호작용이 이뤄짐
• 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
• 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
• 브로커 패턴 : 분리된 컴포넌트들로 이뤄진 분산 시스템에서 사용되고, 브로커 컴포넌트는 컴포넌트 간의 통신을 조절하는 역할 수행
• MVC패턴 : 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴

9. 요구사항 공학

: 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

1) 요구사항 도출 : 소프트웨어가 해겨해야할 문제를 이해하고, 고객으로부터 제시되는 추상적인 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계

2) 요구사항 분석 : 도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계

3) 요구사항 명세 : 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

4) 확인 및 검증 : 분석가가 요구사항을 이해했는지 확인하고, 요구사항 문서가 회사의 표준에 적합한지, 일관성있고 완전한지 검증

• 동료검토 : 2~3명이 진행하는 리뷰 형태
• 인스펙션 : 검토자료를 회의 전에 배포해서 사전 검토 후 짧은 시간 동안 회의
• 워크스루 : 제작자 이외의 다른 전문가들이 검사하여 오류 찾는 검토법