[정보처리기사] 1과목 소프트웨어 설계 : 1장. 요구사항 확인

1. 소프트웨어 생명 주기 ***
2. 스크럼 기법 ***
3. XP 기법 ***
4. 현행 시스템 파악
5. 개발 기술 환경 파악
6. 요구사항 정의
7. 요구사항 분석 기법
8. 요구사항 확인 기법
9. UML ***

 

 

1. 소프트웨어 생명 주기 ***

 

소프트웨어 생명 주기

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

​

폭포수 모형

- 폭포에서 한번 떨어진 물은 거슬로 올라갈 수 없듯이 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론

- 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 고전적 생명 주기 모형이라고도 함

- 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형

- 제품의 일부가 될 매뉴얼을 작성해야 함

- 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함

​

프로토타입 모형

- 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(prototype)을 만들어 최종 결과물을 예측하는 모형

- 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

- 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형

​

나선형 모형

- 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

- 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 함

- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함

- 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음

​

애자일 모형

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

- 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초첨을 맞춘 방법론을 통칭

- 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구 적극 수용

- 요구사항에 우선순위를 부여하여 개발 작업 진행

- 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합

- 스크럼, XP(eXtreme Programming), 칸반, Lean, 크리스탈, ASD(Adaptive Software Development), FDD(Feature Driven Development), DSDM(Dynamic System Development), DAD(Disciplined Agile Delivery) 등이 있음

 

 

 

2. 스크럼 기법 ***

 

스크럼의 개요

- 스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형

- 팀이 중심이 되어 개발의 효율성을 높인다는 의미

- 팀원 스스로가 스크럼 팀을 구성해야 하며, 개발 작업에 관한 모든것을 스스로 해결할 수 있어야 함

- 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성

​

1) 제품 책임자(PO)

- 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정

- 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체

- 요구사항이 담긴 백로그를 작성하고 백로그에 대한 우선순위를 지정

​

2) 스크럼 마스터(SM)

- 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할

- 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리

​

3) 개발팀(DT)

- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람

​

스크럼 개발 프로세스

1) 제품 백로그

- 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록

- 개발 과정에서 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트

- 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획을 수립

​

2) 스프린트 계획 회의

- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립

- 스프린트에서 처리할 요구사항을 개발자들이 나눠서 작업할 수 있도록 태스크라는 작업 단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성

​

3) 스프린트

- 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행

- 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간을 추정한 후 개발 담당자에게 할당

- 개발 담당자에게 할당된 태스크는 보통 할 일, 진행 중, 완료의 상태를 가짐

​

4) 일일 스크럼 회의

- 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검

- 남은 작업 시간은 소멸 차트에 표시

- 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도움

​

5) 스프린트 검토 회의

- 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행

- 제품 책인자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트

​

6) 스프린트 회고

- 스프린트 주기를 되돌아보며 정해진 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록

- 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행

 

 

 

3. XP 기법 ***

 

XP

- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함

- 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임

- 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인

- XP의 5가지 핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백

​

XP 개발 프로세스

1) 사용자 스토리

- 고객의 요구사항을 간단한 시나리오로 표현

- 내용은 기능 단위로 구성하며, 필요한 경우 간단한 테스트 사항도 기재

​

2) 릴리즈 계획 수립

- 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립

​

3) 스파이크

- 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

- 처리할 문제 외의 다른 조건은 모두 무시하고 작성

​

4) 이터레이션

- 하나의 릴리즈를 더 세분화 한 단위

- 이 기간 중에 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수 있음

​

5) 승인 검사 (인수 테스트)

- 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트

- 사용자 스토리 작성 시 함께 기재된 테스트 사항에 대하 고객이 직접 수행

- 테스트 과정에서 발견한 오류 사항은 다음 이터레이션에 포함

- 테스트 이후 새로운 요구사항이 작성되거나 요구사항의 상대적 우선순위가 변경될 수 있음

​

6) 소규모 릴리즈

- 릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응할 수 있음

- 계획된 릴리즈 기간 동안 진행된 이터레이션이 모두 완료되면 고객에 의한 최종 테스트를 수행한 후 릴리즈

- 릴리즈가 최종 완제품이 아닌 경우 다음 릴리즈 일정에 맞게 개발을 계속 진행

​

XP의 주요 실천 방법

- Pair Programming: 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눔

- Test-Driven Development: 개발자가 실제 코드를 작성하기 전에 테스트 케이스을 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악

- Whole Team: 개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함

- Continuous Integration: 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합

- Design Improvement(Refactoring): 프로그램 기능의 변경 없이 단순화 유연성 강화 등을 통해 시스템을 재구성

- Small Releases: 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응

 

 

 

4. 현행 시스템 파악

 

현행 시스템 파악 절차

 

시스템 구성 파악

- 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원업무로 구분하여 기술

시스템 기능 파악

- 단위 업무 시스템이 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시

시스템 인터페이스 파악

- 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시

​

아키텍처 구성 파악

- 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성

소프트웨어 구성 파악

- 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시

​

하드웨어 구성 파악

- 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 이중화의 적용 여부를 명시

네트워크 구성 파악

- 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성

 

 

 

5. 개발 기술 환경 파악

 

개발 기술 환경의 정의

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

​

운영체제

- 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

운영체제 관련 요구사항 식별 시 고려사항

- 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

​

데이터베이스 관리 시스템

- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어

DBMS 관련 요구사항 식별시 고려사항

- 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

​

웹 애플리케이션 서버(WAS)

- 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

WAS 관련 요구사항 식별 시 고려사항

- 가용성, 성능, 기술 지원, 구축 비용

​

오픈 소스

- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로 오픈 소스 라이선스를 만족하는 소프트웨어

오픈 소스 사용에 따른 고려사항

- 라이선스의 종류, 사용자 수, 기술의 지속 가능성

 

 

 

6. 요구사항 정의

 

요구사항의 개념 및 특징

- 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄

- 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하에 하는데 도움을 줌

​

요구사항의 유형

기술하려는 내용에 따라

1) 기능 요구사항

- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

- 시스템의의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

2) 비기능 요구사항

- 시스템 장비 구성, 성능, 인터페이스, 데이터, 테스트, 보안, 품질, 제약사항, 프로젝트 관리, 프로젝트 지원 요구사항

(* 품질: 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성)

​

기술 관점과 대상의 범위에 따라

 

1) 시스템 요구사항

- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

2) 사용자 요구사항

- 사용자 관점에서 본 시스템이 제공해야 할 요구사항

​

요구사항 개발 프로세스

1) 요구사항 도출

- 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수립할 것인지를 식별하고 이해하는 과정

- 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유즈케이스 등이 있음

2) 요구사항 분석

- 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내가 위한 과정

3) 요구사항 명세

- 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것

4) 요구사항 확인

- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토

 

 

 

7. 요구사항 분석 기법

 

요구사항 분류

- 기능 요구사항과 비기능 요구사항으로 분류

- 하나 이상의 상위 요구사항에서 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지를 분류

- 개발할 제품에 관련된 것인지 개발 과정에 관한 것인지 분류

​

개념 모델링

- 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라고 하며, 이러한 모델을 만드는 과정을 모델링이라고 함

- 개념 모델은 문제의 주체인 개체 들과 그들 간의 관계 및 종속성을 반영

- 요구사항을 이해하는 이해관계자 별로 관점이 다양함로 그에 맞게 개념 모델도 다양하게 표현되어야 함

- 유즈케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델 등이 있음

- 모델링 표기는 주로 UML을 사용

​

요구사항 할당

- 요구사항을 만족시키기 위한 구성 요소를 식별

​

요구사항 협상

- 요구사항이 서로 충돌될 경우 이를 적절히 해결하는 과정

​

정형 분석

- 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정

 

 

 

8. 요구사항 확인 기법

 

요구사항 검토

- 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법

- 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서 등을 완성한 시점에 이루어짐

​

프로토타이핑

- 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성

1) 장점

- 빠르게 제작할 수 있으며, 반복되는 제작을 통해 발전된 결과물을 얻을 수 있음

- 최종 시스템을 완성하기 전에 추가/변경 요구사항이나 아이디어 등에 대한 피드백 가능

2) 단점

- 사용자의 관심이 핵심에서 벗어나 프로톹입 제작에만 집중될 수 있음

- 개발 대상의 일부만을 대상으로 프로토타입이 제작된 경우 대상 범위를 잘못 이해하여 사용성이 과대평가 될 수 있음

​

모델 검증

- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증

- 정적 분석 수행

​

인수 테스트

- 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

- 사용자 인수 테스트, 운영상의 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사 등이 있음

 

 

 

9. UML ***

 

UML의 개요 (Unified Modeling Language) : 통합 모델링 언어

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

- 객체지향 방법론의 장점을 통합하였으며, 객체 기술에 관한 국제표준화기구인 OMG에서 표준으로 지정

​

사물

- 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상

1) 구조 사물

- 시스템의 개념적, 물리적인 요소를 포현

- 클래스, 유즈케이스, 컴포넌트, 노드

2) 행동 사물

- 시간과 공간에 따른 요소들의 행위를 표현

- 상호작용, 상태 머신

3) 그룹 사물

- 요소들을 그룹으로 묶어서 표현

- 패키지

4) 주해 사물

- 부가적인 설명이나 제약조건 등을 표현

- 노트

​

관계

- 사물과 사물 사이의 연관성을 표현하는 것

1) 연관 관계

- 2개 이상의 사물이 서로 관련되어 있음을 표현

- 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현하나, 서로에게 영향을 주는 양방향 관계의 경우 화살표 생략

- 연관에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기

- 사람이 집을 소유하는 관계

- 교수는 학생을 가르치고 학생은 교수로부터 가르침을 받음

2) 집합 관계

- 하나의 사물이 다른 사물에 포함되어 있는 관계

- 포함하는 쪽과 포함되는 쪽은 서로 독립적

- 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현

3) 포함 관계

- 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현

- 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기를 함께함

- 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현

4) 일반화 관계

- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

- 구체적인 사물에서 일반적 사물 쪽으로 속이 빈 화살표를 연결하여 표현

5) 의존 관계

- 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현

- 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현

6) 실체화 관계

- 사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화 할 수 있는 관계를 표현

- 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현

​

다이어그램

- 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 주는 것

- 정적 모델링에서는 구조적 다이어그램, 동적 모델링에서는 행위 다이어그램을 사용

​

1) 구조적 다이어그램

- 클래스 다이어그램: 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현

- 객체 다이어그램: 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현

- 컴포넌트 다이어그램: 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현하며, 구현 단계에서 사용됨

- 배치 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하며, 구현 단계에서 사용됨

- 복합체 구조 다이어그램: 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

- 패키지 다이어그램: 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

​

2) 행위 다이어그램

- 유스케이스 다이어그램: 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용

- 시퀀스 다이어그램: 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현

- 커뮤니케이션 다이어그램: 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지 뿐만 아니라 객체들 간의 연관까지 표현

- 상태 다이어그램: 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현

- 활동 다이어그램: 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

- 상호작용 개요 다이어그램: 상호작용 다이어그램 간의 제어 흐름을 표현

- 타이밍 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현