devsungyeon

You only live once.
개발 일지

Software 정리

궁금한 점이나 오류는 댓글로 달아주시면, 답변 혹은 수정하겠습니다! “:)”

Top

PART 01 소프트웨어공학의 개념

  • SDLC ; 타당성 조사 - 계획 - 사용자 요구파악 - 분석 - 설계 - 구현 - 시험 - 유지보수

1. 소프트웨어의 개념

  • 생산성 향상
  • 품질향상
  • 재사용 가능한 소프트웨어 개발
    • System의 5대 구성요소 ; Input, Process(Transformation), Output, Control, Feedback O = P(I) Input -> Process(Transformation) -> Output

  • 방법론

    구분 구조적 방법론 정보공학 방법론 객체지향 방법론
    = 프로세스 중심 방법론
    = 자료흐름방법론
    = 절차식 방법론    		 자료중심 방법론  
    중점 Process 중심 Data 중심 객체 중심
    생명주기 Top-down Top-down Bottom-up

to the Top

2. 소프트웨어의 개념

to the Top

3. 소프트웨어의 위기

  • Brooks Raw ; 인력을 추가로 투입하더라도 오히려 프로젝트 시간은 지연될 수 있다.

to the Top

4. 소프트웨어 개발 프로세스 모형

  • SDLC ; 타당성 조사 - 계획 - 사용자 요구파악 - 분석 - 설계 - 구현 - 시험 - 유지보수
    • 소프트웨어 개발 프로세스 모형
구분 설명 장점 단점
폭포수 산출물 명확.
문서와 결과물 도출에 중점		 가시성이 좋음. 소규모 적합 신규 프로젝트 부적합.
새로운 요구 반영 어려움
프로토타이핑 견본품.
신속한 원형화		 폭포수의 전 단계로 올라갈 수 없는 점을 보완. 관리, 통제가 어렵다.
나선형 폭포수, 원형의 장점을 취합.
점진적		 대규모 시스템 적합 초기 위험 분석 오류 시, 실패 가능성
V-모형 분석과 설계는 왼편. 테스팅과 유지보수는 오른편.
작업과 결과의 검증에 초점		 테스트 단계에서 오류 발견 시 되돌아갈 수 있음  
점증적 모형 선형순차 + 프로토타입 결합 중요,기초 기능을 우선 개발.
확장하는 형태. 점증적(추가) & 반복적(보완)
신규 프로젝트 적합		 관리 문제
검증 문제
계약 문제
유지보수 문제
UP(Unified Process) 모형 UML. 객체 지향 분석 및 설계를 지원하기 위한 Diagram
Usecase Diagram
점증적 반복
가. 개 념 정립(도입, Inception) ; 개략적 파악
나. 전개(정련, Elaboration) ; 비전 구체화. 아키텍처 프레임워크 설정
다. 구축(Construction) ; 구현 및 설치 준비. 문서를 User에게 인도하기 위해 준비
라. 전환(전이, Transition) ; 인도. 테스트, 설치, 다음 반복 단계를 준비		 사용자 요구 즉시 파악 가능  
신속한 소프트웨어 개발 모형 신속하게 개발하여 새로운 도전과 기회에 반응하기 위함. 중첩된 반복적인 프로세스.
설계 문서 최소화		  
  • 신속한 소프트웨어 개발 모형

1) 애자일(agile) 기법

  • 문서화 < 구현 < 시험
  • 문제점
    • 대규모에는 부적합. 중소규모에 적합
    • 시스템 개발에 필요한 시간에 대해 비용을 지불
    • 원리
원리 설명
고객 참여 고객은 개발 프로세스 전체에 긴밀하게 참여
점증적인 인도 점증적으로 인도
사람은 프로세스가 아님 규정된 프로세스 없이 자신들의 작업 방식으로 개발. (프로세스보다 사람)
변경을 수용 변경들을 수용할 수 있도록 설계
단순성의 유지 모두 단순성에 초점

2) XP(eXtreme Programming) 모형

  • 의단피용존!
  • 의사소통, 단순함, 피드백, 용기, 존중. ‘고객에게 최고의 가치를 가장 빨리’
    • 경량 방법론
    • 고객의 참여를 극한 수준까지 유도.
    • 스토리 카드. ; 고객의 요구 요약. (요구분석서, CRC 카드)
    • 시험 우선 개발 ; 코드보다 시험을 먼저 작성
    • 중요 키워드 ; 점증적, 소규모 릴리즈, 시험개발우선, 짝 프로그래밍 등.
      • XP의 프로세스 ; 계획 - 설계 - 코딩 - 테스팅

3) 스크럼(Scrum)

  • 30일마다 동작가능한 제품을 제공하는 스프린트(Sprint) 2~4주기 제품 생산
    • 스크럼 ; 매일 이루어지는 스크럼 팀의 회의. 매일 짧은 회의(15분)
    • 스프린트 ; 개발에서 이루어지는 반복
  • 제품 백로그 ; 스크럼 팀이 해결해야 하는 “해야 할 일(to do)”에 대한 목록이다. 그 목록의 내용은 소프트웨어에 대한 특징, 소프트웨어 요구사항, 사용자 스토리에 대한 정의 또는 아키텍처 정의나 사용자 문서와 같이 추가적으로 필요한 업무에 대한 설명일 수도 있다.

4) TDD 테스트 주도 개발(Test-driven development)

  • 테스팅과 코드 개발을 중첩시키는 개발 방법론.
  • JUnit과 같은 자동화된 테스트 프레임워크 필수적.
  • 신규 개발에 가치. (기존x)
  • 장점
    • 코드 커버리지 ; 모든 코드의 일부는 하나의 연관된 테스트가 있어야 함. 초기 결함 발견.
    • 회귀 테스팅 ; 테스트 스위트(test suite)가 점증적 개발. 변경이 새로운 버그를 초래하지 않았는지 회귀 테스트 항상 실행
      • 테스트 스위트(test suite) ; 테스트 케이스들을 하나록 묶은 것.
    • 단순화된 디버깅 ; 디버깅 도구 사용 불필요.
    • 시스템 문서화

5) RAD(Rapid Application Development)

  • 4세대 언어로부터 진화.
  • 매우 짧은 개발 주기.
  • 컴포넌트 기반으로 개발. 재사용이 가능한 컴포넌트의 개발을 중요시.

6) 컴포넌트 기반 개발(CBD ; Component-based Development)

  • 데이터와 그 데이터를 조작하는 연산을 하나로 묶는 클래스화. 재사용

cf) 애자일 UP(Agile Unified Process ; AUP)

  • inception, elaboration, contruction, transition을 채택.

to the Top

PART 02 소프트웨어 프로젝트 관리

1. 프로젝트 범위

  • 3P ; People, Process, Problem
  • 4P ; People, Process, Product, Project
  • Brooks Law ; 스케줄 지연에 대해 추가 인력을 투입이 오히려 악화될 수 있다.
  • PMBOK(Project Management Body of Knowledge, 프로젝트관리지식체계)
    • 프로세스 그룹 ; 시작, 기획, 실행, 통제, 종료
    • 지식 영역 10개 항목 ; 통합, 범위, 시간, 원가, 품질, 인력자원, 의사소통, 위험, 조달, 이해관리자
      • 통합관리
      • 범위관리
      • 시간관리
      • 원가관리
      • 품질관리
      • 인력자원관리
      • 의사소통관리
      • 위험관리
      • 조달관리
      • 이해관리자관리

to the Top

