11/30 13주차 수업 내용 정리

10장 유지보수

 

유지보수

 

소프트웨어가 인수되어 설치된 후 일어나는 작업
개발기간보다 길다.

 

유지보수의 종류

동기에 따라 네 가지 종류
- 교정형
- 적응형
- 개선형
- 예방형

 

Lehman의 원리

- S/W는 계속 변경된다.

- 복잡도가 계속 증가된다.

- 대규모 S/W의 유지보수에는 일정한 방향(특성)이 있다.

- 대규모 S/W는 안정화 상태인 경우가 많다.

- 진화할 때 친근성을 유지하려고 한다.

- S/W의 기능은 계속 증가한다.

- S/W가 운영 환경에 적응하지 못하면 품질이 저하된다.

- 소프트웨어는 피드백을 통해 진화해나간다.

 

개발작업과 유지보수 작업의 차이

- 포괄적이고 단발적으로 수행

   - 다양한 기술이 필요

-이해 단계에 많은 비용이 듦

   - 통합적이며 이해중심적

 

유지보수에 영향을 주는 요소

사용자

  - 불편, 오류의 개선을 위한 변경 요청

 

환경

  - 운용환경, 조직환경의 변화

 

유지보수 프로세스

  - 변경요청, 프로그램 이해/변경, 효과분석, 리그레션 테스팅

 

소프트웨어 제품

  - 지속적인 사용과 변경

 

유지보수 인력

  - 관련된 사람

 

유지보수 작업의 문제점과 한계

  - S/W에 대한 변경이 수로 일어남

    - 문서에 반영하지 않는 경우 이를 추적하는 것은 거의 불가능

 

  - 다른 사람이 작성한 프로그램을 이해하는 일은 쉽지않음

    - 문서화 되어있지 않거나 주석도 달지 않았다면 문제는 매우 심각

 

  - 변경을 가정하여 설계되는 경우가 드물다.

 

  - 관리적인 측면에서 유지보수를 담당하는 프로그래머에게 동기부여를 하지 못함.

 

  - 유지보수를 위한 적극적인 도구를 사용하지 못함.

    - 프로그램 이해를 위여 테스트나 디버깅 도구를 사용하는 데 그침.

 

유지보수 작업 모델

  - 즉시 수정 모델

  - 반복적 개선 모델

  - 재사용 중심 모델

 

형상관리

  - 변경에 대한 철저한 관리가 필요

    - 소프트웨어 형상 관리

 

  - 형상 관리

    - 소프트웨어를 이루는 부품의 baseline(변경 통제 시점)을 정하고 변경을 철저히 통제하는 것

 

  - 형상 관리 요소

    - 분석서

    - 설계서

    - 프로그램(원시코드, 목적코드, 명령어 파일, 자료 파일, 테스트 파일)

 

형상 관리 절차

  - 소프트웨어 형상 파악

  - 형상 변경 제어

  - 소프트웨어 형상 감사

  - 소프트웨어 형상 상태 보관

 

형상 요소 파악

  - 고유 식별자 - 고유 번호    예) LIS-Incl-DM

  - 이름

  - 문서 종류 - 요구 분석서, 설계 문서, 원시코드, 테스트 케이스

  - 문서 파일 - 파일 이름과 경로

  - 저자

  - 생성 날짜, 목표 완성일

  - 버전 번호

  - 업데이트 이력

  - 설명

  - SQA 담당자 - 형상 항목의 품질 보증 책임자

  - SCM 담당자 - 형상 항목을 검토할 책임자

 

형상 변경 제어

  변경의 이유를 파악

    - 소프트웨어의 결함

    - 하드웨어 변경

    - 운영 요구의 변경

    - 고객이나 사용자로부터 개선 요구

    - 예산, 프로젝트 일정, 기간의 변경

 

형상 감사

  - 베이스라인을 구축하기 위한 메커니즘 정의

  - 형상 항목 검토

  - 형상 항목 확인

 

 

리엔지니어링

  - 지속적으로 변화하는 S/W

    - 구조가 나빠짐을 의미

 

  - 리엔지니어링

    - 시스템 또는 컴포넌트를 재구조화 하는 과정

    - 유지보수를 넘어 개선하는 차원

 

  - 목적

    - 소프트웨어 아키텍쳐 개선

    - 소프트웨어의 복잡도 경감

    - 변경에 대한 적응성 개선

    - 성능, 효율성, 자원 유용성 개선

    - 소프트웨어 시스템의 유지보수 개선

 

