내가 공부하기 위한 공간 - [소프트웨어공학] 2 - 프로세스, 방법론

[개념]

프로세스 : 소프트웨어 개발 공정, 구체적인 작업 흐름

프로세스 매핑 : 프로세스를 시각적으로 표현

방법론 : 어떤 순서, 어떤 방법으로 작업을 하는가

+관리 프로세스 : 계획, 모니터링, 분석, 조절

 

왜?

• 사용자 만족도 X
• 수정 반복 > 독립성이 낮아지고 응집력이 높아짐 > 구조 나빠짐, 재사용성 X
• 비용, 일정 조절 X
• 품질 저하

+수정 = 추가/제거, 오류 수정 = 디버깅

 

<정의>

목적 : 프로세스의 목적, 기대되는 성과

작업방법 : 해야 할 작업

성과 : 구체적인 작업 결과 기술

+타임라인

진입조건 : 작업 시작 전 만족해야 할 조건

출구조건 : 작업 종료를 위해 만족해야 할 조건

+검증, 상태정보

 

 

[프로세스 모델]

정의 : 프로세스를 추상적으로 기술, 알맞은 프로세스 개발을 위한 도구

 

-최초-

폭포수 : 중간 테스팅X, 사이클X

계획 > 요구분석 > 설계 > 구현 > 테스팅 > 유지보수

 

-결함을 미리 발견하자-

V : 사이클X

요구분석 <> 인수테스팅

⬇                       ⬆

시스템설계 <> 시스템테스팅

⬇                       ⬆

상세설계 <> 통합테스팅

⬇                       ⬆

코딩 <> 단위테스팅

 

-변경도 가능하게 하자-

프로토타이핑 : 사이클O(구현 전)

요구분석 > 프로토타입 개발/개선 > 프로토타입 테스팅 > 구현 > 유지보수

⬆                         ⬆                     ⬇

  ⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅⬅

+설계단계 없음 : 프로토타입 개발/개선때 완성했다고 봄

+요구분석 조차 없는 새로운걸 개발할 때 사용

+단점 : 사용자와의 오해 유발(기대심리), 중간산출물=정의난해=관리어려움

 

-여러번 사이클을 돌자-

점증적 모델 : 완성된 요구분석으로 완성된 기능 1개씩 추가

• 요구에 대한 가변성 낮음
• 각 사이클을 릴리즈로 구분

진화적 모델 : 완성되지 않아도 모든 기능들을 만들고, 요구분석과 함께 기능들을 강화

• 요구에 대한 가변성 높음
• 각 사이클을 버전으로 구분

 

-위험분석을 하자-

나선형 : 폭포수 + 위험분석 + 사이클

목표, 방법, 제약조건 결정 > 위험분석, 해결 > 개발, 평가 > 다음 단계 계획

+위험부담이 클때, 요구사항 이해 어려울때, 근본적 기술/성능 문제가 있을때

+단점 : 초기 잘못된 위험분석은 실패로 이어짐

 

-재사용하자-

컴포넌트 기반 모델 : 재사용한 컴포넌트로 구성 후 조립하는 개념

타입 : 상용 SW, 객체, 웹 서비스

+단점 : 사용자 요구에 완전 일치 X

 

-다 때려박아-

Unified Process : 통합 프로세스 모델, 유즈케이스를 식별 후 활용

+유즈케이스 중심, 아키텍쳐 중심

4단계

1. Inception (개념 단계) - 1,2회 반복

• 프로젝트의 목표와 범위를 정의

• 간단한 유즈케이스 모델, 소프트웨어 구조 작성

• 프로젝트 설계, 프로젝트의 기본적인 타당성을 검토

2. Elaboration (정교화 단계) - 여러 반복

• 시스템의 아키텍처(Architecture)와 핵심 기능을 설계

• 주요 리스크를 식별하고 해결

• 유즈케이스 설계, 구현

3. Construction (구축 단계)

• 유즈케이스를 구현, 시스템에 통합

• 목표 환경에 점증적으로 설치

4. Transition (전환 단계)

• 개발된 소프트웨어를 실제 운영 환경에 배포

• 사용자 교육 및 유지보수 계획 수립

• 최종 제품의 안정성과 품질을 검증

 

