프로세스와방법론

소프트웨어 공학 - 프로세스와 방법론

​

소프트웨어 공학 접근 방법의 핵심은 프로세스와 방법론 개념이다.

소프트웨어 개발 작업의 성숙도는 어떤 순서로 , 어떤 방법으로 하는 가에 의하여 크게 좌우된다.

프로젝트 계획을 수립하는 과정에 개발 모델 , 즉 프로세스와 방법론의 선정은 다른 어떤 결정보다도 프로젝트 성공에 큰 영향을 준다.

​

프로세스 특징 - 단계적인 작업의 틀을 정의한 것

                  무엇을 하는가에 중점

                  결과물이 표현에 대하여 언급 없음

                  패러다임에 독립적

                  각 단계가 다른 방법론으로도 실현가능

사례 - 폭포수 프로세스 , 나선형 프로세스 , 프로토타이핑 프로세스 , Unified 프로세스 , 애자일 프로세스

​

방법론 특징 - 프로세스의 구체적인 구현에 이름

                 어떻게 하는가에 중점

                 결과물을 어떻게 표현하는지 표시

                 패러다임에 종속적

                 각 단계의 절차 , 기술 , 가이드라인을 제시

사례 - 구조적 분석, 설계 방법론 , 객체지향 방법론, 컴포넌트 , 애자일 방법론

​

2.1 소프트웨어 공학의 접근 방법

​

소프트웨어 프로세스는 소프트웨어 시스템을 구축하기 위하여 수행되는 작업의 단계이다.

각 단계는 결과물을 생성하는데 다른 단계의 입력이 된다.

각 단계는 진입 조건과 종료 조건이 있다.

​

2.1.1 프로세스와 프로세스 모델

​

성공적인 프로젝트는 비용, 일정, 품질, 세 가지 목표에 대한 예상치를 만족하는 프로젝트이다.

따라서 소프트웨어 프로젝트를 계획하고 실행할 때 궁극적으로 비용을 줄이고 일정을 단축하며 품질을 개선하려는 관점으로 의사결정을 내린다.

 

계획 - 요구분석 - 설계 - 구현 - Testing - 인수 - 응용

​

2.1.2 프로세스의 종류

​​

개발 프로세스는 프로젝트에서 이루어져야 할 중심 프로세스다. 작업을 계획하고 모니터링 하는 일은 프로젝트 관리 프로세스에 해당된다.

일반적으로 소프트웨어 개발에는 개발 프로세스와 프로젝트 관리 프로세스로 나눌 수 있다.

​

개발 프로세스는 수행해야 할 개발과 품질 보증 작업들이 해당되며 관리 프로세스는 비용, 품질 , 기타 목표를 맞추기 위한 계획 , 제어 작업을 말한다.

​