리엔지니어링의 정의

  - 역공학

    - 시스템을 이루는 부품을 찾아내고 관계를 파악하며 다른 형태로 표현하기 위하여 대상 시스템을 분석하는 과정

 

  - 재구성

    - 대상 시스템의 기능은 변화 없이 같은 추상 수준에서 표현 형태를 바꾸는 작업

               ex) complete graph를 같은 기능을 하는 좀 더 간단한 구조로 바꾸는 것

 

  - 리엔지니어링

    - 대상 시스템을 새로운 요구에 맞도록 개조하는 작업

 

리엔지니어링 작업 과정

  - 개선이 필요한 위치 파악

  - 개선 전략을 선택

  - 제안된 개선의 구현

  - 목표를 기준으로 시스템 평가

 

 

유지보수 도구

  - 도구의 사용은 시간과 노력을 대폭 감소시킬 수 있음.

    - 일관성 유지, 변경 사항 공유

 

  - 역공학 도구

  - 메트릭 측정 도구

  - 성능 측정 도구

  - 정적 분석 도구

  - 변경 효과 분석 도구

  - 형상 관리 도구

  - 리그레션 테스팅 도구

 

 

 

11장 프로젝트 관리

 

  01. 프로젝트 관리란?

    - 프로젝트를 계획하고 수행하는 데 필요한 모든 작업을 총망라

      - 필요한 작업의 결정

      - 비용 예측

      - 프로젝트에 적합한 인력 확보

      - 직무 정의

      - 일정 계획

      - 작업 준비

      - 지시, 감독

      - 기술적 리더

      - 다른 사람이 내린 결정을 리뷰하고 승인

      - 팀원 사기 진작과 지원

      - 모니터링, 조절

      - 다른 프로젝트 관리자와 협력

      - 보고

 

  02. 소프트웨어 개발 프로세스

    - 프로젝트를 소규모 작업으로 구성하는 일반적인 접근 방법

 

    - 관리자와 팀원들이 다음 사항을 결정하는 데 도움

      - 무엇을 해야 하며

      - 어떤 순서로 작업을 진행할 것인지

 

    - 모델은 작업 방식을 엄격하게 규정하기 위함보다 생각하는 데 도움을 주어야 함.

 

  즉흥적인 개발 프로세스

    - 좋은 엔지니어링 과정을 따르지 않았을 때 일어나는 문제점들

      - 구현하기 전에 요구나 설계 등의 연습의 중요성을 인식하지 못함.

      - 설계가 잘 되지 않았다면 S/W의 질이 떨어질 수 있음.

      - 계획이 없어 목표 없이 일하게 됨.

      - 체계적인 테스트나 품질 보증 같은 작업의 필요성을 간과하게 됨.

      - 이상의 이유로 유지보수 비용이 증가됨.

 

  대표적인 개발 프로세스 모델

     1. 즉흥적인 개발 프로세스 - 즉흥적으로 프로그래밍하고 사용자가 원하면 수정하는 식으로 작업

     2. 폭포수 모델

       - 1970년대 소개

          - 항공 방위 소프트웨어 개발 경험으로 습득

       - 각 단계가 다음 단계 시작 전에 끝나야 함.

          - 순서적 : 각 단계 사이에 중복이나 상호작용이 없음

          - 각 단계의 결과는 다음 단계가 시작되기 전에 점검

        

        - 폭포수 모형의 단점

          - 처음 단계를 지나치게 강조하면 코딩, 테스트가 지연됨.

          - 각 단계의 전환에 많은 노력

          - 프로토타입과 재사용의 기회가 줄어듦

          - 소용 없는 다종의 문서를 생산할 가능성이 있음.

 

     3. 점증적 모형

        - 개발 싸이클이 짧은 환경

           - 빠른 시간 안에 시장에 출시하여야 이윤에 직결

           - 개발 시간을 줄이는 법 - 시스템을 나누어 릴리즈

 

        - 릴리즈 구성 방법

           - 점증적 방법 - 기능별로 릴리즈

           - 반복적 방법 - 릴리즈할 때마다 기능의 완성도를 높임.

 

        - 단계적 개발

           - 기능이 부족하더라도 초기에 사용 교육 가능

           - 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음

           - 자주 릴리즈하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음.

           - 개발 팀이 릴리즈마다 다른 전문 영역에 초점을 맞출 수 있음.

 

      4. 나선형 모형

        - 소프트웨어의 기능을 나누어 점증적으로 개발

          - 실패의 위험을 줄임

          - 테스트 용이

          - 피드백

 

        장점

          - 대규모 시스템 개발에 적합 - risk reduction mechanism

          - 반복적인 개발 및 테스트

             - 강인성 향상

        

        단점

          - 관리가 중요

          - 위험 분석이 중요

          - 새로운 모형

 

      5. 진화적 모형

         - 반복적이며 점증적인 방법

 

         -RUP

           1. 도입 단계 : 프로젝트의 범위를 설정하고 목표를 명확히

           2. 정련 단계 : 시스템의 중요한 요구를 찾아내어 기본이 되는 설계를 완성

           3. 구축 단계 : 제조 단계, 원시코드가 완성되고 모든 중요한 요구의 테스트가 마무리

           4. 전환 단계 : 사용자에게 릴리즈

 

      6. 애자일 프로세스

        - 설계가 변경되어도 잘 수용할 수 있도록 짧게 반복하면서 개발하는 방법

        - 짧은 릴리즈와 반복 : 작업을 작은 조각으로 나누어 되도록 자주 릴리즈

        - 점증적 설계 : 설계에 대한 결정을 미루고 더 많은 지식이 쌓였을 때 설계를 개선

        - 사용자 참여 : 처음부터 변하지 않는 완벽한 표준을 만들려고 하기보다 사용자를 참여시켜 계속 피드백 제공

        - 문서 최소화 : 필요한 문서만 최소로 작성. 원시코드가 문서화의 실체

        - 비공식적 커뮤니케이션 : 형식적인 문서보다 지속적인 대화

        - 변화 : 요구와 환경의 변경을 가정하고 이를 다룰 수 있는 좋은 방법을 찾아냄.

 

        6.1 익스트림 프로그래밍

          - 최초의 애자일 프로세스

          - 계획 : 비즈니스 우선순위와 기술적인 예측을 토대로 결정

          - 짧은 릴리즈 : 2~4주

          - 메타포 : 정형화된 아키텍처 대신 메타포를 사용

          - 간결한 설계 : 불필요하게 복잡한 부분은 제거

          - 테스트 중심 개발 : 실제 코드를 쓰기 전에 먼저 테스트 코드를 작성

          - 설계 개선(리팩토링) : 동작의 변경 없이 시스템을 재구성하고 설계를 개선

          - 페어 프로그래밍 : 컴퓨터를 공유하며 개발과 테스팅 역할을 수행

          - 지속적 통합 : 항상 실행되는 시스템을 유지하도록 여러 번 통합하고 빌드

          - 적정 속도 : 주당 40시간

          - 고객 참여 : 팀에 고객이 합류하여 항상 질문에 답할 수 있도록

          - 코딩 표준 : 코딩에 동일한 규칙

 

       6.2 스크럼

          - 개발 연습을 하면서 개발 능력을 향상할 수 있는 프레임워크

          - 릴리즈 계획 회의

             - 백로그를 결정

          - 스프린트

             - 반복 주기 (2~4주)

             - 스토리를 개발하고 설치

          - 스크럼 회의

             - 매일 15분간의 진도 확인 회의

          - 스프린트 회고

 

  03. 개발 노력의 추정

    - 개발에 얼마만큼의 작업이 필요한지를 예측

    - 개발 노력

       - MM(인원/월)로 나타는 노동량

       - 개발 노력의 산정을 금전으로 환산

 

    - 일반적 추정 공식

                    Effort=a+b(size)^c + ACCUMm(factor)

     

    - 인건비 계산법

      - 상향식

        - 소작업에 필요한 기간을 구하고 이를 바탕으로 전체 소요 기간을 예측

 

      - 하향식

 

