[정보처리기사 실기] 개념요약 - 01. 요구사항 확인

소프트웨어 생명주기 모델
애자일 방법론
객체지향 분석
비용산정 모형
일정 관리 모델
소프트웨어 아키텍처
디자인 패턴
분석산출물의 종류
OSI 7계층
DBMS 현행 시스템 분석 시 고려사항
요구 공학
요구사항 개발 단계
UML-관계
클래스 다이어그램
패키지 다이어그램
소프트웨어 개발 표준

 

---

 

* 소프트웨어 생명주기 모델(SDLC : Software Development Life Cycle)

• 소프트웨어 생명주기 : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것

프로세스

• 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수

모델 종류 : 폭프나반

• 폭포수 모델(Waterfall Model)
  • 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델(고전적 생명주기 모형)
  • 절차 : 타당성 검토 -> 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
• 프로토타이핑 모델(Prototyping Model)
  • 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
• 나선형 모델(Spiral Model)
  • 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
  • 절차 : 계위개고
    • 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
• 반복적 모델(Iteration)
  • 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델

 

* 애자일(Agile) 방법론

• 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론

종류

• XP(eXtreme Programming)
  • 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
  • 5가지 가치    
    * 용기 (Courage)
    * 단순성 (Simplicity)
    * 의사소통 (Communication)
    * 피드백 (Feedback)
    * 존중 (Respect)
  • 12가지 원리
    * 짝 프로그래밍 (Pair Programming)
    * 공동 코드 소유 (Collective Ownership)
    * 지속적 통합 (CI : Continuous Integration)
    * 계획 세우기 (Planning Process)
    * 작은 릴리즈 (Small Release)
    * 메타포어 (Metaphor)
    * 간단한 다지안 (Simple Design)
    * 테스트 기반 개발 (TDD : Test Driven Develop)
    * 리팩토링 (Refactoring)
    * 40시간 작업 (40-Hour Work)
    * 고객 상주 (On Site Customer)
    * 코드 표준 (Coding Standard)