2. 비용 계획

  • 개발기간이 길수록 생산성이 높다.

  • 비용 산정 방법

    • 전문가의 감정

      • 경험과 지식을 갖춘 2명 이상의 전문가에게 의뢰
        • 장점 : 간편, 편리
        • 단점 : 낙관적, 비과학적

    • 델파이(Delphi)식 산정

      • 전문가 + 익명의 조정자(coordinator)
        • 장점 ; 여러 전문가들이 여러 각도에서 산정하여 합의 도출.
        • 단점 ; 다양한 기법을 아는 전문가 부재시 어려움.

    • LOC(line of code) 기법

      • 작업예측치 E = [최적치 + 4*근접치 + 최악치] / 6
      • 작업 편방 편차 = [(최악치 - 최적치) / 6]2
      • 노력 MM = 투입인원 * 개발기간 = 총LOC / 1인당월평균생산코드라인수
      • 개발비용 = MM * 단위비용(1인당 월 인건비)
      • 개발기간 = MM / 투입인원
      • 생산성 = 총LOC / MM = 1인당월평균생산코드라인수

    • COCOMO 기법

      • Boehm이 제안한 원시 프로그램의 규모에 의한 비용예측 모델

      • 수학전 산정기법이지만 비정형모델

        유형 설명
        Organic, 유기적, 조직형 50KDSI, 5만 라인 이하
        semidetached, 반 내장형 300KDSI, 30만 라인 이하
        embedded, 내장형 300KDSI, 30만 라인 이상
        비용추정 단계 및 적용변수 구체화 정도에 따른 분류 설명
        Basic COCOMO 원시코드 라인 수만으로 비용 계산
        Intermediate COCOMO 4가지 특성의 15가지 요인을 가미하여 곱한 가중치 계수
        ㄱ. 제품의 속성
        ㄴ. 컴퓨터의 속성
        ㄷ. 개발요원의 속성
        ㄹ. 프로젝트의 속성
        Detailed COCOMO 노력승수 = 개발 공정별 노력승수 * 개발 공정별 가중치

    • FP 기능점수 방법

      • 각 기능에 대해 가중치를 부여하여 요인별 가중치를 합산하여 규모, 복잡도, 난이도를 산출.
      • 라인 수 LOC에 기반을 두지 않는다.
        • EI external input
        • EO external output
        • EQ external quary
        • ILF internal logical file
        • EIF external interface file
      • TCF = 0.65 + 0.01 * 총영향도( sum 가중치 * 인자)
      • FP = UFP * TCF
        • UFP Unadjusted Function Point ; 조정 전 기능점수
      • FP = 총LOC = 가중치 * 갯수 ; 아마 같다고 판단…

cf) 파킨슨 법

  • 일은 획득 가능한 분량을 채우기 위해 확장된다.
  • 공무원의 수는 경중이나 유무에 관계없이 일정 비율로 증가.

to the Top

3. 일정 계획

- SDLC 선정 -> WBS -> CPM/PERT -> Gantt Chart

  • SDLC 선정
    • Software Development LifeCycle
    • Software 생명 전반에 걸친 생명주기
  • WBS (Work Break-down Structure)
    • 프로젝트 진행에서 일어나는 모든 작업을 찾아내기 위해 프로젝트의 목표를 작은 중간 목표로 세분화한 것. *연관된 소작업으로 분류하는 계층도표
  • CPM/PERT
    • PERT와 CPM은 모두 프로젝트를 서로 연관된 소작업으로 구분하고 시작부터 끝나는 지점까지의 망 형태로 분석함.
    • PERT(Program Evaluation and Review Technique)
      • 불확실성을 고려.
      • 작업 예측치(d) = ( 낙관치 + [4x기대치] + 비관치 ) / 6
      • 작업 평방 편차 = [ (비관치 - 낙관치) / 6 ]2
    • CPM(Critical Path Method)
      • 예산과 개발기간을 최적화 하려는 일정계획 방법.
      • 임계경로(critical path) 방법에 의한 프로젝트 최단 완료시간을 구함.
  • Gantt chart
    • 프로젝트의 각 공정들이 언제 시작되고 종료되는지를 막대 도표로 표시.
    • 여유시간 = 가장 늦은 착수일 - 가장 이른 착수일 = 임계경로 - 남은 작업

to the Top

4. 조직 계획

  • 개발 조직 방법

    분류 정의 영문 장점 단점
    분산형, 민주적, 에고레스(Egoless) ; mesh 민주적 분산형 DD ; Democratic Decentralized 복잡한 장기 프로젝트 적합 대규모 프로젝트 부적합
    중앙 집중형 ; star 통계적 집중형 CC ; Controlled Centralized 책임 프로그래머의 리드에 따라 빠른 의사결정 및 신속 개발 책임 프로그래머의 능력에 민감
    혼합형, 계층형 ; tree 통계적 분산형 CD ; Controlled Decentralized 대규모 프로젝트 적합.
    의사전달 경로를 허용    		 우수한 프로그래머가 관리자로 승진 시, 2중의 부정적 효과.

to the Top

5. 위험 분석 및 관리

  • 식별 - 분석 - 계획수립 - 감시
  • 위험평가 단계 ; 위험 식별, 위험 분석(위험운선순위)
  • 위험통제 단계 ; 위험 계획, 위험 감시

to the Top

6. 개발 계획서

to the Top

PART 03 소프트웨어 품질보증과 품질관리

1.품질보증의 개념

  • 품질보증
    • 확인(Validation) ; 사용자 요구 기능 만족 여부 검사
    • 검증(Verification) ; 개발자 입장. 명세서대로 개발되었는지 검토
  관점 시험 주체 대상
Validation 사용자 사용자 or 시험자 사용자 요구
Verification 개발자 전문시험자 명세서
  • McCall의 sw 품질요인
    • 제품 운영
      • 정확성 ; 사용자의 요구정도를 충족시키는 정도
      • 신뢰성 ; 요구된 기능을 계속적으로 수행할 수 있는 정도 → 사용자, 발주자, 유지보수자가 공통으로 관심을 보이는 항목
      • 용이성 ; 쉽게 배울 수 있고 사용할 수 있는 정도
      • 무결성 ; 허용되지 않은 사용이나 자료의 변경을 제어하는 정도
      • 효율성 ; 최소의(주어진) 시간과 기억용량을 소비하여 요구되는 기능을 수행할 수 있는 정도 → 사용자, 발주자가 공통으로 관심을 보이는 항목
    • 제품 개조
      • 유지보수성 ; 오류가 발견되었을 때 쉽게 교정되는 정도
      • 유연성(융통성) ; 기능의 추가나 다른 환경에서 적응하기 위해 쉽게 수정될 수 있는 정도
      • 시험성 ; 쉽고 철저하게 시험될 수 있는 정도
    • 제품 전이
      • 이식성 ; 여러 하드웨어, 운영체제 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
      • 재사용성 ; 전체나 일부가 다른 응용 목적으로 사용될 수 있는 정도
      • 상호운영성 ; 다른 소프트웨어와 정보를 교환할 수 있는 정도.
  • sw 품질보증 분야
    • 품질 관리 시스템 ; 조직
      • ISO 9000 시리즈
      • TickIT
    • 제품 품질 ; 제품(산출물)
      • ISO / IEC 9126
      • ISO / IEC 12119
      • ISO / IEC 14598
      • ISO / IEC 25000 = 9126+12119+14598
    • 프로세스 품질 ; 개발 공정(과정)
      • ISO / IEC 12207
      • SPICE(ISO 15504)
      • CMM
      • CMMi = SPICE(ISO 15504) + CMM

to the Top

2. 품질 관리 시스템

  • ISO 9000 ; 기업(조직) 을 평가

to the Top

3. 제품 품질

  • ISO / IEC 9126 ; 신사이기유효

    • 암기법 ; 신사이기(에) 유효

      주특성 내용 부특성
      신뢰성 성능 수준을 유지 성숙성
          결함허용성
          회복성
      사용성 사용자에 의해 이해, 학습 이해성
          학습성
          운용성
          친밀성
      이식성 다양한 환경에서 운영 적응성
          설치성
          공존성
          대체성
      기능성 요구, 기능을 제공 적합성
          정확성
          상호운용성
          보안성
      유지보수성 제품을 변경할 수 있는 능력 분석성
          변경성
          안정성
          시험성
      효율성 규정된 조건에 사용되는 자원 및 성능을 제공하는 능력 시간반응성
          자원활용성

  • ISO/IEC 14598

    • 평가 방법과 절차 정의

  • ISO/IEC 12119

    • 품질 요구사항 및 테스트에 관한 표준안
  • ISO/IEC 25000
    • 하기를 합친 것.
    • ISO/IEC 9126 ; 제품 품질 모델
    • ISO/IEC 14598 ; 품질 평가 방법과 절차
    • ISO/IEC 12119 ; 품질 요구사항 및 테스트

  • ISO/IEC 25010

    • 신사이기유효 + 호환성, 보안성

to the Top

