[정보처리기사 실기] 1. 소프트웨어 개발 방법론

 

 

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

- 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

- 시스템이 개발될 떄부터 운용 유지보수를 거쳐 생애를 마칠때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화 한것.

 

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

1. 요구사항분석 :

- 요구사항을 고려하여 새로운 제품 혹은 변경된 제품에 부합하는 요구와 조건을 결정하는 단계

- 개발할 소프트웨어의 기능과 제약조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계

2. 설계:

- 시스템 명세 단계에서 정의한 기능을 실제 수행할수 있도록 수행방법을 논리적으로 결정하는 단계

3. 구현:

- 설계 단계에서 논리적으로 결정한 문제해결 방법을 특정한 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계

- 프로그래밍 언어 선택, 기법, 스타일, 순서등을 결정

4. 테스트 :

시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계

5. 유지보수 :

시스템이 인수되고 설치 된 후 일어나는 모든 활동

 

소프트웨어 생명주기 모델

소프트웨어 생명주기 모델 종류로는 폭포수 모델, 프로토 타이핑 모델, 나선형 모델, 반복적 모델이 있다.

종류	설명
폭포수 모델  (Waterfall Model)	소프트웨어 개발 시 단계를 확실히 마무리 지은 후 다음단계로 넘어가는 모델 가장 오래된 모델  선형 순차적 모형으로 고전적 생명주기 모델이라고 함 모형의 적용 경험과 성공 사례가 많음 단계별 정의와 산출물이 명확 요구사항 변경이 어렵다. 절차 :타당성 검토 -> 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트-> 유지보수
프로토타이핑 모델 (Prototyping Model)	고객이 요구한 주요기능을 프로토 타입으로 구현하여 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 프로토 타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공 프로토타입은 구현 단계의 구현 골격
나선형 모델 (Spiral Model)	시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 절차 : 계획 및 정의 -> 위험분석 -> 개발 - > 고객 평가
반복적 모델 (Iteration Model)	구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC모델 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델

---

소프트웨어 개발 방법론 

- 소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할수 있는 방법,절차,기법

- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론

 

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

소프트웨어 개발 방법론의 종류로는 구조적 방법론, 정보공학 방법론, 객체 지향 방법론, 컴포넌트 기반 방법론(CBD),에자일 방법론,제품 계열 방법론이 있다.

 

구조적 방법론 (Structed Development)

전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론

프로세스 중심의 하향식 방법론

구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용

 

나씨 슈나이더만 차트 특징

논리의 기술에 중점을 둔 도형식 표현 방법

연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현

조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합하다.

정보공학 방법론 (Information Engineering Development)

정보시스템 개발에 필요한 관리절차와 작업기반을 체계화한 방법론

개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

 

객체 지향 방법론 (Object-Oriented Development)

'객체' 라는 기본 단위로 시스템을 분석 및 설계하는 방법론

복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론

객체, 클래스, 메세지를 사용

 

컴포넌트 기반 방법론 (CBD; Component Based Development)

소프트웨어를 구성하는 컴포넌트를 조립하여 하나의 새로운 응용 프로그램을 작성하는 방법론

개발 기간 단축으로 인한 생산성 향상

새로운 기능의 추가가 쉬움(확장성)

소프트웨어 재사용이 가능

 

애자일 방법론 (Agile Development)

절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할수 있는 신속 적응적 경량 개발 방법론

애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

 

제품 계열 방법론 (Product Line Development)

특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

임베디드 소프트웨어를 작성하는데 유용한 방법론

영역 공학과 응용 공학으로 구분된다.

 

영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역

응용 공학: 제품 요구분석, 제품 설계, 제품을 구현하는 영역

---

애자일(Agile)

애자일 방법론의 개념

