소프트웨어 생명 주기

소프트웨어 생명 주기(Software Development Life Cycle, SDLC)

소프트웨어 개발, 운영, 유지보수 등의 과정을 단계별로 나누어 정의한 것으로, 소프트웨어 개발 방법론의 기반이 되는 개념입니다.

 

특징

• 단계별 구분: 소프트웨어 개발 과정은 단계별로 나뉘며, 각 단계에서 수행해야 할 주요 활동과 결과물(산출물)이 명확히 정의됩니다.
• 수명 주기: 소프트웨어 생명 주기(SDLC)는 소프트웨어 수명 주기라고도 불립니다.
• 다양한 표현 방식: 생명 주기를 표현하는 방식을 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고 합니다.
• 유연한 적용 가능성: 개발자는 문제 유형, 프로젝트 요구사항, 개발 방법에 따라 특정 모형을 선택하거나, 복합적으로 조합하여 사용할 수 있습니다.
• 대표적인 모형:
  • 폭포수(Waterfall) 모형
  • 프로토타입(Prototype) 모형
  • 나선형(Spiral) 모형
  • 애자일(Agile) 모형

폭포수 모형(Waterfall Model)

소프트웨어 개발의 각 단계를 순차적으로 진행하며, 이전 단계로 돌아가지 않는다는 전제하에 모든 단계를 확실히 마무리하고 다음 단계로 넘어가는 선형 순차적 개발 방법론입니다.

 

특징

전통적 모형

• 소프트웨어 공학에서 가장 오래되고 널리 사용된 개발 모형으로, 고전적 생명 주기 모형이라고도 불립니다.

선형 순차적 구조

• 개발의 각 단계는 순차적으로 진행되며, 이전 단계로 돌아갈 수 없다는 전제를 기반으로 합니다.

단계별 명확한 산출물

• 각 단계가 끝날 때마다 **결과물(산출물)**이 명확히 정의되어야 하며, 이를 바탕으로 다음 단계로 진행됩니다.

검토 및 승인 과정

• 단계마다 결과를 철저히 검토하고, 승인 과정을 거쳐야만 다음 단계로 넘어갈 수 있습니다.

병행 수행 불가

• 두 개 이상의 과정을 동시에 수행할 수 없으며, 단계 간의 독립성을 유지합니다.

경험과 사례

• 적용 경험과 성공 사례가 많아, 안정적인 프로젝트에 적합합니다.

문서 중심

• 제품의 일부가 될 매뉴얼 및 문서를 작성해야 하며, 이를 통해 개발 과정에서의 명확성을 높입니다.

 

폭포수 모형의 단계

 

요구사항 분석

• 시스템 및 소프트웨어의 요구사항을 명확히 정의.

설계 (Design)

• 소프트웨어 아키텍처와 상세 설계를 작성.

구현 (Implementation)

• 코딩 작업을 통해 설계를 소프트웨어로 변환.

테스트 (Testing)

• 소프트웨어의 기능을 검증하고 오류를 발견 및 수정.

유지보수 (Maintenance)

• 개발 완료 후 발견된 문제를 수정하고, 소프트웨어를 개선.

폭포수 모형

 

프로토 타입 모형(Prototype Model,원형 모형)

사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 소프트웨어 개발 모형입니다.

 

특징 :

사용자 중심의 요구사항 확인:

• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발됩니다.
• 사용자는 시제품을 통해 실제 시스템을 미리 체험하며 요구사항을 명확히 정의할 수 있습니다

골격 코드 제공:

• 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로, 요구된 소프트웨어를 구현하는 데 사용될 골격 코드가 됩니다.

요구사항 변경 용이:

• 개발 초기 단계에서 사용자 요구사항의 변경 및 수정이 용이하여, 개발 완료 후의 오류 및 요구사항 변경 비용을 줄일 수 있습니다.

폭포수 모형의 단점 보완:

