Part1. 요구사항 확인 - 현행 시스템 분석

정보처리기사 Part1. 요구사항확인 - 현행 시스템 분석 요약정리

 

 

1. 현행 시스템 파악

• 현행 시스템 파악 : 개발하고자 하는 응용 소프트웨어에 대한 이해를 높이기 위해 현행 시스템의 적용 현황을 파악함으로써 개발 범위와 향후 개발될 시스템으로의 이행 방향서을 분석할 수 있음.
• 시스템 : 목적을 달성하기 위하여 구성 요소들이 상호 유기적으로 구성된 집합체.
• 컴퓨터 시스템의 구성 요소 : 입력, 처리, 출력, 피드백, 제어
• 현행 시스템 분석 : 운영체제 분석, 네트워크 분석, DBMS 분석등

---

2. 소프트웨어 생명주기

 

  1) 폭포수 모델

    - 적용 사례가 많음, 단계별 산출물이 명확하며 기존 시스템 보완에 좋음

    - 각 단계의 결과가 확인된 후 다음단계로 넘어가는 단계, 순차, 체계적인 접근 방식

    - 응용 분야가 단순하거나 내용을 잘 알고 있는 경우에 적용

    - 비전문가가 사용할 시스템을 개발하는데 적합

 

    1. 폭포수 모델의 개발 단계

      계획 → 요구 분석 → 설계 → 구현 → 시험(디버깅) → 운용 및 유지보수

 

    2. 폭포수 모델의 문제점

      - 모든 분석은 프로젝트가 시작되기 전에 완성되어야 함.

      - 개발 프로젝트의 불명확성을 미연에 방지할 수 없음

 

  2) 프로토 타이핑 모형

      - 폭포수 모델의 문제점을 해결하기 위해 실제 개발될 소프트웨어의 일부분을 직접 개발하여 사용자의 요구사항을 미리 정확하게 파악하기 위한 모형

 

    1. 프로토 타이핑 개발순서

      요구사항 분석  → 신속한 설계 → 프로토타입 작성 → 사용자 평가 → 프로토타입의 정제 → 공학적 제품화 

  

  3) 나선형 모형

      - 폭포수 모형과 프로토타이핑 모형의 장점을 수용하고, 새로운 요소인 위험 분석을 추가한 개발 모델. 대규모 시스템에 적합.

      - 계획 수립, 위험 분석, 개발 , 사용자 평가 과정을 반복적으로 수행

      - 위험분석을 끝낸 후 개발을 들어가기 전 지속할 것인지에 대한 의사결정을 진행함

      나선형 모형의 단점 : 어느 시점에 끝내야 하는지 파악하기 힘듬

 

  4) V-모형

      - 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 것

      - 높은 신뢰서이 요구되는 분야에 적합

 

      V-모형의 장점 : 모든 단계에 검증과 확인 과정이 있어 오류를 줄일 수 있음

      V-모형의 단점 : 생명주기의 반복을 허용하지 않아 변경을 다루기 쉽지 않음.

 

  5) RAD 모형

      - 빠른 개발을 위해 컴포넌트 기반으로 개발, 재사용이 가능한 컴포넌트 개발을 강조

      - 요구사항 파악이 잘 되고, 프로젝트 범위가 한정된다면 60~90일 이내에 완벽한 시스템 개발이 가능

      - 순서 : 비즈니스 모델링 ↔ 데이터 모델링 ↔ 프로세스 모델링 ↔ 애플리케이션 생성 ↔ 시험 및 인도 

 

  6) 애자일

      - 생명주기 동안 반복적인 개발을 촉진

      - 대규모 소프트웨어에는 적합하지 않음

      

      1. 애자일의 특성

        1) 프로세스 중심이 아닌 사람중심

        2) 문서화보다는 제대로 작동하는 소프트웨어

        3) 계약 협상보다는 고객과의 협력

        4) 계획을 따르기보단 변화에 대응

 

      2. 애자일의 종류

        1) 익스트림 프로그래밍(XP) : 고객과 함께 2주 정도의 반복 개발을 하고 테스트와 우선 개발을 특징

        2) 스크럼 : 30일마다 동작 가능한 제품을 제공하는 스프린트 중심 → 스프린트라는 말이 나오면 스크럼이라고 생각하면 됨.

 

      3. 익스트림 프로그래밍(XP) - 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법

        1) XP의 5가지 핵심 가치★★

          - 존중 :  팀원 간의 상호존중을 강조

          - 단순성 : 사용되지 않는 구조와 알고리즘을 배제

          - 의사소통 : 개발자, 관리자, 고객 간의 원할한 의사소통이 가능해야함.

          - 피드백 : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백을 해야함.

          - 용기 : 고객의 요구사항 변화에 능동적인 대처를 해야함.

 

        2) XP의 실천 사항

          - 소규모 릴리즈 : 아주 짧은 사이클로 새로운 버전을 배포

          - 테스트 기반 개발(TDD) : 작성해야 하는 프로그램에 대한 테스트를 먼저 진행 후, 코드를 작성하고 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성

          - 짝 프로그래밍 : 두 사람이 같이 프로그래밍 함

          - 공동 코드 소유 : 시스템에 있는 코드는 누구둔, 언제라도 수정 가능

          - 고객 상주 : 개발자들의 질문에 대응할 수 있는 고객을 프로젝트에 풀타임으로 상주시킴