4. 프로세스 품질

  • ISO/IEC 12207
    • 프로세스 중심
    • 기본 생명주기 프로세스 ; 획득, 공급, 개발, 운영, 유지보수
    • 지원 생명주기 프로세스 ; 문서화, 품질보증, 형상관리, 검증, 확인, 문제해결, 합동검토, 감사
    • 조직 생명주기 프로세스 ; 기반구조, 관리, 개선, 훈련
  • CMM ; 생산하는 능력을 정량화
    • 프로세스 성숙단계 5단계
      • 초기 ; 예측불가
      • 반복 ; 문서화 가능
      • 정의 ; 표준화, 일관된 프로세스
      • 관리 ; 정량적 관리평가, 예층 가능한 프로세스
      • 최적화 ; 개선되는 프로세스
  • SPICE(ISO/IEC 15504) ; 최저점을 대표점수로 산정
    • 프레세스 수행능력 - 6단계로 나누어 평가
      • Lv0 : 불완전 ; 실패. 결과물 없음.
      • Lv1 : 수행 ; 목적. 성취는 없음.
      • Lv2 : 관리 ; 문서화 단계.
      • Lv3 : 확립 ; 표준 프로세스.
      • Lv4 : 예측 ; 정량적 이해, 수행 예측
      • Lv5 : 최적화 ; 지속적 프로세스 감시 및 개선. 현재 및 미래 경영목표에 효과적인 적응.
    • 프레세스 영역
      • 고객공급자 프로세스 ; 발주, 공급자 선정, 고객인수, 요구사항 도출, 공급, 운영 등
      • 엔지니어링 프로세스 ; 요구분석, 설계 및 구현, 통합 및 시험 등.
      • 지원 프로세스 ; 문서화, 형상관리, 품질보증, 검증, 확인, 검토 등.
      • 관리 프로세스 ; 프로젝트관리, 품질관리, 위험관리 등.
      • 조직 프로세스 ; 프로세스 정의, 심사, 개선, 인적자원 관리, 기반구조, 측정, 재사용 등
  • CMMi
    • CMM + SPICE
    • 성숙도 단계
      • 실행되지 않음 not performed 0단계
      • 실행됨 performed 1단계
      • 관리됨 managed 2단계
      • 정의됨 defined 3단계
      • 정량적으로 관리됨 quantitatively managed 4단계
      • 최적화됨 optimizing 5단계
    Level Focus Process Areas
    Performed    
    Managed Basic
    Project
    Management    		 Requirements management
    Project planning
    Project monitoring and control
    Supplier agreement management
    Measurement and analysis
    Process and product quality assurance
    Configuration management
    Defined Process
    standardization    		 Requirements development
    Technical solution
    Product integration
    Verification
    Validation
    Organizational process focus
    Organizational process definition
    Organizational training
    Integrated project management
    Integrated supplier management
    Risk management
    Decision analysis and resolution
    Organizational environment for integration
    Integrated teaming
    Quantitatively managed Quantitative
    management    		 Organizational process Performance
    Quantitative project management
    Optimizing Continuous
    process
    improvement    		 Organizational innovation and deployment
    Causal analysis and resolution

to the Top

5. 소프트웨어 품질 관리

  • 검토(Review) ; 검토 중인 sw가 요구사항과 일치하는지를 검토.
    • 워크스루 Workthrough
      • 전문가들에 의해 개발자의 작업이 비공식적으로 검토.
    • 검열(Inspection)
      • 공식적인 검토회의
      • 인스펙션 체크 리스트
        • 데이터 결함
        • 제어 결함
        • 입/출력 결함
        • 인터페이스 결함
        • 기억장소 관리 결함
        • 예외 관리 결함

to the Top

6. 소프트웨어 매트릭스 & 신뢰성

  • 프로그램 구조의 복잡도 측정은 McCabe의 순환적 복잡도를 이용한다.

  • McCabe 맥카베의 sw복잡도
    • 순환복잡도 = 의사결정수 + 조건수 + 1 = 복잡도 = 영역수(흐름그래프 상에서 내부공간의 수와 외부공간1을 더함.)
    • V(G) = 흐름그래프에서의 영역의 수 = P(분기 노드 수) + 1 = Edge - Node + 2
  • 신뢰성 ; 기능의 계속적인 수행
    • 평균 가동 시간 Mean Time To Failure
      • MTTF = (f1 + … + fn) / n
    • 평균 수리 시간 Mean Time To Repair
      • MTTR = (r1 + .. + rn) / n
    • 평균 고장 간격 MTBF Mean Time Between Failure
      • MTBF = MTTF + MTTR
    • 신뢰성
      • 신뢰성=가용성 = [ MTTF / ( MTTF + MTTR ) ] * 100%

to the Top

PART 04 소프트웨어 형상관리

1. 형상관리의 개념

  • SCM Software Configuration Management 소프트웨어 형상관리

  • 기준선 Baseline 기선 통제점 ; 공식적으로 검토 및 동의되었고 추후 개발의 기초가 되며 오직 공식적인 변경 통제 절차에 의해서만 변경될 수 있는 형상항목

      Milestone 이정표 Baseline 기선
    작성시점 일정계획 형상관리
    작성기준 시간 산출물(결과물)

  • 형상관리의 기능(활동)

    • 형상 식별
      • 소프트웨어 형상 항목들을 관리하고 제어하기 위해서 각 항목들은 객체지향 방법으로 각기 이름이 붙여지고 조직되어 진다.
      • 형상관리 대상인 SCI(형상 항목 Software Configuration Item)들은 tree구조(계층구조)로 구분하고 관리 목록 번호 부여.
      • 조직 구조 명료. 수정 용이. 변경 발생 시 추적 용이
    • 버전 제어
      • sw 프로세스가 진행되는 동안 생성되는 형상객체들의 다른 비전들을 관리하기 위해 절차와 툴들을 결합
      • 프로시저와 도구 결합
    • 형상 제어
      • SCI의 변경요구를 검토 승인. 현재의 베이스라인(기준선)에 적절히 반영할 수 있도록 통제.
      • 형상통제 위원회(Configuration Control Board)의 구성이 필요. CCB는 변경 요청자와 작업 수행자로 구성.
      • CCB는 각 베이스 라인의 승인 및 변경 승인 여부를 결정.
    • 형상 감사
      • 수정된 SCI나 기준선이 미리 정해진 요구사항과 일치하는지를 검사.
      • 소프트웨어 베이스라인의 무결성을 평가하여 공식적으로 승인.
      • 검증(Verification) 및 확인(Validation)
        • 검증(Verification) ; 개발자 입장. 명세서 대상
        • 확인(Validation) ; 사용자 입장. 요구기능 대상
    • 형상 상태 보고
      • 소프트웨어 형상 및 변경관리의 식별 통제 감사 기능의 수행 결과를 기록하고 데이터베이스에 의한 관리를 하며 보고서를 작성.

to the Top

2. 형상관리를 지원하는 도구

to the Top

PART 05 소프트웨어 요구사항 분석

1. 요구사항 분석의 개념

  • sw 시스템의 3가지 관점
    • 기능 관점(모델) ; 자료흐름도(DFD), Use case Diagram
    • 동적 관점(모델) ; 상태전이도(STD ; State Transition Diagram), 사건 추적도(Event Trace Diagram)
    • 정보(객체) 관점(모델) ; ER 모델(ERD), Class Diagram(ERD를 UML)

  • CRC(Class Responsibility Collaboration) 카드

    • 객체지향 분석 단계에서 클래스 모델링을 위해 사용.

    • 클래스의 연산과 속성을 파악하는 데 이용되는 도구

    • 협력 클래스를 파악하는 데 이용하는 도구

    • 카드의 상단에 클래스 이름, 왼쪽 열에 클래스 책임, 오른쪽 열에 협력자를 나열한다.

구분 구조적 방법론 정보공학 방법론 객체지향 방법론
= 프로세스 중심 방법론
= 자료흐름방법론
= 절차식 방법론		 자료중심 방법론  
중점 Process 중심 Data 중심 객체 중심
생명주기 Top-down Top-down Bottom-up

to the Top

2. 구조적 분석 기법

  • DFD 자료 흐름도

    • 자료가 변화되는 과정을 도형화.
    • 구성요소
      • 외부 입출력(개체) ; 정보의 생산자와 소비자, 입출력이름
      • 처리과정(process) ; 변환과정
      • 자료 흐름 ; 외부 입출력과 처리과정 or 처리과정과 처리과정 연결
      • 자료 저장소 ; 자료 보관소
      • 사물의 흐름

  • 자료사전 Data Dictionary

    표기내역 항목의 정의
    (자료명과 내용의 연결)    		 순차
    (데이터의 연결)    		 선택 반복 선택사양
    (생략가능)    		 설명문
    (주석문)
    표기법 = + [ | ] { }n ( ) * *

  • 기능 명세서(소단위 명세서, Mini spec)

    • DFD자료흐름도, DD자료사전에 의해 정보 영역이 표현되면 DFD의 각 절차 버빌이 수행할 기능을 작성
    • DFD 최하위 버블 각각에 대하여 하나의 미니명세서가 작성

