메타 스터디 그룹

1. 소프트웨어 유지보수의 개념과 유형

1) 소프트웨어 유지보수의 정의

• 소프트웨어 유지보수는 SDLC(Software Development Life Cycle)의 마지막 단계로 소프트웨어의 생명을 연장시키는 운영중심의 작업 단계
• 오류의 수정, 원래의 요구를 정정, 기능과 수행력을 증진시키는 일련의 작업
• 소프트웨어가 고객에게 납품된 후 결함의 제거, 성능항상, 변화된 환경에 적응하도록 처리하는 일련의 모든 소프트웨어 공학적 작업

2) 소프트웨어 유지보수의 목적 및 필요성

소프트웨어 유지보수의 목적

• 소프트웨어의 성능 개선 및 하자보수
• 새로운 환경에서 동작할 수 있도록 이식 및 수정과 오류를 예방

소프트웨어 유지보수 필요성

• 소프트웨어 개발 및 유지 전체 예산에서 기존 개발 비용보다 유지보수 비용이 현격히 증가
• 소프트웨어 복잡화에 따라 문서화 등의 관리업무가 증가
• 개발 기간에 비해 사용 기간이 길기 때문에 관리의 중요성이 강조
• 용역 개발보다 패키지 개발이 확산됨에 따라 유지보수 부문이 증가

3) 소프트웨어 유지보수의 종류

2. 소프트웨어 유지보수 활동

1) 소프트웨어 유지보수 절차 및 요소

소프트웨어 유지보수 절차

유지보수 용의성

- 유지보수 용이성은 소프트웨어 유지보수의 난이도를 나타내는 특성

유지보수 용의성 개선 활동

- 향후에 환경이 변화하더라도 사용자 또는 고객의 요구사항을 지속적으로 충족시키면서, 급격히 증가하는 유지보수 비용에 경제적으로 대응

- IEEE/EIA 12207은 유지보수 담당자를 유지보수 활동을 수행하는 조직으로 정의

2) 소프트웨어 유지보수 조직 

유지보수 활동별 주체

소프트웨어 유지보수 조직 유형

- 가장 많이 적용되는 유형은 어플리케이션 분야에 따른 조직으로 응용업무에 대한 지식이 필요한 분야에 주로 적용

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)