SW model 종류와 특징

Software Engineering Models

😀 점증적 개발

특징

• 초기 구현을 개발하고 사용자와 다른 사람들로부터 피드백을 받아 여러버전을 거쳐 소프트웨어를 진화시켜 요구한 최종 시스템을 개발한다.

• 명세화, 개발과 검증 활동은 분리되었다기 보다는 활동 간 빠른 피드백을 가지고 중첩되어 있다.

• 시스템과 소프트웨어 제품을 개발하는 데 있어서 가장 일반적인 접근법이다.

• 계획주도 접근법에서는 시스템의 증가분을 미리 찾아서 정리한다.

• 요구사항이 개발 프로세스 과정 동안에 쉽게 바뀌는 시스템에 대해서는 애자일 방법의 기본적인 사항에 해당하는 점증적 소프트웨어 개발이 폭포수 접근법보다 적합하다.

• 점증적 개발은 엔지니어가 문제를 해결하는 방식을 그대로 반영한다.

• 시스템에 대한 각각의 증가분이나 버전은 고객이 필요로 하는 기능의 일부를 담고 있다.

장점 & 단점

장점	단점
소프트웨어를 점증적으로 개발함으로써 소프트웨어를 개발하면서 발생하는 변경 사항에 대해 적은 비용으로 쉽게 대처할 수 있다.	고객은 소프트웨어 설계 문서만으로는 진척 사항을 파악하기 어렵다.
다시 분석하고, 작성해야 하는 문서의 양이 폭포수 모델의 경우보다 훨씬 적다	프로젝트가 가시적이지 못하다. 관리자는 진척도를 확인하기 위해 정기적으로 중간 산출물이 필요하다.
이미 진행된 개발 작업에 대해서는 고객의 피드백을 받기가 더 쉽다.	시스템에 새로운 기능을 추가하는 작업은 하면 할수록 더 어렵고 많은 비용이 들게 된다.
비록 전체 기능을 제공하지 못하더라도 고객에게 유용한 소프트웨어를 빠르게 전달하고 배포하는 것이 가능하다.	고객이 처음부터 완성된 전체기능을 사용하기가 어렵다.

😀 통합 및 환경설정
(컴포넌트 기반 개발 CBD - Component Based Development)

 

컴포넌트:

 

• 정의

• 독립적으로 실행 가능 하며 표준 인터페이스를 갖추고 소프트웨어의 대처 가능성, 재사용성, 기능적 독립성을 갖춘 소프트웨어 집합

 

• 잘 정의된 하나 또는 그 이상의 인터페이스를 가지는 소프트웨어의 단위 조각

• 특징

• 실행환경에서 독립적으로 개발 배포될 수 있음

• 개발 생산성을 획기적으로 향상시킬 수 있으며 품질 증대를 도모할 수 있음

• 컴포넌트 구조를 사용한다면 환경 및 사용자의 요구사항에 적응 가능한 시스템을 쉽게 개발 할 수 있음

• 인터페이스를 이용하여 구현 이전에 컴포넌트를 이용한 분석작업이 가능함

• 종류

 

분산 컴포넌트	EJB,CORBA, COM+  등 산 객체 환경 지원 컴포넌트
비즈니스 컴포넌트	물리적으로 배포 할 수 있는 독립된 하나의 비즈니스 개념을 구현한 컴포넌트
확장 비즈니스 컴포넌트	확장을 고려하여 설계된 Business Componet  의 집합으로 그룹 형태로 재사용이 가능한 항목의 집합
시스템 컴포넌트	비즈니스 가치를 제공하기 위해 같은 일을 하는 시스템 수준의 컴포넌트들의 집합

 

특징

• 잘 정의되고 검증된 컴포넌트 활용으로 개발 기간 단축

• 자원에 대한 재사용성 확대 및 시장환경 변화에 능동적으로 대처

• 테스트와 디버깅 단계에서 시간을 절약

• 컴포넌트 명세서를 통한 소프트웨어 품질관리를 위한 프로세스 지원

• 인터페이스 기반의 접근방법을 통해 조직 내 복잡한 시스템 구성 속에서 일관성 유지가 쉬움

• 반복 점진적 개발 프로세스 제공

장점 & 단점