소프트웨어 프로세스

    - 프로덕트 엔지니어링 프로세스 ( 개발 프로세스 , 프로젝트 관리 프로세스 , 소프트웨어 형상 관리 프로세스)

    - 프로세스 관리 프로세스 (목적 : 소프트웨어 프로세스를 개선하는 것, 개선이란 것은 좋은 품질의 상품을

        낮은 비용으로 생산할 수 있게 프로세스 역량을 개선한다는 것을 의미한다.

​

개발 프로세스의 결과는 작업 결과(work product) 라 부른다. 소프트웨어에서 작업 결과는 요구 분석서 , 설계 문서, 코드 , 프로토타입 등이다.

​

​

2.2 바람직한 프로세스의 특성

​

​

예측 가능한 프로세스는 소프트웨어 공학의 인프라라고 할 수 있다.

개발 프로젝트에서 가장 중요한 사항 중의 하나는 유지보수가 쉬운 소프트웨어를 만들어야 한다는 사실.

​

프로세스의 목적은 설계와 코딩에 드는 노력을 낮추는 것이 아니라 테스팅과 유지보수에 드는 노력을 낮추는 것이다. 테스팅과 유지보수 작업은 설계와 코드 품질을 좌우한다. 테스팅과 유지보수가 쉽도록 소프트웨어를 설계 하고 코딩한다면 비용을 상당히 낮출 수 있다. 따라서 개발 프로세스를 정할때 중요한 이슈는쉽게 테스팅하고 수정할 수 있게 만드는 것이다.

​

   변경 용이성 - 변경은 항상 일어나므로 변경을 쉽게 다룰 수 있는 프로세스가 요망

   결함제거 용이성 - 품질 보증 작업의 주목적은 결함을 찾아 고치는 것 , 결함 방지를 지원하기 위하여 따르는

      일반적인 방법은 과거의 프로젝트에서 배우기 위하여 개발 프로세스를 사용하는 것이다.

​

​

2.3 소프트웨어 개발 프로세스

​​

소프트웨어의 개발 프로세스 모델을 이해하는 것은 소프트웨어 공학을 공부하는 데 필수적이다.

소프트웨어도 사람과 같이 생명주기가 있다.

개념화 단계 (개발 전) - 유아 및 성장기 (개발 단계) - 성년기 - 장년기 (개발 후 )

소프트웨어가 자라나고 있는 단계를 소프트웨어 개발 프로세스 모델이라 하며 여러 가지 모델이 제안되어 있다.

​

소프트웨어를 개발하는 과정에는 여러 가지 작업이 필요하며 요약하며 나열하면 다음과 같다.

   요구 분석과 정의

   시스템 설계

   프로그램 설계

   프로그램의 작성(코딩)

   테스팅(단위 테스팅, 통합 테스팅, 시스템 테스팅)

   시스템 설치

   유지 보수

​

2.3.1 폭포수 모델 - (전통적 모형 - 고전적 - 재래식 - 업무구조 단순)

​

폭포수 모델은 요구분석 , 설계 , 구현, 테스팅 등의 작업을 순서대로 쭉 해나가는 프로세스이다.

폭포수 모델은 폭포에서 내려오는 물이 아래로만 떨어지듯이 각 단계가 순차적으로 진행되는 , 즉 병행되어 진행되거나 거슬러 반복 진행되는 경우가 없다.

폭포수 모델의 큰 특징은 작업 단계가 단순하다는 것 , 작업 단계가 복잡하고 반복되는 경우 일정이나 결과에 대한 예측이 어렵지만 단순한 작업 단계라면 쉽게 예측할 수 있다. 또한 비전문가라 하더라도 시스템을 개발하는 과정을 이해하기 쉽다.

​

계획 - 요구 분석 - 설계 - 구현 - 테스팅 - 인수/설치 ——— 폭포수 모델

​

폭포수 모델의 두 번째 큰 특징은 작업이 일렬로 나열되어 있어 직능 중심의 프로젝트 조직이 가능하다는 점이다. 요구 분석 , 설계 , 구현, 테스팅 등 각 작업을 전문으로 하는 팀이 전담하여 마치 파이프라인과 같은 형태로 작업이 가능하다.

세 번째로 폭포수 모델은 크고 복잡한 오래 지속되는 프로젝트에 적합하다. Ex) 공장을 제어하는 시스템이나 우편물을 정리하고 분류하는 시스템 개발에 적합

​

폭포수 모델은 여러 가지 단점이 있다. - 융통성 x 변화에 약함

   첫째 설계와 코딩 및 테스팅을 지연 시킬 우려가 있다.

   두번 째 각 단계와 일정이 엄격하여 요구 변경을 수용하기가 어렵다.

   전통적인 폭포수 모형을 따를 경우 다음에 설명할 프로토타입과 재사용의 기회가 줄어드는 단점이 있다.

   무엇보다 중요한 단점은 최종 단계까지 가 보아야 결과가 나온다는 점이다.

   전체 소프트웨어가 최종 단계에 가서 한꺼번에 출시 되기 때문이다.

만일 프로젝트가 중간에 취소된다면 투자한 비용을 회수할 수 없는 위험을 감수하여야 한다.

​

2.3.2 프로토타이핑 모델

​

