요구사항 분석의 개요

• 사용자 요구의 타당성 조사, 비용과 일정에 대한 제약 설정
• 정확하고 일관성 있게 분석해서 문서화해야 함

구조적 분석 기법

• 자료의 흐름과 처리를 중심으로
• 도형 중심의 분석용 도구 -> 사용자간 의사소통 용이
• 하향식 방법, 시스템을 세분화할 수 있고 분석의 중복 배제 가능
• 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-spec), 개체 관계도(ERD), 상태전이도(STD), 제어 명세서

자료흐름도 (DFD) (= 자료 흐름 그래프, 버블차트)

• 의미: 자료의 흐름 및 변환괒어과 기능을 도형 중심으로 기술하는 방법
• 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프
• 자료는 process를 거쳐 변환될 때마다 새로운 이름이 부여됨
• 프로세스(Process), 자료흐름(Flow), 자료저장소(Data store), 단말(Terminator)의 4가지 기본 기호로 표시

자료사전(DD)

• 의미: 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 메타데이터라고도 한다.

표기 기호

• =: 자료의 정의, ~로 구성되어 있다(be compose of)
• +: 자료의 연결, 그리고(and)
• (): 자료의 생략, 생략 가능한 자료(optional)
• [|]: 자료의 선택, 또는(or)
• {}: 자료의 반복, interation of
• * *: 자료의 설명, 주석(comment)

요구사항의 개념 및 특징

• 뜻: 소프트웨어가 어떤 문제를 해결하기 위해 제공되는 서비스에 대한 설명, 운영의 제약조건
• 개발이나 유지보수 과정에 필요한 기준과 근거 제공
• 이해관계자들의 의사소통 원활하게 해줌

요구사항의 유형

• 기술하는 내용에 따라 달라짐

기능 요구 사항(Functional requirements)

• 시스템이 뭘 하는지, 어떤 기능을 하는 지, 시스템의 입력과 출력으로 무엇이 포함 되어야 하는지, 시스템이 반드시 수행해야 하는 기능

비기능 요구 사항(Non-functional requirements)

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

요구 사항 개발 프로세스

• 요구사항 도출 -> 분석 -> 명세서(specific document) -> 확인 및 검증
• 요구사항 개발 프로세스 전에 프로세스의 타당성 조사 진행

요구사항 도출

• 요구사항이 어디 있는지 어떻게 수집할 것인지 식별하고 이해되는 과정
• 소프트웨어 생명 주기 동안 주기적으로 반복
• 요구사항을 도출하는 주요기법: 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

요구사항 분석

• 요구사항 중 명확하지 않거나 모호한 부분을 발견하고 걸러내기 위한 과정
• 타당성 조사, 비용과 일정에 대한 제약 설정
• 자료흐름도(DFD), 자료 사전(DD)등의 도구 사용

요구사항 명세

• 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
• 기능 요구사항 -> 완전하고 명확하게, 비기능 요구사항 -> 필요한 것만 명확하게
• 설치 과정에서 잘못되면 요구사항 정의서에서 그 내용을 추적할 수 있어야 함
• 소단위 명세서 사용될 수 있음

요구사항 명세 기법

• 정형 명세기법: 수학적원리, 모델 기반, 결과가 작성자와 상관없이 동일 하므로 완전성 검증 가능(VDM, Z, Petri-net, CSP)
• 비정형 명세기법: 자연어를 기반으로 서술 또는 다이어그램으로 작성, 일관성 떨어짐 (FSM, Decision Tabke, ER모델링, State chart)

요구사항 확인

• 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확한지 검토
• 요구 사항 관리도구를 이용하여 요구사항 정의 문서들에 대한 형상관리를 수행한다.

형상: 프로그램을 설명하는 문서, 데이터들을 통칭 / 형상관리: 모든 형상들의 변경 사항을 관리하는 일련의 활동

개발 기술 환경의 정의

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

운영 체제(OS; Operating System)

