정보처리 기사를 공부하며 공부한 요약본을 블로그에 올리려고 합니다.
1. 요구사항 확인
1) 소프트웨어 개발 방법론
1. 소프트웨어 생명주기(SDLC) 모델
개념
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차프로세스
1) 요구사항 분석
다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여
새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
-기능 요구사항
-비기능 요구사항2) 설계
시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록
수행 방법을 논리적으로 결정하는 단계
-시스템 구조 설계
-프로그램 설계
-사용자 인터페이스 설계3) 구현
설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍
언어를 사용하여 실제 프로그램을 작성하는 단계
-인터페이스 개발
-자료구조 개발
-오류 처리4) 테스트
시스템이 정해진 요구를 만족하는 지, 예상과 실제 결과가 어떤 차이를
보이는 지 검사하고 평가하는 단계
-단위 테스트
-통합 테스트
-시스템 테스트
-인수테스트5) 유지보수
시스템이 인수되고 설치된 후 일어나는 모든 활동
- 예방, 완전, 교정, 적응, 유지보수종류 (폭프나반)
- 폭포수 모델 (Waterfall Model)
소프트웨어 개발시 각 단계를 확실히 마무리 지은 후에 다음으로 넘어가는 모델- 프로토타이핑 모델(prototyping Model)
고객이 요구한 주요기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델- 나선형 모델(Spiral Model)
시스템 개발 시 위험 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해나가는 모델
- 절차 : 계획 및 정의 > 위험 분석 > 개발 > 고백 평가
- 반복적 모델 (Iteration Model)
구축대상을 나눈어 병렬적으로 개발 후 통합하거나 반복적으로 개발하여
점증 완성시키는 모델
2. 소프트웨어 개발 방법론
- 개념
소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법,절차,기법
- 종류
- 구조적 방법론(Structured Development)
전체 시스템을 기능에 따라 나누어 개발하고,이를 통합하는 분할과
정복 접근 방식의 방법론
하향식 방법론, 나씨-슈나이더만 차트 사용한다.
- 정보공학 방법론(Information Engineering Development)
정보 시스템 개발에 필요한 관리 절차와 작업기법을 체계화한 방법론
- 객체 지향 방법론(Object-Oriented Development)
'객체'라는 기본단위로 시스템을 분석 및 설계하는 방법론
객체, 클래스, 메세지를 사용
- 컴포넌트 기반 방법론(CBD; Component Based Development)
소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 응용 프로그램을 작성하는 방법론
- 애자일 방법론(Agile Development)
절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서
효율적으로 시스템을 개발 할 수 있는 신속 적응적 경량 개발 방법론
- 제품 계열 방법론(Product Line Development)
특정제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
영역공학, 응용공학
애자일(Agile)
절차보단 사람 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을
개발할 수 있는 개발 방법론
개발 기간이 짧고 신속
워터폴에 대비되는 방법론
개발과 함께 즉시 피드백받아 유동적으로 개발 가능하다.
유형
XP(extreme Programming)
의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 가치
용기(Courage)
단순성(Simplicity)
의사소통(Communication)
피드백(Feedback)
존중(Respect)
- 12가지 기본원리
1) 짝 프로그래밍(Pair Programming)
개발자 둘이서 짝으로 코딩하는 원리
2) 공동 코드 소유(Collective Ownership)
시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
3) 지속적인 통합(CI; Continuous Integration)
매일 여러번씩 소프트웨어를 통합하고 빌드해야한다는 원리
4) 계획 세우기(Planning Process)
고객이 요구하는 비즈니스 가치 정의,개발자가 필요한 것을 무엇이며,
어떤 부분에서 지연될 수 있는지를 알려주어야한다는 원리
5) 작은 릴리즈(small Release)
작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다는 원리
6) 메타포어(metaphor)
공통적인 이름 체계와 시슽메 서술서를 통해 고객과 개발자 간의 의사소통을
원활하게 한다는 원리
7) 간단한 디자인(Simple Design)
현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
8) 테스트 기반 개발(TDD;Test Driven Development)
작성해야하는 프로그램에 대한 테스트를 먼저 수행하고,
이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
9) 리팩토링(Refactoring)
프로그램의 기능을 바꾸지 않으면서 중복제거,단순화 등을 위해
시스템을 재구성한다는 원리
10) 40시간 작업(40-Hour Work)
개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상은
일 하지 말아야 한다는 원리
11) 고객 상주(on site Customer)
개발자들의 질문을 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀 타임으로
상주 시켜야한다는 원리
12) 코드 표준(Coding Standard)
효과적인 공동작업을 위해서는 모든 코드에 대한 코딩 표준을
정의해야 한다는 원리스크럼(SCRUM)
매일 정해진 시간,장소에서 짧은 시간의 개발을 하는 팀을 위한
프로젝트 관리 중심 방법론
백로그를 나눈 후에 스크럼 팀을 구성하고 스프린트 회의를 거쳐 2~4주 단위의
스프린트를 수행
수행 중 매일 스크럼 미팅을 수행하고, 스프린트가 끝난 후에는 스프린트 회고를 수행
- 백로그(Backlog)
제품과 프로젝트에 대한 요구사항
- 스프린트(Sprint)
2~4주의 짧은 개발 기간으로 반복적 수행으로 개발 품질 향상
- 스크럼 미팅(Scrum Meeting)
매일 15분 미팅으로 TO-DO LIST 계획 수립
데일리 미팅(Daily Meeting)이라고도 함
- 스크럼 마스터(Scrum Master)
프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
- 스프린트 회고(Sprint Retrospective)
스프린트 주기를 되돌아보며 정해 놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
- 번 다운 차트(Burn Down Chart)
남아 있는백로그 대비 시간을 그래픽적으로 표현한 차트
린(LEAN)
도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
7가지 원칙
낭비제거, 품질 내재화, 지식창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
3. 객체 지향 분석 방법론
- 개념
개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법- 구성요소
- 클래스(class)
특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀
- 객체(Object)
물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상- 메서드(Method)
클래스로 부터 생성된 객체를 사용하는 방법
연산- 메세지(Message)
객체 간 상호작용을 하기 위한 수단
객체<->객체- 인스턴스(Instance)
객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체- 속성(Property)
한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들으 단위별로 정의- 객체 지향 기법
- 캡슐화(Encapsulation)
서로 연관된 데이터와 함수를 묶어 외부와 경계를 만들고 필요한 인터페이스만
밖으로 드러내는 기법- 상속성(Inheritance)
상위 클래스의 속성과 메서드를 하위클래스에서 재정의 없이 물려 받아 사용하는 기법- 다형성(Polymorphism)
상속받은 여러개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
- 오버로딩(overloading)
매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러개 가지는 기법
매개변수- 오버라이딩(overriding)
상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서
무시하고 재정의할 수 있는 기법
내용 변경(구현 재정의)- 추상화(Abstraction)
공통 성질을 추출하여 추상 클래스를 설정하는 기법- 정보은닉(Information Hiding)
코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만
접근이 가능하도록 하는 코드 보안 기술- 관계성(Relationship)
데이터를 참조하는 관계를 나타내는 기법
- 연관화
-is - member-of 관계
-클래스와 객체의 참조 및 이용관계
참조 의존성
- 집단화
-is-part-of 관계 , part-whole 관계
-서로 관련있는 여러개의 객체를 묶어 한 개의 상위 객체를 만드는 특징이 있다.
상속X
- 분류화
-is-instance-of 관계
-공통된 속성에 의해 정의된 객체 구성원들의 인스턴스
- 일반화
-is-a관계
-상위클래스의 특성을 하위클래스가 상속받음
상속O
- 특수화
-is-a 관계
-상위 클래스의 특성들을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고
자기 자신의 고유한 특성을 갖는 관계
상속O,수정 O, 고유특성 O
- 객체 지향 설계 원칙(SOLID)
- 원칙
- 단일 책임의 원칙(SRP;single Responsibility Principle)
하나의 클래스는 하나의 목적을 위해서 생성되며,클래스가 제공하는
모든 클래스는 하나의 책임을 수행하는 데 집중 되어 있어야 한다는 원칙
1개 1목적
5 원칙 중 나머지 4원칙의 기초 원칙- 개방 폐쇠의 원칙(OCP; Open Close Principle)
소프트웨어의 구성 요소는 확장에는 열려있고, 변경에는 닫혀 있어야한다는 원칙
확장은 열고,변경엔 닫고- 리스코프 치환의 원칙(LSP;Liskov Substitution Principle)
서브 타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙
상위클래스로 교체- 인터페이스 분리의 원칙(ISP;Interface Segregation Principle)
한 클래스는 자신이 사용하지 않은 인터페이스는 구현하지 말아야 한다는 원칙
그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙- 의존성 역전의 원칙(DIP; Dependency Inversion Principle)
실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써
관계를 최대한 느슨하게 만드는 원칙- 객체 지향 분석 방법론 종류
- 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)
설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
분석과 설계의 분리가 불 가능- 코드-요든 (Coad - Yourdon)
E-R 다이어그램 사용- 워프- 브록(Wirfs - Brock)
분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지
연속적으로 수행하는 분석 방법2) 프로젝트 관리
1. 비용 산정 모형
- 분류
하향식 산정 방법
경험이 많은 전문자에게 비용산정을 의뢰하거나 여러 전문가와
조정자를 통해 산정하는 방식
- 종류
전문가 판단
델파이 기법(Delphi Method)
ㄴ 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
전문가 합의법
상향식 산정 방법
세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식- 종류
코드라인수 (Loc)
Man Month
CoCoMo 모형
푸트남 모형
기능점수(FP) 모형- 종류
1. LOC(Lines of Code) 모형
소프트웨어 각 기능의 원시코드 라인수의 낙관치, 중간 치, 비관치를 측정하여
예측치를 구하고 이를 이용하여 비용을 산정하는 방식
측정이 쉽고 이해하기 쉬워 많이 사용한다.
예측치 이용해 생산성, 노력, 개발 기간 등의 비용 산정적+4(평균)+많/6예측치 = 비관치 + 4(중간치) + 비관치 / 6 비관치: 가장 많이 측정된 코드 라인 수 중간치: 측정된 모든 코드 라인 수의 평균 낙관치: 가장 적게 측정된 코드라인 수
2. Man Month 모형
한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식3. COCOMO(Constructive COst Model) 모형Man Month = (LOC) / 프로그래머의 월간 생산성 프로젝트 기간 = Man Month / 프로젝트 인력 Man Month: 한 사람이 프로젝트를 할 때 걸리는 시간 LOC : Line of Code
보헴(Boehm)이 제안한 모형
프로젝트 규모에 따라 비용을 산정하는 방식
비용 산전 결과는 프로젝트를 완성하는 데 필요한 노력(Man- Month) 으로 산정
규모에 따라 유형이 나뉜다.- 유형
- 조직형(Organic Model)
소규모의 소프트웨어
5만(50KDSI)라인 이하의 소프트웨어 개발하는 유형- 반 분리형(semi-Detached Model)
단순형과 임베디드형의 중간형
30만(300kDSI)라인 이하의 소프트웨어 개발하는 유형
유틸 개발에 적용- 임베디드형(Embedded Model)
초대형 규모의 시스템 개발에 적용
30만(300KDSI)라인 이상의 소프트웨어 개발하는 유형
4. 푸트남(Putnam)모형
소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
푸트남이 제안, 생명 주기 예측 모형
곡선의 노력 분포도를 기초(Rayleigh-Norden)
5. 기능 점수(FP; Function Point) 모형FP = 총 기능점수 * [0.65 + (0.1 * 총 영향도)]
2. 일정 관리 모델
일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
- 종류
- 주 공정법(PM; Critical Path Method)
여러 작업의 수행 순서가 얽혀 있는 프로젝트 일정 계산하는 기법
제약 사항 배제한 채로 프로젝트 시작과 끝을 나타내는 노드(Node)와 노드 간을
연결을 통해 공정을 계산 하기 위한 액티비티(Activity) 표기법
가장 긴 시간 경로, 노드-노드- PERT (Program Evaluation and Review Technique)
일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치,중간치, 낙관치의
3점 추정 방식을 통해 일정을 관리하는 기법
추정 방식- 중요 연쇄 프로젝트 관리(CCPm; Critical Chain Project management)
주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
제약 사항 고려
CPM을 이용해 일정 계산
프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로(임계경로)를 계산