UP는 개발 프로세스를 여러 가지 작업 흐름(Workflows)으로 나누어 관리

주요 작업 흐름

• 비즈니스 모델링 (Business Modeling)

• 요구사항 분석 (Requirements)

• 설계 (Design)

• 구현 (Implementation)

• 테스트 (Testing)

• 배포 (Deployment)

→ 이 모든 과정이 각 단계에서 반복적으로 수행

+단점 : 복잡하여 이해 어려움, 의사소통 가이드 없음

 

 

[애자일] - 더 빨리 제공해야해!

정의 : 피드백을 받고 짧은 사이클(2~6주, 스프린트)을 반복 > 점진적 완성

<애자일 선언>

1. 문서 < 커뮤니케이션으로 목표 달성
2. 문서 < 소프트웨어로 요구 확인
3. 요구가 중간에 따라 바뀔 수 있다는 것을 고려
4. 각 주기의 반성의견을 다음 계획에 포함

<특징> - 설계<코딩중심

1. 짧은 주기 반복
2. 우선순위 - 최소한 기능 실현 > 리스크 최소화
3. 변하는 범위 - 구현 범위 고정 X > 품질, 비용, 마감에 맞춰 기능 변경에 유연
4. 팀 - 분업화 X > 팀으로 모든것을 제안, 수행

 

-소규모, 불확실-

익스트림 프로그래밍 : 상식적이고 경험을 최대한 살린 것

1. 사용자 스토리 - 비즈니스, 우선순위
2. 매일 빌드,통합
3. 테스트 주도 개발 - 테스트 시나리오 먼저 작성 > 요구 기능 명확히, 설계 단순화, 검증비용 고정, 변경에 유연

테스트 시나리오 > 최소한의 코드 > 리팩토링(표준에 맞도록)

1. 페어 프로그래밍 - 수시로 검토 > 품질향상, 문제해결시간 단축

 

-사람에게 중점-

크리스탈 : 프로젝트 특성에 따라 다른 방법론 정의

+6~8명 크리스탈 클리어, 최대 40명의 여러가지 패일리로 제공

1. 대규모 팀/중요한 프로젝트 = 무거운 프로세스
2. 프로세스 간소화 > 최적화 팀
3. 문서 < 커뮤니케이션
4. 다양성 > 일관성있고 엄격한 프로세스 채택 어려움
5. 비공식적인 프로세스를 주도적으로 진행 가능

 

-개발팀이 함께-

스크럼 : 팀원 모두가 소통/협력, 팀역할/이벤트/산출물/규칙의 집합체

• 팀역할 : 프로덕트 오너(요구 정리), 개발(구현), 스크럼 마스터(리더는 아님)

1. 투명성(가시적 프로세스)
2. 점검
3. 적응(바로잡는)

 

• 이벤트 : 스프린트 주기에 진행

1. 계획, 회의 : 무엇을 구현하는지 결정
2. 일일 스크럼 : 팀이 모여 확인
3. 스프린트 리뷰 : 결과물 인스펙션, 프로덕트 백로그 조정
4. 스프린트 회고 : 얻은걸 토대로 다음 스프린트에 반영

 

• 스크럼 산출물

1. 프로덕트 백로그 : 모든 팀원이 남은 작업을 알기 위한 것
2. 스프린트 백로그 : 해야 할 작업의 순서 리스트
3. 작동 SW : 구현된 요구의 총합, 완전체 X, but 배포는 가능
4. 번다운 차트 : 남은 백로그 차트

 

 

[방법론]

구조적 방법론

• 분석 : 문제를 처리
• 모델링 : DFD
• 원리 : 분할과 정복
• 설계 : 흐름도를 구조도로 변경(모듈 사이 구동관계를 나타내기 위해)

 

정보공학 방법론 - 기업 전체 조망, 데이터 통합 극복

• 기업중심
• 전략적 시스템 계획 중심
• 데이터 중심
• 분할과 정복
• 공학적 접근
• 사용자 적극 참여

 

객체지향 방법론 - 객체로 보고 객체 사이의 인터렉션을 모델링

• OMT, Booch 방법론, 유스케이스 접근법
• > 다양한 방법론을 통합, 유지보수, 지원 = 비효율, 비용 > UML, UP