[정보처리기사 필기] 1과목 정리 - 프로세스 모델

프로세스(Process)

어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성

소프트웨어를 개발하는 과정 == 작업 순서

• 순서제약이 있는 작업의 집합
• 높은 품질과 생산성이 목표

소프트웨어 개발에 대한 기술적, 관리적 이슈를 다루는 작업

• 개발 모델별 컴포넌트 프로세스, 부 프로세스 존재
• 서로 협력하여 전체 목적을 만족

특징

• 단계적인 작업의 틀을 정의한 것
• 무엇을 하는가에 중점
• 결과물의 표현에 대하여 언급 없음
• 각 단계가 다른 방법론으로도 실현 가능함.

개발 중심 프로세스 모델

• 폭포수 모델
• 나선형 모델
• 프로토타이핑 모델
• 진화적 모델
• V 모델
• Unified 프로세스
• 애자일(Agile) 모델

개발 중심 프로세스 모델을 지원하는 프로세스

• 관리 프로세스
• 형상 관리 프로세스
• 품질 관리 프로세스
• 프로세스 관리 프로세스

프로세스 정의

• 작업 결과와 검증 조건을 명확히 정의해야 함
• 작업 방법에 대한 언급 포함
• 진입 조건, 출구 조건

프로세스 정의

바람직한 프로세스

• 예측 가능성
• 테스팅과 유지보수 지원
• 변경 지원
• 결함 제거

프로세스 모델 선택

• 프로세스 모델의 선택은 프로젝트의 상황과 요구에 좌우됨
• 프로세스 모델을 잘 선택하면 소프트웨어 생산성이 높아짐
• 경우에 따라서 최적의 효과를 내기 위하여 모델의 융합이 이루어지기도 함
• 기존 프로세스 모델을 자신의 프로젝트에 맞게 수정해서 적용
• 프로세스 모델은 개발을 도와주는 도구, 그 자체가 목적이 아님
• 최근 프로세스 모델은 반복적인 방식을 채택

폭포수(Waterfall) 모델

특징

• 1970년대 소개 - 항공 방위 소프트웨어 개발 경험을 기반으로 작성
• 각 단계가 다음 단계 시작 전에 끝나야 함
  • 각 단계별로 특정 산출물이 정해짐(Document-driven approach)
  • 순서적 - 각 단계 사이에 중복이나 상호작용이 없음
  • 각 단계의 결과는 다음 단계가 시작 되기 전에 점검
  • 바로 전 단계로 피드백
• 단순하거나 개발자가 응용 분야를 잘 알고 있는 경우 적합
• 결과물 정의가 중요
• Linear Sequence Model이라고도 치함

단계별 산출물

장점

• 프로세스가 단순하여 초보자가 쉽게 적용 가능
• 중간 산출물이 명확하여 프로젝트 관리 용이
• 프로젝트 참여자들이 자신들의 업무를 파악하기 용이
• 코드 개발 전 충분한 검토와 분석 과정 수행 가능

단점

• 계획, 분석, 설계의 처음 단계를 지나치게 강조 시 후반부 단계인 코딩, 테스트가 지연
• 각 단계의 전환에 많은 노력 요구
• 프로세스가 시작 시 사용자 요구사항 변화 등의 외부 환경 변화에 적응하기 상대적으로 어려움
• 프로토타입과 재사용의 기회가 줄어듦, 시스템을 한 번의 계획과 실행으로 완성되기 때문에 각 단계별 산출물에 대한 정비 및 개선의 기회가 없어짐
• 불필요한 문서를 대량 생산할 가능성 있음

적용

• 이미 잘알고 있는 문제(요구 사항이 잘 정의된 경우) 적합
• 요구 사항에 대한 변화가 적은 프로젝트에 적합

프로토타이핑 모델

출처 : https://bootcamp.uxdesign.cc/5-prototyping-approaches-84682d8ff09d

시스템의 일부 혹은 모형을 만드는 과정

Quick and dirty(fast but not done well, 약식으로 간단히) 방식

프로토타입(시범 시스템)의 적용

• 사용자의 요구를 더 정확히 추출
• 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작

프로토타이핑 도구

• 비주얼 프로그래밍, 4세대 언어(PowerBuilder, Delphi) 등

공동의 참조 모델(Reference Model)

• 사용자와 개발자의 의사소통을 도와주는 좋은 매개체

목적

• 단순한 요구 추출 - 제작 후 버림
• 제작 가능성 타진 - 개발 단계에서 유지보수가 이루어짐

장점

• 사용자의 의견 반영이 잘 됨
• 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할 수 있음

단점