to the Top

3. 자료구조 지향 분석 기법

  • 정보 공학

to the Top

4. 요구 사항의 명세화

  • 명세화는 구현과 독립.
  • 일관성 ; 요구 사항들이 모순되지 않게 정의
  • 명확성 ; 명확하게 명세서를 기술. 모호하지 않게.

to the Top

PART 06 소프트웨어 설계

1. 설계의 개념

  • 설계의 유형 ; 기술적 시각

    추상화 Lv 높음       추상화 Lv 낮음
    데이터 설계 구조 설계 인터페이스 설계 컴포넌트 수준 설계 배치 수준 설계

  • 소프트웨어 아키텍처의 분류

    • 계층형 아키텍처
      • 예시 ; 네트워크의 OSI 7계층, 운영체제
    • 클라이언트/서버 아키텍처
      • 각 서비스가 단일 장애점이므로 서비스 거부 공격(DoS)에 민감.
      • 예 ; 웹 기반의 수강 신청 시스템.
    • 트랙잭션 처리 아키텍처
      • 입력을 하나씩 읽어 처리하는 방법.
      • 디스패처(dispatcher, 분배기) 필요 - 트랜잭션을 어디서 처리하는지를 결정.
      • 트랜잭션 처리 시스템은 서버에 탑재. 데이터베이스 엔진.
    • 저장소 구조
    • 모델/뷰/제어(MVC) 아키텍처 - 모바일 앱 개발시 주로 사용.
      • 모델 ; 데이터, 도메인을 저장보관
      • 뷰 ; 사용자에게 보여줌
      • 제어 ; 사용자와의 상호작용을 관리
    • 이벤트 중심 아키텍처 = 상태 전이 이벤트 중심.
      • 예 : 마이크로웨이브 오븐 제어 소프트웨어
    • 파이프 필터 아키텍처
      • 예 ; Unix 쉘. $ who sort pr
      • 서브시스템이 입력데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.
      • 모든 필터가 순차처리 형식으로 작동.

to the Top

2. 설계의 원리

  • 추상화 Abstraction

    • 종류
      • 자료 추상화
        • 기본적 추상화 ; 변수는 선언에 의해.. int x, float y;
        • 구조적 추상화 ; 배열과 레코드. type rarray = array[1…10] of real;
        • 단위 추상화 ; Modula-2의 module, Ada의 package, Java의 class
      • 기능 추상화
      • 제어 추상화
        • 기본적 추상화 ; 배정문. x:=x+y
        • 구조적 추상화 ; C와 Java의 for문, Pascal의 repeat, while 문, Modula-2와 Ada의 loop-exit
        • 단위 추상화 ; 관련 프로그램을 모아서 하나의 프로그램 단위로 만들어 컴파일하여 다른 프로그램에서도 사용가능

  • 정보은닉 Information Hiding

    • 각 모듈은 자세한 처리 내용이 시스템의 다른 부분으로부터 감추어져 있어 모듈 구현 시 다른 모듈에 영향을 받지 않고 설계.

  • 구조화

    • 소프트웨어 전체 구조와 그 구조가 시스템에 개념적인 무결성을 제공하는 방법.
    • 프로그램 구조는 모듈의 계층적 구성, 제어계층구조 암시, 구조도에 의해 표현.
      • 깊이 Depth ; 제어 수준의 개수
      • 너비 Width ; 제어의 전체적인 폭
      • 제어도 Fan-out ; 한 모듈이 호출하는 하위 모듈의 수
      • 공유도 Fan-in ; 한 모듈을 호출하는 상위 모듈의 수

  • 단계적 정제

  • 모듈화

    • 소프트웨어를 기능단위로 분해한 것. subsystem, subroutine, 소프트웨어내의 프로그램 혹은 work unit(작업 단위) 등
    • 모듈의 규모는 작아야 좋다. 모듈의 크기가 작으면 읽기 쉽고, 구현하기 쉬우며 시험에 부담이 적어진다. 그러나 실행시간이 빨라지는 것은 아니다.
    • 모듈의 개수가 증가하면 전체 개발비용이 감소하지만, 인터페이스에 대한 비용이 증가하므로 실행속도는 감소한다.

  • 응집도 ; 한 모듈 내에 있는 구성요소들의 기능적 관련성

우연적, 동시적 논리적 시간적, 임시적 절차적 정보적, 교환적, 통신적 순차적 기능적, 함수적
약함 < < < < < 강함
안좋음 < < < < < 좋음
한 모듈 내 존재 논리적으로 유사.   특정 순서 동일 입력 출력을 사용해 다른 기능 수행 한 출력이 다른 원소의 입력 단일 기능 수행
  • 결합도 ; 모듈간의 상호 의존도
자료 스탬프 제어 외부 공통 내용
약 < < < < 강
좋음 > > > > 안좋음
매개변수, call by value 배열, 구조체   외부변수 extern 전역변수, call by reference 종속.

to the Top

3. 설계 표기법

  • 구조도
    • FAN IN ; 공유도 ; 특정 모듈을 직접 제어하는 모듈의 개수
    • FAN OUT ; 제어도 ; 한 모듈에 의해 직접 제어되는 모듈의 개수
  • HIPO Hierarchy plus Input Process Output
    • 프로그램을 기능중심으로 문서화하는 하향식 설계기법
  • N-S(Nassi-Shneiderman) chart
    • 논리의 기술에 중점을 둔 도형식 표현 방법.
  • PDL Program Design Language
    • ; 의사코드

to the Top

4. 사용자 인터페이스 설계

  • GUI ; 사용자가 아이콘 및 텍스트로 이루어진 객체를 직접 조작.
  • CUI ; 자판을 통해 명령어를 입력하여 시스템을 조작.

to the Top

PART 07 객체지향 패러다임

1. 객체지향의 개념

  • 구조적 분석 기법(하향식) vs 객체지향 분석 기법(상향식)
    • 구조적 분석 기법 = 하향식 = 개발하려고 하는 시스템의 기능을 파악.
    • 객체지향 분석 기법 = 상향식 = 데이터에서 출발하여 데이터에 연관된 기능을 파악 ; 상속Inheriance

  • 객체지향의 개념

    • 객체 ; 데이터와 수행되는 함수들을 가진 작은 소프트웨어 모듈

    • 속성 ; 객체들이 가지고 있는 데이터 값을 단위별로 정의한 것.

    • 메서드(Method) ; 객체가 어떻게 동작하는지를 규정하고 속성의 값을 변경.

    • 클래스 ; 객체의 타입(Object Type)을 말하며, 객체들이 갖는 속성과 적용연산을 정의하는 템플릿

    • 가상 혹은 추상 클래스(Abstract Class)

      • 서브 클래스들의 공통 특성을 하나의 슈퍼 클래스로 추출하기 위한 목적으로 생성된 클래스.
      • 재사용 부품을 이용하여 확장할 수 있는 개념
      • 일반 클래스와 달리 생성할 목적을 가지고 있지 않으며 생성할 수도 없다.

    • 인터페이스 ; 함수들의 시그니처만 명세하고, 함수의 구현은 전혀 존재하지 않는다.

    • 다형성 ; 한 함수가 여러 클래스들에 정의되어 있는 현상

      • 다중성 = 다양성
      • 동일한 메시지가 다른 객체에 보내지더라도 수신 객체는 자기 자신의 고유한 방법만으로 행동
      • 같은 이름의 메서드를 다른 클래스에서 호출 가능 = 동적바인딩(dynamic binding)에 의해 이루어짐

    • 상속성 ; 기존 클래스들의 속성과 오퍼레이션을 상속.

    • 오버로딩 vs 오버라이딩

        오버로딩 overloading 오버라이딩 overriding
      설명 중복정의 재정의
      비고 변수 타입 또는 개수가 다름 같음

    • 캡슐화 ; 정보은닉 Information Hiding

    • 객체지향 프로그래밍의 장단점

      • 장점 ; 재사용성, 선언형 명세 설계, 신뢰성, 유지보수 용이성, 신속한 설계, 설계 독립성, 프로그래밍 개발 용이성, 대량의 분산처리 지원
      • 단점 ; 정형화된 분석 및 설계 방법이 없다. 실행 시 처리(interface) 시간 지연. (다형성, 상속, 오버로딩, 다중 상속) 등은 유지보수 어려움.

