반응형
KMooc에 공개 되어 있는 '쉽게 배우는 소프트웨어 공학' 강의 내용을 정리한 것입니다.(강의: 공주대학교 컴퓨터공학부 김치수 교수)
또한, https://terms.naver.com/list.nhn?cid=58528&categoryId=58528를 확인하시면, '쉽게 배우는 소프트웨어 공학' 책 또한 공개되어있으니 참고하여주시면 감사하겠습니다.
소프트웨어 개발 프로세스
- 소프트웨어 개발 프로세스 모델의 이해
- 주머구구식 모델
- 선형 순차적 모델
- V모델
- 진화적 프로세스 모델
- 나선형 모델
- 단계적 개발 모델
- 통합 프로세스 모델
- 애자일 프로세스 모델
1.소프트웨어 개발 프로세스 모델의 이해
- 일상 : 일을 처리하는 과정 또는 순서 (ex : 요리사가 맛있는 요리를 만드는 과정 레시피)
- 소프트웨어 : 일상에서의 상황과 동일!
프로세스 정의
- 목적 : 문제해결
- 프로세스 : 정해진 순서대로 수행되는 일련의 절차
2.소프트웨어 프로세스 모델의 이해
소프트웨어 개발 프로세스(1)
- 작업(task)순서의 집합 + 제약조건(일정, 예산, 자원)을 포함하는 일련의 활동(activety)
task : sw를 개발할 때 일을 수행하는 작은 단위
- 직접 코딩하는 단위까지를 포함
좁은 의미 소프트웨어 개발 프로세스
- sw제품을 개발할 때 필요한 절차, 과정, 구조
- 사용자의 요구사항을 sw시스템으로 구현하기 위한 일려느이 활동
넓은 의미 소프트웨어 개발 프로세스
- 방법, 도구, 참여자까지 모두 포함
- sw개발 목적을 이루는데 필요한 통합적 수단
소프트웨어 개발 프로세스(2)
프로세스 목적
- 이전에 얻은 노하우를 통해 시행착오 감소 및 빠른 적응을 하여, 생산성이 높고 품질이 높은 소프트웨어를 만들기 위함
- 즉, 가이드의 역할
소프트웨어 삼요소 : 절차와 방법, 도구, 참여인력
소프트웨어 개발 과정
- 작은 규모의 소프트웨어 개발 과정 : 개집 짓는 일에 비유. 적은 장비에 고려사항 적음.
- 대규모의 소프트웨어 개발과정 : 빌딩 짓는 일에 비유. 대규모 장비 고려사항 많음.
3.주먹구구식 모델
주먹구구식 모델(like 개집 짓는 방식)
- build and fix 모델, code and fix모델, 즉흥적 소프트웨어 개발 모델
- 공식적인 가이드 라인이나 프로세스가 없는 개발 방식
- 요구 분석 명세서나 설계 단계 없이 간단한 기능만을 정히하여 개발하는 형태
- 일단 코드를 작성하여 제품을 만들어본 후에 요구 분석, 설계, 유지보수에 대해 생각
모델로 보기 힘듦
개발단계
- 1.첫번째 버전의 코드를 작성하여 제품 완성. 설계 분석 과정 없음.
- 2.작성된 코드에 문제점이 있으면 수정하여 해결
- 3.문제가 없으면 사용
사용
- 개발자 한명이 단시간에 마칠 수 있는 경우
- 대학 수업의 한 학기용 프로젝트 정도
단점
- 문서화된 산출물이 없음 -> 관리 및 유지보수 어려움
- 프로젝트 전체 범위 할 수 없음 -> 좋은 아키텍처 만들 수 없음
- 일을 효과적으로 나눠 개발할 수 없음 -> 진척 상황 파악 불가
- 계속된 수정으로 프로그램 구조 나빠짐 -> 수정이 매우 어려워짐
4.선형 순차적모델
선형 순차적 모델
Linear sequential 모델, Waterfall 모델, Classic life cycle - Waterfall 모델 개발 절차
- 문서 중심의 모델
장점
- 절차가 간결
- 이해가 쉽다 -> 일상적인 프로세스와 유사하여 이해하기가 쉽다는 의미
- 단계별 진척 사항에 대한 관리가 용이. -> 단계별로 명확하기 때문
- 문서화를 체계적으로 할 수 있다.(장점이자 단점)
- 유사한 분야의 소프트웨어 개발 경험이 많으면 우수한 결과 가능
적합한 프로젝트
- 초기에 어느정도 요구사항이 확정된 형태의 프로젝트
- 요구 사항의 변동이 없는 형태의 프로젝트
단점
- 각 단계는 앞 단계가 완료되어야 수행 가능 -> 사용자 요구 사항이 바뀔 경우 반영이 어려움
- 작성된 셜과물이 완벽한 수준이어야 다음 단계에 오류를 넘겨 주지 않음
- 사용자가 중간에 가시적인 결과를 볼 수 없어 답답함
5.V 모델
V 모델
- 폭포수 모델의 변형
- Waterfall model + test 단계 추가 확장
각 개발 단계를 검증하는 데 초점 (vs 폭포수 모델 : 문서, 산출물 중심)
단위 테스트(unit test, module test)
- 개별 module 검증
- 시스템을 구성하는 모듈(함수, 서브루틴, 컴포넌트 등)이 기능을 올바르게 수행하는지 판별
- 내부에 존재하는 논리적인 오류를 검출
- 사용자 요구사항의 내용대로 정확히 구현되었는가를 집중적으로 확인
통합 테스트 (integration test)
- module간의 interface 확인: unit test를 마친 각 module을 통합하는 과정에서 발생 할 수 있는 오류를 찾음
- module사이의 interface 오류
- module사이의 상호작용의 적절한 수행 여부
- module이 올바르게 연계되어 동작하고 있는지
- module 상호간 결합이 잘 되었는지 확인(O), 통합 후의 결과가 정확한지 검증(X)
시스템 테스트(system test)
- 모든 module이 통합된 후 사용자의 요구사항을 만족하는지 확인
- (unit test : 개별 module 검증)
- (integration test : module 간 상화작용을 확인)
- (system test: 전체가 정상적으로 작동하는지 확인)
인수테스트(acceptance test)
- 시스템이 예상대로 동작하고 요구사항에 부합하는지 확인
- (unit test : 개별 module 검증)
- (integration test : module 간 상화작용을 확인)
- (system test: 전체가 정상적으로 작동하는지 확인)
- (acceptance test: 시스템을 사용자에게 인수하기 전 사용자가 요구분석명세서에 명시된 사항을 모두 충족하는지 테스트)
소프트웨어 프로세스 모델의 요약
소프트웨어 프로세스 모델(1)
- SW process model = SDLC(Software Development Life Cycle)
- SW를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념
- 개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다룸
- 순차적인 단계로 이루어짐
목적
- 고품질 SW, 생산성 향상
- 방법 : 1.공장에서 제품을 생산하듯이 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의. 2.주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
역할
- 프로젝트에 대한 전체적인 기본골격을 세워준다.
- 일정계획을 수립할 수 있다.
- 개발 지용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있다.
- 참여자간 의사소통의 기준을 정할 수 있다.
- 용어의 표준화를 가능케 할 수 있다.
- 개발 진행 상황을 명확히 파악할 수 있다.
- 각 단계별로 생성되는 문서를 포함한 샅출물을 활용하여 검토할 수 있게 해준다.
6.진화적 프로세스 모델
진화적 프로세스모델(evolutionary process model)
등장 배경(목적)
- linear sequential model의 대표: waterfall model
- evolutionary process model의 대표: prototype model
- waterfall model단점 : 단계를 거슬러 올라가 작업하는 것이 쉽지 않은 구조
- 현실 : 새로운 요구가 수시로 발생
- 해결안 : 민첩 대응 방법 필요 -> evolutionary process model
특징
- 1.개발자 : 초기 사용자 요구에 따른 prototype 개발(I/O(입력/출력)화면 중심)
- 2.사용자 : UI 중심의 화면과 실행 후 가상 결과 화면 확인. prototype 확인 후 요구사항 추가 및 변경
- 3.개발자 : 사용자 요구 사항을 반영한 2차 prototype 개발
- 1~3 반복!
- 전체 흐름: warterfall model, 요구사항 분석: prototype
- 목적 : 사용자의 요구를 충분히 반영 위함!
장점
- 반복적인 추가 수정 요구가 즉시 반영
- 완성 제품을 대폭 수정해야 하는 대형사고를 막을 수 있다.
- prototype을 고객과의 의사소통 도구로 활용 가능
- 사용자가 만족하는 최종 완제품을 만들 수 있다.
prototype(like 모델하우스)
- 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형
- 소프트웨어에서의 prototype :
- 1.정식 절차에 따라 완전한 소프트웨어를 만들기 전
- 2.사용자의 요구를 받아 일단 모형 제작
- 3.이 모형을 사용자와 의사소통하는 도구로 활용
prototype방법
- modeling : model을 만드는 것
- prototyping : prototype을 만드는 것
- prototype 방법 : prototype을 이용해 최종 요구를 반영한 완성품을 만드는 개발 방식
활용 프로젝트
- 사용자의 요구가 불투명, 요구사항 변화가 계속 발생 시 적합
- 비용이 많이 필요한 변화가 많은 개발에 적합
- 새로운 혁신 기술을 사용할 경우 개발 전, 실현 가능성 타진에 적합
분류: 최종 프로토타입을 어떻게 활용하는지 여부로 나눔
- 실험적(experimental) 프로토타입 모델 : 최종 prototype을 버리고 처음 부터 새로 SW개발
- 진화적(evolutionary) 프로토타입 모델 : 최종 prototype을 버리지 않고 지속적 발전시켜 개발
실험적(experimental) 프로토타입 모델
- 목적 : 사용자의 요구사항을 반복적으로 반영하여 최종 프로토 타입을 만긂
- 용도 : 사용자로부터 충분한 요구사항을 얻기 위한 사용자와의 대화 도구로 활용
- 개발 방식 :
- 1.최종 프로토타입을 통해 결정된 사용자의 요구를 가지고 처음부터 본격적으로 제품 개발
- 2.최종 프로토타입은 더이상 쓸모가 없음
- 3.like 모델하우스
- 모델 절차 :
진화적(evolutionary) 프로토타입 모델
- 목적 : 최종 프로토타입을 버리지 않고 지속적으로 개선, 보완헤 최종 시스템으로 완성
- 실제적으로 적동하지 안흔ㄴ 프로토타입도 만드는 과저에 많은 비요곽 노력 소요
- 모델 절차 :
개발절차
- 1.요구사항 분석 : 1차 개략적인 요구사항 정의 후 n차 바복 -> 최종 프로토타입 개발
- 2.프로토타입 설계: 완전한 설계 대신, 사용자와 대화할 수 있는 수준의 설계. 입출력 화면을 통한 user interface중심 설계
- 3.프로토타입 개발 : 완전히 동작하는 완제품 개발 X. 입력화면을 통한 사용자 요구사항 확인. 출력결과를 통해 사용자가 원하는 거인지 확인. RAD(Rapid Application Development)같은 도구를 이용해 빠르게 실행
- 4.사용자에 의한 프로토타입 평가: (프로토타입 평가 - 추가 및 수정 요구 - 프로토 타입 개발 - 프로토타입 평가 - ... )
- 5.구현 : 최종 프로토 타입 개발
단점
- 반복적인 개발 단계 -> 투입 인력/비용 산정 어려움
- 개발자 입장 -> 프로토타입핑 과정의 관리.통제의 어려움
- 불명확한 개발범위 -> 개발 종료 및 목표의 불명확성
- 프로토타입 제작에 따른 추가 비용 발생 가능
7.나선형 모델 spiral model
나선형 모델 spiral model
spiral model 특성
- 개발과정이 뱅글뱅글 돌아 점점 완성도 높은 제품 만들어짐
spiral model
- evolutionary process model + risk analysis
- 1.계획 및 요구 분석
- 2.위험분석
- 3.1차 프로토타입 개발
- 4.1차 사용자 평가
- 5.1~4 단계 반복(사용자가 만족을 위해
Risk analysis 목적
- 위험 요소 사전 파악 -> 예방 및 제거
개발 절차
1.계획과 요구사항 분석 단계:
- 사용자의 개발의도 파악
- 프로젝트 목표 수립
- 제약 조건 대안 고려 계획 수립
- 기능/비기능 요구사항 정의 분석
2.risk analysis 단계
- 위험요소 발견 및 목록 작성
- 예방대책 논의
- 위험요소 평가 -> 미치는 영향 검토 및 대안 분석
- 심각한 위험이면 프로젝트 계속 진행 여부 결정
소프트웨어 개발시 위험 요소
위험요소 위험내용 개발자의 이직 프로젝트 수행중 개발자의 이직 요구사항 변경 요구사항 확정이후 계속되는 변경 요구 발주사의 재정적 어려움 프로젝트 수행 중 발주사의 경제적 어려움 예상을 빗나간 투입 인력 처음 예측한 인력보다 더 많은 인력 필요 개발 기간의 부족 처음 예측한 개발기간을 초과한 경우 개발지의 초과 처움에 예측한 개발비로 완료할 수 없는 경우
- 3.엔지니어링 단계 : 코딩 단계와 동일
- 4.user evaluation단계
- 프로토타입 평가 -> 추가 및 수정 요구 -> 프로토타입 개발 -> 프로토타입 평가 -> ...
8.단계적 개발 모델
단계적 개발 모델
- 정의
- 개발과 사용을 병행하는 과정을 반복하여 진행하면서 완료
- release 구성 방법에 따른 분류
- 점증적 개발 방법
- 반복적 개발 방법
점증적 개발방법: 개발 범위 증가(like 양식 코스)
- 전체 파이가 n개로 나눌 수 있을 때 개발 시 1번 부분 먼저 개발하고 그 다음에 2번 그다음에 3번 이런식으로 개발하는것
- 예 : 에피타이저 -> 메인디쉬 -> 디저트. 3층 건물 개발 : 1층 먼저 개발. 그다음 2층 개발, 2층 개발 완료 후 3층 개발 이렇게 진행
특징
- 개발 범위의 증가
- SW 개발에서 점증적 방법 : 중요 부분부터 차례로 개발 한 후 그 일부를 사용하면 서 개발 범위를 점차 늘려가는 방식
단계적 개발 방법 순서
- 전체 시스템을 독립성 높은 sub-system으로 분할
- 각 sub-system을 단계적으로 하나씩 release하여 완성
- 장점: 사용자 측
- 한번에 목돈이 안들감
- 완전히 새로운 시스템 전체를 한거번에 주었을 때 조직이 받는 충격을 완화시킴
- 조직에 자연스런 변화를 줄 수 있음
장점 : 개발자 측면
- 이미 사용하고 있는 sub-system이 있어, 어떤 유형으로 개발해야 하는지 잘 알 수 있기에, 사용자에게 원하는 결과를 가져다 줄 수 있음
단점
- 기 개발된 sub-system들과 통합의 어려움
- sub-system들의 유기적 관련성
- 따라서, 처음 설계부터 이후 개발한 sub-system들과 연관성을 고려해야 함.
반복적 개발 방법 : 품질 증가(like 한정식)
- 시스템 전체 개발 후 인도 -> 기능/성능 변경 및 보강
- 예 : 1~10장 원고 작성
- 1.1~10장 대목차 작성
- 2.1~10장 소목차 작성
- 3.소목차 내 주제 설정 ...
- 4.출간
9.통합 프로세스 모델
통합 프로세스 모델
- 최근 SW: 대규모, 복잡함, 빈번한 수정 요구사항 -> 유연한 대처 방법 필요
- waterfall model : 빈번한 요구 대처의 어려움
- 해결 방안 : 반복적 개발
반복적 개발 방법
unified process model(UP)
- OMG가공개한 UML과 함께 제안되어 통합된 process
- 이후 Rational 사에 의해 RUP라는 이름으로 제품화
- 현재는 Rational사가 IBM사에 통합
OMG(Object Management Group), RUP(Rational Unified Process), UML(Unified Modeling Laguage)
통합프로세스모델
출처 : http://terms.naver.com/entry.nhn?docId=3532885&cid=58528&categoryId=58528
UP 모델 절차
- 1.4단계(inception/elaboration/construction/transition)로 나눔
- 2.각 단계는 여러개의 작은단위(iteration) 으로 나눔
- 3.각 반복 구간(iteration)을 하나씩 개발(개발 - 통합 - 테스트 - 실행). 개발 시 9개 영역의 대부분이 포함됨
4.실행 가능한 산출물 도출 (산출물 : 위험 요소의 제거 여부 판단에 활용)
inception phase
- 사업 타당성 / 비용산정/ 개발 목표/ 프로젝트 계획
elaboration phase
- 분석 및 설계 작업 => 일부코딩 => 단위 테스트
construction phase
- 구현 / 단위 및 통합테스트 / 사용자 설명서 작성
transition phase
- 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일
inception/elaboration/construction/transition 단계의 공통 작업
- 형상관리
반응형