• 프로토타입이 시스템의 전부라고 오해할 수 있음
• 완성된 시스템에 대한 기대심리 유발 가능, 프로토타입을 보고 나면 곧 완성된 시스템이 개발 될 것으로 기대
• 관리가 어려움
  • 중간 산출물 정의가 난해
  • 발주자에 대한 참여 계획 작성이 어려움

적용

• 개발 착수 시점에 요구가 불투명할 때(고객이 자세한 요구사항을 모를 경우)
• 실험적으로 실현 가능성을 타진해 보고 싶을 때, 개발자가 알고리즘의 효율성이나 소프트웨어의 편리성에 대해 확신하지 못할 때
• 혁신적인 기술을 사용해 보고 싶을 때

진화적 모델(Evolutionary Model)

한번의 릴리스(Release) 대신 다수의 릴리스를 통해 소프트웨어 개발, increment가 증가할 수록 기능이 추가됨.

요구사항이 분할되고 우선순위가 높은 요구사항이 먼저 개발된 후 릴리스 됨

개발 사이클이 짧은 환경

• 빠른 시간 안에 시장에 출시하여야 이윤에 직결
• 개발 시간을 줄이는 법 - 시스템을 나누어 릴리스

릴리스 구성 방법

• 점증적(Incremental) 방법 - 기능별로 릴리스
• 반복적(Iterative) 방법 - 릴리스 할 때마다 기능의 완성도를 높임

특성

• 초기 increment는 프로토타입 역할을 하여 차후 increment에 대한 요구사항을 유도할 수 있음
• 요구사항 변화를 수용하는 비용 절감
  • 다음 increment에서 요구사항 변화를 수용할 수 있음
• 처음 릴리스되는 소프트웨어는 시작을 빨리 형성 시킬 수 있음
• 자주 릴리스 하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음
• 개발 팀이 릴리스마다 다른 전문 영역에 초점을 둘 수 있음
• 기능이 부족하더라도 초기에 사용 교육 가능
• 프로젝트 실패에 대한 위험을 낮출 수 있음
• 새로운 increment가 추가될 수록 시스템 구조가 나빠질 수 있음

나선형(Spiral) 모델

Boehm이 제안한 점증적 모델의 일종으로 risk-driven process model

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

• 실패의 위험을 줄임
• 테스트 용이
• 피드백

여러 번의 점증적인 릴리스(Incremental Releases)

모델이 제대로 적용하면, Risk가 문제시 되기 전에 줄어들게 됨

주요 단계

• 계획 수립(Planning) : 목표, 기능 선택, 제약 조건의 결정
• 위험 분석(Risk Analysis) : 기능 선택의 우선순위, 위험요소의 분석
• 개발(Engineering) : 선택된 기능의 개발
• 평가(Evaluation) : 개발 결과의 평가

장점

• 대규모 시스템 개발에 적합 - risk reduction mechanism
• 반복적인 개발 및 테스트 - 강인성 향상
• 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

단점

• 관리가 중요
• 위험 분석이 중요
• 적용이 쉽지 않음

적용

• 재정적 또는 기술적으로 위험 부담이 큰 경우
• 요구 사항이나 아키텍처 이해에 어려운 경우

V모델

폭포수 모델의 변형

• 시스템 검증과 테스트 강조
• 폭포수 모델에서는 감추어져 있는 반복과 재 작업을 드러냄
• 작업과 결과의 검증에 초점

검증과 테스트를 강조하므로 오류를 줄일 수 있음

반복 과정이 없어 변경을 다루기가 쉽지 않음

신뢰성이 높이 요구되는 응용 분야에 적용

• 자동차, 항공, 원자력 발전소 제어 등

Unified 프로세스

UML과 관련된 프로세스 모델로 RUP(Rational Unified Process)라고도 함

4단계(Phase) 구성

• 도입(Inception)
  • 최종제품과 프로젝트의 전반적인 범위를 정의하고 관련된 비즈니스 비전 정의
• 정련(Elaboration)
  • 문제 도멘인과 시스템 아키텍처에 대한 이해
  • 산출물을 정제하고 구조를 정의하며 개발 및 배치를 위한 정확한 계획을 수립
• 구축(Construction)
  • 시스템 설계, 프로그래밍, 테스팅 작업
• 전환(Transition)
  • 운영 환경에 시스템 배치
  • 제품 인도, 교육, 지원 및 유지보수 포함

아키텍처 중심, 반복적, 점증적인 모델

장점

• 방법론과 프로세스가 잘 문서화되어 있어 쉽게 접할 수 있어 교육받기 좋음
• 고객의 요구 변경과 관련된 리스크를 적극적으로 해결할 수 있음
• 통합을 위한 노력과 시간을 줄일 수 있고 반복적인 개발 싸이클로 통합하므로 상대적으로 적게듦
• 쉽고 빠르게 코드를 재사용할 수 있음

단점

