1. 요구사항 확인 (소프트웨어 개발 방법론 / 현행 시스템 분석 / 요구사항 확인 / 분석 모델 확인하기)

 

🔢

01. 소프트웨어 개발 방법론

02. 현행 시스템 분석

03. 요구사항 확인

04. 분석 모델 확인하기

---

01. 소프트웨어 개발 방법론

소프트웨어 생명주기(SDLC : Software Development Life Cycle)

- 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 

 

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

프로세스	활동
1. 요구사항 분석	- 기능 요구사항 - 비기능 요구사항
2. 설계	- 시스템 구조 설계 - 프로그램 설계 - 사용자 인터페이스 설계
3. 구현	- 인터페이스 개발 - 자료 구조 개발 - 오류 처리
4. 테스트	- 단위 테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트
5. 유지보수	- 예방, 완전, 교정, 적응 유지보수

 

 

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

폭포수 모델 (Waterfall Model)	프로토타이핑 모델 (Prototyping Model)	나선형 모델 (Spiral Model)	반복적 모델 (Iteration Model)
요구사항 분석 설계 구현 테스트	요구사항 분석 <┐  프로토타임 개발 │  프로토타입 평가 ┘ 구현 테스트	계획 및 정의 <┐      위험분석    │        개발        │     고객평가    ┘	분석 설계 구현 (병행개발)
이해 용이, 관리 편리	요구사항 용이, 타당성 검증	위험성 감소, 변경 유연 대처	일정 단축
요구사항 변경 어려움	프로토타입 폐기에 따른 비용 증가	단계多 관리 어려움	관리 비용 증가

 

 

소프트웨어 개발 방법론 종류

구조적 방법론	Structured Development	기능에 따라 나누워 개발 / 프로세스 중심 하향식 방법론 나씨-슈나이더만 차트 사용 (논리 기술 중점 도형식 표현)
정보공학 방법론	Information Engineering Development	정보시스템 개발 절차, 작업 기법 / 대형 프로젝트를 수행
객체 지향 방법론	Obejct-Oriented Development	객체를 기본단위로 / 객체,클래스,메시지 사용
컴포넌트 기반 방법론	CBD:Component Based Development	컴포넌트를 조립해서 개발 / 기간 단축 / 확장성 / 재사용
애자일 방법론	Agile Development	절차 < 사람 중심 / 유연하고 신속 적응 / 효율적
제품 계열 방법론	Product Line Development	영역 공학 / 응용 공학

 

 

애자일(Agile) 방법론

- 절차보다는 사람이 중신, 변화에 유연하고 신속하게 적응, 효율적 시스템을 개발, 신속 적응적 경량 개발 방법론

- XP, 린(LEAN), 스크럼(SCRUM)

 

 

XP의 5가지 가치 

용기 Courage	용기, 자신감 있게 개발 / 테스트, 피드백, 테스트 적격하지 못한 코드는 갈아엎을 용기
단순성 Simplicirty	필요한 것만 하라
의사소통 Communication	개발자, 관리자, 고객 원활한 소통 이게 되겠냐 PM이랑 맨날 싸우는데
피드백 Feedback	의사소통에 대한 빠른 피드백
존중 Respect	팀원 상호존중

 

 

XP의 12가지 기본원리

짝 프로그래밍 Pair Programming	개발자 둘이 짝짝쿵 개발	간단한 디자인 Simple Design	가장 단순한 시스템 설계
공동 코드 소유 Collective Ownership	누구나 수정 가능	테스트 기반 개발 TDD:Test Driven Develop	테스트 먼저 수행하고 테스트 통과 하도록 코드 작성
지속적인 통합 CI:Continuous Integration	매일 여러번 머지하고 빌드하고	리팩토링 Refactoring	기능 바뀌지 않으면서 중복제거, 단순화 재구성 원리
계획 세우기 Planning Process	고객 니즈 정의, 개발자 지연 언제든지 알린다	40시간 작업 40-Hour Work	일주일 40시간 이상 일하지 말게 이걸 국회로보내라
작은 릴리즈 Small Release	작게 만들고 짧은 단위 업데이트	고객 상주 On Site Customer	고객 풀타임 상주 어우싫어
메타포어 Metaphor	네이밍 체계, 서술서를 통해 클라이언트랑 소통 원할하게	코드 표준 Coding Standard	모든 코드 코딩 표준 정의

 

 

 

스크럼(SCRUM)

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

