01 소프트웨어 공학
요구사항 분석에서부터 유지보수에 이르기까지 전 과정에 걸쳐 예상되는 어려움을 해결하기 위한 체계적인 관리와 효율적 업무 수행을 지원해 주는 기술, 기법 등을 제공하는 기술
✏️ 3가지 핵심 요소
◾️ Process : 체계적인 업무 방식 및 흐름의 정의와 이를 적용할 수 있는 프로세스
◾️ People : 전문적인 지식을 갖춘 조직 및 인력
◾️ Technology : 정의된 업무 방식과 조직 인력이 효율적으로 운영되기 위한 기반 인프라 기술
3가지 핵심 요소를 균형 있고, 조화롭게 갖추고, 이를 유지하기 위한 지속적인 노력이 필요하다.
✏️ 4가지 중요 요소
1️⃣ 방법
◾ 프로젝트 계획 수립과 추정, 시스템과 소프트웨어 분석, 자료구조, 프로그램 구조, 알고리즘, 코딩, 테스팅, 유지 관리와 같은 작업들로 구성
◾ 소프트웨어 품질에 대한 일련의 평가 기준 도입
2️⃣ 도구
◾ 어떤 일을 수행할 때 생산성 혹은 일관성을 목적으로 사용하는 방법들을 자동화나 반자동화시켜 놓은 것
◾ 요구 관리 도구, 모델링 도구, 형상관리 도구, 변경 관리 도구가 존재
◾ 도구들이 통합되어 하나의 도구가 생성한 정보를 다른 도구가 사용할 수 있을 때, 소프트웨어 개발을 지원하는 시스템으로 설정
3️⃣ 절차
◾ 방법과 도구를 결합하여 그것으로 하여금 소프트웨어를 합리적이고 적시에 개발할 수 있도록 함
◾ 적용된 방법들, 요구되는 결과물(문서, 보고서 등), 품질을 보증하고 변경을 조정하게 도와주는 제어들, 소프트웨어 관리자들이 진행을 평가하게 해주는 마일스톤 등의 순서로 정의
4️⃣ 사람
◾ 사람과 조직에 의해서 움직이기 때문에 사람에 대한 의존성이 상대적으로 큼
02 소프트웨어 개발 생명 주기
사용자 환경 및 문제점 이해에서 시작하여 운용/유지 보수에 이르기까지의 모든 과정을 의미
일반적으로 타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수로 구성
🎈 목적
◾️ 프로젝트 비용 산정과 개발 계획 수립, 기본 골격 구성
◾️ 용어의 표준화
◾️ 프로젝트 관리
🧵 모델
선택한 모델은 프로젝트에 존재하는 리스크/불확실성을 최소화시킬 수 있어야 함
1️⃣ V 모델
◾ 프로젝트 관리자와 개발자에게 프로젝트 수행 동안 어떤 활동이 수행되어야 하는지 명확하게 보여줌
◾ 소프트웨어 개발에 대해 잘 알지 못하는 고객을 이해시키는 것이 용이함
◾ 시스템의 요구사항이 모두 식별되고 명확할 때 이상적인 모델
특징
- 프로젝트에 적용, 관리하기가 용이함
- 개발 활동의 시작/종료 조건 및 프로젝트를 효과적으로 관리할 수 있는 척도 등이 명확하게 정의될 수 있음
- 프로젝트의 검증 및 확인을 강조하는 모델
- 테스트 동안 결함이 발견되었을 경우, 개발 활동의 어느 단계를 재 수행되어야 하는지 알 수 있음
2️⃣ VP 모델 (V Model with Prototyping)
◾ 프로토타이핑은 시스템에 대한 이해 또는 리스크, 불확실성 요소와 같은 이슈를 해결하기 위해 시스템 혹은 시스템의 일부분을 빠르게 개발하는 방법. 무엇이 필요하고 무엇이 개발되어야 하는지에 대한 개발자와 고객이 공통적인 이해를 이끌어 낼 수 있음
◾ V 모델에 프로토타이핑 기법을 추가함으로써 프로젝트의 불확실성 요소나 리스크를 줄일 수 있음
3️⃣ 점증적 모델 (Incremental Model)
◾ 시스템 개발 시간을 줄일 필요가 있을 경우 유용
◾ 대부분의 요구사항이 정의되어 있지만, 시간이 지남에 따라 개선의 여지가 있는 경우 유용
◾ 핵심이 되는 부분을 먼저 개발하여 동작 가능하게 만든 후 나머지 기능 구현
◾ 개발 초기의 외부 인터페이스(H/W and S/W)에 대한 리스크를 줄이는 데 유용하게 적용될 수 있다.
4️⃣ 진화 모델 (Evolutionary Model)
◾ 시스템 개발 시간을 줄일 필요가 있을 경우 유용
◾ 시스템 명세가 전체적으로 불분명할 경우, 또 제품의 개선이 지속적으로 요구되는 경우에 적합
◾ 점증적 모델과 달리 전체 시스템에 대한 개발 단계가 여러 번 반복됨
◾ 하나의 시스템이 개발되어 사용되면서 변경 사항이 도출되고, 이 변경사항은 다음 시스템 개발에 반영됨
◾ 변경사항은 비기능적 사항에 대한 변경을 포함
03 소프트웨어 개발 방법론
개발 단계를 각각 정의하고 각 단계별 수행 활동, 산출물, 검증절차, 완료 기준을 정의하고, 개발 계획, 분석, 설계 및 구현의 수행단계에 대해 정형화된 방법과 절차, 지원 도구를 정의한다.
🎈 필요성
◾ 개발 경험의 축적 및 재활용을 통한 개발 생산성 향상
◾ 효과적인 프로젝트 관리
◾ 공식 절차와 산출물을 제시하고 표준용어를 통일하여 의사소통 수단 제공
◾ 각 단계별 검증과 승인된 종료를 통해 일정 수준의 품질 보증
🎈 소프트웨어 개발 방법론 비교
🎈 소프트웨어 개발 단계
1. 요구사항 분석
◾ 무엇을 개발할 것인가를 정확히 결정
◾ 사용자의 요구에 대하여 이해하는 단계
◾ 개발 비용을 감소시킬 수 있는 결정적 단계
2. 설계
◾ 시스템 설계는 서브 시스템들로 이루어지는 시스템 구조를 결정, 서브 시스템들은 하드웨어나 소프트웨어 등의 구성요소에게 할당
◾ 설계는 품질에 직접적인 영향
◾ 설계가 제대로 되지 않으면 시스템 안정감 저하
◾ 안정감 없는 시스템은 유지보수도 어려움
3. 구현
◾ 설계 명세를 기반으로 요구사항을 만족할 수 있도록 프로그래밍
◾ 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 코딩
◾ 코딩 표준을 정하고, 이를 기반으로 명확하게 코드를 작성하는 것이 중요
4. 테스팅
◾ 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지에 대해 수동 또는 자동화된 방법을 동원하여 검사, 평가
◾ 소프트웨어 품질 보증을 위한 마지막 단계. 소프트웨어의 품질을 확보하기 위해 결함을 찾아내는 일련의 작업
◾ 개발한 소프트웨어의 품질에 대한 평가와 품질 향상을 위한 수정 작업 포함
04 애자일 개발 방법론
1️⃣ XP (eXtreme Programming)
◾ 중소 규모 개발 조직에 적합한 경량화된 개발 방식
◾ 반복적 개발 방법론 (프로젝트 수행 과정에 여러 번의 반복이 있으며 테스트 결과에 따라 반복적으로 업무 수행함)
🎈 XP 개발 절차
◾ 유저 스토리 : 요구사항 수집, 의사소통의 도구를 말하고 기능 단위의 필요한 내용 간단히 기재
◾ 스파이크 : 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램. 사용자 스토리의 신뢰성 증대, 기술 문제의 위험 감소
◾ 릴리즈 계획 : 전체 프로젝트에 대한 배포 계획을 수립하여 하나의 반복을 1~3주로 나누고 반복을 균일하게 유지
◾ 승인 테스트 : 릴리즈 전 인수 테스트. 고객이 직접 수행
◾ 작은 릴리즈 : XP 주기의 마지막 단계. 소규모로 빈번하게 배포하여 고객에게 여러 이득을 조기에 제공
🎈 XP의 가치 : 용기, 단순성, 의사소통, 피드백, 존중
🎈 XP 기본 실천 방법
개발
◾ 단순한 설계
◾ 테스트 기반 개발
◾ 리팩토링 : 코드의 중복과 복잡성을 제거하여 기존 코드의 디자인 향상
◾ 코딩 표준
◾ 짝 프로그래밍 : 두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 개발 진행
◾ 코드 공유
◾ 지속적인 통합
관리
◾ 계획 게임 : 프로젝트 전체 계획과 주기 계획 세우고 실행과 피드백 통해 업데이트 유지
◾ 작은 릴리스 : 실행 가능한 모듈을 가능한 한 빨리 배포하여 고객이 수시로 확인 가능하도록 함
◾ 메타포 : 시스템에 대한 전체 모습을 이해하기 쉬운 그림과 스토리로 표현
환경
◾ 주당 40시간 작업
◾ 현장 고객 : 실제 시스템을 사용한 고객이 개발 현장에 상주하게 함
2️⃣️ 스크럼 (SCRUM)
추정 및 조정 기반의 경험적 관리기법의 대표적인 형태
🎈 스크럼 역할자
◾ 제품 책임자
- 제품 기능 목록에 해당하는 제품 백로그 만들고 우선순위를 조정하거나 새로운 항목 추가하는 일 관리
- 스프린트 계획 수립 시점에는 핵심 역할 담당
- 스프린트 시작 후에는 가능한 팀의 운영에 관여하지 않는 것을 권장
◾ 스크럼 마스터
- 팀의 업무를 방해하는 요소 제거에 노력
- 원칙과 가치를 지키면서 팀이 개발 진행할 수 있도록 지원
◾ 스크럼 팀
- 일반적으로 스크럼 팀은 최소 5명에서 최대 9명으로 구성
- 사용자 스토리를 사용하여 한 스프린트 동안에 개발할 기능 도출
🎈 스크럼 프로세스
◾ 스프린트(Sprint) : 달력 기준 1~4주 단위의 반복 개발 기간
◾ 3가지 산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트
◾ 3가지 미팅 : 일일 스크럼, 스프린트 계획, 스프린트 리뷰
👉 제품 백로그
◾ 제품에 담고자 하는 기능의 우선순위를 정리한 목록
◾ 고객을 대표하여 제품 책임자가 주로 우선순위 결정
◾ 사용자 업무량에 대한 추정은 주로 스토리 포인트라는 기준 이용
👉 스프린트 백로그
◾ 하나의 스프린트 동안 개발할 목록
◾ 사용자 스토리와 이를 완료하기 위한 작업을 과업(task)으로 정의
◾ 각각의 과업의 크기는 시간 단위로 추정
👉 소멸 차트
◾ 개발을 완료하기까지 남은 작업량을 보여주는 그래프
◾ 각 이터레이션 별로 남아있는 작업량을 스토리 포인트로 나타낸 것
👉 스프린트 계획
각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할 항목 선택
각 항목에 대한 담당자 배정, 태스크 단위로 계획 수립
👉 일일 스크럼
매일 진행하는 15분 간의 프로젝트 진행사항을 공유하는 회의
모든 팀원이 참석하여 매일매일 각자가 한 일, 할 일, 문제점 등 이야기
👉 스프린트 리뷰
스프린트 목표를 달성했는지 작업 진행과 결과물 확인하는 회의
스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백 받음
스크럼 마스터는 스프린트 동안 잘된 점, 아쉬웠던 점, 개선사항 등을 찾기 위한 회고 진행
🎈 스크럼 특징
◾ 투명성 : 스크럼 회의, 소멸 차트, 스프린트 리뷰 등을 이용하여 프로젝트의 상태나 문제점을 효과적으로 파악
◾ 타임 박싱 : 스크럼을 진행하는 데 들어가는 시간제한함으로써 프로젝트 진행에만 집중하도록 함
일일 스크럼은 매일 15분 간, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행
◾ 커뮤니케이션
◾ 경험주의 모델 : 프로젝트별로 고유한 상황과 특징을 가지므로 스크럼은 기본적인 구조만 동일할 뿐 팀마다 달라지는 것을 인정
'TOPCIT > M1 소프트웨어 개발' 카테고리의 다른 글
| Ⅱ소프트웨어 재사용 (0) | 2022.07.29 |
|---|
