[정보처리기사] 소프트웨어 개발 방법론 활용 ( 정리, 공부 )

소프트웨어 개발 방법론

소프트웨어 개발 방법론

1) 개요

• 소프트웨어 개발, 유지 보수 등에 필요한 여러가지 일들의 수행 방법
• 개발을 수행하는 과정에서 필요한 각종 기법과 도구를 표준화한 것
• 소프트웨어의 생산성과 품질의 향상에 목적

2) 구조적 방법론

① 개념

• 정형화된 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
• 정보와 정보의 구조를 중심으로 분석, 설계, 구현
• 순차, 선택, 반복으로 프로그램의 흐름을 구성하여 복잡성을 감소
• 분할 정복을 통해 프로그램을 모듈화

② 구조적 방법론의 절차

타당성 검토 → 계획 → 설계 → 구현 → 시험 → 운용/유지보수

3) 정보공학 방법론

① 개념

• 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화하는 것
• 계획, 분석, 설계, 구축에 대한 정형화된 기법을 전체적으로 적용
• 데이터, 업무 활동, 상호작용으로 구성

② 정보공학 방법론의 절차

정보 전략 계획 수립 → 업무 영역 분석 → 업무 시스템 설계 → 업무 시스템 구축

4) 객체지향 방법론

① 개념

• 현실 세계의 개체를 객체화하여, 각각의 객체가 서로 통신을 통해 정보를 처리하는 형태의 소프트웨어를 구현하는 것
• 구조적 기법의 문제점을 보완하는 방법론 ★
• 객체, 클래스, 속성, 멤버, 메시지 등으로 구성 ★

② 객체지향 방법론의 기본 원칙 ★

• 캡슐화 : 데이터와 데이터를 처리하는 기능을 하나로 묶은 것
• 정보은닉 : 다른 객체에게 자신의 정보를 숨기는 것
• 추상화 : 객체의 중요한 특징만을 간단하게 표현하는 것
• 상속성 : 상위 객체의 속성을 하위 객체가 물려받는 것
• 다형성 : 하나의 이름으로 여러가지 기능을 가지는 것

③ 객체지향 방법론의 절차

요구 분석 → 설계 → 구현 →테스트 및 검증 → 인도

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

① 개념

• 재사용이 가능한 컴포넌트 기반의 개발 방법론
• 개발 기간 단축으로 생산성과 품질을 높일 수 있다.
• 유지보수 비용을 최소화할 수 있다.
• 시스템을 신속하게 구축, 새로운 기능 추가 및 확장을 용이하게 한다.

② 컴포넌트 기반 방법론의 절차

개발 준비 → 분석 → 설계 → 구현 → 테스트 → 전개 → 인도

③ 단계별 산출물

• 분석 단계 산출물 : 사용자 요구사항 정의서, 유스케이스 명세서, 요구사항 추적표
• 설계 단계 산출물 : 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기 데이터 설계서
• 구현 단계 산출물 : 프로그램 코드, 단위시험 결과서, 데이터베이스 테이블
• 시험 단계 산출물 : 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서

6) 애자일(Agile) 방법론

① 개념

• 고객의 요구사항 변화에 민첩하게 유연하게(Agile) 대응할 수 있도록 진행하는 것
• 일정한 주기를 반복하면서 개발 과정이 진행
• 소규모 프로젝트, 숙련된 개발자, 급변하는 요구사항에 적합
• XP, Scrum, 기능 중심 개발(FDD : Feature-Driven Development), 동적 시스템 개발 방법(DSDM : Dynamic Systems Development Method), 경량 개발, Kanban 등이 대표적

② 애자일 방법론의 절차

사용자 요구사항(User Story) → ( 계획 → 개발 → 승인 테스트 ) 반복

7) 제품 계열 방법론

① 개념

• 특정 제품의 공통된 기능을 중심으로, 새롭게 특화된 기능을 구현하여 조합하는 것
• 공통된 기능이 있는 제품들의 개발 비용 및 시간을 단축
• 임베디드 소프트웨어를 개발하는 데 적합
• 영역공학과 응용공학으로 구분

