인터넷 속도 개발
Internet-Speed Development인터넷 속도개발은 고속의 제품 개발을 목표로 하는 일일 빌드와 함께 나선형 모델/물방울 모델을 결합한 애자일 소프트웨어 개발 방식이다.
소프트웨어 개발이 빠르게 변화하고 있었기 때문에 90년대 후반에 개발되었다.기업들은 프로젝트 예정 시간 내에 정확한 요구 사항을 갖춘 제품을 납품하는 데 어려움을 겪었고, 따라서 보다 민첩한 소프트웨어 개발 방법으로 변화하고 있었다.인터넷 속도법이 어떻게 개발되었는지에 대한 자세한 내용은 Abrahamsson 논문의 진화 지도에서 확인할 수 있다.[1]
인터넷 속도 개발의 주요 아이디어
종종 소프트웨어 공학에서 가장 큰 문제들 중 하나는 요구사항이 빠르게 변하고 이러한 상황에 적응하기 위해 인터넷 속도 개발 방법이 만들어졌다는 것이다.소프트웨어 엔지니어링 모델의 두 가지 주요 표준인 나선형 모델과 폭포 모델을 새로운 모델로 결합하고, 새로운 소프트웨어 엔지니어링 방식을 기반으로 한다는 구상이다.폭포 모델의 가장 큰 단점은 요구사항 변화에 대해서는 매우 경직되고 유연성이 떨어진다는 점이었고 나선형의 단점은 구조성이 높지 않다는 점이었다.인터넷 속도 개발의 이면에 있는 아이디어는 이러한 모델들의 조합은 이러한 단점을 갖지 않고 요건이 빠르게 변할 수 있는 상황에서 더 나은 사용 방법이지만, 프로젝트는 구조적으로 실행되어야 한다는 것이다.
방법의 목표
인터넷 속도 개발 방법의 목표는 소프트웨어 개발자들이 체계적인 방법으로 프로젝트를 수행할 수 있도록 하지만 여전히 고객의 요구에 적응할 수 있도록 하는 것이다.집중적인 개발을 통해 단기간에 소프트웨어 제품을 납품하는 것을 목표로 한다.이 방법은 완전하게 구현된 시스템을 전달할 수 있는 수단을 제공하며 이정표 사용을 통해 프로젝트의 진행 상황을 결정할 수 있는 방법도 가지고 있다.이 방법의 주요 버전 중 하나는 마이크로소프트에 의해 만들어지며 마이크로소프트 솔루션 프레임워크라고 불린다.
인터넷 속도 개발 방법의 개념
인터넷 속도 개발에 매우 중요한 첫 번째 개념은 비전과 범위 조성(프로젝트 관리)이다.이것이 의미하는 것은 이 시스템이 무엇을 목표로 하고 있는지, 범위 내에 무엇이 있는지, 그리고 무엇이 아닌지를 설명하는, 이 시스템의 글로벌한 정의가 프로젝트의 시작에 만들어졌다는 것이다.이것은 개발자들에게 어떤 요구사항도 동결하지 않고 시스템이 어떤 것이 될 것인지에 대한 몇 가지 지침을 주기 때문에 기본적인 단계 중 하나이다.그 범위는 비전 진술서에 기록될 수 있다.
이 방법에서 또 다른 매우 중요한 개념은 범위 관리다.프로젝트 전체에 걸쳐 범위를 관리하여 지연을 초래하는 범위를 축소하지 않도록 해야 한다.범위를 조기에 결정하고 범위 변경(처음에는 프로젝트의 범위를 벗어난 것으로 간주되었던 기능을 추가하는 것)을 평가하여 수용하거나 거부한다.범위 변경은 가능하지만 이는 항상 특징, 자원 및 시간 사이의 트레이드오프에 의해 영향을 받는다.
인터넷 속도 개발 방식은 기존 방식과 매우 다르기 때문에 애자일 방식 원칙을 사용한다.그것은 요건에 대한 적응에 초점을 맞추고 있으며, 따라서 애자일 소프트웨어 개발의 기본 원리에 기초하고 있다.
인터넷 속도 개발은 또한 제품이 구축되는 하나의 고정된 프레임워크 아키텍처를 사용하는 데 초점을 맞추고 있으며 개발 속도를 높이기 위한 도구에 크게 의존한다.
인터넷 속도 개발의 또 다른 기본 개념은 소규모 팀 활용에도 초점을 맞춘다는 것이다.그 아이디어는 모든 프로젝트를 종종 병행할 수 있는 작은 활동으로 나눌 수 있다는 것이다.소규모 팀들은 종종 자신의 업무에 더 집중할 수 있고 프로젝트 내에서 책임성을 결정하고 진행 상황을 모니터링하는 것이 더 쉽다.
이 인터넷 속도 개발 항목에서 논의된 마지막 개념은 병렬 개발 개념이다.이 개념은 기본적으로 모든 소프트웨어 개발이 가능한 한 자주 병행된다는 것을 의미한다.이것은 매우 빠른 개발을 가능하게 할 것이고 그것은 더 작은 팀들이 가능한 한 그들 자신의 특징에 집중할 수 있게 할 것이고 그것은 좋은 결과를 가져올 것이다.그러나 소규모 팀들이 최종 시스템을 구축하기 위해 협력할 수 있도록 하려면 개발을 자주 동기화할 필요가 있다.이는 일일 빌드를 사용하여 수행될 수 있으며, 이는 모든 개발자가 빌드가 생성된 후 하루가 끝날 때 코드를 체크인하고, 이후 빌드를 평가 및 테스트하여 진행 상황을 모니터링할 수 있다는 것을 의미한다.빌드 인에서 형상이 완료된 후 테스트하고 다듬어야 하는데, 이를 동기화와 안정화 과정이라고 부르기도 한다.개발된 기능은 빌드와 동기화되어 테스트된다.이러한 시험 후에 버그가 수정되고 기능이 더 잘 작동하도록 개선될 수 있다(안정화 부품이다).
인터넷 속도 개발은 민첩한 원리에 기초하고 있으며, 따라서 익스트림 프로그래밍, 합리적 통합 프로세스, DSDM 및 기능 중심 개발과도 많은 유사점을 가지고 있다.그러나 인터넷 속도 개발은 보다 광범위한 위험 관리 계획을 통합하고 프로젝트의 매우 중요한 목표로서 품질을 가지고 있기 때문에 이러한 방법과는 다르다.[2]인터넷 속도 개발의 개발 단계는 또한 인터넷을 통한 통신과 코드와 문서를 저장하기 위한 저장소의 사용으로 인해 전 세계의 많은 개발자들이 개발 과정의 일부가 될 수 있기 때문에 오픈 소스 소프트웨어 개발 모델과 일부 유사함을 보여준다.
인터넷 속도 개발 단계
이 방법의 모델은 다음과 같다.
그림 1: 위상 모델 이 모델은 방법의 5가지 기본 위상을 보여준다.이 단계들은 이 항목의 다음 절에서 설명될 것이다.단계는 계획, 계획, 개발, 안정화 및 배치이다.이 주기가 완료되면 시스템의 버전이 준비되고 새로운 주기가 새로운 버전을 만들기 시작한다.위상은 다음 절에서 설명하고 메타 모델링 기법을 통해 보여준다.프로젝트 컨텍스트의 다중성과 개념에 대한 자세한 내용은 나중에 전체 데이터 모델에서 확인할 수 있다.
구상 단계
구상 단계는 다음과 같이 모델링할 수 있다.
그림 2: 단계 프로세스/데이터 모델 구상
| 활동 | 정의(원본) |
|---|---|
| 요구사항 분석 | 구상 단계 중에는 비즈니스 요구사항을 파악하고 분석해야 한다. "계획 단계에서 보다 엄격하게 다듬어진다."(MSF 프로세스 모델)[3] |
| 목표 및 제약 조건 정의 | "프로비저닝, 프로젝트의 목표와 제약에 대한 높은 수준의 뷰를 생성함" (MSF 프로세스 모델)[3] |
| 폼 팀 | 핵심팀 구성. |
| 비전/범위 만들기 | "비전/스코프 문서의 준비 및 전달" (MSF 프로세스 모델)[3] |
| 위험 평가 작성 | 구상 단계에서는 위험 문서를 작성하고 최상위 리스크를 제시한다. (MSF 프로세스 모델)[3] |
표 1: 구상 활동
구상 단계에서 수행하는 기본 활동은 요구사항 분석, 프로젝트 팀 구성, 프로젝트 위험 및 범위 결정이다.프로젝트의 요구사항과 목표로부터 비전/범위 문서가 작성된다.이 문서는 제품이 배송되었을 때 어떤 제품이 되어야 하는지에 대해 설명한다.그것은 제품의 매우 상세한 기능을 포함하고 있지 않다.
| 개념 | 정의(원본) |
|---|---|
| 비전/스코프 문서 | "비전 및 범위를 정의하는 문서" (MSF 프로세스 모델)[3] |
| 비전 | "해결책이 무엇인지에 대한 비전은 한없는 관점이다. (MSF 프로세스 모델)[3] |
| 범위 | "프로젝트 제약조건 내에서 달성할 수 있는 비전의 부분을 파악한다." (MSF 프로세스 모델)[3] |
| 위험 평가 문서 | "위험도 평가를 위한 표준화된 문서" (MSF 위험관리 분야)[4] |
| 우선순위 지정 위험 목록 | 프로젝트 조건, 컨텍스트, 근본 원인, 우선순위에 사용되는 측정 기준(확률, 영향, 노출)을 포함한 상세한 위험 정보가 위험 명세서 양식에 기록되는 경우가 많다. (MSF 위험관리 분야)[4] |
| 리스크 계획 | "우선순위 위험 리스트를 실행 계획으로 전환" (MSF 위험관리 분야)[4] |
| 프로젝트 구조 문서 | "사업구조 문서에는 팀이 어떻게 구성되고 누가 어떤 역할을 하고 구체적인 책임을 지는지에 대한 정보가 담겨 있다.프로젝트 구조 문서에는 프로젝트 팀이 고객과 가지는 고객에 대한 책임 사슬과 지정된 연락 지점도 명확히 되어 있다.이는 사업 상황에 따라 달라질 수 있다고 말했다. (MSF 프로세스 모델)[3] |
| 팀 구성 | "팀 구성 방법에 대한 정보." (MSF 프로세스 모델)[3] |
| 접점 | "프로젝트 팀이 고객과 가지고 있는 지정된 연락 지점" (MSF 프로세스 모델)[3] |
| 팀 역할 | "누가 어떤 역할을 하고 구체적인 책임을 지는지에 대한 정의" (MSF 프로세스 모델)[3] |
표 2: 구상 단계의 개념
계획 단계
그림 3: 계획 단계 프로세스/데이터 모델
| 활동 | 정의(원본) | |
|---|---|---|
| 요구사항 정의 | 기획 단계 초기에 팀은 분석하고 문서화한다. 목록 또는 도구의 요구 사항.요구사항은 비즈니스 요구사항, 사용자 요구사항, 운영 요구사항 및 시스템 요구사항(솔루션 자체의 요구사항)의 4가지 범주로 나뉜다." (MSF 프로세스 모델)[3] | |
| 피쳐에 대한 추적 요구 사항 | "팀이 솔루션을 설계하고 기능사양을 만드는 방향으로 나아가면서 요구사항과 특징 간의 추적성을 유지하는 것이 중요하다.추적가능성은 1대1로 할 필요가 없다.추적가능성을 유지하는 것은 설계의 정확성을 확인하고 설계가 솔루션의 목표와 요건을 충족하는지 검증하는 한 가지 방법이 된다." (MSF 프로세스 모델[3]) | |
| 기능 사양 정의 | "팀에서 기능사양을 준비한다." (MSF 프로세스 모델[3]) | |
| 계획 작성 | 위험 추정 | 팀은 위험 추정을 생성한다. |
| 견적 비용 | 팀은 비용 추정치를 작성한다. | |
| 작업 계획 작성 | 팀은 작업 계획을 만든다. | |
| 일정 만들기 | 팀이 일정을 만든다. | |
| 설계 작성 | 사용 사례 모델 만들기 | "이것은 사용자 프로파일에 대한 체계적인 분석으로부터 시작된다. ("Personas"라고도 함) 다양한 유형의 사용자와 그 직무 기능을 기술한다(직원은 사용자이기도 함).이 중 많은 부분이 계획 단계에서 종종 이루어진다.이는 일련의 사용 시나리오로 나뉘는데, 특정 유형의 사용자가 호텔에서 프런트 데스크 등록을 하거나 시스템 관리자의 사용자 비밀번호를 관리하는 것과 같은 유형의 활동을 완료하려고 시도한다.마지막으로 각 사용 시나리오는 사용자가 해당 활동을 완료하기 위해 수행하는 특정 작업 순서(사용 사례)로 구분된다.이것을 "스토리 보드"라고 부르지." (MSF 프로세스 모델[3]) |
| 개념 설계 작성 | 개념 설계 생성. | |
| 논리 설계 생성 | 논리적 설계 생성. | |
| 물리적 설계 생성 | 물리적 설계 생성. | |
| 건축 만들기 | 제품에 대한 아키텍처 생성. | |
표 3: 계획 단계에서는 요구사항으로부터 기능 규격을 작성한다.선택한 형상이 이 규격에 포함되어 있다(MoSCoW Method는 형상에 자주 사용되므로 보다 쉽게 우선순위를 정할 수 있다).또한, 이 단계에서는 기본 설계와 계획이 만들어진다.그러나 이 설계는 개발 단계에서 변경될 수 있으므로 동결되지 않는다.
| 개념 | 정의(원본) |
|---|---|
| 요구사항 목록 | 문서화 목록 또는 도구의 요구 사항. (MSF 프로세스 모델[3]) |
| 리스크 관리 계획 | 문서 프로젝트 맥락 안에서 리스크 관리 프로세스를 어떻게 구현할 것인지에 대해." (MSF 위험관리 분야[4] ) |
| 마스터 프로젝트 계획 | 전부 계획이 동기화되고 마스터 프로젝트 계획으로 함께 제시된다." (MSF 프로세스 모델[3]) |
| 워크플란스 | 역할과 관련된 결과물에 대한 계획 또는 계획 팀 기획 세션에 참여한다." (MSF 프로세스 모델[3]) |
| 비용 추정치 | 프로젝트 비용 추정. |
| 일정 | 결과물에 대한 시간 추정 및 일정." (MSF 프로세스 모델[3]) |
| 마스터 프로젝트 일람표 | 그 이후 다양한 일정이 동기화되어 마스터 프로젝트 일정으로 통합된다." (MSF 프로세스 모델[3]) |
| 기능 사양 | 그 기능 사양은 각 형상이 어떻게 보이고 동작하는지를 자세히 설명한다.모든 특징에 대한 구조와 설계도 기술하고 있다." (MSF 프로세스 모델[3]) |
표 4: 계획 단계의 개념
개발단계
그림 4: 단계 프로세스/데이터 모델 개발
| 활동 | 정의(원본) |
|---|---|
| 기능 개발 | 솔루션 구성요소(문서 및 코드) 구축." (MSF Process Model)[3] 일일 빌드 후 테스트, 버그 수정 및 기능 평가도 포함한다. |
| 일별 빌드 만들기 | 근무일 이후 빌드 생성. |
| 범위 완료 | 이 이정표에서 모든 기능이 완성되고 외부 시험과 안정화를 위한 솔루션이 준비된다." (MSF 프로세스 모델)[3] |
| 인프라 개발 | 인프라가 개발돼 있다." (MSF 프로세스 모델)[3] |
표 5: 활동 개발 개발 단계에서 가장 중요한 활동은 기능의 개발이다.이러한 특징의 구현 이외에도 이 단계에서는 적용범위가 확정된다.개발 중에 제품에 새로운 기능이 추가될 수 있지만, 일단 범위가 확정되면 기능이 동결되어 시험 및 안정화를 위한 준비가 된다.이 단계에서는 네트워크 구조가 식별되고 데이터베이스 서버와 같은 서버가 정의된다는 것을 의미하는 인프라도 개발된다.
| 개념 | 정의(원본) |
|---|---|
| 배포를 위한 설치 스크립트 및 구성 설정 | 제품을 설치/실행하는 데 필요한 스크립트 및 설정 모음입니다. |
| 설치 스크립트 | 제품을 설치하는 데 필요한 스크립트. |
| 구성 설정 | 제품의 구성 속성. |
| 성능 지원 요소 | 제품의 성능을 지원하는 요소(추가 데이터베이스, 서버 등) |
| 테스트 사양 및 테스트 사례 | 제품 유효성 검사에 사용되는 테스트 및 테스트 사례의 사양 |
| 기능 사양 | 기능 사양은 각 형상이 어떻게 보이고 동작하는지를 자세히 설명한다.모든 특징에 대한 구조와 설계도 기술하고 있다." (MSF 프로세스 모델)[3] |
| 소스 코드 및 실행 파일 | 소스 코드/실행 가능 조합. |
| 소스 코드 | 제품의 소스 코드. |
| 실행 파일 | 소스 코드에 의해 생성된 실행 파일. |
표 5: 개발 단계의 개념
안정화 단계
그림 5: 안정화 단계 프로세스/데이터 모델
| 활동 | 정의(원본) |
|---|---|
| 테스트 | 이 단계에서의 시험은 현실적인 환경 조건에서 사용과 운영을 강조한다.“ (MSF 프로세스 모델)[3] |
| 버그 해결 | 버그 해결과 트라이징(사전화), 출시를 위한 솔루션 준비에 주력하고 있다고 말했다. (MSF 프로세스 모델)[3] |
| 파일럿 배포 | 일단 빌드가 릴리스 후보로서 충분히 안정되었다고 판단되면, 솔루션은 시범 그룹에 배치된다." (MSF 프로세스 모델)[3] |
| 검토 | 검토되고 승인되면 솔루션은 라이브 프로덕션 환경에 완전히 배포할 준비가 되어 있다." (MSF 프로세스 모델)[3] |
표 6: 안정화 활동 주요 활동은 버그 시험과 해결이다.일단 빌드 버전이 파일럿을 위해 충분히 안정적이라고 여겨지면 파일럿 버전이 만들어지고 배치된다.이 조종사로부터 시험/안정화 루프로 돌아가거나 승인 및 검토된다.
| 개념 | 정의(원본) |
|---|---|
| 테스트 결과 및 테스트 도구 | 테스트에 사용되는 테스트 결과 및 도구 모음입니다. |
| 테스트 결과 | 실행된 테스트의 결과. |
| 테스트 도구 | 테스트에 사용되는 도구. |
| 골든 릴리즈 | 최종 검토에 사용된 버전. |
| 릴리스 노트 | 릴리스 버전에 대한 참고 사항. |
| 소스 코드 및 실행 파일 | 소스 코드/실행 가능 조합. |
| 소스 코드 | 제품의 소스 코드. |
| 실행 파일 | 소스 코드에 의해 생성된 실행 파일. |
| 마일스톤 리뷰 | 최종본 및 프로젝트 문서 검토. |
| 프로젝트 문서 | 모든 프로젝트 문서 모음입니다. |
표 7: 안정화 단계의 개념
배치 단계
그림 6: 배포 단계 프로세스/데이터 모델
| 활동 | 정의(원본) |
|---|---|
| 핵심 구성 요소 배포 | 제품에 필요한 모든 구성 요소(데이터베이스 서버, 메일 서버 등)의 배포 |
| 현장에 솔루션 배포 | 맞춤형 시스템의 경우 제품의 배포는 여기에서 이루어진다(소프트웨어 제품의 경우 생략할 수 있음). |
| 배포 안정화 | 전개된 구성 요소의 태클, 모니터링 및 개선. |
| 운영 및 지원으로 프로젝트 이전 | 운영 및 지원 팀에 모든 문서 및 코드 전송 |
| 고객의 최종 승인 획득 | 고객은 팀이 목표를 달성했다는 데 동의해야 해결책이 생산 중임을 선언하고 프로젝트를 마무리할 수 있다.이를 위해서는 성공 기준을 명확히 기술한 것뿐만 아니라 안정적인 해결책이 필요하다.솔루션이 안정적이라고 판단되려면 적절한 운영과 지원 시스템을 갖춰야 한다." (MSF 프로세스 모델)[3] |
| 프로젝트 검토 | 프로젝트의 최종 검토. |
표 8: 활동 전개 전개 단계의 주요 활동은 제품 운용에 필요한 인프라 설치(서버 배치 등)이다.또한, 문서를 확정하여 운영지원부서로 이관하고, 지식기반을 조성하고, 제품 및 프로젝트를 고객(해당되는 경우)과 프로젝트팀에서 검토한다.
| 개념 | 정의(원본) |
|---|---|
| 절차 및 프로세스 | 절차 및 프로세스의 모음입니다. |
| 절차들 | 제품의 설치 및 작동에 사용할 절차 모음입니다. |
| 과정 | 제품의 설치 및 작동에 사용할 프로세스 모음입니다. |
| 기술 자료, 보고서, 로그북 | 기술 자료, 보고서 및 로그북의 모음입니다. |
| 기술 자료 | 제품과 관련된 기술 자료. |
| 보고서 | 제품과 관련된 리포트. |
| 로그북 | 제품과 관련된 로그북. |
| 문서 저장소 | 모든 문서의 저장소. |
| 모든 프로젝트 문서의 최종 버전 | 프로젝트 문서의 최종 버전. |
| 운영 및 지원 정보 시스템 | 제품과 관련된 운영 및 지원 팀에서 사용하는 시스템. |
| 고객/사용자 만족도 데이터 | 제품에 대한 고객/사용자의 만족도에 대한 데이터 수집. |
| 다음 단계 정의 | 제품 진화를 위해 취해야 할 다음 단계에 대한 설명. |
| 프로젝트 마감 보고서 | 제품, 프로젝트 및 운영 및 지원으로의 이전에 대한 최종 보고서. |
표 9: 배치 단계의 개념
전체 데이터 모델
그림 7: 전체 데이터 모델 이 데이터 모델은 전체 프로젝트 맥락에서 다중성과 관계가 있는 모든 개념을 보여준다.
인터넷 속도 개발용 도구
- 그리기 도구(예:Microsoft Visio, Rational Rose, Dia) 도표를 만드는 데 사용.
- 워드 프로세서(예:Microsoft Word, OpenOffice.org Writer, AbiWord, Percherra Words) 비전 진술서 또는 범위 문서와 같은 텍스트 문서를 만드는 경우.
- 스프레드시트(예:Microsoft Excel, OpenOffice.org Calc, Gnumeric, Percyra Sheet) 우선순위 위험 목록을 작성하고 비용을 계산하는 데 사용.
- 프로젝트 도구(예:Microsoft Project, OpenProj, Gnome Planner, Percherra Plan) 프로젝트 계획 활동.
- 데이터베이스 및 데이터베이스 관리 도구(예: MS SQL Server, MySQL, Oracle, Postgre)SQL) 지식 기반 만들기.
- 자동화된 테스트 도구(예:테스트 스크립트) 매일 빌드 후 테스트를 실행하는 경우.
참고 항목
메모들
참조
- Microsoft 2002년 6월 Microsoft Solutions Framework(백서) Microsoft Press
- Microsoft 6월 2002 MSF 위험 관리 부문 1.1.1(백서) Microsoft Press
- Wolfgang Zuser, Stefan Haley, Thomas Grechenig 2005 소프트웨어 품질 개발 및 보증(RUP, MSF 및 XP) - 소프트웨어 품질에 대한 2005 워크숍 비교 연구 절차
- Peka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003 새로운 대응방안: 비교분석 ICSE
- 마이클 A.쿠스마노, 데이비드 B.Yofie 1999 인터넷 시간 32 IEEE의 소프트웨어 개발
- Balasubramaniam Ramesh, Jan Pries-Heje 2002 인터넷 소프트웨어 엔지니어링: 소프트웨어 엔지니어링의 다른 프로세스 목록 14169–195
