[정보처리기사 필기] 1과목 소프트웨어 설계 - 1

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

 - 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

 - 개발자 또는 개발팀은 개발 방법 등에 따라 특정 모형을 선택하여 사용하거나 개별적인 모형을 사용

 - 일반적으로 사용되는 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 사용

---

폭포수 모형(Waterfall Model)

 - 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
 - 제품의 일부가 될 메뉴얼을 작성해야 함
 - 두 개 이상의 과정이 병행하여 수행되지 않음

 

프로토타입 모형(Prototype Model)

 - 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
 - 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형

 

나선형 모형(Spiral Model)

 - 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
 - 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로 점진적 모형이라고도 함
 - 위험을 관리하고 최소화하는 것을 목적으로 함

 

애자일 모형(Agile Model)

 - 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론
 - 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복
 - 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용

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

     1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

     2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

     3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.

     4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

---

스크럼(Scrum)

 - 팀이 중심이 되어 개발의 효율성을 높인다는 의미

 - 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성

---

제품 책임자(PO:Product Owner)

 - 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정. 주로 개발 의뢰자나 사용자가 담당

 - 백로그 작성 및 백로그에 대한 우선순위를 지정

 

스크럼 마스터(SM:Scrum Master)

 - 객관적인 시각에서 조언을 해주는 가이드 역할을 수행. 팀원을 통제하는 것이 목표가 아님

 - 일일 스크럼 회의를 주관 및 진행 사항을 점검. 개발 과정에서 발생된 장애 요소를 공론화하여 처리

 

개발팀(DT:Development Team)

 - 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

 - 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상

---

스크럼 개발 프로세스

 - 제품 백로그->스프린트 계획 회의->스프린트->일일 스크럼 회의->스프린트 검토 회의->스트린트 회고

---

XP(eXtreme Programming)

 - 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

 - 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적

 - 릴리즈 테스트마다 고객을 직접 참여

 - 소규모 인원의 개발 프로젝트에 효과적

 - XP의 5가지 핵심 가치 : 의사소통(Communication) / 단순성(Simplicity) / 용기(Courage) / 존중(Respect) / 피드백(Feedback) 

---

XP 개발 프로세스

 - 사용자 히스토리 : 고객의 요구사항을 간단한 시나리오로 표현

 - 릴리즈 계획 수립 : 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립

 - 스파이크 : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

 - 이터레이션 : 하나의 릴리즈를 더 세분화 한 단위

 - 승인 검사 : 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트(고객이 직접 수행)

 - 소규모 릴리즈 : 고객의 반응을 기능별로 확인, 고객의 요구사항에 좀 더 유연하게 대응

---

XP의 주요 실천 방법

 - Pair Programming(짝 프로그래밍)

   - 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성

 - Test-Driven Development(테스트 주도 개발)

   - 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지 정확히 파악

   - 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용

 - Whole Team(전체 팀)

   - 개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함

 - Continuous Integration(계속적인 통합)

   - 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합

 - Design Improvement(디자인 개선)

   - 프로그램 기능의 변경 없이, 단순화, 유연성 등을 통해 시스템을 재구성

 - Small Releases(소규모 릴리즈)

   - 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응

---

요구사항

 - 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄

 - 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공

---

요구사항의 유형

 - 기능 요구사항(Functional requirements)

   - 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

   - 시스템이 반드시 수행해야 하는 기능

   - 사용자가 시스템을 통해 제공받기를 원하는 기능

 - 비기능 요구사항(Non-functional requirements)

   - 시스템 장비 구성 요구사항

   - 성능 요구사항

   - 인터페이스 요구사항

   - 데이터 요구사항

   - 테스트 요구사항

   - 보안 요구사항

   - 품질 요구사항

   - 제약사항

   - 프로젝트 관리 요구사항

   - 프로젝트 지원 요구사항

 - 사용자 요구사항(User requirements)

   - 사용자 관점에서 본 시스템이 제공해야 할 요구사항

 - 시스템 요구사항(System requirements)

   - 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항