to the Top

2. 객체지향 개발 단계

  • UML 시스템 모델 3가지
    • 기능적 모델 ; 사용 사례 다이어그램
    • 정적 모델 ; 클래스 다이어그램, 객체 다이어그램, 컴포지트 다이어그램, 컴포넌트 다이어그램, 패키지 다이어그램, 배치 다이어그램
    • 동적 모델 ; 인터랙션 다이어그램, 상태 다이어그램, 액티비티 다이어그램
  • 객체지향 분석 기법
    • 럼바우 Rumbaugh의 OMT(Object Modeling Technique) 기법
      • 객체 모델링 ; ERD
      • 동적 모델링 ; STD(State Transition Diagram)
      • 기능 모델링 ; DFD

  • 객체지향 설계의 원리

    • SOLID
    • SRP Single Responsibility Principle 단일 책임의 원리
      • 하나의 클래스는 하나의 책임만. 세분화
    • OCP Open-Closed Principle 개방-폐쇄의 원리
      • 확장에 열림, 변경에 닫힘
      • OPEN : 수직관계 Is-a 에는 열림
      • CLOSE : 수평관계 has-a에는 유연, 즉 영향을 받지 않아야 한다
    • LSP Liskov Substitution Principle 리스코프 치환의 원리
      • 자식 타입들은 부모 타입들이 사용되는 곳에 대체.
      • 즉, 부모 클래스가 사용되는 곳에 자식 클래스로 치환하더라도 문제가 없어야 한다.
      • 상위 클래스는 파생 클래스로 대체 가능해야 한다.
    • ISP Interface Segregation Principle 인터페이스 분리의 원리
      • 서로 다른 성격의 인터페이스는 명백히 분리. 하나x, 다수의 인터페이스
    • DIP Dependency Inversion Principle 의존 관계 역전의 원리
      • 추상클래스는 파생클래스를 참조해서는 안되며, 파생클래스나 추상클래스는 오직 추상클래스만을 참조.
      • 상속성과 관계
      • 추상 = 부모, 파생 = 자식
    • REP Reuse/Release Equivalency Principle 재사용 동등성 배포의 원리
      • 재사용 클래스를 그룹으로 묶어 새로운 버전이 나오면 관리하고 제어할 수 있는 패키지로 만들 것을 권장
    • CCP Common Closure Principle 공통 폐쇄의 원리
      • 동일한 유형의 변경에 대해서 닫혀있어야 한다.
      • 클래스가 변경되어야 한다면 패키지 내의 모든 클래서들은 마찬가지로 변경 => observer pattern
    • CRP Common Reuse Principle 공통 재사용의 원리
      • 같이 사용되는 클래스만이 패키지 안에 포함.

  • 클래스의 설계

    • 프레임워크 framework 정의

      • 재사용 가능한 아키텍처와 협력하는 소프트웨어 산출물(클래스 ,객체, 컴포넌트)의 통합된 집합
      • 구현 언어에 종속적
      • 디자인 패턴 = 설계 스타일

    • 프레임워크 위치에 따른 분류

      • 인프라 구조 ; 개발 프로세스를 간소화
      • 미들웨어 ; 분산된 응용 시스템과 컴포넌트를 통합 ; .NET, EJB
      • 엔터프라이즈 ; 도메인이 특유한 응용 ; 통신, 항공기, 제조, 금융 등
  • 객체지향 구현
    • 재사용성, 확장용이성, 신뢰성, 모듈화된 프로그램 개발이 용이
    • 객체지향 프로그래밍 언어의 종류
      • 객체 기반 언어 ; 객체 지원 Ada, Actor, java script
      • 클래스 기반 언어 ; 객체와 클래스 지원 Clu
      • 객체 지향 언어 ; 객체, 클래스, 상속성 개념 지원 ; Simula, Smalltalk, C++, Object C, java, visual basic, Ada95, CLOS, Python

to the Top

###

PART 08 UML & Design Pattern

1. UML의 개념

  • UML Unified Modeling Language

    • 객체지향 분석, 설계 시에 사용

    • 모델링 언어 Diagram

  • UML의 4+1뷰(view)

    • 사용 사례 뷰 ; 사용자 관점
    • 논리적 뷰 ; 설계자 관점
    • 구현 뷰 ; 개발자 관점
    • 프로세스 뷰 ; 시스템 통합자 관점
    • 배치 뷰 ; 시스템 엔지니어 관점
모델의 종류 다이어 그램 분석 설계 구현
기능모델 사용 사례 O    
정적 모델 객체 O O  
  클래스 O O O
  컴포넌트   O O
  배치     O
동적 모델 인터랙션 O O  
  액티비티 O O  
  상태 O O  

  • Relationships(관계)

    종류 설명
    Dependency 의존 한쪽의 변화가 다른 쪽에 영향을 줄 수 있다. 화살표 시작점을 위해서 화살표 향한 쪽을 행함. 주문 –> 상품. 점선 속이 찬 화살표
    Association 연관 참조 관계. 연관이 있음을 나타냄. 실선
    Generalization 일반화 두 클래스가 일반화-특수화 관계. 상속을 표현. 화살표 시작점이 화살표 도착점의 특성을 상속. 토끼 –> 동물. 실선 빈 화살표
    Realization 실체화 구체화. Use case - Collaboration, Interface - class. 점선 빈 화살표. 건물 –> 청사진

uml_relationships

to the Top

2. UML의 다이어그램

  • 졸라맨
  • 사용사례(use case)와 액터(actor)로 구성.
  • 액터는 시스템 범위 밖, 사용 사례는 시스템 안.
  • 사용사례 ; actor의 요청에 수행되는 시스템의 기능. 시나리오의 집합
  • 사용사례 ; 시스템의 기능을 나타내는 모든 가능한 시나리오를 추상화
  • 시나리오 ; 실제 일어나는 일들을 기술한 사용 사례의 인스턴스

uml_diagram

  • 관계
    • 포함 Inclusion « include »
      • 의존 관계를 이용. 점선 화살표위 « include »
    • 확장 Extension « extend »
      • 기존 use case에 추가 또는 확장. 점선 화살표위 « extend »

  • 클래스 다이어그램 ; 시스템의 구조를 나타낼 때 사용. 객체, 클래스, 속성, 오퍼레이션 및 연관관계를 이용하여 시스템이 갖는 정적인 정보들의 관계를 설명.

    • 집합(Aggregation)

      • 구성요소(부분)이 없어도 전체 개념이 존재할 수 있다.
      • 구성요소는 하나 이상의 집합들에 소속될 수 있다.
      • ◇
      • uml_aggregation

    • 복합(Composition)

      • 구성요소가 없다면 전체 개념이 존재하지 않음
      • ◆
      • uml_composition

    • 일반화 Generalization

      • 빈 삼각형이 붙은 실선. 구체적. 수직적. Is-a

  • 순서 다이어그램 Sequence Diagram 순차도

    • 객체들 간의 메시지 교환을 시각화

    • 객체들 사이에 보내지는 메시지의 상호작용을 보여줌.

    • 순서적 = 시간적

  • 커뮤니케이션 다이어그램 = communication diagram = collaboration diagram.

    • 객체들 사이의 조직=관계을 강조
    • 객체간의 연결 관계
  • 상태 다이어그램 = State diagram = 상태도
    • 단일 객체가 갖는 여러 상태와 상태 사이의 전환을 이용하여 동작을 나타냄
    • Finite state machine 모습을 확장
    • 시작상태 ● 는 반드시 하나만 존재,
    • 종료상태 ⊙ 는 0개 이상 존재
  • 액티비티 다이어그램 = 활동 다이어그램 = 활동도 ; 오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현.
    • 병렬 액티비티.
    • 시스템을 화이트박스로 보고 수행한 기능모델.

  • 복합 구조 다이어그램 composite structure diagram

    • 아키텍처 다이어그램
    • 트리구조.
    • 내부구조를 명시적 중첩시켜 표현

  • 배치 다이어그램 (사용자 환경)

    • sw 와 hw component 사이의 물리적인 관계를 파악하기 위한 diagram
  • 객체 다이어그램 : 클래스 다이어그램에서 생성된 객체를 나타내며 실행되는 동안의 객체들의 관계를 나타냄
  • 패키지 다이어그램 : 관련된 클래스를 패키지로 그루핑하여 의존도를 낮추기 위하여 사용
  • 커뮤니케이션(communication) 다이어그램 : 순차 다이어그램과 같은 내용을 나타내지만 위임(delegation)과 전달의 관계를 네트워크 형태로 더 명확히 보여준다 (Collaboration 다이어그램이라고도 함)
  • 컴포지트 구조 다이어그램 : 연결된 컴포넌트의 구조를 표현한다. 컴포넌트 요이의 커넥션(포트)을 나타낸다
  • 인터랙션 오버뷰 다이어그램 : 메시지 교환과 제어흐름을 동시에 표시
  • 타이밍 다이어그램 : 시간 제약이 중요한 실시간 시스템의 설계에 사용한다. 시간 흐름에 따른 구성요소의 상태 변화, 상호 작용을 표현
  • 컴포넌트 다이어그램 : S/W부품으로 원시코드, 런 타임, 라이브러리，실행 파일 등의 구성을 나타냄

  • 배치 다이어그램 : 노드, 컴포넌트, 커넥터 등 시스템의 물리적 자원 배치를 나타냄

  • 정리
    • 표

