정처기 필기 요약 - 요구사항 확인

소프트웨어 생명 주기

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

소프트웨어 개발 단계와 각 단계별 주요 활동 및 활동의 결과를 산출물로 표현

소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고 한다

특정 모형을 선택하여 사용하거나 개별적인 모형을 사용할 수 있다

 

 

폭포수 모형

이전 단계를 확실히 마무리하고 다음 단계로 진행하는 개발 방법론

소프트웨어 공학에서 가장 오래되고 폭넓게 사용된 생명 주기 모형

한 단계가 끝나야 다음 단계로 넘어갈 수 있는 선형 순차적 모형

매뉴얼 작성 과정 필요

다음 단계로 넘어가기 위한 각 단계의 산출물이 나옴

1. 타당성 검토

2. 계획

3. 요구분석

4. 설계

5. 구현

6. 시험

6. 유지보수

 

프로토타입 모형

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

폭포수 모델의 단점을 보완하기 위한 모형

사용자와 시스템 사이의 인터페이스를 중심으로 개발

1. 요구 수집

2. 빠른 설계

3. 프로토타입 구축

4. 고객 평가

5. 프로토타입 조정

6. 구현

(필요하다면 다시 1번으로)

 

 

나선형 모형

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

나선을 따라 돌듯이 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발

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

요구사항 추가가 가능하다

유지보수 과정이 필요 없다

대규모 프로젝트에서 많이 쓰임

1. 계획 및 정의

2. 위험 분석

3. 공학적 개발

4. 고객 평가

(필요하다면 다시 1번으로)

 

 

애자힐 모형

고객의 요구사항의 변화에 유연하게 대처할 수 있도록 설계된 모형

고객과의 소통에 초점을 맞춘 모든 방법론을 통칭

스프린트 혹은 이터레이션이라고 불리는 짧은 개발 주기를 반복

매 주기마다 결과물에 대한 평가와 요구사항 수용

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

 

애자일 모형을 기반으로 하는 모형

- 스크럼

- XP

- 칸반

- 린 (Lean) 소프트웨어 개발

- 크리스탈 방법론 = 결정론

- ASD

- 기능 중심 개발 FDD

- 동적 소프트웨어 개발 방법 DSDM

 

 

애자힐 - 스크럼 기법

팀이 중심이 되어 개발의 효율성을 높임

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

 

<스크럼 기법의 구성 요소>

 

제품 책임자

• 개발될 제품에 대하여 이해도가 높고 요구사항을 책임지고 의사 결정할 사람
• 개발 의뢰자나 사용자가 담당
• 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성
• 백로그를 작성
• 팀원들이 백로그에 스토리를 추가할 수 있지만 우선순위를 정하는 것은 제품 책임자
• 테스트를 수행하면서 주기적으로 요구사항의 우선순위 갱신

스크럼 마스터

• 팀이 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할
• 일일 스크럼 회의를 주관하여 진행사항을 점검하고 개발과정에서 발생된 장애요소를 공론화하여 처리

개발팀

• 개발자 외에도 디자이너, 테이터 등 제품 개발을 위해 참여하는 모든 사람
• 보통 최대 인원은 7~8명이 적당

<스크럼 개발 프로세스>

 

제품 백로그

• 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록
• 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트
• 작성된 사용자 스토리를 기반으로 릴리즈 계획을 수립

스프린트 계획 회의

• 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
• 처리할 요구사항을 개발자들이 나워서 작업할 수 있도록 task라는 작업 단위로 나눠 개발자 별로 수행할 작업 목록인 스프린트 백로그 작성

스프린트

• 실제 개발 작업을 진행하는 과정
• 스프린트 백로그에 작성된 task를 대상으로 작업시간이나 양을 추정한 후 개발 담당자에게 할당
• task를 할당할 때는 개발자가 원하는 task를 직접 선별하여 담당할 수 있도록 하는 것이 좋음
• 할당된 task는 할 일, 진행 중, 완료의 상태를 가짐

일일 스크럼 회의

