요구사항

요구사항 개념

1. 요구공학의 개념 :  사용자의 요구가 반영된 시스템 개발을 위해 요구사항에 대한 도출, 분석, 명세 확인 및 검증하는 구조화된 활동

 

2. 요구공학의 목적 

- 이해관계자 사이에 효과적 의사소통 수단 제공, 시스템 개발의 요구사항에 대한 공통된 이해 설정

- 요구사항 누락 방지 및 이해 오류로 인한 불필요 비용 절감, 요구사항 변경 추적 용이

- 초기 요구사항 관리로 개발 비용과 시간 절약, 효과적인 의사소통 수단 제공

 

3. 요구사항의 분류

구분 기능적 요구사항 비기능적 요구사항
개념 · 시스템이 제공하는 기능, 서비스 · 시스템 구축에 대한 제약사항
도출
방법
· 특정 입력에 대한 반응
· 특정 상황에 대한 동작
· 품질 속성에 관련하여 시스템이 갖춰야 할 사항
· 시스템이 준수해야할 제한 조건
특성 · 기능성, 완전성, 일관성  · 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보완성 및 품질관련 요구사항, 제약사항 
사례 · 상품의 결제수단은 신용카드, 무통장입금, 포인트 결제가 가능해야함  · 특정 함수의 호출시간은 3초를 넘지 않아야 함 

 


 

요구공학 프로세스 : 요구사항 개발 단계와 요구사항 관리 단계로 구성

1. 요구사항 개발 단계 (CMM Level 3 프로세스 영역)

도출 분석 명세 확인
 · 요구사항 소스
 · 도출 기법


 · 요구사항 분류
 · 개념 모델링
 · 기술 구조 설계 및 요구사항 할당
 · 요구사항 협상
 · 시스템 정의서
 · 시스템 요구사항 명세서
 · 소프트웨어 요구사항 명세서

 · 검토 
 · 프로토타이핑
 · 모델 검증
 · 인수 테스트

 

2. 요구사항 개발 단계 상세

- 요구사항 도출 단계 : 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계

주요기법 설명
인터뷰 이해관계자와 직접 대화해 공식적/비공식적 정보 수집
브레인스토밍 대화하기 편한 분위기를 조성해 아이디어를 비판없이 수용하는 회의
델파이기법 전문가의 경험지식을 통한 문제해결, 미래예측
롤플레잉 현실 장면을 설정하고 각자 맡은 역할을 연기해 요구사항 분석 및 수집
워크숍 단기간 집중을 통해 전문적 정보 획득, 공유. 프로젝트 핵심인물참여 필요. 사전 준비 요구
설문조사 설문지, 여론 조사로 간접적 정보 수집. 다수의 의견수렴 용이.

- 요구사항 분석 단계 : 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성일관성을 확보하는 단계

  └  절차

순서 절차 설명
1 요구사항 분류 · 요구사항이 기능/비기능 확인
· 요구사항이 SW에 미치는 영향 범위 파악
· 요구사항이 SW 생명주기 동안 변경이 발생하는지 확인
· 하나 이상의 상위 요구사항에서 유도된 것인지 or 이해관계자나 다른 원청으로부터 직접 발생한 것인지 분류
2 개념 모델링 생성 및 분석 · 모델링 : 요구사항을 쉽게 이해할 수 있도록 단순화, 개념적으로 표현한 것 → 모델링을 만드는 활동
· 개념모델 : 문제 도메인의 엔티티들과 개별 관계 및 종속성을 반영
· 다양한 개념모델 작성 가능    유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델
· 모델링 표기는 주로 UML 사용
3 요구사항 할당 · 요구사항에 만족하기 위한 아키텍처 구성요소를 식별하는 활동
· 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구사항 발견 가능
4 요구사항 협상 · 두 명의 이해관계자의 의견이 상충되는 경우 적절한 지점에서 합의하기 위한 활동
5 정형 분석 · 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 활동
· 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
· 요구사항 분석의 마지막 단계

 

    기법

   - 자료흐름지향 분석 : 데이터 흐름도, 자료 사전으로부터 SW 구조 유도 방법

   - 객체지향 분석 : 시스템 기능과 데이터 분석, UML로 표준화

   기술 : 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성

 

- 요구사항 명세 단계 :  체계적으로 검토, 평가, 승인될 수 있는 문서(요구사항 명세서)를 작성하는 단계

   기법

