[정보처리기사] 1장 요구사항 확인

소프트웨어 생명 주기

- 소프트웨어를 개발하기 위한 설계, 운영, 유지보수등의 과정을 각 단계별로 나눈 것

소프트웨어 개발 단계와 각 단계별 주요 활동 그리고 활동의 결과에 대한 산출물로 표현

 

종류

- 폭포수 모형

- 프로토타입 모형

- 나선형 모형

- 애자일 모형

 

폭포수 모형(waterfall model)

- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론

- 고전적 생명 주기 모형

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

 

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

- 실제 개발될 소프트웨어에 대한 견폰품을 만들어 최종 결과물을 예측

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

 

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

- 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형

- 보헴이 제안

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

- 유지보수가 필요 없다

- 요구사항 첨가 가능

 

[계획 수립 -> 위험분석 -> 개발 및 검증 -> 고객 평가]

 

애자일 모형

- 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형

- 고객과의 소통에 초점을 맞춤 방법론을 통칭

 

종류

- 스크럼

- XP

- 칸반

- Lean

- 기능 중심 개발(FDD)

 

핵심가치

- 프로새스와 도구보다는 개인과 상호작용에 더 가치를 둠

- 방대한 문서보다는 실행되는 SW에 더 가치를 둠

- 계약 협상보다는 고객과 협업에 더 가치를 둠

- 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 붐

 

소프트웨어 공학(SE)

- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문

- 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적

 

소프트웨어 공학의 기본 원칙

- 현대적인 프로그래밍 기술을 계속적으로 적용해야 함

- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함

- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지 해야함

 

스크럼

- 팀이 중심이 되어 개발의 효율성을 높이는 기법

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

 

스크럼 팀

제품 책임자(PO:Product owner): 요구사항이 담긴 백로그를 작성하는 주체, 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정

스크럼 마스터(SM:Scrum master):스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함

개발팀(DT): 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함

 

*백로그: 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록

*이해관계자: 소프트웨어 개발과 관련해 이해관계자는 소프트웨어 개발 의뢰자, 개발자, 사용자

 

[스프린트 계획 회의 -> 진행(스프린트) -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고]

 

XP(eXtreme Programming)

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

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

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

 

XP의 5가지 핵심가치

- 의사소통

- 단순성

- 용기

- 존중

-피드벡

 

XP 개발 프로세스

필리즈 계획 수립 -> 이터레이션 (주기)-> 승인 검사(인수테스트) -> 소규모 릴리즈

 

XP의 주요 실천 방법

Pair Programming(짝 프로그래밍): 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성

 

Collective Ownership(공동 코드 소유): 개발 코드에 대한 권한과 책임을 공동으로 소우

 

Test-Driven Development(테스트 주도 개발): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악, 테스트가 지속적으로 진행될 수있도록 자동화된 테스팅 도구(프레임 워크)를 사용함

 

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

 

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

 

Refactoring(리팩토링): 프로그램 기능의 변경 없이 시스템을 재구성함, 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함

 

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

 

개발 기술 환경 파악

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

 

운영체제(OS)

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

- 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어

 

*미들웨어: 미들웨어는 운영체제와 해당 운영체제에 의해 실행하는 응용프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어

 

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

- 가용성

- 성능

- 기술 지원

- 주변 기기

- 구축 비용

 

데이터베이스 관리 시스템(DBMS)

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

-데이터의 종속성과 중복성의 문제를 해결하기 위함

 

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

- 가용성

- 성능

- 기술 지원

- 상호 호환성

- 구축 비용

 

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

- 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어

- 데이터베이스 서버와 연동해서 사용

 

웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항

- 가용성

- 성능

- 기술 지원

- 구축 비용

 

오픈소스(Open Source)

- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어

 

오픈 소스 관련 요구사항 식별 시 고려사항

- 라이선스의 종류

- 사용자 수 

- 기술의 지속 가능성

 

요구사항

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

- 개발에 참여하는 이해관계자들 간의 의사소통을 원할하게 하는 데 도움을 줌

 

요구사항의 유형

- 기능 요구사항

- 비기능 요구사항

- 사용자 요구사항

- 시스템 요구사항

 

기능 요구사항

- 기능이나 수행과 관련된 요구사항

-  반드시 수행해야 하는 기능

 

비기능 요구사항

- 품질이나 제약사항과 관련된 요구사항

- 시스템 장비 구성 요구사항

- 성능 요구사항

- 인터페이스 요구사항

- 데이터를 구축하기 위해 필요한 요구사항

- 테스트 요구사항

- 보안 요구사항

- 프로젝트 관리 요구사항

- 프로젝트 자원 요구사항

 

사용자 요구사항

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

- 사용자를 위한것이므로, 친숙한 표현, 이하해기 쉽게 작성

 

 