• 소프트웨어 개발이 완료된 시점에서 요구사항 오류가 발견되는 폭포수 모형의 단점을 보완합니다.
• 개발 초기부터 사용자의 피드백을 수용하여 오류 가능성을 줄입니다.

개발 비용과 시간 절감:

• 최종 시스템 개발 전에 요구사항을 정확히 파악하므로, 개발 비용과 시간을 절감할 수 있습니다.

프로토타입 모형의 주요 단계:

 

요구 수집 (Requirement Gathering):

• 사용자의 기본적인 요구사항을 빠르게 수집하여, 시스템의 주요 기능과 기대치를 명확히 파악합니다.
• 이 단계에서 사용자의 모호한 요구사항을 프로토타입을 통해 구체화합니다.

빠른 설계 (Quick Design):

• 사용자의 요구사항에 기반한 간단한 설계를 수행합니다.
• 이 설계는 시스템의 전체 구조보다는 사용자 인터페이스(UI)와 기본 기능 구현에 초점이 맞춰집니다.

프로토타입 개발 (Prototype Development):

• 빠른 설계에 따라 시제품을 제작합니다.
• 이 시제품은 완성된 시스템이 아니며, 주요 기능과 인터페이스만을 포함합니다.

사용자 평가 및 피드백 (User Evaluation & Feedback):

• 사용자는 시제품을 테스트하며 자신의 요구사항이 충족되었는지 확인합니다.
• 시스템에 대한 개선점, 새로운 요구사항, 수정 사항 등을 피드백으로 제공받습니다.

프로토타입 개선 (Prototype Refinement):

• 사용자 피드백을 반영하여 프로토타입을 개선하고, 반복적으로 수정합니다.
• 최종적으로 사용자의 요구사항에 맞는 시스템의 설계가 확정됩니다.

최종 시스템 개발 (Final System Development):

• 확정된 설계를 바탕으로 최종 소프트웨어 시스템을 개발합니다.

프로토 타입 모형

 

나선형 모형(Spiral Model, 점진적 모형)

보헴(Boehm)이 제안한 소프트웨어 개발 모형으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형입니다.

 

특징 :

 

나선형 접근 방식:

• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 반복하며 점진적으로 완성된 최종 소프트웨어를 개발합니다.
• 점진적 모형이라고도 불립니다.

위험 분석 기능:

• 각 반복 단계에서 잠재적인 위험 요소를 분석, 관리, 최소화하는 것을 주요 목표로 합니다.
• 이를 통해 소프트웨어 개발 과정에서 발생할 수 있는 위험 요인을 사전에 대비할 수 있습니다.

점진적 개발:

• 각 반복(Iteration)을 통해 점진적으로 시스템의 완성도를 높이며, 누락되거나 추가된 요구사항을 반영할 수 있습니다.
• 사용자의 요구사항이 명확하지 않은 경우나, 개발 중 변경 가능성이 높은 프로젝트에 적합합니다.

유연성:

• 반복적이고 점진적으로 개발 과정을 진행하므로, 요구사항 변경에 유연하게 대응할 수 있습니다.
• 유지보수 과정이 불필요하거나 최소화될 수 있습니다.

폭포수 모형 + 프로토타입 모형:

• 폭포수 모형의 단계적 접근 방식과 프로토타입 모형의 사용자 피드백 기능을 결합하였습니다.

나선형 모형의 단계:

 

목표 설정 (Determine Objectives):

• 개발 목표, 제약 조건, 대안을 정의하고, 각 반복 단계에서 달성할 구체적인 목표를 설정합니다.

위험 분석 (Identify and Resolve Risks):

• 각 단계에서 발생할 수 있는 잠재적인 위험 요소를 식별하고 분석하여 해결 방안을 마련합니다.
• 이를 통해 개발 과정에서 리스크를 최소화합니다.

개발 및 검증 (Develop and Validate):

