메타 스터디 그룹

1. 소프트웨어 형상관리의 개요
 가) 형상관리의 정의
     - 정의 : 소프트웨어 개발시점부터 유지보수 단계까지 발생되는 구성요소의 변경이력 관리
     - 필요성 : 가시성 미흡, 컨트롤 어려움, 추적성 미흡, 감시미비, 잦은 변경

 2. 형상관리 개념도 및 구성요소 
 가) 형상관리 개념도 

 나) 형상관리의 구성요소 

    -  기준선, 형상항목, 형상물, 형상정보

3. 형상관리 활동
 가) 형상관리 활동

    - 형상식별, 형상 컨트롤, 형상감사, 형상기록

 나) 형상관리의 효과

   - 소프트웨어 개발 및 관리 적용시 효과적 

 다) 형상관리 고려사항

   - 적절한 운영조직 구성, 관리 전문 도구 활용

   - 지속적 관리 및 기준, 해결방안 필요

   - 소규모 프로젝트시 형상관리 정도를 적절히 테일러링

   -  형상관리 항목 정하고 모든 변경사항 공식적인 합의에 의해 실시 

   - 운영중인 소프트웨어의 변경 신중히 진행

4. 형상관리도구
 가) 형상관리도구   

 나) 서브버전 (Subversion, SVN)

   - 정의 : 오픈소스 소프트웨어 버전관리 시스템

   - 사용 : 중앙 집중형 저장소시스템, 중앙서버로 부터 파일을 check-out 

 다) 분산형 저장소(Git)

   - 정의 :  클라이언트가 마지막 Snapshot을 직접 다운받지 안고 저장소 전부 복제, 서버 문제시 클라이언트 카피본으로 서버 복원 

 라) TFS(Team Foundation Server)

   - 정의 : 소스코드 관리, 보고,요구 사항관리, 프로젝트관리(에자일 소프트웨어 개발,, 폭포수 모델), 자동화 빌드, 랩관리, 테스트 및 출시 관리기능 제공하는 마이크로소프트의 제품

   - 목적 : 개발팀의 효과적인 협업을 위한 소스코드, 산출물, 개발활동등 소프트웨어 개발활동 모든 정보 저장

X. 소프트웨어 요구관리

핵심 키워드 : 요구사항 관리 프로세스, 요구사항 명세기법, 요구사항 변경 관리

01. 프로젝트 성공의 핵심요소, 요구사항 관리

  가. 정의

    - 정의된 요구 사항의 반영과 진행을 확인하고, 요구사항의 변경에 대한 지속적인 관리를 수행하는 활동

    * 요구사항 공학(Requirement Engineering) 구성 : 요구사항 개발(목표 설정), 요구사항 관리(목표 관리)

 나. 요구사항 관리의 중요성

    - 의사소통 수단 제공, 납기지연 및 예산초과 방지, 사용자 요구 명세 수행 및 관리

 다. 요구사항 관리의 목적

    - 고객 요구의 명확한 파악 및 만족, 고품질 소프트웨어 일정내 생산

 라. 요구사항 관리 공정  

  - 소프트웨어 개발 생명주기 전체에서 명확한 요구 사항 정의 및 지속적인 관리 활동이 중요함

  마. 요구사항 공정별 관리활동

        - 실무측면에서는 변경제어, 추적성/버전 제어가 매우 중요하며 철저한 관리 원칙 준수가 필요함

  바. 요구사항 관리 원칙

    - 요구 우선순위 부여(고객 가치기반), 이해관계자의 동의

    - 요구 시스템의 목표 식별(기대/범위 관리)

    - CCB운영 통해 변경의 영향 분석 및 Baseline 설정

02. 요구사항 명세

  가. 요구사항 명세 기법

      - 명세 방식에 따라 정형 명세, 비정형 명세로 구분 가능

  나. 명세 원칙

     - 명확성, 검증성, 추적성, 수정성, 일관성, 완전성, 정확성, 이해성, 해석성

  다. IEEE 표준 요구사항 명세서 목차

      - 공공 SW 사업의 경우 ‘요구사항 상세화 실무 가이드’ 참조 필요

03. 요구사항 변경 및 추적 관리

  가. 요구사항 변경 관리 개요

     - 정의 : 요구사항의 Baseline 기준, 모든 변경의 공식적 통제 프로세스

     - 목적 : 변경에 대한 일관성, 무결성 확보

  나. 요구사항 변경에 따른 오류 발생 원인

    - 요구 사항 추적성을 통해 오류 감소 및 예방

 다. 요구사항 변경의 추적성 관리

   - 정의 : 요구 사항 문서내의 요구사항 단위별로  추적성을 정의하고 구성하는 프로세스

   - 특징 : 수직적/수평적 추적성, 순방향/역방향 추적성

  라. 추적 관리의 효과

