소프트웨어의 정의와 특징
- 소프트웨어 : 프로그램(코드)를 비롯, 개발 과정 중 생성되는 모든 산출물과 각 단계에서 만들어지는 각종 문서, 매뉴얼 등 전부(자료 구조, DB 구조, 테스트 결과 등)
소프트웨어 특징
- 제조가 아닌 개발
- 제조는 개인 능력에 따른 결과물의 차이가 크지 않음
- 하지만 개발은 제조와 달리 개인 능력에 따른 차이가 큼 - 소모가 아닌 품질 저하
- 하드웨어 : 오래 사용하면 부품이 닳고 기능이 떨어짐
- 소프트웨어 : 닳지 않고 시간이 지나도 기능이 떨어지지 않으나, 사용 시작 단계부터 사용자의 요구가 계속 발생하고 이런 요구를 모아 시스템에 반영하면(기능 추가, 향상 등) 실패율이 급격히 증가할 수 있음
소프트웨어 공학의 정의와 소프트웨어 개발의 생명주기
- 소프트웨어 공학이란, 품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획을 세우고 개발, 유지 및 관리 하는 전 과정에서 수학, 과학, 공학적 원리와 방법을 적용해 필요한 이론과 기술, 도구들에 관해 연구하는 학문
- 소프트웨어의 개발 생명주기 : 계획 > 분석 > 설계 > 구현 > 테스트 > 유지보수
소프트웨어 개발 프로세스
- 소프트웨어 개발 프로세스란 좁은 의미에선 개발에 필요한 절차나 과정을 의미, 넓은 의미로는 개발에 필요한 방법, 도구를 비롯해 개발과 관련된 절차를 따라 작업을 수행하는 참여자까지 포함함
소프트웨어 개발 프로세스 모델
- 정의
- 소프트웨어 개발 프로세스 모델은 어떻게 개발할 것인지에 대한 전체 흐름을 체계화한 개념
- 개발 계획부터 최종 폐기까지 전 과정을 순차적으로 다룸 - 목적
- 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
- 고품질의 소프트웨어 제품을 만드는게 목적 - 역할
- 프로젝트 전체 골격을 세우고, 비용산정 뿐 아니라 여러 자원을 산정하고 분배 가능
- 참여자 간 의사소통 기준을 정할 수 있고, 용어의 표준화 가능
- 개발 진행 상황을 명확하게 파악 가능하며, 단계별 생성되는 문서를 포함한 산출물을 검토할 수 있게 함
주먹구구식 모델
- 공식적인 가이드라인, 프로세스가 없는 개발 방식
- 즉흥적 소프트웨어 개발 혹은 코딩과 수정 모델이라고도 부름
- 일단 작성하고 요구분석, 설계, 유지보수에 대해 생각함
- 첫 릴리즈 코드를 작성해 제품을 완성하고, 문제가 있으면 수정하고 아니면 마는 식으로 사용
- 단점
- 정해진 개발 순서, 단계별 문서화된 산출물이 없어 유지보수가 매우 어려움
- 프로젝트 전체 범위를 알기도 어려우며 좋은 아키텍쳐 생산도 불가능
- 개발자가 일을 효과적으로 분담할 수 없음
- 프로젝트 진척 상황을 파악할 수 없음
- 코딩부터 실행하므로, 지속적인 수정이 이루어질 가능성이 높고 이로 인해 프로그램 구조가 나빠져 수정이 어려워짐
선형 순차적 모델(폭포수 모델)
- 선형 순차적 모델은 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델(고전적 생명주기, 거스르기 불가능)
- 소프트웨어 공학의 대명사로, 초깅 개발된 전통적인 모델
- 공장 생산 라인의 작업 프로세스와 유사
개발 절차
- 폭포의 물이 위에서 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수 단계가 하향식으로 진행
- 각 단계가 끝날때 확실히 끝나고 그 결과를 철저히 확인한 이후에 다음 단계로 넘어감
- 이 모델을 적용한 개발 절차에서는 요구사항 분석 단계가 끝나면 '요구분석명세서'라는 문서를 작성
- 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계로 넘어감
장점과 단점
- 장점
- 분리가 명확하므로 관리가 용이하고 체계적으로 문서화 할 수 있음
- 요구사항의 변화가 적은 프로젝트에 적합함(요구분석명세서 작성 이후에는 변경이나 추가 반영이 불가능함) - 단점
- 각 단계는 앞 단계과 완료되어야 수행 가능함
- 각 단계마다 작성된 결과물이 완벽한 수준이어야 다음 단계에 오류가 넘어가지 않음
- 사용자가 중간에 가시적인 결과를 볼 수 없어 답답할 수 있음
선형 순차적 모델(V 모델)
- 폭포수 모델의 변형으로, 테스트 단계를 확장해 테스트 단계가 분석 및 설계와 어떻게 관련되는지 나타냄
- 폭포수 모델이 산출물 중심이라면, V모델은 각 개발 단계를 검증하는데 초점을 두므로 오류를 줄일 수 있음
진화적 프로세스 모델
- 새로운 요구가 수시로 발생해 이에 민첩하게 대응할 수 있는 방법
- 초기의 사용자 요구에 따라 가상으로 실행되는 초기 버전의 프로토타입 작성
- 사용자는 사용자 인터페이스 중심의 화면과 실행 후 나타나는 가상의 결과 화면을 확인
- 변경된 요구사항을 반영하거나 추가해 2차 프로토타입을 만들어 사용자에게 보여주며 이 과정을 만족할 때 까지 반복
진화적 프로세스 모델(프로토타입 모델)
- 앞서 미리 제작해보는 원형, 시제품
- 소프트웨어적으로는, 완전한 소프트웨어 이전에 사용자의 요구대로 일단 모형을 만들고 사용자와 의사소통하기 위한 도구로 활용
프로토타입 모델의 개발
- 프로토 타이핑 : 프로토타입을 만드는 것
- 초기 요구사항으로 1차 프로토타입 생성 -> 사용자는 이걸 보고 추가 요구를 하고, 개발자는 이를 받아 2차 프로토타입 생성 -> 반복
- 프로토타입 모델은 사용자의 요구가 불투명하고 요구사항의 변화가 잦은 경우에 적합
프로토타입 모델의 장점과 단점
- 장점
- 프로토타입을 이용하여 사용자-개발자 간 구체적이고 원활한 의사소통 가능
- 요구사항을 반복하여 요구가 충분히 반영된 요구분석명세서 작성 가능
- 개발 소프트웨어의 모습을 예측할 수 있음
- 사용자 요구가 충분히 반영되어 나중의 유지보수 비용을 줄일 수 있음 - 단점
- 반복적인 단계로 비용 산정이 어려움
- 개발 범위가 명확하지 않아 개발 목표나 종료 시점이 불명확해질 수 있음
- 프로토타입에 따른 추가 비용이 발생 가능
프로토타입 모델의 개발 절차
- 요구사항 정의 및 분석
- 폭포수 모델과 달리 1차로 개략적인 요구사항을 정의한 이후 n차까지 반복하면서 완성도를 높이는 방식 - 프로토타입 설계
- 동작이 가능하도록 구현하는 것이 아니라 입력, 출력화면을 통해 사용자가 만들어질 시스템이 어떻게 수행될 수 있는지 파악할 수 있도록 UI 중심으로 설계 - 프로토타입 개발
- 프로토타입 개발은 취지에 맞게 가상 수행을 전제로 한 실행을 보여주는 것이 우선 - 사용자에 의한 프로토타입 평가
- 프로토타입 모델에서 가장 중요한 단계
- 사용자는 1차로 개발된 프로토타입을 보며 요구사항 반영 여부를 확인
- 사용자가 확인후 추가 요구사항을 전달
- 개발자는 이를 반영해 n차까지 설계하는 식으로 반복
진화적 프로세스 모델(나선형 모델)
- 초기 요구분석 후 프로토타입 개발 이전 위험 분석 단계를 거침
- 위험 분석 단계에서 위험 요소는 개발 과정에 방해되는 모든 것
나선형 모델 개발 절차
- 계획 및 요구분석 단계
- 개발 의도를 파악해 프로젝트 목표를 명확하게, 여러 조건의 대안을 고려한 계획 수립
- 사용자 요구를 통해 파악 기능 요구사항과 비기능 요구사항을 정의하고 분석 - 위험 분석 단계
- 프로젝트 수행에 방해되는 위험 요소를 찾아 목록을 작성해고 예방 대책을 논의 - 개발 단계
- 프로토타입을 만드는 과정. 다른 소프트웨어 개발 프로세스에서 설계 및 구현에 대응 - 사용자 평가 단계
- 사용자가 만족할 때 까지 n번 반복해 추가 요구사항이 없으면 최종 제품 개발
- 프로토타입 모델과 마찬가지로 매우 중요
나선형 모델의 장점과 단점
- 장점
- 위험을 미리 인식하고 개발하므로 프로젝트 중단과 같은 심각한 사태의 위험이 적음 - 단점
- 요구분석, 위험분석, 개발, 사용자 평가가 반복되므로 프로젝트 기간이 길어질 수 있음
- 반복될수록 관리가 어려움
- 위험 관리가 중요한만큼 관리 전문가가 필요하다는 부담감
단계적 개발 모델
- 개발자가 릴리즈1을 개발해 사용자에게 제공하고, 이를 사용하는 동안 개발자는 릴리즈 2를 개발
- 개발과 사용을 병행하는 과정을 반복하면서 완료
- 구성방법에 따라 점증적, 반복적 개발방법으로 나뉨
단계적 개발 모델(점증적)
- 개발 범위의 증가
- 중요하다고 생각되는 부분부터 차례로 개발한 후 그 일부를 사용하면서 범위를 점차 늘려가는 방식
- ex). 3층 건물 건설 시, 1층을 완벽하게 지어 입주시킨 후, 여건이 갖추어지면 2, 3층을 올리는 방식
- 장점
- 한꺼번에 많은 비용을 들이지 않아도 됨
- 완전히 새로운 시스템을 도입할 때 조직이 받는 충격 완화
- 소프트웨어 단계적 도입은 조직에 자연스럽게 변화를 줄 수 있음 - 단점
- 처음 설계부터 이후 개발할 다른 서브시스템과 연관성을 고려해야함
- 이미 개발된 서브시스템들과 통합 시 어려움이 있음
단계적 개발 모델(반복적)
- 초기에 시스템 전체를 개발해 인도한 후, 각 서브시스템의 기능과 성능을 변경, 보강해 완성도를 높임
- 초기 요구사항이 불분명한 경우 적합
통합 프로세스 모델
- 반복적 개발 방법론의 등장
- 폭포수 모델은 각 단계별 깔끔하게 떨어지지만, 사용자 요구사항이 많은경우 대처가 불가
- 폭포수 모델의 문제점을 해결하기 위해 계속 작업을 반복하는 반복적 개발 방법론의 등장
- 통합 프로세스 모델은 반복적 생명주기를 기반으로 하는 프로세스 모델 중 가장 많이 사용
통합 프로세스 모델의 절차
- 크게 4단계, 도입, 구체화, 구축, 전이로 나눔
- 각 단계도 여러 개의 작은 단위로 나누어 각 반복구간을 하나씩 정함
- 이때 반복 주기를 시작하기 전 기준선(베이스라인)계획을 설립
- 그리고 반복 주기가 끝나면 실행 가능한 산출물이 도출되며, 이것을 위험 요소의 제거 여부를 판단하는 데 사용
- 반복 구간 하나가 수행될 때 전체 9개의 개발 영역이 대부분 수행(BM 모델링, 요구사항 정의, 분석및설계, 구현, 테스트, 배치, 형상관리, 프로젝트관리, 환경 점검)
통합 프로세스 모델의 개발 순서
- 관리 가능한 소규모 단위로 나뉨
- 그 안에서 수행될 작은 단위의 계획을 세움(위의 9가지 영역도 작은 단위 내에서 이루어짐)
- 각 반복에서 작은 부분을 통합, 테스트, 실행
도입단계
- 준비, 인지, 시작, 발견, 개념정립 단계와 같이 다양한 이름으로 불림
- 구현, 테스트, 배치 작업은 거의 없고 '비즈니스 모델링'과 '요구사항 정의' 관련 작업이 가장 많음
구체화 단계
- 상세, 정련 단계로도 불리고 보통 2~4개의 반복 단위로 구성
- 비즈니스 모델링, 요구사항 정의 작업은 점차 줄고, 분석 및 설계 작업이 크게 이루어짐
- 설계 결과에 따른 구현(코딩) 작업, 구현에 대한 단위 테스트가 조금씩 시작
구축 단계
- 구현 작업이 가장 많이 이루어짐
- 비즈니스 모델링, 요구사항 정의 작업이 많이 줄고, 분석 및 설계도 구체화 단계보다 줄어듬
전이 단계
- 이행 단계라고도 하며 사용자를 위한 제품을 완성하는 단계
- 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일들을 작업
도입, 구체화, 구축, 전이 단계의 공통 작업
- 분석, 설계, 구현, 테스트 작업을 공통으로 수행하되 각 단계별 수행하는 정도에는 차이가 있음
- 구체화와 전이단계는 2회, 구축 단계는 3회 or n회 반복
- 형상 및 변화관리, 프로젝트 관리, 환경 점검은 지속적으로 수행
애자일 프로세스 모델
- 애자일(agile) : 날렵한, 민첩한
- 고객의 요구에 민첩하게 대응하고, 그때마다 주어지는 문제를 풀어나가는 방법론
애자일의 기본 가치
- 프로세스와 도구 중심이아닌, 개개인간의 상호소통을 중시
- 문서 중심이아닌 실행 가능한 소프트웨어를 중시
- 계약과 협상 중심이 아닌, 고객과의 협력을 중시
- 계획 중심이 아닌 변화에 대한 민첩한 대응을 중시
- 환경과 고객의 변화에 능동적으로 대처하는 것을 강조
애자일의 원칙
- 최우선 목표는 고객을 만족시키기 위해 가치있는 소프트웨어를 빨리, 지속적 제공하는 것
- 개발 후반에 추가되는 요구도 받아들임
- 고객의 경쟁력을 위해 요구사항 변경을 받아들임
- 동작 가능한 소프트웨어를 2주, 길면 2개월 간격으로 자주 고객에게 전달, 짧을수록 좋음
- 진척 상황 척도의 가장좋은 척도는 실행가능한 소프트웨어 시연
- 효율성 증가를위해 정기적 미팅을 진행
애자일 프로세스 개발 방법
- 가장 기본이 되는 1차 요구사항을 분석하고 이를 반복으로 나누어 개발
- 사용자가 릴리즈 1을 사용하는 동안 개발자는 릴리즈 2를 개발
- 이때 좀 더 복잡한 기능을 추가해 마찬가지로 반복으로 나누어 개발
- 개발 방법은 반복적 개발을 통한 잦은 출시, 릴리즈를 목표로
- 실행 가능한 프로토타입을 만들어 사용자에게 확인받음
- 좀 더 빠른시간 내에 일부이지만 소프트웨어를 사용할 수 있게 하는것을 목표로
애자일 프로세스 모델(스크럼)
- 스크럼 : 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론으로 경험적 관리 기법 중 하나이며 구체적인 프로세스를 명확하게 제시하지 않음
스크럼 방식의 진행 과정
- 제품 기능 목록 작성
- 요구사항 목록에 우선순위를 매겨 제품 기능 목록 작성 - 스프린트 계획 회의
- 스프린트 구현 목록 작성
- 스프린트 개발 기간 추정 - 스프린트 수행
- 스프린트 개발
- 일일 스크럼 회의
- 스프린트 현황판 변경
- 소멸 차트 표시 - 스프린트 개발 완료
- 실행 가능한 최종 제품 생산 - 스프린트 완료 후
- 스프린트 검토 회의
- 스프린트 회고
- 두 번째 스프린트 계획 회의
제품 기능 목록
- 사용자가 요구하는 제품의 기능 목록
- 모든 요구사항에 대해 우선순위가 정해져 있음
- 제품 책임자가 요구사항 목록에 우선순위를 매겨 작성함
- 한 주기가 끝날 때 까지 수정하지 않음
- 사용자 스토리 이용
사용자 스토리
- 제품 기능이 도출되면 각 기능을 간략하게 서술
- 주로 한장의 포스트잇으로 작성
- 상세히 적지않고 개발자와 대화를 지속할 수 있는 단서 정도로만 활용할 수 있게 작성
작성기준
- 사용자 스토리는 서로 의존적이지 않아야 함
- 사용자 스토리는 언제든 변경할 수 있어야하므로 자세할 필요 없음
- 사용자의 이야기이므로 사용자가 이해할 수 있는 언어와 용어로 작성해야함
- 사용자에게 필요한 이야기이므로 개발자에게 필요한 내용을 서술해선 안됨
- 사용자 스토리를 보면 개발 규모, 투입 공수가 얼마나 필요할지 개발자들이 짐작할 수 있어야함
- 개발 규모가 적절해야함
- 구성 요소 확인을 위해 테스트가 가능한 테스트 케이스를 만들어야 함
스토리 포인트
- 요구사항의 규모를 측정하는 단위로, 업무량을 이용해 산정
- 스토리 간 상대적 업무량을 비교해 가장 적을 때 1로 정한 뒤 이를 기준으로 산정
- 일반적 소프트웨어 개발 방법론에서는 개발에 소요되는 시간을 일/주/월 시간 단위로 예측
- 애자일 방법론에서는 스토리 포인트라는 추상 개념으로 예측
스프린트 계획 수립
- 스프린트 : 작업량이 많지 않고 개발 기간도 짧은 경우를 의미 = 작은 단위의 개발 업무를 전력질주 수행한다는 뜻
- 하나의 스프린트에 사용자 스토리를 몇 개 포함할지는 스프린트 계획 회의에서 결정
- 보통 1~4주를 하나의 스프린트로 봄
- 외부 개발 방해 요소를 차단하는 것은 스크럼 마스터의 역할
- 하나의 스프린트 개발이 끝나면 사용자에게 시연하고 사용자는 피드백 제공
- 계획된 일정 안에 못 마치더라도 정해진 일정이 끝나면 하나의 스프린트는 끝남
스프린트 계획 회의
- 전체적인 스프린트 계획 회의
- 제품 책임자를 통해 사용자의 요구사항을 파악하는데 중점
- 이를 위해 스크럼 마스터는 제품 기능 목록을 검토하며 우선순위를 확인
- 그 배경, 목표에 대해 팀원과 토의하며 제품 책임자의 의도 파악 - 세부적인 스프린트 계획 회의
- 우선순위가 높은 항목을 어떻게 구현할 지 구체적 계획 설립
- 먼저 우선순위가 매겨진 사용자 요구사항 목록인 제품 기능 목록에서 개발 항목을 결정
- 스프린트 구현 목록을 작성하며 팀원들은 작업 수행에 필요한 시간을 추정
스프린트 구현 목록 작성
- 제품 기능 목록에 있는 스토리 중 선택
- 스프린트 계획 회의에서 결정
- 기준은 기간 내에 완료할 만큼의 스토리
소멸 차트
- 계획 대비 작업이 어떻게 진행되고 있는지 날짜별 남은 작업으로 나타냄
- 소멸 차트는 개발 후 남은 작업량을 표현하므로, 시간이 지남에 따라 차트가 감소함
일일 스크럼 회의 : 스크럼기간에 하는 회의
특징
- 매일 한다.
- 서서 한다.
- 약속된 시간에 한다.
- 짧게 한다
- 진행 상황만 점검
- 스프린트 구현 목록을 잘 개발하는지 확인
- 모든 팀원이 참석
- 한 사람씩 어제 한 일과 오늘 할 일을 이야기
- 한 사람씩 문제점 및 어려운점을 이야기
- 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트
- 개별 팀원에 대한 진척 상태 확인
- 그날 남은 작업량을 소멸 차트에 표시
스크럼 마스터의 역할
- 팀원들 개발에 방해되는 요소를 찾아 해결
- 개발자 개개인이 수행하는 일의 진행 상황 확인
- 소멸 차트에 남은 작업량 표시
스프린트 현황
- 개발 팀의 개발 현황을 나타냄
스프린트 진척 관리
- 각 작업에 대한 날짜별 작업시간, 남은시간 등을 기록해 진척 관리를 함
스크럼 진행 방식 정리과 스프린트 개발 완료 후
- 제품 책임자를 중심으로 제품 기능 목록 작성
- 스프린트 계획 회의에서 스프린트 구현 목록 작성
- 일일 스크럼 회의로 스프린트 개발
- 개발이 완료되고 최종 제품이 생산됨(모든 스프린트 주기가 끝났을 때)
스프린트 개발 완료 후
- 스프린트 검토 회의
- 하나의 스프린트 주기가 끝났을 때 실행 가능한 제품을 검토
- 스프린트 목표 달성 여부와 결과물을 확인하고 전체 흐름을 확인해 비즈니스 가치를 점검
- 스크럼 팀은 스프린트 동안 작업한 결과를 참석자에게 시연하고 요구사항에 부합하는지 검토
- 스크럼 마스터는 잘된, 안된, 개선할 점 등을 찾기 위해 회고할 수 있음
- 검토는 가능한 한 4시간 안으로 - 스프린트 회고
- 그동안 스프린트에서 수행한 활동을 되돌아보고 각종 검토를 진행
- 단점을 찾기보단 강점을 찾아 더 극대화하는데 중점
- 문제점 해결 방안을 찾기 위한 회의가 아니므로 기록하는 정도만 진행
- 추정 속도와 실제 속도를 비교하고 차이가 크면 이유 분석(품질은 측정X)
배포 목록 작성
- 배포 사용자에게 시스템 일부를 제공하는 것
- 배포 목록은 제품 기능 목록의 항목 중 이번 배포본에 포함하기로 결정한 것들
- 배포 목록을 작성하면 이번 배포본의 개발 범위, 일정을 수립할 수 있음
- 사용자에게 전달될 배포본의 기능 내역, 시기, 스프린트 주기, 배포일 결정
스크럼 방식의 장단점
- 장점
- 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분한 소통 가능
- 일일 회의를 함으로써 팀원 간 신속한 협조와 조율 가능
- 다른 개발 방법론에 비해 단순하고 실천 지향적
- 진행 현황을 볼 수 있어 신속하게 목표, 결과 추정 가능하며 목표에 맞게 변화 시도 가능 - 단점
- 반복 주기마다 실행 가능한 제품을 만들어야 하는데, 이 작업이 많아지면 시간이 더 필요
- 일일 스크럼 회의 시간이 길어지면 작업시간이 부족해짐
- 투입 공수를 측정하지 않으므로 얼마나 효율적으로 작업이 수행되는지 알 수 없음
- 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 품질의 정도를 알 수 없음