정처기 5과목: 정보 시스템 구축 관리
1. 소프트웨어 개발 방법론
1) 객체지향 방법론(Object-oriented Engineering Methodology)
- 요구분석, 설계, 구현, 테스트 및 검증 단계로 구성
- 구성 요소: 객체(Object), 클래스(Class), 메시지(Message)
- 기본 원칙: 캡슐화, 정보 은닉, 추상화, 상속, 다형성
- 시스템 분석을 위해 Usecase Diagram이 주로 사용됨
- 시스템 설계를 위해 Sequence Diagram이 주로 사용됨
2) 컴포넌트 기반 개발 방법론(CBD, Component Based Developmnet)
- 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 애플리케이션 개발 생산성과 품질을 높이고, 시스템 유지보수 비용을 최소화할 수 있는 개발 방법 프로세스
- 컴포넌트 단위의 개발 및 조립을 통하여 정보 시스템의 신속한 구축 ,변경, 확장의 용이성과 타 시스템과의 호환성을 달성하고자 하는 소프트웨어 공학 프로세스, 방법론 및 기술의 총체적 개념
3) CBD 방법론의 특징
- 개발 준비, 분석, 설계, 구현, 테스트, 전개, 인도 순으로 반복 점진적 개발 프로세스를 제공하고, 시스템 설계를 위해 컴포넌트 설계서가 주로 사용됨
- 컴포넌트는 데이터베이스와 소프트웨어의 모듈 단위로 재사용이 가능함
- 시스템 분석을 위해 Usecase Diagram이 주로 사용됨
- 개발 기간 단축으로 인한 생산성이 향상되며 새로운 기능 추가가 쉬워 확장석이 높음
4) 소프트웨어 재사용
- 합성 중심(Composition based): 전자칩과 같은 소프트웨어 부품, 즉 블록(모듈)을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로, 블록 구성 방법이라고도 함
- 생성 중심(Generation based): 추상화 형태로 쓰여진 명세를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 함
2. 소프트웨어 개발 방법론 활용
1) 소프트에어 개발 생명주기(SDLC, Software Development Life Cycle)
- 소프트웨어 시스템의 개발, 가동, 운용, 유지보수, 파기의 전 공정을 체계화한 개념
- 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 됨
- 용어를 표준화시키고 문서화가 충실한 프로젝트 관리를 가능하게 함
- SDLC Model: 구축 및 수정 모형, 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등
2) 프로토타입 모형(Prototyping Model)
- 실제 개발될 소프트웨어에 대한 시제품(Prototype)을 만들어 최종 결과물을 예측하는 모형
- 단계: 요구 수집, 빠른 설계, 프로토타입 구축, 고객 평가, 프로토타입 조정, 구현
- 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있음
3) 폭포수 모형(Waterfall Model)
- 보헴(Bohem)이 제안한 고전적 생명주기 모형으로, 선형 순차적 모형이라고도 함
- 단계: 타당성 검토, 계획, 요구사항 분석, 구현, 유지보수
- 순차적인 접근 방법을 이용하여, 단계적 정의와 산출물이 명확함
- 각 단계의 결과가 확인되어야지만 다음 단계로 넘어감
- 개발 중 발생한 요구사항은 반영하기 어려움
4) 나선형 모형(Spiral Model)
- 보헴이 제시하였으며 반복적인 작업을 수행하는 모형으로 점증적 모형, 집중적 모형이라고도 함
- 여러 번의 개발 과정을 거쳐 완벽한 최종 소프트웨어를 개발하는 점진적 모형
- 가장 큰 장점인 위험 분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 위험성 평가에 크게 의존하지 않기 때문에 이를 발견하지 않으면 문제가 발생할 수 있음
- 대규모 시스템의 소프트웨어 개발에 적합
5) 나선형 모형의 개발 단계
- 계획 수립(Planning): 위험 요소와 타당성을 분석하여 프로젝트의 추진 여부 결정
- 위험 분석(Risk Analysis): 개발 목적과 기능 선택, 제약 조건 등을 결정하고 분석
- 개발 및 검증(Development): 선택된 기능을 수행하는 프로토타입을 개발
- 고객 평가(Evaluation): 개발된 프ㅗ토타입을 사용자가 확인하고 추가 및 수정될 요구사항이 있으면 이를 반영한 개선 프로토타입을 만듦
6) CPM(Critical Path Method)
- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는 기법
7) PERT(Program Evaluation and Review Technique)
- 소요 시간 예측이 어려운 경우 최단 시간 내에 완성할 수 있게 하는 프로젝트 방법
- 계획 공정(Network)을 작성하여 분석하므로 간트도표에 비해 작업 계획을 수립하기 쉬움
- 계획 공정의 문제점을 명확히 종합적으로 파악할 수 있음
- 관계자 전원이 참가하게 되므로 의사소통이나 정보 교환 용이
3. 비용 산정 모델
1) 전문가 감정 기법
- 개발 조직 내에 경험이 많은 2인 이상의 전문가에게 비용 산정을 의뢰하는 기법
2) 델파이(Delphi) 기법
- 산정 요원과 조정자에 의해 산정하는 기법
- 전문가가 독자적으로 감정할 때 발생할 수 있는 편차를 줄이기 위해 단계별로 전문가들의 견해를 조정자가 조정하여 최종 견적을 결정
- 유사한 프로젝트 경험을 가진 전문가 집단을 구성하여 규모, 공수, 비용의 산정 의견을 구함
3) LOC(Line Of Code) 기법
- 소프트웨어 각 기능 구현 시 작성될 원시 코드 라인수의 비관치, 낙관치, 기대치를 츶겅하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
- 예측치 = a + (4 x c) + b / 6 (단, a는 낙관치, b는 비관치, c는 기대치)
4) COCOMO(COnstructive COst MOdel) 모델
- 보헴이 제안한 소스 코드의 규모에 의한 비용 예측 모델
- 같은 규모의 소프트웨어라도 그 유형에 따라 비용이 다르게 산정됨
- 산정 결과는 프로젝트를 완성하는데 필요한 MM(Man-Month)으로 나타냄
- 소프트웨어 개발 유형: Organic Mode(단순형), Semi-detached Mode(중간형), Embedded Mode(임베디드형)
5) Putnam 모델
- Rayleigh-Norden 곡선의 노력 분포도를 이용한 프로제긑 비용 산정 기법
- 소프트웨어 개발 생명주기의 전 과정 동안에 사용될 노력의 분포를 예측
- SLIM: Rayleigh-Norden 곡선과 Putnam의 모델에 기반을 둔 자동화 추정 도구
6) 기능 점수(FP: Functional Point)
- 시스템을 구현한 기술에 의존적이고 개발자에 의해 식별되는 기능에 기반하여 시스템의 크기를 측정하는 척도
- 입력, 출력, 질의, 파일, 인터페이스의 개수로 소프트웨어의 규모를 표현
- 기능 점수 비용산정 요소: 코드 라인 수, 데이터 파일 수, 문서 페이지 수, 입력 유형의 수, 출력 보고서의 수, 외부 루틴과의 인터페이스 수, 명령어(사용자 질의 수)
4. 소프트웨어 개발 표준
1) ISO/IEC 25000
- 9126과 14598을 통합, 2500n~2504n의 다섯 가지 분야, 확장 분야인 2505n
- 2501n(품질 모형): 품질 모델 및 품질 사용
- 2503n(품질 측정): 매트릭을 통한 측정 방법 제시
2) ISO/IEC 12207
- 소프트웨어 개발 작업에 일관적이고 체계적인 프레임워크를 제공하기 위하여 1995년에 제정된 소프트웨어 생명주기 프로세스 국제 표준
- 기본 생명주기 프로세스 구분: 획득 프로세스, 공급 프로세스, 개발 프로세스, 운영 프로세스, 유지보수
3) SPICE(Software Process Improvement and Capability dEtermination)
- 소프트웨어 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
- 공식 명칭은 ISO/IEC 15504
- 모델 범주: 고객-공급자 프로세스, 공학 프로세스, 지원 프로세스, 관리 프로세스, 조직 프로세스
- 레벨: 불완전 단계, 수행 단계, 관리 단계, 확립 단계, 예측 단계, 최적 단계
5. 테일러링과 프레임워크
1) 테일러링(Tailoring)
- 기존 개발 방법론의 절차, 기법, 산출물 등을 프로젝트 상황에 맞게 수정하는 작업
- 수행 절차: 프로젝트 특징 정의, 표준 프로세스 선정/검증, 상위 레벨 커스터마이징, 세부 커스터마이징, 테일러링 문서화
2) 라이브러리(Library)
- 단순 활용 가능한 도구들의 집합
- 프로그래머가 어떠한 기능을 수행하기 위해서 도움을 주는 또는 필요한 것을 제공해주는 역할
3) 프레임워크(Framework)
- 비슷한 유형의 응용 프로그램들을 위해 재사용이 가능한 아키텍처와 협력하는 소프트웨어 산출물의 통합된 집합
- 특정 클래스의 재사용뿐만 아니라 응용 프로그램을 위한 핵심 아키텍처를 제공하여 설계의 재사용을 지원
4) 프레임워크와 라이브러리의 차이점
- 프레임워크: 전체적인 흐름을 자체적으로 가지고 있어 프로그래머는 그 안에서 필요한 코드를 작성
- 라이브러리: 프로그래머가 전체적인 흐름을 가지고 있어 라이브러리를 자신이 원하는 기능을 구현하고 싶을 때 가져다 사용할 수 있음
5) 소프트웨어 개발 프레임워크
- 소프트웨어 개발을 도와주는 재사용이 가능한 클래스와 패턴의 집합
- 소프트웨어의 틀과 구조를 결정하고, 이를 바탕으로 개발된 개발자의 코드를 제어
6) 소프트웨어 개발 프레임워크 적용 시
- 개발 용이성: 공통 기능은 프레임워크가 제공, 패턴 기반 개발과 비즈니스 로직에만 집중한 개발이 가능
- 시스템 복잡도 감소: 시스템의 복잡한 기술은 프레임워크에 의해 숨겨짐, 미리 잘 정의된 기술 셋을 적용할 수 있음
- 이식성: 플랫폼 연동을 프레임워크가 제공, 플랫폼의 독립적인 개발이 가능
- 품질 보증: 검증된 개발 기술과 패턴에 따른 개발 가능, 개발자의 경험과 능력 차이 줄여줌
- 운영 용이성: 소프트웨어 변경 용이, 비즈니스 로직 및 아키텍처 파악 용이
- 개발 코드 최소화: 공통 컴포넌트와 서비스 활용, 반복적인 코드 개발 최소화
- 변경 용이성: 잘 구조화된 아키텍처 적용, 플랫폼에 독립적
- 설계 및 코드의 재사용성: 프레임워크의 서비스와 패턴을 재사용, 이미 개발된 컴포넌트 재사용