• 프로세스가 너무 복잡하여 전문가가 아니면 이해하기 어렵고 정확히 적용하기가 어려움
• 소프트웨어 프로젝트 참여자들이 어떻게 협동하고 점증적으로 개발할 것인지 의사 소통하는 자세한 가이드가 없음
• 조직화되지 않은 개발로 완전히 알려지지 않은 형태의 소프트웨어 개발로 이어질 수 있음

애자일(Agile) 프로세스

애자일 선언문에 기초한 프로세스 모델폭포수 모델과 같은 초기 프로세스는 개발 중 고객의 변경 요청을 처리하고 통합하는 데 많은 비용과 시간이 필요함이러한 단점들을 극복하기 위해 프로젝트에 대한 피드백을 빨리 받고 방향을 평가하여 짧은 싸이클을 반복하는 방법중요 가치

• 형식적인 문서보다는 커뮤니케이션을 통하여 프로젝트가 목표를 향하여 나아가게함
• 사용자는 문서가 아니라 실행되는 소프트웨어를 통하여 요구를 확인
• 사용자의 요구는 비즈니스 환경에 따라 프로젝트 중간에 바뀔 수 있다는 것을 고려함
• 짧은 주기 동안 요구정의에서 구현, 테스트까지 이루어지며 각 반복 주기의 반성 의견을 다음 계획에 포함시킴

특성

• Modularity
  • 애자일 프로세스는 모듈화되어 여러 개의 activity로 나눌 수 있음
• Iterative
  • 짧은 사이클 안에서 하나의 activity를 완성시키면서 반복저으로 프로젝트를 수행
• Time-bound
  • 반복 주기를 1~6주 가량으로 정하고 프로세스 진행
• Incremental
• Convergent(수렴성)
  • 주어진 제약사항 범위에서, 프로젝트 수행 시 발생하는 risk에 대해 능동적으로 대처
• People-oriented
• Collaborative

주요 모델로 익스트림 프로그래밍(eXtreme Programming)과 스크럼(Scrum)이 있음

 

애자일(Agile) 프로세스 - 익스트림 프로그래밍(eXtreme Programming, XP)

소규모 개발 조직이 불확실 하고 변경이 많은 요구를 접하였을 때 적절한 애자일 방법

• 사용자 스토리(User Story)
  • 간단한 사용자 스토리 작성
  • 각 기능의 비즈니스 가치와 우선순위를 정한 것
  • 간결한 문장으로 표현한 시스템의 기능, 간단한 기능을 짧은 싸이클로 구현해 나감
• 매일 빌드와 통합
  • 실행되는 시스템을 항상 준비하기 위해, 개발한 것을 매일 빌드하고 통합
• 테스트 주도 개발(Test-Driven Development)
  • 코딩 전 요구사항을 검증하는 테스트 시나리오 작성
  • 테스트 시나리오를 통과하기 위한 최소한의 코드 생성
  • 작성한 코드를 표준에 맞도록 리팩토링함
• 페어 프로그래밍(Pair Programming)
  • 두 명의 프로그래머가 하나의 컴퓨터를 공유하면서 한 사람은 코딩, 다른 한 사람은 확인하면서 개발
  • 둘이 역할을 바꾸면서 구현
  • 프로그램을 수시로 검토하여 품질 상승
  • 짝을 이루면서 프로그램에 대한 지식 공유를 통해 문제 해결 시간 단축 

애자일(Agile) 프로세스 - 스크럼(Scrum)

개발 팀원 모두가 함께 소통하고 협력하여 짧은 주기를 반복하여 소프트웨어를 개발하는 작업, 역할, 결과물의 집합체

계속 변경되는 요구에 잘 적응하는 애자일의 원리를 따름

• 백로그(할일)을 정하고 여기에 우선순위를 부여
• 스프린트(짧은 주기)를 반복하여 출시주기를 단축하며 팀과 사용자가 지속적으로 소통하고 의견을 반영하여 시스템을 향상 시킴

장점

• 다른 프로세스 모델보다 소프트웨어를 빠르게 배포할 수 있어 고객이 그 가치를 얻을 수 있음
  • 최종 결과만 아니라 요구 처리 시간이 적어 즉각적인 피드백을 받을 수 있음
  • 변화에 더 잘 적응하고 빠르게 대응할 수 있음
• 항상 최신 작업을 수행하기 때문에 자원의 낭비가 적음
• 문제와 결함을 더 빨리 감지하고 수정할 수 있음
• 계층적인 관료주의와 불필요한 문서화 등에 시간을 덜 씀, 비용이 저렴하므로 아이디어를 실험하고 테스트 가능

단점