백로그 Backlog	제품, 프로젝트 요구사항
스프린트 Sprint	2~4주 개발 기간 딻게 반복 수행. 개발 질 향상
스크럼 미팅 Scrum Meeting	매일 15분 미팅 할일 정리 (=데일리 미팅)
스크럼 마스터 Scrum Master	프로젝트 리더, 문제 인지 및 해결하는 사람 욕받이
스프린트 회고 Sprint Retrospective	스프린트 끝나고 회고
번 다운 차트 Burn Down Chart	백로그 대비 시간 그래픽적 차트

 

 

 

---

객체 지향 분석(OOA : Object Oriented Analysis)

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

 

 

객체 지향 분석 방법론 종류

OOSE (Object Oriented Software Engineering)	야콥슨 (Jacobson)	유스케이스에 의한 접근 방법 /  분석,설계,구현 / 기능적 요구사항 중심
OMT (Object Modeling Technology)	럼바우 (Rumbaugh)	분석절차 객→동 →기 ◎ 객체 모델링 (Object Modeling) - 정보 모델링 (Information Modeling) 같은말 - 요구 객체 찾고, 관계 정의, ER 다이어그램 과정까지의 모델링 - 객체 다이어그램 ◎ 동적 모델링 (Dynamic Modeling) - 시간의 흐름따라 객체 사이 제어 흐름, 동작 순서 행위를 표현 - 상태 다이어그램 ◎ 기능 모델링 (Functional Modeling) - 자료 흐름을 중심으로 처리 - 자료 흐름도(DFD)
OOD ( Object Oriented Design)	부치 (Booch)	설계 문서화를 강조 / 분석과 설계 분리 불가능

 

 

 

비용산정 모형 분류

하향식 산정방법	전문가에게 의뢰, 전문가 합의법 전문가 판단, 델파이 기법
상향식 산정방법	요구사항, 기능에 따라 산정

 

 

 

비용산정 모형 종류

LoC 모형 (Lines of Code)	낙관치, 중간치, 비관치로 예측치를 구해 비용산정 측정, 이해가 쉽다 - 예=(낙+4중+비)/2
Man Month 모형	개발자 1명이 1개월 동안 할 수 있는 양을 기준으로 프로젝트 비용 산정 - MM = LoC/월생산성 - 프로젝트 기간 = MM/인력
COCOMO 모형 (Constructive Cost Model)	보헴이 제안, 프로그램 규모에따라 비용산정 ◎ 조직형 (=기본형, 단순형) Organic Model : 5만 이하 라인 ◎ 반 분리형 Semi-Detached Model : 30만 라인 이하 ◎ 임베디드형 Embedded Model : 30만 라인 이상
푸트남 모형 (Putnam)	개발주기의 단꼐별 요구할 인련의 분포를 가정 생명주기 예측 모형 /  랠리노드곡선의 노령 분포도를 기초
기능접수 모형 (FP:Function Point)	기능 가중치, 요인별 가중치 합상 - 기능점수 = 총 기능점수 x [0.65 + (0.1 x 총 영향도)]

 

 

 

일정관리 모델

주 공정법 CPM (Critical Path Method)	여러 작업 순서 얽힌 프로젝트 일정 계산 임계경로(Critical Path)는 시작-종료까지 가장 긴 시간
PERT (Program Evaluation and Review Technique)	비관치, 중간치, 낙관치의 3점 추정방식
중요 연쇄 프로젝트 관리 CCPM (Critical Chain Project Management)	자원 제약사항을 고려하여 일정 작성 기법

 

 

---

02. 현행 시스템 분석

소프트웨어 아키텍처 4+1 뷰

- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

 

유논프구배

유스케이스 뷰 Usecase View	다른 뷰를 검증 - 사용자, 설계자, 개발자, 테스트 관점
논리 뷰 Logical View	기능적인 요구사항 설명 - 설계자, 개발자 관점
프로세스 뷰 Process View	비기능적인 속성, 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등의 표현 - 개발자, 시스템 통합자 관점
구현 뷰 Implementation View	개발환경 정적인 소프트웨어 모듈의 구성 컴포넌트 구조와 의존성
배포 뷰 Deployment View	컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

 

소프트웨어 아키텍처 패턴

- SW T설계 시 참조할 수 있는 전형적인 해결 방식

 

소프트웨어 아키텍처 패턴 유형