• 개발 목표에 따라 설계, 개발, 테스트 등의 작업을 수행하며, 프로토타입을 사용하여 결과를 검증합니다.

계획 수립 (Plan the Next Iteration):

• 다음 반복 주기의 계획을 수립하고, 필요에 따라 요구사항을 추가하거나 수정합니다.

나선형 모형

 

애자일 모형(Agile Model)

“민첩한, 기민한”이라는 의미를 가진 애자일 모형은 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발 과정을 진행하는 방법론입니다.

 

특징 :

 

통합적인 접근:

• 특정한 개발 방법론이 아니라, 효율적이고 낭비 없이 결과물을 만드는 데 초점을 맞춘 방법론을 통칭합니다.
• 고객과의 긴밀한 소통과 협업을 중시합니다.

반복적 개발:

• 스프린트(Sprint) 또는 **이터레이션(Iteration)**이라고 불리는 짧은 개발 주기를 반복하며, 각 주기마다 작동 가능한 결과물을 만듭니다.
• 주기마다 고객의 피드백을 받아 요구사항을 반영합니다.

우선순위 기반:

• 고객이 요구사항의 우선순위를 부여하며, 중요한 작업부터 개발이 진행됩니다.
• 이를 통해 핵심 요구사항을 먼저 충족시킵니다.

적합한 환경:

• 소규모 프로젝트, 고도로 숙련된 개발자, 급변하는 요구사항에 적합합니다.
• 특히 변화가 잦은 환경에서도 높은 생산성을 유지할 수 있습니다.

애자일 선언문(Agile Manifesto)의 원칙:

• 개인과 상호작용이 도구와 프로세스보다 우선.
• 작동하는 소프트웨어가 문서보다 중요.
• 고객 협력이 계약 협상보다 중요.
• 변화에 대응하는 것이 계획을 따르는 것보다 중요.

애자일 기반 소프트웨어 개발 방법론:

스크럼(Scrum):

• 팀이 역할을 분담하여, 짧은 주기(스프린트) 동안 목표를 설정하고 진행 상황을 점검하며 개발.

XP(Extreme Programming):

• 테스트 우선 개발(TDD), 지속적 통합(CI) 등 프로그래밍 관행을 강화한 방법론.

 

칸반(Kanban):

• 시각적 도구를 사용해 작업의 흐름을 관리하고, 작업량을 조절하여 낭비를 줄이는 방식.

Lean:

• 낭비 제거와 품질 향상에 초점을 맞춘 방법론.

크리스탈(Crystal):

• 프로젝트의 복잡성과 팀의 특성에 따라 맞춤형 프로세스를 적용.

ASD(Adaptive Software Development):

• 빠르게 변화하는 요구사항에 적응하기 위한 반복적 개발 방법론.

기능 중심 개발(FDD):

• 전체 기능을 세부 기능으로 나누고, 기능 단위로 개발과 테스트를 진행.

DSDM(Dynamic Systems Development Method):

• 시간과 자원에 제약을 두고, 필요한 시스템을 개발하는 데 초점을 맞춘 방법론.

DAD(Disciplined Agile Delivery):

• 애자일, 스크럼, 칸반 등의 장점을 통합하여 팀 기반으로 소프트웨어를 개발.

애자일 모형