• 문서화가 등하시 되어 새로 들어온 개발자의 속도를 높이기가 더 어려워질 수 있음
• 애자일 모델은 개발자가 고객이 지속적으로 상호작용해야 하므로 모든 사람에게 많은 시간과 에너지를 요구함
• 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속될 수 있음
  • 지정된 예산 또는 일정에 따라 작업하는 고객은 프로젝트의 시;ㄹ제 비용을 알 수 없으므로 결산 주기가 매우 복잡
• UX 및 아키텍처 관점에서 전체적인 디자인이 부족하여 제품을 완성시키기 위한 작업이 더 많이 드는 문제가 발생할 수 있음
  • 제품에 대한 장기적인 비전이 필요함
  • 적극적으로 의사소통하기 위한 노력이 필요함
  • 제품의 응집력이 없음
  • 디자인이 조각화되어 사용하는 방법도 조각화됨
  • 시간이 지날수록 소프트웨어의 연결이 끊어질 수 있음

 

지원 프로세스

개발에 중심이 된 프로세스는 각 단계별로 해야할 작업들 있음.

이러한 작업들을 지원하는 프로세스를 지원 프로세스(우산 프로세스)라고 함

 

지원 프로세스 - 관리 프로세스

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

• 계획
  • 가장 어려운 작업
  • 프로젝트의 목적에 맞는 소프트웨어 개발 계획을 개발하는 것
  • 개발 시작전에 작성하고 개발하면서 변경됨
  • 프로젝트 프로세스에 대한 데이터가 남게됨
  • 비용과 일정 예측, 중간 점검에 대한 결정이 주 작업
  • 가장 중요한 작업, 모니터링과 제어 작업을 위한 기준이 됨
• 모니터링
  • 개발하는 동안 수행하는 모든 작업이 프로젝트의 목적에 부합되며 개발이 계획대로 진척되는지 확인하기 위하여 데이터를 수집함
  • 비용, 일정, 품질이 중요한 요소이므로 작업의 대부분은 이런 것에 영향을 주는 요인들을 모니터링함
• 제어, 분석
  
  • 모니터링에 의하여 확인된 사실을 분석하고 계획과 차이나는 부분에 대하여 조정하고 조치함.

지원 프로세스 - 품질 보증(Quality Assurance,QA) 프로세스

프로세스(Process)와 프로덕트(Product)에 대한 품질 관리 및 향상하는 것을 목적으로 하는 프로세스

인스펙션(Inspection) 프로세스

• 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것
• 개발 결과에서 결함을 찾거나 방지하기 위한 것
  • 결함을 발견하여 작업 결과의 품질을 향상 시키는 것을 기본 목적
  • 적은 비용으로 조기에 결함을 찾아 생산성도 높임
• 특성
  • 인스펙션은 전문 기술 인력이 담당
  • 참석자의 역할이 정해진 프로세스
  • 해결 방법이 아니라 문제 자체에 집중
  • 검토 자료는 기록되며 인스펙션 작업의 효율성을 모니터링 하는 데 사용
• 여러 명이 참여하여 이루어지며 테스팅으로 검사할 수 없는 결과물에 대하여 적용
• 장점
  • 생명 주기 초기에 유입된 결함, 또는 관리 등 기타 프로세스에 의하여 유입된 결함을 결과물 안에서 찾을 수 있음
  • 가성비가 높은 품질보증 작업
• 작업 결과물

 

프로세스 관리 프로세스

• 프로세스를 사용하여 작업한 결과가 높은 품질과 낮은 비용을 가지도록 지속적으로 변경됨
• 품질과 생산성의 향상은 엔지니어링의 기본 목표
• 프로젝트를 수행하여 프로젝트의 목적을 달성하는 것
• 프로젝트 관리 기간은 보통 프로젝트가 수행되는 동안만
  • 각 프로젝트가 진행되는 기간을 초과한 긴 시간 동안 이루어짐
• 각 프로세스의 능률을 정확히 측정하여 더 효과적인 프로세스로 교체하거나 개선해 나감
• 현재 상태를 기반으로 작은 변경을 해나가면서 수정해 나가는 개념이 능력 성숙도 모델(Capability Maturity Model,CMM)로 정리되어 있음

지원 프로세스 - 형상 관리 프로세스

소프트웨어 프로젝트에서는 변경이 지속적으로 일어남

이러한 변경(Changes)을 체계적으로 컨트롤하는 것을 형상 관리(Configuration Management)라고 함

개발 작업과 독립적인 작업

형상 관리 기능

• 프로그램의 최신 버전 유지
• 지정된 버전으로 되돌아 갈 수 있는 기능
• 무허가 변경이나 삭제를 방지
• 현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관

형상 관리 메커니즘

• 프로젝트에서 변경이 발생되었을 때 처리하는 시나리오를 다루는 메커니즘 제공
  • 형상 관리 대상 파악과 베이스라인 지정
  • 버전관리
  • 접근제어