S/W develope process

Process : 일이 처리되는 과정이나 공정.

S/W Process Model

SDLC(S/W Developement Life Cycel)
S/W를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화
개발 계획 수립부터 최종 폐기까지 전 과정

Build and fix Model

장점	단점
단시간에 개발 가능	유지보수 어려움

Waterfall Model

단계별 결과물 정의가 중요
각 단계가 다음 단계 시작 전에 끝나야 함.

장	단
체계적인 문서화	각 단계는 앞 단계가 완료되어야 수행 가능
관리의 용이	설계에 많은 노력을 기울여야함
요구사항의 변화가 적은 프로젝트의 적합	중간에 가시적인 결과를 볼 수 없음.

V model

Waterfall Model에서 각 단계별 테스트를 진행

Prototype Model

정식 절차에 따라 완전한 S/W를 만들기 전에 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사용자와 의사소통 하는 도구로 사용

Waterfall model 범주에 속한 개념.
요구 사항 정의 분석에서 사용자의 Ok가 나오면 바로 waterfall 절차를 따름.

Experimental Prototpye(실험적 프로토타입)

Evolutionary Prototype(진화적 프로토타입)

실험적 프로토타입은 최종제품까지 waterfall을 따르는 것을 의미하고, 진화적은 바로 최종제품으로 연계되는 것을 의미한다. 진화적 프로토타입은 매 개발 단계마다 높은 퀄리티가 요구될 것을 내포한다.

장점	단점
프로토타입이 의사소통 도구로 활용됨	반복적 개발을 통한 투입 인력 및 비용 산정의 어려움
반복된 요구사항 정의를 통해 사용자의 요구가 충분히 반영된 요구 분석 명세서 작성	프로토타이핑 과정에 대한 통제 및 관리의 어려움
초기 프로토타입 사용을 통한 새로운 요구사항 발견	중간 산출물 생성의 어려움
프로토타입 사용을 통한 완성품의 예측 가능	불명확한 개발 범위로 인한 개발 종료 및 목표의 불확실성

절차

요구사항 정의 및 분석

1차 개략적인 요구 사항 정의를 내림
프로토타입 설계

완전한 설계가 아닌, 사용자와 대화할 수 있는 수준의 설계

입출력 화면을 통한 UI 중심 설계
프로토타입 개발

완전히 동작하는 완제품을 개발하는 것이 아닌, 입력 화면을 통한 사용자의 요구 항목 확인 및 출력 결과를 통해 사용자가 원하는 것인지 확인함.
사용자에 의한 프로토타입 평가

평가 → 수정 → 개발 → 평가 → 수정 → 개발 → 평가 ....
최종 프로토타입 개발

진화적이나 실험적에 따라 waterfall model을 할 것인지 혹은 최종제품으로 마무리할 것인지 결정됨.

Spiral Model

진화적 프로토타입 모델 + 위험 분석이 합쳐진 개념

절차

계획 및 초기 요구 분석

프로젝트의 명확한 목표

제약 조건의 대안을 고려한 계획 수립

기능/비기능 요구사항 정의 및 분석
위험 분석 단계

목표와 제약에 대한 대안 평가. 기능 선택의 우선순위 등 위험요소의 분석
개발 단계

파악한 위험 요소를 고려하여 다음 레벨의 프로토타입 개발
사용자 평가 단계

개발 결과의 평가. 다음 사이클을 위한 목표와 계획 검증

고객을 포함한 관련자들과 함께 리뷰
- 실패의 위험을 줄임
- 테스트 용이
- 피드백

장점	단점
사전 위험 분석을 통한 프로젝트 중단 확률 감소	반복적 개발에 의한 프로젝트 기간연장의 가능성
사용자 평가에 의한 개발방식이라, 사용자의 불만 감소	반복 회수의 증가에 따른 프로젝트 관리의 어려움
대규모 시스템 및 위험 부담이 큰 시스템에 적합	위험 전문가가 필요할 정도로 위험관리가 중요

Phased development

요구사항의 일부분, 제품의 일부분만 개발하고 점진적 또는 반복적으로 개발하여 최종적으로 요구사항에 부합하는 시스템을 완성해가는 과정
오늘날 보편적 개발 모델이 갖고 있는 특성

Incremental Model