② 종류

• 영역공학: 제품(공통 영역) 분석, 요구사항 도출, 아키텍처(영역) 설계, 핵심 영역을 구현
• 응용공학: 제품 요구 분석, 제품 설계, 제품을 구현

8) 테일러링(Tailoring) 방법론

① 개요

• 개발하려는 소프트웨어 특성에 맞도록, 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 것
• 다양한 종류의 프로젝트를 일관된 하나의 방법론으로만 적용하기 어려웠기 때문에 등장
• 방법론의 최적화를 위하여 프로젝트를 분석하고 커스터마이징을 반복
• ISO/IEC 12207, CMMI, SPICE 등의 소프트웨어 개발 프레임워크를 사용

② 테일러링 개발 방법론의 필요성 판단 기준

• 내부적 요건

- 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우

- 요구사항 : 프로젝트의 생명 주기 활동에서 우선적으로 고려할 요구사항이 서로 다른 경우

- 프로젝트 규모 : 비용, 기간 등 프로젝트의 규모가 서로 다른 경우

- 보유 기술 : 소프트웨어 개발 방법론, 산출물 등이 서로 다른 경우

• 외부적 요건

- 법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우

- 표준 품질 기준 : 산업 분야별 표준 품질 기준이 서로 다른 경우

9) 보안 개발 방법론의 종류 ★

① MS-SDL

• 보안 수준이 높은 소트프웨어를 개발하기 위해 MS사가 자체적으로 수립한 SDLC(Software Development Life Cycle)이다.

② Seven Touchpoints

• 실무적으로 검증된 개발 보안 방법론 중 하나이다.
• 소프트웨어 보안의 모범 사례를 SDLC에 통합한 소프트웨어 개발 보안 생명 주기 방법론이다.
• 소프트웨어 보안의 모범 사례

- 코드 검토(code review)
- 아키텍처 위험 분석(architectural risk analysis)
- 침투 테스트(penetration testing)
- 위험 기반 보안 테스트(risk-based security tests)
- 악용 사례(abuse cases)
- 보안 요구(security requirement)
- 보안 운영(security oepration)

③ CLASP(Comprehensive, Lightweight Application Security Process)

• 소프트웨어 개발 생명 주기 초기 단계의 보안을 강화하기 위해 졍형화된 절차
• 활동 중심 역할 기반의 프로세스로 구성된 집합체이다.
• 이미 운영 중인 시스템에 적용하기 쉽다.
• 개념, 역할 기반, 활동 평가, 활동 구현, 취약성의 5가지 관점에 따라 개발 보안 절차를 진행한다.

④ CWE(Common Weakness Enumeration)

• 소프트웨어의 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론

- 입력 데이터 검증 및 표현 : 프로그램 입력값에 대한 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식 지정으로 인해 발생할 수 있는 보안 취약점

- 보안 기능 : 보안 기능(인증, 접근제어, 기밀성, 암호화, 권한 관리 등)을 부적절하게 구현 시 발생할 수 있는 보안 취약점

- 시간 및 상태 : 동시 또는 거의 동시 수행을 지원하는 병렬 시스템, 하나 이상의 프로세스가 동작되는 환경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안 취약점

- 에러 처리 : 에러를 처리하지 않거나 중요한 정보가 포함될 때 발생할 수 있는 보안 취약점

- 코드 오류 : 인가되지 않은 사용자에게 데이터가 유출되었을 때 발생하는 보안 취약점

- 캡슐화 : 중요한 데이터 또는 기능성을 불충분하게 캡슐화하였을 때, 인가되지 않은 사용자에게 데이터 누출이 가능해지는 보안 취약점

- API 오용 : 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안 취약점

---

비용 산정 기법

1) 개요