비정형 명세기법 요구표현을 자연어로 서술.
명확성 및 검증에 문제. 사용자와 개발자의 이해가 용이.
정형 명세기법 요구표현을 수학적 원리와 표기법으로 서술. 정형 명세인 Z-스키마, Petri Nets, 상태차트 활용.
표현 간결, 명확성 및 검증 용이. 기법 이해 어려움.

   

   요구사항 명세 원리 및 검증 항목 : 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

 

- 요구사항 확인 및 검증 단계 : 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동

   순서 : 요구사항 목록 확인  요구사항 정의서 작성 여부 확인  비기능적 요구사항 확인  타 시스템 연계, 인페 요구사항 확인

    주요 기법

주요 기법 설명
요구사항 검토  · 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토
 · 담당자들이 수작업으로 분석
정형 기술 검토  동료검토  · 2~3명 리뷰 진행. 
 · 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 들으면서 결함을 발견하는 형태로 진행. 
워크스루  · 검토 자료를 회의 전에 미리 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류 검출. 
 · 사전검토
인스펙션  · 소프트웨어 요구, 설계 원시 코드 등의 작성자 외의 다른 전문가 or 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
프로토타이핑   · 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물 예측
모델 검증  · 분석단계에서 개발된 모델의 품질 검증 필요
 ·
정적 분석 수행에 유용
테스트 케이스 및 테스트를 통한 확인  · 테스트 케이스를 생성하고 이후 요구사항이 현실적으로 테스트 가능한지를 검토
 · 인수테스트에는 알파 테스트와 베타 테스트가 있음
CASE 도구 활용  · 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리, 표준 준수 여부 확인. 
 · 자동화된 요구 사항 관리 도구 이용
베이스 라인 검증  · 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검층 수행
요구사항 추적표  · 요구사항 정의서를 기준으로 개발단계별 최종 산출문의 반영과 변경을 확인가능한 문서

 

    상세 정형 기술 검토 기법 : 관리리뷰, 기술리뷰, 인스펙션(== 동료검토), 워크스루, 감사

 

3. 요구사항 관리 단계 (CMM Level 2 프로세스 영역)

- 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동

 


 

TEST  →  정답은 드래그!

정답 문제
요구공학 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다.
비기능적 요구사항 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항으로, 품질 속성에 관련하여 시스템이 갖춰야 할 사항에 관하여 기술한다.
기능적 요구사항 시스템이 제공하는 기능, 서비스에 대한 요구사항으로, 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대해 기술한다.
브레인스토밍 말을 꺼내기 쉬운 분위기로 만들어 회의 참석자들이 내놓는 아이디어들을 비판없이 수용할 수 있도록 하는 회의이다.
롤 플레잉 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법이다.
워크숍 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법으로 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요하고, 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구된다.
UML 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어이다.
비정형 명세 기법 명세 기법 중에서 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법으로 사용자와 개발자의 이해가 용이하지만, 명확성 및 검증에 문제가 있다.
정형 명세 기법 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법으로, Z-스키마, Petri Nets, 상태 차트를 활용하여 표현한다.
인스펙션 정형 기술 검토 기법 중 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법이다.
워크스루 정형 기술 검토 기법 중 컴토 자료를 회의 전에 배포해서 사전 검도한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법이다.
감사 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법으로 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행한다.

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

소프트웨어 개발 방법론

소프트웨어 생명주기 모델

1. 개념

 - 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 - 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것

 

2. 프로세스 ( 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 )

 - 요구사항 분석 : 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 정의하는 단계

  └  기능 요구사항, 비기능 요구사항  

 - 설계 : 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계

  └  시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

 - 구현 : 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하여 실제 프로그램을 작성하는 단계

  └  인터페이스 개발, 자료 구조 개발, 오류 처리

 - 테스트 : 예상과 실제결과의 차이를 검사, 평가 단계

  └  단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

 - 유지보수 : 시스템 인수되고 설치된 후 일어나는 모든 활동

  └  예방, 완전, 교정, 적응 유지보수

 

3. 모델 종류

종류 설명
폭포수 모델
(Waterfall Model)

· 개발시 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
· 선형 순차적 모형, 고전적 생명주기 모형
· 요구사항 변경 어려움
절차 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
프로토타이핑 모델
(Prototyping Model)
· 고객이 요구한 주요기능을 프로토타입으로 구현하여, 고객의 피드백을 반영
· 요구사항 분석 용이, 타당성 검증가능
· 프로토타입 폐기에 따른 비용 증가
나선형 모델
(Spiral Model)

