| English | 의미 |
|---|---|
| requirements/rɪˈkwaɪəmənts/ | 요구사항 |
| development life cycle/dɪˈveləpmənt laɪf ˈsaɪkl/ | 개발 수명 주기 |
| waterfall/ˈwɔːtəfɔːl/ | 폭포 모델 |
| maintenance/ˈmeɪntənəns/ | 유지보수 |
| iterative model/ˈɪtərətɪv ˈmɒdl/ | 반복 모델 |
| rapid application development/ˈræpɪd ˌæplɪˈkeɪʃn dɪˈveləpmənt/ | 빠른 애플리케이션 개발 |
| prototype/ˈprəʊtəʊtaɪp/ | 프로토타입 |
| agile/ˈædʒaɪl/ | 애자일 |
| implementation/ˌɪmplɪmənˈteɪʃn/ | 구현 |
열여섯 개월 늦게 문을 연 공항
- 덴버의 신공항은 역사상 가장 ambitious한 수하물 시스템을 갖추어 10월 1993에 개장할 예정이었다: 4,000 자동 카트, 35 km 궤도, 무인 운영. 그러나 2월 1995에 개장while 예산을 $560 백만 달러 초과했으며, 테스트 주행 중 카트가 수하물을 파손했다.
- 시스템이 무엇을 해야 하는지 분석하기 전에 일정이 고정되었다. 개발 중에도 요구사항이 계속 바뀌었다. 수정할 시간이 없을 때나 테스트가 시작되었다.
- 이 수업에서 언급하는 모든 실패에는 명칭이 있다. 프로젝트가 발견되는 것이 아니라 계획되고 관리되며 통제되도록 하기 위해 개발 수명 주기가 존재한다.
- 이 수업은 수명 주기의 목적, 과목 표준에서 언급하는 세 가지 모델, 그리고 모든 프로그램이 거치는 다섯 단계에 대해 설명한다.
수명 주기가 필요한 이유
- 개발 수명 주기는 아이디어부터 완성되고 유지보수되는 소프트웨어까지의 단계들의 집합이다. 그 목적은 계획하고, 관리하며, 통제하여 올바른 제품을 제시간에 좋은 품질로 제공하는 것이다.
- 큰 프로그램을 단계로 나누어 복잡성을 관리하고, 팀을 조정하며, 마일스톤 대비 진척 상황을 추적한다.
- 끝부분으로 미루기보다 테스트를 내재화하고, 나중에 프로그램을 유지보수할 사람이 알 수 있도록 설계 결정을 기록하며, 리스크를 관리한다.
개발 생명 주기는 다음을 위해 사용됩니다:
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
작업을 단계로 구조화하여 팀이 올바른 제품을 제때, 품질 있게 구축하도록 합니다.
개발 생명 주기의 목적은 무엇입니까? 모든 해당 항목을 선택하십시오.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
생명 주기는 계획, 관리, 통제를 담당합니다. correctness를 보장할 수는 없으며, 오류를 찾고 수정하는 과정을 계획에 포함시킵니다.
여러 가지가 있는 이유
- 단일 수명 주기가 모든 프로젝트에 적합하지 않으므로 여러 가지가 존재하며, 시험에서는 적절한 것을 선택해야 한다.
- 선택은 프로그램의 크기와 복잡성, 시작 시 요구사항의 명확성, 예상되는 변경 사항, 실패 시 리스크, 팀, 그리고 마감 기한에 따라 달라진다.
- 법적 규율이 고정된 급여 계산 시스템과 사용자의 니즈가 아직 불확실한 게임은 서로 다른 프로젝트이다. 이들은 서로 다른 수명 주기를 deserve(필요로)한다.
폭포 모델(Waterfall)
- 폭포 모델은 선형적인 순서이다: 분석, 설계, 코딩, 테스트, 유지보수. 각 단계가 완료되고 문서화되며 승인을 받은 후에야 다음 단계가 시작된다.
- 장점: 명확한 구조, 관리 및 일정 설정이 쉬움, 각 단계별 철저한 문서화, 안정된 요구사항에 적합함.
- 단점: 프로젝트 중반에 요구사항이 변경되면 폭포를 거슬러 올라가야 함; 고객은 마지막까지 작동하는 것을 보지 못함; 분석 오류는 테스트阶段才显现出来。
물은 언덕 위쪽으로 흐르지 않는다
물줄기 모델(Waterfall model)은 다음과 같은 프로젝트에 가장 적합합니다:
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
물줄기 모델은 선형적이며 각 단계가 완료되어야 다음 단계가 시작됩니다.安定된 요구사항에는 적합하지만, 프로젝트 중반의 변경에는 취약합니다.
물줄기 모델에서 고객은 프로젝트 초기에 작동하는 버전을 보게 됩니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
코딩과 테스팅이 끝난 마지막에 가까워지기 전까지는 아무것도 실행되지 않습니다. 초기에 작동하는 소프트웨어를 보는 것은 반복 모델과 RAD의 강점입니다.
반복 모델(Iterative)
- 반복 모델은 반복적인 과정을 거친다. 각 과정은 부분적으로 작동하는 버전을 생성하며, 이를 사용자가 검토하고 다음 과정에서 개선한다.
- 장점: 문제를 더 일찍 발견 가능; 사용자는 초기부터 자주 작동하는 소프트웨어를 볼 수 있음; 요구사항이 시간이 지남에 따라 발견되는 경우에 좋음.
- 단점: 총 비용과 시간을 추정하기 어려움; 반복 검토는 사용자의 지속적인 관심 필요; 규칙성이 없으면 설계가 방황할 수 있음.
제작, 제시, 정제, 반복
빠른 애플리케이션 개발(Rapid Application Development)
- 빠른 애플리케이션 개발(RAD)은 프로토타입을 빠르게 제작하여 사용자 앞에 놓으며, 피드백을 바탕으로 다시 제작하여 최종 제품으로 만든다. 팀원들은Often parts in parallel to work on different components simultaneously.
- 장점: 매우 빠른 첫 번째 납품; 변화하는 요구사항을 발생하자마자 수용 가능; 사용자가 제품을 직접 형성 가능.
- 단점: 전체 기간 동안 사용자가 가용해야 함; 프로토타입의 타협점이 제품에 그대로 남을 수 있음; 대형 안전 중요 시스템보다 작은 시스템에 더 적합함. 애자일(Agile) 방식은 같은 개념을 short sprints와 constant testing으로 확장하여 적용한다.
프로토타입, 피드백, 다시 프로토입
물줄기 모델에서는 각 단계가 완료되어야 다음 단계가 시작되지만, 애질(Agile)은 짧은 반복 스프린트와 지속적인 피드백을 통해 진행합니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
워터폴은 선형적이며(안정된 요구사항에 적합); 애자일은 짧은 스프린트와 지속적인 고객 협업 및 테스트를 통해 적응합니다.
각 모델과 그에 해당하는 핵심 개념을 매칭하십시오.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
워터폴 = 선형; 반복적 = 반복적인 정제; RAD = 프로토타입 중심且 빠름.
신속 애플리케이션 개발(RAD)은 사용자가 시도하고 피드백을 제공한 후 다시 구축하는 ____을 만듭니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
프로토타입은 RAD의 결정적 특징이며, 이를 통한 사용자 피드백이 요구사항을 발견하는 방법입니다.
worked example: 수명 주기 선택 및 근거 제시
- 법령으로 규정된 세금 규정에 따라 사원의 급여를 계산할 소프트웨어가 필요한 회사가 있다. 어떤 수명 주기가 적절하고 왜? 폭포: 요구사항이 안정적이고 초기에 완전히 알려져 있으며, 규율은 분석 단계에서 완전히 문서화될 수 있고, 정확성과 감사를 requirement하는 시스템에는 철저한 문서화가 중요하다.
- 새로운 종류의 사회 행사용 앱을 원하는 스타트업이 있으나, 사용자는 어떤 기능이 필요한지 확실하지 않다. RAD: 요구사항이 불분명하고 변경될 가능성이 높으므로, 사용자가直接使用하고 반응하는 프로토타입을 통해 빠르게 요구사항을発見할 수 있으며, 작은 시스템은 빠른 재제작에 적합하다.
- 모델을 이름으로 명시하고, 두 가지 속성을 시나리오의 두 가지 사실과 연결하라.
작은 팀이 사용자에게 어떤 것을 원하는지 불분명한 앱을 만들어야 하며, 사용자는 매주 버전을 테스트할 수 있습니다. 이 시나리오에 가장 적합한 개발 수명은 무엇인가?
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
불분명하고 변화하는 요구사항과 사용자의 접근 가능성이 있는 경우가 RAD입니다. 워터폴은 시작 시 요구사항이 고정되어 있어야 합니다.
다섯 단계
- 분석: 프로그램이 무엇을 해야 하는지 파악; 사용자로부터 요구사항을 수집하고 문서화함.
- 설계: 어떻게 할지 결정: 데이터 구조, 알고리즘, 모듈, 사용자 인터페이스, 파일 레이아웃 등을 구조 차트, 흐름도, 가짜 코드(pseudocode)로 표현함.
- 코딩(구현): 설계를 따르는 소스 코드를 작성함. 테스트: 계획된 테스트 데이터를 사용하여 실행하고, 발견된 오류를 수정함.
- 유지보수: 출시 후, 시스템이 작동하고 유용하도록 유지하며, 결함을 수정하고, 변화에 적응하며, 성능을 향상시킴.
프로그램 개발 생명 주기
모든 프로젝트가 거치는 단계를 단계별로 진행하십시오. 분석 단계에서 요구사항을 정확히 파악하는 것이 가장 중요합니다. 테스트 단계에서 발각되는 오류를 수정하는 비용은 초기에 발견된 오류보다 훨씬 큽니다.
분석 단계는 주로 다음 중 무엇을 결정하는지에 관한 것입니다:
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
분석은 요구사항(무엇을 할 것인가)을 수집하고, 설계는 '어떻게 할 것인가'를 결정합니다.
프로그램 개발 수명의 단계를 순서대로 나열하십시오.
난이도 3/5 · 200 코인 + 오늘 첫 완료 시 소액 보너스
무엇, 어떻게, 구축, 확인, 유지. 반복적 모델에서는 중간 단계가 반복되지만, 각 주기의 내부 순서는 동일합니다.
worked example: 분석 및 설계 단계에서 일어나는 일
- 프로그램 개발 수명 주기의 분석 및 설계 단계에서何が发生하는지 설명하시오. [4점]
- 분석: 개발자는 사용자들과 면담하고 관찰하여 프로그램이 무엇을 해야 하는지 파악함; 입력, 출력, 필요한 처리 과정을 식별하고, 고객이 동의하는 요구사항 명세서(requires specification)를 작성함.
- 설계: 개발자가 프로그램이 요구사항을 어떻게 충족할지 결정합니다. 데이터 구조와 알고리즘을 선택하고, 구조도(structure chart)를 바탕으로 프로그램을 모듈로 분해하며, 화면과 파일을 설계하고 가짜 코드를 작성합니다.
- 각 단계마다 두 가지 행동과 하나의 산출물이 필요합니다. "They analyse the problem"은 제목을 재表述할 뿐이며 점수를 주지 않습니다.
놓칠 수 있는 점
- 분석(Analysis)은 '무엇(what)'이고, 설계(Design)는 '어떻게(how)'입니다. "Deciding the algorithms"는 설계에 속합니다.
- 워터폴(Waterfall)이 나쁜 방식은 아닙니다. 그 장점은 안정적이고 문서화된 요구사항이며, 단점은 변경에 취약하다는 점입니다. 장점과 단점 모두 묻는 경우 두 가지를 모두 제시해야 합니다.
- RAD가 단순히 '빠름'만은 아닙니다. 그 핵심 특징은 프로토타입과 사용자로부터의 피드백입니다.
- 유지보수(Maintenance)는 후속 사항이 아닌 하나의 단계입니다. 프로그램 수명 기간 비용의 대부분은此处에서 지출됩니다.
이해했습니다
- 수명 주기(Life cycle)는 프로젝트를 계획하고, 관리하며, 통제합니다: 단계, 마일스톤, 내장된 테스트, 기록된 의사결정, 리스크 관리
- 워터폴: 선형적이며 각 단계가 승인을 받으며, 안정적 요구사항에 적합하지만 변경에는 불리함 · 반복적(iterative): 반복하여 정제된 버전으로 문제를 초기에 포착하지만 예측이 어려움 · RAD: 프로토타입과 사용자 피드백 포함, 빠르고 유연하며 사용자를 확보해야 함
- 요구사항 명확성, 예상되는 변경 사항, 크기 및 리스크에 따라 선택하고 시나리오를 근거로 정당화해야 합니다.
- 단계: 분석(무엇) → 설계(어떻게) → 코딩 → 테스트 → 유지보수