• 모든 팀원이 매일 약속된 시간에 짧은 시간 동안 진행 상황을 점검
• 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌
• 남은 작업 시간은 소멸 차트에 표시

스프린트 검토 회의

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

스프린트 회고

• 스프린트가 끝나고 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 점검하고 수행

 

애자힐 - XP 기법

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

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발하는 것이 목적

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

 

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

 

사용자 스토리 : 요구사항을 간단한 시나리오로 표현

릴리즈 계획 수립 : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것에 대한 계획 수림

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

이터레이션 : 하나의 릴리즈를 더 세분화한 단위

승인 검사 : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트로 사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행

소규모 릴리즈 : 고객의 반응을 기능별로 확인하고 고객의 요구사항에 유연하게 대응하고 진행된 이터레이션이 모드 완료되면 고객에 의한 최종 테스트 수행 후 최종 결과물을 고객에게 전달

 

<XP의 주요 실천 방법>

Pair Programming : 짝을 이뤄 다른 사람과 함께 프로그래밍

Test-Driven Development : 실제 코드 작성 전 테스트 케이스를 먼저 작성하여 무엇을 해야 할지 파악

Whole Team : 개발에 참여하는 모든 구성원은 각기 역할이 있어 책임을 다해야 함

Continuous Intergration : 모듈 단위로 나눠 개발한 코드는 하나의 작업이 마무리되면 지속적으로 통합

Design Improvement / Refactoring : 프로그램 기능의 변경 없이 시스템을 재구성

Small Release : 릴리즈 기간을 짧게 하여 고객의 요구 변화에 신속하게 대응

 

 

현행 시스템 파악

<1단계>

• 시스템 구성 파악 : 조직의 업무를 담당하는 기간 업무와 이를 지원하는 업무로 구분하여 나타낸 구성을 파악
• 시스템 기능 파악 : 현재 제공하는 기능들을 주요, 하부, 세부 기능으로 구분하여 계층형으로 표시
• 시스템 인터페이스 파악 : 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시

<2단계>

• 아키텍처 구성 파악 : 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 구성 파악
• 소프트웨어 구성 파악 : 업무 처리를 위해 설치되어 있는 소프트웨어의 제품명, 용도, 라이선스 적용 방식을 명시

<3단계>

• 하드웨어 구성 파악 : 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량 및 이중화 적용 방식 등을 명시
• 네트워크 구성 파악 : 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성

 

 

개발 기술 환경 파악

개발하고자 하는 소프트웨어와 관련된 O/S, DBMS, Middle Ware 등을 선정할 때 고려해야 할 사항을 기술하고 오픈 소스 사용 시 주의해야 할 내용을 제시

 

운영체제

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

요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

 

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

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

요구사항 식별 시 고려사항

: 가용성

성능

기술 지원

상호 호환성

구축 비용

 

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

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

요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

 

오픈 소스 (Open Source)

누구나 제한 없이 사용할 수 있도록 소스 코드를 공개한 것

라이선스를 만족하는 소프트웨어

요구사항 식별 시 고려사항 : 라이선스의 종류, 사용자의 수, 기술의 지속 가능성

 

 

요구사항

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

요구사항이 제대로 정의되어야 이를 토대로 이후 과정의 목표와 계획의 수립이 가능

 

요구사항의 유형

기술하는 내용에 따라서

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

- 비기능 요구사항 : 품질이나 제약사항에 대한 사항

 

기술 관점과 대상의 범위에 따른 분류

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

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

 

요구사항 개발 프로세스

1. 요구사항 도출

요구사항이 어디에 있고 어떻게 수집할지 식별하고 이해하는 과정

인터뷰, 설문, 브레인스토밍(3인 이상이 아이디어 산출), 워크샵, 프로토타이핑, 유스케이스(사용자의 요구 사항을 기능 단위로 표현) 등

 

2. 요구사항 분석

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

 

3. 요구사항 명세

요구사항을 분석한 후 승인될 수 있도록 문서화하는 과정

