구조 프로그램을 만드는 단계. 소프트웨어 개발 단계
프로그램 개발 단계
프로그래밍은 어떻게 수행되며, 이 과정에서 어떤 프로세스가 발생합니까?
복잡한 문제에 대한 해결책은 4단계로 구성됩니다. :
1) 문제 해결자가 무엇이 주어지고 목표가 무엇인지(결국 얻으려면 무엇이 필요한지) 결정할 때 문제에 대한 인식과 공식화;
2) 해결 전략(목표 달성을 위한 전략)을 나타내는 계획 개발
3) 계획의 실행(구현). 이 경우 복잡한 계획은 (원래 작업에 비해) 매우 간단한 일련의 작업으로 변환됩니다.
4) 솔루션의 정확성을 확인합니다.
5) 문서;
6) 소비자에게 솔루션을 전달합니다.
이들 단계 프로그래밍과 관련해 그에 따라 호출됩니다.
1) 소프트웨어 요구사항 및 소프트웨어 설계 목표 결정(문제 설명, 형식화 및 기술 사양 개발)
2) 소프트웨어 설계(해결 방법, 프로그램 구조 및 알고리즘 개발)
3) 코딩(선택한 프로그래밍 언어로 프로그램 자체를 작성) 및 프로그램 디버깅
4) 고객 측을 포함한 프로그램 테스트(PMI에 따름)
5) 문서 공개(프로그래머 매뉴얼, 시스템 프로그래머 매뉴얼 등)
6) 소비자(고객)에게 양도하기 위한 소프트웨어 제품 출시.
GOST 19.102-77 "개발 단계"에 따르면 다음과 같은 소프트웨어 개발 단계가 정의됩니다.
1) 기술 사양 개발 (위에서 언급한 "문제 공식화 및 공식화" 단계가 이에 해당함)
2) EP 개발(위에서 언급한 단계 “해결방법 개발,
3) TP 프로그램 구조 및 알고리즘 개발")
4) RP 개발(위에서 언급한 "코딩 및 디버깅", "테스트" 및 "문서화" 단계가 포함됩니다.
5) 구현(위에서 언급한 "소비자(고객)에게 전송하기 위한 소프트웨어 제품 출시" 단계에 해당).
소프트웨어 개발의 일부 단계(또는 하위 단계)에 대해 자세히 알아보세요.
문제 설명
도메인 언어로 수행됩니다. 해당 주제 영역(안테나, TV, 저항기...)에서 사용되는 기술 용어를 사용합니다. 이 단계에서:
지정됨(주제 영역에서 선택됨) 소스 객체(과제와 관련된 주제 영역의 개체), 해당 유형(구조, 조직) 및 이들 간의 관계(소스 개체)
공식화 목표(개발), 새로운 개체를 얻거나 원래 개체의 특성을 처리하는 것으로 구성됩니다(예를 들어 일부 통계를 찾기 위해).
선택, 동의 및 기록됨 제한(초기 데이터 및 해결 방법에 대해).
후에 초기 (초기) 문제 설명공식적이거나 문제의 수학적 진술 . 수학이라는 단어는 다음과 같은 의미로 이해됩니다. 재정의하다 객체 모델(추상화)과 객체 간의 관계(보통 수학 공식의 형태) 측면에서 명시된 문제입니다. 이 단계를 흔히 형식화.
공식화 과정에서 업무에 대한 심층적인 분석이 수행되며, 모호한 구두 설명에서 전환각 용어의 고정된 의미(이미지)를 가진 일부 인공 언어를 사용하여 기호 형식으로 설명되는 작업입니다. 공식화는 다음을 제공합니다. 분명한 진술작업. 처럼 형식주의자주 사용되는:
그래프 이론;
확률 이론;
큐잉 이론;
집합이론
공식화할 때 장치가 사용됩니다. 추출. 추상화는 실제 대상에서 추상화로의 전환으로 구성된 과학적 지식의 방법입니다. 이 경우, 문제의 특정 공식화(해결되는 문제의 관점에서)에서 표현되는 실제 객체의 속성과 객체 사이의 연결에서 정신적 혼란이 발생합니다. 의미 없는. 추상화의 결과로 모델(추상화)이 획득됩니다. (특정 가정 하에서) (설정의 틀 내에서) 원래 객체의 기본 속성을 보존하는 특정 인공 객체(기억 전압계 및 스톱워치 높이를 측정하기 위해). 다음으로 문제는 수학적 공식으로 해결됩니다.
좋은문제를 수학적 공식화하면 즉시 다음을 수행할 수 있습니다. 해결책을 참조하십시오.
문제를 해결하기 위한 방법 찾기 (설계 단계에서)
분명히, 문제 해결 방법을 알지 못한 채 문제 해결을 위한 조치(즉, 해결 알고리즘)를 정확하고 필요한 순서대로 설명하는 것은 불가능합니다. 따라서 알고리즘의 개발은 항상 그러한 방법을 먼저 찾아야 할 필요성과 연관되어 있습니다. 아래에 문제 해결 방법특정 문제를 해결하는 데 필요한 순서를 나타내는 것으로 이해됩니다. 알려진 문제필요한 결과를 얻으려면. 알려진 작업은:
이전에 이미 만났고 그 해결책이 이미 알려진 사람들;
공식이 알려져 있고 그 해결책이 어렵지 않은 것(프로그래머의 경우).
따라서 해결 방법에 따라 결정됩니다. 원래 문제의 대체알려진 문제의 동등한 순서로.
개발자의 시야에서 이러한 알려진 문제가 나타나는 위치는 그가 프로그램(알고리즘)을 개발하기 위해 선택한 접근 방식에 따라 다릅니다. 오름차순또는 내림차순.
논평 : 알고리즘(프로그램) 개발에 대한 위의 두 가지 접근 방식 외에도 일반적으로 다음과 같은 방법론이 구별됩니다( 패러다임) 프로그래밍:
절차적(상향식 및 하향식 접근 방식 포함) - 여기서만 알고리즘 개발이 필수입니다.
객체 지향(본질적으로 상향식 접근 방식이지만 절차적 접근 방식은 아님)
논리적(논리 지향);
기능성.
우리는 이 패러다임에 대해 잠시 후에 이야기하겠습니다.
코딩 일반적으로 다음 단계를 수행합니다.
1).알고리즘을 프로그래밍 언어 중 하나로 번역, 결과적으로 (처음에는 종이에) 손으로 쓴 (소스) 프로그램 텍스트가 생성됩니다.
2).PC용 프로그램 준비, 즉. 손으로 쓴 프로그램 텍스트를 종이에서 컴퓨터 저장 매체로 전송하는 것입니다. 이를 위해 텍스트 편집기가 사용됩니다.
3).편집 텍스트를 기계어 코드로 프로그래밍컴파일러라는 프로그램을 사용합니다.
| 컴퓨터 |
기계코드
(컴퓨터가 이해함)
논평 : 그 문구 프로그램은 컴퓨터가 이해할 수 있는 언어로 작성된 알고리즘이다., 즉 중간 컴파일러가 있는 경우컴퓨터 프로그램으로 작성된 텍스트는 이미 컴퓨터에서 이해할 수 있는 것으로 간주됩니다. 이 중간 컴파일러는 프로그램 텍스트를 Java에서 기계어로 번역하는 역할을 담당합니다.
논평 : 컴파일러 외에 인터프리터도 있습니다. 프로그램 텍스트의 각 명령을 구문 분석하고 즉시 실행합니다(명령별 명령). 이것은 기계어 파일을 생성하지 않습니다. 인터프리터는 컴파일러보다 훨씬 느리게 작동합니다. 하지만 도움을 받으면 프로그램을 디버그하는 것이 더 쉽습니다(오류 찾기).
프로그램의 구문이 완전히 정확하면 컴파일(번역)이 성공적으로 완료될 수 있습니다. 따라서 이 단계에서는 프로그램 텍스트에서 모든 구문 오류를 제거하기 위해 여러 번의 컴파일 시도가 필요할 수 있습니다.
컴파일의 결과는 일반적으로 다음과 같은 기계어 코드 프로그램입니다. 개체 모듈(*.obj). 그러나 그녀는 직접 실행할 수 없음, 왜냐하면 소위 코드가 포함되어 있지 않습니다. 표준 루틴(예를 들어 입력 및 출력에 대한 작업을 수행합니다) 게다가, 컴파일러는 종종 프로그램이 부분적으로 컴파일되도록 허용합니다. 컴파일의 결과는 프로그램 일부의 기계어 코드일 수 있습니다. 따라서 컴파일 후에는 링크를 해줘야 합니다.
4).공들여 나열한 것 (연결) 프로그램: 즉. 프로그램의 개별 부분을 결합하고, 표준 서브루틴을 추가하고, 프로그램 부분 간에 필요한 연결을 설정합니다. 이러한 작업은 다음과 같은 프로그램에 의해 수행됩니다. 링커(링커).
컴파일 단계에서프로그램에서 외부(이 프로그램에서는 구현되지 않은 외부) 함수에 대한 모든 호출(호출 주소)은 널 코드로 대체됩니다. 컴파일 타임에 함수를 메모리에 로드하기 위한 실제 주소는 알 수 없습니다. 레이아웃 단계에서 이러한 위치는 프로그램의 실제 배치와 프로그램의 여러 부분에 있는 기능을 고려하여 조정됩니다. 이 작품 링커에 의해 실행됨(링커). 결과는 실행 가능한 프로그램(로드 모듈), 즉 *.exe입니다.
논평: 터보 파스칼(및 프리 파스칼) 컴파일러는 실행 가능한 코드로 직접 컴파일됩니다(별도의 연결 단계가 필요하지 않음).
로드 모듈의 모든 주소 링크는 상대적입니다(로드 모듈의 시작 부분을 기준으로 함). 프로그램에 제어권을 넘기기 전에 모든 주소 링크는 RAM에 있는 프로그램의 시작 주소로 구성되어야 합니다. 이 기능이 수행됩니다 짐을 싣는 사람 .
디버깅 및 테스트: 실행 준비가 된 프로그램 코드를 수신한 후 해당 단계가 시작됩니다. 디버깅및 테스트 - 프로그램 오류 검색(디버깅)(예: 데이터 작업 시 오류, 논리적 오류 등)
사용 중에 프로그램이 올바르게 실행되는지 여기에서 확인합니다. 특별히 준비된 소스 데이터(테스트 데이터) 각각에 대해 다음이 결정됩니다. a) 테스트 목적(찾아야 할 내용) b) 초기 데이터(명세해야 할 내용) c) 주어진 초기 데이터에 대한 예상 결과 . 특정 테스트를 통과할 때 잘못된 결과가 나오는 경우 특정 프로그램 기능이나 프로그램의 특정 분기에서 오류를 확인할 수 있습니다.
구별하다 테스트 방법: a) 화이트 박스(구조 테스트) 및 b) 블랙 박스(기능 테스트 - 기술 사양을 받은 후 즉시 시작할 수 있음).
구별하다 테스트 유형: a) 알파 테스트(프로그래머가 직접 수행) b) 베타 테스트(고객 또는 잠재적 소비자가 수행).
(성공적인) 테스트가 완료되면 프로그램을 고객에게 전송할 준비가 된 것입니다.
논평:
위에 나열된 모든 프로그램(편집기, 컴파일러, 링커, 디버거 등)은 별도로 시작하고 사용할 수 있지만(설명된 순서대로) 터보 파스칼에서는 소위 통합 프로그램으로 결합됩니다. 개발 환경 (IDE)를 사용하여 환경을 떠나지 않고도 프로그램을 생성, 디버그 및 실행할 수 있습니다. 메뉴 시스템.
4. 녹음 도구 및 알고리즘 분류 .
문제에 대한 설명입니다.모든 프로그램의 작성은 문제 설정부터 시작됩니다. 처음에는 주제 영역에 따라 작업이 공식화되고 번역이 필요합니다.
쌀. 26.1.
프로그래밍에 더 가까운 개념의 언어로 표현됩니다. 프로그래머가 해당 주제 영역을 완전히 이해하는 경우가 거의 없고, 고객이 프로그래밍을 완전히 이해하는 경우가 거의 없기 때문에(간단한 예: 회계 프로그램을 작성해야 하는 경우) 문제 설정은 매우 어려운 반복 프로세스가 될 수 있습니다. 또한 작업을 설정할 때 고객이 자신의 요구 사항과 기준을 명확하고 완전하게 공식화할 수 없는 경우가 많습니다.
이 단계에서는 프로그램이 실행될 환경(하드웨어 요구 사항, OS 및 사용되는 기타 소프트웨어)도 결정됩니다.
문제 설명은 생성으로 끝납니다. 기술 사양,그런 다음 외부 프로그램 사양,포함:
■ 소스 데이터 및 결과에 대한 설명(유형, 형식, 정확성, 전송 방법, 제한 사항)
■ 프로그램에 의해 구현된 작업에 대한 설명;
■ 프로그램에 액세스하는 방법;
■ 발생할 수 있는 긴급 상황 및 사용자 오류에 대한 설명.
따라서 프로그램은 기능과 입출력 데이터가 정의된 '블랙박스'로 취급된다.
문제 해결을 위한 모델과 방법을 선택합니다.이 단계에서는 문제의 조건을 분석하고 이를 토대로 문제의 모델을 구축하고 이를 해결하기 위한 일반적인 방법을 결정합니다. 모델을 구성할 때 고려 사항의 관점에서 중요한 문제의 특성이 식별됩니다. 그것은 추상화되어 있습니다. 이러한 특성은 필요한 완전성과 정확성을 바탕으로 모델에 표현되어야 합니다. 즉, 이 단계에서는 문제 설명이 형식화되고 이를 기반으로 문제 해결을 위한 일반적인 방법이 결정됩니다. 여러 가지 방법이 있는 경우 프로그래머가 직면하는 특정 작업에 따라 복잡성, 효율성, 정확성 기준에 따라 가장 좋은 방법이 선택됩니다.
내부 데이터 구조 개발.대부분의 알고리즘은 데이터가 어떻게 구성되는지에 따라 달라지므로 프로그램 설계는 알고리즘이 아닌 입력, 출력 및 중간 데이터를 표현하는 데 필요한 구조의 개발로 시작되어야 한다는 것이 직관적입니다. 이 경우 데이터 크기 제한, 필요한 정확도, 프로그램 속도 요구 사항 등 많은 요소가 고려됩니다. 데이터 구조는 정적이거나 동적일 수 있습니다.
프로그램에서 데이터를 구성하는 방법을 결정할 때 다음 질문을 스스로에게 물어보는 것이 도움이 됩니다.
■ 어느 정도의 데이터 정확성이 요구됩니까?
■ 데이터 값의 범위는 무엇입니까?
■ 최대 데이터 제한이 있나요?
■ 프로그램에 동시에 저장해야 하나요?
■ 데이터에 대해 어떤 작업을 수행해야 합니까?
예를 들어, 처리해야 하는 동일한 유형의 데이터의 최대 양이 알려져 있고 작은 경우 가장 쉬운 방법은 이를 저장할 정적 배열을 만드는 것입니다. 그러한 배열이 많으면 데이터 세그먼트와 스택이 충분하지 않을 수 있으며 이러한 배열을 위해 동적 메모리에 공간을 할당해야 합니다.
최대 데이터 양을 알 수 없고 프로그램이 실행되는 동안 지속적으로 변경되는 경우 동적 구조를 사용하여 이를 저장합니다. 구조 유형의 선택은 데이터에 필요한 작업에 따라 다릅니다. 예를 들어 요소를 빠르게 검색하려면 이진 트리가 가장 적합하며, 데이터가 도착한 순서대로 처리해야 하는 경우 큐가 사용됩니다.
설계.아래에 프로그램 디자인모듈의 일반적인 구조와 상호 작용에 대한 정의를 나타냅니다.
이 단계에서 적용됩니다. 탑다운 디자인 기술, 위에서 논의한 주요 아이디어입니다. 이 경우 단계별 세부화 방법이 사용됩니다.
먼저 프로그램이 가장 일반적인 동작을 이해할 수 있는 가상 기계의 언어로 작성된 다음 각 동작이 더 낮은 추상화 수준에서 설명되는 방식으로 이 프로세스를 상상할 수 있습니다. 이 단계에서는 매우 중요합니다 인터페이스 사양,저것들. 하위 작업이 상호 작용하는 방식을 결정합니다.
각 하위 작업에 대해 앞서 주어진 것과 유사한 외부 사양이 작성됩니다. 같은 단계에서 프로그램을 모듈로 나누는 문제가 해결되며 주요 기준은 상호 작용을 최소화하는 것입니다. 하나의 작업은 여러 모듈을 사용하여 구현할 수 있으며, 그 반대의 경우에도 하나의 모듈에서 여러 작업을 해결할 수 있습니다. 상위 레벨의 디자인을 완료한 후에야 하위 레벨의 디자인으로 이동합니다. 알고리즘은 단어, 일반화된 순서도 또는 기타 방법과 같은 일반화된 형식으로 작성됩니다.
주목
설계 단계에서는 향후 프로그램 수정 가능성을 고려하고 변경이 가능한 한 쉽게 프로그램을 설계하도록 노력해야 합니다.
어떤 변화가 이루어져야 할지 알 수 없기 때문에 이러한 욕구는 "모든 것에 대한 일반 이론"의 창설과 유사합니다. 실제로 우리는 합리적인 타협으로 제한해야 합니다. 프로그래머는 자신의 경험과 상식을 바탕으로 향후 프로그램의 어떤 기능을 변경하거나 개선해야 할지 결정합니다.
실제 크기의 프로그램에서는 처음부터 모든 세부 사항을 생각하는 것이 불가능하기 때문에 설계 프로세스는 반복적입니다.
구조화된 프로그래밍.여기서 프로그래밍은 "협의적인 의미"로 간주됩니다. 기성 알고리즘을 사용하여 프로그래밍 언어로 프로그램을 작성하는 것으로 이해됩니다. 이 과정을 흔히 코딩이를 전체 프로그램 개발 주기와 구별합니다.
코딩도 하향식으로 구성됩니다. 먼저 최상위 모듈을 코딩하고 테스트 케이스를 컴파일하여 디버깅합니다. 이 경우 아직 작성되지 않은 다음 레벨의 모듈 대신 스텁이 배치됩니다. 가장 간단한 경우에는 제어권이 해당 모듈로 전달되었다는 메시지를 표시한 다음 호출 모듈로 반환합니다. 다른 경우에는 스텁이 미리 정의되거나 단순화된 알고리즘을 사용하여 계산된 값을 생성할 수도 있습니다.
따라서 프로그램의 논리적 골격이 먼저 생성된 다음 코드의 육체로 가득 차게 됩니다. 프로그래밍 프로세스에 상향식 기술을 적용하는 것이 더 논리적으로 보일 수 있습니다. 즉, 먼저 낮은 수준의 모듈을 작성하고 디버그한 다음 이를 더 큰 조각으로 결합하는 것입니다. 그러나 이 접근 방식에는 여러 가지 단점이 있습니다.
첫째, 최상위 수준을 코딩하는 과정에서 프로그램의 하위 수준을 설계할 때 특정 어려움이 드러날 수 있습니다(단순히 프로그램을 작성할 때 설계할 때보다 논리를 더 신중하게 고려하기 때문입니다). 이러한 오류가 마지막으로 발견되면 기성품 하위 모듈을 재작업하는 데 추가 비용이 필요합니다.
둘째, 각 모듈을 디버깅하고 프로그램의 더 큰 조각을 디버깅하려면 매번 자체 테스트 사례를 구성해야 하며 프로그래머는 종종 모듈이 작동해야 하는 환경을 모방해야 합니다. 하향식 프로그래밍 기술은 테스트 생성을 위한 자연스러운 순서, 즉 하향식 디버깅 가능성을 제공합니다. 이에 대해서는 아래에서 설명합니다.
설계 및 프로그래밍 단계는 시간에 맞춰 결합됩니다. 이상적으로는 최상위 수준이 먼저 설계되고 코딩된 다음 다음 단계 등이 수행됩니다. 이 전략은 하위 수준 모듈에 영향을 미치는 코딩 프로세스 중에 변경이 필요할 수 있으므로 오류 비용을 줄이기 위해 사용됩니다.
하향식 테스트.이 단계는 마지막에 기록되지만 이것이 이전 단계에서 테스트를 수행해서는 안 된다는 의미는 아닙니다. 디자인과 프로그래밍 모두 글쓰기를 동반해야 합니다. 테스트 스위트 – 초기 데이터와 해당 표준 반응 세트를 검증합니다.
프로그램을 테스트하는 과정과 디버깅하는 과정을 구별할 필요가 있습니다. 테스트프로그램의 정확성을 검증하는 과정이다. 테스트는 긍정적이며 그 목적은 프로그램이 올바르게 작동하고 모든 설계 사양을 충족하는지 보여주는 것입니다. 디버깅– 모든 오류를 수정하는 것이 목표가 아닌 프로그램의 오류를 수정하는 프로세스입니다. 테스트 중 발견된 오류를 수정합니다. 계획을 세울 때 오류 감지 프로세스가 포화 법칙을 따른다는 점을 고려해야 합니다. 대부분의 오류는 테스트 초기 단계에서 발견되며, 프로그램에 남아 있는 오류가 적을수록 각 오류를 찾는 데 시간이 더 오래 걸립니다.
블랙박스와 화이트박스라는 두 가지 테스트 전략이 있습니다. 첫 번째를 사용할 때 프로그램의 내부 구조는 고려되지 않으며 올바른 입력 영향과 잘못된 입력 영향에 대한 프로그램 기능을 완전히 확인하는 방식으로 테스트가 설계되었습니다.
화이트박스 전략에는 알고리즘의 모든 분기를 테스트하는 작업이 포함됩니다. 총 분기 수는 각 단계의 모든 대안의 조합에 의해 결정됩니다. 이는 유한한 숫자이지만 매우 클 수 있으므로 프로그램이 여러 조각으로 분할된 후 철저한 테스트를 거친 후 더 긴 분기의 기본 노드로 처리됩니다. 필요한 순서로 명령문의 실행을 보장하는 데이터 외에도 테스트에는 다음이 포함되어야 합니다. 경계 조건 확인(예를 들어 조건에 따른 전환 엑스> 10은 10보다 크거나 작거나 같은 값인지 확인해야 합니다). 에 대한 프로그램의 반응 잘못된 소스 데이터.
불리"화이트 박스" 전략은 이를 사용하여 누락된 분기를 감지하는 것이 불가능하다는 것이며, "블랙 박스" 전략은 많은 수의 입력 옵션이 필요하므로 실제로는 두 전략을 조합하여 사용됩니다.
주목
하향식 테스트 아이디어는 프로그램 테스트가 설계가 완료되기 전에 시작된다는 것을 의미합니다. 이를 통해 주요 모듈 간 인터페이스를 더 일찍 시험해 볼 수 있으며 프로그램이 기본적으로 사용자 요구 사항을 충족하는지 확인할 수도 있습니다. 기본 인터페이스의 올바른 구현에 대한 확신이 있을 정도로 논리 코어를 테스트한 후에만 프로그램의 다음 레벨을 코딩하고 테스트하기 시작합니다.
당연히 프로그램이 뼈대 형태로 제공되는 동안 완전한 테스트는 불가능하지만, 각 후속 레벨을 추가하면 테스트 영역을 점차 확장할 수 있습니다.
하향식 설계의 종단 간 시스템 수준 디버깅 단계는 상향식 설계보다 시간이 덜 걸리고 시스템의 많은 부분에 영향을 미치는 주요 버그가 발생할 가능성이 훨씬 적기 때문에 놀라움도 적습니다. 또한 시스템에 연결된 각 모듈마다 해당 환경이 이미 생성되어 있으며, 디버깅된 모듈의 출력 데이터를 다른 모듈의 테스트를 위한 입력으로 사용할 수 있어 테스트 프로세스가 용이합니다. 이는 모듈이 시스템에 완전히 "원시"로 연결되어야 한다는 의미는 아닙니다. 별도의 모듈을 테스트하는 데 필요한 모든 옵션을 시스템 입력에서 생성하는 것이 어렵기 때문에 테스트의 일부를 자율적으로 수행하는 것이 편리할 수 있습니다. .
순수한 형태의 캐스케이드 모델은 모든 구현 세부 사항을 미리 예측하기 어렵기 때문에 간단한 프로그램에만 사용됩니다. 보다 현실적인 계획은 중간 제어를 사용하는 것입니다(그림 26.2). 각 단계 후에 수행되는 제어를 통해 필요한 경우 더 높은 수준으로 돌아가 필요한 변경을 수행할 수 있습니다.
이러한 계획을 사용할 때의 가장 큰 위험은 개발이 결코 완료되지 않고 끊임없이 개선되고 개선되는 상태에 있다는 것입니다.
쌀. 26.2.
- 유형과 형식은 프로그래밍 언어 유형을 참조하지 않습니다.
최근 프로그래밍에 대한 관심이 급격히 높아졌습니다. 이는 정보통신기술의 발전과 일상생활의 구현에 따른 것이다. 사람이 컴퓨터를 다룬다면 조만간 프로그래밍에 대한 욕구가 생기고 때로는 필요하기도 합니다.
프로그래밍은 프로그램 작성을 목표로 하는 활동 분야입니다. 프로그래밍은 과학이자 예술로 간주될 수 있습니다.
프로그램은 작업을 기계로 구현하도록 설계되었습니다. 프로그램은 문제를 해결하기 위한 일련의 컴퓨터 명령입니다. 이 프로그램은 창의성을 특징으로 하는 지적 작업의 결과입니다.
현재 소프트웨어 제품을 만들 때 여러 가지 문제가 발생하며 주요 문제는 다음과 같습니다.
1. 컴퓨터 기술 및 알고리즘 언어의 급격한 변화;
2. 컴퓨터가 서로 연결되어 있지 않습니다(VAX 및 IBM).
3. 개발된 소프트웨어 제품에 대해 고객과 계약자 간의 완전한 상호 이해가 부족합니다.
프로그래밍 기술의 일반적인 사항을 고려해 봅시다. 물론, 소규모 교육 프로그램을 개발할 때 이 기술의 모든 요소를 구현해야 하는 것은 아니지만(실제로 항상 가능한 것은 아니지만) 그 존재 자체를 실현해야 합니다.
모든 프로그램이나 소프트웨어 시스템의 개발은 특정 사용자 집합에 대한 요구 사항을 결정하는 것으로 시작하여 이러한 사용자가 시스템을 작동하는 것으로 끝납니다.
알고리즘과 프로그램을 개발하는 데는 다양한 접근 방식과 기술이 있습니다. 프로그래밍은 대체로 예술이지만 축적된 전문적 경험을 체계화하고 일반화하는 것은 가능합니다. 프로그램의 설계 및 개발을 여러 연속 단계로 나누는 것이 좋습니다.
1) 문제에 대한 설명
2) 프로그램 설계
3) 모델 구축
4) 알고리즘 개발;
5) 프로그램 작성;
6) 프로그램 디버깅;
7) 프로그램 테스트;
8) 문서.
각 단계를 간략하게 살펴보겠습니다.
문제 해결을 시작하려면 문제를 정확하게 공식화해야 합니다. 우선, 이는 입력 및 출력 데이터를 정의하는 것을 의미합니다. 질문에 대한 답변: a) 주어진 것; b) 찾아야 할 것. 문제 설명을 더 자세히 설명하면 다음과 같은 일련의 질문에 대한 답변이 표시됩니다.
해결책을 결정하는 방법;
어떤 데이터가 누락되었으며 모두 필요합니까?
어떤 가정이 이루어졌는지 등
따라서 간략하게 우리는 무대에서 다음과 같이 말할 수 있습니다. 문제 진술필요한:
초기 데이터 및 결과에 대한 설명
작업의 공식화
특별한 경우(있는 경우)의 프로그램 동작에 대한 설명입니다.
이 작업 과정에서 시스템이 최종 형태(설계)에서 가져야 할 속성이 식별되고, 시스템의 기능과 인터페이스의 특성이 설명됩니다.
프로그램 설계. 첫째, 소프트웨어 시스템의 아키텍처를 설계한다. 다음 단계는 세부 설계입니다. 이 단계에서는 프로그램의 절차적 설명, 각 모듈 구현을 위한 알고리즘의 선택 및 평가가 이루어집니다. 설계 입력은 시스템 요구 사항 및 사양입니다.
프로그램 설계에는 다양한 접근 방식과 방법이 있습니다. 현대 디자인 접근 방식은 분해에 기반을 두고 있으며, 이는 다시 추상화의 사용에 기반을 두고 있습니다. 분해의 목표는 구체적이고 간단한 규칙에 따라 서로 상호 작용하는 모듈을 만드는 것입니다. 분해는 프로그램을 결합할 수 있는 구성 요소로 나누는 데 사용됩니다.
아키텍처 설계 방법은 두 그룹으로 나뉩니다.
1) 처리 중심
2) 데이터 지향.
처리 중심 방법, 다음과 같은 일반적인 아이디어를 포함합니다.
a) 모듈형 프로그래밍.
기본 개념:
각 모듈은 하나의 독립적인 기능을 구현합니다.
단일 입구/출구 지점이 있습니다.
모듈 크기가 최소화됩니다.
각 모듈은 다른 모듈과 독립적으로 개발됩니다.
시스템 전체는 모듈로 구성됩니다.
이러한 원칙에 따라 각 모듈을 개별적으로 테스트한 다음 코딩 및 테스트를 거쳐 통합하고 전체 시스템을 테스트합니다.
b) 기능적 분해.
분할 관리 전략과 유사합니다. 실질적으로 단계별 세부화와 정보 숨기기 개념의 분해입니다.
c) 데이터 흐름을 사용하여 디자인합니다.
프로그램의 일반 설계 라인으로 데이터 흐름을 사용합니다.
단계별 세부 사항이 포함된 하향식 구조 설계 요소가 포함되어 있습니다.
d) 프로젝트의 구조 분석 기술.
시스템 개체 간의 계층적 기능 연결을 구성하기 위한 특수 그래픽 도구를 사용하는 구조 분석을 기반으로 합니다. 다이어그램이 간단하고 읽기 쉬운 시스템 생성 초기 단계에 효과적입니다.
데이터 구조를 기반으로 한 설계 방법, 아래에 설명되어 있습니다.
a) 잭슨의 방법론.
여기서 데이터 구조는 프로젝트 구성의 핵심 요소입니다. 프로그램의 구조는 처리할 데이터의 구조에 따라 결정됩니다. 프로그램은 입력 데이터가 출력 데이터로 변환되는 메커니즘으로 표현됩니다.
b) 워너의 방법론.
이전과 유사하지만 설계 절차가 더 상세합니다.
c) 계층적 다이어그램의 방법.
이 방법에서는 입력, 출력 데이터 및 처리 프로세스 간의 관계가 시스템의 계층적 분해(세부 사항 없음)를 사용하여 결정됩니다. 기본적으로 입력, 처리, 출력의 세 가지 요소가 사용됩니다.
d) 객체 지향 설계 방법론.
정보 은닉과 추상 데이터 유형의 개념을 기반으로 합니다. 핵심 개념은 객체입니다. 각 개체에는 이 데이터를 사용하도록 설계된 일련의 절차가 포함된 일부 데이터 구조가 포함되어 있습니다. 이 방법론을 사용하여 특정 문제 영역에 대한 추상화가 생성됩니다.
모델 구축대부분의 경우 쉬운 일이 아닙니다. 모델링 경험을 얻으려면 알려진 성공적인 모델을 최대한 많이 연구해야 합니다.
모델을 구축할 때 일반적으로 연역적(일반에서 특정으로)과 귀납적(특정에서 일반으로)의 두 가지 원칙이 사용됩니다.
쌀. 3.1. 연역적 방법을 이용한 모델 구축 계획
연역적 접근법(그림 3.1)은 잘 알려진 기본 모델의 특별한 경우를 고려합니다. 여기에서 주어진 가정 하에서 알려진 모델은 시뮬레이션된 객체의 조건에 적응합니다. 예를 들어, 잘 알려진 뉴턴의 법칙을 바탕으로 자유 낙하하는 물체의 모델을 구축할 수 있습니다. ma = mg – F 저항그리고 수용 가능한 근사치로 짧은 시간 동안 균일하게 가속된 운동 모델을 받아들입니다.
쌀. 3.2. 귀납법을 이용한 모델 구축 방안
귀납적 방법(그림 3.2)에는 가설 제시, 복잡한 대상 분해, 분석, 합성이 포함됩니다. 여기서는 시스템의 행위에 대한 가정의 형태로 어떤 패턴을 형성하기 위해 유사성, 유사 모델링, 추론 등이 널리 사용된다.
귀납법을 이용한 모델 구축 기술:
1) 경험적 단계
추론;
직관;
추정;
가설.
2) 모델링 문제에 대한 설명;
3) 평가; 정량적 및 정성적 설명;
4) 모델을 구축합니다.
알고리즘 개발- 가장 복잡하고 시간이 많이 걸리는 프로세스이지만 가장 창의적으로 흥미로운 프로세스이기도 합니다. 개발 방법의 선택은 문제의 공식화와 모델에 따라 달라집니다.
복잡한 문제에 대한 알고리즘을 구성할 때 분해(하향식 설계)와 합성(상향식 프로그래밍)을 사용하는 체계적인 접근 방식이 사용됩니다. 복잡한 시스템의 구조를 개발할 때와 마찬가지로 알고리즘을 구성할 때 연역적 방법과 귀납적 방법이 사용됩니다.
연역적 접근 방식은 잘 알려진 알고리즘 모델의 특별한 경우를 고려합니다. 여기서는 주어진 가정 하에서 잘 알려진 알고리즘이 해결되는 문제의 조건에 적응합니다. 예를 들어, 선형 대수의 많은 계산 문제, 특히 비선형 방정식, 대수 방정식 시스템 등은 서브루틴 및 모듈의 특수 라이브러리가 많이 있는 잘 알려진 방법과 알고리즘을 사용하여 해결될 수 있습니다. 현재 많은 문제(Mathcad, Autocad 등)를 해결할 수 있는 특수 패키지가 널리 보급되었습니다.
귀납적 방법에는 경험적 시스템 접근 방식(분해 - 분석 - 합성)이 포함됩니다. 이 경우 일반적이고 가장 성공적인 방법은 없습니다. 각 특정 사례에서 알고리즘을 찾고 구축할 수 있는 몇 가지 접근 방식이 가능합니다. 알고리즘 개발 방법은 부분 목표 방법, 리프팅 방법, 역방향 작업 방법, 분기 및 경계 방법 등으로 나눌 수 있습니다.
알고리즘을 개발하는 체계적인 방법 중 하나는 구조화된 프로그래밍입니다.
구조적 프로그래밍은 제어 구조 요소를 사용하여 형성된 블록 다이어그램의 사용을 기반으로 합니다.
구성, 대안, 반복이라는 세 가지 기본 구조 요소(제어 구조)가 있습니다.
구성는 순차적으로 다음과 같은 기능 정점으로 구성된 알고리즘의 선형 구성입니다.
S1을 시작합니다. S2; 끝
대안술어 정점을 갖는 분기 구조입니다. 알고리즘의 분기 설계는 포크로 표현될 수 있습니다.
B이면 S1, 그렇지 않으면 S2
불완전한 포크:
반복일반적으로 말하면 구성과 대안으로 구성된 복합 구조인 알고리즘의 순환 설계입니다. 반복은 두 가지 형식으로 표현될 수 있습니다: 전제 조건:
그리고 사후 조건이 있습니다:
B까지 S1을 반복
고려된 각 구조에는 하나의 입력과 하나의 출력이 있습니다. 따라서 모든 컴퓨터 프로그램은 제시된 세 가지 제어 구조로 구성된 블록 다이어그램으로 표현될 수 있습니다.
구조화된 프로그래밍 프로세스는 일반적으로 순서도 개발로 시작됩니다.
하향식 구조적 프로그래밍의 아이디어에는 특정 명령을 작성할 수 있는 기본 구조 수준까지 알고리즘(흐름도)을 점점 더 작은 부분으로 나누는 프로세스가 포함됩니다.
구조화된 하향식 프로그래밍 기술을 설명하기 위해 예를 고려하십시오.
예. 2차 방정식을 푸는 프로그램 개발 기술.
그림에서. 3.3은 알고리즘 구성 프로세스를 단계별로 자세히 설명합니다. 프로그램 개발의 초기 단계에서는 2차 방정식 ax 2 + bx + c = 0의 계수 a, b, c를 입력 데이터로 갖고 출력은 두 근 x1, x2의 값입니다.
하향식 절차의 대안으로 상향식 구조 프로그래밍 방법이 자주 사용됩니다. 본질적으로 우리는 체계적인 방법을 사용하여 최종 결과에 도달합니다. 먼저 문제를 서로 연결(분해)하는 별도의 블록(모듈)으로 나눈 다음, 개발 후 블록을 단일 프로그램(합성)으로 조립합니다. 상향식 접근 방식은 프로시저, 기능, 모듈 및 개체의 표준 및 특수 라이브러리를 최대한 활용하는 모듈식 접근 방식을 선호하는 프로그래머들 사이에서 널리 퍼져 있습니다.
무대에서 프로그램 작성개발된 알고리즘에 따라 선택된 프로그래밍 언어로 프로그램이 컴파일됩니다.
프로그램 디버깅오류를 발견하고 수정하는 과정이다. 소프트웨어 오류는 구문(프로그래밍 언어 구문)과 알고리즘(논리)의 두 가지 클래스로 나눌 수 있습니다. 구문 오류는 프로그램을 컴파일하는 동안 식별됩니다. 이는 수정하기 가장 쉬운 오류입니다. 프로그램의 알고리즘 오류는 식별하기가 훨씬 더 어렵습니다. 프로그램은 작동하지만 잘못된 결과를 생성합니다. 이 클래스의 오류를 감지하려면 프로그램 테스트 단계가 필요합니다.
테스트오류를 식별(감지)하기 위해 프로그램을 실행하는 프로세스입니다.
프로그램을 테스트하는 방법에는 여러 가지가 있습니다.
프로그램을 "블랙 박스"로 테스트합니다. "블랙 박스" 전략은 입력 데이터와 프로그램 결과를 분석하여 테스트를 정의합니다. 철저한 입력 테스트의 기준은 가능한 모든 입력 데이터 세트를 사용하는 것입니다.
프로그램을 "화이트 박스"로 테스트하는 것은 프로그램의 논리를 제어하여 내부 구조를 사용할 수 있도록 하는 전략입니다. 기준은 프로그램의 모든 경로와 제어 구조를 철저하게 테스트하는 것입니다.
합리적이고 실행 가능한 테스트 전략은 블랙 박스 모델과 화이트 박스 모델의 조합입니다.
테스트 원칙:
출력이나 결과의 기대값에 대한 설명은 테스트 케이스의 필수 부분이어야 합니다.
부정확하고 예상치 못한 입력에 대한 테스트는 정확하고 의도된 입력에 대한 테스트만큼 신중하게 설계되어야 합니다.
프로그램이 의도한 대로 수행되는지 여부뿐만 아니라, 해서는 안 되는 작업도 수행하는지 여부도 확인해야 합니다.
프로그램을 개발할 때 컴퓨터 없이 검사와 Walk-through view(드라이 테스트)를 기반으로 하는 “수동 테스트” 방법은 매우 유용할 수 있습니다.
검사 및 조사는 텍스트를 읽을 때 오류를 감지하기 위한 일련의 절차 및 기술입니다.
프로그래밍 중에 발생하는 주요 오류 유형은 다음과 같습니다.
값이 할당되거나 초기화되지 않은 변수에 대한 액세스;
배열 경계를 넘어서는 인덱스.
변수 유형 또는 속성의 불일치
명시적 또는 암시적 메모리 주소 지정 문제
잘못된 제어 전송;
논리적 오류.
설계 시 테스트 절차에는 가장 많은 오류를 감지할 확률이 가장 높은 일련의 테스트가 포함됩니다. 철저한 테스트를 위해 입력 매개변수의 동등한 파티션이 생성되고 올바른 입력 데이터와 잘못된(잘못된 입력 값)이라는 두 가지 클래스가 제공됩니다. 각 동등 클래스에 대해 자체 테스트가 구축됩니다. 테스트 등가 클래스는 테스트 중 하나에서 알고리즘을 실행하면 다른 테스트를 실행할 때 유사한 결과가 보장되는 테스트 집합으로 정의할 수 있습니다.
경계 조건에서의 테스트에는 특별한 주의를 기울여야 합니다. 경계 조건은 입력 및 출력 등가 클래스의 경계 위, 위 또는 아래(즉, 등가 파티션의 경계 근처)에서 직접 발생하는 상황입니다.
테스트 프로세스 자체는 단계별 및/또는 모놀리식일 수 있습니다. 두 경우 모두 하향식 테스트 전략이 사용됩니다. 즉, 상단, 헤드 모듈에서 시작하여 다른 모듈을 직렬로 연결(스텁 장치)하고 상향식 테스트는 개별 모듈 테스트부터 시작됩니다.
프로그램을 디버깅하는 과정에서 무차별 대입 방법을 사용합니다. 즉, 프로그램 전체에서 중간 데이터 출력을 사용하거나(추적) 자동 수단을 사용합니다. 예를 들어, 터보 파스칼에는 강력한 자동 프로그램 디버깅 장치(DEBUG 모드)가 있습니다.
위의 모든 것에서 테스트는 알고리즘의 모든 분기를 포괄하는 테스트 세트(입력 데이터 - 예상 결과) 컴파일로 구성됩니다.
프로그래머에게는 황금률이 있습니다. 다른 사람이 작성한 프로그램을 보고 싶은 형태로 프로그램을 설계하십시오. 각 최종 소프트웨어 제품은 다음을 충족해야 합니다. 문서화된 지원도움말(help), 파일 텍스트(readme.txt) 형식으로 제공됩니다.
보안 질문
1. 프로그램 작성 단계를 나열하십시오.
2. 작업 설정 단계에서는 어떤 작업이 이루어지나요?
3. 분해란 무엇입니까?
4. 모델 구축 단계에서는 어떤 원칙이 사용됩니까?
5. 구조화된 프로그래밍은 어떤 원칙을 기반으로 합니까?
6. 구조적 프로그래밍의 기본 구조 요소는 무엇입니까?
7. 구조화된 프로그래밍의 요소로서 어떤 두 가지 형태의 반복을 알고 있습니까?
8. 하향식 구조 프로그래밍의 아이디어는 무엇입니까?
9. 상향식 구조 프로그래밍의 아이디어는 무엇입니까?
10. 프로그램 디버깅이란 무엇입니까?
11. 어떤 종류의 소프트웨어 오류를 알고 있으며 언제 감지됩니까?
12. 프로그램 테스트의 목적은 무엇입니까?
13. 어떤 테스트 방법을 알고 있나요?
14. 테스트에서의 "화이트 박스" 전략은 "블랙 박스" 전략과 어떻게 다릅니까?
이 기사에서는 모든 프로그래밍 언어로 작성된 프로그램을 개발하는 주요 단계를 공개하려고 합니다.
사양(프로그램 요구 사항 정의):
이 단계에서는 소스 데이터에 대한 자세한 설명이 발생하고 결과 결과에 대한 요구 사항이 공식화되며 특별한 경우(예: 잘못된 데이터가 입력된 경우)가 발생할 때 가능한 모든 프로그램 동작이 고려되고 대화 상자가 개발됩니다. 사용자와 프로그램 자체 간의 상호 작용을 보장합니다.
알고리즘 개발:
이 단계에서 프로그래머는 원하는 결과를 얻기 위해 이후에 수행해야 하는 필수 작업의 순서를 결정합니다.
주어진 문제가 여러 가지 방법으로 해결될 수 있는 상황이 발생한다면 물론 솔루션 알고리즘에 대한 다양한 옵션이 가능합니다. 그런 다음 프로그램 개발자는 몇 가지 중요한 기준(예: 알고리즘 해결 속도)을 기반으로 보다 적합한 솔루션을 선택합니다.
이 프로그램 개발 단계의 결과는 프로그램 알고리즘에 대한 자세한 구두 설명 또는 알고리즘의 블록 다이어그램입니다. 이 기사를 연구하면 모든 프로그램에 대한 알고리즘을 개발하는 방법에 대해 자세히 배울 수 있습니다.
코딩:
솔루션 알고리즘을 지정하고 작성한 후 사용되는 알고리즘은 궁극적으로 필요한 프로그래밍 언어(Pascal, Delphi, C++ 등)로 작성됩니다. 코딩 단계의 결과는 완성된 프로그램입니다.
프로그램 개발 단계. 디버깅:
이 단계에서 프로그래머는 프로그램을 디버깅합니다. 즉, 오류를 찾아 제거합니다. 후자는 알고리즘과 구문(소스 프로그램 텍스트의 오류)이라는 두 그룹으로 나뉩니다. 이 두 가지 오류 그룹 중에서 구문 오류는 제거하기 가장 쉬운 반면, 알고리즘 오류는 식별하기가 매우 어렵습니다.
디버깅 단계는 원래 프로그램이 하나 또는 두 개의 원시 데이터 세트에서 올바르게 작동하는 경우에만 완료된 것으로 간주됩니다. 이 기사를 읽으면 프로그램의 컴파일이 무엇인지, 프로그램이 수행하는 주요 작업이 무엇인지 알아볼 수 있습니다.
테스트:
대부분의 경우 프로그래머는 개인용이 아닌 다른 사람이 자신의 프로그램을 사용할 수 있도록 프로그램을 만들기 때문에 프로그램 테스트는 매우 중요합니다. 테스트 단계에서 개발자는 올바른 입력 데이터 세트와 특별히 선택된 잘못된 데이터 세트 모두에서 프로그램의 동작을 확인합니다.
도움말 시스템 만들기:
프로그래머가 나중에 다른 사람이 사용할 수 있도록 프로그램을 개발하는 경우 프로그래머는 도움말 시스템을 개발하고 사용자가 프로그램 작업 시 이 도움말 시스템에 쉽고 빠르게 액세스할 수 있도록 해야 합니다. 최신 프로그램에는 CHM 또는 HLP 파일 형식의 도움말 정보가 있습니다.
도움말 정보 외에도 도움말 시스템에는 프로그램 설치에 필요한 지침이 포함되어 있습니다. 일반적으로 *.doc, *.txt, *.htm 등 다양한 형식의 Readme 파일 형태로 제공됩니다. 프로그램 개발의 고려되는 단계는 나중에 더 자세히 설명됩니다.
설치 디스크(CD-ROM) 만들기:
개발자는 사용자가 프로그래머의 도움 없이 독립적으로 이 프로그램을 PC에 설치할 수 있도록 설치 디스크(CD-ROM)를 만듭니다.
일반적으로 설치 CD-ROM에는 프로그램 자체 외에도 프로그램 설치에 대한 도움말 파일과 지침이 포함되어 있습니다. Delphi 환경에서 개발된 프로그램을 포함한 대부분의 최신 프로그램은 많은 경우 단순히 파일을 복사하는 것만으로는 사용자 컴퓨터에 설치할 수 없습니다. 이러한 프로그램이 올바르게 작동하려면 특수 라이브러리가 필요하기 때문입니다. 특정 사용자의 PC에는 존재할 수 없는 구성 요소도 포함됩니다.
프로젝트를 어떤 방향으로 발전시켜야 할지 모른다면, 스스로 올바른 길을 선택할 가능성은 거의 없습니다.
스티브 맥코넬
소개
이전 기사 "소프트웨어 개발 프로세스 개요"에서 나는 현재 내 실무에서 개발된 개발 프로세스의 "최상위 수준"에 대해 이야기했습니다. 리뷰 서문에서 나는 사용된 용어를 공식화하려고 노력했고 문제의 프로세스를 사용한 일부 프로젝트의 예를 제시했습니다.오늘은 소프트웨어 개발 준비 단계를 어떻게 진행하는지 알려드리겠습니다. 준비 단계에는 고객과 공연자라는 두 명의 집단 행위자가 있습니다. 각 당사자는 무대 내에서 자신의 이익과 목표를 가지고 있습니다. 준비 단계를 설명하면서 두 가지 관점, 두 관점의 관계 및 가능한 이해 상충을 제시하려고 노력할 것입니다.
소프트웨어 개발 프로세스의 준비 단계에서는 개발자가 소프트웨어 제품 구현을 수행할지 여부를 결정하는 매우 간단한 목표를 갖습니다. 시스템 고객의 관점에서 볼 때 이 단계의 목표는 계약자를 신뢰할 수 있는지 여부를 결정하는 것입니다. 이벤트가 성공적으로 진행되면 준비 단계의 자연스러운 결과는 고객이 요구하는 시스템의 생성 또는 수정에 대한 계약(또는 적절한 경우 기타 계약)의 체결이 되어야 합니다.
목표를 달성하기 위해 고객과 계약자는 다음과 같이 잘 정의된 여러 작업을 공동으로 해결해야 합니다.
- 초기 아이디어를 바탕으로 향후 프로젝트의 목표와 목적을 공식화합니다.
- 몇 가지 초기 비전, 즉 프로젝트의 개념을 개발하십시오.
- 미래 제품에 대한 수요 분석을 수행합니다.
- 향후 프로젝트에 대한 예비 위험 평가를 수행합니다.
- 예비 위험의 개념과 목록을 기반으로 예비 기술 솔루션을 준비합니다.
- 개발 방법론을 선택하고 예비 작업 계획을 준비합니다.
- 인건비와 필요한 자원에 대한 예비 평가를 수행합니다.
- 제품 타당성 분석을 수행합니다.
- 기술 솔루션에 대한 독립적인 검토를 수행합니다.
- 작업을 계속할지 여부를 결정합니다.
초기 정보는 매우 부족할 수 있습니다. 대부분의 경우 이는 고객, 관리자 또는 팀원 중 한 명(어쩌면 귀하)의 마음속에 떠오른 아이디어일 뿐입니다. 이 아이디어가 실제 제품으로 구현될지는 대부분 준비 단계에서 결정됩니다.
소프트웨어 개발 준비 단계의 활동 다이어그램이 그림 1에 나와 있습니다. 특히 이 단계에 대한 자금 조달이 항상 고객에게서 나오는 것은 아니라는 점을 고려하면 다소 무섭게 보입니다. 그러나 때로는 이러한 거의 모든 문제가 시스템 설계자의 숙련된 눈에 의해 해결되고, 한 시간 반 후에 그는 근거 있는 평가를 제공할 준비가 됩니다. 때로는 준비 단계가 몇 주 동안 지속될 수도 있습니다. 특히 고객이 자신의 아이디어를 명확하게 공식화할 수 없고 정치적 이유로 프로젝트를 포기하기 어려운 경우에는 더욱 그렇습니다.
그림 1. 예비 단계에서 프로젝트 참가자의 활동.
물론 프로젝트의 성격 자체도 무대 기간에 영향을 미칩니다. 정부 기관이나 국가가 참여하는 회사를 대신하여 수행해야 할 작업이 있는 경우 준비 단계에서 입찰 준비에 대해 이야기할 가능성이 높습니다. 이 경우 모든 단계에서 최대 수준의 공식화로 작업해야 하며, 물론 작업 속도가 빨라지지는 않습니다. 내부 고객의 요청에 따라 향후 프로젝트가 수행되는 경우, 수행자가 현실적인 견적을 제공할 수 있도록 지나치게 참을성 없는 관리자의 열정을 소멸해야 하는 경우가 더 자주 발생합니다.
제 생각에는 공연자에게 가장 편안한 것은 투자 상품 작업을 하는 것입니다. 여기서는 필요한 프로세스 활동과 디자인 제한 사이의 균형을 유지하는 것이 다소 더 쉽습니다.
여기에 나열된 모든 작업을 해결하고 소요된 시간과 예산이 낭비되지 않고 실질적인 이점을 가져올 것이라고 확신할 때까지 프로젝트를 계속하지 않는 것이 중요합니다. 소프트웨어를 개발할 때 어떤 방법론을 사용하든 준비 단계에서 지정된 모든 작업을 해결해야 합니다. 실습에 따르면 특정 제품 개발을 위한 방법론 선택은 준비 단계가 아닌 준비 단계에서 이루어져야 합니다. 예를 들어 스크럼과 같이 개발 접근 방식을 변경하고 포기하고 싶지 않았기 때문에 프로젝트를 실행 불가능하다고 포기한 팀을 알고 있습니다. 방법론을 선택하는 팀의 유연성은 프로젝트의 타당성을 평가하는 데 필수적인 요소입니다.
아래에서는 준비 단계의 각 작업의 특징을 공개하고 실제로 이를 해결하는 방법을 알려 드리겠습니다.
미래 프로젝트의 목표와 목표 수립
나는 프로젝트의 목표와 목적을 공식화하는 것이 소프트웨어 개발 프로젝트의 가장 중요한 단계 중 하나라고 확신합니다. 그 중요성은 이 단계에서 소프트웨어 제품 고객이 계약자에게 자신의 아이디어를 소개하고 향후 프로젝트 개발 방향을 설정하며 프로젝트가 넘어서는 안 되는 최대 허용 한계를 결정한다는 사실에 있습니다. 고객이 계약자가 접근할 수 있는 형식으로 자신의 아이디어를 계약자에게 알리지 않으면 계약자는 작업을 완료할 수 없습니다. 고객이 향후 프로젝트의 목표를 잘못 또는 부정확하게 정의하는 경우 계약자는 자신의 활동에 대한 지침을 갖지 못하며 고객의 계획을 구현할 수 없을 것입니다. 나중에 오류가 발견되더라도 프로젝트 방향을 바꾸면 상당한 비용이 발생하게 됩니다. 마지막으로, 프로젝트의 최대 제한으로 인해 프로젝트가 구현되지 않을 경우 고객과 계약자가 허용할 수 없는 손실을 피할 수 있습니다.프로젝트의 목표와 목적을 공식화할 때 다음 질문에 대한 답변을 제공하는 문서를 작성해야 합니다.
- 특정 프로젝트의 주제 영역은 어떻게 정의됩니까? 해당 주제 영역에서는 어떤 용어가 사용됩니까? 주제 영역에서 프로젝트의 영향을 받는 비즈니스 프로세스는 무엇입니까?
- 프로젝트의 목표는 무엇입니까? 개발된 시스템은 해당 분야의 비즈니스 프로세스에 어떤 영향을 미쳐야 합니까?
- 목표를 달성하려면 어떤 과제를 해결해야 합니까? 할당된 작업 해결 품질은 어떤 기준으로 평가됩니까? 개발 중인 시스템의 기능적, 비기능적 품질 지표는 무엇입니까?
- 프로젝트 실행 시 마감일, 자원 및 예산에 어떤 제한이 적용됩니까?
이러한 질문에 대한 답변을 통해 구현자는 프로젝트의 개념을 공식화하고 관련성과 타당성을 평가할 수 있어야 합니다. 고객에게는 이러한 질문에 대한 답변의 정확성이 중요합니다. 왜냐하면 이 정보는 고객이 특정 계약자에게 작업을 신뢰할지 여부를 결정할 수 있는 기준을 설정하기 때문입니다.
일반적으로 목표와 목표를 공식화하는 것은 프로젝트 아이디어의 전달자로서 고객입니다. 그런데 실제로 우리 공연자들이 이 일을 해야만 하는 경우가 있었어요. 우리는 특정 정부 서비스를 위한 매우 구체적인 시스템을 개발하기 위한 입찰에 직면했습니다. 이러한 프로젝트에는 특징이 있습니다. "위로부터"서비스에는 특정 시스템을 개발하고 유지 관리하라는 명령이 주어지지만 서비스 자체는 일반적으로 시스템의 사용자가 아닙니다. 당연히 서비스의 리더십이 주도권을 잡고 경쟁을 발표합니다. 하지만 서비스 자체에서는 개발 중인 제품이 어떤 목적으로, 어떻게 사용될지는 누구도 모릅니다. 그리고 무엇보다도 최악인 것은 아무도 알고 싶어하지 않는다는 것입니다. 이러한 조건에서는 고객(정부 서비스)의 시스템에 대한 초기 비전이 거의 전혀 없습니다. 고객은 프로젝트의 목표나 목적을 공식화할 수 없습니다. 우리는 고객의 모든 장비를 직접 살펴보고, 필요한 기술 문서를 찾고, 다양한 정부 부서의 최종 사용자에게 연락해야 했습니다. 결국 우리는 프로젝트를 성공적으로 완료하고 이익과 좋은 경험을 얻었으며 가장 중요한 것은 고객으로부터 추천을 받았습니다. 그러나 이 상황은 여전히 예외이다. 프로젝트의 목표와 목적은 아이디어 소유자가 공식화해야합니다.
외부 고객을 위한 소프트웨어 개발의 목표와 목적은 "기술 요구 사항"이라는 문서 형식으로 경쟁이 발표될 때 계약자가 받는 경우가 많습니다. 이름에도 불구하고 이는 시스템에 대한 요구 사항이 아니라 고객의 눈을 통해 시스템 비전을 표현한 것임을 이해하는 것이 중요합니다.
위의 질문을 처음부터 해결하는 것이 중요한 이유는 무엇입니까?
와 함께 주제 영역간단합니다. 고객이 수행할 작업과 관련된 조건 및 비즈니스 프로세스에 대해 이야기할 때까지 고객과 계약자는 서로를 이해할 수 없습니다. 이 문제를 공식적으로 받아들이실 것을 강력히 권합니다. 도메인 설명은 프로젝트에서 가장 간단한 활동 중 하나이지만 프로젝트의 기초가 된다는 점을 기억하세요. 프로그래머가 고객의 비즈니스 프로세스를 오해하면 기능을 잘못 구현할 수 있으며 고객이 이 기능을 사용하기 전까지는 불일치를 판단하는 것이 불가능합니다. 그러나 그때쯤이면 함수 위에 두 개 이상의 애플리케이션 코드 계층이 작성될 것이며, 단순히 피할 수 있었던 오류를 수정하는 것은 매우 비용이 많이 드는 작업이 될 것입니다.
동일한 고객의 주문에 대한 주제 영역 설명은 한 입찰의 문서에서 다른 입찰의 문서로 이동하는 경우가 많습니다. 이는 문서 규칙으로 인해 발생합니다. 내부 고객 프로젝트 또는 투자 소프트웨어에 대한 작업이 수행되는 경우 주제 영역에 대한 설명이 별도의 문서에 표시되는 경우가 있습니다. 투자 프로젝트 중 하나에서 우리는 제품의 세 가지 버전을 동시에 작업했습니다. 하나는 유지보수 중이었고, 하나는 개발 중이었고, 세 번째는 이제 막 준비 단계에 들어섰습니다. 이것은 우리 자신의 프로젝트였기 때문에 우리는 개발 전략의 우선순위에 따라 개발 목표를 독립적으로 결정할 수 있는 특권을 누렸습니다. 팀원은 수시로 바뀌기 때문에, 주제 영역에 대한 설명이 모든 사람에게 지속적으로 제공되는 것이 중요했습니다. 그리고 버전마다 주제 영역이 거의 변하지 않았기 때문에 설명을 모든 버전에 공통되는 별도의 문서로 분리하고 필요에 따라 보완했습니다.
프로젝트 목표프로젝트의 발전 방향을 설정합니다. 생성되거나 현대화된 시스템이 고객의 비즈니스 프로세스에 미치는 영향을 간단하고 명확하게 나타내야 합니다. 목표가 정확하게 지정되지 않으면 프로젝트가 잘못된 방향으로 발전하게 됩니다. 프로젝트를 다른 방향으로 전환하는 것은 매우 어렵고, 프로젝트 내에서 더 많은 작업이 수행될수록 개발 방향을 조정하는 것이 더 어려워집니다. 머지않아 프로젝트는 목표 설정의 실수를 수정할 수 없는 지점에 도달하게 되며, 그런 다음 처음부터 다시 시작하거나 프로젝트를 완전히 포기해야 할 것입니다.
실제로 프로젝트 초기에 상당한 불확실성이 존재하기 때문에 프로젝트의 정확한 방향을 결정하는 것은 매우 어렵습니다. 따라서 실제로는 좁은 벡터 대신 프로젝트 개발의 예상 벡터와 일치하는 축을 사용하여 일종의 "원추"를 얻습니다. 개발 과정에서 프로젝트는 주어진 방향에서 벗어나게 되며, 목표의 불확실성이 넓어질수록 프로젝트는 이 원뿔에 더 많이 "매달려"지게 됩니다. 목표가 명확하지 않으면 프로젝트가 의도한 벡터에서 크게 벗어날 수 있으며 결과적으로 개발된 시스템이 할당된 실제 문제를 해결하는 데 적용되지 않을 수 있습니다.
목표를 달성하려면 한 사람 이상의 노력이 필요할 수 있습니다. 예를 들어, 시스템을 만들려면 특수 하드웨어를 개발하거나 일부 타사 소프트웨어를 수정해야 할 수도 있습니다. 그렇기 때문에 목표 설정특정 수행자가 프로젝트의 틀 내에서 달성해야 하는 , 목표 설정만큼 중요합니다. 계약자는 프로젝트에서 자신의 역할, 고객 및 기타 수행자와의 상호 작용 경계, 프로젝트에 중요한 기타 뉘앙스를 이해해야 합니다.
작업을 설정할 때 작업이 승인되는 기준을 공식화하는 데 특별한 주의를 기울여야 합니다. 시스템 품질 지표는 고객만이 설정할 수 있으며 프로젝트의 타당성을 평가할 때 중요합니다. 기능적, 비기능적 핵심 품질 지표를 명시해야 합니다. 예를 들어, 시스템에서 동시에 작업할 수 있는 사용자 수, 계산된 데이터 계산에 소요되는 최대 시간, 사용자 인터페이스가 고객의 기업 스타일이어야 하는지 여부 등을 표시해야 합니다.
어떤 경우에는 고객이 작업 수락 절차와 독립 감사인 참여 가능성을 규정합니다.
이미 목표와 목표를 수립하는 단계에서 다음을 설정하는 것이 중요합니다. 프로젝트 범위, 초과하면 프로젝트를 중단해야 함을 의미합니다. 제약 조건은 공식화된 목표와 함께 불확실성을 줄이고 프로젝트의 제어 가능성을 높입니다. 부정적인 시나리오에서는 프로젝트가 명시된 범위를 벗어나 너무 많은 비용과 시간이 소비되기 전에 중단될 것입니다. 제한 사항을 정의하면 고객과 계약자가 가능한 프로젝트 실패의 결과로부터 비즈니스를 보호할 수 있습니다.
제한의 두 번째 긍정적인 측면은 프로젝트 내에서 확실히 수행되지 않는 작업의 경계를 명확하게 설정할 수 있다는 것입니다. 이러한 제한은 개발자의 시간을 크게 절약하고 향후 프로그램에서 오랫동안 유지 관리해야 하는 불필요하고 복잡하며 불필요한 기능을 제거할 수 있습니다.
제약은 시간 제약, 예산 제약, 자원 제약의 세 가지 유형으로 나눌 수 있습니다.
목표 수립 단계의 시간 제한은 목표 날짜와 개발된 시스템을 상용화하는 데드라인이라는 두 가지 날짜를 결정해야 합니다.
목표 날짜는 개발자에게 지침을 제공합니다. 동시에 프로젝트 작업 시간을 단축하거나 크게 늘릴 수 있으며 두 번째 작업이 첫 번째 작업보다 훨씬 더 가능성이 높은 프로젝트의 불확실성을 기억해야 합니다. 프로젝트가 진행됨에 따라 목표 날짜를 업데이트해야 합니다.
시스템 가동 기한은 어떤 상황에서도 프로젝트가 넘지 말아야 할 한계선이다. 이 기간은 고객과 계약자가 프로젝트가 실패할 경우 작업을 계획하는 데 사용됩니다. 계획된 기간이 이 한도를 초과하면 프로젝트를 중지해야 합니다.
예산 제한에는 두 가지 값, 즉 지속적인 모니터링과 설명이 필요한 프로젝트의 계획 예산과 프로젝트가 초과해서는 안 되는 최대 예산 값도 포함됩니다.
사용되는 리소스에 대한 제한은 개발 중인 시스템에 따라 다릅니다. 특히, 프로그램이 실행되어야 하는 하드웨어 및 소프트웨어 플랫폼의 선택, 운영 모드 표시기, 문서 및 프로그램 코드 개발을 위한 기술 선택을 제한해야 합니다. 맞춤형 소프트웨어의 경우 하드웨어 가상화 환경, 바이러스 백신 보호 또는 기타 데이터 보호 도구와의 호환성, 고객에게 중요한 기타 제한 사항을 지원하기 위한 요구 사항이 도입될 수 있습니다. 가능하다면 목표 및 최대 허용 한계를 지정해야 합니다.
네 가지 질문에 대한 답변은 모두 문서 형식으로 기록하고 버전 관리 시스템에 입력해야 하며(하청업체에 작업을 할당하는 계약업체의 경우 특히 그렇습니다) 공개적으로 사용할 수 있어야 합니다. 합리적인 수준의 형식주의가 유지되어야 합니다. 이 작업을 담당하는 경우 시간을 들여 프로젝트의 목표와 목적을 공식화하고 프로젝트가 진행됨에 따라 프로젝트가 올바른 방향으로 진행되고 있는지, 목표가 충분히 명확한지, 작업이 제대로 진행되고 있는지 지속적으로 모니터링하십시오. 완전히 정의되어 있습니다. 목표와 목표에 대한 설명을 주기적으로 검토하여 이를 명확하게 하고 프로젝트의 불확실성을 압축합니다.
귀하의 비즈니스에 중대한 영향을 미칠 내부용 시스템을 개발하려는 경우, 높은 수준의 작업 공식화를 포함하여 엄격하게 이를 투자 프로젝트로 취급해야 합니다. 귀하의 비즈니스 안정성은 귀하가 사용하는 시스템의 안정성을 결코 초과하지 않으며 시스템의 모든 실수에 대해 7배의 대가를 치르게 됩니다.
실제로 단 한 가지 경우에만 프로젝트 목표를 공식화할 때 공식적인 접근 방식을 포기할 수 있습니다. 단 하나! 사무용품과 화장지의 평균 가격을 배경으로 볼 수 없는 고장으로 인한 피해, 사소한 문제를 해결하는 소규모 유틸리티를 개발한 사례입니다.
프로젝트 컨셉 개발
시스템 개념의 생성에 대해 이야기하기 전에 이야기를 하나 들려 드리겠습니다.약 2년 전, 당시 제가 근무했던 부서의 한 팀은 러시아의 주요 운송 회사 중 하나를 위한 매우 크고 복잡한 시스템을 개발하기 위한 입찰을 준비해야 했습니다. 그 당시 저는 다른 프로젝트를 진행하고 있었습니다. 그러나 작업을 시작한 지 꽤 오랜 시간이 지나서 프로젝트 관리자가 나에게 도움을 요청했습니다. 프로젝트의 문제는 참가자 중 누구도 시스템이 어떻게 작동해야 하는지 이해하지 못했다는 것입니다. 이는 시스템의 규모와 이러한 복잡한 프로젝트를 처리할 팀의 경험이 부족하기 때문일 수 있습니다. 하지만 제가 이 주제를 다루기 시작했을 때 가장 먼저 발견한 것은 팀의 성공에 대한 자신감이 전혀 없다는 것이었습니다. 둘째, 프로젝트를 어떻게 진행해야 할지에 대한 이해가 전혀 부족합니다. 이미 한 달 이상이 지났음에도 불구하고 주요 질문은 남아 있습니다. 최소한 고객에게 무엇을 물어봐야 할까요? 시작하다일하다?
여기에는 재미있는 것이 없습니다. 각 전문가는 대부분 자신의 분야의 전문가입니다. 여기에 필요한 것은 엄청난 양의 고객 기대를 모두 흡수하는 동시에 고객의 아이디어를 현실적인 솔루션의 형태로 표현하기 위해 복잡한 정보 시스템을 개발하는 데 충분한 경험을 가진 사람이었습니다. 미래 시스템의 규모가 커질수록 컨셉 개발자에게 더 많은 기술과 지식이 요구됩니다. 팀에 그러한 전문가가 없으면 프로젝트가 중단됩니다. 우리 프로젝트에서 시스템 설계자는 개념의 개발 및 추가 지원을 담당합니다. 그는 또한 제품이 컨셉에 따라 엄격하게 판매되도록 하는 책임도 맡고 있습니다. 그리고 나는 이 직책에 개발자를 고용하는 것을 권장하지 않습니다. 심지어 경험이 풍부한 개발자라도 이 직위에는 고품질 코드를 작성하는 재능이 고객과 대화하는 능력과 결합되는 경우가 거의 없으며 프로그래머가 규정을 준수하려는 경우는 더욱 드뭅니다. 개념.
우리에게 가장 큰 문제는 고객이 프로젝트의 목표를 가장 일반적인 용어로 정의했지만 작업이 전혀 공식화되지 않았다는 것입니다. 우리는 이전 섹션에서 제가 이야기한 모든 것을 스스로 해야 했고, 고객 담당자와 반복적으로 만나야 했습니다. 그러나 고객이 특정 질문에만 답변하는 방식은 계약자와 고객 간의 최악의 상호 작용 방식입니다. 그리고 이제 우리가 어떤 질문을 할지는 나에게 달려 있었습니다.
나는 올바른 우선순위를 설정하고 고객을 위한 가장 중요한 질문 목록을 작성하는 데 내 모든 경험을 쏟아부어야 했습니다. 다음 몇 주 동안 모든 정보가 지속적으로 나에게 전달되었고 나는 이를 체계화하여 퍼즐처럼 고객의 기대와 가능한 구현에 대한 완전한 그림을 구성하려고 노력했습니다.
그리고 팀 전체가 회의실에 모인 날이 있었습니다. 그리고 시스템이 개발되는 모습을 어떻게 보았는지 이야기했습니다. 나는 많은 질문에 답함으로써 내 비전을 방어해야 했습니다. 하지만 더 많은 질문에 답할수록 팀은 더 자신감을 갖게 되었습니다. 그들은 이 거대한 시스템을 만들 수 있다고 믿었습니다. 그들은 다시 자유로워졌고 복잡한 문제를 창의적으로 해결할 수 있었습니다.
이 개념이 프로젝트 참가자에게 어떻게 생명을 주는 영향을 미치는지에 대한 유일한 예는 아닙니다. 특히 고객 자신이 자신의 아이디어를 구현하는 방법을 이해하지 못하는 경우에도 동일한 반응이 관찰됩니다. 몇 개의 다이어그램과 짧은 프리젠테이션이 때로는 고객과 계약자 사이의 불신을 완전히 녹일 수 있습니다.
컨셉은 마술이다. 건축이 프로젝트의 뼈대라면 컨셉은 프로젝트의 정신입니다. 아무런 개념도 없고, 프로젝트는 생명이 없는 몸으로 남겨져 곧 악취가 나기 시작합니다. 그러나 그것이 있으면 프로젝트가 발전하고 개념이 더 잘 실행될수록 프로젝트는 더 건강해지고 프로젝트 팀원은 더 자신감과 성공을 거둘 수 있습니다.
하지만 컨셉을 만들고 이를 고객과 조율하는 것만으로는 충분하지 않습니다. 소프트웨어 시스템의 모든 개발은 수용된 개념에 따라 완전히 수행되어야 합니다. 누구도 이를 위반하도록 허용되어서는 안 됩니다. 예, 심각한 사유가 있는 경우 수정될 수 있고 수정되어야 합니다. 그러나 그 이유는 심각할 것입니다. 그리고 결정은 최고 수준에서 이루어져야 하며 항상 고객의 동의를 얻어야 합니다.
기억하세요: 개념이 없으면 프로젝트는 죽은 것입니다. 프로젝트의 일부가 컨셉에 의해 지원되지 않으면 프로젝트의 해당 부분이 죽거나 프로젝트의 다른 부분을 감염시켜 전체 프로젝트가 죽게 됩니다. 개념이 있지만 완전히 따르지 않으면 프로젝트가 때때로 중단되고 궁극적으로 허용 가능한 시간과 예산을 초과하게 됩니다. 팀의 비전이 고객과 합의한 비전과 다르다면, 요청받은 시스템을 만드는 것이 아닙니다. 나는 이 진술에서 어떤 타협도 본 적이 없습니다.
투자 프로젝트를 진행하는 경우 제품 개념을 통해 비즈니스 개발 전략을 수립할 수 있습니다. 이를 통해 귀하의 제품이나 서비스의 새로운 소비자를 찾을 수 있습니다. 올바른 마음을 가진 최고 관리자 중 누구도 시스템의 코드나 아키텍처를 깊이 파고들지 않을 것입니다. 깨끗한 코드나 팀의 개발 방법론에 대해 이야기한다고 해서 고객을 확보할 수는 없습니다. 그러나 컨셉에 대한 다채로운 그림을 보여주면 모든 것이 올바른 방향으로 움직이기 시작합니다. 귀하의 제품 비전은 파트너, 소비자, 심지어 경쟁사의 비전이 됩니다. 그러나 이는 시스템을 설계하는 동안 개념을 엄격하게 준수하는 경우에만 작동합니다.
프로젝트에 컨셉의 정신을 불어넣고 건강을 유지하며 절대 잃지 마세요.
프로젝트 팀은 목표와 목표를 수립하는 단계에서 고객이 거의 참여하지 않습니다. 더 자주 공연자는 대회 직전에 문구를 받게 되는데, 이는 조작에 많은 시간을 주지 않습니다. 동시에 위의 예에서 볼 수 있듯이 고객은 프로젝트 목표 및 목표 공식화의 정확성에 항상 충분한 관심을 기울이지 않습니다. 따라서 컨셉 개발을 시작할 때 계약자는 고객이 보여주려고 하는 미래 제품의 그림을 기꺼이 또는 비자발적으로 검토해야 합니다. 적어도 고객의 기대를 알기 위해서입니다.
검토의 목적은 공식이 얼마나 잘 만들어졌는지 확인하고 가능하다면 이를 명확히 하는 것입니다. 목표와 목적이 입찰 참여 요구 사항의 형태로 표현되면 계약자는 문서 자체를 변경할 수 없습니다. 그러나 고객과 대화를 시도하면 프로젝트 개발 방향을 명확히 하고 불확실성을 줄이고 보다 구체적인 제한 사항을 지정할 수 있습니다. 이 경우 주제 영역을 더 잘 이해하는 것이 거의 항상 가능합니다.
프로젝트가 고객과의 관계 역사상 처음이라면 고객은 그다지 말이 많지 않을 것입니다. 우선, 당신은 아직 연기자가 아닙니다. 둘째, 당신은 매우 바쁜 사람들을 힘든 일로부터 멀어지게 합니다. 대회에서 우승하기 전에 고객에게 연락할 때 이 점을 고려해야 합니다. 고객이 미래의 제품을 어떻게 보는지 이해하는 데 도움이 되는 구체적인 질문을 해보세요. 지금은 요구 사항에 대한 작업을 진행하고 있지 않다는 점을 기억하세요. 귀하의 목표는 단순히 프로젝트의 전망을 평가하고 대회 참가에 대한 결정을 내리는 데 충분한 정보를 얻는 것입니다. 그리고 그 이상은 없습니다.
프로젝트의 목표와 목적에 대한 검토가 고객으로부터 경쟁 참여 요구 사항을 받은 즉시 한 번만 수행된다고 말하는 것은 잘못된 것입니다. 대부분의 경우 검토는 평가를 수행하거나 결정을 내릴 때 문제 공식화 수준이 충분하지 않은 것으로 판명되는 전체 준비 단계에서 수행됩니다. 그런 다음 고객과 함께 목표와 목표를 명확히 하고 프로젝트 개념을 조정하거나 심지어 완전히 수정해야 합니다.
우리의 경우 목표와 목표에 대한 검토는 일반적으로 개념 개발을 맡은 숙련된 시스템 설계자에 의해 수행됩니다. 검토 후 이 사람은 개발된 시스템이 비즈니스 프로세스에 어떤 영향을 미칠지에 대한 고객의 기대와 향후 제품의 운영 환경과 관련된 중요한 제한 사항에 대한 충분한 정보를 가지고 있어야 합니다. 개념을 개발할 때 프로젝트의 시기와 예산에 대한 제한을 고려해서는 안 됩니다. 개념은 시스템이 어떻게 작동해야 하는지에 대한 비전이지 이러한 기능이 어떻게 구현될 것인지에 대한 비전이 아닙니다. 앞으로는 제품의 수요와 타당성을 평가할 때 시간과 예산의 제약을 고려할 것입니다.
컨셉 개발자가 프로그램이 고객의 비즈니스 프로세스에 어떤 영향을 미칠지, 런타임 환경에 의해 기능에 어떤 제한이 가해질 것인지를 이해하고 나면 개발 중인 제품이 어떤 것인지에 대한 비전을 형성해야 합니다.
개념 개발자는 다음 질문에 답해야 합니다.
- 시스템이 지리적으로 분산됩니까? 그렇다면 어떤 구성 요소로 나누어지며, 각 구성 요소는 어디에 배치되거나 배포될 수 있습니까? 분산 구성 요소 간에 어떤 통신 채널을 사용할 수 있나요? 고객이 사용할 수 있는 커뮤니케이션 채널을 갖고 있습니까, 아니면 채널을 만들어야 합니까? 통신 채널은 소유할 것인가, 아니면 임대할 것인가? 통신 채널 임대에 대한 책임은 누구에게 있습니까? 고객입니까 아니면 계약자입니까?
- 각 시스템 구성 요소에는 어떤 소프트웨어가 포함됩니까? 개별 소프트웨어는 시스템 구성 요소의 일부로서 어떻게 서로 상호 작용합니까?
- 시스템에 각 소프트웨어 기능을 배포하는 데 어떤 하드웨어 및 소프트웨어 플랫폼이 사용됩니까? 계약자가 런타임 환경의 구매, 배포 및 유지 관리를 담당합니까?
- 고객이 구성한 작업 중 이 소프트웨어 또는 해당 소프트웨어로 해결되는 작업은 무엇입니까? 할당된 작업을 어떻게 해결합니까? 시스템의 기능 품질 지표는 어떻게 보장됩니까?
- 시스템 소프트웨어는 사용자 및 외부 정보 시스템과 어떻게 상호 작용합니까? 시스템이 외부적으로 어떤 인터페이스와 서비스를 제공합니까? 비기능적 품질 지표는 어떻게 보장됩니까?
- 궁극적으로 주요 질문은 확립된 제한 사항을 고려하여 시스템 전체가 고객이 설정한 작업을 어떻게 해결할 것인가입니다.
이러한 질문에 대한 답변은 소프트웨어 개발과는 거리가 멀지만 해당 분야에 대한 지식이 있는 사람이라도 짧고 이해할 수 있어야 합니다. 각각에 대한 텍스트 설명이 포함된 일련의 시각적 다이어그램 형태로 개념을 제시하는 것이 가장 좋습니다. 독자의 특별한 지식이 필요한 표기법의 사용이 항상 권장되는 것은 아닙니다.
개념은 프로젝트의 주요 문서이며 팀 내부 및 외부의 기술 전문가가 아닌 사람들이 접근할 수 있다는 점을 기억하십시오. 이를 통해 고객, 최고 경영진, 마케팅 전문가, 제품이나 서비스의 잠재 소비자가 개발 중인 시스템을 평가할 수 있어야 합니다.
때로는 고객의 비즈니스 프로세스를 컨셉으로 제시하고, 우리 시스템의 영향을 받을 것으로 예상되는 영역을 보여주기도 했습니다. 다른 경우에는 이전 프로세스 계획과 새 프로세스 계획을 표시하고 새 계획이 이전 프로세스보다 어떻게 더 효과적이었으며 그로 인해 우리의 개발이 더 나은 기능적 성능을 제공했는지 보여주었습니다.
고객이 UML 다이어그램을 두려워하지 않는다면 시퀀스 다이어그램을 보여주십시오. 이 다이어그램은 시스템의 다양한 구성 요소가 서로 어떻게 상호 작용하는지 매우 명확하게 보여줍니다. 활동 다이어그램이 제공될 수 있습니다. 그러나 너무 많이 사용하지 마십시오. 개념의 다이어그램은 프로그램의 원리를 설명하는 데만 필요하며 그 이상은 아닙니다.
개념을 프로젝트의 기초로 받아들이기 전에 먼저 검토해야 합니다. 이러한 검토의 목적은 해당 개념이 실제로 명시된 목표를 충족하고 설정된 작업에 대한 솔루션을 제공하면서도 동시에 이해하기 쉽고 불필요한 내용이 포함되어 있지 않음을 알아내는 것입니다.
컨셉이 전문적인 언어로 작성되지 않았기 때문에 컨셉을 "방어"하기 위해 그 순간 존재하는 전체 프로젝트 팀을 소집하고 심지어 외부에서 누군가를 초대하는 것이 관례입니다. 개념 작성자가 짧은 프레젠테이션을 한 후 참석한 모든 사람이 질문을 할 수 있습니다. 다양한 분야의 전문가와 다양한 경험을 갖춘 프레젠테이션에 참석하면 제안된 개념을 다양한 관점에서 고려할 수 있습니다. 때로는 저자가 더 깊이 생각하게 되기도 하고, 매우 유용한 몇 가지 의견을 받는 경우가 더 자주 발생합니다.
팀 내에서 컨셉이 승인되면 컨셉 작성자가 이를 고객에게 제시합니다. 고객의 의견을 바탕으로 컨셉이 확정되고 있습니다. 계약자와 고객이 공통된 의견을 갖게 되면 그 개념은 문서 버전 관리 시스템에 기록됩니다. 개념은 모든 프로젝트 참가자가 접근할 수 있어야 합니다.
개발 중인 시스템에 대한 수요 분석
시스템에 대한 수요를 분석하면 이 프로젝트가 계약자에게 정말 흥미로운지, 아니면 너무 많은 비용이 지출되기 전에 포기해야 하는지 여부가 표시되어야 합니다.맞춤형 소프트웨어를 개발할 때 수요 분석이 필요한 이유는 무엇일까요? 결국 고객은 프로그램이 필요하지 않았다면 경쟁을 발표하지 않았을 것입니다. 그러나 계약자가 수행하는 수요 분석의 목적은 프로젝트가 계약자의 비즈니스 이익에 얼마나 잘 부합하는지 확인하는 것입니다.
비즈니스 이익은 매우 광범위한 개념입니다. 실제로는 수익성이 별로 좋지 않은 제품을 일부러 판매하려고 했으나 고객과 신뢰 관계를 구축할 수 있는 기회를 얻었고 이후 수익성이 좋은 주문을 받은 경우도 있었습니다. 그리고 반대로 사업상 이익이 아닌 경우 입찰 참여를 거부하는 경우도 있었습니다.
귀하의 비즈니스에 필수적인 요구 사항을 충족하는 투자 소프트웨어 또는 소프트웨어를 개발할 때 수요 분석은 특별한 중요성을 갖습니다. 2008년에 저는 AFK Sistema의 보안 서비스 책임자와 협상하여 "박스형" 제품에 특별한 기능을 추가하도록 강요했던 것을 기억합니다. 그는 나의 단호한 거절을 듣고 매우 놀랐습니다. 하지만 저에게는 이유가 있었습니다. 수천 명의 고객이 있었고 소프트웨어 변경 사항이 고객의 이익에 영향을 미쳤기 때문입니다. 우리 시스템에 특정 기능을 도입하면 한 명의 새로운 고객을 확보할 수 있지만 수백 명의 고객을 잃게 됩니다. 나는 대담자에게 우리의 입장을 설명했습니다. 궁극적으로 우리는 작은 플러그인만 추가하여 거의 원래 형태로 AFK에 보안 시스템을 공급했습니다. 그리고 그들의 작업에 대해 팀은 이 유명한 조직의 경영진으로부터 감사 편지를 받았습니다.
프로젝트 구현이 귀하의 비즈니스 이익을 침해한다고 판단되면 해당 프로젝트를 포기하십시오. 공연자로서 당신에게 각 프로젝트는 사업 발전의 한 단계이거나 비오는 날을 대비한 믿을 수 있는 안전망이 되어야 합니다. 프로젝트가 둘 중 하나가 아니라면 관심을 낭비할 가치가 없습니다.
컨셉을 만들기 전에 수요 분석을 수행하는 것은 불가능하다는 점을 분명히 밝혔으면 좋겠습니다. 귀하의 비즈니스를 어느 수준으로 끌어올릴 수 있는지 이해하려면 개발 중인 시스템이 어떤 것인지 상상해야 합니다.
프로젝트 위험 및 불확실성에 대한 사전 평가
개발 중인 시스템이 수요가 있다고 인식된 후 계약자는 프로젝트의 타당성에 대한 분석을 수행해야 합니다. 그러나 이를 위해서는 위험 평가, 기술 솔루션을 통해 프로젝트 개념을 보완하고, 개발 방법론을 선택하고, 예비 작업 계획을 개발하고 비용을 추정해야 합니다. 그런 후에야 프로젝트가 실현 가능한지 또는 고객과의 타협이 필요한지 여부를 이해할 수 있습니다.초기 단계에서는 시스템과 관련된 많은 질문에 아직 명확한 답변이 없기 때문에 위험 평가가 중요합니다. 가장 중요한 위험과 해결되지 않은 문제의 목록을 작성한 후 계약자는 예를 들어 계약자에게 여러 가지 기술 솔루션을 제공하여 불확실성을 줄이려고 노력할 수 있습니다. 이를 통해 불확실성이 줄어들고 필요한 예산과 기간에 대한 추정이 줄어들어 경쟁에서 승리할 가능성이 높아집니다.
시스템 유연성에 대한 요구 사항에 특별한 주의를 기울여야 합니다. 동적으로 생성된 코드를 실행하고, 시스템을 동적으로 확장하고, 시스템 안정성을 보장하기 위해 일부 구성 요소를 복제하는 등 이러한 문제와 기타 유사한 문제는 비용이 매우 높습니다. 내 작업의 모든 프로젝트에서 나는 그것들을 발견합니다. 그러나 거의 항상 수용 가능한 타협점을 찾을 수 있습니다.
시스템 중 하나를 개발할 때 고객은 각 엔터티에 대한 동적 매개변수 집합을 사용하여 동적 엔터티 집합을 구현할 것을 제안했습니다. 그러나 주제 영역을 분석한 결과 새로운 유형의 엔터티가 거의 나타나지 않는 것으로 나타났으며 고객이 정적 엔터티 세트를 보유하고 필요한 경우 간단히 시스템 코드를 수정하는 것이 더 수익성이 높은 것으로 나타났습니다. 엔터티의 동적 구성을 거부함으로써 시스템 비용을 대폭 절감하고 경쟁에서 승리하며 프로젝트를 구현할 수 있었습니다.
예비 기술 솔루션 준비
그래서 시스템의 개념이 있고 위험과 해결되지 않은 문제의 목록이 있습니다. 이러한 초기 데이터를 기반으로 계약자는 예비 기술 솔루션의 형태로 고객에 대한 대응을 준비할 수 있습니다. 이 문서의 목적은 개념에 설명된 시스템이 기술적으로 어떻게 구현될 수 있는지 보여주는 것입니다.기술 솔루션은 개념과 달리 기술 언어로 설명되며 기술 전문가를 대상으로 합니다. 고객의 전문가는 솔루션을 분석하고 해당 계약자가 프로젝트 구현에 참여해야 하는지에 대한 권장 사항을 제시합니다. 경쟁에서 승리하면 선택한 기술 솔루션은 계약업체가 시스템을 구현하는 데 도움이 됩니다.
실제로 기술 솔루션을 개발할 때 계약자는 세부 사항을 설명하지 않고도 채택된 제품 개념이 원칙적으로 실현 가능함을 보여야 합니다(아직 시간 및 예산 제한을 고려하지 않음). 시스템의 특정 기능을 구현하는 것이 어떤 기술 기반에서 가능한지(요구 사항이 아닌 기회가 강조됨) 표시할 필요가 있습니다. 또한 시스템 품질의 비기능적 지표를 어떻게 보장할 수 있는지 명시할 필요가 있습니다.
솔루션을 준비할 때 고객이 공식화한 문제 해결과 직접적인 관련이 없는 기능을 솔루션에 도입하려는 유혹을 피해야 합니다. 이로 인해 프로젝트가 크게 부풀려지고 고객에게 많은 질문이 제기됩니다. 물론, 어느 누구도 자신의 비용으로 다소 유용한 추가 기능을 만들기로 결정한 계약자를 방해하지 않을 것입니다. 그러나 연주자는 그러한 조치를 취하는 데에는 타당한 이유가 있어야 합니다. 다른 모든 경우에는 고객이 수용할 수 있는 제품 품질을 유지하면서 시간과 예산 비용을 최소화하는 경로를 따라야 합니다.
예비 기술 솔루션에는 개발 중인 시스템의 개발 또는 운영을 보장하기 위해 구매해야 하는 하드웨어 및 소프트웨어가 명시되어 있어야 합니다. 예를 들어 전자 디지털 서명을 생성하고 확인하는 데 사용되는 GOST R 34.10/34.11-2001 암호화 알고리즘을 사용하려면 이러한 알고리즘을 지원하는 암호화 공급자의 라이센스가 필요할 수 있습니다. 관리 코드를 사용하려는 경우 암호화 공급자 외에 추가 소프트웨어가 필요할 수 있습니다. 또 다른 예는 사용자 인터페이스를 위한 시각적 구성 요소 라이브러리입니다. 어떤 경우에는 시스템을 배포하기 위해 하드웨어를 구입해야 합니다. 이러한 구매 비용은 상당히 클 수 있으므로 개발 중인 소프트웨어의 타당성을 분석할 때 평가해야 합니다.
불확실성을 줄이고 예산 및 마감일 추정의 정확성을 높이기 위해 계약자는 하나가 아닌 여러 가지 기술 솔루션을 개발할 수 있습니다. 시스템을 위한 단일 솔루션은 가능한 모든 위험과 가장 비용이 많이 드는 접근 방식의 사용을 고려해야 합니다. 그러나 문제를 해결하는 데 여러 가지 접근 방식이 있는 경우 각 옵션에 대한 솔루션을 찾을 수 있으며 일반적으로 가장 비싼 기술은 서로 호환되지 않거나 전혀 필요하지 않은 것으로 나타났습니다. 결과적으로 고객에게 제공되는 솔루션 비용이 크게 낮아져 솔루션 자체가 고객에게 더욱 매력적이게 됩니다.
제품 개발 방법론 선택
일련의 기술 솔루션을 받은 후에는 각각에 대한 개발 방법론을 선택해야 합니다.방법론의 선택은 프로젝트의 특성을 고려해야 합니다. 정부 기관이나 대규모 상업 고객과 협력할 때 유연한 방법론의 사용을 방해하는 기능이 종종 있습니다. 어떤 경우에는 계약자가 "정부 고객을 위한 프로젝트 개발 시 애자일 사용" 기사에서 설명한 것처럼 고객의 절차적 제한에서 내부 개발 프로세스를 추상화하여 제한을 우회할 수 있습니다. 다른 경우에는 모든 방법론에 한계가 있다는 점을 염두에 두고 민첩한 방법론에서 벗어나고 싶을 수도 있습니다.
예비 작업 계획 준비
예비 작업 계획의 목적은 인건비, 프로젝트 팀 구성, 개발 및 테스트 환경에 필요한 소프트웨어 및 하드웨어, 전문가 및 자원 유치 시기를 추정할 수 있는 기회를 제공하는 것입니다.계획은 프로젝트 개념, 기술 솔루션 및 선택한 방법론을 기반으로 합니다. 여러 가지 기술 솔루션이 준비되어 있는 경우 각 솔루션에 대한 계획을 별도로 준비해야 합니다.
계획은 프로젝트에 채택된 방법론의 틀 내에서 개발 프로세스의 각 단계에서 팀의 활동을 잘 이해하고 있는 전문가 또는 전문가 그룹이 준비해야 합니다.
계획을 세울 때 분석, 아키텍처, 설계, 프로그래밍, 테스트, 인프라 관리, 고객과의 상호 작용, 최종 사용자, 하청업체 및 기타 영역의 일반적인 작업을 완료하는 데 대략 얼마나 많은 시간이 걸릴지 알고 내 자신의 경험에 의존합니다. 프로젝트 활동의 그러나 평가하기 훨씬 더 어려운 프로젝트별 활동도 있습니다. 나는 보통 그러한 작업을 여러 활동으로 나눕니다. 예를 들어, 대용량 데이터 처리를 위한 알고리즘을 구현하는 작업의 경우 솔루션 검색 및 테스트, 로드 테스트를 위한 프로토타입 생성, 디버깅된 솔루션을 프로젝트에 통합하는 하위 작업을 선택할 수 있습니다. 복잡한 문제를 하위 작업으로 나누면 불확실성이 줄어들고 계획 및 추정이 향상됩니다.
작업 목록을 정의하는 것뿐만 아니라 대략적인 기간, 종속성, 실행자, 필요한 인프라를 나타내는 것도 합리적입니다.
작업 기간은 "이상적인" 시간이 아니라 실제로 문제를 해결하는 데 소요된 시간을 고려해야 합니다. 실제 추정치를 구할 때 초점 인자를 사용하면 좋은 결과를 얻을 수 있습니다. 이 경우 초점 요소는 일련의 문제 해결에 할당된 "이상적인" 시간을 실제로 해결하는 데 소요된 시간으로 나눈 것으로 정의되는 애자일 관행에서 빌려왔습니다. 따라서 이상적으로 프로그래머가 특정 작업을 구현하는 데 4시간을 소비한다면 초점 계수 0.55를 사용하면 작업에 대한 실제 작업 시간은 거의 7.5시간이 됩니다. 그 차이는 상당하므로 고려해야 합니다.
나는 매우 높은 품질의 개발 프로세스를 갖추고 자신에게 알려진 주제 영역 내에서 오랫동안 작업해 온 경험이 풍부한 전문가로 구성된 이상적인 팀에서 0.7의 초점 요소가 달성된다는 점에 주목합니다. 평균 팀에서 페어 프로그래밍을 사용하면 0.6이라는 값을 얻을 수 있지만 이 개발 모드는 개발자를 크게 지치게 하므로 지속적으로 기준을 높게 유지하는 것은 불가능합니다. 따라서 0.55라는 값은 일반적으로 사전 계획 요구 사항과 더 일치합니다.
간트 차트를 사용하면 작업의 기간과 종속성을 표현하는 것이 편리합니다. 이를 통해 어떤 작업을 병렬로 수행할 수 있거나 수행해야 하는지(따라서 다른 수행자가 필요함)와 어떤 작업을 순차적으로 수행해야 하는지에 대한 아이디어를 얻을 수 있습니다. 중요한 작업 체인을 식별하고 이를 최적화하는 것이 가능할 것입니다. 이 보기에서는 인력을 모집하거나 프로젝트 인프라 구성 요소를 배포/업데이트/릴리스하는 기한도 제공합니다.
계획의 또 다른 중요한 긍정적 효과는 전체 작업 범위를 여러 개의 작은 납품 단계로 나누어 프로젝트를 더욱 유연하고 예측 가능하게 만드는 능력입니다. 배송의 각 단계에서 특정 기능 세트를 갖춘 완제품을 출시함으로써 고객으로부터 적시에 피드백을 받을 수 있으며, 이는 복잡한 주제 영역에서 작업할 때 매우 중요합니다. 나는 일반적으로 4-6주의 배송 단계를 수행합니다.
인건비, 필요한 인력 및 자원에 대한 사전 평가
제안된 각 기술 솔루션에 대한 예비 작업 계획을 기반으로 계약자는 총 인건비, 인력 구성, 개발 프로세스에 필요한 하드웨어 및 소프트웨어를 추정해야 합니다. 평가의 목적은 프로젝트의 타당성을 평가할 수 있도록 각 솔루션에 대한 현실적인 시간 및 예산 견적을 얻는 것입니다.일반적으로 저는 각 수행자와 각 리소스에 대해 점유율을 나타내는 단계별 추정치를 제공한 다음 최종 전체 추정치를 제공합니다. 예를 들어, 소규모 프로젝트의 구현 단계에는 설계자(시간의 50%), 분석가(25%), 인프라 관리자(10%) 및 3명의 정규 개발자의 참여가 필요할 수 있습니다. 단계는 6주(영업일 기준 30일) 동안 진행되므로 설계자는 15일, 분석가는 7일, 관리자는 3일, 각 개발자는 모두 30일 동안 바쁠 것입니다. 이러한 인건비를 기준으로 인건비를 계산할 수 있습니다. 동일한 30일 동안 팀에는 작업 추적 시스템, 버전 제어 시스템, 테스트용 가상 머신 두 대, 배포된 DBMS가 있는 가상 머신 및 프로젝트와 관련된 기타 항목이 필요합니다. 또한, 디지털 서명을 사용하려면 암호화 공급자를 사용할 수 있는 라이센스, 각 스탠드 및 각 개발자에 대한 인증서 및 개인 키 컨테이너가 필요합니다.
각 단계에 대한 평가를 통해 특정 전문가를 유치하거나 방출해야 하는 시점, 프로젝트에 필요한 가상 머신을 언제, 얼마 동안 주문해야 하는지, 장비를 구매/임대해야 하는 시기와 기간을 쉽게 이해할 수 있습니다. 필수 타사 소프트웨어에 대한 라이선스를 취득해야 하는 기간 등
이를 통해 우리는 문제의 솔루션을 구현하기 위한 기간과 예산을 전반적으로 평가할 수 있습니다. 그러나 프로젝트에는 준비 단계에서 해결할 수 없는 불확실성이 많기 때문에 프로젝트의 실제 비용과 기간은 물론 전문가와 자원을 유치하는 실제 기간도 다를 수 있음을 이해하는 것이 중요합니다. 얻은 추정값과 크게 다릅니다. 편차는 추정치를 초과하는 방향으로 최대 100%, 감소하는 방향으로 최대 50%까지 가능합니다.
기술 솔루션의 타당성 분석
타당성 분석은 제안된 솔루션 중 실제로 실현 가능한 솔루션과 계약자에게 가장 최적이고 유익한 솔루션을 보여주어야 합니다. 따라서 분석 결과에 따라 계약자는 공식적으로 고객에게 어떤 솔루션을 제공할지 결정해야 합니다.일반적으로 제안된 솔루션이 실현 가능한지 여부에 대한 질문에 답하려면 다음 질문에 답해야 합니다.
- 솔루션이 수용된 개념과 일치합니까?
- 선택한 방법론이 솔루션에 적용 가능합니까?
- 이 결정을 위해 계약자가 작성한 시간과 예산의 추정이 정확합니까?
- 견적과 관련하여 마감일 및 예산의 실제 값의 편차는 무엇입니까?
이해하기 어렵지 않기 때문에 제안된 솔루션에 대한 내부 전문가의 검토와 이에 대한 평가에 대해 이야기하고 있습니다. 분석가, 건축가, 관리자, 프로그래머 등 계약자의 다양한 부서에서 경험이 풍부한 전문가가 검토에 참여하는 경우가 많습니다. 그들은 함께 광범위한 문제를 해결해야 합니다. 행정 부서에서 필요한 인프라를 제공할 수 있나요? 이를 위해 추가 하드웨어나 소프트웨어를 구입해야 합니까? 필요한 직원이 있고 필요한 시간 내에 다른 프로젝트에 참여할 수 있습니까? 계약자의 전문가가 필요한 지식과 기술을 갖추고 있습니까? 새로운 전문가가 직원으로 고용됩니까? 아웃소싱업체도 참여하나요?
때때로, 제안된 모든 솔루션을 고려한 후 구현자는 그 중 어느 것도 실현 가능하지 않다는 결론에 도달합니다. 대부분의 경우 타당성을 평가하고 다시 분석해야 하는 새로운 솔루션이 나타날 수 있습니다. 때로는 고객과 타협점을 찾아 컨셉을 수정해야 할 때도 있습니다. 마지막으로, 절충안을 찾을 수 없으면 프로젝트를 포기하는 것이 최악은 아니지만 가능성이 매우 높은 해결책일 수도 있습니다.
예비 결정에 대한 독립적 검토
수용 가능한 기술 솔루션이 발견되면 고객에게 제공됩니다. 경쟁에 참가하기 위한 결정은 경쟁 신청으로 공식화됩니다. 다른 경우에는 솔루션이 다른 형태로 고객에게 제공됩니다. 솔루션 제공을 공식화하는 것이 중요합니다(비즈니스에 중요하지 않은 내부 고객을 위한 프로젝트는 제외). 이는 고객과 제안하고 합의한 솔루션이 고객과 계약자 모두가 추가 결정을 내리는 기초가 되기 때문에 중요합니다. 솔루션에 동의한 후 고객은 필요한 하드웨어 및 런타임 소프트웨어, 교육 직원 및 제품 배포에 필요한 기타 조치를 구매하기 시작합니다. 계약자는 공식적으로 자금을 지원받고 제품 개발을 시작할 수 있게 됩니다.계약자로부터 결정을 받은 후 고객은 이를 검토해야 합니다. 본질적으로 그는 동일한 기본 질문에 대한 답을 얻어야 합니다.
- 솔루션이 고객이 설정한 목표와 목적을 충족합니까?
- 솔루션이 고객과 계약자 간에 합의된 개념과 일치합니까?
- 솔루션이 기술적으로 실현 가능한가?
- 솔루션이 고객이 지정한 시간 및 예산 제약에 부합합니까?
그러나 고객이 이러한 질문에 대답하는 것은 더 어렵습니다. 고객이 상당히 유능한 전문가를 고용하는 자체 IT 부서를 가지고 있다면 좋습니다. 종종 고객은 계약자가 제안한 솔루션의 타당성을 분석하는 독립 감사인을 참여시켜야 합니다. 전문가의 의견을 바탕으로 고객은 계약자의 결정을 수락하거나 거부합니다.
준비 단계 완료 - 계약 체결
솔루션이 고객에게 적합한 경우 고객과 계약자는 소프트웨어 제품의 개발(또는 수정)에 대한 계약을 체결합니다. 계약자는 작업에 대한 자금 출처를 받고 공식적으로 프로젝트를 시작할 수 있습니다. 일반적으로 고객은 계약업체에 더 쉽게 접근할 수 있게 되며 개발 프로세스는 요구사항 개발 단계로 이동합니다.계약자는 고객과 합의한 기술 솔루션을 버전 관리하에 기록하고 배치해야 하며, 이 솔루션은 개념과 함께 공개적으로 접근 가능한 문서여야 하며 필수적인 이유에 대해서만 변경할 수 있어야 합니다.
내 경험에 따르면 개념과 예비 기술 솔루션을 결합해서는 안 됩니다. 이 개념은 기술 전문가를 위한 것이 아니며 기술 솔루션은 특히 전문가를 대상으로 합니다. 또한 위에서 언급한 것처럼 이 개념에는 여러 가지 기술적 솔루션이 있을 수 있습니다. 그리고 개발 프로세스의 후속 단계에서는 현재 개념의 틀 내에서 기술 솔루션을 다시 고려해야 하는 경우도 있습니다. 당신 아래에서 지원 포인트를 제거할 필요가 없습니다.
예비 작업 계획, 위험 평가 및 해결되지 않은 문제 목록이 버전 관리에 포함되어야 합니다. 후속 단계에서 이러한 문서는 보완되고 명확해질 것입니다.
결론
소프트웨어 개발 프로세스의 준비 단계는 중요합니다. 이 단계에서는 소프트웨어 제품의 아이디어가 요구되고 구현 가능한 시스템 개념의 형태로 첫 번째 구현을 받는 단계입니다.첫 번째 단계부터 적절한 책임을 가지고 작업을 처리하는 것이 매우 중요합니다. 목표나 목적을 공식화하는 데 오류가 있으면 의도적으로 부정확하고 프로젝트가 매우 불안정하게 개발될 수 있습니다. 컨셉 및 기술 솔루션의 형성 오류로 인해 고객의 주제 영역에 시스템이 적용되지 않을 수 있습니다. 타당성 평가에 오류가 있으면 프로젝트 마감일과 예산을 위반하게 됩니다.
그러나 고객과 계약자 모두 적절한 주의를 기울여 프로젝트에 접근하고 고품질 기반을 마련했다면 이미 요구 사항 개발 단계에서 프로젝트가 빠르게 추진력을 얻기 시작합니다. 명확한 개념을 통해 고객, 하청업체 및 프로젝트 팀 구성원과의 상호 작용 비용을 줄일 수 있습니다. 준비 단계에서 계약자가 수행한 개발은 후속 단계의 작업을 크게 촉진하며, 또한 향후 제품의 다음 버전 작업이나 다른 프로젝트 작업 시 사용할 수 있습니다.
프로젝트의 초석을 놓을 때 주의하고 책임감을 가지십시오. 당신은 그를 자랑스러워하게 될 것입니다!
참고자료
- 막심 쿠즈네초프. 소프트웨어 개발 프로세스 개요 – habrahabr.ru, 2015(