프로토타이핑이란 시스템의 일부 혹은 시스템의 모형이 될 만한 것을 만드는 과정이다. 예를 들면, 시스템을 사용하는 과정을 보여줄 시나리오나 화면 모형을 말한다. 이는 시스템의 작동을 시뮬레이션 하여 사용자가 볼 수 있는 반응을 보여준다.이것은 요구된 소프트웨어의 일부를 구현하여 보여주는 것으로 나중에 구현 단계에서 사용될 골격 코드가 된다.

​

프로토타이핑 기반 개발 프로세스의 목적은 폭포수 모델의 두 가지 단점을 보완하려는 것이다.

​

요구 분석 - 프로토타입 개발/개선 - 프로토 타입 평가. (루프) - 구현 - 인수/설치. - 프로토타이핑 모형

​

프로토타입이 구현된 후에 발주자와 개발자는 이를 평가하여 요구를 수정한다. 프로토타입을 수정하거나 보완하고 이를 확장하면 시스템이 구현되는 것이다.

이를 진화적 프로토타입이라고 하며 프로토타입을 계속 발전시켜 원래 정한 수준까지 만들어 나가는 형태이다.

반면에 쓰고 버리는 프로토타입이 있다. 프로토타입의 개발은 요구 분석 명세서의 처음 버전이 나온 후에 시작한다.

프로토타입을 개발한 후에는 사용자가 프로토타입을 사용할 기회를 준다. 사용 경험을 바탕으로 사용자가 개발자에게 피드백을 제공하는 것이다. 올바른 것, 수정될 필요가 있는 것, 빠진 것 , 필요 없는 것이 무엇인지 알려준다.

​

프로토타입 개발은 약식으로 간단히 한다. 프로토타입은 확인 후에 버릴 것이므로 품질보다는 빠르게 만들어야 한다.

프로토타입을 개발하는 과정에는 문서도 최소한으로 만들고 테스팅 작업에도 많은 비용을 투자하지 않는다.

​

개발 비용이 늘어날 것이 염려되어 프로토타입을 자주 사용하지 않는다. 그러나 프로토타이핑을 하지 않고 소프트웨어를 개발하는 비용이 프로토타이핑을 하는 것보다 더 많이 들 수도 있다. 두 가지 이유때문이다. 하나는 프로토타입 개발 경험이 실제 소프트웨어를 개발하는 후반의 비용을 절감시킨다. 둘째는 개발이 오랫동안 이루어져 요구가 계속 바뀌기 때문이다.

​

프로토타입을 사용하면 여러 가지 장점이 있다. 발주자가 완성된 시스템의 모습을 먼저 볼 수 있고 , 이를 보고 요구를 수정할 수도 있다.

프로토타입은 발주자나 개발자에게 공동의 참조 모델을 제공한다. 발주자는 프로토타입으로 인하여 소프트웨어 개발에 더 관심을 가지고 참여할 수 있고, 개발자는 프로토타입을 통하여 사용자의 요구를 자세하게 도출할 수 있다. 또한 중요한 것은 프로토타이핑으로 소프트웨어 개발이 제대로 되고 있는지 확인할 수 있다는 점이다. 다른 관점에서 보면 프로토타이핑 모형은 소프트웨어 생명 주기에서 유지보수가 없어지고 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있다.

폭포수 모형은 개발 단계에 변경을 금지하여 이를 개발 후로 미루었다.

결국 뒤로 미룬 오류들을 변경하기 위하여 많은 비용과 노력이 유지보수 단계에 투입된다. 프로토타이핑은 두 차례에 걸쳐 개발할 기회가 있으므로 잘못된 부분을 고칠 기회가 많다.

프로토타이핑의 가장 큰 단점은 발주자가 프로토타입이 최종 결과라 믿고 곧 소프트웨어 개발이 완성되리라고 오해하는 것이다.

개발자 입장에서의 단점은 프로토타이핑 과정을 관리, 통제하기가 어렵다는 것이다.

폭포수 모델은 개발을 계속하기 위하여 요구를 동결하는 반면 프로토타입 구축을 경험한 후 동결된 요구는 더 안정적이다.