• 운영 체제 -> 컴퓨터 시스템 자원 효율적 관리
• 사용자와 하드웨어 간 인터페이스

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

• 가용성: 장시간 운영으로 인한 장애, 메모리 누수 , 보안/에러 패치로 인한 재가동
• 성능: 대규모 사용자 처리, 대용량 파일 처리, 지원가능한 메모리 크기(32bit, 64bit)
• 기술 지원: 제작자의 기술지원, 여러 사용자간 커뮤니티, 오픈소스 여부
• 주변기기: 설치 가능한 하드웨어, 주변 기기 지원 여부
• 구축 비용: 히드웨어 비용, 라이선스, 유지관리 비용, 총 소유비용(TCO)

데이터베이스 관리 시스템(DBMS; DataBase Management System)

• 사용자와 데이터 베이스 사이에서 사용자의 요구에 따라 정보를 생성, 데이터베이스를 관리
• 기존 파일 시스템(각 응용 프로그램들이 개별적으로 자기 데이터를 file로 관리)의 데이터 종속성과 중복성 문제 를 해결하기 위해 제안됨
• 데이터 종속성: 데이터의 구성방식이나 접근 방법에 대한 응용 프로그램과 데이터 간의 상호 종속 관계
• 데이터 중복성: 같은 데이터를 여러 응용 프로그램에서 이용해야 하는 경우
• 모든 응용 프로그램이 데이터베이스를 공용 할 수 있도록 관리
• 데이터베이스 구성, 접근 방법, 유지관리 에 대한 모든 책임을 짐
• Oracle, DB2, MS SQL Server, MySQL, SQLite, MongoDB, Redis

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

• 가용성: 백업/복구의 편의성, DBMS 이중화 지원 여부
• 성능: 대규모 데이터 처리, 분할 테이블 지원 여부, 대용량 트랜잭션 처리, 다양한 튜닝 옵션, 비용기반 질의 최적화(질의의 대한 다양한 실행방법을 만들고 각각의 방법에 대한 비용을 추정)
• 기술지원: 제작자의 기술지원, 커뮤니티, 오픈소스
• 상호 호환성: 설치 가능한 운영체제, JDBC/ODBC 여부(JDBC: 자바와 DB를 연결해주는 인터페이스, ODBC: 응용 프로그램과 DB를 연결해주는 인터페이스)
• 구축 비용: 라이선스,, 유지관리, 총 소유비용

웹 어플리케이션 서버(WAS; Web Application Server)

• 정적인 콘텐츠 -> 웹서버, 동적인 콘텐츠 -> 웹 어플리케이션 서버
• 데이터 접근, 세션 관리, 트랜잭션 관리 를 위한 라이브러리
• 주로 데이터베이스 서버와 연결
• TomCat, GlassFish, JBoss, Jetty, JEUS, Resin,, Web Logic, Websphere

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

• 가용성: 고유적인 장애, 안정적 트랜잭션, WAS 이중화 지원여부
• 성능: 대규모 트랜잭션 처리 여부, 다양한 설정 옵션, 가비지 콜렉션(사용하지 않는 메모리 공간을 강제로 해제하는 기법) 지원
• 기술지원: 안정적인 기술지원, 커뮤니티, 오픈 소스 여부
• 구축 비용: 라이선스, 유지/보수 비용, 총 소유 비용

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

• 오픈소스: 누구나 별 다른 제한 없이 사용할 수 있도록 소스코드를 공개한 것, 오픈소스 라이선스를 만족하는 소프트웨어
• 라이선스의 종류, 사용자 수, 기술의 지속 가능성 을 고려

현행시스템 파악 절차

• 왜 현행 시스템을 파악해야 하는가?: 새로운 소프트웨어의 시스템 개발 범위 를 명확히 설정하기 위해
• 절차: 시스템 구성, 기능, 인터페이스 파악 -> 아키텍처, 소프트웨어 구성 파악 -> 하드웨어, 네트워크 구성 파악