요구 분석서에 나타난 시스템을 기능별로 여러개의 서브시스템으로 나누고, 일부 기능만을 포함한 서브시스템을 릴리즈하고 난 다음 새로운 기능을 추가해 릴리즈를 하는 방식

Iterative Model

처음부터 시스템 전체 기능을 대상으로 하되 릴리즈 할 때마다 더 완벽히 개발하는 형태, 릴리즈가 발표됨에 따라 같은 기능이지만, 더욱 품질이 향상되도록 개선하는 방법

예시

총 목표는 100장의 도서를 출간하는 것.

Incremental Model

1장을 완벽히 쓰고 릴리즈
2장을 완벽히 쓰고 릴리즈 .. 순서로 진행

Iterative Model

1~100장을 쓰고 1차 릴리즈
1~100장을 더 좋게 쓰고 2차 릴리즈

Incremental Model

장점	단점
몇 가지 기능이 부족하더라도 초기에 사용 교육 가능	고객의 요구를 적절한 크기로 나누는 것이 어려움
자주 릴리즈하기에, 예상하지 못했던 문제에 신속한 대응 가능	분할된 컴포넌트들이 완전히 독립된 컴포넌트로 구현하기 어려울 수 있음
개발팀이 릴리즈마다 다른 전문 영역에 초점을 둘 수 있음	컴포넌트 사이에 정보의 의존관계가 있을 수 있음
규모가 큰 개발 조직은 병행 개발을 통해 개발 기간을 단축시킬 수 있음	증분의 수가 많고 병행 개발이 빈번하면 프로젝트 관리가 어려움

Unified Process Model

sw를 반복적, 점진적으로 개발하는 통합 프로세스 모델

위에서 기재한 점진적 모델을 반복적으로 수행함.

Model 1

Iterative Model이 이에 해당.

Model 2

model 3

절차

도입단계
- 프로젝트의 범위를 설정하고 목표를 정의
- 타당성을 판단
- 시스템과 반응하는 모든 외부 개체와 그들의 상호작용을 식별
- 중요 사용사례(Use case)를 정의해 s/w의 구조와 대략적인 설계 결정
- 앞으로의 일정 및 자원 계획 수립
- 프로젝트 산정(비용, 규모, 일정, 공수)
- 전체 유스케이스의 10% 정도 분석
구체화 단계
- 시스템의 중요한 요구를 찾아내어 기본이 되는 설계를 완성
- 일부 구현, 테스트, 통합 플랫폼 구축
- 아키텍쳐 수립
- 요구 사항의 기능 요소에 대한 문서화
- 도입 단계에서 파악한 요구 사항을 상세하게 분석
- 이 단계가 끝나면 약 80% 정도의 유스케이스가 분석됨
구축 단계
- 남아있는 덜 중요한 부분을 구현하고 설치를 준비
- 만들어진 프로토타입을 기반으로 실행 버전의 sw가 개발됨
- 모든 개발 요소 구현
- 작성된 평가 기준을 사용한 단위 테스트 및 통합 테스트 수행
- 사용자 설명서 및 현재 버전의 설명서 작성
전이 단계
- 사용자에게 릴리즈
- 개발된 모듈에 대해 베타테스트 실시
- 사용자에게 배포 가능한 단위로 묶는 작업 수행
- 사용자 환경에서 사용자가 직접 테스트
- sw 제품 및 사용자 설명서 등을 사용자에게 인도
- 제품 사용자 및 유지보수 담당자에게 교육
도입/구체화/구축/전이 단계의 공통된 작업사항
- 분석, 설계, 구현 테스트 작업을 공통으로 수행하되, 각 단계별로 수행하는 정도에는 차이가 존재
- 각 작업을 반복 수행
- 형상 및 변화 관리, 프로젝트 관리, 환경 점검은 지속적으로 수행

Agile Process Model

애자일은 방법론이 아닌 하나의 문화

애자일 선언문

프로세스와 도구 중심이 아닌, 개개인과의 상호 소통 중시
문서 중심이 아닌, 실행 가능한 소프트웨어 중시
계약과 협상 중심이 아닌, 고객과의 협력 중시
계획 중심이 아닌, 변화에 대한 민첩한 대응 중시

반복적인 개발을 통한 잦은 출시를 목표로 함

개발 > 사용자 확인 > 일부 기능 사용

애자일 기법의 원리

고객 참여

