요구사항 확인 A
- 소프트웨어 생명주기란 SW개발을 단계별로 나눔
- 비용 및 개발 계획의 골격
- 표준화를 가능하게 함
- 프로젝트 관리에 용이함
1. 폭포수형 모형
- 폭포수 모델은 완전히 순차적으로 진행
- 폭포수 모들은 전 단계가 수행되어 완료되기 전에는 다음 단계로 진행 할 수 없도록 제한한다.
- 1970년도부터 사용한 가장 전통적인 방법
- 폭포수는 사용자가 정확하게 요구사항을 얘기해줘야함. 수정 불가
계획
(타당성) -> 요구분석
(문서화) -> 설계
-> 구현
(코드화) -> 테스트
-> 유지보수
2. 프로토타입 모형
- 요구사항이 부정확
- 개발초기에 시스템의 모형(prototype)을 간단히 말들어 사용자에게 보여주고 진행
- 오류를 초기에 발견가능
- 변경에 용이함
- 모형을 만드는데에 비용/시간이 많이 투자됨
요구분석
-> 프로토타입 설계
-> 프로토타입 개발
-> 고객평가
3. 나선형 모형
계획수립
-> 위험분석
-> 개발
-> 고객평가
를 반복적으로 진행
- 비용이 많이 들며 대규모 시스템에서 적합함
4. 애자일
- 고객의 요구사항이 중심
- 소규모 프로젝트에서 적합함
- 고객의 요구사항이 있다면 우선순위를 부여해서 진행
- 개인상호작용에 더 작업의 가치를 둠
- 문서보다는 실행 sw에 대해 더 가치를 둠
- 계약보단 고객과의 협업에 더 가치를 둠
- 계획보단 변화 대응에 더 가치를 둠
- 애자일의 12가지 실험지침이 있음
요구사항 확인 B
- 분석모델에 대해 확인하고 현행 시스템에 대해 분석
현행 시스템 분석 필요 이유
- 소프트웨어 대한 이해도와 적용할 수 있는지 판단
- 개발하고자하는 OS와 DBMS의 적용에 대한 판단
- 시스템 분석하여 향후 개발/적용될 시스템에 대해서 구체적으로 기술 가능
- 지식 :
산업분야
, 플랫폼
, 프로젝트 환경
, 플랫폼
, 가상화
, 클라우드
- 기술 :
환경분석
, 운영체제
, 저장장치
, 네트워크
, DBMS
, 가상화
1. 플랫폼
플랫폼의 개념
- 소프트웨어를 구동시키는데 쓰이는 하드웨어와 소프트웨어의 결합
플랫폼의 기능
플랫폼의 기능 특정 확인 방법
현행 시스템 분석하기에서 플랫폼의 성능 특성을 알아야하는 이유
- 사용자가 사용하기에 속도가 느린지 빠른지 파악
- 현재 시스템의 플랫폼 성능
플랫폼 성능 특성 확인 방법
2. 현행 시스템 파악
현행 시스템 파악절차
- 1단계: 시스템 구성(업무 구분), 기능(주요기능, 하부기능, 세부기능), 인터페이스(데이터, 프로토콜 형식) 파악
- 2단계: 아키텍처(기술 요소) 구성, 소프트웨어(SW 제품명, 용도, 라이센스) 구성 파악
- 3단계: 하드웨어(서버) 구성, 네트워크(서버 구성) 구성 파악
3. 현행 시스템 파악
- 운영체제 분석
- 네트워크 분석
- DBMS 분석
- 비즈니스 융합 분석
4. 운영체제 분석
운영체제(OS)의 개념
현재 시스템의 운영체제를 분석한다
- 현재 운영 체제에 대한 종류, 버전에 대한 분석
운영체제의 종류 및 특징
유닉스
(대용량), 리눅스
(중/대형 서버), 마이크로소프트 윈도우
, 아이오에스
, 안드로이드
5. 네트워크 분석
네트워크의 개념
- 디지털 전기통신망
- 분산되어 있는 컴퓨터를 통신망으로 연결
- OSI 7 Layer의 정의(
물리
(LAN 구축), 데이터링크
(전송), 네트워크
(라우터), 전송
(전송~종단), 세션
(연결), 표현
(암호화), 응용 계층
(서비스))
현재 시스템의 네트워크를 분석한다.
- 네트워크 구조를 분석, 사내 인터넷(
IDC
) 데이터 센터 분석
현재 시스템의 네트워크 구성도를 작성한다.
6. 데이터베이스 분석
데이터베이스의 개념
데이터베이스의 기능
- 중복성 통제, 데이터 공유, 데이터 접근 통제, 인터페이스 제공
- 관련성 표현, 무결성(정확한;
pk, fk
) 보장
현재 시스템의 데이터베이스 시스템을 분석한다
논리/물리 테이블의 구조 파악
7. 비즈니스 융합분석
비즈니스 융합의 개념
- 비즈니스 : 영리를 목적으로 행하는 모든 활동
- 비즈니스 모델 : 요소들의 구성체
- 비즈니스 융합 : 비즈니스 모델의 적용범위 확대
비즈니스 융합 유형
- 제품융합, 서비스융합, 제품과 IT융합, 서비스와 IT융합, 제품의 서비스화, 서비스의 제품화, 제품과 서비스 융합
비즈니스 융합 분석
- 고객 분석, 제품 및 서비스 분석, 사업구조 분석
요구사항 확인 C
요구사항
1. 요구사항의 개념
- 설명, 제약 조건을 기준 근거가 되고 의사소통이 됨.
2. 요구사항의 유형
- 기술하는 내용에 따라
- 기능 요구사항 - 시스템이 무엇을 또는 어떤 기능 그리고 기능과 제공
- 비기능 요구사항 - 장비, 성능, 인터페이스, 데이터, 테스트, 보안, 품질
- 기술관점과 대상의 범위에 따라
- 시스템 요구사항 - 개발자
- 사용자 요구사항 - 사용자
3. 요구사항 개발 프로세스
도출
-분석
-명세
-확인
- 요구사항 개발은 요구공학 중 하나
4. 요구사항 도출
- 요구사항에 대한 수집
- 개발자와 고객 간 관계 및 의사소통
- 방법으로는 -
인터뷰
, 설문
, 워크샵
, 브레인스토밍
, 프로토타입
5. 요구사항 분석
- 요구사항 수집한 내용을 걸러낸다
- 타당성, 비용, 일정, 범위 설정
6. 요구사항 명세
- 명세는 문서화
- 기능 요구사항은 완전 명확하게 명세해야하고 비기능은 필요한 것만
7. 요구사항 확인
요구사항 확인(응용SW엔지니어링)
- 지식 -
산업 분야
, 프로젝트
, 업무 특성
, 요구공학
, 소프트웨어
, 통계학
- 기술 -
유즈케이스 작성능력
, UML 작성기술
, 분석자동화 도구
, 요구사항 관리도구
, 리뷰진행
요구사항 분석
- 요구사항분석 기법
- 요구사항 분류 -
기능/비기능
, 제품/개발과정
, 우선순위
, 영향
, 변경
- 개념 모델링 - 단순화를 시키고 개념적으로 표현하는 것 (UML:
유즈케이스
, 데이터흐름도
, 목표기반모델
, 객체모델
)
- 요구사항 할당 - 구성요소를 식별 및 분석
- 요구사항 협상 - 일어난 문제에 대해 우선순위를 정하는 것
- 정형분석 - 언어를 수학적 기호로 표현한 후에 분석하는 것
요구사항 확인기법
- 요구사항 확인기법
- 요구사항 검토 - 명확, 가정, 기준이 맞는지 검토
- 프로토타이핑 - 모델하우스처럼 요구사항을 토대로 모형물을 만들고 반영
- 장점: 추가, 변경, 피드백 및 이해 및 의사소통이 쉬워짐
- 단점: 제작에만 집중 및 잘못된 이해 그리고 많은 비용 소모
- 모델 검증 - 요구사항이 충족되었는지 검증
- 인수 테스트 - 사용자 입장에서 요구사항이 충족되었는지 테스트
요구사항 확인 D
UML
1. 사물(Things)
- 행동 사물 - 시간/공간에 따라 행위 표현, 상호작용, 상태머신
- 그룹 사물 - 요소를 그룹별로 표현
- 구조 사물 - 시스템의 개념적 또는 물리적으로 표현
- 주해 사물 - 주석
2. 관계
- 연관 관계 - 두개 이상의 사물이 연관성을 표현(실선/방향)
- 집합 관계 - 하나의 사물이 다른 사룸에 포함 또는 의존을 표현(속이 빈 마름모)
- 포함 관계 - 집합 관계의 어떤 특수한 관계(속이 찬 마름모)
- 일반화 관계 - 상위 계층으로 화살표(실선)를 표현
- 의존 관계 - 짧은 시간동안 연관을 유지하는 것(점선)
- 실체화 관계 - 그룹화(점선)
3. 다이어그램
- 구조적 다이어그램(정적)
- 클래스, 객체
- 컴포넌트, 배치
- 복합체 구조, 패키지
- 행위 다이어그램(동적)
- 유스케이스, 시퀀스
- 커뮤니케이션, 상태
- 활동, 상호작용 개요, 타이밍