Transcript 02장 생명주기모델.
CHAPTER 2 SOFTWARE LIFE-CYCLE MODELS 학습목표 정보시스템들이 실무에서 어떻게 개발되는지 진화-트리 생명주기 모델 이해 소프트웨어 프로덕트들에 대한 변경의 부정 적인 영향 인식 반복적(Iteration)이고 점진적 (incrementation) 생명주기 모델 활용 초기에 위험을 완화시켜야 하는 중요성 인식 소프트웨어 프로덕션에 대한 Miller의 법칙 영향 이해 반복적-점진적 생명주기 모델의 강점 초기에 위험을 완화시켜야 하는 중요성 인식 다양한 생명주기 모델들을 비교 및 대조 2.1 Software Development in Theory 통상적으로 소프트웨어 프 로덕트는 1장의 서술처럼 개 발됨 • Linear • Starting “from scratch” (아무것도 없이 처음부터 시작) Figure 2.1 실무에서의 소프트웨어 개발 실무에서 소프트웨어 개발은 완전히 다름, 즉 • We make mistake • The client’s requirements change while the software product is being developed 2.2 Winburg市 공공수송시스템: Mini Case Study Episode 1: 첫 번째 버전 구현 Episode 2: 결함 발견 • 프로덕트는 구현결함(표 인식)으로 인해 긴 응답시간을 가짐 • -> 배정도실수 연산 때문 -> 단정도실수로 변경 • 구현을 변경하기 시작 Episode 3: 요구사항의 변경 • 문제: 복잡한 이미지 인식 알고리즘 • 더 빠른 알고리즘 사용 Episode 4: 새로운 설계의 채택 • 일정이 상당히 지연되고 예산은 초과 • 정확도 증가 요구(99.5%이상) - 개발 완료 Epilogue: 몇 년 후 이러한 문제의 재 발생 진화-트리 모델 Winburg Mini Case Study • 점선으로 작성된 사각형은 구현이 완성되지 않 은것 Figure 2.2 폭포수 모델 피드백 루프들을 갖는 선형 life cycle model • Waterfall model 은 이벤트 들의 순서를 보여줄 수 없음 Figure 2.3 진화-트리(Evolution-Tree) 모델 The explicit order of events is shown At the end of each episode • We have a baseline, a complete set of artifacts(산 출물) Example: • Baseline at the end of Episode 4: • Requirements3, Analysis3, Design4, Implementation4 2.3 Winburg 미니 사례연구의 교훈 실무에서 소프트웨어 개발은 Winburg 미니 사례 연구보다 더 무질서함 변경들이 항상 필요함 • 소프트웨어 프로덕트는 끊임없이 변화하는 실 • 세계(실무상)의 모델 소프트웨어 전문가들도 인간이므로 mistake들 을 만듬 2.4 Teal Tractors Mini Case Study Teal Tractors 소프트웨어 프로덕트가 만들어지는 동안 요구사항이 변경됨 회사가 캐나다로 확장함 (캐나다 트랙터 컴퍼니 인수) 수정 포함 내역: • 추가된 판매 지역 더하기 • 세금처럼 Canada에서 다르게 처리되는 비즈니스의 모 • 든 측면을 처리할 수 있게 확장되어야 함 두 국가의 화폐기준인 U.S dollar와 Canada dollar를 모 두 처리할 수 있게 확장되어야 함 이러한 수정은 있을 수 있음 • 회사로선 좋은 일,그러나 • 소프트웨어 프로덕트 담당부서의 입장에선 불행한 일 이동 대상 문제 (Moving Target Problem ) 소프트웨어가 개발되는 동안에 요구사항들이 변경되는 것 변경(Change)에 대한 이유가 좋을지라도, 소 프트웨어 프로덕트는 불리하게 (품질에) 타격 을 입을 수 있음 • 종속성들의 유발 어떤 변경에도 회귀결함의 원인이 될 수 있음 • 코드의 관련 없는 부문의 결함도 생길 수 있음 만약 너무 많은 변경이 있다면 • 전체 소프트웨어 프로덕트를 재설계하고 재구현 하여야 함 이동 대상 문제 (contd) 변경은 피할 수 없음 • 성장중인 회사는 언제나 변경하려 함 • 부정적인 변경들에 대해 만약 이들 변경을 요청 하는 개인이 엄청난 영향력을 갖고 있다면 소프트 웨어 프로덕트의 세부 유지보수성에 해가 되는 구 현중인 변경을 어느 누구도 막을 수가 없음 moving target problem의 해결방안은 없음 2.5 Iteration(반복)과 Incrementation(점진) 기본 소프트웨어 개발 프로세스(basic software development process)는 반복적 (iterative) • 각 버전이 이의 선행버전보다 우리의 목표에 근접 하게 되어 최종 버전은 우리가 만족하는 버전으로 구축하는 것 Miller의 법칙 언제나 인간은 거의 7개정도의 청크(chunk:정보 의 단위)에만 집중할 능력을 갖고 있다고 제시 더 많은 양의 정보를 다루기 위해, 단계적 정제 (stepwise refinement)가 사용됨 • 현재 가장 중요한 측면들에만 집중 • 그렇지 않은 측면들은 차후로 연기 • 모든 측면이 결국에는 다 처리되지만 단지 현재의 중요 도에 따라 순서대로 구축되는 것 이것이 점진적 프로세스(incremental process)임 2.5 반복과 점진 (contd) Figure 2.4 네 개의 점진들로 소프트웨어 구축 고전적 페이즈들과 웍플로우들의 비교 순차적 페이즈들은 실세계에서는 존재하지 않음 대신에 다음과 같이 다섯 개의 핵심 workflows (activities)는 전체 생명주기를 통해 수행됨 • Requirements workflow • Analysis workflow • Design workflow • Implementation workflow • Test workflow 웍플로우들 이들 다섯 개의 핵심 웍플로우들은 소프트웨어 프로덕트의 생 명주기 전체에서 수행 그러나 대부분의 경우 한 workflow가 다른 네 개의 workflow보 다 우선시될 시기가 있음 Examples: • 생명주기를 시작할 때 • 요구사항 웍플로우가 우선 수행 • 생명주기의 후반부 • 구현과 테스트 웍플로우가 우선 수행 계획수립(planning)과 문서화 활동들(documentation activities) 은 생명주기 전체에서 수행 2.5 반복과 점진 (contd) Iteration은 각 incrementation 동안에 수행됨 Figure 2.5 2.6 The Winburg Mini Case Study 재고 그림 2.6 (다음 슬라이드)은 반복-점진모델 위에 겹 쳐놓은 Winburg 미니 사례연구의 진화-트리 모델을 보여주고 있음 진화-트리 모델은 계속 testing을 한다는 가정 이기 때문에 test workflow는 보여주지 않음 반복과 점진 중심으로 구축됨을 보여줌. 2.6 Winburg Mini Case Study 재고 (contd) Figure 2.6 More on Incrementation (cont.) 각 에피소드는 increment와 일치 모든 increment는 모든 workflow를 포함하지 않 음 Increment B 완전하지 않음 – 완료가 안됨 점선은 유지보수를 나타냄 • Corrective maintenance, in all three instances • 수정적 유지보수의 인스턴스(세 개 각각) 2.7 반복과 점진의 위험들과 또 다른 측면들 반복과 점진에서 보는 또 다른 측면은 포로젝트 전체를 보다 소규모의 미니 프로젝트들(increments)로 분할하 는것 각 미니 프로젝트들은 다음과 같이 확장 • • • • • 요구사항 산출물 (Requirements artifacts) 분석 산출물 (Analysis artifacts) 설계 산출물 (Design artifacts) 구현 산출물 (Implementation artifacts) 테스팅 산출물 (Testing artifacts ) The final set of artifacts is the completed product 2.7 반복과 점진의 위험과 또 다른 측면 (contd) 각 미니 프로젝트동안에 • 산출물들을 확장하고 (incrementation); • 산출물들을 체크하고 (test workflow); • 만약 필요하다면 관련 산출물들을 변경 (iteration) 2.7 반복과 점진의 위험과 또 다른 측면 (contd) 각 반복은 소규모이지만 완벽한 폭포수 생명주기 모 델로 볼 수 있다는 점을 보여줌 각 반복 동안 소프트웨어 프로덕트의 일부분 (portion)를 선택 각 부분(portion)에 대해 개발 팀의 멤버는 다음과 같은 순으로 진행 • • • • Classical requirements phase Classical analysis phase Classical design phase Classical implementation phase 반복적-점진적 모델의 장점 소프트웨어 프로덕트가 수정되는 것을 체킹하는 다 중 기회들을 제공 • 모든 반복은 test workflow를 포함 • 각각의 많은 반복은 결함들을 발견하고 이들을 수정하 는 구체적인 기회를 제공 아키텍처의 강건성(robustness) 높다. • Architecture — the various component modules and • how they fit together Robustness — the property of being able to handle extensions and changes without falling apart(인도 후 유지보수 및 확장을 가능하게 하는 중요한 품질) 반복적-점진적 모델의 장점 (contd) 반복적-점진적 모델은 위험을 초기에 완화 시킬 수 있음 • 위험들은 소프트웨어 개발과 유지보수에 항상 내포되어 있음 항상 소프트웨어의 작업용 버전을 갖고 있 음 • 각 버전마다 고객의 요구와 변경을 결정함 -> 고객의 만족 보장 2.8 반복과 점진 관리하기 반복적-점진적 모델은 폭포수 모델처럼 조직 화되어 있음 반복적-점진적 모델을 사용해 소프트웨어 프 로덕트를 개발하는 것은 폭포수 모델을 모두 사용해 일련의 소규모 소프트웨어 프로덕트들 을 개발하는 것에 지나지 않음 각각의 increment는 waterfall mini project라 볼 수 있음 2.9 다른 생명주기 모델 다른 생명 주기 모델: • Code-and-fix life-cycle model • Waterfall life-cycle model • Rapid prototyping life-cycle model • Extreme programming and agile processes • Synchronize-and-stabilize life-cycle model • Spiral life-cycle model 2.9.1 코드-픽스 생명주기 모델 No requirements No analysis No design No specifications • Maintenance nightmare 소프트웨어를 개발 하기 위한 가장 쉬운 방법 가장 비용이 많이 드는 방법 Figure 2.7 2.9.2 폭포수 생명주기 모델 Figure 2.8 2.9.2 폭포수 생명주기 모델 (contd) 특징 • Feedback loops • Documentation-driven – 단계별 SQA 승인 • 단계별 테스팅 장점 • 문서화 (Documentation) • 유지보수는 더 쉬움 단점 • Specification document – 명세언어, DFD • 이해가 어렵다. 2.9.3 라피드 프로토타이핑 생명주기 모델 Rapid Prototyping Model Linear model “Rapid” 기능들만 보여주는 working model -> 해결방안 제시 Figure 2.9 2.9.4 Extreme Programming과 Agile Processes 프트웨어 개발에 반복적-점진적 모델에 기반 을 둔 약간은 모순된 새로운 접근법 Stories (클라이언트가 요구하는 특성들) • 각 스토리(story)에 소요되는 구현 기간과 소요 비용을 추정 • 다음 빌드(build)에 포함되어야 하는 스토리들을 선택 • 제안된 각 빌드들은 task라고 부르는 소규모 단위로 분해 • 우선 한 task에 대한 test-case 들을 작성 -> TDD(Test-Diven Development) Pair programming : 한 스크린상에서 파트너와 함께 작업하 는것 task들의 계속적인 통합 Unusual Features of XP XP 팀의 컴퓨터들은 작은 칸막이가 된 큰 사무실의 중앙에 설치 클라이언트 대표자는 항상 XP팀과 작업 개인이 2주 이상을 연속으로 작업할 수 없음 전문화(specialization)란 없음 Refactoring (design modification) : 전체적인 설계 단계 없이 프로덕트가 구축되는 동안 수정 Agile Processes A collection of new paradigms characterized by • 분석과 설계를 크게 강조하지 않음 • 더 빠른 구현 (작동 소프트웨어가 세부 문서화 • • 보다 중요하기 때문 ) 변경에 대한 응답 클라이언트와 협업의 중요성 Agile Processes 와 XP 의 평가 XP는 많은 소규모 프로젝트들에 성공적으로 사 용 • 중간 규모 또는 대규모 소프트웨어 프로덕트들에 사 용될 수 있다는 의미는 아님 주요 핵심 요소 : Agile processess가 소프트웨어 공학에서 정말로 주요 돌파구인지를 결정하는 핵 심 요소는 미래의 인도 후 유지보수의 비용이 될 것 • 리 팩터링(refactoring)은 agile processes의 내재된 필 수 적인 컴포넌트 • 예비 실험 리서치가 가리킨 것처럼 refactoring는 post-delivery 유지보수 의 비용을 증가 시킬 것인가? Agile Processes 와 XP 의 평가 (contd) Agile processes는 요구사항이 분명치 않거나 변화가 있을 때 좋음 agile processes에 대한 평가는 이름 • 데이터가 충분치 못함 agile processes 가 실망스럽게 판명될지라도 • 몇 가지 특성들은 미래의 주 소프트웨어 공학 실 무로 채택될 것 2.9.5 동기적-안정적 생명주기 모델 Synchronize-and Stabilize Model Microsoft사의 life-cycle model 요구사항 분석 — 잠재적 고객들의 interview 명세서 작성 프로젝트를 3 내지 4 빌드(build)로 분할 각 빌드는 많은 소규모 팀들이 병렬적으로 수행 2.9.5 동기적-안정적 생명주기 모델 (contd) At the end of the day — 동기화 (synchronize (test and debug)) At the end of the build — 안정화 (stabilize (freeze the build)) 반복되는 동기화 단계는 다양한 컴포넌트들이 함 께 작동 • 개발자가 프로덕트의 운영에 관한 통찰력을 얻을 수 있음 • 구축 과정 시 필요하다면 요구사항을 수정할 수 있음 2.9.6 나선형 생명주기 모델 Spiral Model 간단해진 form • Rapid prototyping model 은 각 단계에서 위험분석 을 선행함 나선형 생명주기 모델의 Key Point • 만약 해당 단계에서 중요 한 위험들을 모두 완화시 킬 수 없다면 이 프로젝트 는 즉시 중단 Figure 2.10 완전한 나선형 생명주기 모델 Full Spiral Model [Boehm, 1988] 각 단계에서 선행되는 것 • 대안 (Alternatives) • 위험분석 (Risk analysis) 각 단계를 따르는 것 • 평가 (Evaluation) • 다음 단계에 대한 계획 Radial dimension: 누적 날짜에 대한 비용 Angular dimension: 나선형을 통한 진전 완전한 나선형 생명주기 모델 (contd) Figure 2.11 나선형 생명주기 모델의 분석 장점 • 얼마나 많은 테스트를 거쳐야 하는지에 대한 판 단이 쉬움 • 개발과 유지보수를 구분하지 않음 단점 • Only 대규모 소프트웨어 개발 • Only 내부 소프트웨어 개발로 한정 2.10 생명주기 모델들의 비교 life-cycle model들이 가지고 있는 다른 점 • 그들이 갖고 있는 각각의 장점과 단점 모델을 결정하는 기준: • The organization • Its management • The skills of the employees • The nature of the product Best suggestion • “Mix-and-match” life-cycle model 2.10 생명주기 모델들의 비교 Figure 2.12