장점	단점
재사용을 통한 생산성 향상 반복적 활용에 수익성 제고 및 개발 시간 단축, 개발 비용 감소	요구사항을 타협해야 하는 문제가 발생하기 때문에 시스템이 사용자의 진정한 요구사항을 만족시키기 어려울 수도 있다.
신뢰도 향상 > 기존에 여러 시스템에서 사용되었던 것을 활용하므로 충분히 신뢰성이 검증되었다 고 볼 수 있다.	새로운 버전의 재사용 컴포넌트에 대한 통제권을 개발조직이 가지지 못하기 때문에 시스템 진화에 대한 주도권을 상실한다는 문제도 있다.
프로세스 위험 감소 > 이미 소프트웨어의 일부가 존재한다면, 이에 대한 비용은 비교적 정확하게 예측할 수 있다.	지적 재산권 문제
전문가의 효율적인 활용 > 각 도메인 분야에서 전문가들에 의해 만들어진 소프트웨어를 사용할 수 있다.	유지보수 비용 증가 > 재사용되는 소프트웨어의 코드가 제공되지 않는 경우라면 시스템 변화 등에 따른 유지보수 비용이 크게 증가할 위험이 있다
표준 호환 > UI나 Menu등이 표준으로 만들어지고, 이를 재사용한다면 훨씬 소프트웨어의 일관성을 유지하고, 표준화하기 용이하다.	도구 지원 부족 > CASE가 재사용을 지원하지 않을 수도 있고, 해당 도구를 기존 개발 환경에 통합하기 어려울 수도 있다.
빠른 개발 > 재사용하는 소프트웨어에 대한 개발과 검증시간을 절약할 수 있다.	컴포넌트 라이브러리를 생성하고 관리하는 비용 > 재사용하기 위한 컴포넌트를 관리하는 것이 쉽지 않다.
	컴포넌트 검색, 이해, 수정 비용 > 실제로 컴포넌트를 사용하기 위해서는 적합한 컴포넌트를 찾고, 명세를 이해하고, 이를 시스템에 통합하기 위한 수정 작업을 거쳐야 한다.

 

 

😀 애자일 방법론 ( Agile )

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 

 

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

애자일 소프트웨어 개발 모델은 실용적인 측면을 강조한 개발 방법론 입니다.

 

특징

• less document-oriented, 즉 문서를 통한 개발 방법이 아니라,
  code-oriented, 실질적인 코딩을 통한 방법론

 

• 협력과 피드백을 자주! 일찍! 더 잘하는 것!

 

• 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있다.

 

• 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다.

중점가치( = 애자일 선언 )

 

• 공정과 도구보다 개인과 상호작용을

• 포괄적인 문서보다 작동하는 소프트웨어를

• 계약 협상보다 고객과의 협력을

• 계획을 따르기보다 변화에 대응하기를

가치있게 여긴다.

 

애자일방법론 중시 가치는?

1. 소통하라 - 크고잘 보이는 차트 , 정보 공유시스템 회의, 정기적인 계획 세션

2. 협력하라 - 전체팀은 고객과 함께 생각하고 문제 해결

3. 적응하라 - 변화를 수용 , 변화에 대한 제어를 포기

4. 지속적으로 - 짧게 시간이 정해진 반복점증개발

5. 가치를 전달하라 - 가치와 위험도가 가장 높은 일부터 먼저 시작 , 자주 출시하고 낭비를 줄임

6. 피드백을 구하라 - 일찍 자주 일을 보여줌

 

장점 & 단점

장점	단점
요구사항 변경관리 - 프로젝트 진행 중간 중간에 필요한 요소들을 바꿀 수 있습니다.	계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있다.
시작할 때 프로젝트를 정확하게 규정하지 않아도 됩니다.	체계화된 문서가 적을 수 있다
작은 요소들을 출시 할 때 빠르게 만들 수 있습니다.	모델이 복잡하여 비용이  많이들고 복잡하다는 단점
점진적으로 테스트되기 때문에 초기에 버그를 발견할 수 있습니다.
프로젝트 가시성 개선
팀생산성 증가

 

종류

• 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다

• 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

 

• 스크럼 

• 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

• 프로젝트 관리를 위한 애자일 방법론으로 추정및 조정기반의 대표 기법
  1986년 시작됨 1995년에 소프트웨어 개발에 적용시켜 탄생

• 익스트림 모델링

