본문으로 바로가기

소프트웨어 공학

category 01. 기술 - 요약 2014.11.07 14:39
IT정리-Software Engineering편
  • SW공학개념
    • S/W위기에서 출발
      • 1차 : 하드웨어는 발전하는데 SW 생산성 및 유지 보수성 향상은 더디다. GOTO문 없이 순차/분기/반복( 구조적)으로 가자.
      • 2차 : 기능 추가시 새 모듈도 추가. 새 모듈로 인해 중복이 발생=> 상속, 객체 지향으로 가자.
      • 3차 : SW는 Lead Time(요구->결과물)이 오래 걸림. 결과물이 빨리 나올 방법은? => 미리 준비해 놓자. 프레임워크( 재사용가능한 컴포넌트)
    • 위기 탈출 방법
      • 재사용: 방법론( 객체지향, CBD,SOA..)
      • 표준화 : CMMI, SPICE
    • 소프트웨어 공학
      • 재사용, 표준화를 통한 생산성, 품질을 높이기 위한 체계적,공학적 방법
      • "싸게, 빨리, 좋게"
    • faster
      • 재사용성
      • 모듈화
    • cheaper
    • better
      • 품질보증
        • SW프로세스
        • SW개발방법론
      • 품질관리
  • SW프로세스
    • 폭포수
    • 프로토타입 모델
    • 나선형 모델
      • 폭포수 + 프로토타이핑 장점
      • 계획-위험분석-공학화-사용자평가( planning-risk analysis-engineering-customer evaluation)
      • 규모가 큰 프로젝트 제작에 적합
    • 점증적 개발 모델
      • 점증적, 증분적 
        • 폭포수 모델의 변형
        • 증분으로 분리->통합
      • 진화적
        • 핵심 부분으로 먼저 개발->진화시킴
      • 증분개발모델
      • 진화적개발모델
  • SW개발방법론
    • 분석기법
      • Rumbaugh
        • OMT
          • OMT
            • 객체모델링
            • 동적모델링
            • 기능모델링
      • Booch
        • OOAD
      • Jachobsom
        • OOSE
    • 구조적방법론
      • 라이지움 p.14
      • 등장배경
        • GOTO문을 쓰지 말고, 구조적으로 프로그래밍을 하자.
        • -> 분석과 설계도 구조적으로 하자. 모듈의 분할과 정복
      • 특징
        • 데이터 흐름 즉 프로세스 위주의 분석,설계
        • "데이터 구성"에 대한 설계 방안 부족
        • 프로젝트 관리 및 조직, 역할 정의 없음
        • NS-Chart
        • 모듈의 분할과 정복-Top down
    • 정보공학방법론
      • 라이지움 p. 15
      • 등장배경
        • 정보 시스템(Biz 시스템)은 일반 소프트웨어 개발과는 달리 여러 요소가 얽힌 대규모다.
        • 프로젝트 관리, 진행 방법론 도입 필요
      • 특징
        • 기업중심
        • ISP( 정보 전략 계획) : Biz, 경영 전략 분석 후 IT 전략을 수립해야 한다고 제시 
          • ISP 후 분석->설계->구현 
        • 데이터 중심 : 데이터 분석, 설계 중심
        • 공학적 접근(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
          • 분>설>구>시 #1
          • 분>설>구>시#2
        • Transition
          • 교육, cut over(운영으로 올림)
      • 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
          • 기타
            • 코드 표준 coding standard
        • 스토리 카드
        • 4가치
        • 12기본원리
          • 개발원리
          • 관리원리
          • 구현원리
          • 환경요소
          • 기타
        • XP에서의 시험
      • 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단가 * 최종 보정 계수 적용 단가)
        • 용도
          • 기능점수 용도
            • 견적
            • 요구사항 변경 관리
            • 개발 생산성 측정
        • 측정절차
          • 측정절차
            • 측정유형결정
            • 측정범위와 어플리케이션 경계 식별
            • 데이터 기능 측정
              • ILF
              • EIF
            • 트랜잭션 기능 측정
              • EI
              • EO
              • EQ
            • 미조정 기능 점수 결정

            • 조정인자 결정
              • : TCF = 0.65 + 0.01 * TDI( DI합)
            • 조검 기능점수 결정 
              • : FP = UFP * TCF
          • 측정유형결정
          • 측정범위와 어플리케이션 경계식별
          • 데이터 기능측정
            • 복잡도와 기여도 측정(평균법 사용시 제외)
              • 복잡도 : 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사업대가기준
        • 기능점수에 의한 소프트웨어 개발비 = 개발원가 + 직접경비 + 이윤
          • 개발원가 = 기능점수 * 단계별 기능점수담 단가 * 보정계수
            • 단계 : 분석,설계,구현,시험
          • 보정계수 = 규모보정, 어플리케이션유형 보정계수, 언어 보정계수, 품질및특성 보정
            • 언어보정계수는 구현과 시험단계에만 적용
          • 직접 경비
          • 이윤
            • 개발원가의 25% 이내
        • 보정계수
          • 규모보정
          • 어플리케이션보정
            • 어플리케이션 유형 보정 계수
              • 업무처리용 - 보정계수 제일 낮음
              • 지휘통제용(군사용) - 보정계수 제일 높은
              • 지공통시 지멀과업
                지휘통제용, 공정제어용, 통신제어용, 시스템용, 지능정보용, 멀티미디어, 과학기술, 업무처리용
          • 언어보정
            • 언어보정 계수
              • 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 9000 시리즈
        • 제품 품질
          • 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의 통신포맷이 바이너리 형태여서, 서로 통신할 수 없다.
                  출처 : SOAP에 대하여(http://blog.daum.net/ossogood/8435521)
                  • RPC기반기술

                    • RPC는 TCP/IP 즉 연결지향형 호출이다.
                    • RPC기반 분산 컴퓨팅 기술의 4가지 문제점
                      • 연결지향->연결단절시 정보 손실
                      • 자원낭비->서버 메모리, 연결
                      • 대부분 방화벽 통과 못함
                      • 프로토콜 간 상호 호환 안됨
                      • -> 웹서비스 등장 배경

                  • SOAP
                    SOAP

                    • 오재우 p.463
                      • 정보교환용 프로토콜
                    • 메시지구성요소
                      • 봉투요소
                      • 헤더요소
                      • body요소
                      • 결함요소
                    • 문법규칙
                      • SOAP 메시지는
                        • XML을 사용해서 인코딩한다.
                        • SOAP 봉투 네임스페이스 사용한다.
                        • SOAP 인코딩 네임 스페이스 사용
                        • DTD를 참조할 수 없다.
                        • XML 처리 명령어가 포함되어서는 안된다.
                  • REST
                • 서비스
                  • 웹서비스
                    http://www.simpleisbest.net/articles/1693.aspx
                    • XML
                    • 웹1.0

                      • 모든 자료는 디렉토리에 체계적으로 분뢰되어 있고, 
                      • 사용자는 단순한 소비자
                    • 웹2.0
                      • "참여,공유,개방" 철학으로 소비자 중심의 모델
                      • "참여,공유,개방"을 위한 플랫폼으로서의 웹
                    • 웹3.0
                      • 유비쿼터스 환경에 적합한 웹
                      • 시멘틱과의 결합
                      • 인공지능적인 웹
                • SW아키텍처
                  1) SW의 복잡성 증가로 SW의 구조와 구성 요소를 정의하고 구성요소간의 상호작용 관계를 파악하는 것이 중요하게 됨.이런 SW의 구조와 구성요소, 상호 관계를 정의해 놓은 문서

                  2) 소프트웨어의 WHAT에 대한 정의
                  • 프레임워크
                    아카텍처의 모듈화( 컴포넌트화 )
                  • 플랫폼
                    개발환경
        • 요구분석
          • 요구분석 단계
            • 문제인식
              • 문제 영역 안에 있는 중요한 사항을 파악하는 단계
              • 면담, 설문조사, 현장조사
            • 전개단계
              • 파악한 문제에 대해서 더 자세히 조사
            • 종합단계
              • 자동화 도구를 사용해서 통합 모형으로 표현
            • 검토단계
              • 문제 및 요구사항 결과, 일정, 조직을 재검토
            • 문서화단계
              • 요구사항 명세서 작성
          • 7장. 요구공학 프로세스
            • 타당성조사
              • 타당성 조사(feasibility Study)
                • 법적, 경제적, 기술적 관점
                • 비전, 목표 제시
            • 요구사항추출 및 분석
              • 요구사항 분석 및 추출 프로세스
                • 요구사항 발견
                • 요구사항 분류와 구성
                • 요구사항 우선순위 설정과 협상
                • 요구사항 문서화

              • 요구사항발견기술
                • 관점지향분석
                  • 상호작용관점
                  • 간접적관점
                  • 도메인관점
                • 면담
                • 시나리오
                • 유스케이스
                • 민속학
              • 사용자요구사항
                • 자연어
              • 시스템요구사항
                • 구조적자연어
                  • 표준양식,템플릿
                  • ULM 순차다이어그램
                • 설계기술언어
                • 그래픽표현
                  • 시스템모델
                • 수학적명세
            • 요구사항명세화
              • 8장. 시스템모델
                • 시스템 모델
                  • 요구사항 분석 모델, 분석 모델( "설계 모델"과 비교)
                  • 시스템 요구사항의 상세화 방법
                  • 시스템 명세를 문서화하는 것
                  • 그래픽 표현 방법
                  • 분석과 설계 프로세스간의 다리 역할

                • 컨텍스트모델
                  • 컨텍스트모델
                    • 외부관점
                    • 시스템과 환경과의 경계를 정의한다.
                  • 아키텍처 모델
                  • 프로세스모델
                • 행위모델
                  • 데이터흐름모델
                  • 상태기계모델
                  • 자극-반응 모델
                • 데이터모델
                  • 개체관계속성모델(ERA)
                  • 데이터사전
                • 객체모델
                  • ULM 객체 클래스
                    • 상속
                    • 일반화
                    • 객체집합
                    • 객체행위모델링
                      • 순차다이어그램
                      • 협력다이어그램
                • 구조적방법
                  • 구조적 방법
                    • 요구사항 추출과 분석의 일부인 상세 시스템 모델링에 대한 틀을 제공
                    • 나름대로의 시스템 모델을 유도하기 위해서 사용되는 프로세스와 모델에 적용될 규칙과 지침을 정의한다.
                    • 표준 문서가 시스템에 대해 생성된다.
                    • CASE 도구를 사용할 수 있다.
                  • 자료흐름도
                    • 자료사전
                    • 소단위명세
              • 인터페이스 명세
              • 9장. 중대한 시스템의 명세
              • 10장. 정형명세
                • 대수명세
                  • 순차언어
                    • Larch, OBJ
                  • 병렬언어
                    • Lotos
                    • Brinksma

                • 모델기반명세
                  • 순차언어
                    • Z
                    • VDM
                    • B
                  • 병렬언어
                    • CSP
                    • Petri Nets
            • 요구사항명세서작성
              • 시스템 개요 및 요약
              • 개발 운용 및 유지보수 환경
                • 개발 여건과 장비
                • 운용 절차 및 제약 조건
                • 유지보수 방법과 환경
              • 사용자 요구사항 및 제약 사항
                • 기능적 요구사항
                • 비기능적 요구사항
                • 성능 요구사항
                • 예외 조건 및 이의처리
                • 초기 제공 기능 및 우선 순위
                • 변경 및 개선 예정 사항
                • 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 상세화
                    • 2-3 레벨 상세화가 적당
                  • 자료사전 작성
                    • 자료사전( 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. 응용아키텍처
                • 데이터처리시스템
                • 트랜잭션 처리 시스템
                • 이벤트처리 시스템
                • 언어처리시스템
            • 객체설계
              • 객체식별
              • 설계모델
                • 정적모델
                  • 서브시스템모델
                    • ULM의 패키지
                • 동적모델
                  • 순차모델
                  • 상태기계모델
            • 객체인터페이스 명세
            • 사용자 인터페이스 설계
          • 구조적설계
            • 자료흐름도 -> 구조적설계 -> 소프트웨어 구조 식별( 모듈 식별 )
            • 구조적 설계 결과 -> 구조도(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)
                • 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브 시스템 간의 통신 등을 포함한다.
              • 저장소 구조
                • repository architecture
              • MVC구조
              • 클라이언트/서버 구조
              • 계층 구조
              • 파이프필터구조
                • 필터 : 서브 시스템
                • 파이프 : 서비시스템 사이의 관계
            • 프로그램설계
              • 프로그램 설계
                • 시스템의 각 모듈 안에서 일어나는 일들과 모듈 안에서의 자료 구조에 관하여 자세히 설계하는 작업
              • 알고리즘 선택
              • 알고리즘 표현
                • 의사코드
                • 나씨-슈나이더만 도표
                  • 논리의 기술에 중점을 둔 도형을 이용한 표현 방법
            • 사용자인터페이스 설계
            • 설계표기법
              • 흐름도(Flow Chart)
              • 구조도(Structure Chart)
                • fan-in
                • fan-out
              • HIPO
                • 구조도에 입출력 부분의 추가가적으로 명세화함
                • IBM에서 개발
                • 구성
                  • 계층도표
                  • 총괄도표(Overview diagram) : 프로그램의 입력, 처리, 출력 표현
                  • 상세도표(Detail diagram) : 모듈별 기능을 입력, 처리, 출력으로 표현
              • 나씨-슈나이터 도표
                • 논리의 기술에 중점을 둔 도형식 표현 방법
                • 순차,선택,반복구조 등의 제어 구조 사용
              • 워니어-오 다이어그램
              • 잭슨 다이어그램
              • PDL
                • Program Design Language
                • PDL은 구어체 텍스트이고 컴파일되지 않음
            • 구조적 설계서
              • 시스템 구조
                • 시스템구조도
                • 자료사전
              • 모듈설계
                • 알고리즘
                • 인터페이스
                • 기능설명
              • 파일구조, 데이터베이스 설계
                • 외부파일(데이터베이스) 논리적 구조
          • 설계모델
            • 기능모델
              • DFD
              • Use Case
            • 정적모델
              • ERD
              • 클래스 Diagram
              • ...
            • 동적모델
              • STD
              • 순차
              • 상태
              • 액티비티
        • 구현
          • 18. 소프트웨어 재사용
            • 재사용전망
            • 설계패턴
            • 생성기 기반의 재사용
            • 응용 프레임워크
            • 응용 시스템 재사용
            • 19. 컴포넌트 기반 소프트웨어 공학
            • 재공학
          • 객체지향
            • 개발단계
              • 사용사례작성
              • 정적모형작성
              • 동적모형작성
              • 시스템설계
              • 객체설계
            • 객체설계의 원리
              • SRP
                • Single Responsibility Principle, 단일 책임의 원리
              • ISP
                • Interface Segregation principle, 인터페이스 분리의 원리
              • DIP
              • LSP
              • OCP
              • REP
              • CCP
              • CRP
          • 언어
            • AI
              • LISP
              • PROLOG
        • 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...*  , *
              • 객체 참조 멤버
            • 일반화
            • 실체화
          • 다이어그램
            • 구조
              • 객체다이어그램
              • 클래스
              • 컴포짓 구조
              • 컴포넌트
              • 패키지
              • 배포
            • 행위
              • 사용사례
                • 구성요소
                  • 액터
                  • 사용사례
                  • 시나리오
                  • 관계
              • 인터랙션
                • 순차
                • 통신
                • 인터랙션오버뷰
                • 타이밍
              • 액티버티
                • 구획면(Swim Lane)
              • 상태기계
          • 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
              • 상위클래스에서 뼈대 알고리즘 정의, 하위 클래스에서 각 단계의 구현을 정의
            • 커맨드
              • 요청을 객체로 캡슐화
            • 반복자
            • 미디에이터
              • m:m 관계 연결
            • 메멘토
              • 내부 상태 객체화, undo 기능 가능
            • 옵서버
              • 1:n rorcp dusruf
            • 스테이트
              • 상태에 따라 행위를 변경할 수 있다.
            • 스트래티지
              • open-closed 원칙
              • 정책 패턴
            • 비지터
              • 비지터 패턴
                • http://www.buggymind.com/24
                • 객체("Element")의 구조는 고정적인데, 그 객체에서 정의해야 하는 오퍼레이션(메소드)는 정의되어 있지 않다. 추후에 필요에 따라서 추가되어야 한다.
                • 이 메소드를 다른 객체에 정의해서 두어야 하는데, 이 객체를 "비지터" 즉 "Element에 대한 방문자"라고 한다. 
                • Element에는 방문자를 받아들이는 accept(Visitor객체)가 있고, 
                • Visitor에는 Visit(Element객체)라는 메소드가 있다. 이곳에서 Element객체의 타입에 따라서 적절한 오퍼레이션을 구현해준다.
              • 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의?
            • 책임연쇄

        '01. 기술 - 요약' 카테고리의 다른 글

        보안 프레임워크  (0) 2014.11.07
        소프트웨어 공학  (0) 2014.11.07
        네트워크  (0) 2014.11.07
        인프라, 컴퓨터 아키텍처  (0) 2014.11.07
        엔터프라이즈 솔루션  (0) 2014.11.07
        데이터베이스  (0) 2014.11.07

        댓글을 달아 주세요

        티스토리 툴바