[참고]

    * VDM (Vienna Development Method)

      - 시스템의 기능적인 요구사항만 한정하여 요구 명세와 검증 설계에 관한 검증 방법 제공하는 정형 명세 기법

   *  수학적 기반 기술

      - 수리, 논리 기반으로 시스템을 명세하는 기법, Z notation, B method등, 수학적 기호 사용

   * FSM(Finite State Machin, 유한 상태 기계)

      - 여러 제한된 상태가 존재하며, 그 존재들이 특정 조건에 따라 상태 전이하는 개념적 모델

         . 장점 : ① 가질 수 있는 상태가 한정되며 ‘한 번에 한 가지 상태’만 보유

                      ② 내부 구조와 구현 용이

                      ③ 오류의 수정 용이, 유연성 보유

          . 단점 : 규모가 커지면 설계가 복잡, 제한된 범위의 문제에만 적용 가능

   * SADT(Structured Analysis and Design Technique, 구조적 분석 및 설계기법)

        -  시스템을 기능의 계층 구조로 설명하기 위한 시스템 엔지니어링 및 소프트웨어 엔지니어링 방법론

           . 장점 : 대규모 복잡한 문제 구조적 접근, 분할/통합 가능, 명료한 표기

IX. 소프트웨어 테스팅과 리팩토링

01. 테스팅 개념 및 프로세스

가) 테스팅 개념

①  테스팅 정의

    - 테스팅이란 어플리케이션 또는 시스템의 동작과 성능, 안정성이 사용자나 고객이 요구하는 수준을 만족하는지 확인이나 검증하기 위해 결함을 발견하는 방법

② 테스팅 원리

- 테스트를 통해 결함 예방, 비용감소 등의 긍정적인 영향도 있지만, 테스트를 한다고 해서 모든 프로그램이 완벽하다고 신뢰할 수 는 없다.

나) 테스팅 프로세스

*테스트 웨어? 테스트를 계획, 설계, 실행하는 프로세스 동안 생성된 산출물

- 테스팅은 다양한 구성요소를 포함하는 프로세스를 중심으로 조정되고 관리되어야 함

다) 테스트 설계

①  테스트 설계 개요

    - 테스트 케이스를 도출/수행하여 테스팅의 진행사항을 보장하기 위해 사용 됨

②  테스트 케이스의 구성

 - 테스트 케이스는 특정 테스트 조건을 확인하기 위해 작성됨

③ 테스트 케이스 설계 기법

  - 테스트 설계 기법은 테스트 베이시스의 참조 기준으로 기법이 분류됨

02. 테스팅 유형 및 기법

가) 테스팅 유형

①  테스트 레벨 유형

 - 각 유형 별 테스트에서 테스트 수행의 주체, 목적, 환경 등을 고려하여 테스트를 수행

②  테스트 유형

  - 테스트 레벨 별로 목적, 수행주체, 환경에 따라 테스트 케이스를 도출하기 위해 참조되는 개발 산출물을 상세하게 정의해야 함

나) 테스팅 기법

- 테스팅 기법은 화이트 박스 테스팅과 블랙박스 테스팅 기법으로 구분됨

① 화이트 박스 테스팅 기법

 - (정의)  원시코드를 보고 실행을 변경하면서 검사를 수행하는 기법

 - 화이트 박스 테스트의 검증 기준은 문장, 분기, 조건, 분기/조건 으로 분류됨

② 블랙 박스 테스팅 기법

 - (정의)  사용자의 요구사항 명세에 따라 각 기능이 정상적으로 작동되는지 입증하는 기능 테스트 기법

 - 요구사항 명세대로 소프트웨어가 동작하는지 초점을 맞춘 테스트 기법

03. 리팩토링

가) 리팩토링 개념 

① 리팩토링 개요

 - (정의) 소프트웨어의 외부적 기능은 수정하지 않고, 내부 구조, 관계 등을 단순화 하여 유지보수성을 향상시키는 품질 향상 기법

 - (목적) 유지보수성 향상, 유연한 시스템, 생산성 향상, 품질 향상

② 리팩토링 수행 절차

- 리팩토링은 소규묘 변경 후 동작 여부를 테스트 하고, 정상 동작하는 경우 다음 리팩토링 단계로 전진하는 방식으로 진행

나) 코드스멜(Code Smell) 개념

① 코드스멜의 정의

 - 읽기 어렵거나 중복된 로직을 가진 프로그램처럼 개발자가 이해하거나 유지보수하기 어려워 리팩토링의 대상이 되는 소스코드

② 코드스멜의 종류

- 코드의 복잡도 및 이해하기 쉽게하기 위한 클린 코드의 필요성 증대

*클린코드(Clean Code) ? 코드를 작성한 의도와 목적이 명확하여 다른 사람이 쉽게 읽을 수 있도록 설계자의 의도를 반영하여 단순하고 직접적으로 작성된 코드

다) 대표적인 리팩토링 기법

- 리팩토링 시 코드에 대한 과도한 수정이 필요하거나, 적합하지 않은 인터페이스에 대해서는 무리한 리팩토링은 시스템의 불안정성을 유발할 수 있음