• 소프트웨어 개발 규모를 확인하여 필요한 비용을 산정하는 것
• 소요되는 인원, 자원, 기간 등으로 확인하여 실행 가능한 계획을 수립
• 비용 산정이 너무 낮을 경우 개발자의 부담이 증가되며 품질이 저하
• 하향식 비용 산정 기법과 상향식 비용 산정 기법

2) 소프트웨어 비용 결정 요소

① 프로젝트 요소 : 제품 복잡도, 시스템 크기, 요구되는 신뢰도 등

② 자원 요소 : 인적 자원, 하드웨어 자원, 소프트웨어 자원 등

③ 생산성 요소 : 개발자의 능력, 개발 기간 등

3) 하향식 비용 산정 기법

① 개념

• 과거 유사한 경험을 바탕으로 전문 개발자들이 참여한 회의를 통해 비용을 산정
• 전문 개발자의 경험에 의지하는 비과학적인 방법 ( 경험 바탕 )
• 프로젝트의 전체 비용 산정 후 각 작업별로 비용을 세분화

② 전문가 측정 기법

• 가장 신속하게 비용 산정이 가능
• 개인적이고 주관적인 판단이 포함될 가능성

③ 델파이(Delphi) 측정 기법

• 전문가 측정 기법의 주관적인 판단을 보완하기 위해 중재자와 많은 전문가가 함께 비용을 산정(평균 비용을 최종 비용으로 결정)
• 델파이 측정 기법의 절차

4) 상향식 비용 산정 기법

① 개념

• 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후에 전체 비용을 측정
• LOC, 수학적 산정 기법 등

② LOC(Line Of Code) 기법

• 각 기능의 원시 코드 라인 수를 예측하여 생산성, 개발 기간 등의 비용을 산정
• 예측치 측정 공식 : (낙관치 + ( 4 X 기대치 ) + 비관치 ) / 6

- 비관치 : 예측된 라인 수 중 가장 많은 것
- 낙관치 : 예측된 라인 수 중 가장 적은 것
- 기대치 : 예측된 라인 수들의 평균치

• LOC 기반 비용 산정 공식

- 노력(인월, Man(Person) Month) = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수

- 개발 비용 = 노력 X 단위 비용(월 평균 1인 인건비)

- 개발 기간 = LOC / (1인당 월평균 생산 코드 라인 수 X 투입 인원)

- 생산성 = LOC / 노력

③ 단계별 인월수(Effort Per Task) 기법

• LOC의 단점을 보완한 측정 방식
• 개발 단계별 중요도에 따른 가중치를 부여하여 측정

---

소프트웨어 비용 추정 모형(수학적 산정 기법)

1) COCOMO(Constructive Cost Model) 모델

① 개요

• 보헴(Boehm)이 제안한 LOC에 의한 비용 산정 기법
• 비용 견젹의 유언성이 높아 비용 산정에 널리 사용
• 소프트웨어의 성격에 따라 비용이 다르게 산정

② Organic

• 기관 내부에서 개발되는 중소 규모의 소프트웨어를 대상으로 한다.
• 사무 처리, 과학용, 업무용 등의 소프트웨어를 개발하는 유형
• 5만 라인(50KDSI=50KLOC) 이하의 소프트웨어 개발에 적합
• 노력 측정 공식 = 2.4 X KDSI1.05
• 개발 기간 = 2.5 X 노력0.38

③ Semi-Detached

• Organic과 Embedded의 중간형으로 운영체제, 데이터베이스 등의 관리 시스템 등의 소프트웨어 대상으로 한다.
• 30만 라인(300KDSI) 이하의 소프트웨어 개발에 적합하다.
• 노력 측정 공식 = 2.5 x 노력^0.35

④ Embedded

• 초대형 규모의 시스템 소프트웨어를 대상
• 신호 제어, 우주항공, 실시간 처리 시스템 등의 소프트웨어 개발에 적합
• 30만 라인(300KDSI) 이상의 소프트웨어 개발에 적합
• 노력 측정 공식 = 3.6 X KDSI^1.20
• 개발 기간 = 2.5 X 노력^0.32