· 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발
· 위험분석, 반복개발
·
위험성 감소와 변경에 유연한 대처
·
단계 반복에 따른 관리 어려움  
절차 계획 및 정의 → 위험 분석 → 개발 → 고객평가 
반복적 모델
(Iteration Model)
· 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델
· 병행 개발로 인한 일정 단축 가능
· 병행 개발에 따른 관리 비용 증가

 


 

소프트웨어 개발 방법론

1. 개념

- 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법

- 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론

 

2. 종류

종류 설명
구조적 방법론 ·  전체 시스템을 기능에 나누어 개발, 이를 통합하는 분할과 정복 접근 방식의 방법론
·  프로세스 중심의 하향식 방법론
·  나씨 슈나이더만 차트 사용 : 논리의 기술에 중점을 둔 도형식 표현방법
정보공학 방법론 · 정보시스템 개발에 필요한 관리 절차와 작업 기법을 쳬계화
객체 지향 방법론 · '객체'라는 기본 단위로 시스템을 분석 및 설계
컴포넌트 기반 방법론(CBD) · 컴포넌트를 조립해서 하나의 새로운 응용프로그램 작성
· 개발시간 단축 - 생산성 향상, 확장성, 재사용성
애자일 방법론 · 절차보다는 사람 중심, 변화에 유연 신속 적응하면서 효율적인 시스템 개발
제품 개발 방법론 · 특정 제품에 적용하고 싶은 공통된 기능을 정의 개발, 임베디드 S/W작성에 유용

 

3. 애자일 : 절차보다는 사람중심, 변화에 유연 신속 적용, 즉시 피드백을 받아 유동적 개발

- 유형

  XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질 향상을 위한 방법론

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

     XP 12가지 기본원리

기본원리 설명
짝 프로그래밍  개발자 둘이서 짝 코딩
공동 코드 소유  시스템에 있는 코드는 누구든 언제든 수정 가능
지속적인 통합 (CI)  매일 여러번 소프트웨어 통합, 빌드
계획 세우기  고객 요구 비즈니스 가치 정의, 개발자가 필요한 것이 무엇인지, 어떤 부분에서 지연 여부를 알려줌
작은 릴리즈  작은 시스템을 먼저 만들고, 짧은 단위 업데이트
메타포어  공통적인 이름 체계와 시스템 서술서를 통해 의사소통을 원활
간단한 디자인  요구사항에 적합한 가장 단순한 시스템을 설계
테스트 기반 개발 (TDD)  작성하는 프로그램에 대한 테스트 먼저 수행, 테스트를 통과하도록 실제 코드 작성
리팩토링  프로그램 기능을 바꾸지 않으면서, 코드의 중복제거, 단순화
40시간 작업  개발자 실수 방지를 위해 일주일 40시간 이상 일하지 말아야 함
고객 상주  개발자 질문에 즉각 대응을 위해 고객 풀타임 상주
코드표준  효과적인 공동 작업을 위해 코딩 표준 정의


   린(Lean) : 토요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질 향상을 위한 방법론

     린 7가지 가치 : 낭비제거, 품질 내재화, 지식창출, 늦은 확정, 빠른 인도, 사람존중, 전체 최적화

  ③ 스크럼(SCRUM) : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 중심 방법론

     백로그, 스프린트, 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번 다운 차트

 

 


 

객체 지향 분석 방법론 ( OOA : Object Oriented Analysis )

1. 개념 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 속성과 연산, 관계를 정의

 

2. 종류

- OOSE(Object Oriented Software Engineering) : 유스케이스를 모든 모델의 근간으로 활용되는 방법론, 야콥스

- OMT(Object Modeling Technology) : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링, 럼바우

  └ 분석 절차  : 객체 - 동적 - 기능
  └ 객체 모델링 (Object, Information)  : 객체 다이어그램, 객체들 간의 관계 정의하여 ER 이어그램을 만드는 과정까지의 모델링
  └ 동적 모델링 (Dynamic) : 상태 다이어그램, 시간의 흐름에 따라 객체들의 동적인 행위를 표현
  └ 기능 모델링 (Functional) : 자료흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리과정 표현 

- OOD(Object Oriented Design) : 설계 문서화를 강조하여 다이어그램 중심으로 개발, 부치

 

 

 


 

비용산정, 일정관리 모형

비용산정 모형 : 소프트웨어 비용 산정 방식

1. 분류

- 하향식 산정방법 : 경험이 많은 전문가에게 비용산정

  └ 전문가 판단
  └ 델파이 기법  : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

- 상향식 산정방법 : 세부적인 요구사항과 기능에 따라 비용산정

  └ 코드라인수(LoC) 모형, Man Month 모형, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형

 