to the Top

3. Design Pattern

  • 디자인 패턴

    • 프레임워크보다 추상적. 사용자 언어에 가까움.

    • 장 ; 사용자의 기능추가 및 유지보수성 용이. 원활한 의사소통, 구조파악 용이, 재사용을 통한 개발시간 단축

    • 단 ; C는 도움x 객체지향 설계/구현에 많이 사용

          목적에 의한 분류  
        생성적 구조적 행위적
      클래스 팩토리 메소드 어뎁터(클래스) 인터프리터
      탬플릿 메소드
      객체 추상 팩토리
      싱글톤
      프로토타입
      빌더      		 어뎁터(객체)
      브리지
      컴포지트
      데코레이터
      퍼싸드
      플라이웨이트
      프록시      		 커맨드, 반복자
      중재자, 메멘토
      옵저버
      상태
      전략
      비지터
      책임 체인
  • 생성적 패턴
  • 구조적 패턴

  • 행위적 패턴

  • 생성적 패턴

    종류 사용목적
    Factory Method  
    Abstract Factory  
    Singleton  
    Prototype  
    Builder  

  • 구조적 패턴

    종류 사용목적
    Adapter  
    Facade 서브시스템에 대한 통합된 인터페이스를 제공
    Bridge  
    Composite  
    Decorator  
    Flyweight  
    Proxy  
  • 행위적 패턴
종류 사용목적
Interpreter  
Template Method  
Command  
Iterator  
Mediator  
Memento  
Observer  
State  
Strategy  
Visitor  
Chain of Responsibility  

to the Top

PART 09 구현(Implementation)

1. 프로그래밍의 개념

  • 원시프로그램 -> 컴파일러 -> 목적프로그램(기계어) -> 링커(linker) -> 로드모듈(실행 가능 기계어) -> 로더(loader) -> 실행

  • 프로그래밍 언어의 종류

    • 1세대 ; 기계어 어셈블리어 저급언ㅇ
    • 2세대 ; FORTRAN, COBOL, ALGOL, BASIC
    • 3세대
      • 구조적언어 ; PASCAL, C, Ada
      • 특수어
        • 인공지능 ; LISP, PROLOG
        • 객체지향 ; C++, JAVA, Smalltalk
    • 4세대 ; 자연어. 비절차적 언어, 사용자중심언어, SQL

to the Top

2. 코딩과 주석

to the Top

PART 10 소프트웨어의 시험과 디버깅

1. 시험의 개념

  • 테스트의 원리 5단계
    • 테스트의 목표 설정(what)
    • 테스트의 방법 결정(how) ; 검사, 증명, 블랙박스 테스트, 화이트박스 테스트, 자동화 도구
    • 테스트 케이스 개발 ; 테스트 케이스란 테스트 자료나 실행 조건 등
    • 테스트의 예상 결과 작성 ; 테스트 오라클(test oracle) 작성
    • 테스트 케이스 실행 ; 시험 소프트웨어에 변경을 가하는 테스트 하니스(test harness)를 실시
      • 테스트 하니스(test harness) ; 시스템의 일부 기능만 시험하기 위하여 소프트웨어를 변경하는 것으로, 검사가 끝나면 이를 제거.
  • Verification
    • 개발자 입장에서 시험자가 시스팀이 명세서대로 만들어졌는지를 점검
  • Validation
    • 사용자의 시각에서 고객의 요구사항이 구현되었는지를 점검.
  • 디버깅(Debugging)
    • 개발자의 시각에서 노출된 오류를 고치는 활동
  • 블랙박스
    • 목적 ; 기능, 성능, 입출력
    • 단위시험 ;
    • 통합시험 ; big bang, 상향식, 하향식, 샌드위치식 시험
    • 시스템시험 ; 스트레스, 성능, 보안, 사용 용이성 시험
    • 인수시험 ; 알파 시험, 베타 시험
    • 설치시험 ; 소프트웨어 설치사항, HW구성
  • 화이트박스
    • 목적 ; 구조 시험, 복잡도 시험
    • 단위시험 ; 인터페이스 시험, 자료구조, 수행 경로, 오류처리, 경로시험
    • 통합시험 ; big bang, 상향식, 하향식, 샌드위치식 시험
    • 시스템시험 ;
    • 인수시험 ;
    • 설치시험 ;
  • 시험 방법에 의한 분류
    • 화이트박스 테스트 ; 내부(원시코드)의 논리적 구조를 시험
    • 블랙박스 테스트 ; 외부에서 기능, 성능, 입출력을 시험

to the Top

