소프트웨어 프로세스 모델
일반적인 소프트웨어 프로세스 모델
- 폭포수 모델
- 기본적인 프로세스 활동으로 명세화, 개발, 검증, 진화 거침
- 개별적인 프로세스 단계로 모델을 나타냄
- 점증적 개발
- 명세화, 개발 및 검증 활동이 서로 중첩되는 접근법
- 연속적인 버전을 통해 시스템 개발(각각의 버전은 이전버전에 기능 추가)
- 통합 및 환경 설정(재사용 지향 소프트웨어 공학)
- 재사용 가능한 컴포넌트나 시스템의 사용가능 여부에 의존하는 접근법
- 사용할 컴포넌트들을 조합하고 하나의 시스템으로 통합하는데 중점
폭포수 모델( = 소프트웨어 생명 주기)
- 대규모 군사 시스템 개발에 사용했던 공학 프로세스 모델 기반
- 계획 주도 프로세스의 한 종료
→ 개발 시작 전 모든 활동에 대한 일정 계획 필요 - 각 단계는 기본적인 소프트웨어 개발 활동을 직접적으로 반영
요구사항 분석 및 정의
- 시스템의 서비스, 제약 조건과 목표를 설정
- 시스템 사용자와 면담 → 설정한 목표는 더 구체화시킨 후 시스템 명세서로 사용
- 시스템 사용자와 면담 → 설정한 목표는 더 구체화시킨 후 시스템 명세서로 사용
시스템/소프트웨어 설계- 전체 시스템 아키텍처 작성
- 요구사항을 하드웨어와 소프트웨어 시스템으로 나누어 할당
- 기본적인 소프트웨어 시스템 추상화와 이들 간의 관계 파악하고 기술화하는 활동 포함
- 전체 시스템 아키텍처 작성
구현 및 단위 테스팅
- 설계 구현프로그램이나 프로그램 단위로 실체화
- 단위 테스팅 수행→ 각각의 프로그램 단위가 명세를 만족하는지 검증
- 단위 테스팅 수행→ 각각의 프로그램 단위가 명세를 만족하는지 검증
통합과 시스템 테스팅- 개별 프로그램 단위나 프로그램을 통합
- 전체 시스템 검사
→ 소프트웨어 요구사항 만족하는지 보증 - 소프트웨어 시스템을 고객에게 전달
- 테스트/검증 후
- 테스트/검증 후
- 전체 시스템 검사
- 개별 프로그램 단위나 프로그램을 통합
운영과 유지보수- 가장 긴 생명 주기 단계
- 시스템 설치 및 사용 단계
- 시스템 서비스 향상하는 것 포함
- 발견 못한 오류 수정
- 시스템 단위 구현 개선
- 새로운 요구사항 발견
폭포수 모델 단점
- 소프트웨어 프로세스는 단순한 선형 모델일 수가 없다.
- 개발은 각 단계가 중첩되며 서로에게 정보를 제공하는 방식으로 이루어짐
(설계 과정에서 요구사항 문제 발생, 코딩 과정에서 설계 문제 발견 등)
- 개발은 각 단계가 중첩되며 서로에게 정보를 제공하는 방식으로 이루어짐
- 이전 단계가 끝나기 전까지는 다음 단계를 시작하지 않음
- 시스템 변경이 필요한 경우, 이전 단계에서 작성한 문서 수정 필요
→ 너무 많은 비용이 발생할 경우 해당 항목을 삭제해야 할 수도 있음
- 시스템 변경이 필요한 경우, 이전 단계에서 작성한 문서 수정 필요
- 요구사항을 급히 확정 지으면 나쁜 구조를 가진 시스템이 나올 수도 있음
- 유지보수 단계에서 프로그램 설계 오류 및 새로운 기능 필요성 발견 가능
- → 문제점을 놓친 채로 프로그램화될 수도 있음
→ 사용자가 원하는 것을 제대로 제공하지 못할 수도 있음
폭포수 모델이 적합한 시스템 유형
- 임베디드 시스템 하드웨어
- 하드웨어와 소프트웨어가 연동해야 함
- 구현까지 소프트웨어 기능에 대한 의사결정 미루기 어려움
- 안전성과 보안 분석 필요한 중대한 시스템
- 소프트웨어 명세와 설계에 대한 분석 필요(안전성과 보안 측면)
- 안정성 관련 문제는 구현 단계에서 수정하는 경우 매우 높은 비용 발생
- 대규모 소프트웨어 시스템의 서브 시스템
- 하드웨어와 소프트웨어에 대해 공통 모델 사용 가능
- 서로 다른 서브시스템을 독립적으로 개발하기 위해 완성된 명세서 필요
점증적 개발
- 시스템과 소프트웨어 제품을 개발하는 데 있어서 가장 일반적인 접근법
- 여러 버전에 거쳐 소프트웨어를 진화시켜 최종 시스템 개발
→ 초기 구현을 개발하고 사용자로부터 피드백을 받아 적용
- 여러 버전에 거쳐 소프트웨어를 진화시켜 최종 시스템 개발
- 변경 사항에 대해 적은 비용으로 쉽게 대처
점증 개발의 장점
- 요구사항 변경 구현의 비용이 줄어듦
- 분석 및 작성해야 하는 문서 양이 폭포수 모델의 경우보다 훨씬 적음
- 분석 및 작성해야 하는 문서 양이 폭포수 모델의 경우보다 훨씬 적음
- 이미 진행된 개발 작업에 대한 고객의 피드백받기 쉬움
- 소프트웨어 시연에 대해 의견을 줄 수 있고, 구현 정도 확인 가능
- 소프트웨어 시연에 대해 의견을 줄 수 있고, 구현 정도 확인 가능
- 소프트웨어를 빠르게 전달하고 배포 가능
- 전체 기능을 제공하진 못해도, 고객이 소프트웨어를 경험하고 사용해 볼 수 있음
점증적 개발의 문제점
- 프로세스가 가시적이지 못함
- 정기적으로 중간 산출물 필요 ← 관리자가 중간 진척도를 확인하기 위함
- 모든 버전을 적용한 문서 작성이 비용 측면에서 비효율적일지도..(시스템을 빨리 개발하는 경우)
- 새로운 증가분이 반영되면서 시스템 구조를 훼손시키는 경향이 있음
- 점점 더 어렵고 많은 비용 필요 ← 새로운 기능 추가 때문에 기존 코드 영향
- 정기적인 리팩토링 필요(애자일 방법론)
- 리팩토링 : 소프트웨어를 개선하고 재구성하는 작업
- 구조적인 품질 저하와 일반적인 코드 망가짐 방지
통합과 환경설정(재사용 지향 소프트웨어 공학)
- 기존 소프트웨어 재사용에 초점을 맞춘 개발 프로세스
→ 재사용 가능한 코드를 찾고, 요구에 맞춰 수정하고, 새로운 코드와 통합 - 재사용 가능한 소프트웨어 컴포넌트와 이 컴포넌트를 조합하기 위한 통합 프레임워크에 기반을 둠
- 특정 환경에서 사용할 수 있도록 설정된 독립적 애플리케이션 시스템
→ 특정 애플리케이션과 사용할 수 있도록 맞춤 작업 필요 - 프레임워크에 통합할 수 있도록 개발한 컴포넌트나 패키지 객체들의 모음(Java Spring framework)
- 서비스 표준에 따라 개발하고, 인터넷을 통해 원격 실행이 가능한 웹 서비스
- 특정 환경에서 사용할 수 있도록 설정된 독립적 애플리케이션 시스템
재사용 지향 소프트웨어 공학의 각 단계
요구사항 명세화- 시스템에 대한 초기 요구사항 제안
- 필수 요구사항, 시스템 기능에 대한 간략한 설명 필요
소프트웨어 발견 및 평가- 필요한 기능을 제공하는 컴포넌트 및 시스템을 찾고 사용이 적절한지 평가
(필수 요구사항 만족하는가? 시스템에 사용하기 적당한가?)
- 필요한 기능을 제공하는 컴포넌트 및 시스템을 찾고 사용이 적절한지 평가
요구사항 정제- 사용 가능한 컴포넌트를 반영하여 요구사항 수정 및 시스템 명세 재정의
- 재사용 컴포넌트와 애플리케이션에 대한 정보 활용
- 수정이 불가능하면, 대안을 찾기 위해 컴포넌트 분석 활동 재개
- 사용 가능한 컴포넌트를 반영하여 요구사항 수정 및 시스템 명세 재정의
애플리케이션 시스템 설정- COTS 시스템을 설정하여 새로운 시스템을 만드는 데 사용
(요구사항을 만족하는 COTS 애플리케이션 시스템을 확보한 경우)
- COTS 시스템을 설정하여 새로운 시스템을 만드는 데 사용
컴포넌트 수정과 통합- 개별적으로 재사용 가능한 컴포넌트를 수정하여 새로운 컴포넌트 개발 및 시스템 개발에 통합
재사용 지향 소프트웨어 공학의 장단점
- 장점
- 비용과 위험 감소 → 개발해야 하는 소프트웨어의 양 감소
- 소프트웨어를 고객에게 더 빨리 전달 가능
- 단점
- 사용자의 진정한 요구사항 만족 어려움 → 요구사항 타협해야 하는 문제 발생
- 소프트웨어 진화에 대한 주도권 상실
← 새로운 버전의 재사용 컴포넌트에 대한 통제권을 개발 조직이 가지지 못한다.