• 스크럼(SCRUM)
  • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
  • 주요 개념
    * 백로그 (Backlog) : 제품과 프로젝트에 대한 요구사항
    * 스프린트 (Sprint) : 2~4주의 짧은 개발 기간의 반복적 수행으로 개발품질 향상
    * 스크럼 미팅 (Scrum Meeting) : 매일 15분 정도 미팅으로 To-Do List 계획 수립 (= 데일리 미팅 (Daily Meeting))
    * 스크럼 마스터 (Scrum Master) : 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
    * 스프린트 회고 (Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
    * 번 다운 차트 (Burn Down Chart) : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
• 린(LEAN)
  • 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제고하여 품질을 향상시킨 방법론
  • JIT(Just In Time), 칸반(Kanban) 보드 사용
  • 7가지 원칙
    * 낭비 제거
    * 품질 내재화
    * 지식 창출
    * 늦은 확정
    * 빠른 인도
    * 사람 존중
    * 전체 최적화

 

* 객체 지향 분석(OOA: Object Oriented Analysis)

• 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법

방법론 종류

• OOSE(Object Oriented Software Engineering)
  • 야콥슨(Jacobson)
  • 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론
• OMT(Object Modeling Technology)
  • 럼바우(Rumbaugh)
  • 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
  • 분석 절차 : 객동기
    • 객체 모델링(Object Modeling)
      • 정보 모델링(Information Modeling)
      • 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
      • 객체 다이어그램 활용
    • 동적 모델링(Dynamin Modeling)
      • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현
      • 상태 다이어그램 활용
    • 기능 모델링(Functional Modeling)
      • 프로세스의 자료 흐름을 중심으로 처리 과정 표현
      • 자료 흐름도(DFD) 활용
• OOD(Object Oriented Design)
  • 부치(Booch)
  • 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론

 

* 비용 산정 모형

• 소프트웨어 규모 파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식

분류

• 하향식 산정 방법
  • 전문가 판단
  • 델파이 기법
• 상향식 산정 방법
  • 코드 라인 수(Loc: Lines of Code)
    • 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식
  • Man Month
    • 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식
  • COCOMO 모형(COnstructuve COst MOdel)
    • 보헴(Bohem)이 제안한 모형으로, 프로그램 규모에 따라 비용을 산정하는 방식
    • 비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정한다
    • 소프트웨어 개발 모형
      • 조직형(Organic Mode)
        • 5만(50KDSI) 라인 이하
        • 기관 내부에서 개발된 중소규모의 소프트웨어
        • 일괄 자료 처리 / 과학 기술 계산용 / 비즈니스 자료 처리 개발
      • 반 분리형(Semi-Detached Mode)
        • 30만(30KDSI) 라인 이하
        • 단순형과 임베디드형의 중간형
        • 트랜잭션 처리 시스템 / 데이터베이스 관리 시스템 / 컴파일러 / 인터프리터
      • 임베디드형(Embedded Mode)
        • 30만(30KDSI) 라인 이상
        • 초대형 규모의 트랜잭션 처리 시스템 / 운영체제 / 실시간 처리 시스템 등의 시스템 프로그램 개발
  • 푸트남(Putnam) 모형
    • 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
    • 생명주기 예측 모형이라고 한다
    • Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다
  • 기능점수(FP : Function Point) 모형
    • 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별로 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식

 

* 일정 관리 모델

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

종류

• 주 공정법(CPM : Critical Path Method)
  • 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 방법
  • 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로를 계산한다
• PERT(Program Evaluation and Review Technique)
  • 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로, 비관치 / 중간치 / 낙관치의 3점 추점방식을 통해 일정을 관리하는 기법
• 중요 연쇄 프로젝트 관리(CCPM : Critical Chain Project Management)
  • 주 공정 연쇄법으로 자원 제약 사항을 고려하여 일정을 작성하는 기법

 

* 소프트웨어 아키텍처

4+1뷰

• 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방식
• 체크 방법으로 유스케이스를 사용한다
  • 유스케이스(Usecase) : 시스템이 액터에게 제공해야 하는 기능으로서 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능
• 1(유스케이스 뷰) + 4(논리 뷰, 프로세스 뷰, 구현 뷰, 배포 뷰)
• 구성 요소 : 유논프구배
  • 유스케이스 뷰(Usecase View)
    • 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
    • 사용자 / 설계자 / 개발자 / 테스트 관점
  • 논리 뷰(Logical View)
    • 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
    • 설계자 / 개발자 관점
  • 프로세스 뷰(Process View)
    • 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
    • 개발자 / 시스템 통합자 관점
  • 구현 뷰(Implementation View)
    • 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
    • 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
  • 배포 뷰(Deployment View)
    • 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

비용 평가 모델

• 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
• 종류 : SACAA(사카)
  • SAAM(Software Architecture Analysis Method) : 변경 용이성과 기능성에 집중, 평가가 용이하며 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
  • ATAM(Architecture Trade-off Analysis Method) : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
  • CBAM(Cost Benefit Analysis Method) : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델
  • ADR(Active Design Review) : 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
  • ARID(Active Reviews for Intermediate Designs) : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

 

* 디자인 패턴(Design Pattern)

• 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

디자인 패턴 구성 요소 : 패문솔 사결샘

• 패턴의 이름
• 문제 및 배경
• 솔루션
• 사례
• 결과
• 샘플 코드

디자인 패턴 유형

• 목적에 따른 구분 : 생구행
  • 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
  • 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
  • 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
• 범위에 따른 구분
  • 클래스 : 클래스 간 관련성(상속 관계)을 다루는 패턴, 컴파일 타임에 정적으로 결정
  • 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정

디자인 패턴 종류

• 생성 패턴 : 생빌 프로 팩앱싱
  • Builder : 복잡한 인스턴스를 조립하여 만드는 구조
  • Prototype : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴
  • Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
  • Abstract Factory : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 페턴
  • Singleton : 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴, 한 클래스에 한 객체만 존재하도록 제한
• 구조 패턴 : 구 브데 퍼플 프록 컴 어
  • Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 패턴
  • Decorator : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
  • Facade : 복잡한 시스템에 대하여 단순한 인터페이스를 제공함으로써, 사용자와 시스템 간 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게하는 패턴
  • Flyweight : 다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스화하여 공유함으로써 메모리를 절약하고, '클래스의 경량화'를 목적으로 하는 패턴, 여러 개의 '가상 인스턴스'를 제공하여 메모리 절감
  • Proxy : '실제 객체애 대한 대리 객체'로 실제 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만들며, 이 점을 이용해서 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때 할당하게 하여 메모리 용량을 아낄 수 있으며, 실제 객체를 드러나지 않게하여 정보 은닉의 역할도 수행하는 패터
  • Composite : 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 하는 패턴
  • Adapter : 기존에 생성된 클래스를 재사용할 수 있도록 중간에 맞춰주는 역할을 하는 인터페이스를 만드는 패턴
• 행위 패턴 : 행 미인이 템옵 스테 비커 스트 메체
  • Mediator : 중간에 지시할 수 있는 역할을 하는 중재자를 두고, 중재자에게 모든 것을 요구하여 통신의 빈도수를 줄여 객체 지향의 목표를 달성하게 해주는 패턴
  • Interpreter : 언어의 다양한 해석, 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴
  • Iterator : 컬렉션의 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공하는 디자인 패턴
  • Template Method : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴으로 상위 클래스(추상 클래스)에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스(구체 클래스)의 메서드에는 세부 처리를 구체화하는 방식으로 사용하여 코드 양을 줄이고 유지 보수를 용이하게 만드는 특징을 갖는 패턴
  • Observer : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고, 자동으로 내용이 갱신되는 방법으로, 일대 다의 의존성을 가지며 상호 작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 패턴
  • State : 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여, 변경 시 원시 코드의 수정을 취소할 수 있고, 유지보수의 편의성도 갖는 패턴
  • Vistor : 각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스의 메서드가 각 클래스를 돌아 다니며 특정  작업을 수행하도록 만드는 패턴으로 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용하는 패턴
  • Command : 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 패턴
  • Strategy : 알고리즘 군을 정의하고(추상 클래스), 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴
  • Memento : 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용하는 패턴으로, Undo 기능을 개발할 때 사용하는 디자인 패턴
  • Chain of Reponsibility : 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능한데, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 패턴

 

* 분석 산출물의 종류 : 현기인 아소하네

• 정보 시스템 구성 현황
• 정보 시스템 기능 구성도
• 인터페이스 현황
• 현행 시스템 아키텍처 구성도
• 소프트웨어 구성도
• 하드웨어 구성도
• 네트워크 구성도

 

* OSI 7계층  : 물데네 전세표응

• 물리 계층(Physical Layer)
  • 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
  • 프로토콜 : RS-232C
  • 전송 단위 : 비트(Bit)
• 데이터 링크 계층(Data Link Layer)
  • 인접 시스템 간 데이터 전송, 전송 오류 제어
  • 동기화, 흐름 제어 등의 전송 기능 제공
  • 오류 검출 / 재전송 등의 기능 제공
  • 프로토콜 : 이더넷
  • 전송 단위 : 프레임(Frame)
• 네트워크 계층(Network Layer)
  • 단말 간 데이터 전송을 위한 최적화된 경로 제공
  • 프로토콜 : IP, ICMP
  • 전송 단위 : 패킷(Packet)
• 전송 계층(Transport Layer)
  • 신뢰성 있는 통신 보장
  • 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어 등을 담당
  • 프로토콜 : TCP, UDP
  • 전송 단위 : 세그먼트(Segment)
• 세션 계층(Session Layer)
  • 연결 접속 및 동기 제어
  • 프로토콜 : SSH, TLS
  • 전송 단위 : 데이터(Data)
• 표현 계층(Presentation Layer)
  • 데이터 형식 설정과 부호 교환, 암 / 복호화
  • 프로토콜 : JPEG, MPEG
  • 전송 단위 : 데이터(Data)
• 응용 계층(Application Layer)
  • 사용자와 네트워크 간 응용서비스 연결, 데이터 생성
  • 프로토콜 : HTTP, FTP
  • 전송 단위 : 데이터(Data)

 

* DBMS 현행 시스템 분석 시 고려 사항  : 가성호기구

• 성능 측면
  • 가용성
  • 성능
  • 상호 호환성
• 지원 측면
  • 기술 지원
  • 구축 비용

 

* 요구 공학(Requirements Engineering)

• 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

요구 공학의 분류

• 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항
• 비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항

 

* 요구사항 개발 단계

구성 : 도분명확

• 요구사항 도출(Eliciation)
• 요구사항 분석(Analysis)
• 요구사항 명세(Specification)
• 요구사항 확인 및 검증(Validation)

요구사항 도출 - 주요 기법

• 인터뷰(Interview) : 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법
• 브레인스토밍(Brainstorming) : 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의
• 델파이 기법(Delphi Method) : 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 방법
• 롤 플레잉(Role Playing) : 현실에 일어나는 장면을 설정하고, 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
• 워크숍(Workshop) : 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
• 설문 조사(Survey) : 설문지 또는 여론 조사 등을 이용해 간접적으로 정보를 수집하는 방법

요구사항 분석

• 절차
  • 요구사항 분류
  • 개념 모델링 생성 및 분석
  • 요구사항 할당
  • 요구사항 협상
  • 정형 분석
    • 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 활동
    • 구문(Syntax)와 의미(Semantics)를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
    • 요구사항 분석의 마지막 단계에서 이루어짐
• 기법
  • 자료 흐름 지향 분석
  • 객체 지향 분석
• 기술 
• * 청취 기술
  * 인터뷰와 질문 기술
  * 분석 기술
  * 중재 기술
  * 관찰 기술
  * 작성 기술
  * 조직 기술
  * 모델 작성 기술

요구사항 명세

• 주요 기법
  • 비정형 명세 기법 : 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 방법
  • 정형 명세 기법 : 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 방법
• 원리 및 검증 항목 : 명완검 일수 추개
  • 명확성
  • 완전성
  • 검증 가능성
  • 일관성
  • 수정 용이성
  • 추적 가능성
  • 개발 후 이용성

요구사항 확인 및 검증 - 주요 기법

• 요구사항 검토
• 정형 기술 검토 활용 : 동워인
  • 동료 검토(Peer Review) : 2~3명이 진행하는 리뷰의 형태로 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
  • 워크 스루(Walk Through) : 오류를 조기에 검출하는 데 목적이 있으며, 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
  • 인스펙션(Inspection) : 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
• 프로토타이핑 활용
• 모델 검증
• 테스트 케이스 및 테스트를 통한 확인 
• CASE 도구 활용 검증
• 베이스라인(Baseline)을 통한 검증
• 요구사항 추적표(RTM : Requirement Traceability Matrix)를 통한 검증

상세 정형 기술 검토 기법 : 관기 인워감

• 관리 리뷰(Management Review) : 프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰
• 기술 리뷰(Technical Review) : 정의된 계획 및 명세서를 준수하고 있는지에 대한 검토를 수행하는 리뷰
• 인스펙션(Inspection) : 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법(= 동료 검토(Peer Review))
• 워크 스루(Walk Through) : 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로, 비형식적인 검토 기법
• 감사(Audit) : 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 방법으로, 소프트웨어 제품의 제공자, 소비자, 제 3기관 등이 수행

 

* UML - 관계(Relationship)

• 사물과 사물 사이의 연관성을 표현하는 것

종류

• 연관(Association) 관계
  • 2개 이상의 사물이 서로 관련되어 있는 관계
  • 사물 사이(양방향 관계) - 실선 / 방향성 - 화살표
  • 연관에 참여하는 객체의 개수(다중도)를 선 위에 표기
• 집합(Aggregation) 관계
  • 하나의 사물이 다른 사물에 포함되어 있는 관계
  • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적이다
  • 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현한다
• 포함(Composition) 관계
  • 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
  • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께한다
  • 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현한다
• 일반화(Generalization) 관계
  • 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
  • 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다
  • 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다
• 의존(Dependency) 관계
  • 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
  • 하나의 사물과 다른 사물이 소유 관계는 아니지만, 사물의 변화가 다른 사물에도 영향을 미치는 관계
  • 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다
• 실체화(Realization) 관계 
  • 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계
  • 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다

 

* 클래스(Class) 다이어그램

정적 모델링

• 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것
• 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점(View)에서 표현한다
• 정적 모델링은 객체(Object)들을 클래스(Class)로 추상화하여 표현한다
• UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다

클래스(Class) 다이어그램

• 클래스와 클래스가 자신을 가지는 속성, 클래스 사이의 관계를 표현한 것
• 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램
• 시스템 구성 요소를 문서화하는 데 사용된다

구성 요소

• 클래스(Class)
  • 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한 것
  • 구성요소
    • 클래스의 이름
    • 속성(Attribute) : 클래스의 상태나 정보를 표현함
    • 오퍼레이션(Operation) : 클래스가 수행할 수 있는 동작으로, 함수(메소드, Method)라고도 함
• 제약조건
  • 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
  • 클래스 안에 제약조건을 기술할 때는 중괄호({})를 이용함
• 관계(Relationships)
  • 관계는 클래스와 클래스 사이의 연관성을 표현함
  • 클래스 다이어그램에 표현하는 관계에는 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계가 있음

연관 클래스

• 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
• 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점섬을 연관 클래스로 이어 표시한다
• 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정한다

 

* 패키지(Package) 다이어그램

• 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
• 패키지는 또 다른 패키지의 요소가 될 수 있다
• 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다

구성 요소

• 패키지(Package)
  • 객체들을 그룹화한 것
  • 단순 표기법 : 패키지 안에 패키지 이름만 표현
  • 확장 표기법 : 패키지 안에 요소까지 표현
• 객체(Object)
  • 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
• 의존 관계(Dependency)
  • 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현함
  • 스테레오타입을 이용해 의존 관계를 구체적으로 표현할 수 있음
  • 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import와 access가 사용됨
  • import : 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
  • access : 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계

 

* 소프트웨어 개발 표준

• 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준

ISO/IEC 12207

• ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
• 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공한다
• 구분
  • 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영, 유지보수 프로세스
  • 지원 생명 주기 프로세스 : 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스
  • 조직 생명 주기 프로세스 : 관리, 기반 구조, 훈련, 개선 프로세스

CMMI(Capability Maturity Model Integration)

• 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
• 미국 카네기멜론 대학교의 소프트웨어 공학연구소(SEI)에서 개발하였다

SPICE(Software Process Improvement and Capability dEtermination)

• 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
• 공식 명칭은 ISO/IEC 15504이다

구성

• 고객-공급자(Customer-Supplier) 프로세스
  • 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성됨
  • 구성요소 : 인수, 공급, 요구 도출, 운영
  • 프로세스 수 : 10개
• 공학(Engineering) 프로세스
  • 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 사용되는 프로세스로 구성됨
  • 구성요소 : 개발, 소프트웨어 유지보수
  • 프로세스 수 : 9개
• 지원(Support) 프로세스
  • 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성됨
  • 구성 요소 : 문서화, 형상, 품질 보증, 검증, 확인, 리뷰, 감사, 품질 문제 해결
  • 프로세스 수 : 8개
• 관리(Management) 프로세스
  • 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성됨
  • 구성 요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
  • 프로세스 수 : 4개
• 조직(Organiztion) 프로세스
  • 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성됨
  • 구성 요소 : 조직 배치, 개선 활동 프로세스, 인력 관리, 기반 관리, 측정 도구, 재사용
  • 프로세스 수 : 9개

프로세스 수행 능력 단계

• 불완전(Incomplete) : 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
• 수행(Performed) : 프로세스가 수행되고 목적이 달성된 단계
• 관리(Managed) : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
• 확립(Established) : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
• 예측(Predictable) : 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
• 최적화(Optimizing) : 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계