시스템 구성 파악

• 현행 시스템의 구성 -> 기간 업무(조직의 주요업무) + 지원 업무
• 단위 업무 정보시스템들의 명칭, 주요기능 명시

시스템 기능 파악

• 현행 시스템의 기능을 주요기능 > 하부기능 > 세부기능 으로 계층형으로 구분

시스템 인터페이스 파악

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

아키텍처 구조 파악

• 아키텍처 구성도 로 기술 요소들을 계층별로 표현
• 업무별로 아키텍처가 다를 땐 가장 핵심이 되는 기간 업무 처리시스템의 아키텍처를 기준으로 한다.

소프트웨어 구성 파악

• 업무별로 설치되어 있는 소프트웨어 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다.
• 시스템 구축 비용 중 소프트웨어 비용이 비중 多 -> 라이선스 적용 방식의 기준과 보유한 라이선스의 파악이 중요

하드웨어 구성 파악

• 서버의 주요 사항과 수량, 이중화 작용 여부 명시
• 이중화(Replication): 서버에 문제가 생겨도 대기서버로 서비스할 수 있도록 서버의 자료변경을 대기서버에도 적용하게 하는 것
• 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정 된다.
• 현행 시스텡메 이중화가 적용되면 새로 구성될 시스템에도 필요하므로, 이로 인한 비용 증가와 시스템 구축 난이도가 높아질 가능성을 고려해야 함

네트워크 구조 파악

• 서버의 위치, 네트워크 연결 방식을 네트워크 구성도 로 작성
• 서버의 물리적 위치 파악 가능, 보안 취약점 분석
• 네트워크 장애시 발생원인을 찾아 복구하기 위한 용도

XP (eXtream Programming)

• 뜻: 생산성 향상을 위해 고객의 참여와 개발과정 반복을 극대화

• 특징

  • 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여 -> 소프트웨어 빠르게 개발
  • 릴리즈 기간 ↓, 요구반영 가시성 ↑
  • 테스트 마다 고객 직접 참여
  • 소규모 인원 개발 프로젝트에 효과적

• XP의 5가지 핵심가치

  • 의사소통
  • 단순성
  • 용기
  • 존중
  • 피드백

XP 개발 프로세스

사용자 스토리(User Story)

• 요구사항 시나리오(ex. 고객은 상품 주문을 위해 로그인을 수행해야 한다)
• 기능단위로 구성, 테스트 사항 기재

릴리즈 계획 수립(Release Planning)

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

스파이크(Spike)

• 요구사항 대한 신뢰성을 높이고 기술문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램
• 처리할 문제 외의 다른 조건은 무시

이터레이션(iteration)

• 하나의 릴리즈를 더 세분화한 단위
• 새로운 스토리가 작성될 수 있음

승인 검사(Acceptance test, 인수 테스트)

• 소규모 릴리즈 -> 고객의 반응을 기능별로 확인
• 릴리즈 기간이 완료되면 고객에 의한 최종 테스트 후 릴리즈

XP의 주요 실천 방법

• Pair Programming: 다른 사람과 같이 프로그래밍하고 개발에 대한 책임을 나눔
• Collective Ownership: 코드에 대한 권한과 책임을 공동 소유
• Test-Driven Development: 코드 작성전 테스트 케이스를 먼저 작성, 자동화된 테스트 도구 사용
• Whole Team: 모든 구성원은 역할에 대한 책임을 져야 함
• Continuos integration: 모듈 단위로 구성된 코드들을 지속적으로 통합
• Design improvementL 기능 변경 x, 단순화와 유연성 강화로 시스템 재구성
• Small Release: 릴리즈 기간 짧게, 요구변화 신속 대응

스크럼의 개요

• 뜻: 팀이 중점이 되어 개발의 효율성으 높인다.
• 특징: 팀원 스스로가 스크럼 팀을 구성(self-organization)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 함
• 제품 책임자(Product Owner), 스크럼마스터(Scrum master), 개발팀(Develop Team)으로 구성