⑤ 이후 발전된 COCOMO 모델 : 구체화 정도에 따라 Basic, Intermediate, Detailed 모델 등

2) Putnam 모델

① 개요

• 시간에 따라 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초
• 생명 주기 예측 모형이라고 하며 Putnam이 제안
• 대형 프로젝트에 이용되는 기법
• 개발 기간이 연장될수록 프로젝트 적용 인원의 노력이 감소
• SLIM(Software Lifecycle Management) : Putnam 모델을 기초로 한 소프트웨어 비용 산출 자동화 측정 도구

3) 기능 점수(Function Point) 모델

① 개요

• 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여
• 요인별 가중치를 합산하여 총 기능 점수를 산출
• 총 기능 점수와 영향도를 이용하여 기능 점수를 산출하여 비용을 산정
• 물리적 파일이나 테이블, 프로그램이 아닌 논리적인 사용자의 기능 요구사항을 기초로 비용을 산정

② 기능 점수 모델의 비용 산정 요소

산정 요소	설명
입력 유형의 수	형식이 다른 입력 양식의 수, 입력 파일
출력 유형의 수	형식이 다른 출력 양식의 수, 출력 보고서
사용자 명령의 수	프로그램을 실행하는 명령어 수, 사용자 질의 수
데이터 파일의 수	시스템에 의해 생성되는 내부 파일의 수
인터페이스의 수	외부 프로그램과의 연계되는 수

---

소프트웨어 개발 표준

1) 소프트웨어 개발 방법론 결정 절차

• 프로젝트 관리와 재사용 현황을 반영
• 개발 단계별 작업 및 절차를 수립
• 결정된 소프트웨어 개발 방법론의 개발 단계별 활동 목적, 작업 내용, 산출물에 대한 매뉴얼을 작성

2) ISO/IEC 12207

• 국제표준화기(ISO : International Organization for Standardization)에서 만든 표준 소프트웨어 생명 주기 프로세스
• 소프트웨어의 개발, 운영, 유지보수 프로세스를 향상시키기 위한 표준을 제공
• 기본, 지원, 조직 생명 주기 프로세스로 나뉜다.

- 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영, 유지보수

- 지원 생명 주기 프로세스 : 문서화, 형상 관리, 문제 해결, 품질 보증, 검증, 확인, 합동 검토, 감리

- 조직 생명 주기 프로세스 : 관리, 기반 구조, 개선, 교육 훈련

3) ISO/IEC 12119

• 패키지 소프트웨어의 제품 품질 요구사항 및 테스트를 위한 국제 표준

4) ISO/IEC 29119

• 소프트웨어 테스트 관련 국제 표준

5) ISO/IEC 9126 ★

① 개념

• 소프트웨어 품질 특성과 평가에 관한 표준 지침서
• 2011년에 호환성과 보안성을 강화하여 25010으로 개정

② 특성

• 기능성(Functionality) : 소프트웨어가 사용자 요구사항을 만족하는 기능을 제공하는지 평가
• 신뢰성(Reliability) : 소프트웨어가 기능을 정확하게 오류 없이 수행하는지 평가
• 사용성(Usability) : 소프트웨어의 기능과 결과를 사용자가 정확히 이해하고, 다시 사용할 의지가 있는지 평가
• 효울성(Efficiency) : 한정된 시간과 자원으로 얼마나 빨리 처리할 수 있는지 평가
• 유지보수성(Maintainability) : 새로운 요구사항 및 환경의 변화에 따라 소프트웨어를 개선할 수 있는지 평가
• 이식성(Portability) : 소프트웨어가 다른 환경에서 얼마나 쉽게 적용되는지에 대한 정도를 평가

6)CMM(Capability Maturity Model)

① 개념

• 소프트웨어 유지보수, 개발에 대한 프로세스 개선과 능력 향상을 위한 프레임워크
• 개발 조직의 프로세스 성숙도 개선 및 측정을 위해 사용
• 소프트웨어 개발 프로세스의 신뢰적이고 일관성 있는 능력 평가 기반 구조
• 프로세스가 가지는 기술적인 측면과 인간적 측면을 동시에 고려
• 레벨이 높을수록 소프트웨어 개발 프로세스의 품질 향상