​

2.3.3 진화적 모델

​

진화적 모델은 폭포수 모델이 한 번에 릴리스 하기 전에는 사용자가 아무 것도 경험하지 못하고 피드백 할 수 없는 단점,

즉 빅뱅 릴리스를 보완하려는 방법

​

개발자 릴리스 1 구축 ———사용자 릴리스 1 사용 ,

개발자 릴리스 2 구축 ——— 사용자 릴리스 2 사용,

개발자 릴리스 3 구축 ——— 사용자 릴리스 3 사용

기본적인 아이디어는 사용자에게 시스템을 조기에 경험하게 하고 출시를 빠르게 하기 위하여 표현한 것처럼 조금씩 점증적으로 개발하는 것.

즉 시스템을 여러 번 나누어 릴리스 하는 방법으로 중요하고 기초적인 기능을 우선 개발하여 사용하게 하고 나머지는 다음번에 개발하여 확장해 나가는 방법.

따라서 이 방법은 개발되어 운용되고 있는 시스템과 개발되고 있는 시스템이 병행 존재한다.

이런 방법의 장점은 시험을 잘 할 수 있다는 점이다. 반복의 증가분을 테스트하는 것이 폭포수 모델과 같이 전체 시스템을 단번에 테스트하는 것보다 쉽기 때문이다.

또한 프로토타이핑과 같이 시스템의 최종 요구를 결정하는 데 유용한 피드백을 사용자에게 제공할 수 있다.

개발 과정에서 릴리스를 구성 방법은 크게 두가지가 있다. 점증적인 방법과 반복적인 방법

점증적인 개발 방법은 요구 분석서에 나타낸 시스템을 기능별로 여러개의 서브시스템으로 나누고 일부 기능만을 포함한 서브시스템을 릴리스하고 다음에 새로운 기능을 추가해 나가는 형태이다. 따라서 새로운 릴리스가 발표됨에 따라 시스템의 기능이 완성되어 간다.

반복적인 방법은 처음부터 시스템 전체 기능을 대상으로 하되 릴리스 할 때 마다 기능을 더 완벽히 개발하는 형태이다. 예를 들어

워드프로세서를 개발한다고 할 때 릴리스1에 문서의 입력 기능을 완성하고 릴리스 2에 편집기능을 추가하며 릴리스 3에 다양한 글자체와 서식을 사용할 수 있도록 포매팅기능을 추가하였다면 이는 점증적인 방법이다. 반복적인 방법은 릴리스 1에 입력,편집,포메팅 기능이 기본적으로 가능하게 하고 릴리스2에서는

같은 기능이지만 성능을 향상한다든지 기능을 개선한다.

점증적인 방법과 반복적인 방법을 병행하여 사용하는 경우도 많이 있다. 새로운 릴리스에 새 기능을 추가할 수도 있고 릴리스된 기능을 향상시킬 수도 있다.

이 두 가지 방법을 단계적 개발이라고 부르기도 하며 각광 받고 있다.

고객에서 ㄹ모둔 증분을 릴리스하고 고객의 우선순위를 고려하여 고객과 밀접하다는 의미에서 애자일 모델과 유사.

결론 적으로 진호적 모델은 탐구적인 프로젝트에 적합.

​

​

2.3.4. 나선형 모델

​

​

위험 관리를 위한 독특한 프로세스이다.

나선형 모델의 중요한 특징은 개발을 위한 계획 및 요구분석 후에 위험 요소와 차선책에 대하여 검토하는 단계가 있다는 점이다.

​

1. 계획 수립 - 목표 , 기능 선택 , 제약 조건의 결정

2. 위험 분석 - 기능 선택의 우선순위, 위험 요소의 분석

3. 개발 - 선택된 기능의 개발

4. 평가 - 개발 결과의 평가

​

나선형 모델은 대규모 시스템의 소프트웨어를 개발하는 데 가장 적합한 방법으로 평가받고 있다.

