1️⃣ 요구사항 확인
Chapter01. 소프트웨어 개발 방법론
소프트웨어 개발 방법론
소프트웨어 생명주기
(1) 개념
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
(2) 모델 프로세스
요구사항 분석 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
| 설계 | 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 |
| 구현 | 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 |
| 테스트 | 시스템이 정해진 요구를 만족하는지, 예상과 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 |
| 유지보수 | 시스템이 인수되고 설치된 후 일어나는 모든 활동 |
(3) 모델 종류
- 폭포수 모델 : 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
- 프로토타이핑 모델 : 고객이 요구한 주요 기능을 프로토 타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
- 나선형 모델 : 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
- 반복적 모델 : 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델
소프트웨어 개발 방법론
(1) 개념
소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
(2) 종류
- 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통함하는 분할과 정복 접근 방식의 방법론
- 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 객체 지향 방법론 : ‘객체’라는 기본 단위로 시스템을 분석 및 설계하는 방법론
- 컴포넌트 기반 방법론 : 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 제품 계열 방법론
애자일(Agile)
(1) 개념
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 개발 기간이 짧고 신속, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있다.
(2) 등장 배경
- 소프트웨어 개발 환경의 변화
- 기존 개발 방법론의 한계
(3) 유형
1) XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 5가지 가치
- 용기
- 단순성
- 의사소통
- 피드백
- 존중
- 12가지 기본 원리
이외에 공동 코드 소유, 계획 세우기, 작은 릴리즈, 간단한 디자인, 40시간 작업, 고객 상주, 코드 표준이 있다.짝 프로그래밍 개발자 둘이서 짝으로 코딩하는 원리 지속적인 통합
(CI)매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리 메타포어 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리 테스트 기반 개발
(TDD)작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리 리팩토링 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
2) 스크럼 (SCRUM) :매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
3) 린 (LEAN) : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용
객체 지향 분석 방법론
(1) 개념
실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표한하는 기법
(2) 구성요소
클래스 (Class) 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀
| 객체 (Object) | 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상 |
| 메서드 (Method) | 클래스로부터 생성된 객체를 사용하는 방법 |
| 메시지 (Message) | 객체 간 상호 작용을 하기 위한 수단 |
| 인스턴스 (Instance) | 객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체 |
| 속성 (Property) | 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의 |
(3) 기법 : 캡슐화 / 상속성 / 다형성 / 추상화 / 정보은닉 / 관계성
- 오버로딩 : 매개변소의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법
- 오버라이딩 : 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의 할 수 있는 기법
(4) 객체 지향 설계 원칙 (SOLID)
- 단일 책임의 원칙 (SRP)
- 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중되어 있어야 한다는 원칙
- 객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초 원칙
- 개방 폐쇄 원칙 (OCP)
- 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다는 원칙
- 리스코프 치환의 원칙 (LSP)
- 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙
- 인터페이스 분리의 원칙 (ISP)
- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
- 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙
- 의존성 역전의 원칙 (DIP)
- 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙
(5) 럼바우의 객체 지향 분석 절차
- 객체 모델링 (Object Modeling)
- 정보 모델링(Information Modeling)이라고도 하며, 시스템에서 요구하는 객체를 찾고 객체 간의 관계를 정의하여 ER다이어그램을 만드는 과정까지의 모델링
- 가장 중요하며 선행되어 진행
- 동적 모델링 (Dynamic Modeling)
- 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링
- 상태 다이어그램을 활용하여 표현
- 기능 모델링 (Functional Modeling)
- 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링
- 자료 흐름도(DFD)를 활용하여 표현
프로젝트 관리
프로젝트 관리
(1) 개념
주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동
(2) 프로젝트 관리 대상
계획 관리 / 품질 관리 / 범위 관리
(3) 프로젝트 관리 3대 요소
사람(People) / 문제(Problem) / 프로세스(Process)
비용산정 모형 종류
(1) LoC (Lines of Code)
- 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식
(2) Man Month
- 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식
- (Man Month) = (LoC) / (프로그래머의 월간 생산성)
- (프로젝트 기간) = (Man Month) / (프로젝트 인력)
(3) COCOMO
- 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식
(4) 푸트남 (Putnam)
- 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
(5) 기능점수 (FP)
- 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식
델파이 기법(Delphi Method)
: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법으로 전문가 합의법이라고도 한다.
일정관리 모델 종류
(1) 주 공정법 (CPM)
- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
- 임계경로 : 프로젝트 시작에서 종료까지 가장 긴 시간이 걸리는 경로를 계산
(2) PERT
- 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
(3) 중요 연쇄 프로젝트 관리 (CCPM)
- 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
Chapter02. 현행 시스템 분석
현행 시스템 파악
구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성파악
소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 긜고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
소프트웨어 아키텍처 4+1 뷰
- 유스케이스 뷰
- 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰
- 사용자, 설계자, 개발자, 테스트 관점
- 논리 뷰
- 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
- 설계자 개발자 관점
- 프로세스 뷰
- 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
- 개발자, 시스템 통합자 관점
- 구현 뷰
- 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
- 배포 뷰
- 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰
소프트웨어 아키텍처 패턴
- 계층화 패턴
- 시스템을 계층으로 구분하여 구성하는 패턴
- 서로 마주 보는 두 개의 계층 사이에서만 상호 작용이 이루어짐
- 클라이언트 - 서버 패턴
- 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공
- 서버는 계속 클라이언트로부터 요청을 대기
- 파이프 - 필터 패턴
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능한 패턴
- 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복
- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이
- 브로커 패턴
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호작용이 가능한 패턴
- 모델 - 뷰 - 컨트롤러 패턴 (MVC)
- 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴
모델 핵심 기능과 데이터 보관 뷰 사용자에게 정보 표시
(하나이상의 뷰가 정의될 수 있음)컨트롤러 사용자로부터 요청을 입력받아 처리
소프트웨어 아키텍처 비용평가 모델
- SAAM : 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능
- ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
- CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족
- ADR : 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
- ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델
디자인 패턴
(1) 생성 패턴
- Builder : 복잡한 인스턴스를 조립하여 만드는 구조
- Prototype : 처음부터 원형을 만들어 놓고, 필요한 부분만 수정하여 사용하는 패턴
- Factory Method : 상위 클래스에서 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
- Abstract Factory : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
- Singleton : 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴
(2) 구조 패턴
- Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결
- Decorator : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
- Facade : 사용자와 시스템 간의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴
- Flyweight : 모두가 갖는 본질적인 요소를 클래스 화하여 공유함으로써 메모리 절약
- Proxy : 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때 할당하게 하여 메모리 절약
- Composite : 객체들의 관계를 트리 구조로 구성
- Adapter : 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
(3) 행위 패턴
- Mediator : 중간에 통제하고 지시할 수 있는 역할을 하는 중재자를 둔다.
- Interpreter : 여러 형태의 언어 구문을 해석할 수 있게 만든다.
- Iterator : 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능
- Template Method : 상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행
- Observer : 객체 상태의 변화에 따라 다를ㄴ 객체의 상태도 연동. 일대다 의존
- State : 객체의 상태에 따라 행위 내용을 변경
- Visitor : 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용
- Command : 주어진 여러기능을 실행할 수 있는 재사용성이 높은 클래스를 설계
- Strategy : 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해준다.
- Memento : 객체를 이전 상태로 복구시켜야 하는 경우, ‘작업취소(Undo)’요청 가능
- Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리
개발 기술 환경 정의
운영체제
컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램
- PC
- 윈도즈 : 중/소규모 서버, 일반 pc, 관리 비용이 장점
- 유닉스 : 대용량 처리, 엔터프라이즈급 서버
- 리눅스 : 중/대규모 서버, 높은 보안성
- 모바일
- 안드로이드 : 리눅스 운영체제 위에서 구동
- iOS
네트워크 OSI 7계층 (Layer)
| 응용 (Application) |
| 표현 (Presentation) |
| 세션 (Session) |
| 전송 (Transport) |
| 네트워크 (Network) |
| 데이터링크 (Data Link) |
| 물리 (Physical) |
DBMS 현행 시스템 분석 시 고려 사항
가 성 호 기 구 (가용성/ 성능/ 상호 호환성/ 기술 지원/ 구축 비용)
미들웨어 현행 시스템 분석 시 고려 사항
가 성 기 구 (가용성/ 성능/ 기술지원/ 구축 비용)
Chapter03. 요구사항 확인
요구사항
요구공학
사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
- 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항
- 비기능적 요구사항 : 시스템이 수행가능 기능 이외의 사항, 제약사항에 관한 요구사항
- 요구사항 명세서 : 소프트웨어의 요구사항을 분석하고 정의하는 단계(요구사항 명세단계)에서 작성되는 최종 산출물
정형 기술 검토
- 동료검토 : 2~3명이 진행하는 리뷰의 형태
- 워크스루 : 검토자료를 회의 전에 배포해서 사전검토한 후 짧은 시간동안 회의
- 인스펙션 : 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 검토방법
