[ 정보처리기사 실기] 요구사항 확인2

소프트웨어 생명주기 : 소프트웨어 제품을 계획할 떄부터 시작하여 운용 유지 보수에 이르기까지 변화의 전 과정, 소프트웨어 생명주기 단계에는 분석, 설계, 구현, 테스트 확인, 유지보수 등 여러단계가 있으며, 이들 단계는 중복되기도 하고 반복 되기도 한다.  일반적으로 사용되는 소프트웨어 생명주기 모형에는 폭포수 모델, 프로토타입 모델, 나선형 모델, 애자일 모델 등이 있다. 

 

1. 폭포수 모델 (워터폴 모델)

- 순차적으로 한단계 한단계를 진행해 나가는 모델

장점 

프로세스가 단순하여 초보자도 쉽게 적용가능

단계별 작업 진행으로 해당 단계의 진척 관리가 쉬움

반드시 각 단계마다 눈에 보이는 성과물이 출력

 

단점 

앞 단계로 되돌아가서 반복하는 작업이 많은 시스템 개발에서는 작업 단계의 변경이 곤란한 경우가 많음 

 처음 단계에서 지나치게 강조하다 보면 코딩이나 테스트 작업이 지연됨

사용자의 요구를 만족하는지 최종적인 성과물이 완성되어야만 판명됨

 

 

2. 프로토 타입 모델(Prototype) 

- 사용자의 요구사항에 따라 프로토타입 제품을 신속히 개발하여 제공한 후 사용자의 피드백을 통해 개선하고 보완해가는 모델( 폭포수 모델 단점 보안)

* 프로토타입 : 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램

요구분석 -> 프로토타입 개발/개선->검토 평가 -> 상세 개발-> 설치 /운영

                                                                   -> 피드백 -> 프로토타입 개발 개선-> 검토 평가 등       

장점

사용자의 참여를 유도하여 정확한 요구 도출이 가능

빠르게 모형을 개발하여 피드백을 통해 시스템 개선에 효율적

 

단점

시제품을 최종 완제품으로 오해가능하여, 기대심리의 유발할 수 있음

시제품 폐기 시 비경제적이며, 시제품 개발에 오랜시간을 소요할 경우 시간이 낭비될 수 있음

 

3. 나선형 모델(Spiral Model)

- 시스템 개발시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

목표설정-> 위험 분석-> 개발과 검증-> 고객 평가 -> 목표설정

 

목표 설정: 고객의 요구사항을 분석하여 프로젝트 각 단계에 대한 특정목표를 수립

위험분석 - 프로젝트 진행시 요구사항을 기반으로 예측된느 위험 사항에 대해 추출하고, 이에 대한 대처 방안을 수립한다.

개발과 검증 - 구축하려는 시스템과 개발 환경에 맞는 개발 모델을 선택하여 개발 절차를 진행하고, 개발 진행 중에는 검증이 이루어진다.

고객평가 - 개발과 테스트가 끝난 내용을 고객이 평가하여, 추가 반복에 대한 여부를 결정한다. 

 

장점 

- 위험관리로 인해 위험성이 큰 프로젝트를 수행할 수 있다.

변경되는 요구사항에 대해 적용이 가능하다

최종 완제품에 대한 고객 만족도와 품질이 높다

 

단점 

프로젝트 기간이 오래걸린다

반복단계가 길어질수록 프로젝트 관리가 어렵다

 

4. 반복 점증적 모델

- 요구사항이나 제품의 일부분만을 개발/반복하여 최종 사용자 요구사항에 부합하는 시스템을 완성해가는 모델

1) 증분형 - 사용자 요구사항의 일부분을 하나씩 구현/ 반복한 후 결합하여 최종 제품을 완성하는 방법론

 

2) 진화형 - 시스템의 프로토타입을 개발하면서 추가 요구사항이나 개선사항을 지속적으로 발전 시켜 최종 완성품을 개발하는 방법론

핵심요구사항 개발 :  분석 -> 설계-> 구현 시험.- > 설치 운영

1단계 진화  분석 -> 설계-> 구현 시험.- > 설치 운영

2단계 진화  분석 -> 설계-> 구현 시험.- > 설치 운영

 

5.,RAD(Rapid Application Development) 모델

: 사용자의 적극적인 참여와 강력한 소프트웨어 개발 도구( CASE  도구)를 이용하여 매우 짧은 주기(60-90일) 로 개발을 진행하는 순차적 모델

*CASE도구 : 소프트웨어 공학에서 사용하는 자동화 도구 개발자의 반복적인 작업량을 줄이도록 해준다.

JRP(Joint Requirement Planning)  -> JAD(Joint Application Development) -> Cut-over  =>  60-90일

 

JRP  :   데이터 모델링, 프로세스 모델링

JAD : 프로토타입 개발/ 수정/보완

Cut-over  : 운영 지침서 작성-> 현업부서로 이전

 

장점 : 요구사항의 완전한 이해와 프로젝트 범위를 명확히 설정한 경우 신속한 개발 가능