특히 이 방법은 개발자나 사용자가 각 확장 단계에서 발생될 위험에 대한 이해와 대책이 가능하다. 따라사 프로젝트가 실패로

끝날 수 있는 위험을 사전에 막는 방법이 된다.

나선형 모델은 비선형적이며 반복적으로 개발이 진행되므로 소프트웨어 품질 중 강인성을 높일 수 있는 방법이 된다. 한 사이클이 끝난 후 포함되지 못한 요구 사항을 다음 단계의 개발을 위한 요구 사항으로 첨가할 수 있다.

반면에 점증적으로 시스템을 개발할 때 얼마나 관리를 잘 할 것인가가 중요하다. 초기에 위험 분석을 잘못하여 위험 요소가 발견되지 못하고 계속 진행된다면 많은 비용을 투입하고 실패로 끝날 수도 있다. 나선형 모형은 상대적으로 새로운 모형이므로 신중하게 적용할 필요가 있다. 나선형 방법은 재정적으로 혹은 기술적으로 위험 부담이 큰 경우 위험 분석을 해 나가면서 시스템을 발전시켜 나가자는 취지의 모형이다.

즉 요구사항이나 아키텍처를 이해하지 어렵다거나 근본적으로 성능에 문제가 있거나 중심 되는 기술에 문제가 있는 경우 나선형 모델이 적합하다.

​

2.3.5 V모델

​

V모델은 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 것이다.

세부적인 테스팅 프로세스로 구성되어 신뢰도 높은 시스템을 개발하는데 효과적인 것으로 알려져 있다.

 

                                                              인수/설치

  요구 분석  —        (요구분석 검증 )      — 시스템 테스팅

     시스템 설계 —  (인터페이스 검증)  — 통합 테스팅

           상세 설계  —  (모듈 검증)  — 단위 테스팅

                                   코딩

​

V모델은 개발 작업과 검증 작업 사이의 관계를 명확히 들어내 놓은 폭포수 모델의 변형이라 할 수 있다.

폭포수 모형은 문서와 결과물에 중점을 두는 반면 V모델은 작업과 결과의 검증에 초점을 두고 있다.

V모델의 장점은 모든 단계에 검증과 확인 과정이 있어 오류를 줄일 수 있다는 것이다.

따라서 무엇보다도 높은 신뢰성이 필요한 응용 분야, 예를 들면 의료 제어 시스템이나 원전 제어 시스템의 개발 같은 곳에 적합하다.

V모델의 단점은 생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지 않다는 점이다.

​

2.3.6 Unified 프로세스

​

여러개의 싸이클로 구성된다 . 각 싸이클은 시스템을 출시함으로 종결된다. 하나의 반복과정은 네 단계 ,

도입 , 정련 , 구축, 전환으로 구성되어 있다. 각 단계는 중요한 점검 일정으로 종료되는데 관리자가 프로젝트에 대한 중요한 결정을 내리도록 되어 있다. 각 반복 과정은 요구 분석, 설계 , 구현 , ㅌ스팅을 포함한 일연의 워크플로 작업을 따라간다.

​

1. 도입 - 1,2회 정도 반복으로 도입 단계를 진행한다. 이 단계에는 간단한 사용 사례 모델과 소프트웨어 구조, 프로젝트 계획을 작성한다. 사용 사례란 어떤 시스템이 개발될 것인지를 나타내기 위하여 비즈니스 프로세스를 모델링한 것이라 할 수 있다. 예를 들면

현금인출기를 위한 사용 사례는 입금 , 출금, 잔고조회 등이다. 사용 사례 모델은 소프트웨어 시스템 개발을 위한 가장 중요한 기준이 된다.

2. 정련 - 정련 단계는 어려 번의 반복 과정으로 이루어진다.

이 단계에서 대부분의 사용 사례를 작성하며 아키텍처 설계를 나타내는 UML 다이어그램을 그린다. 시스템의 가장 중요한 사용 사례에 대하여 설계하고 구현한다.