시스템 요구사항

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

- 전문적이고 기술적인 용어로 표현

- 소프트웨어 요구사항

 

 

요구사항 개발 프로세스

- 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동

- 요구사항 개발 프로세스가 진행되기 전에 타당성 조사가 선행 필요

- 요구사항 개발은 요구공학의 한 요소

 

도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

 

요구사항 도출(요구사항 수집)

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

-개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별

-소프트웨어 개발 생명 주기 동안 지속적으로 반복

 

요구사항을 도출하는 주요 기법

-청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

 

요구사항 분석

- 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

- 요구사항의 타당성을 조사, 비용과 일정에 대한 제약 설정

- 상충되는 요구사항이 있으면 이를 중재하는 과정

 

요구사항 분석에 사용되는 대표적인 도구

- 자료 흐름도(DFD)

- 자료사전(DD)

 

요구사항 명세

- 분석된 요구사항을 바탕으로 모델을 작성, 문서화

- 기능 요구사항을 빠짐없이 기술

- 비기능 요구사항은 필요한 것만 기술

- 소단위 명세서가 사용될 수 있음

 

요구사항 확인(요구사항 검증)

- 요구사항에 명세서가 정확하고 완전하게 작성되었는지 검토

- 요구사항 관리도구를 이용해 형상 관리 수행

 

요구홍각

- 요구사항을 정의하고, 분석 및 관리;하는 프로세스를 연구하는 학문

- 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표

 

요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	생태/기능/객체 중심
작성기법	수학적 기호, 정형화된 표기법	일반 명서, 동사 등의 자연어 기반, 다이어그램
특징	정확하고 간결허게 표현가능 표기법이 어려워 사용자가 이해하기 어려움	자연어의 사용으로 요구사항에 대한 결과가 작성자에 따라 다를 수 있음, 일관성이 떨어짐 내용의 이해가 쉬워 의사소통 용이
종류	VDM, Z, CSP	FSM,ER 모델링,State Chart

 

요구사항 분석

- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동

- 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정

 

구조적 분석 기법

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

-도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화

- 하향식 방법을 사용하여 시스템을 세분화

 

주요 구조분석 기법 도구

- 자료흐림도(DFD)

- 자료 사전(DD)

- 소단위 명세서

- 개체 관계도

- 상태 전이도

- 제어 명세서

 

자료흐름도(DFD)

- 자료의 흐름 및 변환과정과 기능을 도형 중심으로 기술하는 방법

-프로세스, 자료 흐름, 자료 저장소, 단말

 

자료 사전(DD)

- 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한것

- 자료의 정의 = , 자료의 연결 + , 자료의 생략 ( ) , 자료의 선택 [ ] , 자료의 반복 { } , 자료의 설명 * *  

 

요구사항 분석용 CASE(자동화 도구)

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

-SADT, SREM, PSL/PSA,TAGS

 

HIPO

- 시스템의 분석 및 설계, 문서화에 사용되는 기법, 시스템 실행 입력-처리-출력의 기능을 표현한 것

- 하향식 소프트웨어 개발을 위한 문서화 도구

- 기능과 자료의 의존 과계를 동시에 표현 가능

- 기호, 도표 등을 사용하므로 보기 쉽고 이해가 쉬움

- 가시적 도표(Visual Table of Contents, 도식 목차), 총체적 도표(Overview Diagra, 총괄 도표, 개요도표), 세부적 도표(Detail Diagram, 상세도표)

 

UML(Unified Modeling Language)

- 시스템 개발 과정에서 시스템 개발자와 고객 개발자 상호 간의 의사소통이 원할하게 이루어지도록 표준화한 객체지향 언어

- 럼바우, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

 

UML 구성요소

- 사물(Things)

- 관계(Relationships)

- 다이어그램(Diagram)

 

사물

- 다이어그램 안에서 관계가 형성될 수 있는 대상들

- 모델을 구성하는 기본요소

- 구조 사물( 개념적, 물리적), 행동 사물(시간, 공간), 그룹 사물(요소들을 그룹), 주해 사물(부가적인 설명, 제약조건)

 

관계 사물과 사물 사이의 연광성을 표현

 

연관 관계(Association)

- 2개 이상의 사물이 서로 관련되어 있는 관계

- 사물 사이를 실선으로 연결하여 표현( ->)

 

집합 관계(Aggregation)

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

 

포함 관계(Composition)

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

 

일반화 관계(Generalization)

- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계( -▷)

 

의존 관계(Dependency)

- 서로에게 영향을 주는 짧은 기간 동안만 연관을 유지하는 관계(-->)

 

실체화 관계(Realization)

- 사물이 할 수 있거나 해야하는 기능, 서로를 그룹화 할수 있는 관계( --▷)