애자일 방법론은 절차보다 사람이 중심이되어 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발하는 신속 적응적 경량 개발 방법론이며 개발 기간이 짧고, 신속하며 폭포수 모형에 대비되는 방법론으로 개발과 함께 피드백을 받아서 유동적인 개발이 가능하다.

 

애자일 방법론 등장 배경

애자일 방법론은 기존 개발 방법론의 한계를 극복하기 위해 등장

 

소프트웨어 개발 환경의 변화

- 소프트웨어 개발 트렌드가 모바일 환경으로 변화, 시장 적시성과 잦은 배포의 중요성 부각

기존 개발 방법론의 한계

- 전통적 방법론은 문서 및 절차위주로 변화에 신속한 대응이 어렵다. 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성이 증가

 

애자일 방법론의 유형

애자일 방법론은 대표적으로 XP, 린(Lean), 스크럼(SCRUM)등이 있다.

 

XP

의사소통 개선과 즉각적인 피드백으로 소프트웨어 품질을 높이기 위한 방법론

1~3주의 반복(Iteration)주기

5가지의 가치와 12개의 실천항목이 존재

 

XP의 5가지 가치

용기

용기를 가지고 자신감있게 개발 (코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링 할 수 있는 용기)

단순성

필요한것만 하고 그 이상의 것은 하지 않음

의사소통

개발자,관리자, 고객간의 원할한 소통

피드백 

의사소통에 대한 빠른 피드백

존중

팀원간의 상호 존중

 

XP의 12가지 원리

짝 프로그래밍(Pair Programming) : 개발자 둘이서 짝으로 코딩하는 원리