구분	폭포수 모형	프로토타입 모형	나선형 모형	애자일 모형
개발 순서	선형(단계별 진행, 이전 단계로 복귀 불가)	시제품을 통해 요구사항을 점진적으로 명확화	나선을 따라 여러 번 반복적으로 개발	짧은 주기의 반복적 개발 및 지속적 피드백
특징	각 단계의 결과물 명확, 단계 간 병행 수행 불가	사용자 요구를 정확히 파악하고 사용자 피드백 반영	폭포수+프로토타입+위험 관리 기능 추가	고객 요구와 변화에 유연한 대응, 협력 중심
새로운 요구사항 반영	어려움(초기 계획 변경 불가)	용이(시제품 제작 후 반영 가능)	유연함(각 반복 주기에 반영 가능)	매우 유연함(반복 주기마다 즉시 반영 가능)
고객과의 의사소통	제한적(단계 간 문서 검토)	빈번함(시제품 제작과 피드백 단계)	정기적(위험 평가와 요구사항 검토 시 소통)	매우 빈번(개발 주기마다 고객 참여 및 피드백)
테스트	마지막 단계에서 집중적으로 수행	시제품 단계에서 주요 기능 테스트	각 반복 주기마다 테스트 수행	지속적인 통합 및 테스트(매 개발 주기마다 테스트)
개발 중심도	문서화 중심	시제품 중심	위험 분석과 관리 중심	개발과 협력 중심
장점	- 관리가 용이 - 문서화와 산출물 명확	- 요구사항 명확화 - 고객과의 소통 강화	- 위험 관리 가능 - 정밀하고 유연한 요구사항 반영 가능	- 고객 요구에 빠른 대응 - 짧은 주기로 결과물 제공
단점	- 요구사항 변경에 취약 - 후반부에서 오류 발견 시 비용 증가	- 시제품 제작 시간과 비용 소요 - 최종 제품 품질 보장 어려움	- 복잡한 관리 필요 - 위험 분석에 많은 시간과 자원 소요	- 문서화 부족 가능성 - 숙련된 팀원 필요 - 대규모 프로젝트에는 부적합
적용 사례	- 명확한 요구사항과 고정된 계획이 필요한 프로젝트	- 요구사항이 불명확하거나, 사용자와의 협력이 필요한 프로젝트	- 대규모, 복잡한 시스템 - 위험 요소가 많은 프로젝트	- 요구사항이 자주 변경 - 빠른 피드백이 중요한 프로젝트

새로운 요구사항 반영:

• 폭포수 모형은 초기 계획 변경이 어렵지만, 애자일 모형은 매우 유연하게 요구사항을 수용합니다.

고객과의 의사소통:

• 폭포수 모형은 제한적 문서 검토에 의존하지만, 애자일 모형은 지속적이고 빈번한 협력이 중심입니다.

테스트:

• 폭포수 모형은 마지막 단계에서 테스트를 집중적으로 수행하며, 애자일 모형은 반복 주기마다 테스트와 통합을 수행합니다.

개발 중심도:

• 폭포수 모형은 문서화 중심, 프로토타입은 시제품 중심, 나선형은 위험 관리 중심, 애자일은 개발과 협력 중심입니다.

---

소프트웨어 공학(Software Engineering)

• 소프트웨어의 위기를 극복하기 위해 연구된 학문.
• 다양한 방법론, 도구, 관리 기법 등을 통해 소프트웨어의 품질과 생산성을 향상시키는 것을 목적으로 함.
• 다음과 같은 여러 정의가 있음:
  • IEEE 소프트웨어 공학 표준 용어사전: 소프트웨어 개발, 운용, 유지보수 및 관리를 위한 체계적인 접근 방법.
  • Fairley: 소프트웨어 개발과 관련된 기술적, 관리적 원칙을 적용하여 품질 높은 소프트웨어를 효율적으로 생산.
  • Boehm: 소프트웨어 비용과 일정을 효율적으로 관리하면서 성능, 신뢰성을 충족시키는 과정.

소프트 웨어 공학의 기본원칙

 

현대적인 프로그래밍 기술의 지속적 적용

• 최신 개발 기법과 도구를 채택하여 소프트웨어의 생산성과 효율성을 높임.

지속적인 품질 검증

• 소프트웨어 품질이 일정 수준 이상 유지되도록 주기적인 검증 및 테스트를 수행.

명확한 기록 유지

• 개발 관련 사항과 결과를 명확히 문서화하여 유지보수와 협업이 용이하도록 함.

 

소프트웨어 위기의 현상