COCOMO 추정 모델

  - Boehm이 개발

     - TRW의 2K-32K 정의 많은 프로젝트의 기록을 통계 분석

 

  - 추정 과정

    1. 기본형 organic, 중간형 semi-detached, 내장형 embedded 중 어떤 프로젝트 유형인지 선택

 

  표준 산정 공식

                               

 기능 점수 기반 추정 모델

   LOC의 문제점

     - 정확한 라인 수는 예측 불가능

 

   S/W 구성 요소

     - 외부 입력, 외부 출력, 외부 질의, 내부 논리 파일, 외부 인터페이스 파일

 

   가중치 반영 기능 점수 도출

     - UFP=(입력 개수 X 3) + (출력 개수X4) + (질의 개수X3)

 

 

기술 복잡도 계산

  - 14개 분야

    - 데이터 통신, 분산 데이터, 성능 중요도, 과중한 하드웨어 사용, 높은 트랜잭션 비율, 온라인 데이터 입력, 온라인 업데이트, 복잡한 계산, 설치 용이성성, 오퍼레이션 용이성, 이식성, 유지보수성, 엔드유저의 효율, 재사용성

 

  - TCF = 0.65+[(0.01) Xt (14개 기술적 복잡도 요인의 합)]

 

객체 점수 기반 추정 모델

  - 구성요소인 클래스의 개수와 가중치 기반

  - 추정 방법

     1. 문제 도메인에 있는 클래스의 갯수를 추정

     2. 사용자 입력의 종류를 분류, 가중치 정함

       - UI 없음 : 2.0, 단순한 텍스트 UI : 2.25, 그래픽 UI : 2.5, 복잡한 UI : 3.0

     3. 1단계에서 추정한 클래스의 갯수에 사용자 인터페이스 유형에 의한 가중치를 곱함.

     4. 3단계에서 추정한 총 클래스의 개수에 

 