공동 코드 소유 (Collective Ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리

지속적인 통합 (CI : Continuous Integration) : 매일 여러번 씩 소프트웨어를 통합하고 빌드해야한다는 원리

계획 세우기 (Planning Process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한것은 무엇이며 어떤부분에서 지연될 수 있는지를 알려주어야 한다는 원리

작은 릴리즈(Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다는 원리

메타포어 (Metaphor) : 공통적인 이름체계와 시스템 서술서를 통해 고객과 개발자간 의사소통을 원활하게 한다는 원리

간단한 디자인 (Simple Design) : 현재의 요구사항에 가장 적합한 가장 단순한 시스템을  설계한다는 원리

테스트 기반 개발 (TDD : Test Driven Development) : 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할수 있도록 실제 프로그램의 코드를 작성한다느 원리

리팩토링(Refactoring) : 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성한다는 원리

40시간 작업(40-Hour Work): 개발자가 피곤으로 실수하지 않도록 일주일에 40시간 이상 일하지 말아야 한다는 원리

고객 상주 (On Site Customer) : 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을  프로젝트에 풀타임으로 상주시켜야 한다는 원리

코드 표준(Coding Standard) : 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

 

스크럼(SCRUM)

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

백로그 (Backlog) : 제품과 프로젝트에 대한 요구사항

스프린트(Sprint) : 2~4주간의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상

스크럼 미팅 (Scrum Meeting): 매일 15분 정도 미팅으로 To-Do List 계획 수립, 데일리 미팅(Daily Meeting)이라고도 함

스크럼 마스터(Scrum Master): 프로젝트 리더, 스크롬 수행 시 문제를 인지 및 해결하는 사람

스프린트 회고(Sprint Retospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록

해당 스프린트가 끝난 시점이나 일정 주기로 시행

번 다운  차트 ( Burn Down Chart) : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트, 백로그는 보통 수직축에 위치하며 시간을 수평축에 위치

 

린(LEAN)

도요타의 린 시스템 품질기법을  소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

JIT(Jut In Time), 칸반 (Kanban)보드 사용

7가지 원칙

낭비제거, 품질 내재화, 지식 창출, 늦은  확정, 빠른 인도, 사람 존중, 전체 최적화

 

 

---

객체 지향 개념

객체지향은 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법

 

객체지향 구성요소

클래스, 객체, 메서드, 메세지, 인스턴스, 속성

 

객체지향 기법

캡슐화(Encapsulation) ,상속성(Inheritance),다형성(Polymorphism),추상화(Abstraction),정보은닉(Information Hiding),관계성(Relationship)

 

객체 지향 설계 원칙(SOLID)

단일 책임의 원칙(SRP), 개방 폐쇄 원칙(OCP), 리스코프 치환의 원칙(LSP), 인터페이스 분리의 원칙(ISP),의존성 역전의 원칙(DIP)

 

객체 지향 분석의 개념

객체 지향 분석 (OOA; Obejct Oriented Analysis)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법이다.

 

객체 지향 분석 방법론 종류

OOSE(Object Oriented Software Engineering): 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용

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

객체모델링,동적모델링,기능모델링이 존재한다.

OOD(Object Oriented Design) : 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론

코드 요든(Coad-Yourdon)방법론 : E-R 다이어그램을 사용하여 객체의 행위를 모델링, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법

워프 브록(Wirfs-Brocks)방법론: 분석과 설계간의 구분이 없고 고객명세서를 평가하여 설계 작업까지 연속적으로 수행하는 분석 방법

 

기능 모델링 주요 기법

데이터흐름도

데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림, 시스템 분석과 설계에서 유용하게 사용되는 다이어그램

자료 흐름 그래프 또는 버블(Bubble) 차트라고도 한다.

데이터 흐름도 특징

구조적 분석 기법에 사용, 데이터의 흐름에 중심을 두는 분석용 도구 , 제어의 흐름은 중요하지않다. 시간의 흐름을 명확하게 표현 불가능

 

자료 사전

자료사전(DD, Data Dictionary 개념)

자료 사전은 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전.

자료사전은 파일 혹은 데이터 베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이 그리고 서술과 같은 데이터를 포함하는 참조를 위한 작업이다.

 

자료사전 작성 목적

자료 사전은 조직에 속해 있는 사람들에게 특정한 자료 용어가 무엇을 의미하는지 알려주기 위함, 용어의 정의를 조정하고 취합하고 문서로 명확하게 하는데 목적이 있다. 자료 흐름도에 나타나는 어떤 자료의 흐름도 자료 사전에 정의되어 있어야 한다.

 

---

프로젝트 관리

프로젝트 관리의 개념

프로젝트 관리는 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동이다.

프로젝트 관리는 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등의 작업을 통제하는것으로 소프트웨어 생명 주기의 전 과정에 걸쳐서 진행, 소프트웨어 프로젝트를 성공적으로 수행하기 위해서 수행할 작업의 범위, 필요한 자원, 수행 업무, 비용, 추진 일정들을 관리해야한다.

 

프로젝트 관리 대상

프로젝트 관리 대상에는 계획 관리, 품질 관리, 범위 관리 등이 있다

계획관리 : 프로젝트 계획, 비용, 일정, 조직 에 대한 관리

품질관리 : 품질통제 및 품질 보증

범위관리 : 이해관계자가 요청한 모든 요구사항이 프로젝트 범위에 포함되었는지 보장하고, 필요한 작업만 수행될수 있도록 관리

 

프로젝트 관리 3대요소

효과적인 프로젝트 관리를 위한 3대요소(3P)는 사람, 문제, 프로세스 이다

사람(People) : 프로젝트 관리에서 가장 기본이 되는 인적 자원

문제(Problem) : 사용자의 입장에서 문제를 분석하여 인식함

프로세스(Process) : 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조(Framework)

 

비용산정 모형

비용산정 모형은 소프트웨어 규모파악을 위한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식

 

비용산정 모형 분류

하향식 산정방법과 상향식 산정방법이 존재

 

하향식 산정방법 : 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식 (전문가 판단,델파이 기법)

상향식 산정방법: 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식 (코드라인수:Loc,Man Month,COCOMO 모형,푸트남,기능점수FP 모형)

 

비용산정 모형 종류

LoC(Lines of Code) 모형

LoC 모형은 소프트웨어 각 기능의 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식

측정이 쉽고 이해하기 쉬워 많이 사용한다, 예측치를 이용하여 생산성,노력, 개발기간 등의 비용을 산정한다.

 

예측치 : o + 4m + p / 6 ( o:낙관치, m:중간치, p: 비관치)

비관치 : 가장 많이 측정된 코드 라인 수

중간치: 측정된 모든 코드 라인 수의 평균

낙관치 : 가장 적게 측정된 코드 라인  수

 

Man Month 모형

Man Month 모형은 한 사람이 1개월 동안 할수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식

(Man Month) = (Loc) / 프로그래머의 월간 생산성

(프로젝트 기간) =  (Man Month) / 프로젝트 인력

 

COCOMO(Constructive Cost Model) 모형

보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식이다

비용산정 결과는 프로젝트를 완성하는데 필요한 노력(Man-Month)로 산정한다.

비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용된다

규모에 따라 유형이 조직형( = 기본형, 단순형), 반 분리형, 임베디드형으로 나뉜다.

 

COCOMO 소프트웨어 개발 유형

조직형 (Organic Mode) : 기관 내부에서 개발된 중,소규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료처리 개발에 적용 , 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형

반 분리형 (Semi-Detached Mode) : 단순형과 임베디드의 중간형, 트랜잭션 처리 시스템이나, 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용, 30민(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형

임베디드형 (Embedded Mode) : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용, 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형

 

푸트남(Putnam) 모형

푸트남 모형은 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식

푸트남이 제안한 것으로 생명주기 예측 모형이라고 한다. 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.

 

기능점수(FP; Function Point)모형

기능점수 모형은 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식

 

기능점수(FP) = 총 기능점수 x [0.65 + (0.1 x 총 영향도 )]

경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다.

 

일정관리 모델

일정 관리 모델 개념

일정관리 모델은 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델이다

 

일정관리 모델 종류

주 공정법, PERT, 중요 연쇄 프로젝트 관리가 있다

 

주 공정법 : 여러 작업의 수행순서가 얽혀있는 프로젝트의 일정을 계산하는 기법, 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드(Node)와 노드간의 연결을 통해 공정을 계산하기 위한 액티비티(Activity) 표기법

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

중요 연쇄 프로젝트 관리: (CCPM; Critical Chain Project Management) : 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성

 

위험관리(Risk Management) 개념

위험 관리는 프로젝트에 내재된 위험 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동

위험 관리는 프로젝트를 성공시키기 위하여 위험요소를 사전에 예측, 대비 하는 모든 기술과 활동을 포함한다

 

위험의 종류

소프트웨어 개발 시 나타나는 일반적인 위험 요소에는 인력부족, 예산관리, 일정관리, 사용자 요구사항 변경 등이 있으며 , 이중 가장 대표적인 위험 요소는 사용자 요구사항 변경이다.

위험의 종류에는 알려진 위험, 예측 가능한 위험, 예측 불가능한 위험 이 있다.

 

위험 대응 전략

회피(Avoidance) : 발생 가능성을 원천적으로 제거하는 전략

전가(Transference) : 위험에 대한 책임을 제3자에게 넘기는 전략

완화(Mitigation) : 위험 발생 가능성을 감소시키거나 영향력을 감소시키는 전략

수용(Acceptance) : 위험을 그대로 받아들이는 전략

 

 

 

 

 

 

 

느낀점:

1회차 가볍게 전체 내용을 읽으며 정리하고 자세한 정리는 이어서 추가하는 방식으로 변경해야겠다 일주일안에 1회독을 하려고 계획을 잡았는데 자세한 내용을 적어가면서 정리하려니 시간상 도저히 맞출수없을거같다. 2회독부터 1회독 내용부분에 추가하며 정리를 추가하도록 하려고 한다.