소프트웨어 개발 속도가 하드웨어 발전 속도를 따라가지 못해 사용자 요구를 충족하지 못하는 문제.

 

구체적인 현상:

 

개발 인력 부족과 인건비 상승

• 숙련된 개발자 부족으로 인한 인건비 증가.

성능 및 신뢰성 부족

• 개발된 소프트웨어가 기대한 성능이나 신뢰성을 충족하지 못함.

개발 기간의 지연 및 비용 증가

• 일정 초과 및 비효율적인 개발로 인해 발생.

유지보수 어려움

• 초기 설계의 비효율성과 문서화 부족으로 인해 유지보수 비용 상승.

소프트웨어 생산성과 품질 저하

• 비효율적인 개발로 인해 소프트웨어 품질이 낮아지고, 생산성이 떨어짐.

---

애자일 선언(Agile Manifesto)

• 2001년, 17명의 애자일 전문 개발자가 공통의 관점을 정리하여 '애자일 소프트웨어 개발 선언문'을 발표.
• 선언문에는 애자일 개발 철학을 나타내는 4가지 핵심 가치와, 애자일 개발을 실무에 적용할 때 기준이 되는 12가지 실행 지침이 포함됨.

애자일 개발 4가지 핵심 가치

1. 개인과 상호작용을 프로세스와 도구보다 중시한다.
   • 프로세스나 도구보다 사람 간의 소통과 협업을 강조.
2. 작동하는 소프트웨어를 포괄적인 문서보다 중시한다.
   • 과도한 문서 작성보다 실제로 동작하는 소프트웨어를 더 중요하게 여김.
3. 고객과의 협력을 계약 협상보다 중시한다.
   • 고객의 요구와 피드백에 유연하게 대응하고 긴밀한 협력 관계를 유지.
4. 변화에 대응하는 것을 계획을 따르는 것보다 중시한다.
   • 초기 계획보다 변화하는 요구사항에 유연하게 적응.

 

애자일 개발 12가지 핵심가치

 

1. 고객 만족을 최우선으로 한다.
   • 초기에 가치 있는 소프트웨어를 조기에 지속적으로 제공.
2. 변화하는 요구사항을 수용한다.
   • 설계 후반이라도 고객 요구사항의 변화를 수용.
3. 짧은 주기로 소프트웨어를 자주 배포한다.
   • 몇 주에서 몇 달 간격으로 작동하는 소프트웨어를 지속적으로 제공.
4. 개발자와 비즈니스 관계자가 함께 협력한다.
   • 프로젝트 전 과정에서 매일 함께 협력.
5. 동기 부여된 개인들로 구성된 팀을 구성한다.
   • 팀원에게 필요한 환경과 지원을 제공하고, 신뢰를 바탕으로 업무를 맡김.
6. 직접적인 대면 대화를 선호한다.
   • 가장 효율적이고 효과적인 정보 전달 방법은 대면 대화.
7. 작동하는 소프트웨어가 진척의 주요 척도다.
   • 소프트웨어가 실제로 작동하는 것이 프로젝트의 진척을 평가하는 주요 기준.
8. 지속 가능한 개발을 지원한다.
   • 모든 팀원이 일정한 속도로 개발을 지속할 수 있도록 유지.
9. 기술적 우수성과 좋은 설계에 대한 지속적 관심이 필수다.
   • 생산성을 높이기 위해 기술적 탁월성과 훌륭한 설계를 꾸준히 추구.
10. 단순성을 추구한다.

• 작업을 단순화하고 불필요한 일을 줄이는 것이 중요.

11. 자가 조직화된 팀을 만든다.

• 가장 좋은 설계, 요구사항, 아키텍처는 스스로 조직화된 팀에서 나온다.

12. 팀의 성찰과 개선을 정기적으로 수행한다.

• 팀은 정기적으로 효율성을 높이기 위해 과정을 반성하고 조정.

---

출저 및 참고

정보처리 산업기사 기본서(시나공)