3. 구축 - 구축 단계에서는 남아 있는 사용 사례에 대하여 구현화 하고 시스템에 통합한다. 시스템을 목표 환경에 점증적으로 설치한다.

4. 전환 - 전환 단계에서는 시스템을 배치하는 작업을 한다. 사용자를 교육하며 베타 테스팅을 하여 결함을 수정하고 기능을 개선하는 작업이 포함된다.

Unified 프로세스는 사용 사례를 식별하여 시스템을 개발 계획에 활용하는데 초점을 두고 있다. 즉unified 프로세스는 사용 사례 중심의 프로세스라는 특징을 가진다. 또한 시스템 개발 초기에 아키텍처와 전체적인 구조를 확정하고 이를 시스템 개발의 가이드로 활용한다.반복적이고 점증적이다. 시스템이 여러 번의 반복과정을 통하여 이루어지며 여러 싸이클을 통하여 점증적으로 개발되기 때문이다.

​

2.3.7 애자일 프로세스

​

폭포수 프로세스는 복잡한 문제를 잘 파악하고 이해하여 해결하는 프로젝트에는 적합하다. 하지만 프로그램을 개반한다는 측면에서는 문서화 등의 오버헤드가 많은 단점이 있다. 이런 단점을 개발하기 위한 것이 애자일 프로세스이다. 애자일 프로세스는 팀워크,사용자와 협력하여 개발, 변경을 위한 설계, 짧은 주기의 반복으로 빠른 속도로 개발하고 자주 출시한다는 면을 강조한다. 애자일

프로세스는 새로운 가치와 원리 , 최적 방법을 제시하고 있는데 이로써 폭포수 프로세스의 단점을 해결하고 있다.

애자일 프로세스는 네 가지 가치를 철학으로 담고 있다.

1. 절차와 도구보다 개인과 소통을 중요시 한다.

2. 잘 쓴 문서보다는 실행되는 소프트웨어 더 가치를 둔다.

3. 계약 절충보다는 고객 협력을 더 중요하게 여긴다.

4. 계획을 따라 하는 것보다 변경에 잘 대응하는 것을 중요하게 여긴다.

​

애자일 프로세스에서는 개발팀이 중요한 결정을 내리는 권한이 가진다. 프로세스나 도구보다는 개발자나 팀의 협력이 더 중요하기 떄문이다. 팀 멤버들은 책임과 권한을 가지고 서로 긴밀히 협력한다.

애자일 프로세스는 다음 방복 주기로 넘어가기 전에 각 기능을 완성한다. 즉 각 기능은 다음 반복 주기로 넘어가기 전에 100%

구현되고 테스트된다. 이렇게 될 수 있는 이유는 각 기능에 대한 테스팅이 개발이 완료되기 전에 준비되기 떄문이다. 이를 테스트 중심 개발이라 한다.

​

2.4.1 관리 프로세스

​

프로젝트 관리 프로세스는 비용과 품질 목표를 달성하기 위하여 프로젝트 관리하는 데 필요한 모든 작업을 말한다.

관리 프로세스의 작업은 세 가지 단계로 크게 그루핑된다. 계획 , 모니터링과 제어 , 분석이다.

계획 단계의 주된 작업은 비용과 일정 예측, 중간 점검에 대한 결정이다.

프로젝트 모니터링과 제어는 개발 프로세스의 모든 단계를 포함하므로 가장 긴 기간 동안 이루어진다. 개발하는 동안 수행하는 모든 작업이 프로젝트의 목접에 부합되며 개발이 계획대로 진척되는지 확인하고 컨트롤 하는 작업들이다. 비용 , 일정 , 품질이 중요한

요소이므로 작업의 대부분은 이런 것에 영향을 주는 요인들을 모니터링 한다.

​

​

2.4.2 품질 보증 프로세스

​

품질 보증 프로세스의 목적은 소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 것이다.

소프트웨어 개발 과정이 올바로 되어 있는지 확인하고 개선하는 작업을 프로세스 관리 프로세스라 부른다.

또 다른 품질 보증 작업은 주로 결과물의 검토로 이루어진 인스펙션 프로세스가 있다.

