요구 사항 확인

소프트웨어 생명 주기

소프트웨어 생명 주기(Software Life Cycle)

소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

• 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다. 소프트웨어 수명 주기라고도 한다.
• 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 한다.
• 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적인 모형을 사용할 수도 있다.
• 일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있다.

폭포수 모형(Waterfall Model)

• 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 고전적 생명 주기 모형이라고도 한다.
• 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형이다.
• 모형을 적용한 경험과 성공 사례가 많다.
• 제품의 일부가 될 메뉴얼을 작성해야 한다.
• 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.
• 두 개 이상의 과정이 병행하여 수행되지 않는다.

프로토타입 모형(Prototype Model, 원형 모형)

견본 품을 만들어 최종 결과물을 예측하는 모형이다.

• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
• 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 된다.
• 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모델

나선형 모델(Spiral Model, 점진적 모형)

폭소수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 한다.
• 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요없다.

애자일 모형

고객의 요구사항 변화를 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다.

• 고객과의 소통에 초점을 맞춘 방법론
• 기업 활동 전반에 걸쳐 사용됨
• 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다 고객의 평가와 요구를 적극 수용
• 각 개발주기에서는 고객이 요구사항에 우선순위를 부여하여 개발작업을 진행
• 소규모 프로젝트, 소도로 숙달된 개발자, 급변하는 모구 사항에 적합

애자일 개발 4가지 핵심 가치

1. 프로세스와 도구보다는 개인과 사용작용에 더 가치를 둔다.
2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.
4. 계획을 따르기 보다는 변화에 반응하는 것을 더 가치에 둔다.

스크럼 기법

스크럼의 개요

스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미

< 스크럼 팀 구성 >

• 제품 책임자
  - 요구사항에 책임을 지고 의사 결정할 사람
  • 개발 의뢰자, 사용자
  • 백로그(모든 요구사항의 모음)에 대한 우선순위 지정
  • 주기적으로 우선순위 갱신
• 스크럼 마스터
  - 객관적인 시점에서 조언을 해주는 가이드 역할
  • 일일 스크럼 회의를 주관하여 진행 사항을 점검
• 개발팀
  - 위 두 팀원을 제외한 나머지
  • 7~8명도가 적당

스크럼 개발 프로세스

• 개발 백로그
  - 모든 요구사항을 우선순위에 따라 나열한 목록
  • 지속적 업데이트
  • 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 게획을 수립
• 스프린트 계획 회의
  - 단기 일정 수립을 목적
  • 개발자들이 작업을 나누어서 할 수 있도록 스프린트 백로그작성
• 스프린트
  - 실제 개발 작업, 2~4주 정도의 기간 내에서 진행
  • 태스크를 할당할 때는 개발자가 원하는 태스크를 직접 선별해 당담하도록 하는 것이 좋음
  • 개발 담당자에게 할당된 태스크는 보통 할일, 진행중, 완료의 상태를 가짐
• 일일 스크럼 회의
  - 15분 정도의 짧은 시간동안 진행 상황을 점검
  • 보통 서서 진행, 남은 작업 시간을 소멸차트에 표시
  • 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌
• 스프린트 검토 회의
  - 부분 또는 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 자리에서 테스팅
  • 스프린트의 한 주당 한 시간 내에서 진행한다.
  • 제품 책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스트린트에 반영할 수 있도록 제품 백로그 업데이트
• 스프린트 회고
  - 스프린트 주기를 돌아보면 잘 지켰는지, 개선할 점을 없는지 확인하고 기록
  • 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행

XP(eXtreme Programing) 기법

XP

고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

• XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 목적으로 개발
• 릴리즈(부분 개발)의 기간을 짧게 반복하면서 고객의 요구사항 적극 반영
• 릴리즈 마다 고객을 직접 참여 시켜 고객 안심
• 소규모 인원 개발에 효과적

< XP의 5가지 핵심 가치 >
1. 의사소통
2. 단순성
3. 용기
4. 존중
5. 피드백

XP 개발 프로세스

1. 사용자 스토리(고객의 요구사항을 간단한 시나리오로 표시한것)
2. 릴리스 계획 수립
3. 스파이크(요구사항의 신뢰성을 높이고 기술의 문제의 위험을 감소하기 위한 프로그램)
4. 이터레이션(릴리즈를 세분화한 것)
5. 승인 검사(릴리즈 단위 테스트)
6. 소규모 릴리즈(고객의 의견 확인)

현행 시스템 파악

현행 시스템 파악 절차

• 1단계
  - 시스템 구성 파악
  • 시스템 기능 파악
  • 시스템 인터페이스 파악
• 2단계
  - 아키텍처 구성 파악
  • 소프트웨어 구성 파악
• 3단계
  - 하드웨어 구성 파악
  • 네트워크 구성 파악

개발 기술 환경 파악

정의