• 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다

적용대상

• 하나는 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직이다. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것이다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮다.

 

• 두 번째는 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직이다. 

 

• 또한 CMMI나 SPICE등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것이다.

 

예제문제

Q1. ) 애자일 방법론이 아닌것은?

 

1. 스케줄 쥐어짜기 ->지속가능한 시간 속도를 파악해서 안정적 성과 내도록 강조

2. 문서작성 안하기 

3. 막장 코딩

4. 설계나 계획 안하기 ->? 엔지니어링 실천법을 이용해서 챙겨야함 ( TDD 등)

😀 폭포수 모델

특징

• (각 단계별로 지정된 산출물이 필요하다.)
  원칙적으로 폭포수 모델에서 각 단계의 결과로 승인된 하나 또는 그 이상의 문서들이 나와야 한다. 

• 이전 단계가 끝나기 전까지는 다음 단계를 시작하지 않는다.

• 소프트웨어 개발은 각 단계가 중첩되며 서로에게 정보를 제공하는 방식으로 이루어진다.

• 마지막 생명주기(운영과 유지보수) 동안에는 소프트웨어를 사용할 수 있도록 제공한다.

• 소프트웨어 명세와 설계에 대한 광범위한 안전성과 보안 분석이 필요한 중대한 시스템이 필요한 분석을 수행할 수 있도록 명세서와 설계문서를 완료해야 한다.

 

장점 & 단점

장점	단점
	계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있다.
설계과정에서 요구사항에서의 문제점을 발견하고, 코딩 과정에서 설계 문제를 발견할 수 있다.	요구 분석에 상당한 시간이 소요
	개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려우며 규모가 크고 복잡한 시스템에는 적합하지 않다
	한 프로세스 단계에서 새로운 정보를 발견하게 되면 필요한 시스템 변경을 반영하기 위해 이전 단계에서 작성한 문서를 수정해야 한다.

 

적용대상

• 제조비용이 높게 발생하는 하드웨어 개발에는 적합할 수 있다.

이럴땐 사용 X

• 자유로운 팀 커뮤니케이션이 가능하고 소프트웨어 요구사항이 빨리 변경되는 상황에서는 이(폭포수) 모델이 적합한 프로세스 모델이 아니다.

• 정형적 명세를 개발하는 것은 많은 비용이 들기 때문에 중대한 시스템을 개발하는 경우가 아니면 폭포수 모델은 거의 사용하지 않는다.

 

🚩 애자일 개발 프로세스와 전통적인 개발 프로세스와의 차이

전통 VS 애자일
	전통( = 계획기반 = 폭포수)	애자일
중점	탄탄한 계획을 중점 산출물 중심 (각 단계별로 지정된 산출물이 작성되었는지)	개인과 상호작용, 작동하는 소프트웨어, 고객과 협력, 변화에 대응 소프트웨어가 잘 작동하는지, 얼마나 요구사항에 맞게 개발했는지
요구사항 관리	한번에 정의 초기 요구사항 수집 및 엄격한 변경 관리	지속적인 요구사항 개발 및 변경 수용
계획수립	상세한 계획수립(Up-Front)설계	두 단계 계획(찾은 계획수립&갱신) 경험 기반 프로세스
문서화	중량 프로세스 및 상세한 문서화 강조	경량 프로세스 및 문서화보다 코드를 강조
역할	엄격한 역할 분리	전체 팀워크를 중요시
고객과 의사소통	적음	많음
테스트	마지막 단계에서 테스트	지속적인 테스트

폭포수 모델등의 고전적인 방법론과의 가장 큰 차이는 적은 문서를 지향하고, 실제 개발을 지향하는 방법입니다.

 

😀  V-model (브이모델)

 

 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나로 볼 수 있다.

아래 방향으로 선형적으로 내려가면서 진행되는 폭포수 모델과 달리, 이 프로세스는 오른쪽 그림과 같이 코딩 단계에서 위쪽으로 꺾여서 알파벳 V자 모양으로 진행된다.

 

V 모델은 개발 생명주기의 각 단계와 그에 상응하는 소프트웨어 시험 각 단계의 관계를 보여준다.

 

특징

• V 모델은 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 잘 짜인 방법을 사용한다.

 

• 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작하여, 전체적으로 많은 양의 프로젝트 비용과 시간을 감소시킨다.

 