​

1. 인스펙션 프로세스

​

인스펙션 프로세스의 주목적은 개발 결과에서 결함을 찾거나 방지하기 위한 노력이 여기에 해당된다.

인스펙션은 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것이다.

인스펙션 특성

- 인스펙션은 전문 기술 인력이 담당한다.

- 참석자의 역할이 정해진 프로세스이다.

- 해결 방법이 아니라 문제 자체에 집중한다.

- 검토 자료는 기록되며 인스펙션작업의 효울성을 모니터링 하는 데 사용한다.

​

2. 프로세스 관리 프로세스

프로세스 관리는 프로젝트 관리와 큰 차이가 있다는 점을 기억하여야한다. 프로세스 관리의 초점은 프로세스를 개선하여 생성된 결과의 품질과 생산성을 향상시키는 것 . 반면 프로젝트의 관리 초점은 프로젝트를 수행하여 프로젝트의 목적을 달성하는 것

​

2.4.3 형상 관리 프로세스

​

형상 관리는 개발 중에 발생하는 변경을 체계적으로 컨트롤하는 것이다.

소프트웨어 형상 관리는 개발 작업과 독립적인 작업이다.

​

1. 형상 관리 기능

- 프로그램의 최신 버전 유지

- 지정된 버전으로 되돌아 갈 수 있는 기능

- 무허가 변경이나 삭제를 방지

- 현 시스템에 대한 모든 정보, 문서 등의 정보를 모오 보관

​

2. 형상 관리 메커니즘

형상 관리의 주목적은 프로젝트에서 변경이 발생되었을 때 처리하는 시나리오를 다루는 메커니즘을 제공하는 것이다.

일반적으로 다음과 같은 메커니즘이 제공되어야 한다.

- 형상 관리 대상 파악과 베이스라인 지정

- 버전 관리

- 접근 제어

​

​

추가적인 내용 (수업내용)

   Sw 개발 - 출시 - 반응 - 변경 -모니터링

​

변경에 대한 요구 - 변경 요구서 - 형상관리 위원회 - 변경 요구사항 구현 - 시스템 구현 출시

​

​

2.5 방법론

​

방법론이란 소프트웨어 프로세스의 각 작업을 어떻게 수행하느냐를 정의한 것이다.

방법론은 각 단계와 입력 자료 및 산출물, 이들의 표현 방법까지 명시한다.

방법론에서 제공하는 산출물의 표현 방법은 패러다임,즉 소프트웨어를 보는 관점에 따라 다르다.

따라서 객체지향 분석 설계는 객체를 기반으로 모델링 한다. 이런 의미에서 방법론은 패러다임에 의하여 좌우된다. 결국 방법론은 프로세스가 구체적으로 구현된 것이며 소프트웨어 프로세스는 하나 이상의 방법론으로 구현될 수 있다.

​

​

2.5.1 구조적 방법론

​

구조적 분석은 실세계의 문제를 처리라는 관점으로 모델링한다.

모델링은 그래프의 일종인 자료 흐름도를 사용한다.

​

​

존재하지 않는 이미지입니다.

​

​

구조적 분석에는 복잡한 문제를 쉽게 다루기 위하여 분할과 정복 원리를 적용한다.

맨 처음에는 시스템 전체를 하나의 프로세스로 보고 최상위 레벨의 DFD(이를 배경도라함)를 그린다. 복잡한 프로세스가 있다면 더 단순한 프로세스로 계속 분할하여 나간다. 계층의 말단 프로세스를 쉽게 구현할 수 있을 때까지 이런 작업을 반복하는 것이다. 또한 말단의 업무 프로세스만이 아니라 새로 제안하는 프로세스도 나타낼 수 있다.

구조적 설계는 자료 흐름도를 구조도로 변경하는 과정이다. 구조도는 모듈사이의 관계를 나타내는 그래프로 각 노드는 모듈을 나타내며 간선은 상위층의 모듈이 서브루틴을 함수로 호출하는 의미이다.

​

​

