소프트웨어공학#4-ProcessModels

소프트웨어 개발을 위한 여러 가지 경로를 표현하는 방법

소프트웨어 프로세스 모델

소프트웨어 프로세스란?

소프트웨어 제품을 개발, 배포, 설치, 유지관리 하기 위해 따라야 하는 절차

아이디어의 시작부터 시스템의 전달과 최종 폐기까지를 지칭

프로세스의 목표

고객의 기대치를 만족시키기 위함

적시에, 정해진 예산 범위 내에서 배포

고객에게 이익을 주고

신뢰성, 효율성, 예측가능한 제품

소프트웨어 라이프 사이클 모델

요구사항

분석

설계

개발

테스팅

배포

운영 및 유지보수

폐기

왜 프로세스 모델이 중요한가?

Black-Box Procss

제품으로 내기전까지 프로세스 전 과정이 비밀임

최종 제품이 고객의 요구사항에 걸맞지 않을 수 있음
Transparent Process

프로세스를 여러 절차로 나누어서 다음 절차로 넘어가기 전에 고객으로부터 피드백을 받음

시간과 비용이 절약

품질에 결정적 영향을 미침

제품의 필요한 품질을 더 잘 제어할 수 있음

프로세스

무엇을 하는가에 대한 일련의 과정
메인 과정

실현가능성 분석

요구사항 도출, 이해, 명세

소프트웨어 아키텍쳐(상위수준) 및 디테일한 설계(하위수준)

상위수준 설계 : 전반적인 틀 구성

하위수준 설계: 아키텍쳐를 구성하는 컴포넌트, 자료구조 등 디테일한 설계

코딩과 모듈 테스트

통합과 시스템 테스트

배포, 설치, 유지보수

소프트웨어 프로세스 모델이란?

소프트웨어 개발 활동을 어떻게 프로세스 안에서 구성할 건지에 대해 표현한 것

대포적인 모델
1. Build and fix Model
2. Waterfall Model
3. Evolutionary Model

빠른 프로토타입

점진적

Transformation Model

Spiral Model

1. Build and fix Model

개발하고 수정한다. 프로세스 모델이라고 하기에 애매
-> 코딩하고 수정하는 두 가지 일만 반복

주로 혼자하는 작업에 쓰임
명세서없이 구성됨
큰 규모의 제품에는 부적합
오늘날에는 적합하지 않음

2. Waterfall Model

기본적인 모델
소프트웨어 개발의 근간이 되는 모델

폭포수처럼 아래로 가면 다시 위로 못올라간다.
전 단계로 돌아갈 수 없다.
1970년대에 많이 활용

순차적, 단계기반, 문서지향적

단계를 기반으로 하기 때문에 단계적으로 산출물을 작성하게 된다.

해당 단계의 산출물에 오류가 있을 시, 다음 단계로 넘어가지 않는다.

한 단계의 결과가 다음 단계의 input

원칙적, 계획적

제품 구현은 그 목적이 잘 이해될 때까지 미뤄짐

문제점

중간에 피드백을 반영하지 않기 때문에 요구사항이나 변경사항이 발생할 경우 반영하기 힘들다.
다음 단계로 가기 위해서는 최종 확정이 필요한데, 주로 책임자가 맡게 됨에 따라 책임자의 권한이 강력한 과정이 될 수 있다.
-> 책임자에 의존적인 과정

폭포수의 개선 모델이 새로 나오고 있음

피드백을 반영하는 폭포수 모델
전체를 묶음별로 쪼개서 각 묶음 별로 다시 폭포수 모델로 구현하는 모델

3. 진화적 모델

운영 소프트웨어 제품을 확장하는 단계로 구성된 모델

배포하고, 피드백받고, 조정하는 과정 반복
- 유지보수라는 개념이 사라짐

2가지 타입

1. Incremental approach

빌드+피드백을 통합해서 새로운 빌드를 만듦

단계별 개발

미니 폭포수 모델이다. 각 단계에서 폭포수 모델 적용
장점

사용자에게 신제품에 적응할 시간 제공

수용하기 쉽다

단계 단위로 배포된다. 단계 배포에는 큰 자본이 필요하지 않다.
단점