제품 책임자(PO; Product Owner)

• 요구 사항을 책임지고 의사결정을 하는 사람
• 업무: 요구사항이 담긴 백로그 작성, 우선순위 정하기, 주기적으로 우선순위 갱신
• 다른 팀원들은 우선순위 결정 x

스크럼 마스터(SM; Scrum mater)

• 스크럼팀을 객관적인 시각에서 조언, but 팀원 통제 X
• 업무: 스크럼 회의 주관, 진행 상황 점검, 개발 장애요소 공론화

개발팀(DT; Development Team)

• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

스크럼 개발 프로세스

제품 백로그

• 요구사항(user story)을 우선순위에 따라 나열한 목록
• 백로그에 작성된 사용자 스토리를 기반으로 릴리즈 계획(release plan) 수립

스프린트 계획 회의

• 백로그 중 이번 스프린트에 수행할 작업을 대상으로 단기일정 수립
• 요구사항 -> 태스크로 분할 -> 개발자 별 스프린트 백로그 작성

스프린트

• 개발 작업을 수행하는 과정
• 태스크 별로 작업시간을 추정한 후 개발 담당자에게 할당
• 개발자가 원하는 태스크를 담당할 수 있어야 함
• 태스크를 할 일(To Do), 진행중(In progress), 완료(Done)의 상태를 갖는다.

일일 스크럼 회의

• 모든 팀원이 진행상황을 점검
• 남은 작업은 소멸차드에 표사
• 스크럼 마스터는 장애요소를 해결할 수 있도록 도와준다.

스프린트 검토 회의

• 부분 또는 완성제품이 요구사항에 잘 부합하는지 사용자가 포함된 참석자 앞에서 테스트
• 피드백 정리, 제품 백로그 업데이트

스프린트 회고

• 주기를 되돌아보며 규칙을 잘 준수했는지, 개선할 점은 없는지 확인하고 기록

소프트웨어 생명 주기

• 뜻: 소프트웨어를 개발하기 위해 정의하고 운용, 유지 보수등의 과정을 단계별로 나눈 것
• 개발 단계 + 단계별 활동 + 산출물
• (= 소프트웨어 생명주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임

폭포수 모형(Waterfall model)

• 뜻: 각 단계를 확실히 매듭짓고 그 결과를 검토하여 승인과정을 거친 후 다음 단계를 진행
• 특징: 가장 오래되고 사용 多, 선형 순차적 모형, 매뉴얼 작성, 각 단계마다 결과물 이 명확히 산출 되어야 함
• 절차: 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 시험 -> 유지/보수

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

• 뜻: 소프트웨어의 견본 을 만들어 최종 결과물을 예측하는 모형
• 특징: 시제품은 사용자와 시스템 사이 인터페이스 에 중점, 폭포수 모형 단점 보완

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

• 뜻: 나선을 돌듯이 여러번의 소프트웨어 개발 과정 을 거쳐 점진적 으로 완벽한 최종 소프트웨어를 개발
• 특징: 폭포수 + 프로토타입 + "위험 분석 기능", 위험 관리 가 목적, 점진적으로 요구사항 첨가 가능, 유지보수 필요 X
• 절차: 계획 -> 위험분석 -> 개발 및 검증 -> 고객 평가 -> 반복

애자일 모형(Agile model)

• 뜻: 특정 개발 방법론 x, 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통 에 초첨을 맞춘 방법론
• 특징
  • 요구 사항에 유연하게 대응할 수 있도록 일정 주기(스프린트, 이터레이션) 를 반복하면서 개발과정 진행
  • 반복되는 주기마다 요구사항 적극 반영
  • 요구 사항에 우선순위 를 정함
  • 소규모 + 숙달된 개발자 + 급변하는 요구 사항에 적합
• 애자일 모형 기반: 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발

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

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