2. 종류

종류 설명
코드라인수(LoC) 모형 ·  원시 코드 라인수의 낙관치, 중간치, 비관치 측정하여 예측치를 구해 비용산정
Man Month 모형 ·  한 사람이 1개월동안 할 수 있는 일의 양을 기준으로 비용산정
·  (Man Month) = (LoC) / (프로그래머 월간 생산성) 
·  (프로젝트 기간) = (Man Month) / (프로젝트 인력)
COCOMO 모형 ·  보헴이 제안한 모형으로 프로그램 규모에 따라 비용산정
·  조직형(Organic) : 5만 라인 이하
·  반분리형(Semi) : 30만 라인 이하
·  임베디드형(Embedded) : 30만 라인 이상
푸트남 모형 ·  개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
기능점수(FP) 모형 ·  소프트웨어 기능을 증대시키는 요인별로 가중치를 부여햐여 비용산정

 


 

일정 관리 모델 :  프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델

1. 종류 (주,펄,중)

- 주 공정법(CPM)  : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
  └ 주 공정(임계경로) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
- PERT  : 일의 순서를 계획적으로 정리하기 위한 수렴 기법. 비관치, 중간치, 낙관치 이용
- 중요 연쇄 프로젝트 관리(CCPM) : 주 공정 연쇄법으로 자원 제약사항을 고려하여 일정 작성

 


TEST  →  정답은 드래그!

정답 문제
소프트웨어 생명주기
(SDLC)
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
폭포수 모델 소프트웨어 개발시 각 단계를 확실히 마무리 지은 후에 다음단계로 넘어가는 가장 오래된 생명주기 모델이다.
나선형 모델 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델이다.
소프트웨어 개발 방법론 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
구조적 방법론 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식을 사용하는 방법론이다.
나씨-슈나이더만 차트 구조적 프로그래밍 표현을 위해 논리의 기술에 중점을 둔 도형식 표현 방법으로 연속, 선택, 반복 등의 제어 논리 구조로 표현한다.
애자일 방법론 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론이다.
XP 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론으로 5가지 가치와 12개의 실천항목이 존재한다.
지속적인 통합(CI) 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리이다.
메타포어 XP의 12가지 기본원리 중 하나로 공통적인 이름체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다는 원리이다.
테스트 기반 개발(TDD) 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리이다
스크럼 애자일 방법론 중 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론이다.
스프린트 스크럼 방법론에서 2~4주의 짧은 개발 기간으로 반복적 수행하는 개발 품질을 향상시키는 프로젝트 수행법이다.
번 다운 차트 스크럼 방법론에서 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트이다.
리팩토링 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성 한다는 원리이다.
LoC 모형 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측지를 구하고 이를 이용하여 비용을 산정하는 방식이다.
Man Month 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식이다.
COCOMO 모형 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식으로, 규모에 따라 조직형, 반 분리형, 임베디드형으로 나뉜다.
푸트남 모형 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식으로, 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력분포도를 기초로 한다.
델파이 기법 비용산정 모형 중 하향식 산정방법이며, 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법이다.
기능 점수 모형(FP 모형) 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식이다.
주 공정법 일정관리 모델 중에서 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법이며, 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티로 표기한다.
PERT 일정관리 모델 중에서 일의 순서를 계획적으로 정리하기 위한 수렴기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법이다.
데이터 흐름도(DFD) 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로, 시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램이다.
자료 사전(DD) 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전이다.
릴리즈노트 조직의 최종사용자인 고객과 잘 정리된 릴리즈 정보를 공유하는 문서이다.
헤더 릴리즈 노트 작성 항목 중 문서 이름, 제품 이름, 버전 번호, 릴리즈 날짜, 참고 날짜, 노트 버전 등의 정보이다.
재현 항목 릴리즈 노트 작성 항목 중 버그 발견에 따른 재현 단계 기술이다.
사용자 영향도 릴리즈 노트 작성 항목 중 버전 변경에 따른 최종 사용자 기준의 기능 및 응용 프로그램상의 영향도 기술이다.
노트 릴리즈 노트 작성 항목 중 소프트웨어 및 하드웨어 설치 항목, 제품, 문서를 포함한 업그레이드 항목 메모이다.
면책조항 릴리즈 노트 작성 항목 중 회사 및 표준 제품과 관련된 메시지, 프리웨어 및 불법 복제 방지, 중복 등 참조에 대한 고지 사항이다.

 

 

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

+ Recent posts