계층화 패턴 (Layered Pattern)	각 하위 모듈들은 특정한 수준의 추상화 제공 각 계층 다음 상위 계층에 서비스 제공 서로 마두보는 두개 계층 사이에서만 상호작용
클라이언트-서버 패턴 (Client-Server Pattern)	하나의 서버와 다수의 클라이언트 서버는 계속 요청 대기
파이프-필터 패턴 (Pipe-Fillter Pattern)	데이터 스트림을 생성하고 처리하는 시스템에서 사용 서브 시스텝 입력받아 → 데이터 처리  → 결과를 다음 서브 시스템으로 넘겨줌 필터 컴포넌트는 재사용이 좋고 추가가 쉽다. 확장이 용이
브로커 패턴 (Broker Pattern)	분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 원격 서비스 실행을 통해 상호작용 가능 브로커 컴포넌트 :  컴포넌트 간 통신을 조정
MVC패던 (Model View Controller Pattern)	◎ 모델 : 핵심 기능과 데이터 보관 ◎ 뷰 : 사용자에게 정보 표시 ◎ 컨트롤러 : 사용자로부터 요청을 입력받아 처리 각 부분이 컴포넌트로 분리 서로 영향받지 X 코드 효율적인 재사용

 

 

 

소프트웨어 아키텍처 비용 평가 모델

- 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 적합성을 평가하는 모델

		SAAM
CBAM은 ATAM에서 부족한 경제성 평가를 보강		↓	ATAM은 SAAM을 계승하여 발전
CBAM	←→	ATAM	─┬─	ADR
			↓	ARID는 ATAM+ADR혼합
			ARID

 

SAAM (Software Architecture Analysis Method)	변경 용이성, 기능성에 집중, 평가 용이. 경험이 없는 조직에서도 활용
ATAM (Architecture Trade-off Analysis Method)	아키텍처 품질 속성을 만족시키는지 판단
CBAM (Cost Benefit Analysis Method)	ATAM바탕. 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델
ADR (Active Design Review)	응집도 평가 모델
ARID (Active Reviews for Intermediale Designs)	전체가아닌 특정 부분의 품질요소에 집중하는 비용 평가 모델

 

 

 

---

디자인 패턴

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

- 개발의 효율성과 유지보수성, 운용성이 높아지며 프로그램 최적화에 도움

 

 

디자인 패턴 유형

생구행

목적	생성	객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
	구조	더 큰 두조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
	행위	클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다르는 패턴
범위	클래스	클래스 간 관련성(상속 관계를 다루는 패턴). 컴파일 타임에 정적으로 결정
	객체	객체 간 관련성을 다루는 패턴. 런타임에 동적으로 결정

 

 

디자인 패턴의 종류

생 : 빌프팩앱싱

구 : 브데 퍼플 프록 컴어

행 : 미인이 템옵 스비커스 메체리

 

 

생성 패턴 생 : 빌프팩앱싱

빌더 Builder	객체 생성 / 객체 구현 방법을 분리 동일한 생성에 다른 표현 결과를 만듬 생성과 표기를 분리해서 복잡한 객체를 생성
프로토타입 Prototype	원형을 만들어 놓고 그것을 복사, 필요한 부분만 수정하여 사용 기존 객체를 복제함으로써 객체를 생성
팩토리 메서드 Factory Method	상위 클래스에서 객체 생성 인터페이스 정의 하위 클래스에서 인스턴스를 생성 상위 클래스에서 인스턴스를 만드는 방법만 결정 하위 클래스에서 데이터의 생성을 책임이조 조작 함수를 오버라이딩 생성할 객체의 클래스 국한 x 객체 생성
앱스트랙 팩토리 Abstract Factory	구체적 클래스 의존x 서로 연관, 의존적 객체들의 조합을 만드는 인터페이스 제공 동일한 주제의 다른 팩토리를 묶음
싱글톤 Singleton	전역 변수 사용x 객체 하나만 생성 한 클래스 한객체만 존재하도록 제한

 

 

구조 패턴 구 : 브데 퍼플 프록 컴어