고객은 개발 프로세스 전체에 긴밀하게 참여해야 함. 고객의 새로운 시스템의 요구사항을 파악하여 우선순위를 결정하고, 시스템의 반복을 평가하여함.
점증적 인도

고객이 지정한 요구사항이 포함된 단계를 기반으로 sw가 개발되고 인도됨.
사람은 프로세스가 아님

기 정의된 프로세스를 강요하지 않고, 작업스타일은 다 다름.
변경을 수용

요구사항의 변화를 받아들이고, 변화 수용 가능한 시스템을 설게
단순성의 유지

파일명, 폴더명과 같은 기술적채무를 절대로 남기지 않으며, sw및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거함

문제

고객은 계속하여 프로세스에 참여하기 어려움
다수의 이해관계자가 있다면 우선순위 변경이 어려워짐
다른 외부 개발조직과 협업이 어려움

Agile vs Waterfall

Extreme Programming

가장 유명한 애자일 기법
반본적 개발과 같은 좋은 실무 관행과, 고객 참여를 Extreme까지 극대화
새로운 버전이 하루에도 몇 번씩 빌드가능
매 2주마다 각 점증적 단계가 고객에게 인도
매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정
꼭 필요한 문서만 만듦

XP의 실천사항

⭐ 스크럼 ⭐

팀의 개선과 프로젝트 관리를 위한 애자일 방법론
경험적 관리 기법 중 하나
구체적인 프로세스를 명확하게 제시하지 않음
개발 팀을 운영하는 효율적인 운영 지침

스크럼의 진행 과정

제품 기능 목록 작성
- 요구 사항 목록에 우선순위를 매겨 제품 기능 목록 작성
스프린트 계획 회의
- 스프린트 구현 목록 작성
- 스프린트 개발 시간 추정
스프린트 수행
- 스프린트 개발
- 일일 스크럼 회의
- 스프린트 현황판 변경
- 소멸 차트 표시
스프린트 개발 완료
- 실행 가능한 최종 제품 생산
스프린트 완료 후
- 스프린트 검토 회의
- 스프린트 회고
- 두번째 계획 회의

담당자별 역할

Product owner

제품 기능 목록 작성
비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목을 추가
스프린트 계획 수립 시 까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음

Scrum master

PO를 돕는 조력자
업무를 배분만 하고, 일은 강요하지 않음
스크럼 팀이 스스로 조직하고 관리하도록 지원함
개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원함
개발 과정에 방해될 만한 요소를 찾아 제거함

Scrum Team

팀원은 보통 5~9명으로 구성되며, 사용자 요구 사항을 사용자 스토리로 도출하고 이를 구현함
기능을 작업 단위로 나누고 일정이나 속도를 추정해서 PO에게 전달함
하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연함
매일 스크럼 회의에 참여하여 진척 상황을 점검함

Backlog 예시

사용자 스토리 : 구현할 기능을 사용자 관점에서 전문용어 없이 메모지 한장에 작성한 요구사항

스토리 포인트 : 사용자 스토리를 수행하는데 걸리는 상대적인 개발 기간

제품 기능 목록에 정의된 사용자 관점에서의 기능이며 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것
작은 메모지를 이용해 필요한 것만 짧게 표현 (문서화 아님)
사용자 스토리는 반복을 마치면 사라지지만 유스케이스는 개발 기간 동안 지속되며 유스케이스 보다 당연히 작은 규모를 가짐
사용자와 충분히 대화하여 세부 사항을 구체적으로 서술
테스트를 통해 스토리가 완료된 것을 확인함
다른 스토리에 종속되지 않고, 독립적이며, 협상 가능해야 함
추정 및 측정이 가능해야함
사용자 스토리는 스토리가 큰 것보단 많은 것이 좋음
테스트가 가능해야 좋은 사용자 스토리

소멸 차트

계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 표현

전체적인 스프린트 계획 회의(Spring Backlog)
- 가장 높은 순위 항목에 관심
- 그 배경과 목표에 대해 팀원들과 토의
- 제품 책임자의 의도 파악
세부적인 스프린트 계획 회의
- 우선순위가 높은 항목의 구현 방법에 대한 구체적인 작업 계획을 세움
- 결정된 개발 항목에 대한 스프린트 구현 목록 작성
- 정해진 작업 수행 소요 시간 추정

데일리 스크럼 회의