Software
- 원하는 기능과 성능을 제공하는 프로그램
- 프로그램의 사용과 동작을 설명한 문서들
소프트웨어의 특징 : 비가시성, 비마모성, 요구사항의 변경과 주변 환경의 변화에 따라 계속 수정되고 진화
소프트웨어의 위기 : 소프트웨어 수요 증가에 비해 공급 및 개발의 어려움
소프트웨어 공학
정의 : 소프트웨어의 개발, 운용, 유지보수 및 폐기에 대한 체계적인 접근방법
목표 : 소프트웨어 개발이 체계적이고 공학적인 방법으로 이루어져서,
제한된 비용과 기간 내에 고객이 원하는 품질 높은 소프트웨어를 개발
고객의 요구 → 요구사항 분석 → 설계 → 구현 → 테스팅 → S/W 제품
소프트웨어 공학의 영역들
개발 방법론 : 시스템 개발을 어떠한 방법으로 진행할 것인가를 다루는 분야
요구공학 : 시스템에 대한 고객의 요구를 이해하고 파악하는 분야
설계 : 어떻게 설계를 하느냐의 문제 (설계원칙, 모듈화, 설계방법론 등)
테스팅 : 효과적으로 비용을 최소화하면서 어떻게 테스트 케이스를 생성할 지의 문제
프로세스 : 소프트웨어 제품을 생산하기 위해서 요구되는 인력, 절차 ,방법, 도구들을 통합하는 수단
형상 관리 : 형상 항목을 식별하고 변경을 통제
품질
재사용 : 코드 뿐만 아니라 시스템에 대한 지식, 경험, 요구사항, 테스트 케이스등 재사용
프로세스
[의미]
주어진 목적을 위해 수행되는 일련의 절차
[역할]
각 순서와 활동을 명확하게 정의
프로세스를 사용하는 조직원들의 공통된 행동 약식을 지정
소프트웨어 개발의 목표 : 정해진 기한 내에, 주어진 예산을 이용해 사용자가 원하는 좋은 품질로 개발
소프트웨어 프로세스
- 시스템의 개발에 필요한 구조화된 활동의 집합
- 일반적으로 다음의 과정을 포함 : 명세 - 설계 및 구현(개발) - 검증(테스트) - 진화(유지보수)
소프트웨어 프로세스 모델(Software Process Model) = Developement Life-Cycle = 생명 주기 모델
- 특정한 관점에서 소프트웨어 프로세스의 흐름을 체계화한 개념
- 소프트웨어를 어떻게 개발할 것인가에 대한 추상적인 표현
[특징]
- 각 단계에 관련된 활동 및 산출물이 정해져 있음
- 전체 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격 제시
- 참여자들 간에 의사소통의 기준과 용어의 표준화를 가능하게 함
(1) 주먹구구식 개발 모델 (Build-Fix Model)
요구사항 분석, 설계 단계 없이 일단 개발에 들어간 후, 만족할 때까지 수정
장점 : 매우 작은 규모의 프로젝트에서는 효용성이 높음
단점 : 계획이 정확하지 않음, 진행 상황 파악이 어려움, 개발 및 유지보수가 어려움(개발 문서가 없기 때문)
(2) 폭포수 모델(Waterfall Model)
순차적으로 소프트웨어를 개발하는 전형적이고 기본적인 방법 (가장 많이 사용됨)
이전 단계가 끝나지 않으면 다음 단계를 시작할 수 없다, 모든 단계에 무조건 산출물이 존재한다
요구사항 분석 → 요구사항 명세서
설계 → 설계 명세서
구현 → SW 소스코드
테스트 → 테스트 명세서
유지보수 → 운영가능한 SW
장점 : 각 단계별로 정형화된 접근 가능, 체계적인 문서화로 명확한 프로젝트 진행 가능
단점 : 앞 단계가 완료될 때까지 다음 단계들은 대기,
실제 작동하는 SW를 후반부에 확인할 수 있기 때문에 요구사항 만족 여부 확인하기 까지 많은 시간 소요
적용 가능한 경우: 각 단계가 확실하고, 변경 가능성이 적은 소프트웨어 프로젝트에서 주로 사용됨 ex) 대규모 프로젝트
(3) 원형 모델(Prototyping Model)
폭포수 모델의 단점을 보완
점진적으로 SW를 개발해 나가는 접근 방법
원형을 만들어 고객과 사용자가 함께 평가하며, 요구사항 정제
목적 : 원형을 가능한 빨리 개발하여 고객과 검증하는 것
적용 가능한 경우 : SW 개발 초기에 고객의 요구사항을 완전히 파악하기 어려울 때
요구사항 정의 : 고객의 불완전한 요구사항으로부터 SW의 윤곽 설계
원형 설계 : 빠른 설계, 사용자 인터페이스에 초점
원형 개발 : 설계된 원형을 RAD(Rapid Application Development) 도구 등을 사용하여 빠르게 구현
가능한 빨리 원형을 구현하는 것이 목적
고객 평가 : 고객과 개발자가 함께하는 가장 중요한 단계
원형에 대한 사용 및 평가 시간 충분히 제공
요구사항 정제에 중요한 정보로 사용
원형 정제 : 원형 개발과 검증, 요구사항 정제의 순환을 반복하여 추가적인 정보를 통해 요구사항 완성
(4) 나선형 모델(Spiral Model)
폭포수 모델과 원형 모델의 장점을 수용하고 위험 분석(Risk analysis)을 추가한 점증적 개발 방법
발생하는 위험을 관리하여 최소화하는 것이 목적
나선상의 각 원은 소프트웨어 개발의 점증적 주기 표현
적용 가능한 경우 : 개발에 따른 위험을 잘 파악하여 대처할 수 있기 때문에,
고비용의 시스템 개발
시간이 많이 소요되는 큰 시스템 구축 시
단계별 활동
계획 및 정의 : 고객에게 요구사항 수집, 시스템의 목표를 규명하고 제약 조건을 파악, 프로젝트의 위험 원인 규명
위험 분석 : 초기 요구사항을 토대로 위험 규명, 프로젝트를 계속 진행할 것인지 아니면 중단할 것인지 결정
개발 : 프로세스 모델을 선택하거나 원형 또는 최종적인 제품을 만드는 단계
고객 평가 : 다음 단계에서 고객의 피드백 및 평가를 반영할 수 있는 자료 획득
장점 : 사전 위험 감소
요구사항 변경, 재품 개발 지연 등에 효과적으로 대응 가능
단점 : 프로젝트 소요 기간 증가 가능성, 정확한 위험 분석의 필요성
상대적으로 복잡하여 프로젝트 관리 어려움
애자일 방법론(Agile Development)
절차보다는 사람이 중심으로 변화에 유연하게 적응하면서 SW를 개발하는 방법론
특징 : 개발 기간이 짧으며(프로세스를 짧게 짧게), 개발과 함께 즉시 피드백을 받아 유동적으로 개발
UP (Unified Process)
기존의 작업을 병렬적으로 진행
각 step마다 집중해야 하는 작업이 조금씩 차이가 있음
평가는 반복마다 이루어짐
도입(Inception) -> 상세(Elaboration) -> 구축(Construction) -> 이행(Transition)
장점
위험 요소 초기 발견 가능
아키텍쳐에 대한 정의를 중요한 요소로 삼고 관리하기 때문에 견고하고 변경관리가 용이
단점
컨셉이 복잡
병렬적으로 수행되기 때문에 관리를 잘못하면 프로젝트 진행이 어려움
XP(eXtreme Programming)
짧은 주기, 여러 번의 피드백, 쓸 데 없는 산출물을 줄인다, 실천 사항(10~12개를 정해 놓는다)
요구사항 변경이 빈번한 소규모 프로젝트에 적합
4가지 가치 : 의사소통, 피드백, 단순성, 용기
스크럼(Scrum) : 매일 정해진 시간, 장소에서 짧은 개발을 하는 팀을 위한 프로젝트 관리 방법론
린(Lean) : 낭비 요소를 제거하여 품질을 향상시킨 방법론