01. 사용자 인터페이스(User InterFace) 개요

  가. 정의

    - 사용자와 시스템이 정보를 주고받는 상호 작용이 잘 이루어지도록 하는 장치 혹은 소프트웨어

  나. 설계시 고려사항

    - 일관성 필요 : 사용자 인터페이스가 일관성을 가지기 위해 표준안을 만들고, 이를 점검하여 오류를 수정

    - 사용자 중심 설계 : "입력 및 출력 언어"를 사용자가 쉽게 배울 수 있도록 설계

    - 피드백 : 사용자가 잘못 버튼을 누르거나 잘못된 연산을 수행하고자 할때 자신의 잘못을 쉽게 파악 가능

    - 파괴적인 행동에 관한 확인 : 사용자가 자료 또는 파일을 지우려고 하면 이를 실행에 옮기기 전에 확인 필요

02. 사용자 경험(User Experience) 개요

  가. 정의

    - 사용자의 환경을 개선하려는 설계자의 사고와 행동

    - 사용자가 어떤 시스템, 서비스를 통해 목적을 이루려 할 때 느끼는 경험, 감정, 지각, 태도, 반응의 종합적인 경험을 말하고, 사용자를 위해 편리한 화면 설계와 환경을 연구하고 서비스를 기획하는 과정

  나. UX와 UI의 차이점

    - UX는 보이는 것에 대한 경험을 말하고, UI는 사용자에게 보이는 인터페이스 그 자체

03. UI/UX 설계 도구

관련 링크

 1. Topic >  사용자 경험(UX, User Experience)

[TOPCIT 목차]

1. 객체 지향 분석과 모델링 개념

- 객체 지향 분석 : 주어진 요구 사항을 실세계에 존재하는 객체의 집합으로 보고 컴퓨터 세계로 가상화하는 과정

- 모델링 : 대상 시스템의 성능 또는 동작과정을 간단히 도식화하거나 수학적으로 표현하는 과정

- 객체 지향 모델링의 세가지 관점

- UML등의 툴을 사용하여 모델링한 후 설계에서 연속적으로 사용

- 기능 모델링 : Activity Diagram

- 동적 모델링 : Sequence Diagram

- 정보 모델링 : Class Diagram 

2. 객체 지향 설계와 원리

분석은 고객 관점의 개념적 차원이며, 설계는 구현 세부 사항 및 물리적 실현 방법 제시

가) 객체와 클래스

  - 객체: 독립적으로 존재하는 실세계의 사물로 속성 정보를 포함

  - 클래스 : 동일 속성 정보를 가지는 객체들의 집합

  - 클래스와 객체의 관계 : 객체 = 클래스의 인스턴스 (ex. 학생(클래스), 객체(김철수, 이영희))

나) 캡슐화(Encapsulation)

  - 정보의 은닉을 통한 추상화, 독립성 향상 방법으로 속성과 오퍼레이션을 함께 묶어 보호하는 방법

다) 상속(Inheritance)

 - 일반화된 속성을 가지는 상위 클래스가 하위 클래스에게 속성을 상속

 - 상위 클래스 : 사람 (이름, 주민번호) => 하위 클래스 : 학생(+ 학번), 교수(+직원번호) 

라) 다형성(Polymorphism)

 - 동일한 이름의 오퍼레이션이 다른 동작을 하는 것

 - 오버로딩과 오버라이딩이 있음

 - 오버로딩 : 다중 메소드로 구현, 입력 변수와 타입을 달리함

 - 오버라이딩 : 하위 클래스에서 상속받은 메소드를 재정의

3. 정적 모델링과 동적 모델링

가) 정적 모델링

 - 시간의 개념이 개입되지 않은 객체의 정적인 정보

- 객체의 속성과 객체들 사이의 연관성을 나타내는 관계가 대표적임

나) 동적 모델링

 -  객체의 상태나 동작의 변화, 객체들 사이의 상호 작용을 표현

4. 디자인 패턴

가) 디자인 패턴 개념

 - 소프트웨어 설계의 특정한 맥락에서 반복해서 해결해야 할 문제에 대해서 일반적이고 재사용이 가능한 해결 방법

 - 목적 및 범위에 따른 분류

나) 대표적인 디자인 패턴

[부록] 객체지향설계원칙 (SOLID)

① 단일 책임 원칙(SRP: Single-Responsibility Principle)

클래스를 변경해야 하는 이유는 오직 하나여야 한다.

② 개방 폐쇄의 원칙(OCP: Open-Closed Principle)

확장(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

③ 리스코프 교체의 원칙(LSP: Liskov Substitution Principle)

기반 클래스는 파생 클래스로 대체할 수 있어야 한다.

=> 모든 메소드를 상속받도록 설계할 것. 이 경우 상호 대체 가능하며, 변경이 최소화된다. 

④ 의존 관계 역전의 원칙(DIP: Dependency Inversion Principle)

클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다.

=> 슈퍼클래스 자체를 추상화하거나 메소드만 추상화(인터페이스)하면, 실제 사용시 슈퍼클래스가 하위클래스를 참조하는 "의존관계역전"이 생기므로 이런 이름이 붙었음

⑤ 인터페이스 분리의 원칙(ISP: Interface Segregation Principle)

하나의 일반적인 인터페이스보다는 구체적인 여러 개의 인터페이스가 낫다.