IT정리-Software Engineering편
- SW공학개념
- S/W위기에서 출발
- 1차 : 하드웨어는 발전하는데 SW 생산성 및 유지 보수성 향상은 더디다. GOTO문 없이 순차/분기/반복( 구조적)으로 가자.
- 2차 : 기능 추가시 새 모듈도 추가. 새 모듈로 인해 중복이 발생=> 상속, 객체 지향으로 가자.
- 3차 : SW는 Lead Time(요구->결과물)이 오래 걸림. 결과물이 빨리 나올 방법은? => 미리 준비해 놓자. 프레임워크( 재사용가능한 컴포넌트)
- 위기 탈출 방법
- 재사용: 방법론( 객체지향, CBD,SOA..)
- 표준화 : CMMI, SPICE
- 소프트웨어 공학
- 재사용, 표준화를 통한 생산성, 품질을 높이기 위한 체계적,공학적 방법
- "싸게, 빨리, 좋게"
- SW프로세스
- 폭포수
- 프로토타입 모델
- 나선형 모델
- 폭포수 + 프로토타이핑 장점
- 계획-위험분석-공학화-사용자평가( planning-risk analysis-engineering-customer evaluation)
- 규모가 큰 프로젝트 제작에 적합
- 점증적 개발 모델
- SW개발방법론
- 분석기법
- 구조적방법론
- 라이지움 p.14
- 등장배경
- GOTO문을 쓰지 말고, 구조적으로 프로그래밍을 하자.
- -> 분석과 설계도 구조적으로 하자. 모듈의 분할과 정복
- 특징
- 데이터 흐름 즉 프로세스 위주의 분석,설계
- "데이터 구성"에 대한 설계 방안 부족
- 프로젝트 관리 및 조직, 역할 정의 없음
- NS-Chart
- 모듈의 분할과 정복-Top down
- 정보공학방법론
- 라이지움 p. 15
- 등장배경
- 정보 시스템(Biz 시스템)은 일반 소프트웨어 개발과는 달리 여러 요소가 얽힌 대규모다.
- 프로젝트 관리, 진행 방법론 도입 필요
- 특징
- 기업중심
- ISP( 정보 전략 계획) : Biz, 경영 전략 분석 후 IT 전략을 수립해야 한다고 제시
- 데이터 중심 : 데이터 분석, 설계 중심
- 공학적 접근(CASE Tool)
- 사용자 참여
- 데이터와 프로세스의 상관 관계 :
- Top down
- 객체지향방법론
- 라이지움 p.16
- 등장배경
- 객체지향 프로그램밍으로부터 객체지향 방법론 출발
- 기존의 프로세스,데이터를 객체로 표현
- 객체 지향 원리
- 추상화
- 캡슐화
- 상속성
- 다형성 : overloading, overriding
- CBD로 넘어가며 상속과 다형성을 버린다. 컴포넌트 자체는 상속X
- white box reuse - 반드시 소스가 있어야 한다.
cf) CBD -black box resuse
- bottom up
- CBD
- reuse - black box resuse
- 위임, I/F
- 표준화된 UML을 통한 모델링 및 산출물 작성
- 반복, 점진적 개발 프로세스 제공
- RUP
- 라이지움. p. 17
- RUP - 2차원적 모델
- Phases
- Inception
- 시스템의 최종 목표
- 프로젝트 범위 규정
- 타당성 분석
- 법적 타당성
- 경제적 타당성
- 기술적 타당성
- Elaboration
- 요구사항 명세화
- 위험 요소 판단, 제거
- S/W 아키텍처, 프로토타입 구현
- Construction
- Transition
- 6 Core Process Workflows
- BM 비즈니스 모델링
- Requirements
- Analysis & design
- Imp
- Test
- Deployment
- 3 Support
- C&C 형상 및 변경 관리
- PM 프로젝트 관리
- Env 환경
- MDA
- 현재 : 단일 플랫폼 지향 개발 절차
- 향후 : 다중 플랫폼 지향 개발 절차, MDA( Model Driven Architecture) 기반
- MDA = BM + PIM (Platform Independent Model)+ PSM(Platform Specific Model)
- UML : PIM, PSM 표현 표준
- MOF(Meta Object Facility) :
- 다른 메타 모델을 정의하기 위한 메타-메타 모델.
- UML, CWM은 MOF 기반 메타 모델.
- MOF는 모델 저장소 역할
- CWM( Common Warehouse Model)
- PIM<->PSM 변환, 매핑 정보를 가지고 있음
- XMI
- MOF, UML, CWM (UML) ->XMI->xml로 변환하기 위한 표준 사양.
- Product Line
- 17. Agile
- XP
- 라이지움. p.22
- 4가지 가치
- 의간피자
- 의사소통
- 간결함 Simplicity
- 피드백
- 자신감
- 12가지 원리
- 개발원리
- 페어 프로그래밍 pair programming
- 공동 소유( Collective Ownership )
- 지속적인 통합( Continuous Integration )
- 관리원리
- 게임 계획(Planning Game ) - xp 게임( 스토리카드), 스토리카드 작성( 탐색기->실행기->조정기)
- 짧은 릴리스( Small Release )
- 메타포(Metaphor) - 은유, 이심전심, 텔레파시
- 구현원리
- 간략한 디자인 simple desing
- 테스트 test-driven
- 리팩토링 refactoring
- 환경요소
- 주 40시간 작업 40-hours work
- 고객 상주 on-site customer
- 기타
- 스토리 카드
- RAD
- 빠르게 해 보자.=>Agile(scrup, xp)
- RAD 대상
- 매우 짧은 개발 주기(60-90)동안 개발하기 위한 순차적 프로세스 모델.
- 폭포수 모델의 응용 형태
- 단일 시스템을 단기간에 개발하는데 적합. 즉 다른 시스템과의 인터페이스 모델링은 없음
- 컴포넌트 기반
- 4세대 언어 이용
- visual development은 COTS(Commercial Off-the-Shelf, 상용 기성품)기반 개발
- 개발과정
- 비즈니스 모델링->데이터 모델링->프로세스 모델링->애플리케이션 생성->시험,전환
- 임베디드 시스템과 같이 상태 변화가 중요한 경우 데이터 모델링과 프로세스 모델링의 순서가 바뀔 수 있다.
- 특징
- 시간이 많이 소요되는 분석단계에 사용자 투입하자.
- JRP(Joint Requirement Planning) : Joint->사용자 참여
- JAD(Joint Application Design)
- CASE 툴 사용
- RAD가 되기 위한 조건
- SWAT : 소규모 전문 개발 팀 필요
- 통합 DB(Repository) : 재사용
- 자동화 CASE : 원하지 않는 코드 포함된다. 성능 저하 원인 될 수 있다.
- TimeBox : 요구사항 제출, 마감시간 제한
- RAD 환경 도구들
- 데이터베이스 응용 프로그래밍 언어 : 예, SQL
- 인터페이스 생성기
- 오피스 응용 프로그램과 연결 : 예, 스프레드 쉬트
- 보고서 생성기
- 소프트웨어 프로토타이핑
- 스크럼
- 스프린트 : 짧은 주기로 종료시 실행한 가능한 제품이 인도되어야 한다.
- 제품 백로그 : 시스템이 해결 또는 포함되어야 할 제품의 모든 요구사항
- 고객이 모든 요구사항을 전달->제품 오너가 백로그에 등록
- XP의 유저 스토리에 해당
- 일일미팅
- 회고 Retrospective : 프로세스 리뷰
- 리뷰 review : 제품 리뷰
- 프로젝트관리계획
- 일정계획
- 비용추정
- 프로젝트 비용 결정 요소
- 프로젝트 요소
- 제품의 복잡도, 시스템 코드, 요구되는 신뢰도
- 자원요소
- 생산성요소
- LOC
- COCOMO I, II
- COCOMO - 정보공학 방법론
- 보헴이 개발
- 각 분야에서 엄섬한 63개 프로젝트 데이터에 기초해 작성
- 경험적인 소프트웨어 비용 견적 모델
- LOC에 나타난 프로그램 크기의 함수로써 정적 단위 변수 모델
- 제품의 복잡도(LOC)에 따른 프로젝트 개발 유형
- organic model : 5만 라인 이하
- semi-detached model : 30만 라인 이하
- embedded model
- 비용 추정 단계 및 적용 변수 구체화 정도에 따른 분류
- Basic COCOMO - 앞의 3가지
- Intermediate COCOMO- 비용승수( 가중치 계수, 노력계수) 사용
- 제품의 속성-소프트웨어 신뢰도, 데이터베이스 크기 , 복잡도 등
- HW의 속성 - 응답시간, 실행시간성능제약, 메모리제약, 서버환경의 휘발성
- 개발 요원의 속성-분석가 능력, 응용경험, 언어구사경험, 엔지니어 능력, 서버환경경험
- 프로젝트의 속성 - 일정, 개발도구 사용, 방법론
- Detailed COCOMO
- 시스템을 모듈 서브 시스템으로 세분하여 Intermediate COCOMO 적용
- 개발 과정의 후반부에 적용
- COCOMO II - 객체지향 방법론
- COCOMO
- 프로젝트유형
- 단순형(organic)
- 중간형(semi-detached)
- 임베디드형(embedded)
- COCOMO II
- 기능점수
- 1 FP - 50여만원
- 정규법
- : 세밀하게 측정하여 데이터, 트랜잭션 기능 점수에 가중치를 부여하는 방법
- 데이터기능과 트랜잭션 기능을 측정할 때 복잡도와 기여도 사용하는 방법
- 간이법(간이법)
- : 정부고시되는 데이터, 트랜잭션 평균적 기능 점수 사용
- 조정 기능 점수 계산 절차
-
- 1) 기능유형별 기능 목록
- 2) 기능별 복잡도->기여도 계산
- - DET, RET, FTR 수-> 복잡도->미조정 기능 점수 변환표에 의한 기여도
- - 간이법인 경우, "기능별 평균 복잡도 가중치"제공
- 3)미조정 기능 점수 계산
- - 기능별 기여도 합산값
- - 간이법인 경우, 스킵
- 4)조정인자(VAF) 계산
- - GSC별 DI 계산
- - TDI = DI합산값
- - VAF = 0.65 + ( TDI*0.01)
- - 간이법인 경우, 정의된 유형별 보정계수 제공
- 5) 조정 기능 점수
- 측정 유형별(개발, 개선, 어플리케이션) 조정 기능 계산
- -간이법인 경우, 개발원가 = 미조정 FP * ( FP단가 * 최종 보정 계수 적용 단가)
- 용도
- 측정절차
- 측정절차
- 측정유형결정
- 측정범위와 어플리케이션 경계 식별
- 데이터 기능 측정
- 트랜잭션 기능 측정
- 미조정 기능 점수 결정
- 조정인자 결정
- : TCF = 0.65 + 0.01 * TDI( DI합)
- 조검 기능점수 결정
- 측정유형결정
- 측정범위와 어플리케이션 경계식별
- 데이터 기능측정
- 복잡도와 기여도 측정(평균법 사용시 제외)
- 복잡도 : Low, Avg. High
- 기여도 : 복잡도에 따라서 결정되는 최종 기능별 미조정 점수
- DET( 데이터 요소 유형, Data Element Type )
- REF(레코드 요소 유형, Record Element Type )
- 데이터 기능별 미조정 점수 측정
- 데이터 기능 유형(ILF, EIF)별 데이터 기능 도출
- 기능별 DET 수, REF 수를 카운팅
- 기능별 복잡도 Low, Avg, High를 결정( 복잡도 평가표 참조 )
- 복잡도에 따른 기능별 가중치(기여도) 결정( 기능점수 변환표 참조)
- 데이터 기능의 미조정 기능 점수 계산 = ∑ 데이터기능별 기여도
- ILF식별
- EIF식별
- 복잡도및기능점수 가중치적용
- 트랜잭션 기능측정
- 복잡도와 기여도 측정(평균법 사용시 제외)
- 복잡도 : Low, Avg. High
- 기여도 : 복잡도에 따라서 결정되는 최종 기능별 미조정 점수
- DET( 데이터 요소 유형, Data Element Type )
- 어플리케이션내로 들어오거나 나가며, 비반복되는 필드 갯수
- 메시지
- 동일한 논리 프로세스를 가동시키는 방법
- FTR( File Type Reference, 파일 타입 레퍼런스 )
- "단일프로세스"를 통해 "유지되는" ILF
- "단일 프로세스"를 통해서 읽혀지는 ILF, EIF
- 트랜잭션 기능별 미조정 점수 측정
- 트랜잭션 기능 유형(EI, EO, EQ)별 트랜잭션 기능 도출
- 기능별 DET 수, FTR 수를 카운팅
- 기능별 복잡도 Low, Avg, High를 결정( 복잡도 평가표 참조 )
- 복잡도에 따른 기능별 가중치(기여도) 결정( 기능점수 변환표 참조)
- 트랜잭션 기능의 미조정 기능 점수 계산 = ∑ 트랜잭션기능별 기여도
- EI식별
- EO식별
- EQ식별
- 복잡도및 기능점수 가중치적용
- 미조정 기능 점수
- 전체 미조정 기능 점수 = ∑ 데이터기능점수 + ∑ 트랜잭션기능점수
- 조정인자
- VAF( 기능점수의 조정인자, Value Adjustment Factor )
- 시스템 특성에 따른 분류(GSC, General System Characteristics )- 14개
- 각 GSC항목에 따른 DI(영향도, Degree of Influence) : 0~5
- TDI( 총영향도 ) = ∑DI
- 조정기능점수
- 기타추정모델
- 시간연구모델
- 파킨슨법
- 유추법
- 능력별지불
- 작업상노력비용산정
- 3D FP
- 보잉사에서 제작
- 실시간 처리형 App에 적합한 비용 추정 모델
- Function Point : 업무 처리형 App에 적합
- MarkII FPA
- 영국의 Charless Symons 제작
- 측정 간소화
- FP : 측정 복잡
- Feature Point
- Caper Jones 제작
- 모든 유형의 App에 적용하기 위해 제작
- SLIM
- Putnam
- SLIM - Rayleigh-Norden곡선과 Putnam 모형을 기초로 한 비용산정 자동화 도구
- ESTIMACS - 비용산정 자동화 도구
- 소프트웨어 개발 프로젝트 작업에 특별한 분포를 가정하는 정적 단일 변수
- SW사업대가기준
- 기능점수에 의한 소프트웨어 개발비 = 개발원가 + 직접경비 + 이윤
- 개발원가 = 기능점수 * 단계별 기능점수담 단가 * 보정계수
- 보정계수 = 규모보정, 어플리케이션유형 보정계수, 언어 보정계수, 품질및특성 보정
- 직접 경비
- 이윤
- 보정계수
- 규모보정
- 어플리케이션보정
- 어플리케이션 유형 보정 계수
- 업무처리용 - 보정계수 제일 낮음
- 지휘통제용(군사용) - 보정계수 제일 높은
- 지공통시 지멀과업
지휘통제용, 공정제어용, 통신제어용, 시스템용, 지능정보용, 멀티미디어, 과학기술, 업무처리용
- 언어보정
- 언어보정 계수
- Assembly, 기계어 - 보정계수 제일 높음
- C,C#, Java..
- JSP, ASP, PHP..
- ABAP4...
- Excel, 스프레드쉬트 - 보정계수 제일 낮음
- 품질및특성보정
- 조직계획
- 위험관리
- 개발계획서
- 품질
- 소프트웨어 품질 관점
- 발주자 관점 : 최소비용, 생산성, 융통성
- 사용자관점 : 기능의 정확성, 이해 용이성, 사용 용이성, 일관된 통합
- 유지보수자 : 이식성, 재사용성, 유지보수성, 상호운용성
- 발주자, 사용자 : 효율성, 신뢰성
- 발주자, 사용자, 유지보수자 : 신뢰성
- McCall이 제안한 품질요소
- Product operation(제품운영)
- 정확성(correctness)
- 신뢰성(reliability) :
- 옳고 일관된 결과를 얻기 위해 요구된 기능을 수행할 수 있는 정도
- 발주자, 사용자, 유지보수자의 공통 관심 품질
- 사용 용이성(usability)
- 유용성
- 무결성(integrity) : 허용되지 않은 사용이나 자료의 변경을 제어하는 정도
- 효율성(efficiency)
- Product revision(제품 개조)
- 유지보수성(maintainability) : 오류를 쉽게 교정할 수 있는 정도
- 유연성(flexibility) : 쉽게 수정될 수 있는 정도
- 검사이용성(testability)
- Product Transition(제품 전이)
- 이식성( portability)
- 재사용성(reusability)
- 상호운용성(interoperability) : 다른 소프트웨어와 정보를 교환할 수 있는 정도
- 강건성(강인성) : 부적절한 입력에 견디어 내는 정도
- 품질보증
- 품질보증 = validation + verification
- validation = "사용자 요구 사항이 맞는지" 검증
- verification = "명세서에 맞게 구현했는지" 확인
- 소프트웨어 품질 보증 분야
- 품질관리 시스템
- 제품 품질
- ISO 9126
- ISO 12119
- ISO 14598
- ISO 25000
- 프로세스 품질
- ISO 12207
- ISO 15504(SPICE)
- CMM, CMMI
- 품질경영
- 품질경영표준
- 기업의 모든 분야의 성과를 모니터링하고 개선하는 품질 관리 시스템
- ISO 9000 시리즈
- ISO 9000
- ISO 9001
- 요구사항 : 품질경영 시스템에 대한 요구사항을 규정
- ISO 9000-3은 ISO 9001을 소프트웨어 산업에 적용하기 위한 지침
- ISO 9004
- 성과개선 지침 : 품질 경영 8 원칙을 기초로 하며, 기업이 고객뿐만 아니라 모든 이해 관계자의 요구사항을 고려함으로써 성과를 개선할 수 있도록 안내하는 체제로 고위 경영진이 사용하도록 고안
- ISO 9000
- ISO 9000시리즈
- 기업의 품질 경영 시스템 개발에 사용될 수 있는 국제 표준의 집합
- 품질 경영 시스템 : 품질 보증 활동, 제품/프로세스 표준화등을 도입, 품질 위주의 경영 시스템
- ISO 9000
- ISO 9001
- ISO 9001
- 요구사항 :
- 품질경영 시스템에 대한 요구사항을 규정, 인증을 획득하는 데 필요한 기준 정의
- 공급자와 구매자간의 프로세스 품질 모델
- SDLC의 과정에 대한 품질 보증 모델
- 품질 시스템 순기활동
- 공급자와 구매자간의 관리 책임 명시
- ISO 9000-3
- ISO 9000-3
- ISO 9001( 요구사항)을 소프트웨어 산업에 적용하기 위한 지침
- ISO 9004
- ISO 9004
- 성과개선 지침 : 품질 경영 8 원칙을 기초로 하며, 기업이 고객뿐만 아니라 모든 이해 관계자의 요구사항을 고려함으로써 성과를 개선할 수 있도록 안내하는 체제로 고위 경영진이 사용하도록 고안
- 제품품질표준
- 소프트웨어 품질
- ISO 9126
- ISO 9126-1
- 주특성과 부특성
- 신사이기(에)유효
- 신뢰성(Reliability) : 규정된 성능 수준 유지, 사용자로 하여금 오류를 방지할 수 있도록 하는 능력
- 사용성(Usability)
- 이식성(Portability)
- 기능성(functionality) : 명시된 요구와 내재된 요구를 수행할 수 있는 능력
- 적합성, 정확성,상호운용성,보안성(**), 준수성
- 유지보수성(maintainability) : 변경(수정,개선, 개작)할 수 있는 능력
- 효율성(efficiency) : 최소의 자원으로 최대의 성능을 제공
- ISO 25000( SquaRE )
- ISO 9126 : 제품 품질 평가 모델
- ISO 14598 : 소프트웨어 품질 평가 방법과 절차 정의
- ISO 12119 : 소프트웨어 품질 요구사항 및 테스트 절차
- ISO 25000 5대 구성 요소
- 품질 요구사항 division
- 품질 모형 division
- 품질 관리 division
- 품질 측정 division
- 품질 평가 division
- ISO 9126
- ISO 9126 :
- 품질 특성과 척도에 관한 지침
- 고객관점의 소프트웨어 6가지 품질특성, 부특성으로 세분화 정의
- ISO 9126-1
- ISO 9126-1
- 주특성과 부특성
- 신사이기(에)유효
- 신뢰성(Reliability) : 규정된 성능 수준 유지, 사용자로 하여금 오류를 방지할 수 있도록 하는 능력
- 사용성(Usability)
- 이식성(Portability)
- 기능성(functionality) : 명시된 요구와 내재된 요구를 수행할 수 있는 능력
- 적합성, 정확성,상호운용성,보안성(**), 준수성
- 유지보수성(maintainability) : 변경(수정,개선, 개작)할 수 있는 능력
- 효율성(efficiency) : 최소의 자원으로 최대의 성능을 제공
- ISO 25000(SQUARE)
- 소프트웨어 품질 평가 SQUARE 구조
- ISO/IEC 25000
- SquaRE 프로젝트
- 기존의 국제 표준을 보강하고 통합하는 소프트웨어 평가 모델
- ISO 9126 : 제품 품질 평가 모델
- ISO 14598 : 제품 품질 평가 절차 정의
- ISO 12119 : 제품 품질 요구사항 및 테스트 절차
- ISO 25000 5대 구성 요소
- 4+1 구조
- 품질 요구사항(25030 Quality Requirement Division)
- 품질 모델(25010 Quality Model Division)
- 품질 메트릭(25020 Quality Metrics Division)
- 품질 평가(25040 Quality Evaluation Division)
- +(plus) 품질 관리(25000 Quality Management Division)
- <SQUARE 표준 구조>
- <SQUARE 개발 현황>
- ISO 9126
- ISO 14598
- ISO 14598
- 소프트웨어 품질의 측정,평가에 필요 절차 방법
- 개발자, 구매자, 평가자로 구분해 제품 평가 활동 다룸
- ISO 14598의 품질 평가 특성
- 반복성(Repeatability) : 특정 제품을 동일 평가자가 동일 사양으로 평가하면 동일한 결과가 나와야 함
- 재현성(Reproducibility) : 특정 제품을 다른 평가자가 동일 사양을 평가하면 유사한 결과가 나와야 함
- 공정성(Impartiality) : 평가가 특정 결과에 편향되지 않아야 함. 목적의식을 갖고 평가결과를 임의로 유도하여서는 안된다.
- 객관성(Objectivity) : 평가 결과는 객관적 자료에 의해서만 평가되어야 함
- ISO 12119
- ISO 12119
- 소프트웨어 제품의 품질
- 사용자 문서와 프로그램으로 구분, ISO/IEC 9126의 품질모델 준수
- 테스트 절차 규정
- 프로세스품질 표준
- Spice
- 5가지 프로세스
- CUS, ENG, SUP, MAN, ORG - 커스,엔지,숲,만,오알지 프로세스
- 프로세스 능력 수준 6단계( 0~ 5)
- Level0,
- Level1 , 수행됨 - 프로세스 달성, 계획, 추적없음, 결과물(코드) 존재
- Level2, 관리됨 managed - 계획, 추적, 결과물(문서)
- Level3, 수립됨 established - 조직차원의 프로세스 표준화, 자원준비
- Level4, 예측 predictable - 프로세스 측정, 정량화로 예측 가능
- Level 5, 최적화
- CMM
- 성숙도 5단계( 1 ~ 5)
- Level 1, 초기 initial
- Level 2, 반복 Repeatable - 프로젝트 단위의 프로세스 영역 포함
- Level 3, 정의 Defined - 조직 단위의 프로세스 영역 포함-> 표준화
- Level 4, 관리됨 Managed - 품질에 대한 정량적 측정
- Level 5, 최적화 Optimized
- CMMI
- 단계적(staged) 모델
- 성숙도 수준 - 5단계( 1~5)
- Level 1 - 초기
- Level 2, 관리 managed
- Level 3, 정의 defined
- Level 4, 양적으로 관리 quantitatively managed
- Level 5, optimized
- 연속적 모델( <- SPICE )
- 4개 프로세스 그룹,
- Engineering - 요구관리
- Project management
- Support
- Process Management
- Level 1 ~ Level 6
- ISO 12207
- ISO 12207
- ISO에서 정한 SDLC 프로세스 표준
- 23개의 프로세스, 95개 활동, 224개의 산출물 정의
- 특징
- 소프트웨어 개발과 유지보수에 필요한 공정(process), 활동(activity), 세무 업무(task) 정의
- 특정 생명 주기, 개발 방법 규정하지 않음, 즉 what만 정의하고 how는 정의하지 않음->CMM,SPICE는 how까지 정의
- 상위수준에서 정의됨. 일반적인 실제 심사에서 사용하기 힘듬
- 주요 프로세스
- 기본(핵심) 생명주기 프로세스
- 지원 생명주기 프로세스
- 문서화,품질보증,형상관리, 문제해결
- verification, validation, 합동검토,감사 프로세스
- 조직 생명주기 프로세스
- 구성도
- ISO 15504(SPICE)
- SPICE
- 프로세스 "개선", 공급자 "평가" 모두 지원. cf) CMM - 공급자 평가만 지원
- 구성 - ISO 15504 구조는 프로세스 차원과 프로세스 능력 차원으로 구성
- 프로세스 영역
- CUS, ENG, SUP, MAN, ORG - 커스,엔지,숲,만,오알지
- 고객,공급자 프로세스(Customer-Supplier, CUS)
- 발주,공급자 선정, 고객인수, 요구사항 도출, 공급, 운영 프로세스
- 엔지니어링(공학) 프로세스(Engineering, ENG)
- 요구분석, 설계 및 구현, 통합 및 시험 프로세스
- 지원프로세스(Support, SUP)
- 문서화, 형상관리, 품질보증, 검증,확인, 검토 프로세스
- 관리프로세스( Management , MAN)
- 조직프로세스(Organization, ORG)
- 프로세스 정의, 심사, 개선, 인적자원 관리, 기반구조, 측정, 재사용 프로세스
- 프로세스 능력 수준의 결정
- IPMEPO
- Level 0 - incomplete, 불완전
- 프로세스 결과물(Work Product) 없음. 코드 없음
- Level 1 - Performed, 수행
- 프로세스의 전반적 달성 . 그러나 계획, 추적 없음
- 식별 가능한 WP(Work Product, 코드) 존재.
- 프로세스 목적 달성 입증
- Level 2 - Managed, 관리
- 계획됨, 추적됨 - 계획서
- 결과물( 문서 ) 존재
- Level 3- Established, 수립
- 조직의 프로세스 표준화 - 정의된 프로세스 존재
- 수행자원 준비
- Level 4 - Predictable, 예측
- Level 5 - 최적화
- CMM
- 1단계- 초기단계, initial
- 2단계-반복 가능 단계, repeatable
- 프로젝트 단위의 핵심 프로세스를 반복할 수 있는 단계
- 핵심 프로세스 - 요구사항 관리, s/w프로젝트 계획 수립, s/w 프로젝트 추적/예측, s/w 외주계약 관리, s/w 품질 보증, s/w 구성 관리
- 3단계-정의된 단계, defined
- 전사 단위의 핵심 프로세스가 정의된 단계
- 핵심 프로세스 - 통합 소프트웨어 관리, 그룹간 상호협력, 조직 프로세스 초점, 조직 프로세스 정의, 교육 훈련 프로그램, 소프트웨어 생산 공학, 상세검토
- 4단계 - 관리된 단계, managed
- 전사 단위의 프로세스를 정량적, 품질적으로 관리
- 핵심 프로세스 = 정략적 프로세스 향상 관리, 정량적 소프트웨어 품질 관리
- 5단계 - 최적화 단계, optimizing
- 변경, 변화, 결함 예방 관리
- 핵심 프로세스 - 프로세스 개선/변경 관리, 기술 변화 관리, 결함 예방
- CMMi
- CMMi 24개 프로세스 영역
- 4개 프로세스 그룹 : ENG, SUP, PRO, PRO - 엔지, 숲, 프로, 프로
- 프로세스 관리( process management) - 조직 차원 프로세스
- 조직의 프로세스 정의
- 조직의 프로세스 초점
- 조직의 훈련
- 조직의 프로세스 성과(OPP)
- 조직의 혁신과 배치(OID)
- 프로젝트 관리(project management) - 프로젝트 차원
- 프로젝트 계획 수립
- 프로젝트 모니터링과 통제
- 공급자와의 합의 관리
- 통합된 프로젝트 관리
- 위험 관리
- 통합된 팀 구성
- 정량적인 프로젝트 관리
- 엔지니어링(engineering ) - SDLC 차원
- 요구사항 관리
- 요구사항 개발
- 기술적 해결책
- 제품 통합
- 증명
- 검증
- 지원( support ) - 품질 및 지원
- 형상관리
- 프로세스와 제품의 품질경영
- 측정과 분석
- 통합을 위한 조직의 환경
- 의사결정과 해결책
- 원인분석과 해결책
- CMMi 성숙도
- Continuous Model( 6단계 <- SPICE )
- IPMDQO
- 0단계(not performed ) : 한 영역의 하나 이상의 프로세스가 목표를 만족하지 못함
- 1단계(performed) :
- 프로세스 영역에 포함된 모든 프로세스의 목표를 만족시킨다.
- 각 프로세스에 대해 실행된 작업범위가 명확
- 2단계(managed ) : - 계획이 존재
- 각 프로세스가 사용되어야 할때를 정의하는 정책
- 문서화된 계획이 존재
- 자원관리, 프로세스 모니터링 절차 존재
- 3단계(defined ) - 표준화
- 조직의 표준화와 프로세스의 전개에 초점을 맞춘다.
- 프로세스 자산과 프로세스 측정치가 수집되어, 프로세스 개선을 위해 이용된다.
- 4단계(quantitatively managed): - measure&forecasting
- 5단계(optimizing)
- Staged Model( 5단계 <- CMM )
- 초관정정최
- 조직의 프로세스 능력을 평가
- 각 "성숙도 수준"은 "프로세스 영역"과 "일반 목표의 집합"을 갖는다.
- Performed
- Managed : basic project management
- Defined : process standardization
- Optimizing : Continuous process improvement
- 국내표준
- KS, KICS, TTAS
- KModel
- 정보통신부 소프트웨어 진흥원에서 만든 한국형 프로세스 평가 모델
- CMMI, SPICE 와 비슷
- initial, good, excellent란 3가지로 다음과 같이 5가지 영역에 대해 평가.
- 영역 1. 소프트웨어 개발 계획수립, 통제 등 관리프로세스에 관한 사항
- 영역 2. 소프트웨어개발공정에서 필요한 분석, 설계 등 개발 프로세스에 관한 사항
- 영역 3. 소프트웨어 품질관리에 필요한 품질보증 등 지원프로세스에 관한 사항
- 영역 4. 조직의 프로세스 표준화 및 이의 적용?확산 등에 관한 조직관리 사항
- 영역 5. 소프트웨어 프로세스의 유지 및 개선 등에 관한 사항
- 인증을 통해 공공분야에 가산점 부여, 해외표준 연계로 활성화 / 인증기관, 심사제를 통한 운영
- 중소기업인들의 형식적인 K Model 의 문제 지적
- McCall품질요소
- 품질관리
- 품질계획
- 품질 요구사항 파악
- 품질보증 절차 파악
- 품질통제 절차 파악
- 품질관리 체크리스트 작성
- 품질관리 계획 작성
- 품질보증
- 라이지움 p.111
- 품질보증
- 품질보증활동
- 프로젝트 산출물 검토
- 프로젝트 절차 검토
- 고객의 초기 검토 및 피드백 요구
- 라운드로빈검사 (round-robin review)
- Peer Review
- inspection
- 소프트웨어 구성 요소들의 정확한 평가
- Review보다 엄격 - 계획서, 미팅, 결과 단계별 단출물
- CheckList 등 사용
- 계확단계에서 역할 정의( Leader(사회자), Inspector, 서기, 개발자, 낭독자)
- 문서inspection
- 코드inspection
- Walkthrough
- Formal Review
- 고객과 함께 리뷰
- 공식적 -리뷰(FTR) - Formula Technical Review
- 품질통제
- 품질결과 모니터
- 계획된 품질 수준과의 차이분석
- 수정계획 수립
- 수정활동 문서화 및 계획의 최신 상태 유지
- 형상관리
- 형상변경절차
- 형상관리 절차
- 변경요청->요청서분석->형상관리위원회->변경구현 및 테스트->시스템 설치
- 소프트웨어 형상
- 형상 대상은 변경이 가능한 항목
- 계획서, 분석서, 설계서, 프로그램, 테스트케이스, 유지보수문서 등
- 비용계획서(X)
- 형상관리 시스템 요소
- 기준선(baseline, 기선, 통제점)
- 형상항목
- 기준선
- 기준선 :
- 기능적 기준선
- 사용자의 요구분석명세서 또는 시스템 기능 요구 정의서를 검토하는 시점
- 할당 기준선
- 사용자 요구기능들이 하위시스템에 어떻게 할당되는가를 정의하는 기본 설계 명세서를 검토하는 시점
- 설계 기준선
- 테스트 기준선
- 소프트웨어 성능을 평가할 수 있는 원시코드, 실행코드, 시험계획서를 검토하는 시점
- 제품기준선
- 하나의 시스템으로 완료된 제품의 품질을 보증하는 시점
- 운영 기준선
- 설치, 운용되기 시작한 소프트웨어 품질을 사용자 입장에서 평가하는 시점
- 형상관리활동
- 형상관리 활동
- 형상 식별(identification)
- 버전 제어(version control)
- 형상제어( configuration control)
- 형상감사(auditing)
- 수정된 SCI나 기준선이 미리 정해진 요구사항과 일치하는지를 검사.
- Verification&Validation 절차를 따른다.
- 형상상태보고( status accouting )
- 툴
- make
- 소스코드와 목적코드 버전 일치를 유지하는 보조 시스템
- RCS
- RCS Revisio Control System
- SCCS
- 변종
- 메쉬업
- 이론은 다른 노드에 추가
- 이곳은 SW 개념들의 메쉬업
- 생산성
- 품질
- 제품품질
- 프로세스(조직)품질
- 재사용성
- 모듈화
- 객체(클래스)
- 컴포넌트
- J2EE
Java2 Enterprise Edition
- EJB
- J2EE의 컴포넌트기술
- Enterprise Java Bean
- 컴포넌트 기반의 개발환경을 갖는다.
-이식성이 우수하면, 다른 JVM이나 다른 EJB서버에서도 잘 실행된다.
- 트랜잭션, 네트워킹, 보안 자원관리 등을 작업을 EJB 서버에서 제공한다.
- 종류 : Session빈, Entity 빈, Message-Driven 빈(MDB)
- COM+
- 분산객체시스템
기존에 분산 환경에서 원격 함수를 호출하는 방법은 CORBA의 IIOP(Internet Inter-ORB Protocol)나 DCOM의 ORPC(Object Remote Procedure Call)와 같은 프로토콜을 이용.
DCOM, CORBA의 통신포맷이 바이너리 형태여서, 서로 통신할 수 없다.
- RPC기반기술
- RPC는 TCP/IP 즉 연결지향형 호출이다.
- RPC기반 분산 컴퓨팅 기술의 4가지 문제점
- 연결지향->연결단절시 정보 손실
- 자원낭비->서버 메모리, 연결
- 대부분 방화벽 통과 못함
- 프로토콜 간 상호 호환 안됨
- -> 웹서비스 등장 배경
- MS-DCOM
- *- CORBA
language independent
- Java-RMI
- SOAP
- 메시지구성요소
- 문법규칙
- SOAP 메시지는
- XML을 사용해서 인코딩한다.
- SOAP 봉투 네임스페이스 사용한다.
- SOAP 인코딩 네임 스페이스 사용
- DTD를 참조할 수 없다.
- XML 처리 명령어가 포함되어서는 안된다.
- REST
- 서비스
- SW아키텍처
1) SW의 복잡성 증가로 SW의 구조와 구성 요소를 정의하고 구성요소간의 상호작용 관계를 파악하는 것이 중요하게 됨.이런 SW의 구조와 구성요소, 상호 관계를 정의해 놓은 문서
2) 소프트웨어의 WHAT에 대한 정의
- 요구분석
- 요구분석 단계
- 문제인식
- 문제 영역 안에 있는 중요한 사항을 파악하는 단계
- 면담, 설문조사, 현장조사
- 전개단계
- 종합단계
- 검토단계
- 문제 및 요구사항 결과, 일정, 조직을 재검토
- 문서화단계
- 7장. 요구공학 프로세스
- 타당성조사
- 타당성 조사(feasibility Study)
- 법적, 경제적, 기술적 관점
- 비전, 목표 제시
- 요구사항추출 및 분석
- 요구사항 분석 및 추출 프로세스
- 요구사항 발견
- 요구사항 분류와 구성
- 요구사항 우선순위 설정과 협상
- 요구사항 문서화
- 요구사항발견기술
- 사용자요구사항
- 시스템요구사항
- 구조적자연어
- 설계기술언어
- 그래픽표현
- 수학적명세
- 요구사항명세화
- 8장. 시스템모델
- 시스템 모델
- 요구사항 분석 모델, 분석 모델( "설계 모델"과 비교)
- 시스템 요구사항의 상세화 방법
- 시스템 명세를 문서화하는 것
- 그래픽 표현 방법
- 분석과 설계 프로세스간의 다리 역할
- 컨텍스트모델
- 행위모델
- 데이터모델
- 객체모델
- 구조적방법
- 구조적 방법
- 요구사항 추출과 분석의 일부인 상세 시스템 모델링에 대한 틀을 제공
- 나름대로의 시스템 모델을 유도하기 위해서 사용되는 프로세스와 모델에 적용될 규칙과 지침을 정의한다.
- 표준 문서가 시스템에 대해 생성된다.
- CASE 도구를 사용할 수 있다.
- 인터페이스 명세
- 9장. 중대한 시스템의 명세
- 10장. 정형명세
- 요구사항명세서작성
- 시스템 개요 및 요약
- 개발 운용 및 유지보수 환경
- 개발 여건과 장비
- 운용 절차 및 제약 조건
- 유지보수 방법과 환경
- 사용자 요구사항 및 제약 사항
- 기능적 요구사항
- 비기능적 요구사항
- 성능 요구사항
- 예외 조건 및 이의처리
- 초기 제공 기능 및 우선 순위
- 변경 및 개선 예정 사항
- H/W요구
- 사용자 인터페이스
- 자원, 인력에 대한 제약조건
- 자연어, 다이어그램 등 이용
- 제품과 프로세스 표준도 포함가능
- 시스템 아키텍처
- 시스템 요구사항 명세
- 시스템 모델
- 시스템 모델 기술
- 데이터 흐름 모델, 행위모델, 객체모델 등
- 구조적 분석 기법 - 자료흐름도, 자료사전, 소단위 명세서
- 시스템 진화
- 시스템의 기본적인 가정
- 하드웨어 진화로 인한 예상되는 변경, 사용자 요구의 변경
- 인수 조건 및 문서 표준
- 기능 및 성능 시험
- 코딩 표준 제도 및 문서 표준화
- 요구사항 검증
- 요구사항 검증
- 요구사항이 실제로 고객이 원하는 바를 정의했는지를 확인하는 것
- 요구사항 점검 항목( 요구사항 평가 기준 )
- 유효성 점검
- 시스템의 결과가 사용자가 예상하는 결과와 일치해야 한다.
- 일관성 점검
- 문서의 요구서항은 서로 살퉁되지 않아야 한다.
- 완전성 점검
- 요구사항 문서가 모든 기능을 정의하고 시스템 사용자가 의도한 제약 조건을 모두 포함하는지 검사
- 실현성 점검
- 기존 기술을 이용해서 요구사항이 구현될 수 있는지 점검
- 증명가능성
- 인도된 시스템이 명시된 각 요구사항과 일치하는지를 보여줄 수 있어야 한다.
- 해서 시험을 작성해야 한다.
- 좋은 요구 분석 명세서
- 일정한격식(formality)
- 작성 용이(Constructibility)
- 이해가 쉬워야(Comprehensibility)
- 최소의 정보만 포함해야 한다(Minimality)
- 설계와 구현에 적용 가능해야(Applicability)
- 확장 가능해야(Extensibility)
- 요구사항 관리
- 전통적 요구분석기법
- 구조적분석기법
- 구조적 분석의 특징
- 자료흐름지향(data flow oriented) 분석 기법
- 2가지 가정
- 시스템이 무엇을 하느냐에 관심 - 시스템의 기능과 프로세스
- 기능과 프로세스는 입력 자료 흐름을 출력자료 흐름으로 변환하는 액티비티이다.
- 기능의 하향식 분할
- 전통적인 데이터 처리 시스템을 개발하는 데 많이 사용
- DeMarco 고안
- 시스템을구성하는 프로세스들 사이의 데이터 흐름 파악이 중요
- 현재 시스템과 개발될싯템의 모형 생성이 중요 목표
- 시스템환경분석
- 컨텍스트 다이어그램
- UML의 UseCase Diagram에 해당한다.
- DFD Level 0에 해당한다.
- 요구수집
- 시스템모형
- 자료흐름도 작성
- 일명 Bubble chart라고도 한다.
- DFD 구성 요소
- 외부 입출력(단말,개체) - 사각형
- 처리(process, bubble) - 원
- 자료흐름 - 화살표
- 자료 저장소 - 한쌍의 평행선
- DFD 상세화
- 자료사전 작성
- 자료사전( Data Dictionary )
- 자료흐름도의 자료항목에 대한 정의를 모은 것
- 자료 흐름의 대상이 되는 "자료의 내용"을 구체적으로 명세화한다.`````````````````자료흐름도상의 모든 자료요소를 수학적으로 정의한다. 자료항목의 구성과 표기법이 있다.
- 소단위 명세서 작성
- 기능명세서, 소단위명세서, (Mini Spec)
- 자료흐름도의 최하위 프로세스가 어떤 기능을 하는가를 기술한 것` "처리과정 설명" 분석가가 작성하는 문서이다.
- 표현도구
- 기능명세 작성 방법
- Structured English(구조적 문장, 구조적 영어) - 구어체 텍스트
- 프로그램 설계 언어(PDL, Program Design Language)
- 의사코드( Pseudo code )
- 의사결정도 table, 의사결정트리 tree : 조건에 대한 판단을 표나 트리형태로 표현한것
- 의사 결정표
- 실시간 소프트웨어 개발 시 : 상태전이도, 상태전이표 이용
- 구조적 프로그래밍 설계시 :나씨-슈나이터만 도표( NS-chart )
- 흐름도(flow chart )
- 요구사항 명세서 작성
- 분석도구
- 자료사전(DD)
- 개체관계도(ERD)
- 소단위명세서(MiniSpec)
- 상태전이도(STD)
- 자료흐름도(DFD)
- 흐름도(FlowChart)
- NS도표
- 프로세스명세
- 데이터객체기술
- 자료구조지향 분석
- 자료구조 지향 분석
- 자료구조를 통해서 소프트웨어 구조를 유도할 수 있다고 보는 기법
- 워니어-오 분석 기법(DSSD, 출력중심)
- 잭슨 분석 기번( JSD, 입출력중심)
- 워니어-오 분석기법
- DSSD(Data Structured System Development) 개발 방법론
- 자료구조를 통해 소프트웨어 구조를 유도할 수 있음
- 출력 자료 구조에서 프로그램 구조와 입력 자료구조를 추론한다.
- 순차,선택, 반복의 세가지 구조를 사용해서 정보 계층을 표현한다.
- JSD기법
- JSD 기법
- Jackson system Development
- Tree Structured Diagram
- 입출력 자료 구조도
- 입출력 구조간의 대칭관계 점선 표기
- JSD는 대칭 관계로부터 프로그램 구조를 유도해 낸다.
- 설계
- 설계작업
- 소프트웨어 구조 설계
- 인터페이스 설계
- 자료 저장소 설계
- 프로그램 설계
- 상요자 인터페이스 설계
- 기본설계
- 전체적인 하드웨어 구조, 소프트웨어 구조, 제어구조, 데이터 구조, 검사계획서
- 상세설계
- 프로그램 제어구조, 데이터구조, 인터페이스, 소프트웨어 크기, 주요 알고리즘
- 객체지향설계
- 시스템구조설계
- 사용자 요구사항->시스템 요구사항->시스템설계, 객체설계
- 11장. 아키텍처 설계
- 평가모델
- ATAM
- Quality Attribute Scenario
- 품질속성유틸리티
- 아키텍처 설계 결정
- 시스템 구성 스타일 결정
- 모듈 분해 스타일
- 제어스타일
- 중앙집중제어
- 한 서브시스템이 제어의 전체적인 책임을 지고 다른 서브 시스템을 시작시키거나 종료시킨다.
- 제어의 결정은 몇몇 시스템의 상태 변수의 변화에 따라 정해진다.
- 이벤트기반싯템
- 11.5 참조 아키텍처
- 12장. 분산 시스템 아키텍처
- 멀티프로세서 아키텍처
- 클라이언트-서버 아키텍처
- 분산객체 아키텍처
- 객체요청중개자
- 객체요청중개자
- Object Request Broker
- 분산객체들은 네트워크상의 다수의 컴퓨터에 분산되고 미들웨어 ORB를 통해서 통신할 수 있다.
- CORBA
- 조직간의 분산 컴퓨팅
- 피어투피어아키텍처
- 서비스 지향 시스템 아키텍처
- 13. 응용아키텍처
- 데이터처리시스템
- 트랜잭션 처리 시스템
- 이벤트처리 시스템
- 언어처리시스템
- 객체설계
- 객체인터페이스 명세
- 사용자 인터페이스 설계
- 구조적설계
- 자료흐름도 -> 구조적설계 -> 소프트웨어 구조 식별( 모듈 식별 )
- 구조적 설계 결과 -> 구조도(Structure chart) 생성됨
- 자료흐름도 -> 구조적 설계 -> 구조도
- 모듈을 찾아내는 방법에는 '변환분석', '처리(거래)분석'이 있다.
자료흐름도 작성 및 검토->(자료흐름도) -> 구조도 작성( 변환분석, 거래분석) ->(개괄적 구조도) -> 설계의 평가(결합도, 응집도) ->(상세한 구조도)-> 구현준비 -> ( 논리적,물리적 프로그램 설계)
- 설계원리
- 추상화
- 기능추상화
- 자료추상화
- 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체(data object)를 구성하는 방법
- 제어추상화
- 정보은닉
- 정보은닉
- 설계상의 결정 사항들이 모듈안에 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 한다.
- 인터페이스를 통하여 메시지를 전달하도록 하는 개념
- 단계적분해
- 모듈화개념
- 수향가능명령어, 자료구조, 또는 다른 모듈을 포함하고 있는 독립 단위
- 응집도
- 모듈의 응집력의 정도(Myers)
- functional -> sequential -> communication -> procedural -> temporal -> logical -> coincidental
- 기능적 응집(functional cohesion) - 응집력 강함
- 순차적 응집(sequential cohesion)
- 모듈간 데이터 흐름 - 절차적 응집도와 다른 점
- 포함된 모듈간에 선행 및 후행 순서를 유지
- 모듈안의 소작업에 대한 결과가 다른 작업의 입력이 된 경우
- "다음 거래를 읽고 마스터 화일을 변경함"
- 통신적( 정보적, 교환적) 응집(communicational cohesion)
- 모듈간 동일 데이터 전달
- 모듈에 포함된 모든 작업들이 동일 입력 또는 출력 자료를 이용하여 서로 다른 기능 수행하는 경우
- "출력 파일을 출력하고 저장"
- 절차적 응집(procedural cohesion)
- 입력되는 데이터 없음
- 두 개 이상의 기능으로 된 모듈에서 기능 요소는 아무런 관련이 없고 수행순서만 정해진 경우
- 순차적으로 구성되어야 할 요소들을 하나의 모듈로 강제 통합함.
- "총계 출력, 화면을 지우고, 메뉴 추력, 메뉴 선택코드를 받는 작업"
- 시간적 응집(temporal cohesion)
- 같은 시간대에 처리해야 할 관련 작업을 포함한 모듈
- 한번만 수행되는 요소들의 모임
- 프로그램 초기화 모듈
- 논리적 응집(logical cohesion)
- 유사한 성격을 갖는 처리 요소들의 모임
- 매개 변수에 의하여 서로 다른 작업이 선택
- 우연적응집(coincidental cohesion) - 응집력약함
- 결합도
- 모듈의 결합도
- 결합도 약함 -> data -> stamp -> control -> content -> 결합도 강함
- 자료결합(data coupling) - 결합도 약함
- 모듈간의 인터페이스가 자료요소로만 사용된 경우
- 스탬프결합(stamp coupling)
- 모듈간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달되어 일부만 사용됨.
- 광역의 공통 자료를 필요로 하는 모듈사이에서 선별적으로 공유하는 경우
- 자료구조 전부가 사용되면 자료 결합이 됨
- 제어결합(control coupling)
- 다른 모듈내의 흐름을 제어하기 위해서 제어용 신호를 전달하는 경우
- 외
- 공통 결합(common coupling)
- 내용결합(content coupling) - 결합도 강함
- 한 모듈이 다른 모듈의 일부분을 직접 참조, 수정하는 경우
- 한 모듈에서 다른 모듈의 중간으로 분기(goto)하는 경우
- 다른 모듈의 국부 자료(local data)를 참조하는 경우
- 구조적설계기법
- 변환분석
- transformation analysis
- 입력흐름 ->변환센터 -> 출력흐름
- 변환분석
- 변환센터를 찾아내고 이름 중심으로 보조 모듈이 될 만한 기능을 찾아내는 것
- 처리분석
- transaction analysis
- 자료흐름도의 한 프로세스에서 여러개의 자료 흐름이 유출되는 경우에 사용
- 여러개의 작업중에 하나를 선택하게 하는 프로세스
- 소프트웨어 구조 스타일
- 소프트웨어 구조(software architecture)
- 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브 시스템 간의 통신 등을 포함한다.
- 저장소 구조
- MVC구조
- 클라이언트/서버 구조
- 계층 구조
- 파이프필터구조
- 필터 : 서브 시스템
- 파이프 : 서비시스템 사이의 관계
- 프로그램설계
- 프로그램 설계
- 시스템의 각 모듈 안에서 일어나는 일들과 모듈 안에서의 자료 구조에 관하여 자세히 설계하는 작업
- 알고리즘 선택
- 알고리즘 표현
- 의사코드
- 나씨-슈나이더만 도표
- 논리의 기술에 중점을 둔 도형을 이용한 표현 방법
- 사용자인터페이스 설계
- 설계표기법
- 흐름도(Flow Chart)
- 구조도(Structure Chart)
- HIPO
- 구조도에 입출력 부분의 추가가적으로 명세화함
- IBM에서 개발
- 구성
- 계층도표
- 총괄도표(Overview diagram) : 프로그램의 입력, 처리, 출력 표현
- 상세도표(Detail diagram) : 모듈별 기능을 입력, 처리, 출력으로 표현
- 나씨-슈나이터 도표
- 논리의 기술에 중점을 둔 도형식 표현 방법
- 순차,선택,반복구조 등의 제어 구조 사용
- 워니어-오 다이어그램
- 잭슨 다이어그램
- PDL
- Program Design Language
- PDL은 구어체 텍스트이고 컴파일되지 않음
- 구조적 설계서
- 시스템 구조
- 모듈설계
- 파일구조, 데이터베이스 설계
- 설계모델
- 구현
- 18. 소프트웨어 재사용
- 재사용전망
- 설계패턴
- 생성기 기반의 재사용
- 응용 프레임워크
- 응용 시스템 재사용
- 19. 컴포넌트 기반 소프트웨어 공학
- 재공학
- 객체지향
- 개발단계
- 사용사례작성
- 정적모형작성
- 동적모형작성
- 시스템설계
- 객체설계
- 객체설계의 원리
- SRP
- Single Responsibility Principle, 단일 책임의 원리
- ISP
- Interface Segregation principle, 인터페이스 분리의 원리
- DIP
- LSP
- OCP
- REP
- CCP
- CRP
- 언어
- V&V
- V&V
- V&V 계획수립
- 소프트웨어검사
- 자동화된 정적 분석
- Verification과 정형기법
- 시험
- 시험5단계
- 테스트 목표(what)
- 테스트 목표 설정 : 기능의 완벽성? 신뢰도?
- 테스트 방법(how)
- verification, validation, 블랙박스, 호이트박스, 자동화 도구 사용?
- 테스트 케이스 개발
- 테스트 케이스는 테스트 자료, 실행 조건을 포함한다.
- 테스트 예상 결과 작성
- 테스트 케이스 실행
- 테스트 하니스(test harness)를 실시할 수도 있다.
- 결과비교
- 테스트 결과와 테스트 오라클을 비교한다.
- 차이가 있다면 수정한 후 다시 리그레션 테스트(회귀테스트, regression test)를 수행한다.
- 시험종류
- 정적테스팅
- Inspection
- 설계 명세서대로 구현되었는지 verification
- 소프트웨어가 운영측면에서 유용한지는 알 수 없다.
- 성능과 신뢰성과 같은 특성을 점검할 수 없다.
- 동적테스팅
- 화이트박스시험
- 모듈의 논리적인 구조를 체계적으로 점검하는 구조적 테스트
- 동적 분석 : 모듈, 프로그램이 실행되는 동안 수행되는 테스트
- verification : 설계서대로 만들어졌나?
- 요구사항에서 빠지 기능은 찾아내기는 어렵지만, 불필요한 기능은 찾아낼 수 있다.
- 테스트케이스작성
- 논리흐름도
- 나씨-슈나이더만 도표
- 의사코드
- 코드
- 설계문서
- 테스트검증기준(coverage)
- 검증기준별 테스트 케이스 수
- 문장검증기준 < 선택검증 기준 < 경로 검증기준 < 조건 검증 기준
- 문장검증기준
- "모든 문장(코드)"를 실행하도록 기준을 잡아라.
- 프로그램에 있는 모든 문장의 코드가 적어도 한번씩은 실행되도록 한다는 기준
- 선택검증기준
- 다이아몬드로 표시된 선택 분기점을 파악해서 모든 선택적 상황을 포함시키도록 한다는 기준
- 경로검증기준
- "모든 경로"를 커버하도록 케이스를 잡아라.
- 수행가능한 모든 경로가 선택되도록 한다는 기준
- 조건검증기준
- "모든 조건"을 테스트하라.
- if, while문의 조건식의 모든 범위를 시험에 포함시킨다는 기준
- if(x>21 or y< 100)
- 테스트케이스작성
- 선택된 테스트검증기준(coverage)를 모두 커버하도록 테스트 케이스를 작성한다.
- 기본경로시험
- (basic path testing), 구조시험, 복잡도 시험
- MaCabe의 복잡도( Cyclomatic complexity)에 해당하는 경로마다 테스트한다.
- McCabe 복잡도
- 영역수(외부영역포함)
- V(G) = P+1( P, 분기 노드수 )
- 루프검증기준
- 조건시험
- 데이터흐름시험
- 그래프행렬(graph matrix)
- 제어구조 기반의 경로를 결정하는데 노드들의 매트릭스를 만들어 사용한다.
- 블랙박스시험
- 기능 테스트
- 요구분석서에 기술된 기능을 수행하는지 검사
- validation : 사용자 요구대로 만들어졌나?
- 요구사항에서 빠진 기능을 찾아낼 수 있지만, 불필요한 기능을 찾아낼 수는 없다.- 화이트박스와 반대
- 동치분해(분할)
- 동치분할
- 입력조건을 여러 개의 동치 클래스(equivalence class)로 나눈다.
- 동치클래스 : 같은 부류에 속하는 자료의 집합.
- 입력 조건 : 0<= x <= 100일때 이 조건을 동치 분할하면
x<0, 0<=x<=100, x>100이 된다.
- 이 클래스 내에서 하나의 값을 선택해서 테스트 케이스를 만든다.
- 경계값테스트
- 입력조건의 경계값과 범위밖의 값을 테스트 케이스로 선정한다.
- 직교배열테스팅
- 입력 개수가 많은 경우, 테스트 케이스를 합리적으로 결정할 수 있게 해 준다. 즉 전부 다 테스트하는 것보다 훨씬 적은 테스트 케이스를 가지고 좋은 범위의 테스트를 할 수 있다.
- 1,2,3을 가질 수 있는 파라미터가 x,y,z 3개라면 테스트 케이스는 3^3, 27이다. 이런 경우 테스트 케이스를 줄여주는 방법이다.
- 그래프기반테스팅
- 유한상태 테스트(finite state testing)
- 다양한 종류의 소프트웨어에 적용 가능한 유한 상태 모델을 테스트한다.
- 모든 "상태" 노드의 입력, 출력을 식별하고, 도달 가능한 모든 상태의 입력 조합을 포함하는 상태 전이 테이블을 정의한 후 테스팅을 수행하게 된다.
- 설계 명세에 대한 일치성을 verification하는 단계인 통합 테스팅 수행 시에 적용할 수 있다.
- 트랜잭션 흐름 모델 테스트
- 데이터 흐름 모델 테스트
- 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라 프로그램의 테스트 경로들을 선택하는 방법이다.
- 타이밍 모델 테스트
- 유한상태 테스트
- 트랜잭션흐름모델테스트
- 데이터 흐름 모델 테스트
- 타이밍 모델 테스트
- 결정테이블
- 상태전이
- 유스케이스
- 원인결과그래프
- 경험기반테스트
- 오류추정기법
- 유사 어플리케이션이나 기술에서의 경험,직관으로부터 테스트 케이스 추출
- 탐색적테스팅
- exploratory testing
- 테스트 케이스를 먼저 설계하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 것과 동시에 테스트 케이스를 작성하고 테스트 수행
- 감리에서 주로 사용
- 분류 트리 기법
- Classification Tree method
- 소프트웨어 일부 또는전체를 트리 구조로 분석 및 표현하고 거기에서 테스트 케이스를 도출
- 체크리스트
- 테스트 경험과 노하우를 정리하고 목록화하여 다음번 테스트에서 해당 내용을 누락없이 재활용하는 것을 목적으로 작성됨
- 특성테스팅
- ISO 9126 품질 특성을 염두에 두고 이를 근간으로 경험적으로 테스트 케이스를 도출
- 시험목적
- 성능시험
IT 서비스의 성능 테스트
http://news.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&keywords=%C0%D0%C0%BB%B0%C5%B8%AE&page=40&wr_id=36681
- 기능시험
- 스트레스시험
- 복잡도시험
- 논리경로의 복잡도를 평가하는 구조시험
- 유지보수의 용이성을 위해
- 컴포넌트 시험
- 인터페이스시험
- 매개변수 인터페이스
- 공유 메모리 인터페이스
- 프로시저 인터페이스
- 메시지 전달 인터페이스
- 시험 사례 설계
- 요구사항 기반 시험
- 분할 시험(partition testing)
- 구조시험(structural testing)
- 경로시험
- 소프트웨어 시험
- 모듈시험
- 단위시험, 모듈시험, 컴포넌트 시험, unit testing
- 주로 상세설계서에 기초한 모듈 구조를 시험하는 화이트박스 테스트이다.
- 테스트 대상 모듈을 가동하는 드라이버(driver), 타 모듈을 흉내내는 스텁(stub)가 필요하다.
- 통합시험
- 동시식 통합 시험
- 하향식 통합
- 주프로그램으로부터 호출이 시작된다.
- 통합되지 않는 하위 모듈을 대신하는 더미 모듈, 스텁이 필요하다.
- 깊이 우선 통합, 넓이 우선 통합
- 점증적 통합이므로 오류발견이 쉽고, 하드웨어 사용을 분산시킨다. (상향식,하향식 공통 )
- 상향식 통합
- 하위 기능을 수행하는 클러스터(빌드하고도함)
- 각 클러스터의 시험가동기(driver) 필요.
- 점증적 통합이므로 오류발견이 쉽고, 하드웨어 사용을 분산시킨다.
- 연쇄식(threads)통합
- 최선의 통합 방식
- 중요한 기능을 수행하는 최소 모듈 집합(threads)을 먼저 구현, 통합테스트한다.
- 반드시 시행해야 할 시험은 중요 모듈들에 대한 "회귀시험"이다.
- "상향식"과 "하향식"의 통합으로 "샌드위치"라고도 한다.
- 객체지향소프트웨어
- 회귀테스틩
- Regression test
- 변경이 추가오류를 가져오지 않는다는 것을 보장하는 활동
- 변경때문에 영향을 받게 될 기능에 초점을 맞춘 추가 시험
- "자동 재생도구"를 서용
- 별도의 드라이버나 스텁 사용하지 않음
- 테스트 환경을 다시 구축하기 때문에 비용이 많이든다.
- 스모크테스팅
- 시간이 매우 중요한 프로젝트에서 시간을 조절하기 위해 사용하는 테스팅 방법
- 통합 빌드의 기능을 제대로 수행하지 못하게 하는 오류들을 찾아내기 위한 일련의 테스트
- 소프트웨어 프로젝트가 계획된 일정을 맞추지 못하도록 할 가능성이 가장 큰 오류를 발견하는데 목적이 있다.
- 빌드를 통합하고 매일 스모그 테스트된다.
- 통합 방식은 상,하향식이다.
- 시스템시험
- 소프트웨어, 하드웨어 결합된 후 전체 시스템의 기능 또는 성능을 검증하는 테스트
- 통합 테스트가 "모듈의 인터페이스"에 초점을 뒀다면 그 이외의 측면에서 시스템을 시험하는 방법
- 구조테스트
- 화이트박스테스트와 개념적으로 동일
- 화이트박스 : 논리흐름에 존재하는 모든 경로를 점검
- 구조테스트 : 구조도(Structure chart)에 있는 모든 경로와 서브시스템간의 호출관계를 점검한다.
- 기능테스트
- 블랙박스 테스트와 유사
- 요구 분석에 나타난 사항이 제대로 구현되었는지 시험
- 전체 시스템이 하나의 블랙박스
- 스트레스 테스트
- 허용 가능한 입력 이상을 주었을때 시스템이 어떻게 처리하는가를 시험한다.
- 과부하 입력을 처히할때 시스템 반응 속도 측정
- 성능테스트
- 기능을 수행하는데 소요되는 시간을 측정한다.
- 정상적인 상태에서 제시간에 일을 처리하는가?
- 과부하인 경우에도 많이 지체하지 않고 처리하는가?
- 그렇지 않다면 해당되는 모듈의 효율을 높이도록 변경하여야 한다.
- 인수시험
- 알파시험
- 선택된 사용자가 개발자의 개발환경에 참여하여 시험한다.
- 개발자 환경
- 개발자 참석
- 사용자가 직접 테스트
- 베타시험
- 사용자가 직접 텟트
- 사용자 환경
- 개발자 참석 안함
- 설치시험
- 백투백시험
- 시스템의 구버전과 신버전 시험후 결과를 비교한다.
- 시험자동화
- 코드분석도구
- 정적분석기
- 정적분석기
- 프로그램을 실행하지 않고 원시 코드를 분석하여 오류나 적절성을 검사하는 도구
- 정적분석기들이 검사 결과는 프로그램의 특성을 잘 파악할 수 있도록 도와준다.
예를 들어, 흐름도와 함께 프로그램의 모든 가능 수행 경로를 알려주는 분석기가 있다면 경로 시험을 위한 테스트 계획을 쉽게 작성할 수 있다.
- 정적분석 도구 종류( 최은만 )
- 코드 분석 도구 도구 :
- 구조 검사 도구 도구:
- 논리흐름의 구조적인 결함 체크. 예) dead code 발견
- 데이터 분석 도구 :
- 원시코드에 정의된 데이터 구조, 선언,사용의 적절성
- 순서 검사 도구 :
- 이벤트의 순서 체크. 즉 파일 입출력 컴포넌트를 사용하기 전에 파일이 열려 있는지 확인할 수 있다.
- 정적분석 종류(
- 제어 흐름 분석
- 여러개의 출구나 입구를 갖는 반복문, 도달할 수 없는 코드 식별
- 데이터 사용 분석
- 인터페이스 분석
- 루탄, 프로시저 선언과 그의 사용과의 일치성 체크
- 정보흐름 분석
- 경로 분석
- 동적분석기
- 동적분석기
- 수행되는 프로그램의 동작이나 반응을 분석하는 도구
- 모듈의 호출 회수, 수행된 문장 번호 리스트를 만들어준다.
- 테스트 검증 기준(coverage)가 얼마나 만족되었는지를 알려주는 정보가 된다.
- 유지보수
- UML
- UML 구성요소
- 사물(Things )+ 관계 + 도해
- 사물
- 관계
- 도해
- UML2.0 - 13개 다이어그램( 9개 + TCP / I )
- Things
- 관계
- 의존
- 연관
- 클래스의 멤버로 다른 객체에 대한 참조를 갖는 구조?
- 연관 이름
- Work클래스 -- Company 클래스간에 "work" 연관이 있다.
- 클래스 역할
- Worker클래스의 이름 예-> Employee
- 다중성
- 객체( ! 클래스 )간 구조적 관계
- 1...* , *
- 일반화
- 실체화
- 다이어그램
- 구조
- 객체다이어그램
- 클래스
- 컴포짓 구조
- 컴포넌트
- 패키지
- 배포
- 행위
- 4+1뷰
- 유스 케이스 + LPCD
- Logical View
- Process View
- Implementation View( Component View )
- Deployment View
- 디자인패턴
- Strategy vs Template
- Strategy : 알고리즘 캡슐화
- Template : 알고리즘, Hook 메소드( 메소드 재정의)
- Mediator vs Facade
- 브릿지
- 객체생성패턴
- 구조개선패턴
- 어댑터
- 브릿지
- 추상화와 구현 분리,
- 인터페이스와 구현 분리
- 구현 - I/F - APP
- 컴포짓트
- 데코레이터
- 퍼사드
- 플라이웨이트
- 변하지 않는 공통 핵심부분과 변하는 부분 분리
- 프록시
- 행위개선패턴
- 인터프리터
- 템플릿메소드
- Hollywood principle
- 상위클래스에서 뼈대 알고리즘 정의, 하위 클래스에서 각 단계의 구현을 정의
- 커맨드
- 반복자
- 미디에이터
- 메멘토
- 옵서버
- 스테이트
- 스트래티지
- 비지터
- 비지터 패턴
- http://www.buggymind.com/24
- 객체("Element")의 구조는 고정적인데, 그 객체에서 정의해야 하는 오퍼레이션(메소드)는 정의되어 있지 않다. 추후에 필요에 따라서 추가되어야 한다.
- 이 메소드를 다른 객체에 정의해서 두어야 하는데, 이 객체를 "비지터" 즉 "Element에 대한 방문자"라고 한다.
- Element에는 방문자를 받아들이는 accept(Visitor객체)가 있고,
- Visitor에는 Visit(Element객체)라는 메소드가 있다. 이곳에서 Element객체의 타입에 따라서 적절한 오퍼레이션을 구현해준다.
- 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의?
- 책임연쇄