브릿지 Bridge	기능-구현 클래스 계층을 연결 구현부에서 추상 계층을 분리 추상화된 부분과 실제 구현 부분을 독립적으로 확장
데코레이터 Decorator	기존 클래스에 필요한 기능 추가 기능을 동적으로 유연하게 확장, 상속의 대안으로 사용
퍼사이드 Facade = 건물정면	복잡한 시스템(건물) 단순한 인터페이스(정면/정문)을 두어 사용자-시스템간 결합도를 낮춤. 시스템 구조 파악 쉽고 오류 단위별 확인 가능 사용자 측면 단순한 인터페이스. 접근성 높임.
플라이웨이트 Flyweight	다수 객체의 공통적 요소를 클래스화하여 공유 메모리 절약 /  클래스 경량화
프록시 Proxy	실체 객체에 대한 대리 객체 실체 객체 접근 이전 행동을 취할 수 있게 함 메모라 용량 아낌, 실체 객체는 정보은닉 특정 객체로 접근 제어위한 용도로 사용
컴포지트 Composite = 합성	객체 관계를 트리구조로 구성 부분-전체 계층을 표현 사용자가 복합 객체와 단일 객체를 동일하게 취급
어댑터 Adatper	기존 생성 클래스를 재사용하도록 중간에 맞춰주는 역할 인터페이스를 만듬 상속을 이용한 클래스 패턴 / 위임을 이용한 인스턴스 패턴 두가지 형태로 사용 인터페이스 호환x 인 클래스를 이용할 수 있도록 함

 

 

행위 패턴 행 : 미인이 템옵 스비커스 메체리

미디에이터 Mediator = 중재인	상호작용의 유연한 변경을 지원 객체 수가 너무 많아 복잡해지는것을 해결하기위해 중재자가 통제, 지시, 요구를 받아 통신 빈도수를 줄여 느슨한 결합 목표
인터프리터 Interpreter = 통역사	문법 자체를 캡슐화 하여 사용 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만듬
이터레이터 Iterator = 반복자	내부구조 노출x 그 안에 모든 항목에 접근할 방법을 제공 순차적으로 접근 가능하게 해주는 패턴
템플릿 메소드 Template Method	상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행 전체 수행 구조는 냅두고 특정 단계만 바꿈 상위 클래스 추상 메서드를 통해 기능 골격 제공 하위 클래스 메서드에서는 세부 처리를 구채화해 유지보수 편의성
옵저버 Observer = 관찰자	한 객체 상태가 바뀌면 의존된 가른 객체에 연락가서 자동 내용 갱신 일대 다의 의존성
스테이트 State	객차의 상태에따라 행위 내용을 변경 객체 상태를 캡슐화 클래스화함 그걸 참조하게하는 방식 상태에따라 다르게 처리할 수있도록 행위 내용 변경. 원시코드 수정 최소화
비지터 Visitor	각 클래스 데이터구조로부터 처리기능 분리, 별도 클래스를 만들어 놓고  해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴 복합 객체의 원소 특성에 따라 동작 수행할 수 있도록 지원
커맨드 Command	명령어를 객체로 캡슐화 기능을 캡슐화해서 주어진 여러 기능을 실행할 수 있는 재사용 높은 클래스를 설계하는 패턴
스트레티지 Strategy = 계획 전략	알고리즘을 각각 하나의 클래스로 캡슐화한 다음 필요할때만 서로 교환 행위 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴
메멘토 Memento = 기념품	객체를 이전 상태로 복구해야할 때 (객체 정보를 저장)
체인 오브 리스판서빌리티 Chain of Responsibility	한 요청을 2개 이상의 객체에서 처리 어떤 기능 처리 연결이 하드코딩일 때 동적으로 연결되는 경우에따라 다르게 처리하도록 연결

 

 

 

---

OSI 7계층

- 네트워크 통신에서 생긴 여러 가지 충돌 문제를 완화하기 위해 국제 표준화 기구에서 제시한 네트워크 기본 모델

응표세전네데물

계층	TCP/IP 계층	장비	전송단위	프로토콜	설명
응용 계층 Application Layer	응용	-	데이터 Data	(TCP) HTTP, HTTPS, FTP	사용자 - 네트워크 응용 서비스 연결, 데이터 생성
표현 계층 Presentation Layer				JPEG, MPEG	데이터 형식 설정, 부호교환, 암복호화, 압축
세션 계층 Session Layer				(TCP) SSH, TELNET, TLS (UDP) DNS, SIMP, DHCP	연결 접속 및 동기제어
전송 계층 Transport Layer	전송	-	세그먼트 Segment	TCP : 연결지향 UDP : 비연결형	신뢰성 있는 통신 보장 데이터 분할과 재조립, 흐름제어, 오류제어, 혼잡제어 담당
네트워크 계층 Network Layer	인터넷	라우터	패킷 Packet	IP, ICMP, ARP(IP→MAC), RARP (MAC→ IP)	단순 빠르게 단말기 간 데이터 전송을 위한 최적화된 경로제공 비연결성, 비신뢰성
데이터링크 계층 Data Link Layer		스위치, 브릿지	프레임 Frame	이더넷	인접 시스템 간 데이터 전송, 전송오류 제어 오류 검출, 재전송 기능제공
물리 계층 Physical Layer	네크워크 액세스	NIC, 허브, 리피터	비트 Bit	RC-232C	0과 1의 비트 회선에 보내기 위한 전기적 신호 변환

 

 

 

 

