[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(요구사항 확인)

  -  1  -  요구사항 확인

 

 

 

1. 소프트웨어 생명 주기

 

소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕으로 운용, 유지보수 등의 과정을 단계별로 나눈 것

소프트웨어 개발단계와 각 단계별 주요 활동을 산출물로 표현

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

종류 : 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형.

 

 

 

 

 

 1) 폭포수 모형

•  폭포에서 한번 떨어진 물은 거슬러 올라 갈 수 없음
•  각 단계를 확실히 매듭 지음
•  각 단계를 철저하게 검토
•  가장 오래되고 가장 폭넓게 사용된 전통적 모형 -> 고전적 생명 주기 모형
•  선형 순차적 모형
•  제품의 메뉴얼 작성
•  두 개 이상의 과정 병행 수행 할 수 없음

 

순서

타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 시험 -> 유지보수

 

 

 

 

 2) 프로토타입 모형

•  실제 개발될 소프트웨어의 Prototype을 만들어 최종 결과물을 예측
•  사용자와 시스템 사이의 인터페이스에 초점
•  시스템 모형의 골격 코드
•  폭포수 모형의 단점 보안

 

순서 반복

요구 수집 -> 설계 -> 구축 -> 평가 -> 조정 -> 구현 -> 요구수집

 

 

 

 

 

 3) 나선형 모형

•  보헴(Boehm) 제안
•  위험 분석 기능 추가
•  여러 번의 개발 과정과 검토 과정을 거치는 점진적 모형
•  위험 관리와 리스크 최소화
•  별도의 유지보수 과정 필요 없음

 

순서 반복

계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가

 

 

 

 

 4) 애자일 모형

•  민첩한, 기민함 이라는 의미. 요구사항 변화에 유연하게 대응 가능한 모형으로 일정한 주기를 반복하며 개발
•  고객과의 소통에 초점을 맞춘 방법론
•  스프린트 또는 이터레이션 개발 주기 반복
•  고객이 요구사항에 우선순위를 부여함
•  급변하는 요구사항 환경에 적합
•  애자일 모형 기반의 종류 : 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD

 

 

 

 

 

 

 

 

 

2. 스크럼(Scrum) 기법

 

 

 

1) 스크럼

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

 

제품 책임자(PO)

• 제품에 대한 이해도가 높고, 요구사항을 책임지며, 주로 개발 의뢰자나 사용자가 담당
• 이해관계자들의 의견을 종합해 제품에 대한 요구사항 작성
• PO는 요구 사항이 담긴 백로그를 작성하고 백로그 우선 순위를 지정할 수 있다.
• 그 밑의 팀원은 백로그 스토리를 작성하고 우선순위를 갱신할 수 있지만 백로그 우선순위는 지정하지 않는다. 
• 주기적으로 우선순위를 갱신

스크럼 마스터(SM) : 객관적인 시각에서 팀원에게 조언해주는 가이드. 일일 스크럼 회의 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화해서 처리

개발팀(DT) : 개발자, 디자이너, 테스터 등

 

* PO는 요구사항과 우선순위를 작성해요!

* SM은 일일 스크럼 회의를 주관해요!

 

 

 

 

 

2) 스크럼 개발 프로세스

 

스크럼 개발 진행 순서

• 제품 백로그 : 제품 개발에 필요한 요구사항을 우선순위에 따라 나열한 로그 리스트. 지속적으로 업데이트되며, 사용자 스토리 기반의 릴리즈 계획 수립
• 스프린트 계획 회의 : 수행할 작업에 대한 단기적 일정. 태스크(Task) 작업 단위로 분할. 개발자별로 수행할 작업 목록인 스프린트 백로그 작성
• 스프린트 : 실제 개발 작업 과정. 개발자가 원하는 태스크를 담당할 수 있도록 함. 할 일(Todo), 진행 중(In Progress), 완료(Done)의 상태로 태스크 관리
• 일일 스크럼 회의 : 15분 정도의 짧은 시간으로 진행상황을 점검하고 남은 작업 시간을 소멸 차트에 표시한다.
• 스프린트 검토 회의 : 제품 책임자(PO)는 개선할 사항에 대한 피드백을 정리 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트함
• 스프린트 회고

 

* 제품 요구사항을 기반으로 계획을 수립하고, 스프린트를 진행하기 위해 회의하고, 실제로 스프린트를 진행하며, 날마다 일일 스크럼 회의를 진행하며, 전체적으로 스프린트에 대해 PO가 검토하고 피드백합니다.

 

 

 

 

 

 