• 각 테스트 단계에서 오류가 발견되었을 때에는 왼쪽의 해당하는 단계에서 문제점을 찾고 되돌아갈 수 있음을 의미하는데, 오류가 빨리 발견되면 빠를수록, 개발 초기 단계에서의 작업이 명확하면 명확할 수록, 전체 프로젝트 일정이 단축되고, 후반부에서 발생할 테스팅 비용을 줄일 수 있게 된다.

용어설명

V&V

(1) 검증(Validation)

• 목적 : Are we building the RIGHT product?(올바른 제품을 만들고 있는가?)

• 소프트웨어의 올바른 구현을 보장하기 위해 정적분석(리뷰, 익스펜션 등)을 비롯한 단위, 통합, 시스템 테스트에서 수행되는 활동을 말한다.

 

(2) 확인(Verification)

• 목적 : Are we building the product RIGHT?(제품을 올바르게 만들고 있는가?)

• 확인(Validation)이란 최종 목적의 달성을 위해 사용자 요구사항이 충족되었는지, 단위 테스트에서부터 사용자 인수 테스트까지의 단계를 통해 수행되어지는 활동을 말한다.

 

검증(Validation)단계

종류	정의 및 특징
요구사항 분석	개발될 시스템에 대한 요구사항은 시스템 사용자의 필요를 분석함으로써 얻을 수 있다. 목표로 하는 이상적인 시스템이 수행해야할 기능에 대해 고민하는 단계이다.  소프트웨어가 어떻게 설계되고 구현될 것인지에 대한 사항은 다루지 않는다.
시스템 설계	시스템 엔지니어는 사용자 요구사항 문서를 면밀히 검토하는 것을 통해 개발할 시스템에 대해 분석하고 이해한다 또한 시스템 엔지니어는 사용자 요구사항을 구현 가능성과 필요한 기술들을 파악한다.
아케텍처 설계 (구조설계)	고수준 설계 아키텍처를 선택함으로써 만들어지는 베이스라인은 일반적으로 모든 구현될 모듈 항목과 그 간략한 기능을 정의하고, 모듈 간의 인터페이스, 관계, 의존성을 기술하며, 필요한 데이터베이스 테이블, 아키텍처 다이어그램, 적용기술 내역을 기술한다.  또한 이 단계에서 통합 테스트에 대한 설계가 이루어진다.
모듈 설계	저수준 설계 아키텍처 설계 단계에서 정의된 모듈 항목을 더 세분하여 각각의 모듈에 대한 기술을 작성하며, 이를 이용하여 프로그래머들이 코딩을 시작할 수 있도록 만들어 준다. 이 단계에서는 단위 테스트를 위한 케이스와 절차가 설계된다.

확인(Verification)단계

종류	정의 및 특징
단위 테스트	화이트박스 테스트-코드를 직접 확인하는 형태다.  단위 테스트는 테스트 프로세스의 첫 단계이다. 단위 테스트 시에는 에러를 줄이기 위한 의도로 작성된 코드에 대한 분석을 진행한다. 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 코드가 효율적으로 작성되었는지, 프로젝트 내에 합의된 코딩 표준을 준수하고 있는지도 검증한다. 코드를 개발한 개발자가 직접 수행한다.
통합 테스트	블랙박스 테스트 -코드를 직접 확인하는 형태는 아니다.  각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견하는 작업을 수행한다. 아키텍처 설계 단계에서 준비된 테스트 케이스를 사용하여 테스트가 진행되며, 일반적으로 개발자가 진행한다.
시스템 테스트	실제 구현된 시스템과 계획된 사양(specifications)을 서로 비교하는 작업이다.
인수 테스트	시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 "확신(Confidence)"을 얻는 작업이다.  결함을 찾는 것은 인수 테스팅의 주 목적이 아니다. 이 테스트는 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가한다.
알파 + 배타	알파 : 개발의 마지막 부분에서 수행하는 테스팅으로서 가상의 유저 환경이 조성될 수 있다 배타 : 일반적으로 엔드 유저에 의해 완료되는 테스팅이다. 프로그램 상용화를 위한 애플리케이션 릴리즈 이전의 최종 테스팅을 의미한다.

 

 

😀  

😀

 

🙈🔑⭐⌚🚩