---

03. 요구사항 확인

요구공학

- 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

 

요구사항 개발 단계 구성

도분명확

도출 Elicitation	분석 Analysis	명세 Specification	확인 Validation
요구사항 소스 도출 기법	요구사항 분류 개념 모델링 기술구조 설계 및 요구사항 할당 요구사항 협상	시스템 정의서 시스템 요구사항 명세서 소프트웨어 요구사항 명세서	검토 프로토타이핑 모델 검증 인수 테스트

 

 

요구사항 도출 단계 기법

인터뷰 (Interview)	직접 대화. 공식적, 비공식적 정보 수집 방법
브레인스토밍 (Brainstorming)	말을 꺼내기 쉬운 분위기로 내놓은 아이디어 수용
델파이 기법 (Delphi Method)	전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
롤 플레잉 (Role Platying)	맡은 역 연기해서 요구사항 분석, 수집
워크숍 (Workshop)	단기간 집중적인 노력. 핵심인물 참여 필요. 사전 준비 요구
설문 조사 (Survey)	설문지 및 여론조사 간접적 정보 수집 방법. 사용자가 다수일 때 의견수림 용이

 

 

요구사항 분석 단계 기법

자료 흐름 지향 분석	데이터 흐름도(DFD) 및 자료 사전(DD)으로부터 소프트웨어 구조를 유도하는 방법
객체 지향 분석	시스템의 기능과 데이터를 함께 분석, UML로 표준화

 

 

요구사항 명세 단계 기법

비정형 명세 기법	사용자 요구 표현 시 자연어 기반으로 서술 사용자, 개발자 이해가 용이 명확성 및 검증에 문제
정형 명세 기법	수학적인 원리와 표기법으로 서술하는 기법 Z-스키마, Petri Nets, 상태차트 활용 표현 간결, 명확성 검증 용이 기법 이해가 어려움

 

 

요구사항 확인 및 검증 단계의 주요 기법

요구사항 검토		요구사항 명세서 완성 시점에서 검토. 여러 검토자들이 검토
정형 기술 검토 활용	동료 검토 (Peer Review)	2~3명이 진행하는 리뷰 형태 명세서 작성자가 설명, 설명듣고 결함 찾기
	워크 스루 (Walk Through)	오류 조기 검출 목적 검토 자료 회의 전 배포, 사전검토상태에서 짧은 회의로 리뷰
	인스펙션 (Inspection)	다른 전문가 팀이 검사하여 오류를 찾는 공식적 검토 방법
프로토타이핑 활용		주요 기능 및 일부분 개발, 시연하면서 작동 경험을 보면서 요구사항 확인
모델 검증		분석단계에서 개발된 모델 품질 검증 필요 정적 분석 수행에 용이
테이트 케이스 및 테스트를 통한 확인		요구사항 만족 계획하고 테스트 케이스 작성 단계, 인수테스트에서 활용
CASE 도구 활용 검증		자동화된 일관성 분석을 제공하는 CASE도구 활용 대규모 프로젝트 프로젝트에서 이용
베이스라인을 통한 검증		요구사항 변경 체계적 추적, 통제 시점인 베이스라인을 통해 지속적 검증 수행
요구사항 추적표(RTM)를 통한 검증		요구사항 정의서를 기준으로 개발단계 별 최종 산출물이 어떻게 변경,반영되었는지 확인 가능한 문서

* CASE (Computer - Aided Software Engineering) 분석 자동화 도구

 

 

 

---

04. 분석 모델 확인하기

분석 모델 검증

- 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해서 확인하는 활동

 

분석 모델 검증 방법

- 유스케이스 모델 검증

- 개념 수준의 분석 클래스 검증

- 분석 클래스 검증