3. XP(eXtreme Programming) 기법

•  고객의 요구 사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화함 -> 개발 생산성 향상
•  고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발
•  릴리즈 기간을 짧게 반복 -> 요구사항에 대한 가시성 높임
•  릴리즈 테스트 마다 고객을 직접 참여
•  소규모 프로젝트에 효과적
•  핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

 

 

 

 

 1) XP 개발 프로세스

•  사용자 스토리 : 요구사항 간단한 시나리오로 표현. 기능 단위 구성.
•  릴리즈 계획 수립 : 부분적으로 기능이 완료된 제품 제공
•  스파이크 : 요구사항 신뢰도를 높이고, 기술 문제의 위험 감소를 위해 별도로 만드는 프로그램
•  이터레이션 : 하나의 릴리즈를 더 세분화한 단위
•  승인 검사(인수 테스트) : 계획된 릴리즈 단위가 부분 완료가 구현되면 고객이 직접 수행해서 테스트함.
•  소규모 릴리즈

 

 

XP의 주요 실천 방법

Pair Programming(짝 프로그래밍)	다른 사람과 함께 프로그래밍을 수행함으로 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성
Test-Driven Development (테스트 주도 개발)	테스트 케이스를 먼저 작성해 자신이 무엇을 해야할지 정확히 파악 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구 사용
Whole Team(전체 팀)	개발에 참여하는 모든 구성원은 각자의 역할에 따른 책임을 가져야함
Continuous Integration (계속적인 통합)	모듈 단위로 나눠서 개발된 코드는 작업이 마무리 될 때마다 지속적으로 통합됨
Design Improvement (디자인 개선 또는 리팩토링)	프로그램 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
Small Releases (소규모 릴리즈)	릴리즈 기간을 짧게 반복해 고객의 요구 변화에 신속히 대응

 

 

 

 

 

 

 

4. 요구사항 정의

 

 

 1) 요구사항의 개념 및 특징

 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 운영에 대한 필요한 제약조건이다. 요구사항은 유지보수 과정에서 기준과 근거를 제공하고 개발자들 및 이해관계자들 간의 의사소통을 원활하게 한다.

 

 

 

 

 

 2) 요구사항의 유형

기술하는 요구사항에 따라 나뉨

 

 

기능 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지?
• 입출력의 결과는?
• 어떤 데이터를 저장하고 어떤 연산을 수행하는지?
• 사용자가 시스템에게 어떤 기능을 제공받고 싶은지?

비기능 요구사항

• 하드웨어, 소프트웨어, 네트워크 등의 시스템 장비 구성
• 처리 속도 및 시간, 처리량, 가용성
• 다른 시스템과의 정보 교환에 대해 사용되는 프로토콜
• 보안이 필요한 데이터는 무엇인지?
• 장비의 성능 테스트
• 시스템의 데이터 및 기능, 운영 접근 통제 관련 보안적 요구사항. 품질 요구사항
• 사전에 파악된 기술, 표준, 업무, 법, 제도 등의 제약조건

사용자 요구사항

시스템 요구사항 = 소프트웨어 요구사항

 

 

 

 

 

 

3) 요구사항 개발 프로세스

순서

도출 -> 분석 -> 명세 -> 확인

 

 

도출

•  시스템, 사용자, 개발자가 의견을 교환하여 요구사항을 식별하고 이해하는 과정.
•  이해관계자 식별
•  다양한 이해관계자 간의 의사소통 중요
•  소프트웨어 개발 생명주기(SDLC) 반복
•  요구사항 도출 방법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스(사용사례)

분석

•  요구사항 중 명확하지 않거나 모호한 부분을 걸러내는 과정
•  타당성을 조사. 비용과 일정에 대한 제약 설정

명세

•  요구사항을 체계적으로 분석 한 후 승인될 수 있도록 문서화함
•  기능 요구사항은 완전하고 명확하게 기술하고, 비기능 요구사항은 필요한 것만 명확하게 기술

확인

•  개발 자원을 요구사항에 할당하기 전에 명세서가 정확하고 완전하게 작성되었는지를 검토
•  정확한 이해 후 확인이 필요
•  일관성이 있는지, 누락된 기능이 없는지 검증하는 과정이 중요
•  요구사항 관리 도구를 이용하여 요구사항 정의 문서를 형상 관리 해야 함