② CMM의 단계별 핵심 프로세스

단계	정의	핵심 프로세스
초기화(Initial)	소프트웨어 개발 관리 프로세스가 없는 상태	프로세스 성과 예측 불가능
반복(Repeatable)	성공한 프로젝트의 반복 사용으로 인한 통계 데이터 관리가 가능한 상태	요구 관리, 계획, 추적, 감시, 형상 관리, 품질 보증
정의(Defined)	프로세스에 대한 정의와 이해가 가능한 발전된 상태 데이터 기반 프로젝트 관리	조직 프로세스 관리, 교육 훈련 프로그램, 통합 소프트웨어 관리, 생산 공학, 동료 검토, 중간 심사
관리(Managed)	프로세스 성과 분석과 측정을 통해 개선, 관리가 가능한 상태	정량적 프로세스 관리, 품질 관리
최적화(Optimizing)	지속적인 질적, 양적 품질 개선이 가능한 상태	결함 예방, 기술 변화 관리, 프로세스 변경 관리

③ CMM의 프로세스 평가 기준

Level	관리 명칭	주요 내용	평가
1	혼돈적 관리	순서의 일관성 X	위험성 높음
2	경험적 관리	일정, 비용의 경험적 법칙 적용
3	정성적 관리	경험 공유, 공식적 프로세스 관리
4	정량적 관리	통계적 방법과 조직적 분석
5	최적화 관리	위험 예측 최적화 도구 이용	생산성, 품질 높음

④ CMM의 한계

• 조직 자체를 평가하므로 제품의 품질과는 직접적인 연관성이 없다.
• 소규모 업체에는 적용이 곤란하다.
• 등급 판정이 비효율적, 비현실적이다.

7) CMMI(Capability Maturity Model Integration)

① 개념

• CMM의 후속 모델
• 조직의 개발 프로세스 역량 성숙도를 평가
• 어떤 모델이든 업무의 목적에 맞게 수정하여 사용할 필요
• 프로세스 관리, 프로젝트 관리, 엔지니어링, 지원 영역 등

② CMMI의 종류

• SW-CMM : 소프트웨어 능력 성숙도 모델
• SE-CMM : 시스템 엔지니어링 능력 성숙도 모델
• IPD-CMM : 통합 제품 개발 능력 성숙도 모델
• People-CMM : 인력 개발과 관리 능력 성숙도 모델
• SA-CMM : 소프트웨어 구입 기능 성숙도 모델
• SECMM : 시스템 엔지니어링 능력 평가 모델

8) SPICE(Software Process Improvement and Capability dEtermination)

① 개념

• 소프트웨어 품질 및 생산성 향상을 위한 소프트웨어 프로세스를 평가하는 국제 표준
• ISO 12207 소프트웨어 생명 주기 프로세스에 기초하여 ISO 15504를 완성
• CMM과 비슷한 프로세스 평가 모델을 제시

② SPICE의 목적

• 개발 기관이 프로세스 개선을 위해 스스로를 평가
• 계약 기관에서 정한 요구조건을 만족하는지 평가

③ SPICE 모델의 단계별 프로세스 수행 능력 수준 ★

Level	명칭	단계 설명
0	불안정	프로세스가 충분히 구현되지 못한 단계
1	수행	프로세스가 전반적으로 구현된 단계
2	관리	자원의 한도 내에서 프로세스가 직접 작업 산출물 인도
3	확립	소프트웨어 공학 원칙을 기반으로 프로세스 수행
4	예측	목적 달성을 위한 소프트웨어 통제, 정량적 측정
5	최적화	프로젝트 수행 최적화, 지속적인 업무 목적을 만족시킴

---

※ <이기적> 환상의 콤비 정보처리기사 책으로 공부하며 정리한 내용입니다.