build and fix모델과 비슷해질 수 있다.

통합과 테스팅의 오버헤드 (시간이 많이 소모)

유저가 부분 시스템을 최종시스템으로 오해할 수 있어 재촉을 요구할 수도 있다.

2. Prototyping

딱 두번만 한다.

첫번째 버전

제품의 실현 가능성을 평가하기 위한, 완료 후 폐기할 버전

요구사항 검증하기 위함

두번째 버전

폭포수 모델을 따름

프로토타입은 점차 최종 시스템으로 발전할 수 있음

장점

시간과 비용이 줄음
개발자와 사용자 간의 커뮤니케이션 향상
에러를 초기에 탐지 가능
단점
앞으로 생길 변경의 예측에 대해 생각하지 않는다.

빠른 어플리케이션 개발

어떤 방법이 소프트웨어 시스템을 빠르게 개발하는데 사용될 수 있을까?

사용자가 원하는 걸 빨리빨리 받는 방법

왜 소프트웨어를 빨리 개발해야할까?

마켓을 확장을 위해
사용자들이 원하는 기대가 너무 빨리 변하고, 시대적인 빠른변화를 따라가기 위해 빨리 개발해야함

비즈니스는 요구사항의 변화에 따라 빠르게 운영되며 일련의 안정적인 소프트웨어 요구사항을 생성하는 것은 사실상 불가능
소프트웨어는 변화하는 비즈니스 요구사항을 반영하기 위해 빠르게 발전해야함
명세, 설계, 구현이 오버랩돼서 진행됨
버전의 연속 형태로 개발됨
IDE이나 그래픽 툴을 사용하여 빠르게 개발

Rapid Application Development = Agile Development

4. Agile Development

신뢰성 있는 소프트웨어 개발을 목적으로

1. Agile - XP

요구사항 변화를 다룸
역할과 책임

고객 : 요구사항 & 요구사항의 우선순위 결정
프로그래머 : 분석, 설계, 테스팅, 개발, 통합
매니저 : 프로젝트 진도 체크

추구하는 4가지 가치

커뮤니케이션
단순성 : 전체를 작게 쪼개서 (복잡도 감소)
피드백
용기

12개의 Practice

계획 과정 - 각각의 빌드마다 계획을 세움
작은 단위로 배포
메타포(은어) - 커뮤니케이션과 관련
간단한 설계 - 복잡한 설계X
지속적인 테스팅
리팩토링
페어 프로그래밍 - 한 사람은 코딩, 한 사람은 테스트
일괄코드 소유권 - 모든 사람이 수정 권한 갖음
지속적인 통합
주당 40시간 - 오버타임 할 경우 품질 떨어짐
On-site customer - 고객이 소프트웨어 개발의 멤버처럼 참여
Coding standard - 코딩 규칙 준수 배포 사이클

유저 스토리 선택(사용자의 니즈) -> 테스크라는 작은 단위로 만듦 -> 배포 계획 수립 -> 개발, 통합, 테스트 -> 배포 -> 사용자 평가 -> 다시 유저스토리로 가서 피드백 반영
개발 사이클

코딩->테스트->검토->설계 반복
코딩을 먼저

2. Agile - Scrum(스크럼)

반복적인 개발을 관리하는 데 초점

피드백 중심의 경험적 접근법
모든 작업 결과물을 책임자에게 보여야 함
개발 중인 제품과 팀이 얼마나 잘 일하고 있는지 수시로 점검

전반적인 outline을 계획하는 단계 - 목적과 아키텍쳐 설계

sprint 사이클 - 빌드를 점진적으로 개발

closure 단계 - 마무리 검토

산출물

Produce Backlog
- 스크럼 팀의 순서화된 요구 사항 목록
Sprint Backlog
- 개발 팀의 작업 목록
Product Increment
- 모든 제품 백로그 항목의 합계
Burn-Down Chart
- 다운되어 내려가는 차트
- 현재 남아있는 작업 차트
전체적인 스크럼 과정

5. Transformation Model