일정 계획과 관리

  - 일정 계획

    개발 프로세스를 이루는 소작업(activity)를 파악하고 순서와 일정을 정하는 작업

 

간트 차트

  - 프로젝트 일정표

    - 소작업별로 작업의 시작과 끝을 나타낸 그래프

    - 예비시간을 보여줌

    - 계획 대비 진척도를 표시

    - 개인별 일정표

 

04. 팀 구성

  조직의 구성

    - 결과물 및 소프트웨어 개발 생산성에 큰 영향

    - 역할과 책임 배정

    - 조직 관리

 

  조직 선택에 영향을 주는 요소

    - 작업의 특성

    - 팀 구성원의 의사 교류

 

  S/W 개발 조직

    - 책임 프로그래머 팀

        - 작은 팀으로 구성 책임 프로그래머가 통제

        - Chief programmer team

          - 외과 수술 팀 구성에서 따옴

        - 책임 프로그래머 : 제품설계, 주요부분 코딩, 중요한 기술적 결정, 작업의 지시

        - 프로그램 사서 : 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리

        - 보조 프로그래머 : 책임 프로그래머를 보좌, 여러가지 기술적 문제에 대해 자문

        - 프로그램 사서 : 프로그램 리스트 ,설계 문서 ,테스트 계획 등을 관리함.

 

        장점 : 의사 결정이 빠름

        단점 : 모든 의사 결정이 한 사람에 의해 이루어지므로, 이 사람의 능력이 프로젝트 성패의 갈림길이 됨.

 

   - 에고레스 팀

     - 민주주의식 의사결정

       - 서로 협동하여 수행하는 비이기적인 팀(Ego-less)

       - 자신이 있는 일을 알아서 수행

       - 구성원이 동등한 책임과 권한

 

   - 계층형 팀

     - 집중형, 분산형의 단점을 보완

     - 특징

       - 초보자와 경험자를 분리

       - 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐

       - 의사교환은 초보 엔지니어나 중간 관리층으로 분산

 

     - 소프트웨어 기능에 따라 계층적으로 분산

     - 단점

        - 기술인력이 관리를 담당

        - 의사 전달 경로가 김

 

06. 프로젝트 계획서

  1. 목적

  2. 배경 지식

  3. 프로세스

  4. 서브시스템과 릴리즈 계획

  5. 위험

  6. 작업

  7. 비용산정

  8. 팀 구성

  9. 일정