---

3. 개발비용 산정

  1) 개발비용 산정의 개념 : 인원, 자원, 기간 등으로 소프트웨어 프로젝트 규모를 확인하여 미리 소프트웨어에 필요한 비용 을 산정하는 것

 

  2) 하향식 산정 방법 - 전체 시스템 차원에서 비용을 산정한 후 서브 모델의 비용을 산정

    1. 전문가의 감정 - 경험과 지식을 갖추고 있는 2명 이상의 전문가에게 의뢰하는 기법

    2. 델파이식 산정 - 중재자를 통해 여러 전문가의 의견 일치를 얻어내는 기법이며, 전문가 감정 기법의 문제점을 보완하기 위한 방법

 

  3) 상향식 산정 방법(★) - 세부적인 작업 단위로 비용을 추정하여 전체적인 비용을 산정

    1) LOC(Line of Code)기법

      - 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하고 이를 활용해 예측치를 구해 비용을 산정하는 방식

      - 예측치 = 낙관치+[4*기대치] + 비관치 / 6

    2) 인월 수 기법 - 각 기능을 구현시키는 데 필요한 노력을 생명주기 각 단계별로 산정하여 LOC보다 정확서을 기하기 위한 기법

 

  4) 수학적 산정 방법 - 상향적 산정 방법에 속하며, 경험적 추정 방법, 실험적 추정 방법이라고도 함

    1. COCOMO

      - 보헴이 제안한 산정 기법으로 원시코드 라인수에 의한 비용 예측 모델

      - 유기적 모델 : 5만 라인 이하의 프로젝트

      - 준분리형 모델 : 30만 라인 이하의 프로젝트

      - 내장형 모델 : 30만 라인 이상의 프로젝트

 

    2. Putnam의 생명 주기 예측 모형

      - Rayleigh-Norden 곡선에 기초

      - SLIM 비용 추정 자동화 몽형의 기반이 됨

 

    3. FP모형( Function-Point)

      - 소프트웨어의 각 기능에 대하여 가중치를 부여하여 요인별 가중치를 합산해서 소프트웨어의 규모나 복잡도, 난이도를 산출하는 모형

      - 기능 유형으로는 내부논리파일, 외부연계파일, 외부입력, 외부출력, 외부조회가 있으며 구멍뚫기 문제로도 출제가능함

 

---

느낀점 : 출제 빈도가 낮은 파트인 만큼 중요한 부분이 한정적인 것 같다. 바로 애자일 기법인데, 시간이 부족할 경우 애자일 기법의 XP와 스크럼에 대해 공부해두면 좋을 것 같다.