단점 : 위험성이 높거나 대규모 프로젝트에는 부적함 , 사용자의 책임감이 낮을 경우 실패 가능성이 높음

 

6. 애자일 모델

- 소프트웨어 개발과정에서 지속적으로 발생하는 변경에 유연하고 기만하게 대응하여 생산성과 품질 향상을 목표로 하는 협력적인 모델

 

애자일 : 민첩한, 기민한이란 의미로 사람 중심(고객소통, 고객 협업)이 되어 개발단계에서 변화에 대한 신속한 대응 

- 급변하는 요구사항에 적합

- 소규모 프로젝트에 적합

- 숙달된 개발자 필요

- 폭포수 모델은 계획 중심

 

애자일 유기적 수평적 조직 구조, 고객 중심 운영 방식, 책임 중심 팀 구성

 

 

애장리 방법론의 종류

스크럼 : 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론, 30일 단위의 짧은 개발기간으로 분리하여 반복적으로 수행하는 스프린트를 중심으로 진행

* 스프린트: 달력기준 1-4주 단위를 바탕으로 반복 개발 주기

 

스크럼 팀 구성원

제품 책임자(개발의뢰자, 사용자) : 제품 기능 목록에 해당하는 제품 백로그를 만들고, 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다. 스프린트에 대한 계획을 수립할 떄 까지 중요한 역할을 하고, 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는 것을 권장

 * 제품 백로그 ㅣ 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록

스프럼 마스터( 개발 팀장) : 문제 해결, 방해요소 제거를 위해 노력하며, 스크럼의 원칙과 가치를 지키면서 개발이 진행이 가능하도록 지원한다

스크럼 팀 : 5-9명으로 구성되며, 하나의 스프린트 동안 구현해야할 기능을 사용자 스토리로 도출하고 구현한다. 문제를 보고하며 완료하기 위해 노력하는 구성원이다. 

 

스크럼 개발 프로세스 

제품 백로그 작성-> 스프린트 계획 회의 -> 스프린트 수행 -> 일일 스크럼 회의 -> 리뷰 ( 검토) - > 회고 

스프린트 계획 : 각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행 항목을 선택

일일 스크럼 (데일리) 매일 15분간 프로젝트 진행상황 공유

스프린트 리뷰 : 스프린트 목표를 달성했는지, 작업 진행과 결과물을 확인하는 회의

스프린트 회고 : 스크럼 마스터가 스프린트 동안 잘된 점, 아쉬웠던 점, 개선할 사항등을 찾기위한 회고를 진행

3가지 산출물 

제품 백로그 

스프린트 백로그 : 하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 테스크로 정의 

소멸차트 : 개발을 완료하기 까지 남은 작업량량을 보여주는 그래프이다. 각 주기별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸다.

\

* 스토리 포인트 : 개발에 소요되는 시간, 복잡도 등을 고려하여 추상적인 개념으로 변환한 단위  배

 

2) 익스트림 프로그래밍(xp) 

 - 고객과 함께 2주정도의 반복 개발로 고객 만족을 강조하고 테스트와 우선 개발을 특징으로 하는 방법론으로 애자일 개발 프로세스 보급에 큰 역할을 하였다.. 5가지 핵심 가치와 팀워크, 관리자, 고객에 초점을 맞춰 각 개발자들이 전체적인 맥락에 질적인 소프트웨어 개발에 전념하도록 한 것이다. 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 추구

xp 의 5가지 핵심가치(개발자와 고객 간 중요가치) : 의사소통, 단순성, 피드백, 용기, 존경

 

3) 린 소프트웨어 개발 방법론

- 도요타의 생산방식을 소프트웨어 개발에 적용한 방법론, 구체적인 개발 프로세스를 정의하지 않고 철학적인 접근 방식을 정의하며, 낭비는 곧 결함이기 때문에 결함을줄이는 것이 좋은 방법이라는 사고방식을 가진다.

 

린의 7가지 원칙

낭비제거 :80프로의 가치를 제공하는 20프로 기능 구현에 모든 초점을 맞추어 집중하고 낭비되는 요소 제거 품질 내재화: 개발 중 검증 단계에 이르러서야 결함을 발견한다면 그 프로세스는 결함이 있는 것이다

- 내재 : 어떤 현상이나 성질 따위가 일정한 사물이나 범위의 안에 들어있음 

지식 창출 :  과학적 방법 사용, 모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되, 누구든지 표준에 도전하고 변경하도록 장려

- 늦은 확정 : 마지막까지 변화를 수용할 수 있도록 코드 작성

빠른인도 : 신속한 배포, 고품질, 저비용은 동시에 가능하다

-사람 존중 : 효과적인 리더십 제공하고 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다.

전체 최적화: 고객요구에서  sw 배포까지 전체 가치 흐름에 초점을 맞추러ㅏ 

 

고객의 요구사항 변화에 유연하게 대응하기 위해 일정한 주기를 반복하면서 개발하는 방법론, 워터폴에 대비되는 방법론으로 최근 회사에서 각광받는 방법론 = > 애자일 방법론