소프트웨어 요구사항 명세서 : 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건을 명시

 

- 정형 명세

: 시스템을 상태모형으로 인식, 집합과 수열 등의 수학적 요소로 표현

Z, B, VDM, Larch, OBJ, Lotos, Petri Nets, CSP 등이 있음

 

- 비정형 명세

: 자연어로 기술

 

4. 요구사항 확인

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

 

 

요구사항 분석 기법

 

요구사항 분류

요구사항을 명확히 확인할 수 있도록 정해진 기준으로 분류

- 기능/비기능 요구사항

- 제품/과정으로 분류

- 우선순위로 분류

 

개념 모델링

요구사항의 현실 세계의 상황을 단순화하여 개념적으로 표현하는 과정

현실 세계 문제에 대한 모델링은 요구사항 분석의 핵심

개체와 개체 간의 관계 및 종속성을 반영

개념 모델은 다양하게 표현

주로 UML 사용

 

요구사항 할당

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

 

요구사항 협상

요구사항이 서로 충돌될 경우 해결하는 과정

적절한 기준점을 찾아 합의하는 게 좋음

서로 충돌하는 경우 우선순위를 부여하면 해결에 도움이 됨

 

정형 분석

구문과 의미가 같은 정형화된 언어를 이용하여 요구사항을 수학적 기호로 표현하고 분석

 

 

요구사항 확인 기법

 

요구사항 검토

문서화된 요구사항을 흝어보면서 확인하는 과정

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

 

프로토타이핑

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

장점

- 빠르고 반복되는 제작을 할 수 있어 발전된 결과물을 얻을 수 있음

- 최종 시스템을 완성하기 전에 추가 또는 변경된 요구사항에 대한 피드백 가능

단점

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

- 지속적이고 반복적인 개선에 대한 비용이 부담이 될 수 있음

 

모델 검증

요구사항 분석 단계에서 개발된 모델이 요구사항을 충족하는지 검증하는 과정

 

인수 테스트

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

 

 

UML (Unified Modeling Language)

참고 자료 : gmlwjd9405.github.io/2018/07/04/class-diagram.html

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

객체지향 방법론의 장점을 통합하였으며 OMG(Object Management Group)에서 표준으로 지정

구성요소 : 사물, 관계, 다이어그램

 

사물 (Things)

모델을 구성하는 가장 중요한 기본 요소

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

 

- 구조 사물

시스템의 개념적, 물리적 요소 표현

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

 

- 행동 사물

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

상호 작용, 상태 머신 등

 

- 그룹 사물

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

패키지

 

- 주해 사물

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

노트

 

관계 (Relationship)

사물과 사물 사이의 연관성 표현

 

- 연관 관계

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

실선과 화살표로 연결하여 표현하지만 양방향 관계의 경우 화살표 없이 실선으로 연결하여 표현

 

- 집합 관계

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

부분 (포함되는 쪽)에서 전체(포함하는 쪽)로 속이 빈 마름모를 연결하여 표현

 

- 포함 관계

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

부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 채워진 마름모를 연결하여 표현

 

- 의존 관계

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

영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표 연결

 

- 일반화 관계

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

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

 

- 실체화 관계

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

사물에서 기능 쪽으로 속이 빈 점선 화살표 연결

 

다이어그램 (Diagram)

사물과 관계를 도형으로 표현

정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용

 

구조적 다이어그램

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

- 객체 다이어그램 : 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현

- 컴포넌트 다이어그램 : 구현 단계에서 사용되며 컴포넌트 간의 관계나 인터페이스를 표현

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

- 복합체 구조 다이어 그램 : 복잡한 구조를 가지는 클래스 혹은 컴포넌트의 내부 구조 표현

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

 

행위 다이어그램

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

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

- 커뮤니케이션 다이어그램 : 객체들이 주고받는 메시지를 표현할 뿐만 아니라 객체들 간의 연관까지 표현

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

- 활동 다이어 그램 : 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

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

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

 

 

 

 

2020 ~ 2022 정보처리기사 필기 출제 기준