소프트웨어 생명 주기
- 소프트웨어 생명 주기는 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.
- 대표적인 생명 주기 모형
- 폭포수 모형
- 프로토타입 모형
- 나선형 모형
- 애자일 모형
폭포수 모형
- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.
- 가장 오래되고 가장 폭넓게 사용된 전통적인(고전적) 소프트웨어 생명 주기 모형이다.
프로토타입 모형
- 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.
나선형 모형
- 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형이다.
- 보헴(Boehm)이 제안한 모델로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.
애자일 모형
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형이다.
- 고객과의 소통에 초점을 맞춘 방법론을 통칭한다.
- 폭포수 모형과 대조적이다.
- 애자일 개발 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대만 문서보다는 실행되는 SW에 더 가치를 둔다.
- 계약 협상보다는 고객과 협업에 더 가치를 둔다.
- 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.
- 대표적인 개발 모형
- 스크럼(Scrum)
- XP(eXtreme Programming)
- 칸반(Kanban)
- Lean
- 기능 중심 개발(Feature Driven Development)
스크럼(Scrum) 기법
- 팀이 중심이 되어 개발의 효율성을 높이는 기법이다.
- 팀원 스스로가 스크럼 팀을 구성하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.
XP(eXtreme Programming) 기법
- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
- 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다.
- XP의 5가지 핵심 가치: 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
요구사항
- 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정삭적으로 운영되는데 필요한 제약조건이다.
- 요구사항의 유형
- 기능 요구사항(Functional requirements): 기능이나 수행과 관련된 요구사항
- 비기능 요구사항(Non-functional requirements): 품질이나 제약사항과 관련된 요구사항
- 사용자 요구사항(User requirements): 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 시스템 요구사항(System requirements): 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 요구사항 개발 프로세스: 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다.
- 도출(Elicitation) > 분석(Analysis) > 명세(Specification) > 확인(Validation)
요구사항 분석
- 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미한다.
- 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
구조적 분석 기법
- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법이다.
- 주요 구조적 분석 기법 도구
- 자료 흐름도(DFD): 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 자료 사전(DD): 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
- 소단위 명세서(Mini-Spec.)
- 개체 관계도(ERD)
- 상태 전이도(STD)
- 제어 명세서
요구사항 분석용 CASE(자동화 도구)
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미한다.
- 대표적인 요구사항 분석용 CASE
- SADT
- SREM = RSL/REVS
- PSL/PSA
- TAGS
- 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법으로, 시스템 실행 과정인 입력/처리/출력의 기능을 표현한 것이다.
- 하향식 소프트웨어 개발을 위한 문서화 도구이다.
- 기능과 자료의 의존 관계를 동시에 표현할 수 있고, 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
UML(Unified Modeling Language)
- 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.
- UML의 구성 요소
- 사물(Things)
- 관계(Relationships)
- 다이어그램(Diagram)
UML - 사물
- 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.
- 사물의 종류
- 구조 사물(Structual Things): 시스템의 개념적, 물리적 요소를 표현
- 행동 사물(Behavioral Things): 시간과 공간에 따른 요소들의 행위를 표현
- 그룹 사물(Grouping Things): 요소들을 그룹으로 묶어서 표현
- 주해 사물(Annotation Things): 부가적인 설명이나 제약조건 등을 표현
UML - 관계
- 사물과 사물 사이의 연관성을 표현하는 것이다.
- 관계의 종류
- 연관(Association) 관계: 2개 이상의 사물이 서로 관련되어 있는 관계
- 집합(Aggregation) 관계: 하나의 사물이 다른 사물에 포함되어 있는 관계 ex) 컴퓨터 - 프린터
- 포함(Composition) 관계: 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계 ex) 자동차 - 엔진
- 일반화(Generalization) 관계: 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계 ex) 커피 - 아메리카노
- 의존(Dependency) 관계: 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계 ex) 등급 - 할인율
- 실체화(Realization) 관계: 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계 ex) 날 수 있다 - 새
UML - 다이어그램
- 사물과 관계를 도형으로 표현한 것이다.
- 정적 모델링에서는 주로 구조적 다이어그램을 사용한다.
- 동적 모델링에서는 주로 행위 다이어그램을 사용한다.
- 구조적(Strunctual) 다이어그램의 종류
- 클래스(Class) 다이어그램: 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함
- 객체(Object) 다이어그램: 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현함
- 컴포넌트(Component) 다이어그램: 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함
- 배치(Deployment) 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함
- 복합체 구조(Composite Structure) 다이어그램: 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함
- 패키지(Package) 다이어그램: 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함
- 행위(Behavaior) 다이어그램의 종류
- 유스케이스(Use Case) 다이어그램: 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함
- 시퀸스(Sequence) 다이어그램: 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함
- 커뮤니케이션(Communication) 다이어그램: 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현함
- 상태(State) 다이어그램: 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현함
- 활동(Activity) 다이어그램: 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함
- 상호작용 개요(Interaction Overview) 다이어그램: 상호작용 다이어그램 간의 제어 흐름을 표현함
- 타이밍(Timing) 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현함
소프트웨어 공학
- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이다.
- 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
- 소프트웨어 공학의 기본 원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.
소프트웨어 개발 방법론
- 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.
- 주요 소프트웨어 개발 방법론
- 구조적 방법론
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반 방법론
- 제품 계열 방법론
- 애자일 방법론
소프트웨어 공학의 발전적 추세
- 소프트웨어 재사용(Reuse): 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
- 소프트웨어 재공학(Reengineering): 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
- CASE(Computer Aided Software Engineering): 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것이다.
비용 산정 기법
- 소프트웨어 비용 산정은 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것이다.
- 하향식 비용 산정 기법: 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법이다.
- 상향식 비용 산정 기법: 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법이다.
- LOC(원시 코드 라인 수, source Line of Code) 기법
- 개발 단계별 인월수(Effort per Task) 기법
- 수학적 산정 기법
수학적 산정 기법
- 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다.
- 수학적 산정 기법은 개발 비용 산정의 자동화를 목표로 한다.
- 주요 수학적 산정 기법
- COCOMO 모형
- Putnam 모형
- 기능 점수(FP) 모형
COCOMO 모형
- 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법이다.
- 보헴(Boehm)이 제안하였다.
- COCOMO의 소프트웨어 개발 유형
- 조직형(Organic Mode): 기관 내부에서 개발된 중/소규모의 소프트웨어 (5만 라인 이하)
- 반분리형(Semi0Detached Mode): 조직형과 내장형의 중간형 소프트웨어 (30만 라인 이하)
- 내장형(Embedded Mode): 초대형 규모의 소프트웨어(30만 라인 이상)
- COCOMO 모형의 종류
- 기본형(Basic) COCOMO: 소프트웨어의 크기와 개발 유형만을 이용하여 비용 산정
- 중간형(Intermediate) COCOMO: 기본형 COCOMO의 공식을 토대로 사용하나, 제품의 특성, 컴퓨터의 특성, 개발 요원의 특성, 프로젝트 특성에 의해 비용을 산정
- 발전형(Detailed) COCOMO: 중간형 COCOMO를 보완하여 만들어진 모형으로, 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정
Putnam 모형
- 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형이다.
- 푸트남(Putnam)이 제안한 것으로, 생명 주기 예측 모형이라고도 한다.
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
기능 점수(FP; Functional Point) 모형
- 소프트웨어의 기능을 증대시킨은 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법이다.
- 소프트웨어 기능 증대 요인
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
소프트웨어 개발 표준
- 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미한다.
- 주요 소프트웨어 개발 표준
- ISO/IEC 12207: ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스로, 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공
- CMMI(능력 성숙도 통합 모델): 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
- SPICE(소프트웨어 처리 개선 및 능력 평가 기준): 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준 (공식 명칭은 ISO/IEC 15504)
