그냥 게임개발자
01. 소프트웨어 개발 방법론-01 본문
(1) 소프트웨어 생명주기 모델(SDLC; SoftWare Development Life Cycle) 개념
- 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
- 시스템이 개발 될 때부터 운용과 유지보수를 거쳐 생애를 마칠때까지 어떠한 순서를 밟는지에 대한 작업 프로세스 모델화한 것
1. 요구분석
- 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
- 기능 요구사항, 비기능 요구사항
2. 설계
- 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계
- 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계
3. 구현
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계
- 인터페이스 개발, 자료구조 개발, 오류 처리
4. 테스트
- 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
- (단통시인) 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
5. 유지보수
- 시스템이 인수되고 설치된 후 일어나는 모든 활동
- 예방, 안전, 교정, 적응, 유지보수
소프트웨어 생명주기 모델 종류 (폭프나반)
1. 폭포수 모델 (Waterfall Model)
- 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
- 가장 오래된 모델
- 요구사항 변경 어려움
절차 : 타당성 검토 -> 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
2. 프로토타이핑 모델(Prototyping Model)
- 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
3. 나선형 모델(Spiral Model)
- 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
절차(계위개고) : 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
4. 반복적 모델(Iteration Model)
- 구축대상을 나누어 병력적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델
소프트웨어 생명주기 모델 간 비교
구분 | Waterfall Model | Prototyping Model | Spiral Model | Iteration Model |
절차도 | 1. 요구사항 분석 2. 설계 3. 구현 4. 테스트 |
1. 요구사항 분석 2. 프로토타입 개발 3. 프로토타입 평가(맘에 안들시 다시 1번) 4. 구현 5. 테스트 |
1. 계획 및 정의 2. 위험 분석 3. 개발 4. 고객 평가(맘에 안들시 1번) |
개발 대상 1. 분석, 분석, 분석 2. 설계, 설계, 설계 3. 구현, 구현, 구현 통합 |
특징 | 순차적 접근 | 프로토타입 개발 | 위험분석, 반복 개발 | 증분방식으로 병행 개발 |
장점 | 이해가 용이 관리가 편리 |
요구분석 용이 타당성 검증 가능 |
위험성 감소와 변경에 유연한 대처 | 병행 개발로 인한 일정 단축 가능 |
단점 | 요구사항 변경이 어려움 | 프로토타입 폐기에 따른 비용 증가 | 단계 반복에 따른 관리 어려움 | 병행 개발에 따른 관리 비용 증가 |
(2) 소프트웨어 개발 방법론(Software Development Methodology)
- 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론
○ 소프트웨어 개발 방법론 종류
1. 구조적 방법론(Structured Development)
- 전체 시스템을 기능에 따라 나누어 개발, 이를 통합하는 분할과 정복 접근 방식의 방법론
- 나씨 슈나이더만(Nassi - Shneiderman)차트 사용
*나씨 슈나이더만 차트 : 논리의 기술에 중점을 둔 도형식 표현 방법, 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합.
2. 정보공학 방법론(Information Engineering Development)
- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
3. 객체지향 방법론(Object - Oriented Development)
- '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
- 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
- 객체, 클래스, 메시지를 사용
4. 컴포넌트 기반 방법론(CBD; Component Based Development)
- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 새로운 기능 추가 쉬움(확장성)
- 소프트웨어 재사용 가능
5. 애자일 방법론(Agile Development)
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
6. 제품 계열 방법론(Product Line Development)
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어를 작성하는 데 유용한 방법론
- 영역 공학과 응용 공학으로 구분
* 영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
* 응용 공학 : 제품 요구분석, 제품 설계, 제품을 구현하는 영역
애자일(Agile)
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
애자일 방법론 등장 배경
[ 소프트웨어 개발 환경의 변화 ]
- 소프트웨어 개발 트렌드가 모바일 환경으로 변화
[ 기존 개발 방법론의 한계 ]
- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어렵기에 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성이 증가
애자일 방법론 유형 (XP, 스크럼, 린)
◎XP(eXtreme Programming)
- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 1~3주의 반복(Iteration) 개발 주기
- 5가지 가치와 12개의 실천항목 존재
XP의 5가지 가치(용단의 피존)
1. 용기(Courage)
- 용기를 가지고 자신감 있게 개발
2. 단순성(Simplicity)
- 필요한 것만 하고 그 이상의 것들은 하지 않음
3. 의사소통(Communication)
- 개발자, 관리자, 고객 간의 원활한 소통
4. 피드백(Feedback)
- 의사소통에 대한 빠른 피드백
5. 존중(Respect)
- 팀원 간의 상호 존중
XP의 12가지 기본 원리
1. 짝 프로그래밍(Pair Programming)
- 개발자 둘이서 짝으로 코딩하는 원리
2. 공동 코드 소유(Collective Ownership)
- 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
3. 지속적인 통합(CI; Continuous Integration)
- 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
4. 계획 세우기 (Planning Process)
- 고객이 요구하는 비즈니스 가치를 정의, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
5. 작은 릴리즈(Small Release)
- 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다는 원리
6. 메타포어(MetaPhor)
- 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
7. 간단한 디자인(Simple Design)
- 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
8. 테스트 기반 개발(TDD; Test Driven Develop)
- 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
9. 리팩토링(Refactoring)
- 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
10. 40시간 작업(40-Hour Work)
- 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
11. 고객 상주(Ons Site Customer)
- 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
12. 코드 표준(Coding Standard)
- 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리
◎스크럼(SCRUM)
- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
1. 백로그(Backlog) - 제품과 프로젝트에 대한 요구사항
2. 스프린트(Sprint) - 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
3. 스크럼 미팅(Scrum Meeting or Daily Meeting) - 매일 15분 정도 미팅으로 To-Do List 계획 수립
4. 스크럼 마스터(Scrum Master) - 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
5. 스프린트 회고(Sprint Retrospective) - 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
6. 번 다운 차트(Burn Down Chart) - 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
◎린(LEAN)
- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- JIT(Just In Time), 칸반(Kanban)보드 사용
* 7가지 원칙 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
비교대상 | 애자일 방법론 | 전통적 방법론 |
계획 수립 | 유동적 범위 설정 | 확정적 범위 설정 |
업무 수행 | 팀 중심 업무 수행 | 관리자 주도적 명령과 통제 개인 단위로 업무 수행 |
개발/검증 | 반복 주기 단위로 소프트웨어를 개발/ 검증 | 분석/설계/구현/테스트를 순차적으로 수행 |
팀관리 | 업무 몰입, 팀평가 | 경쟁, 개별 평가 |
문서화 | 문서화보다는 코드를 강조 | 상세한 문서화를 강조 |
성공 요소 | 고객 가치 전달 | 계획/일정 준수 |
유형 | XP, 스크럼, 린 | 폭포수, 프로토타입, 나선형 |
'나만의 정처기 공부' 카테고리의 다른 글
2. 화면설계 (0) | 2022.03.08 |
---|---|
1. 요구사항 확인 (0) | 2022.03.07 |
02. 현행 시스템 분석 (0) | 2022.02.08 |
정처기 예상문제01 푼 거 (0) | 2022.02.08 |
01. 소프트웨어 개발 방법론-02 (0) | 2022.02.07 |