요구사항 분석 및 명세 -> Formal 명세서 -> 최적화 -> Lower level 명세서
각 명세서에 오류가 있을 시 검증 단계

formal 명세서에 기반을 둠
스펙이 구현으로 바로 전환
연구 지향적 접근법
프로그램 정확성 증명에 사용

단점

전문적 지식 요구

산업에서 활용 범위 좁음

6. Spiral Model

나선 한 사이클이 한 단계

목적, 대안, 제약사항 이해 -> 대안 평가 & 리스크 식별, 해결 -> 개발 및 검증 -> 리뷰 및 다음 단계 계획

메타모델
- 프로젝트에서 발생할 수 있는 리스크를 즉시 가이드 해줌
높은 리스크를 식별하고 제거하는데 목적을 둔 모델

단점

리스크 분석에 비용이 많이 들어감

적용의 범주가 제한적

대규모 소프트웨어 개발에 적합

7. V Model

각 단계에 대응되는 테스트 단계가 존재한다.
폭포수 모델의 확장

장점

원리, 원칙적, 단계가 끝나야 다음 단계 진행가능

작은 프로젝트에 적합

간단하고, 쉬움

단점

요구사항이 중간에서 높은 변경 위험에 있는 프로젝트에는 부적합

복잡하고 객체지향적 프로젝트에 부적합

8. CBSE 프로세스

요구사항 명세 -> 컴포넌트 분석 -> 요구사항 수정 -> 재사용과 함께 소프트웨어 설계 -> 개발 및 통합 -> 소프트웨어 검증

여기서 재사용은 컴포넌트 분석 단계에서 나온 것이고 재사용 가능한 것은 통합 단계로 가면됨

DevOps = Development + Oprations

IT 및 개발 팀 프로세스 내의 민첩성, 협업 및 자동화에 초점을 맞춘 철학 및 관행

전통적인 소프트웨어 개발

사일로 기반 접근법
팀과 프로세스 내에서 독립적으로 작업
잘못된 커뮤니케이션, 잘못된 정렬 및 생산 지연이 잦은 환경

DevOps의 목표

IT 운영과 개발 간의 격차 해소
커뮤니케이션과 협업 개선
보다 원활한 프로세스, 전략 및 목표 조정
보다 빠르고 효율적인 배포

DevOps란?

지속적인 통합, 배포, 설치

Micro-Service 아키텍쳐

코드기반의 인프라 구조

모니터링 & Logging

장점

빠른 개발과 배포
테스트 자동화
빠르고 쉬운 업그레이드
협업 강화
안전한 프로세스

프로젝트 특성에 따른 SDLC

큰 규모 : Spiral, Incremental, Iterative
많은 리스크 : Protyping, Spiral, Incremental
모호한 요구사항 : Protyping, Incremental, Agile
긴 개발기간 : Spiral, Incremental, Iterative
충분한 예산 : Spiral, Incremental
쉬운 기술 : Waterfall, Agile
높은 정확성 : Protyping, Spiral, Incremental, Agile
고객 참여 : Agile

프로젝트 타입에 따른 SDLC

일반적인 개발 : Waterfall
대규모 재설계 : Incremental
임베디드 시스템 : Incremental
증명 : Protyping, Spiral
연구 & 개발 : Spiral
작은 규모
- 짧은 개발 기간 : Waterfall
- 짧은 개발 기간 and 고객 참여 : RAD(Rapid Application Development)

주요 산출물

프로젝트 계획 : 프로젝트 관리 계획서
요구사항 수집 : 요구사항 정의서
요구사항 분석 : 요구사항 분석서
설계 : 소프트웨어 설계서
구현 : 소스코드
테스팅 : 테스트 계획, 테스트 결과

낡은 소프트웨어 처리

동기

처음부터 새로운 소프트웨어를 개발 할 수 없다.
재 엔지리어링
새로운 형태로 재구성하기 위해 기존 시스템이 대체 과정을 거치는 과정

낡은 소프트웨어를 리팩토링 해서 새로운 소프트웨어와 함께 만듦

Author And Source

이 문제에 관하여(소프트웨어공학#4-ProcessModels), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@shinoung2360/소프트웨어공학4-ProcessModels

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)