2. 시험 기법

  • 화이트박스 시험
    • 프로그램의 논리적 구조를 파악
    • 모듈 내의 모든 경로들이 적어도 한 번은 테스트 될 수 있게 한다.
    • 수행 단계
      • 테스트 케이스를 만든다.
      • 테스트 결과를 예상하여 테스트 오라클을 만든다.
      • 테스트 케이스를 수행한다.
      • 테스트 결과와 테스트 오라클을 비교한다. –> 결과의 차이가 있다면 변경한다. 이 때 변경 후 실시되는 테스트를 회귀 테스트(regression test)라 한다.
  • 화이트박스 테스트 검증 기준
    • 문장 검증 기준, statement coverage, 노드/문장 커버리지
      • 모든 문장이 적어도 한 번씩 수행
    • 분기 검증 기준, branch coverage, 간선/분기 커버리지
      • 마름모로 표시된 모든 각 분기점들의 참과 거짓을 적어도 한 번 이상 실행.
      • 분기 커버리지를 만족하면 문장 커버리지 만족
    • 경로 검증 기준, path coverage, 경로 커버리지
      • 수행 가능한 모든 경로를 검사.
    • 조건 검증 기준(condition coverage, 조건 커버리지
      • if나 while문 안에 있는 조건식을 자세히 조사
      • 조건문의 모든 조건식을 만족하는 경우와 만족하지 않는 경우를 테스트
  • 화이트박스 테스트의 종류
    • 기본 경로 시험, basic path testing, 구조 시험, 복잡도 시험
      • 동심원Node, 화살표Edge, 영역Region
      • 순환적 복잡도(Cyclematic Complexity), 논리적 복잡도
        • 흐름 그래프 G 영역의 수 = 내부영역의 갯수 + 1개의 외부 영역.
        • V(G) = P + 1 (P ; 분기 node수)
        • V(G) = E - N + 2 (E ; 간선수, N ; 노드수)
    • 루프 시험, loop testing
    • 조건 시험, condition testing
    • 데이터 흐름 시험, data flow testing
    • 그래프 행렬, graph matrix
  • 블랙박스 시험
    • 원시코드는 보지 않고 목적코드를 수행시켜 가며 결함을 발견할 수 있는 시험 방식.
    • 기능성능 위주시험, 데이터 위주시험, 입출력 위주시험
  • 블랙박스 시험의 종류
    • 그래프 기반 테스팅
    • 동등 분할, Equivalence Partiitioning, 균등 분할, 동치 분할
    • 경곗값 분석, Boundary Value Analysis
    • 원인-결과 그래프
    • 오류 예측, Error-Guessing, 데이터 확인
    • 비교 검사, comparison test
    • 직교 배열(orthogonal array) 테스팅
    • 페어와이즈 테스트, Pairwise Test, 조합 테스트
  • Stub vs Driver
    • 전체 시스템을 개발하지 않고, 일부만 개발한 상태로 기능 테스트를 하고자 할 때, 기본적인 뼈대 기능만 만들어서 단순한 기능 테스트를 할 수 있다.
      • 스터브, 스텁, stub
        • 하향식 테스트, 상위 모듈에서 하위 모듈로의 테스트를 진행.
        • 서버-클라이언트 구조에서 서버만 구현된 경우, 단순히 값만 넘겨주는(뼈대만 있는) 가상의 클라이언트를 만들어 테스트 할 수 있다.
        • 가상의 클라이언트가 스터브이다.
      • 드라이버, Driver
        • 상향식 테스트, 하위 모듈에서 상위 모듈로의 테스트를 진행
        • 서버-클라이언트 구조에서 클라이언트만 구현된 경우, 접속 인증 등의 간단한 기능만 하는(뼈대만 있는) 가상의 서버를 만들어 테스트 할 수 있다.
        • 가상의 서버가 드라이버이다.

to the Top

3. 소프트웨어 검사 전략

  • 시험 단계 : 단위 - 통합 - 시스템 - 인수(확인) - 설치
  • 단위 시험 ; 모듈 시험, 화이트박스 기법. 스텁(하위프로그램), 드라이버(상위프로그램)
    • 인터페이스시험
    • 자료구조시험
    • 수행경로시험
    • 오류처리시험
    • 경계시험
  • 통합 시험 ; 모듈사이의 인터페이스와 결함을 테스트. 주로 블랙박스 검사 기법.
    • 빅뱅통합 = 동시식 = 비점진적 = 차분 ; 모든 모듈들을 한꺼번에 조합.
    • 하향식통합
      • 주프로그램에서 모듈이 호출하는 다음 레벨의 모듈들을 점차적으로 통합.
      • 통합이 시도되지 않는 모듈들 자리에는 더미 모듈(stub)이 필요.
      • 회귀시험 ; 새로운 결함발생의 가능성에 대비하여 이미 실시했던 시험사례들의 전부 혹은 일부를 재실행.
    • 상향식통합
    • 샌드위치통합
  • 시스템 시험
    • 외부기능시험
    • 내부기능시험
    • 부피시험
    • 스트레스시험
    • 성능시험
    • 보안시험
    • 사용용이성시험
    • 기억장치시험
    • 호환성시험
    • 설치용이성시험
    • 신뢰성시험
    • 복구시험
    • 구성시험
    • 유지보수용이성 시험
  • 인수 시험(확인시험)
    • 알파시험
    • 베타시험
  • 설치 시험
    • s/w선택사양
    • 하드웨어 구성
    • 파일 분배적재
    • 타 s/w와 연결

to the Top

4. 자동 검사 도구

  • CASE

to the Top

5. 프로그램 디버깅

  • 디버깅 ; 오류의 원인을 찾아 교정.
  • 역행조사(backtracking) ; 증상이 나타난 곳에서부터 원인이 발견될 때까지 거슬러 추적하는 방법.

to the Top

PART 11 소프트웨어 유지보수

1. 유지보수의 개념

  • 작업의 목적에 따른 분류
    • 완전 유지보수 perfective
      • 새로운 기능을 추가하고 기존의 소프트웨어 기능을 개선(enhancement)
    • 적응 유지보수 adaptive
      • 새로운 운영체제, 하드웨어 환경으로 이식(porting)
    • 수정 유지보수 corrective
      • 하자의 원인을 찾아 문제를 해결하는 것으로, After service
    • 예방 유지보수 preventive
      • 기존의 소프트웨어 구조를 변형시키는 것(restructuring) - 재구조화(개조)
  • 유지보수 프로세스 모델
    • 즉시 수정 모델
      • 임시방편 유지보수 작업 모델. 가능하면 빨리 문제를 해결.
    • 반복적 개선 모델
      • 전체 생명주기 단계에 반복적으로 일어나 시스템이 계속 개선
    • 재사용 중심 모델
      • 컴포넌트의 재사용. 컴포넌트를 분류하고 변경을 가능하게 하는 프레임워크 필요.
      • 재사용 컴포넌트 저장소 필요
  • 유지보수 비용
    • 개발비용과 달리 예측하기 어렵다
    • 시스템을 오래 사용할수록 비용 증가
    • 비용 요소
      • 관리적 요소 ; 시스템 이해도, 담당자의 안정성, 소프트웨어의 수명, 하드웨어 환경의 안정성, 외적환경에 대한 종속도.
      • 기술적 요소 ; 모듈성, 프로그래밍 언어, 프로그래밍 스타일, 소프트웨어 품질, 문서
    • 예측 방법
      • 주먹구구식 방법
      • BL(Belady Lehman) 방법
        • M = P + K exp(c-d)
        • M ; 유지보수를 위한 노력(인원/월)
        • P ; 생산적 활동에 드는 비용
        • K ; 통계 값에서 구한 정수(경험적 상수)
        • c ; 설계나 문서화의 결함을 나타내는 복잡도
        • d ; 소프트웨어에 대한 지식의 정보(소프트웨어 친숙도)
      • COCOMO 방법
        • M ; ACT x DE x EAF
        • ACT(Annual Change Traffic) ; 유지보수 작업의 연평균 비율 즉, 한 해 동안 원시코드 한 줄에 가해지는 변경 횟수
        • DE(Development Effort) ; 개발노력(인원/월)
        • EAF(Effort Adjust Factor) ; 유지보수 작업을 위한 노력승수
      • SMI(Software Maturity Index, 소프으웨어 성숙 색인)
        • 유지보수 활동을 계획하는 척도(metrics)로 사용
        • 제품의 각 릴리즈에서 발생하는 변경사항에 기반하여 소프트웨어 제품의 안정성에 대한 지표를 제공
        • SMI가 1에 가까울수록 제품이 안정적
        • SMI = [MT - (Fa + Fc + Fd)] / MT
        • MT ; 현재 릴리즈에서 모듈의 수
        • Fa ; 변경된 현재 릴리즈에서 모듈의 수
        • Fc ; 추가된 현재 릴리즈에서 모듈의 수
        • Fd ; 이전 릴리즈부터 현재 릴리즈에서 삭제된 모듈의 수

to the Top

2. 소프트웨어의 진화

  • 유지보수 자동화 도구
    • 텍스트 편집기 ; 원시프로그램, 테스트 데이터, 지원문서들을 신속하고 효율적으로 수정하게 하는 도구
    • 디버깅 보조기 ; 알려진 오류의 원인을 찾아내는 것을 지원하기 위해 trap, dump, trace, assertion checking, history file을 제공
    • 색인 작성기 ; 프로시저 호출, 문장사용 그리고 자료참조에 대한 색인표
    • 링키지 에디터 ; 실행 가능한 프로그램을 만들기 위해서 컴파일 코드의 목적 모듈들을 서로 연결
    • 비교기 ; 2개의 파일의 차이점을 기록하는 것으로 유지보수 프로그래머가 버전건의 차이점을 지적. 부작용이 변경에 의해 일어나는지를 결정하게 하도록 지원
    • 복잡도 계산기
    • 형상관리 데이터베이스, 버전관리 시스템

to the Top

PART 12 소프트웨어 재공학

1. 소프트웨어의 재사용

  • 재공학
    • 역공학 ; 원시코드로부터 추상화된 정보를 얻기 위함
    • 순(정)공학 ; 새로운 요구에 맞춰 구현
    • 개조(재구축) ; 비구조적인 코드를 구조적 코드 변경하는 작업

to the Top

2. 소프트웨어 재공학

  • 재공학 re-engineering
  • 소프트웨어의 개조(재구축, 재구조) = 재구성 = 재구조 = 개조

  • 역공학 reverse engineering

  • 재공학 re-engineering
    • 소프트웨어 시스템의 개선.
    • 재공학의 목표 ; 복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 부작용의 발견, 잃어버린 정보 복구 및 제거, 고수준의 추상을 합성, 재사용이 쉬움.
    • BPR(Business Process Re-engineering)
      • 비지니스 정의 business definition
      • 프로세스 식별 process identification
      • 프로세스 평가 process evaluation
      • 프로세스 명세와 설계 process specification and design
      • 프로토타이핑 prototyping
      • 정제와 실현 refinement instantiation
  • 소프트웨어의 개조(재구축, 재구조) = 재구성 = 재구조 = 개조
    • 비구조적인 코드를 구조적인 코드로 변환
    • 리팩토링(refactoring)

      • 코드스멜을 없애고 코드의 품질을 향상

      • 기능(동작)의 변경없이 내부구조를 변경.

      • 코드 스멜(프로그램 작업을 어렵게 만드는 것)
        • 읽기 어려운 프로그램
        • 중복된 로직을 가진 프로그램
        • 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램
        • 복잡한 조건문이 포함된 프로그램

      • 리팩토링 기법

        구분 기법 설명
        메소드 정리 Extract Method 그룹으로 묶을 수 있는 코드를 별도 메소드로 추출
        메소드 정리 Repalce Temp with Query 수식을 메소드로 변경, 메소드 호출로 단순화
        객체간 기능 이동 Move Method 다른 클래스의 기능이 더 많은 메소드를 대체
        객체간 기능 이동 Extract Class 하나의 클래스에서 두 개 클래스 업무 수행 시 분리
        메소드 호출 단순화 Rename Method 메소드의 목적이 불분명한 경우 이름 변경
        메소드 호출 단순화 Remove Parameter 불필요한 파라미터를 제거
        클래스 / 메소드 일반화 Full Up Field 두 서브클래스가 동일한 필드를 가질 경우 슈퍼클래스 이전
        클래스 / 메소드 일반화 Full Up Method 동일한 역할의 메소드가 여러 서브클래스에 분산 시 슈퍼클래스로 이전
        기타 Encapsulation Field Public 필드를 Private으로 변경하고 접근자 생성
        기타 Decompose Conditional 조건 논리를 단순화하여 표현
  • 역공학 reverse engineering
    • 개발단계의 진행 방향의 역으로 거슬러 올라가 기존 코드와 데이터로부터 설계명세서나 요구 분석서를 복구
    • 고수준의 추상을 추출
    • 변경이 아니라 분석

to the Top

3. CASE의 개념

  • CASE Computer Aided Software Engineering
    • 소프트웨어 개발방식을 자동화

to the Top

PART 13 클라이언트/서버 소프트웨어공학

1.클라이언트/서버의 아키텍처

  • 클라이언트/서버 아키텍처 ; 서비스와 서버 그리고 클라이언트의 집합으로 구성되는 시스템 모델.
    • 장점 ; 적은 비용으로 지원 가능, 해당 지역에서 자료 처리 가능, 그래핑 사용자 인터페이스 GUI를 지원
    • 단점 ; 응용 논리의 너무 많은 부분이 서버로 옮겨지면, 중대형 컴퓨터와 비슷한 큰 부하. 분산시스템이 비분산 시스템보다 복잡. 보안이 어려움.
  • 시스템의 구성
    • 클라이언트-서버 시스템 4계층
      • 데이터베이스 계층 ; 데이터를 저장하고 트랜잭션 관리와 질의 서비스를 제공
      • 애플리케이션 처리 계층 ; 애플리케이션 논리의 구현과 요구된 기능을 최종 사용자에게 제공
      • 데이터 처리 계층 ; 클라이언트로부터의 전송되는 데이터를 관리. 데이터 검증, 웹 페이지 생성 등
      • 표현 계층 ; 사용자에게 정보를 표현. 모든 사용자의 상호작용을 관리.(가상 table, view - client)
    • 미들웨어(middleware)
      • 분산 환경에서 구성원들을 연결하고 구성원들 간의 차이를 극복하도록 범용으로 개발된 소프트웨어
      • 클라이언트와 서버의 연결을 쉽게 해주는 전용 애플리케이션, 클라이언트와 서버 사이에 존재하는 소프트웨어
        • 통신미들웨어 NCS
        • 데이터베이스 미들웨어 ODBC
        • 분산객체 미들웨어 COBRA, DCOM
  • 미들웨어 아키텍처
    • 분산 객체(COBRA) 미들웨어 Common ORB Architecture
      • 이기종 분산 환경에서 서로 다른 시스템 간의 상호 동작을 무리없이 제공.
      • 구성요소
        • 응용 객체에 관한 객체 모델 ; COBRA 객체는 IDL(Interface Definition Language)로 기술된 잘 정의되고 언어 중립적인 인터페이스를 가진 상태의 캡슐화
        • 객체 요청 중재자 ORB ; 서비스를 요청하는 객체를 찾고, 요청을 대비하여 준비를 하고, 서비스 요청을 보내고 요청자에게 결과를 리턴한다.
        • 객체 서비스의 집합 ; 많은 분산 응용이 요청할 가능성이 높은 일반 서비스, 디렉터리 서비스, 트랜잭션 서비스 및 지속성(persistence) 서비스
        • 공통적인 컴포넌트의 집합 ; 특정 도메인의 컴포넌트(수직)이거나 많은 응용 시스템이 이용하는 범용 컴포넌트(수평)
        • ORB의 장점 ; 서비스 제공 객체들이 네트워크의 임의의 노드(site)에서 실행 가능. 새로운 자원을 추가할 수 있는 개방된 시스템 아키텍처
    • 메시지 중심 미들웨어
      • MOM Message Oriented Middleware. 일종의 소프트웨어 버스를 생성하여 레거시 시스템과 협력사의 외부 시스템을 통합
      • 대규모 엔터프라이즈 시스템을 구축할 때 중요한 기술.
      • 느슨한 결합의 비동기 기술.
    • 애플리케이션 서버
      • N-tier 아키텍처의 중간층에 위치. 분산 통신, 보안, 트랜잭션, 영속성을 제공하는 컴포넌트 기반의 서버 기술
      • JEE Java Enterprise Edition
      • 구성요소
        • 앤터프라이즈 정보 시스템 EIS
        • 비지니스 컴포넌트 층. ; .NET, COBRA
        • 웹 층 ; JSP, ASP와 같은 웹 서버 호스트 컴포넌트를 구동.
        • 클라이언트 층
      • 분산 시스템 아키텍처의 종류
        • 마스터-슬레이브 아키텍처
        • 2단 클라이언트-서버 아키텍처
        • 다단 클라이언트 서버 아키텍처
        • 분산 컴포넌트 아키텍처
        • 피어 투 피어 아키텍처
          • Grid computing ; WAN기반 협업 가능한 system
        • 서비스 중심 시스템 아키텍처(SOA)

to the Top

PART 14 정형적 방법

1.정형적 방법의 개념

  • 정형적 방법 ; 수학적 엄격함
  • 종류

    • 대수학적 algebraic 명세

      • 대수적 데이터 인터페이스를 정의. 부울대수. A+A = A(or)

    • 모델(상태) 기반 명세

      • 집합과 수열 등 수학적 요소를 이용하여 표현. A+A = 2A

        구분 순차 언어 병렬 언어
        대수학적 명세 Larch, OBJ Lotos
        모델기반 명세 Z(Zedd), VDM, B CSP, Petri Nets
  • 문제점
    • 점진적으로 개발하는 애자일 개발과 호환되지 않는다.
    • 매우 큰 시스템까지 확장 어려움

to the Top

PART 15 최신 소프트웨어공학

1. MDA 프레임워크

  • MDA Model Driven Architecture

to the Top

2. 웹서비스와 SOA

  • 서비스 지향 아키텍처 Service Oriented Architecture
    • SOA는 소프트웨어 아키텍처에 가깝고, 웹 서비스는 이러한 아키텍처를 실현하기 위한 기술의 집합체.
    • 모델 - 조립(=조합) - 운영(=배포) - 관리
  • RPA Resource Oriented Architectur
    • Repository 없이직거래

to the Top

3. 컴포넌트 기반 소프트웨어공학

  • CBD Component Based Development
    • 컴포넌트
      • 재사용성
      • 클래스 정의는 추상 데이터 타입을 정의하고 객체는 해당 타입의 인스턴스이다. 하지만 컴포넌트는 인스턴스를 정의하는 데 사용되는 템플릿이 아닌 인스턴스이다.

to the Top

4. 관점지향 프로그래밍

to the Top

5. 보안공학

to the Top

참고