- content
정처기 ch1. 요구사항 분석
1. 현행 시스템 분석
1.1. 현행 시스템 파악
1.1.1. 1단계
- 현행 시스템 구성 현황 파악
- 기간 업무
- 지원 업무
- 현행 시스템 기능 현황 파악
- 주요 기능
- 하부 기능
- 현행 시스템 인터페이스 현황 파악 - 다른 단위 업무 시스템과의 데이터 통신에 사용된 형식, 통신 규약, 연계 유형 등
1.1.2. 2단계
- 아키텍처 구성 현황 파악
- 핵심 기간 업무 처리 시스템 기준
- 소프트웨어 구성 현황 파악
- 단위 업무 별 SW 제품, 라이선스 정보
- 소프트웨어 아키텍처
1.1.3. 3단계
- 하드웨어 구성 현황 파악
- 단위 업무 시스템 별 물리적 서버 정보
- 네트워크 구성 현황 파악
- 서버 간 관계, 위험 대응
1.2. 개발 기술 환경 정의
1.2.1. 운영체제
- 종류
- Windows
- Unix
- Linux
- iOS
- Android
- 고려 사항 - 신뢰도 - 성능 - 주변 기기 - 기술 지원 - 구축 비용
1.2.2. DBMS
- 종류
- Oracle
- IBM DB2
- MS SQL Server
- SQLite
- MongoDB
- Redis
- 고려 사항 - 가용성 - 성능 - 상호 호환성 - 기술 지원 - 구축 비용
1.2.3. 미들웨어
- WAS
- 데이터 접근
- 세션 관리
- 트랜잭션 관리
- 고려사항
- 가용성
- 성능
- 기술 지원
- 구축 비용
1.2.4. 오픈 소스
2. 요구사항 확인
2.1. 요구사항 정의
2.1.1. Elictation, 요구사항 도출
- Requirement Source, 요구사항 소스 (where)
- Elicitation Technique, 도출 기법 (how)
2.1.2. Analysis, 요구사항 분석
- 분석 기법
- Classification, 요구사항 분류
- functional
- non-functional
- 제품
- Usability, 사용성
- Efficiency, 효율성
- Performance, 성능
- Space, 공간
- Reliability, 신뢰성
- Portability, 이식성
- 조직
- Delivery, 납품
- Implementation, 구현
- Standards, 표준
- 외부
- Interoperability, 상호운용성
- Ethical, 윤리
- Legislative, 준법성
- Privacy, 사생활보호
- Safety, 안전
- 제품
- Concepture Modeling, 개념 모델링
- 요소
- Entity
- Relationship
- Dependency
- 종류
- Use Case Diagram
- 사용 시나리오 표현
- Structure Diagram
- 정적 구조, 추상화, 관계 표현
- Behavior Diagram
- 시간 변화에 따른 시스템 변경 표현
- Data Flow Model
- State Model
- Goal-Based Model
- User Interactions
- Object Model
- Data Model
- Use Case Diagram
- 표기
- UML ![[UML]]
- 요소
- Requirement Negotiation, 요구사항 협상
- 우선순위 부여
- 트레이드 오프 지점
- Formal Analysis, 정적 분석
- 시멘틱을 지닌 언어로 요구사항 표현
- 요구사항 분석 마지막 단계
- Classification, 요구사항 분류
2.1.3. Specification, 요구사항 명세
- System Definition Document, 시스템 정의서
- System Requirement Specification, 시스템 요구사항 명세서
-
Software Requirement Specification, 소프트웨어 요구사항 명세서
2.1.4. Validation, 요구사항 확인
회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)
- 요구사항 확인 기법
- Review
- Prototyping
- 새로운 요구사항을 도출하기 위한 수단
- Model Verification
- 분석 단계에서 개발된 모델의 품질 검증
- Acceptance Test
- 최종 제품의 요구사항 만족 여부 확인
2.2. 요구사항의 시스템화 타당성 분석
- 성능 및 용량 산정 적정성 검토
- 시스템 간 상호 운용성 검토
- 상호운용성 : 다른 목적을 지닌 2개 이상 시스템들이 상호 간 정보 및 서비스를 교환하면서 효과적으로 운용될 수 있는 시스템의 능력
- IT 시장 성숙도 및 트렌드 부합성 검토
- 기술적 위험 분석
- 기술의 복잡성, 검증 여부, 의존성 등
- 위험 발생 가능성, 영향도
3. 분석모델 확인
3.1. 분석모델 검증
- 유스케이스 모델 검증
- 액터
- 유스케이스
- 유스케이스 명세서
- 개념 수준 분석 클래스 검증
- 클래스 도출
- 클래스명 & 속성
- 클래스 간 관계 (Multiplicity, 다중성)
- 분석 클래스 검증
- 유스케이스 실현(Realization)
- 클래스 누락, 추적 가능성 검토
- 역할, 관계, 메시지 흐름 완전성 확인
- 역할 기준 클래스 도출
스테레오 타입
- <<boundary» 시스템-외부 액터 상호작용
- <<entity» 시스템의 정보 관리
- <<control» 시스템 기능의 로직 및 제어 담당
- 경계 및 제어 클래스 도출
- 유스케이스 단위로 분석 클래스 확인
- 클래스 간 관계 및 상세화 정도 확인
- 유스케이스 명세서 기반 확인
- 유스케이스 실현(Realization)
3.2. 분석모델의 시스템화 타당성 분석
- 성능 및 용량 산정 적정성
- 시스템 간 상호 운용성
- IT 시장 성숙도 및 트렌드 부합성
- 기술적 위험 분석
요구사항 분석 자동화 도구
CASE, Computer Aided Software Engineering
- 소프트웨어 개발 과정 일부 또는 전체를 자동화하기 위한 도구
- 표준화된 개발 환경 구축 및 문서 자동화 기능 제공 도구
종류
- SADT, Structured Analysis and Design Technique
- SREM
- PSL/PSA, Problem Statement Language / Program Statement Analyzer
- TAGS, Technology for Automated Generation of Systems
시스템 분석 자동화 도구
HIPO, Hierarchy Input Process Output
요구사항 관리 도구
- Swagger
- 간단한 설정으로 프로젝트에서 지정한 URL 들을 HTML 화면으로 확인할 수 있게 해주는 프레임워크
- 1-1-2
- 아키텍처 구성 현황 파악
- 핵심 기간 업무 처리 시스템 기준
- 소프트웨어 구성 현황 파악
- 단위 업무 별 SW 제품, 라이선스 정보
- 소프트웨어 아키텍처
- 소프트웨어 4+1 뷰
- 유스케이스뷰
- 프로세스 뷰
- 배치 뷰
- 논리 뷰
- 구조 뷰
- SW 아키텍처 패턴 종류
- 계층화 패턴
- 클라이언트-서버 패턴
- 파이프-필터 패턴
- 브로커 패턴
- 모델-뷰-컨트롤러 패턴
- SW 아키텍처 비용 평가 모델
- SAAM
- 변경 용이성 & 기능성에 집중
- ATAM
- SAAM + 아키텍처 품질 속성 만족 여부 평가
- CBAM
- ATAM + 경제성 평가 보장
- ADR
- 구성 요소 간 응집도 평가
- ARID
- ATAM+ADR
- SAAM
- 소프트웨어 4+1 뷰
- 아키텍처 구성 현황 파악
- 1-1-3
- 하드웨어 구성 현황 파악
- 단위 업무 시스템 별 물리적 서버 정보
- 네트워크 구성 현황 파악
- 서버 간 관계, 위험 대응
- 하드웨어 구성 현황 파악
- 1-2 개발 기술 환경 정의
- 운영체제
- 종류
- Windows
- Unix
- Linux
- iOS
- Android
- 고려 사항
- 신뢰도
- 성능
- 기술지원
- 주변 기기
- 구축 비용
- 종류
- DBMS
- 종류
- Oracle
- IBM DB2
- MS SQL Server
- SQLite
- MongoDB
- Redis
- 고려 사항
- 가용성
- 성능
- 기술 지원
- 상호 호완성
- 구축 비용
- 종류
- 미들웨어
- WAS
- 고려사항
- 가용성
- 성능
- 기술 지원
- 구축 비용
- 고려사항
- WAS
- 오픈 소스
- 운영체제
2 분석모델 확인
- 3-1 분석모델 검증
- 유스케이스 모델 검증
- 액터
- 유스케이스
- 개념 수준 분석 클래스 검증
- 클래스 도출
- 클래스명 & 속성
- 클래스 간 관계
- 분석 클래스 검증
- 스테레오 타입
- boundary
- entity
- control
- 경계 및 제어 클래스 도출
- 관계 및 상세화 정도
- 스테레오 타입
- 유스케이스 모델 검증
- 3-2 분석모델의 시스템화 타당성 분석
- 성능 및 용량 산정 적정성
- 시스템 간 상호 운용성
- IT 시장 성숙도 및 트렌드 부합성
- 기술적 위험 분석
3 SDLC
-
프로세스
- -
-
- 요구사항 분석
- 설계
- 디자인 패턴
- 생성
- Factory Method
- Prototype
- Builder
- Singletone
- Abstract Factory
- 구조
- Facade
- Flyweight
- Composite
- Bridge
- Adapter
- Decorator
- 행위
- 생성
- 디자인 패턴
-
- 구현
- 테스트
- 단위 테스트
- 통합 테스트
- 시스템 테스트
- 인수 테스트
- 유지보수
- 모델 종류
- 폭포수 모델
- 프로토타이핑 모델
- 나선형 모델
- 계획 및 정의
- 위험 분석
- 개발
- 고객 평가
- 반복적 모델
- 소프트웨어 개발방법론
- 구조적 방법론
- 정보 공학 방법론
- 객체 지향 방법론
- 컴포넌트 기반 방법론
- 애자일 방법론
- XP
- 가치
- 용기
- 단순성
- 의사소통
- 피드백
- 존중
- 12가지 기본 원리
- Pair Programming
- Collective Ownership
- Continuos Integration
- Planning Process
- Small Release
- Metaphor
- Simple Design
- Test Driven Develop
- 가치
- 스크럼
- 백로그
- 스프린트
- 스크럼 미팅
- 스크럼 마스터
- 스프린트 회고
- 번 다운 차트
- 린
- 낭비 제거
- 품질 내제화
- 지식 창출
- 늦은 확정
- 빠른 인도
- 사람 존중
- 전체 최적화
- XP
- 제품 계열 방법론
4 비용 산정 모델
- 하향식
- 델파이 기법
- 상향식
- Lines of Codes
- 코드 라인 수의 예측치를 구해 비용 산정
- (낙관치 + 중관치*4 + 비관치) / 6
- 코드 라인 수의 예측치를 구해 비용 산정
- Man Month
- 한 사람이 1개월 간 할 수 있는 양을 기준으로 비용 산정
- Man Month = LoC / 월간 생산성
- 프로젝트 기간 = Man Month / 프로젝트 인력
- 한 사람이 1개월 간 할 수 있는 양을 기준으로 비용 산정
- COCOMO
- 프로그램 규모에 따라 비용 산정
- 조직형 (Organic)
- 반분리형 (Semi-detached)
- 임베디드형 (Embedded)
- 프로그램 규모에 따라 비용 산정
- Putnam
- 생명 주기 별 인력 분포 예측
- Rayleigh-Norden 곡선 분포도 기초
- 생명 주기 별 인력 분포 예측
- FP
- 요구 기능 별로 가중치 부여
- Lines of Codes
5 일정 관리 모델
- Critical Path Method, 주공정법
- 임계 경로(가장 긴 경로) 계산
- CCPM, 주요 연쇄 공정법
- 자원 제약사항 고려해 계산
- PERT
- 낙관치-중관치-비관치의 3점 추정 방식