CHAPTER.01 소프트웨어 개발 방법론
소프트웨어 생성주기
- 시스템의 요구분석부터 유지보수까지의 전 과정을 체계화한 절차
- 요구사항 분석 : 요구와 조건 결정
- 설계 : 수행 방법을 논리적으로 결정
- 구현 : 실제 프로그램 작성
- 테스트 검사와 평가
- 유지보수 : 인수되고 설치된 후 일어나는 모든 활동
소프트웨어 개발 방법론
- 구조적 방법론(Structured Development) : 전체 시스템을 기능에 따라 나누어 개발, 통합하는 "분할, 정복" 접근 방식
- 정보공학 방법론(Information Engineering Development) : "정보 시스템 개발"에 필요한 관리 절차와 작업 기법 체계화
- 객체지향 방법론(Object-Oriented Development) : "객체"라는 기본 단위로 시스템 분석 및 설계
- 컴포넌트기반 방법론(CBD; Component Based Development) : "컴포넌트"를 조립 > 하나의 새로운 응용 프로그램 작성
- 애자일 방법론(Agile Development) : "사람 중심, 유연, 신속"
- 제품계열 방법론(Product Line Development) : "특정 제품"에 적용하고 싶은 공통된 기능을 정의, 개발. 임베디드 소프트웨어 작성에 유리
애자일 방법론의 유형
- XP : 의사소통 개선, 즉각적 피드백
- 스크럼 : 매일 정해진 시간, 장소에서 짧은 시간의 개발
- 린 : 도요타의 린 시스템 품질 기법, 낭비요소 제거
XP(eXtreme Programming)
- 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중
- 기본 원리
- 짝 프로그래밍(Pair Programming) : "둘이서 코딩"
- 지속적인 통합(CI; Continuous Integration) : 매일 여러번씩 소프트웨어 통합
- 메타포어(Metaphor) : 공통적인 이름체계와 시스템 서술서, 고객과 개발자 간의 의사소통 원활하게
- 테스트 기반 개발(TDD; Test Driven Develop) : 테스트 먼저 수행 후 실제 코드 작성
- 리팩토링(Refactoring) : 프로그램 기능은 바꾸지 않으면서 중복제거와 단순화 위해 시스템 재구성
- 공동 코드 소유(Collective Ownership) : 누구라도 언제든지 코드 수정 가능
- 계획 세우기(Planning Process) : 고객 요구 가치 정의, 개발자가 필요한 것과 지연 부분을 알려주어야 함
- 작은 릴리즈(Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트
- 간단한 디자인(Simple Design) : 가장 단순한 시스템 설계
- 40시간 작업(40 - hour Work : 1주일에 40시간 근무
- 고객 상주(On Site Customer) : 고객 풀타임 상주
- 코드 표준(Coding Standard) : 모든 코드에 대한 코딩 표준 정의
럼바우 데이터 모델링
- 객체(Object) : 객체간 관계 정의. E-R 다이어그램
- 동적(Dynamic) : 시스템 간 제어 흐름, 동작 순서. 상태 다이어그램
- 기능(Functional) : 자료 흐름 중심. 자료 흐름도(DFD)
델파이 기법
- 전문가의 경험적 지식을 통한 문제해결 및 미래 예측
비용 산정 방식 종류
- LoC : 원시 코드 라인의 낙관치, 중간치, 비관치 측정, 예측치를 구하여 비용 산정
- Man Month : 한 사람이 1개월동안 할 수 있는 양 기준 비용 산정
- COCOMO : 프로그램 규모에 따라
- 푸트남(Putnam) : 소프트웨어 개발주기 단계별로 요구할 인력 분포 가정
- 기능점수(FP) : 요구기능 증가 인자별 가중치 부여, 가중치 합산
프로젝트 기간
- Man Month % 프로젝트 인력
- Man Month = LoC(Line of Code) % 월간 코드 생산성
일정관리 모델 종류
- 주 공정법(CPM) : 여러 작업들의 수행 순서가 얽혀 있는 프로젝트 일정 계산
- PERT : 비관치, 낙관치, 중간치의 3점 추첨방식을 통해 일정 관리
- 중요 연쇄 프로젝트(CCPM) : 주 공정 연쇄법으로 자원 제약 사항을 고려하여 일정 관리
임계경로
- 가장 오랜 기간이 걸리는 경로
CHAPTER.02 현행 시스템 분석
소프트웨어 아키텍쳐
- 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
소프트웨어 아키텍쳐 4+1 뷰
- 유스케이스 뷰 : 유스케이스, 아키텍쳐를 도출하고 설계, 다른 뷰를 검증하는 데 사용(사용자, 설계자, 개발자, 테스트 관점)
- 논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
- 프로세스 뷰 : 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 보여주는 뷰(개발자, 시스템 통합자 관점)
- 구현 뷰 : 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
- 배포 뷰 : 컴포넌트가 물리적인 아키텍쳐에 어떻게 배치되는가를 매핑해서 보여주는 뷰
소프트웨어 아키텍쳐 패턴
- 계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴, 서로 마주보는 두 개의 계층 사이에서만 상호 작용이 이루어짐
- 클라이언트 - 서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 파이프 - 필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴. 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복
- 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴
- 모델 - 뷰 - 컨트롤러 패턴(MVC패턴) : 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴
비용 평가 모델
- SAAM : 변경 용이성, 기능성, 경험이 없는 조직 활용 가능
- ATAM : 아키텍쳐 품질 속성을 만족 시키는지 판단 및 품질 속성들의 이해 상충관계 평가
- CBAM : ATAM 바탕. 경제적 의사결정에 대한 요구를 충족
- ADR : 응집도 평가
- ARID : 특정 부분에 대한 품질요소 제공
디자인 패턴 유형
<목적>
- 생성 : 객체 인스턴스 생성에 관여. 구조화, 캡슐화 수행
- 구조 : 클래스, 객체의 조합을 다룸
- 행위 : 클래스타 객체들이 상호 작용하는 방법과 역할 분담
<범위>
- 클래스 : 클래스 간 관련성(상속관계), 컴파일 타임에 정적으로 결정
- 객체 : 객체 간 관련성, 런타임에 동적으로 결정
디자인 패턴 종류
<생성>
- Builder : 생성과 표기를 분리해서 복잡한 객체를 생성. 복잡한 인스턴스를 조립하여 만드는 구조
- Prototype : 기존 객체를 복제 후 수정하여 객체 생성
- Factory Method : 상위 클래스에서 인스턴스 만드는 방법 결정, 하위 클래스에서 실제 객체 생성
- Abstract Method : 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공
- Singleton : 전역 변수를 사용하지 않고 객체를 하나만 생성, 생성된 객체는 어디에서나 참조
<구조>
- Bridge : 기능과 구현의 클래스 계층 연결하고, 구현부에서 추상 계층 분리하여 추상화 부분과 실제 구현 부분 독립 확장
- Decorator : 중심이 되는 객체에 부가적인 기능을 동적으로 추가하고자 할 때 사용
- Facade : 건물의 정면을 의미. 복잡한 소프트웨어를 사용할 수 있게 간단한 인터페이스 제공
- Flyweight : 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 공유하여 메모리 경량화
- Proxy : 실제 기능을 수행하는 객체대신 가상의 객체를 사용해 로직의 흐름 제어
- Composite : 객체들의 관계를 트리 구조로 구성하여 부분 - 전체 계층을 표현하는 패턴
- Adapter : 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴
<행위>
- Mediator : 클래스 간의 복잡한 관계를 캡슐화하여 하나의 클래스에서 관리하도록 처리. M:N > M:1
- Interpreter : 간단한 언어의 문법을 정의하고 해석
- Iterator : 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법 제공
- Template Method : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화 해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
- Observer : 어떤 객체 상태가 변할 때 그와 연관된 객체들에게 알림을 보내는 패턴
- State : 객체 상태를 캡슐화하여 클래스화 함으로써 그것을 참조하게 하는 방식. 객체의 상태에 따라 행위 내용을 변경
- Visitor : 데이터 구조에서 처리기능을 분리하여 별도의 클래스로 구성하는 패턴 > 분리된 처리 기능은 각 클래스를 방문하여 수행
- Command : 요청을 객체 형태로 캡슐화 > 재이용하거나 취소할 수 있도록 요청에 필요 정보를 저장하거나 로그를 남기는 패턴 > 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리, 단순화
- Strategy : 동일 계열 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴. 클라이언트는 원하는 알고리즘을 선택하여 사용 가능. 클라이언트에 영향없이 알고리즘 변경 가능
- Memento : 특정 시점에서의 객체 내부 상태를 객체화 함 > 요청에 따라 해당 시점의 상태로 돌릴 수 있는 기능 제공 > 되돌리기 되돌리기 기능
- Chain of Responsibility
OSI 7 계층
- 응용 계층(Application) : 사용자와 네트워크 간의 응용서비스 연결, 데이터 생성 / HTTP, FTP / 데이터
- 표현 계층(Presentation) : 데이터 형식 설정과 부호 교환, 암·복호화 / JPEG, MPEG / 데이터
- 세션 계층(Session) : 연결 접속 및 동기 제어 / SSH, TLS / 데이터
- 전송 계층(Transport) : 신뢰성있는 통신 보장, 데이터 분할, 재조립, 흐름 제어, 오류 제어, 혼잡 제어 / TCP, UDP / 세그먼트
- 네트워크 계층(Network) : 단말기 간 데이터 전송을 위한 최적화된 경로 제공 / IP, ICMP / 패킷
- 데이터링크 계층(Data Link) : 인접 시스템 간 데이터 전송, 전송 오류 제어 / 이더넷 / 프레임
- 물리 계층(Physical) : 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환 / RS-232C / 비트
CHAPTER.03 요구사항 확인
요구공학이란?
- 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
요구사항의 분류
- 기능적 요구사항 : 시스템이 제공하는 기능, 서비스
- 비기능적 요구사항 : 시스템이 수행하는 기능이외의 사항, 제약사항
요구사항 개발 단계
- 도출 : 문제 이해, 관련 정보 식별, 수집 방법 결정, 수집된 요구사항 구체적 표현
- 분석 : 충돌, 중복, 누락 등 분석을 통해 완전성과 일반성 확보
- 명세 : 체계적 검토, 평가, 승인될 수 있는 문서 작성 (산출물 : 요구사항 명세서)
- 확인 및 검증 : 확인(Validation)하고 검증(Verification)
요구사항 도출 단계 주요 기법
- 인터뷰 : 이해 관계자와 직접 대화. 공식적, 비공식적 정보 수집 방법
- 브레인 스토밍 : 말을 꺼내기 쉬운 분위기, 아이디어를 비판없이 수용할 수 있도록 회의
- 델파이 기법 : 전문가의 경험적 지식
- 롤 플레잉 : 장면 설정, 연기
- 워크숍 : 단기간의 집중적 노력, 다양한 전문적 정보 획득, 공유
- 설문조사 : 설문지, 여론조사, 간접적 정보 수집
요구사항 명세 기법
- 정형 : 수학적 원리, 표기법으로 서술
- 비정형: 자연어 기반
상세 정형 기술 검토 기법
- 관리 리뷰 : 프로젝트 진행 상황에 대한 전반적인 검토 바탕, 범위, 일정, 인력 등에 대한 통제 및 의사결정 지원
- 기술 리퓨 : 정의된 계획 및 명세를 준수하고 있는지에 대한 검토 수행
- 인스펙션 : 저작자 외에 다른 전문가 또는 팀이 검사
- 워크스루 : 검토자료 회의 전에 배포해서 사전 검토 후 짧은 시간동안 회의 진행
- 감사 : 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지 독립적 평가
형상 통제 위원회
- 형상 관리에 대한 주요 방침을 정하고 산출물 검토, 단계별 의사결정 수행
CHAPTER.04 분석모델 확인하기
타당성 검토 항목
- 성능 및 용량 산정의 적정성
- IT 시장 성숙도 및 트렌드 부합성
- 시스템 간 상호 운용성
- 기술적 위험 분석
유스케이스 모델 검증 방법
- 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서를 점검하는 기법