개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등 선정할 때 고려해야할 사항을 기술하는 것

요구사항 정의

요구사항의 개념 및 특징

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명

• 소프트웨어 개발이나 요주 보수 과정에서 필요한 기준과 근거 제공
• 의사소통을 원할하게 하게 도움
• 목표과 계획을 수립하기 위한 과정

요구사항 유형

• 기능 요구사항
• 비기능 요구사항
• 사용자 요구사랑
• 시스템 요구사항(개발자 관점)

요구사항 개발 프로세스

1. 도출(의견 교환)
2. 분석(분석에서 나온 의견 가지치기)
3. 명세(문서화)
4. 확인(요구사항 명세서 검토)

요구사항 분석

개요

사용자의 요구사항을 이해하고 문서화하는 활동
타당성 조사, 비용과 일정 제약 설정
목표를 잡고 어떻게 해결할지 정함

구조적 분석 기법

자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법

• 도형 중심의 분석용 도구를 사용하여 분석
• 도형 중김의 도구를 사용하기 때문에 사용자 간의 대화 용이
• 하향식 방식으로 세분화, 분석의 중복 배제 가능

자료 흐름도

요구사항 분석을 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방식

• 자료 흐름도에서는 자료의 흐름과 기능을 프로세스, 자료 흐름, 자료 저장소, 단말 네가지 기호로 표시
• 프로세스를 거쳐 변환될 때마다 새로운 이름 부여

자료 사전

자료 흐름도에 있는 자료를 더 자세하게 기록한 것
기호를 사용하여 더 체계적이고 조직적으로 보임
=, +, (), [|], {}, ** 기호 사용

요구사항 분석CASE와 HIPO

CASE

요구사항을 자동으로 분석하고 명세서를 기술하도록 개발된 도구

• 비용 축소
• 품질 개선
• 결함 발견

HIPO

시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력 기능을 나타낸다.

• 체계적인 문서관리 가능
• 보기 쉽고 이해 쉽다.
• 기능과 자료의 의존 관계를 동시에 표현 가능
• 변경, 유지보수

UML의 개요

UML은 시스템 분석, 설계 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

• UML은 여러 외국인 등의 객체지향 방법론의 장점을 통합하였으며, 객체 기술에 관한 국젶준화기구인 OMG에서 표준으로 지정하였다.
• UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램으로 나눈다.
• 사물과 사물간의 관계에 용도에 맞게 표현한다.
• UML 구성 요소에서는 사물, 관계, 다이어그램 등이 있다.

관계

• 연관 관계 : 2개 이상의 사물이 서로 관련되어 있음을 표현
• 집합 관계 : 하나의 사물이 다른 사물에 포함되어있는 관계
• 포함 관계 : 집합관계의 특별한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 일반화 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
• 의존 관계 : 연관관계이나 필요에 의해 서로에게 영향을 주는 짧은 시간동안만 연관을 유지하는 관계
• 실체화 관계 : 실체화 관계는 사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화할 수 있는 관계를 표현

다이어그램

구조적 다이어그램

• 클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현, 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있다.
• 객체 다이어그램 : 클래스에 속한 사물들을 특점 시점의 객체와 객체 사이의 관계로 표현
• 컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 간의 관계나 인터페이스 표현, 구현단계에서 사용
• 배치 다이어그램 : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현. 노드와 의사소통 경로로 표현, 구현단계에서 사용
• 복합체 구조 다이어그램 : 클래스나 컴포넌트가 복합 구조를 가질 경우 그 내부 표현
• 패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

행위 다이어그램

• 유스케이스 다이어그램 : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용. 엑터와 유스케이스로 구성
• 시퀀스 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고 받은 메시지를 표현
• 커뮤니케이션 다이어그램 : 시퀀스 다이어그램인데 메시지 뿐만 아니라 객체들 간의 연관까지 표현
• 상태 다이어그램 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
• 활동 다이어그램 : 로직이나 조건에 따른 처리의 흐름에 따라 표현
• 상호작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름을 표현
• 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현

스테레오 타입

스테레오 타입은 UML에서 표현하는 기본 기능 외의 추가적으로 기능을 표현하기 위해 사용

• <<include>> : 연결된 다른 UML 요소에 대해 포함 관계가 있는 경우
• <<extend>> : 연결된 다른 UML요소에 대해 확장 관계가 있는 경우
• <<interface>> : 인터페이스를 정의하는 경우
• <<exception>> : 예외를 정의하는 경우
• <<constructor>> : 생성자 역할을 수행하는 경우

시퀀스 다이어그램

시퀀스 다이어그램은 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것

시퀀스 다이어그램 구성 요소

• 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로 사람이나 외부 시스템을 의미
• 객체 : 메시지를 주고받는 주체
• 생명선 : 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
• 실행 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현
• 메시지 : 객체가 상호작용을 위해 주고받는 메시지