2.5.2 객체지향 방법론

​

​

객체지향 방법론은 실세계를 객체라는 눈으로 보고 객체 사이의 인터랙션을 모델링하는 방법이다. 즉 자료와 함수를 가까운 곳에 정의하여 객체로 묶어 두고 객체 사이에 메시지를 호출하여 원하는 기능을 담당하게 하는 것이다.

함수를 시스템 전체에 걸쳐 흩어지도록 하는 것보다 한 곳, 클래스 안에 모아두는 것이 시스템을 단순하게 한다. 즉 객체지향 방법론은 복잡한 대규모 시스템을 클래스로 모듈화 하고 캡슐화 할 수 있는 좋은 방법으로 여기게 되었다.

결국 객체지향 패러다임은 주어진 작업을 수행하기 위하여 협력하는 객체들의 모임이 바로 시스템이라는 관점이다.

​

존재하지 않는 이미지입니다.

​

​

객체지향 프로그래밍이 널리 알려지면서 다양한 방법론이 나왔는데 그 중에 세 가지,

OMT( Object Modeling Technique), Booch 방법론, 유스 케이스 접근법이 널리 알려졌다.

여러 소프트웨어 개발기관이 이런 전통적인 객체지향 방법론을 사용하여 객체지향 패러다임의 부흥을 가져오게 함. 하지만 서로 다른 방법론을 이용하여 개발된 시스템을 통합하고 유지 보수하는 것은 매우 불편하고 비효율적이다. 또한 다양한 방법론을 제공하는 서로 다른 도구들을 제공하는 것도 매우 비용이 많이 든다.이런 문제들이 통합된 방법을 요구하게 되엇고 이것이 UML

(Unified Modeling Language)와 Up(Unified Process)의 탄생 동기이다.

​

​

​

2.5.3 애자일 방법론

​

애자일 방법은 진화적 모델이나 나선형 모델처럼 반복적이고 점증적인 프로세스를 채택하고 있다. 애자일 프로세스는 2.3.7에 소개한 것 처럼 짧은 반복 주기를 반복하며 점증적으로 자주 출시한다. 반복 주기 안에서 각 단계에 대한 이름은 다르지만 요구 분석, 설계, 구현, 통합, 테스팅, 설치 작업까지 거치게 된다.

하지만 전통적인 프로세스와 다른 점은 완벽한 문서 작성보다는 실행되는 소프트웨어에 더 가치를 둔다는 것이다. 이는 요구 분석과 설계 단계에 그렇게 많은 모델링을 하지 않는다는 의미이다.

​

이 절에서는 많이 사용 되는 애자일 방법론 세 가지 , 익스트림 프로그래밍 , 스크럼 , 기능 중심 개발 이 있다.

​

익스트림 프로그래밍 - 익스트림 프로그래밍(XP)은 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 애자일 방법이다. XP를 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어 올리는 것이다. 예를 들어 시스템을 자주 통합하고 빌드하는 것이 좋다면 XP에서는 매일 빌드하는 것을 원칙으로 삼고 있다.

스크럼- 스크럼은 소프트웨어 개발팀이 개발을 연습하고 능력을 향상시킬 수 있는 프레임워크이다. 스크럼은 럭비의 스크럼을 짜듯이 소프트웨어 개발자들의 팀구성, 팀구성원의 역할 , 시간의 틀 , 결과물 , 스크럼 규칙으로 구성된다. 스크럼은 예측을 정확하게 할 수 있고 위험을 관리 할수 있는 반복적이며 점증적인 접근 방법이다.

기능 중심 개발- 기능 중심 개발 방법은 여섯 단계로 구성된다. 처음 세 단계는 한 번만, 나중 세 단계는 반복되는 과정이다. FDD방법은 목표지향적인 시스템에 적합하다.

전체 모델 개발 - 기능 리스트 구축 - 기능 단위의 계획 - 기능 단위의 설계 , 구축 , 설치

 

[출처] Chapter2 소프트웨어 공학 (프로세스와방법론)|작성자 yucheol2