소프트웨어 수명 주기에 포함된 항목입니다. 소프트웨어 수명 주기

정의하는 것으로 시작해야 합니다.소프트웨어 수명 주기(Software Life Cycle Model)은 소프트웨어 제품을 생성하기로 결정한 순간부터 시작하여 서비스에서 완전히 철회되는 순간 종료되는 기간입니다. 이 주기는 소프트웨어를 구축하고 개발하는 프로세스입니다.

소프트웨어 수명 주기 모델

라이프 사이클은 모델의 형태로 표현될 수 있습니다. 현재 가장 일반적인 것은 다음과 같습니다.계단식, 증분 (중간 제어가 있는 단계적 모델 ) 그리고 나선라이프 사이클 모델.

캐스케이드 모델

캐스케이드 모델(eng. 폭포 모델)은 소프트웨어 개발 프로세스의 모델이며, 그 라이프 사이클은 요구 사항 분석, 설계 단계를 순차적으로 통과하는 흐름처럼 보입니다. 구현, 테스트, 통합 및 지원.

개발 프로세스는 독립적인 단계의 순서화된 순서를 사용하여 구현됩니다. 이 모델은 이전 단계가 완료된 후 각 후속 단계가 시작된다는 것을 제공합니다. 모델의 모든 단계에서 프로젝트 관리, 평가 및 품질 관리, 검증 및 인증, 구성 관리, 문서 개발을 포함한 보조 및 조직 프로세스와 작업이 수행됩니다. 단계가 완료되면 후속 단계에서 변경할 수 없는 중간 제품이 형성됩니다.

라이프 사이클은 전통적으로 다음과 같은 주요 요소로 나뉩니다.단계:

요구사항 분석,
설계,
코딩(프로그래밍),
테스트 및 디버깅,
운영 및 유지 보수.

모델의 장점:

개발 라이프 사이클 전반에 걸친 요구 사항의 안정성;
각 단계에서 완전성과 일관성에 대한 기준을 충족하는 완전한 프로젝트 문서 세트가 형성됩니다.
모델 단계의 확실성과 이해도 및 적용의 단순성;
논리적 순서로 수행되는 작업 단계를 통해 모든 작업 및 해당 리소스(금전적, 물질적, 인적) 완료 시점을 계획할 수 있습니다.

모델의 단점:

요구 사항을 명확하게 공식화하는 복잡성과 전체 수명주기 동안 동적 변경이 불가능합니다.
프로젝트 관리의 낮은 유연성;
결과적으로 개발 프로세스의 선형 구조의 순서로 인해 새로운 문제를 해결하기 위해 이전 단계로 돌아가면 비용이 증가하고 작업 일정이 중단됩니다.
중간 제품의 사용 부적합;
고유한 시스템의 유연한 모델링 불가능;
개발 종료 시 모든 결과의 동시 통합으로 인한 빌드 관련 문제의 늦은 감지;
시스템 생성에 대한 사용자 참여 부족 - 처음(요구 사항 개발 중)과 끝(승인 테스트 중)
사용자는 전체 개발 프로세스가 끝날 때까지 개발된 제품의 품질을 확신할 수 없습니다. 그들은 개발의 완제품을 볼 수 없기 때문에 품질을 평가할 기회가 없습니다.
사용자는 점차적으로 시스템에 익숙해질 기회가 없습니다. 학습 프로세스는 소프트웨어가 이미 작동된 라이프 사이클의 마지막에 발생합니다.
각 단계는 후속 작업을 실행하기 위한 전제 조건이며, 이러한 방법은 유사체가 없는 시스템에 대해 위험한 선택이 되기 때문입니다. 유연한 모델링에 적합하지 않습니다.

Waterfall Life Cycle Model은 이전 단계로 돌아가서 새로 발생하는 문제를 제거하기 위해 결과를 변경하지 않고 PS를 개발하는 복잡성으로 인해 구현하기 어렵습니다.

캐스케이드 모델의 범위

캐스케이드 모델의 범위 제한은 단점에 따라 결정됩니다. 다음과 같은 경우에 가장 효과적입니다.

명확하고 변경 불가능한 프로젝트를 개발할 때라이프 사이클 구현 및 기술 방법론으로 이해할 수 있는 요구 사항
개발자가 이전에 개발한 것과 동일한 유형의 시스템 또는 제품을 구축하는 데 중점을 둔 프로젝트를 개발할 때
기존 제품 또는 시스템의 새 버전 생성 및 출시와 관련된 프로젝트를 개발할 때
기존 제품 또는 시스템을 새로운 플랫폼으로 이전하는 것과 관련된 프로젝트를 개발할 때
여러 대규모 개발 팀이 관련된 대규모 프로젝트를 수행할 때.

증분 모델

(중간 제어가 있는 단계적 모델)

증분 모델(eng. 증가- 증가, 증분) 단계의 선형 시퀀스로 소프트웨어 개발을 의미하지만 여러 증분(버전), 즉 소프트웨어 개발 수명 주기가 끝나는 한 계획된 제품 개선과 함께.

소프트웨어 개발은 단계 간에 피드백 루프를 사용하여 반복적으로 수행됩니다. 단계 간 조정을 통해 다양한 단계에서 개발 결과의 실제 상호 영향을 고려할 수 있으며 각 단계의 수명은 전체 개발 기간에 걸쳐 연장됩니다.

프로젝트 작업이 시작될 때 시스템의 모든 기본 요구 사항이 결정되어 점점 더 중요하지 않은 요구 사항으로 나뉩니다. 그 후, 시스템 개발은 점진적으로 수행되어 개발자는 소프트웨어 개발 중에 얻은 데이터를 사용할 수 있습니다. 각 증분은 시스템에 특정 기능을 추가해야 합니다. 이 경우 릴리스는 우선 순위가 가장 높은 구성 요소부터 시작됩니다. 시스템의 부분이 정의되면 첫 번째 부분을 선택하고 이에 가장 적합한 프로세스를 사용하여 세부 사항을 시작합니다. 동시에 이 작업의 현재 요구 사항 집합에서 동결된 다른 부품에 대한 요구 사항을 개선할 수 있습니다. 필요한 경우 나중에 이 부분으로 돌아갈 수 있습니다. 부품이 준비되면 작업에 사용할 수 있는 클라이언트에게 전달됩니다. 이를 통해 고객은 다음 구성 요소에 대한 요구 사항을 명확히 할 수 있습니다. 그런 다음 시스템의 다음 부분을 개발합니다. 이 프로세스의 핵심 단계는 소프트웨어 요구 사항의 하위 집합을 단순하게 구현하고 소프트웨어가 완전히 구현될 때까지 일련의 연속 릴리스를 통해 모델을 개선하는 것입니다.

이 모델의 수명 주기는 최종 결과가 어떠해야 하는지에 대한 명확한 비전(고객과 개발자 모두)이 있는 복잡하고 복잡한 시스템의 개발에 일반적입니다. 버전 개발은 다양한 이유로 수행됩니다.

비용이 많이 드는 전체 프로젝트에 즉시 자금을 조달할 수 있는 고객의 능력 부족;
개발자가 짧은 시간에 복잡한 프로젝트를 구현하는 데 필요한 리소스가 부족합니다.
최종 사용자가 제품을 단계적으로 구현하고 개발하기 위한 요구 사항. 전체 시스템을 한 번에 도입하면 사용자 사이에서 거부감을 유발할 수 있으며 새로운 기술로의 전환 과정을 "느리게"할 수 있습니다. 비유적으로 말해서 그들은 단순히 “큰 조각을 소화하지 못하므로 부숴서 나누어 주어야 합니다.”

장점그리고 한계이 모델(전략)의 단계는 캐스케이드(고전적 라이프 사이클 모델)의 것과 동일합니다. 그러나 기존 전략과 달리 고객은 결과를 더 일찍 볼 수 있습니다. 첫 번째 버전의 개발 및 구현 결과에 따라 개발 요구 사항을 약간 변경하거나 포기하거나 새로운 계약을 체결하여 더 고급 제품의 개발을 제안할 수 있습니다.

장점:

변화하는 사용자 요구 사항으로 인해 발생하는 비용이 감소하고 폭포식 모델에 비해 재분석 및 문서 수집이 크게 감소합니다.
완료된 작업에 대해 클라이언트로부터 피드백을 받는 것이 더 쉽습니다. 클라이언트는 완성된 부품에 대해 의견을 말할 수 있고 이미 완료된 작업을 볼 수 있습니다. 왜냐하면 시스템의 첫 번째 부분은 전체 시스템의 프로토타입입니다.
고객은 소프트웨어를 신속하게 획득하고 마스터할 수 있습니다. 고객은 폭포수 모델에서 가능한 것보다 더 빨리 시스템에서 실질적인 이점을 얻을 수 있습니다.

모델의 단점:

관리자는 프로세스의 진행 상황을 지속적으로 측정해야 합니다. 빠른 개발의 경우 모든 최소 버전 변경에 대해 문서를 만들 가치가 없습니다.
시스템 구조는 새로운 구성 요소가 추가될 때 악화되는 경향이 있습니다. 지속적인 변경은 시스템 구조를 방해합니다. 이를 피하기 위해서는 리팩토링에 추가적인 시간과 비용이 필요하다. 구조가 좋지 않으면 소프트웨어를 나중에 수정하기가 어렵고 비용이 많이 듭니다. 그리고 중단된 소프트웨어 수명 주기는 더 큰 손실로 이어집니다.

이 계획은 소프트웨어 요구 사항의 새로운 변경 및 설명을 즉시 고려하는 것을 허용하지 않습니다. 사용자와의 개발 결과 조정은 각 작업 단계가 완료된 후 계획된 시점에서만 수행되며 소프트웨어에 대한 일반적인 요구 사항은 생성되는 전체 시간 동안 기술 작업의 형태로 고정됩니다. 따라서 사용자는 실제 요구 사항에 맞지 않는 소프트웨어를 받는 경우가 많습니다.

나선형 모델

나선형 모델:라이프 사이클 - 나선형의 각 회전에서 제품의 다음 버전이 생성되고 프로젝트의 요구 사항이 지정되고 품질이 결정되며 다음 회전의 작업이 계획됩니다. 특정 기술 솔루션의 실행 가능성이 프로토타입 생성을 통해 테스트되고 정당화되는 개발 초기 단계인 분석 및 설계에 특별한 주의를 기울입니다.

이 모델은 설계와 단계별 프로토타이핑을 결합하여 상향식 및 하향식 개념의 이점을 결합하는 소프트웨어 개발 프로세스로, 수명 주기의 초기 단계인 분석 및 설계를 강조합니다.구별되는 특징 이 모델은 라이프 사이클의 조직에 영향을 미치는 위험에 특별한 주의를 기울입니다.

분석 및 설계 단계에서는 시제품을 제작하여 기술 솔루션의 실현 가능성과 고객 요구 사항의 만족 정도를 확인합니다. 나선의 각 회전은 실행 가능한 조각 또는 시스템 버전의 생성에 해당합니다. 이를 통해 프로젝트의 요구 사항, 목표 및 특성을 명확히하고 개발 품질을 결정하며 나선형의 다음 회전 작업을 계획할 수 있습니다. 따라서 프로젝트의 세부 사항이 심화되고 지속적으로 구체화되며 결과적으로 고객의 실제 요구 사항에 맞는 합리적인 옵션이 선택되어 구현됩니다.

나선형의 각 회전에 대한 수명 주기 - 소프트웨어 개발 프로세스의 다른 모델을 적용할 수 있습니다. 최종 결과는 완제품입니다. 이 모델은 프로토타이핑 모델의 기능과폭포 모델. 반복에 의한 개발은 객관적으로 존재하는 시스템 생성의 나선형 주기를 반영합니다. 각 단계에서 작업이 불완전하게 완료되면 현재 작업이 완료될 때까지 기다리지 않고 다음 단계로 넘어갈 수 있습니다. 주요 임무는 시스템 사용자에게 가능한 한 빨리 실행 가능한 제품을 표시하여 요구 사항을 명확히하고 보완하는 프로세스를 활성화하는 것입니다.

모델의 장점:

시스템 사용자에게 실행 가능한 제품을 신속하게 표시하여 요구 사항을 명확히하고 보완하는 프로세스를 활성화 할 수 있습니다.
표준 개발을 포함하여 대부분의 개발에서 일반적으로 나타나는 소프트웨어 개발 중 요구 사항을 변경할 수 있습니다.
이 모델은 캐스케이드 모델의 장점을 구현하고 동시에 동일한 모델의 모든 단계에 대한 반복이 허용되기 때문에 유연한 설계 가능성을 제공합니다.
보다 안정적이고 안정적인 시스템을 얻을 수 있습니다. 소프트웨어가 발전함에 따라 각 반복에서 버그와 약점이 발견되고 수정됩니다.
이 모델을 통해 사용자는 계획, 위험 분석, 개발 및 평가 활동 수행에 적극적으로 참여할 수 있습니다.
고객 위험을 줄입니다. 고객은 최소한의 재정적 손실로 유망하지 않은 프로젝트의 개발을 완료할 수 있습니다.
사용자로부터 개발자에 대한 피드백은 높은 빈도로 모델 초기에 수행되어 원하는 제품의 품질을 보장합니다.

모델의 단점:

프로젝트가 위험이 낮거나 작으면 모델이 비쌀 수 있습니다. 각 나선 이후의 위험 평가는 비용이 많이 듭니다.
모델의 수명 주기는 구조가 복잡하므로 개발자, 관리자 및 고객이 적용하기 어려울 수 있습니다.
생성된 버전에 대한 각 고객의 응답이 프로젝트 완료를 지연시키는 새로운 주기를 생성할 수 있기 때문에 나선형은 무기한 계속될 수 있습니다.
많은 수의 중간 주기로 인해 추가 문서를 처리해야 할 수 있습니다.
모델을 사용하면 비용이 많이 들고 심지어 감당할 수 없을 수도 있습니다. 시각. 계획, 재타겟팅, 위험 분석 수행 및 프로토타입 제작에 대한 지출이 과도할 수 있습니다.
다음에 개발 프로세스를 계속할 준비가 되었음을 나타내는 목표와 이정표를 정의하는 것이 어려울 수 있습니다.

나선형 주기의 주요 문제는 다음 단계로의 전환 순간을 결정하는 것입니다. 이를 해결하기 위해 각 단계에 시간 제한이 도입됩니다.라이프 사이클 계획된 모든 작업이 완료되지 않더라도 전환이 계획에 따라 진행됩니다.계획이전 프로젝트에서 얻은 통계 데이터와 개발자의 개인적인 경험을 기반으로 합니다.

나선형 모델의 범위

다음과 같은 경우 나선형 모델을 사용하는 것이 좋습니다.

새로운 기술을 사용하여 프로젝트를 개발할 때;
새로운 시리즈의 제품이나 시스템을 개발할 때
요구 사항에 상당한 변경 또는 추가가 예상되는 프로젝트를 개발할 때
장기 프로젝트의 구현을 위해;
단기간에 시스템이나 제품의 품질과 버전을 입증해야 하는 프로젝트를 개발할 때
프로젝트를 개발할 때. 위험 평가 및 해결과 관련된 비용을 계산할 필요가 있습니다.

전기 공학). 이 표준은 PS를 만드는 동안 수행해야 하는 프로세스, 활동 및 작업을 포함하는 수명 주기의 구조를 정의합니다.

이 PS 표준(또는 소프트웨어)는 일련의 컴퓨터 프로그램, 절차 및 관련 문서 및 데이터로 정의됩니다. 프로세스는 일부 입력 데이터를 출력 데이터로 변환하는 상호 관련된 일련의 작업으로 정의됩니다(G. Myers는 이를 데이터 변환이라고 함). 각 프로세스는 솔루션에 대한 특정 작업과 방법이 특징입니다. 차례로 각 프로세스는 일련의 작업으로 나뉘고 각 작업은 작업 세트로 나뉩니다. 각 프로세스, 작업 또는 작업은 필요에 따라 다른 프로세스에 의해 시작되고 실행되며 미리 결정된 실행 순서가 없습니다(물론 입력 데이터 연결을 유지하면서).

소비에트 연방과 러시아에서 소프트웨어 (소프트웨어) 생성은 처음에 지난 세기의 70 년대에 GOST ESPD 표준 (Unified System for Program Documentation - GOST 19.XXX)에 의해 규제되었습니다. 시리즈)는 개별 프로그래머가 만든 비교적 간단한 소규모 프로그램 클래스에 초점을 맞췄습니다. 현재 이러한 표준은 개념적으로 구식이며 형식적으로 유효 기간이 만료되어 사용이 부적절합니다.

소프트웨어도 포함하는 AS(자동화 시스템) 생성 프로세스는 GOST 34.601-90 "정보 기술. 자동화 시스템에 대한 표준 세트입니다. 생성 단계", GOST 34.602-89 "정보 기술. A 자동화 시스템에 대한 일련의 표준. 기술과제자동화 시스템 생성" 및 GOST 34.603-92 "정보 기술. 자동화 시스템의 테스트 유형". 그러나 이러한 표준의 많은 조항은 구식이며 다른 항목은 PS 생성을 위한 심각한 프로젝트에 사용할 만큼 충분히 반영되지 않습니다. 따라서 국내 개발에서 현대 국제 표준을 사용하는 것이 좋습니다.

ISO / IEC 12207 표준에 따라 모든 소프트웨어 수명 주기 프로세스는 세 그룹으로 나뉩니다(그림 5.1).

쌀. 5.1.

획득, 공급, 개발, 운영 및 유지 보수의 다섯 가지 주요 프로세스가 그룹으로 정의됩니다. 8개의 하위 프로세스는 주요 프로세스의 실행을 보장합니다. 선적 서류 비치, 구성 관리, 품질 보증, 검증, 검증, 공동 평가, 감사, 문제 해결. 네 가지 조직 프로세스는 거버넌스, 인프라 구축, 개선 및 학습을 제공합니다.

5.2. PS 라이프 사이클의 주요 프로세스

획득 프로세스는 소프트웨어를 구매하는 고객의 활동과 작업으로 구성됩니다. 이 프로세스에서는 다음 단계를 다룹니다.

인수 개시;
신청 제안 준비;
계약의 준비 및 조정;
공급자 활동의 감독;
수락 및 작업 완료.

획득 시작에는 다음 작업이 포함됩니다.

시스템, 소프트웨어 제품 또는 서비스의 획득, 개발 또는 개선에 대한 고객의 요구 사항 결정
기존 소프트웨어의 획득, 개발 또는 개선에 관한 결정
소프트웨어 제품 구매 시 필요한 문서, 보증, 인증서, 라이선스 및 지원의 가용성 확인
시스템 요구 사항, 계약 유형, 당사자의 책임 등을 포함한 인수 계획의 준비 및 승인

입찰에는 다음이 포함되어야 합니다.

시스템 요구 사항;
소프트웨어 제품 목록;
취득 및 계약 조건;
기술적 제한 사항(예: 시스템의 운영 환경).

입찰은 입찰 시 선택된 공급업체 또는 여러 공급업체에게 전송됩니다. 공급자는 계약에 지정된 조건에 따라 시스템, 소프트웨어 또는 소프트웨어 서비스의 공급을 위해 고객과 계약을 체결하는 조직입니다.

계약 준비 및 조정에는 다음 작업이 포함됩니다.

가능한 공급자의 제안을 평가하기 위한 기준을 포함하여 공급자를 선택하는 절차에 대한 고객의 결정;
제안 분석을 기반으로 특정 공급자 선택;
준비와 결론 공급자 계약;
구현 과정에서 계약을 변경(필요한 경우)합니다.

공급업체의 활동은 공동 평가 및 감사 프로세스에 명시된 조치에 따라 감독됩니다. 승인 과정에서 필요한 테스트가 준비되고 수행됩니다. 계약에 따른 작업 완료는 수락 조건이 충족되는 경우 수행됩니다.

전달 프로세스는 고객에게 소프트웨어 제품 또는 서비스를 제공하는 공급업체가 수행하는 활동과 작업을 다룹니다. 이 프로세스에는 다음 단계가 포함됩니다.

배송 개시;
입찰에 대한 응답을 준비하는 단계;
계약 준비;
계약 작업 계획;
계약 작업의 수행 및 통제 및 평가
납품 및 작업 완료.

공급 개시는 입찰 공급자의 고려 및 명시된 요구 사항 및 조건에 동의할지 아니면 자체 제안(합의)을 제공할지 결정하는 것으로 구성됩니다. 계획에는 다음 작업이 포함됩니다.

자체적으로 또는 하청업체의 참여로 작업 수행과 관련하여 공급업체가 결정을 내림
프로젝트의 조직 구조, 책임의 구분, 개발 환경 및 자원에 대한 기술 요구 사항, 하청업체 관리 등을 포함하는 프로젝트 관리 계획의 공급자에 의한 개발

개발 프로세스는 개발자가 수행하는 활동과 작업을 제공하고 지정된 요구 사항에 따라 소프트웨어 및 해당 구성 요소를 만드는 작업을 다룹니다. 여기에는 설계 및 운영 문서 준비, 성능 테스트에 필요한 재료 준비 및 소프트웨어 제품의 품질, 직원 교육 조직에 필요한 자료 등

개발 프로세스에는 다음 단계가 포함됩니다.

준비 작업;
시스템 요구 사항 분석;
시스템 아키텍처 설계;
소프트웨어 요구 사항 분석;
소프트웨어 아키텍처 설계;
상세한 소프트웨어 설계;
소프트웨어 코딩 및 테스트;
소프트웨어 통합;
소프트웨어 자격 테스트;
시스템 통합;
시스템의 자격 테스트;
소프트웨어 설치;
소프트웨어 수용.

준비 작업은 프로젝트의 규모, 중요성 및 복잡성에 적합한 소프트웨어 수명 주기 모델을 선택하는 것으로 시작됩니다. 개발 프로세스의 활동 및 작업은 선택한 모델과 일치해야 합니다. 개발자는 프로젝트의 조건에 맞게 선택하고 적용해야 하며 고객과 합의한 표준, 방법 및 방법을 사용해야 합니다. 개발 도구, 작업 계획을 작성합니다.

시스템 요구 사항 분석에는 기능 결정, 사용자 정의 요구 사항, 신뢰성 요구사항, 보안, 외부 인터페이스 요구사항, 성능 등 시스템 요구 사항은 테스트 중 타당성 기준과 검증 가능성을 기반으로 평가됩니다.

시스템 아키텍처 설계는 시스템을 운영하는 직원이 수행하는 장비(하드웨어), 소프트웨어 및 작업의 구성 요소를 결정하는 것으로 구성됩니다. 시스템 아키텍처는 시스템 요구 사항과 승인된 설계 표준 및 관행을 준수해야 합니다.

소프트웨어 요구 사항 분석에는 각 소프트웨어 구성 요소에 대해 다음과 같은 특성을 결정하는 작업이 포함됩니다.

구성 요소의 성능 특성 및 운영 환경을 포함한 기능;
외부 인터페이스;
신뢰성 및 안전 사양;
인체 공학적 요구 사항;
사용된 데이터에 대한 요구 사항
설치 및 수락 요구 사항;
사용자 문서에 대한 요구 사항
작동 및 유지 보수 요구 사항.

소프트웨어 요구 사항은 테스트 중 시스템 전체의 요구 사항 준수, 실행 가능성 및 검증 가능성 기준에 따라 평가됩니다.

소프트웨어 아키텍처 설계에는 각 소프트웨어 구성 요소에 대한 다음 작업이 포함됩니다.

소프트웨어 요구 사항을 높은 수준에서 소프트웨어의 구조와 구성 요소의 구성을 정의하는 아키텍처로 변환합니다.
소프트웨어 및 데이터베이스(DB)를 위한 프로그램 인터페이스의 개발 및 문서화;
사용자 문서의 예비 버전 개발
테스트 및 소프트웨어 통합 계획을 위한 전제 조건의 개발 및 문서화.

상세한 소프트웨어 설계에는 다음 작업이 포함됩니다.

후속 코딩 및 테스트에 충분한 하위 수준에서 소프트웨어 구성 요소 및 이들 간의 인터페이스에 대한 설명
상세한 데이터베이스 설계를 개발하고 문서화합니다.
(필요한 경우) 사용자 문서 업데이트
테스트 요구 사항의 개발 및 문서화 및 소프트웨어 구성 요소 테스트 계획

소프트웨어 코딩 및 테스트에는 다음 작업이 포함됩니다.

소프트웨어 및 데이터베이스의 각 구성 요소를 코딩하고 문서화하고 테스트 절차 및 테스트를 위한 데이터를 준비합니다.
소프트웨어 및 데이터베이스의 각 구성 요소에 대한 요구 사항 준수 여부를 테스트한 후 테스트 결과를 문서화합니다.
문서 업데이트(필요한 경우)
소프트웨어 통합 계획을 업데이트합니다.

소프트웨어 통합은 집계된 구성 요소에 대한 통합 및 테스트 계획에 따라 개발된 소프트웨어 구성 요소의 조립을 제공합니다. 집계된 각 구성 요소에 대해 후속 능력 테스트에서 각 역량을 테스트하기 위해 테스트 스위트 및 테스트 절차가 개발됩니다. 자격 요건은 자격을 갖추기 위해 충족되어야 하는 일련의 기준 또는 조건입니다. 소프트웨어사양을 준수하고 현장에서 바로 사용할 수 있습니다.

소프트웨어의 적격성 테스트는 고객(

운영 프로세스는 시스템을 운영하는 운영자 조직의 활동 및 작업을 다룹니다. 작업 프로세스에는 다음 단계가 포함됩니다.

작업자가 다음 작업을 수행하는 것을 포함하는 준비 작업:
1. 운영 중 수행되는 활동 및 작업 계획 및 운영 표준 설정
2. 작동 중 발생하는 문제의 현지화 및 해결 절차 결정.
소프트웨어 제품의 각 다음 에디션에 대해 운영 테스트가 수행된 후 이 에디션이 운영으로 이전됩니다.
사용자 문서에 따라 의도된 환경에서 수행되는 시스템의 실제 작동.
문제 분석 및 소프트웨어 수정 요청(발생한 문제 또는 수정 요청에 대한 메시지 분석, 규모 평가, 수정 비용, 결과 영향, 수정 가능성 평가);
소프트웨어 수정(개발 프로세스의 규칙에 따라 소프트웨어 제품 구성 요소 및 문서 변경)
검증 및 수용(수정되는 시스템의 무결성 측면에서)
소프트웨어를 다른 환경으로 이전(일정 기간 동안 프로그램 및 데이터 변환, 이전 환경과 새 환경에서 소프트웨어 병렬 운영)
운영 조직, 유지 보수 서비스 및 사용자의 참여로 고객의 결정에 의한 소프트웨어 폐기. 동시에 소프트웨어 제품 및 문서는 계약에 따라 보관해야 합니다.

주석.

소개.

1. 소프트웨어 수명 주기

소개.

Riley 프로그래밍 프로세스 단계

소개.

1.1.1. 문제의 공식화.

1.1.2. 솔루션 디자인.

1.1.3. 알고리즘 코딩.

1.1.4. 프로그램 지원.

1.1.5. 소프트웨어 문서.

단락 1.1의 결론

1.2. Lehman에 따른 ZhTsPO의 정의.

소개.

1.2.1 시스템 정의.

1.2.2. 구현.

1.2.3. 서비스.

항목 1.2에 대한 결론.

1.3. Boehm에 따른 수명 주기 프로그램의 단계 및 작업

1.3.1. 캐스케이드 모델.

1.3.2. 캐스케이드 모델의 경제적 입증.

1.3.3. 캐스케이드 모델의 개선.

1.3.4. 라이프 사이클 단계의 정의.

1.3.5. 프로젝트의 기본 작업.

문학.

소개

컴퓨터의 산업적 응용과 프로그램에 대한 증가하는 수요는 소프트웨어 개발 생산성, 프로그램 계획 및 설계를 위한 산업적 방법의 개발, 물질적 생산 영역에서 컴퓨터 영역으로의 조직적, 기술적, 기술적, 경제적, 사회심리학적 방법, 패턴 및 방법의 이전. 복잡한 접근소프트웨어의 개발, 운영 및 유지 관리 프로세스에 여러 긴급한 문제가 제시되며, 그 솔루션은 프로그램 설계의 "병목 현상"을 제거하고 완료 시간을 단축하며 기존 프로그램의 선택 및 적용을 개선합니다. 임베디드 컴퓨터가 있는 시스템의 운명을 결정할 수도 있습니다.

대규모 소프트웨어 프로젝트를 개발하는 과정에서 종종 통일된 접근소프트웨어 개발의 생산성 향상을 저해하는 인건비, 작업조건, 자재비 등을 평가하고 궁극적으로는 소프트웨어 라이프사이클을 효율적으로 관리합니다. 모든 유형의 프로그램이 제품이 되기 때문에(교육, 목업 프로그램 제외), 생산에 대한 접근 방식은 여러 측면에서 산업 제품 생산에 대한 접근 방식과 유사해야 하며 소프트웨어 설계 문제가 매우 중요합니다. . 이 아이디어는 B.U. Boehm "엔지니어링 소프트웨어 디자인", 우리가 이 용어 논문을 작성할 때 사용했습니다. 이 책에서 소프트웨어 디자인은 소프트웨어 제품에 대한 디자인을 만드는 과정을 의미합니다.

1 소프트웨어 수명 주기

소개

LCPE는 소프트웨어 생성의 필요성에 대한 결정이 내려지는 순간부터 시작되어 운영이 완전히 중단되는 순간 끝나는 연속적인 프로세스입니다.

소프트웨어 수명 주기(SLLC), 프로그래밍 프로세스 단계, 폭포수 및 나선형 모델의 단계 및 활동을 정의하는 몇 가지 접근 방식이 있습니다. 그러나 그것들은 모두 공통의 기본 구성요소인 문제 설명, 솔루션 설계, 구현, 유지보수를 포함합니다.

아마도 가장 유명하고 완전한 것은 8단계를 포함하는 Boehm에 따른 수명 주기의 구조일 것입니다. 나중에 더 자세히 소개하겠습니다.

가능한 옵션 중 하나는 Lehman에 따른 상위 레벨에 대한 설명일 수 있습니다. 이 설명은 세 가지 주요 단계를 포함하고 가장 일반적인 경우 라이프 사이클 프로그램에 대한 설명을 나타냅니다.

그리고 변경을 위해 D. Riley가 "Modula-2 언어 사용" 책에서 제시한 프로그래밍 프로세스 단계가 있습니다. 내 생각에 이 아이디어는 매우 간단하고 친숙하며 시작하겠습니다.

1.1 Riley 프로그래밍 프로세스 단계

소개

프로그래밍 프로세스에는 4단계가 포함됩니다(그림 1).

문제 진술, 즉 프로그램이 수행해야 하는 작업에 대한 적절한 아이디어 얻기

이미 제기된 문제에 대한 솔루션 설계(일반적으로 이러한 솔루션은 최종 프로그램보다 덜 형식적임)

프로그램 코딩, 즉 설계된 솔루션을 기계에서 실행할 수 있는 프로그램으로 번역

프로그램 지원, 즉 프로그램의 버그를 수정하고 새로운 기능을 추가하는 지속적인 프로세스.

쌀. 1.네 가지 프로그래밍 단계.

프로그래밍은 다음과 같은 순간부터 시작됩니다. 사용자, 즉. 문제를 해결하기 위해 프로그램이 필요한 사람이 문제를 제기합니다. 시스템 분석가.사용자와 시스템 분석가는 공동으로 문제 설명을 정의합니다. 후자는 전송됩니다. 알고리즘 주의자솔루션 설계를 담당하는 사람입니다. 솔루션(또는 알고리즘)은 일련의 작업으로, 이를 실행하면 문제가 해결됩니다. 알고리즘은 종종 기계에서 실행되도록 조정되지 않기 때문에 기계 프로그램으로 변환되어야 합니다. 이 작업은 인코더에 의해 수행됩니다. 유지 관리자는 프로그램의 후속 변경에 대한 책임이 있습니다. 프로그램 제작자. 그리고 시스템 분석가, 알고리즘 학자, 코더, 그와 함께하는 프로그래머 - 모두 프로그래머입니다.

대규모 소프트웨어 프로젝트의 경우 사용자, 시스템 분석가 및 알고리즘의 수가 중요할 수 있습니다. 또한 예상치 못한 상황으로 인해 이전 단계로 되돌려야 할 수도 있습니다. 이 모든 것은 신중한 소프트웨어 설계를 지지하는 추가적인 주장으로 작용합니다. 각 단계의 결과는 완전하고 정확하며 이해할 수 있어야 합니다.

1.1.1 문제에 대한 설명

프로그래밍에서 가장 중요한 단계 중 하나는 문제를 설정하는 것입니다. 사용자와 프로그래머 간의 계약 역할을 합니다. 법적으로 제대로 작성되지 않은 계약과 마찬가지로 잘못된 사명 선언문은 쓸모가 없습니다. 좋은 문제 설명을 통해 사용자와 프로그래머 모두 수행할 작업을 명확하고 모호하지 않게 나타냅니다. 이 경우 사용자와 프로그래머 모두의 이익이 고려됩니다. 사용자는 가능한 지식을 기반으로 아직 생성되지 않은 소프트웨어를 사용할 계획을 세울 수 있습니다. 문제에 대한 좋은 설명은 솔루션 구성의 기초가 됩니다.

문제의 공식화 (프로그램 사양); 본질적으로 특정 프로그램이 실행될 때 일어나는 일에 대한 정확하고 완전하며 이해할 수 있는 설명을 의미합니다. 사용자는 일반적으로 컴퓨터를 블랙박스로 봅니다. 컴퓨터가 어떻게 작동하는지는 그에게 중요하지 않지만 사용자가 관심 있는 작업을 컴퓨터가 수행할 수 있다는 것이 중요합니다. 초점은 사람과 기계 간의 상호 작용에 있습니다.

좋은 문제 진술의 특징:

정확성, 즉. 모든 모호성 배제. 주어진 입력에 대해 프로그램의 출력이 무엇인지에 대해서는 의문의 여지가 없어야 합니다.

완전성, 즉. 잘못된 입력이나 예상치 못한 입력을 포함하여 주어진 입력에 대한 모든 옵션을 고려하고 적절한 출력을 결정합니다.

명쾌함, 즉. 문제 설명이 그들 사이의 유일한 계약이기 때문에 사용자와 시스템 분석가 모두가 이해할 수 있어야 합니다.

정확성, 완전성 및 명확성에 대한 요구 사항이 충돌하는 경우가 많습니다. 따라서 많은 법률 문서는 가장 사소한 불일치를 제외하고 특정 조항을 최대한 정확하게 공식화할 수 있는 공식 언어로 작성되어 있기 때문에 이해하기 어렵습니다. 예를 들어, 시험지의 일부 질문은 때때로 너무 정확하게 표현되어 학생이 답하는 것보다 질문을 이해하는 데 더 많은 시간을 할애합니다. 더욱이, 학생은 많은 세부 사항으로 인해 질문의 주요 의미를 전혀 이해하지 못할 수 있습니다. 가장 좋은 문제 진술은 세 가지 요구 사항의 균형을 달성하는 것입니다.

문제 진술의 표준 형식.

문제에 대한 다음 진술을 고려하십시오. "세 개의 숫자를 입력하고 숫자를 순서대로 출력하십시오."

그러한 진술은 위의 요구 사항을 충족하지 않습니다. 정확하지도 완전하지도 않고 이해할 수도 없습니다. 실제로 숫자를 한 줄에 하나씩 입력해야 합니까, 아니면 모든 숫자를 한 줄에 입력해야 합니까? "순서대로"라는 표현은 가장 큰 것에서 가장 작은 것, 가장 작은 것에서 가장 큰 것, 또는 도입된 것과 같은 순서를 의미합니까?

그러한 진술이 많은 질문에 답하지 않는다는 것은 분명합니다. 모든 질문에 대한 답변을 고려하면 문제 설명이 말이 많아지고 이해하기 어려워집니다. 따라서 D. Riley는 최대 정확도, 완전성, 명확성을 보장하고 다음을 포함하는 문제를 설정하기 위해 표준 형식을 사용할 것을 제안합니다.

작업 이름(도식 정의);

일반 설명(작업에 대한 간략한 설명);

오류(비정상적인 입력 옵션은 사용자와 프로그래머에게 이러한 상황에서 기계가 취하는 조치를 보여주기 위해 명시적으로 나열됨)

예(좋은 예는 문제의 본질을 전달할 수 있을 뿐만 아니라 다양한 경우를 설명할 수 있음).

예시. 표준 형식의 문제 설명.

제목

세 개의 정수를 정렬합니다.

설명

가장 작은 것에서 가장 큰 것 순으로 정렬된 3개의 정수의 입력 및 출력.

한 줄에 하나의 숫자로 세 개의 정수가 입력됩니다. 이 경우 정수는 더하기 기호 "+" 또는 빼기 기호 "-"가 앞에 올 수 있는 하나 이상의 연속 10진수입니다.

입력한 세 개의 정수가 출력되며 세 개는 모두 같은 줄에 표시됩니다. 인접한 숫자는 공백으로 구분됩니다. 숫자는 작은 것부터 큰 것, 왼쪽에서 오른쪽으로 표시됩니다.

1) 3개 미만의 숫자가 입력되면 프로그램은 추가 입력을 기다립니다.

2) 처음 3개 이외의 입력 라인은 무시됩니다.

3) 처음 세 줄 중 하나에 둘 이상의 정수가 포함되어 있으면 프로그램이 종료되고 메시지가 표시됩니다.

주석.

소개.

1. 소프트웨어 수명 주기

소개.

Riley 프로그래밍 프로세스 단계

소개.

1.1.1. 문제의 공식화.

1.1.2. 솔루션 디자인.

1.1.3. 알고리즘 코딩.

1.1.4. 프로그램 지원.

1.1.5. 소프트웨어 문서.

단락 1.1의 결론

1.2. Lehman에 따른 ZhTsPO의 정의.

소개.

1.2.1 시스템 정의.

1.2.2. 구현.

1.2.3. 서비스.

항목 1.2에 대한 결론.

1.3. Boehm에 따른 수명 주기 프로그램의 단계 및 작업

1.3.1. 캐스케이드 모델.

1.3.2. 캐스케이드 모델의 경제적 입증.

1.3.3. 캐스케이드 모델의 개선.

1.3.4. 라이프 사이클 단계의 정의.

1.3.5. 프로젝트의 기본 작업.

문학.

소개

1 소프트웨어 수명 주기

소개

LCPE는 소프트웨어 생성의 필요성에 대한 결정이 내려지는 순간부터 시작되어 운영이 완전히 중단되는 순간 끝나는 연속적인 프로세스입니다.

아마도 가장 유명하고 완전한 것은 8단계를 포함하는 Boehm에 따른 수명 주기의 구조일 것입니다. 나중에 더 자세히 소개하겠습니다.

1.1 Riley 프로그래밍 프로세스 단계

프로그래밍 프로세스에는 4단계가 포함됩니다(그림 1).

문제 진술, 즉 프로그램이 수행해야 하는 작업에 대한 적절한 아이디어 얻기

이미 제기된 문제에 대한 솔루션 설계(일반적으로 이러한 솔루션은 최종 프로그램보다 덜 형식적임)

프로그램 코딩, 즉 설계된 솔루션을 기계에서 실행할 수 있는 프로그램으로 번역

프로그램 지원, 즉 프로그램의 버그를 수정하고 새로운 기능을 추가하는 지속적인 프로세스.

쌀. 1.네 가지 프로그래밍 단계.

프로그래밍은 다음과 같은 순간부터 시작됩니다. 사용자, 즉. 문제를 해결하기 위해 프로그램이 필요한 사람이 문제를 제기합니다. 시스템 분석가.사용자와 시스템 분석가는 공동으로 문제 설명을 정의합니다. 후자는 전송됩니다. 알고리즘 주의자솔루션 설계를 담당하는 사람입니다. 솔루션(또는 알고리즘)은 일련의 작업으로, 이를 실행하면 문제가 해결됩니다. 알고리즘은 종종 기계에서 실행되도록 조정되지 않기 때문에 기계 프로그램으로 변환되어야 합니다. 이 작업은 인코더에 의해 수행됩니다. 동반 프로그래머는 프로그램에 대한 후속 변경에 대한 책임이 있습니다. 그리고 시스템 분석가, 알고리즘 학자, 코더, 그와 함께하는 프로그래머 - 모두 프로그래머입니다.

1.1.1 문제에 대한 설명

좋은 문제 진술의 특징:

정확성, 즉. 모든 모호성 배제. 주어진 입력에 대해 프로그램의 출력이 무엇인지에 대해서는 의문의 여지가 없어야 합니다.

완전성, 즉. 잘못된 입력이나 예상치 못한 입력을 포함하여 주어진 입력에 대한 모든 옵션을 고려하고 적절한 출력을 결정합니다.

명쾌함, 즉. 문제 설명이 그들 사이의 유일한 계약이기 때문에 사용자와 시스템 분석가 모두가 이해할 수 있어야 합니다.

문제 진술의 표준 형식.

문제에 대한 다음 진술을 고려하십시오. "세 개의 숫자를 입력하고 숫자를 순서대로 출력하십시오."

그러한 진술은 위의 요구 사항을 충족하지 않습니다. 정확하지도 완전하지도 않고 이해할 수도 없습니다. 실제로 숫자를 한 줄에 하나씩 입력해야 합니까, 아니면 모든 숫자를 한 줄에 입력해야 합니까? "순서대로"라는 표현은 가장 큰 것에서 작은 것, 가장 작은 것에서 가장 큰 것 또는 입력된 것과 같은 순서를 의미합니까?

작업 이름(도식 정의);

일반 설명(작업에 대한 간략한 설명);

오류(비정상적인 입력 옵션은 사용자와 프로그래머에게 이러한 상황에서 기계가 취하는 조치를 보여주기 위해 명시적으로 나열됨)

예(좋은 예는 문제의 본질을 전달할 수 있을 뿐만 아니라 다양한 경우를 설명할 수 있음).

예시. 표준 형식의 문제 설명.

제목

세 개의 정수를 정렬합니다.

설명

가장 작은 것에서 가장 큰 것 순으로 정렬된 3개의 정수의 입력 및 출력.

1) 3개 미만의 숫자가 입력되면 프로그램은 추가 입력을 기다립니다.

2012년 3월 1일 러시아 연방 기술 규제 및 계측을 위한 연방 기관은 GOST R ISO/IEC 12207-2010 표준 "정보 기술. 시스템 및 소프트웨어 엔지니어링. 소프트웨어 라이프 사이클 프로세스", 국제 표준 ISO/IEC 12207:2008 "시스템 및 소프트웨어 엔지니어링 - 소프트웨어 라이프 사이클 프로세스"와 동일합니다.

이 표준은 확립된 용어를 사용하여 소프트웨어 산업에서 지침으로 사용할 수 있는 소프트웨어 수명 주기 프로세스에 대한 공통 프레임워크를 설정합니다. 이 표준은 소프트웨어 제품 또는 서비스의 획득은 물론 소프트웨어 제품의 제공, 개발, 의도된 사용, 유지 관리 및 중단에 사용되는 프로세스, 활동 및 작업을 정의합니다.

소프트웨어 수명 주기 프로세스

표준은 소프트웨어 시스템의 수명 주기 동안 수행할 수 있는 다양한 활동을 7개의 프로세스 그룹으로 그룹화합니다. 이러한 그룹 내의 각 수명 주기 프로세스는 목적 및 원하는 출력, 이러한 결과를 달성하기 위해 수행할 작업 및 작업 목록의 관점에서 설명됩니다.

계약 프로세스 - 두 가지 프로세스;
프로젝트 조직 지원 프로세스 - 5가지 프로세스;
프로젝트 프로세스 - 7가지 프로세스;
기술 프로세스 - 11개 프로세스;
소프트웨어 구현 프로세스 - 7가지 프로세스;
소프트웨어 지원 프로세스 - 8개 프로세스;
소프트웨어 재사용 프로세스 - 세 가지 프로세스.
기본:
- 획득(소프트웨어를 구매하는 고객의 행동 및 작업)
- 납품(고객에게 소프트웨어 제품 또는 서비스를 공급하는 공급자의 활동 및 작업)
- 개발(개발자가 수행하는 작업 및 작업: 소프트웨어 생성, 설계 및 운영 문서 작성, 테스트 및 교육 자료 준비 등)
- 운영(운영자의 작업 및 작업 - 시스템을 운영하는 조직)
- 유지 관리(동반 조직, 즉 유지 관리 서비스에서 수행하는 작업 및 작업). 유지 관리 - 오류를 수정하고 성능을 개선하거나 변화하는 작동 조건 또는 요구 사항에 적응하기 위해 소프트웨어를 변경합니다.
보조자
- 문서(소프트웨어 수명 주기 동안 생성된 정보에 대한 형식화된 설명)
- 구성 관리(소프트웨어 구성 요소의 상태를 결정하고 수정 사항을 관리하기 위해 소프트웨어 수명 주기 전반에 걸쳐 관리 및 기술 절차를 적용합니다.)
- 품질 보증(IS 및 해당 수명 주기의 프로세스가 지정된 요구 사항 및 승인된 계획을 준수하는지 확인)
- 검증(일부 조치의 결과인 소프트웨어 제품이 이전 조치로 인한 요구 사항 또는 조건을 완전히 충족하는지 확인)
- 인증(특정 요구 사항 및 특정 기능 목적으로 생성된 시스템의 준수 완전성 결정)
- 공동 평가(프로젝트 작업 상태 평가: 자원, 인력, 장비, 도구의 계획 및 관리 관리)
- 감사(계약의 요구 사항, 계획 및 조건 준수 여부 결정)
- 문제 해결(개발, 운영, 유지 관리 또는 기타 프로세스 중에 발견된 문제의 출처 또는 출처에 관계없이 문제의 분석 및 해결)
조직적
- 관리(자신의 프로세스를 관리하는 모든 당사자가 수행할 수 있는 활동 및 작업)
- 인프라 생성(기술, 표준 및 도구의 선택 및 유지 관리, 소프트웨어 개발, 운영 또는 유지 관리에 사용되는 하드웨어 및 소프트웨어의 선택 및 설치)
- 개선(라이프 사이클 프로세스의 평가, 측정, 제어 및 개선)
- 교육(초기 교육 및 이후 지속적인 직원 개발)

각 프로세스에는 여러 활동이 포함됩니다. 예를 들어 획득 프로세스는 다음 단계를 다룹니다.

인수 개시
입찰 준비
계약 준비 및 조정
공급업체 감독
작업 수락 및 완료

각 작업에는 여러 작업이 포함됩니다. 예를 들어 입찰 준비에는 다음이 포함되어야 합니다.

시스템 요구 사항 형성
소프트웨어 제품 목록 구성
조건 및 계약 설정
기술적 한계에 대한 설명(시스템 운영 환경 등)

소프트웨어 라이프 사이클 단계, 프로세스와 단계의 관계

소프트웨어 수명 주기 모델- 수명 주기 전반에 걸쳐 실행 순서와 프로세스, 작업 및 작업의 관계를 결정하는 구조입니다. 라이프 사이클 모델은 프로젝트의 세부 사항, 규모 및 복잡성과 시스템이 생성되고 운영되는 특정 조건에 따라 다릅니다.

GOST R ISO/IEC 12207-2010 표준은 특정 수명 주기 모델을 제공하지 않습니다. 그 조항은 IP 생성을 위한 모든 수명 주기 모델, 방법 및 기술에 공통적입니다. 이러한 프로세스에 포함된 활동 및 작업을 구현하거나 수행하는 방법을 지정하지 않고 수명 주기 프로세스의 구조를 설명합니다.

소프트웨어 수명 주기 모델에는 다음이 포함됩니다.

단계;
각 단계의 작업 결과;
주요 이벤트 - 작업 및 의사 결정 완료 시점.

소프트웨어 수명 주기에 포함된 항목입니다. 소프트웨어 수명 주기

소프트웨어 수명 주기 모델

캐스케이드 모델

캐스케이드 모델의 범위

증분 모델

나선형 모델

나선형 모델의 범위

5.2. PS 라이프 사이클의 주요 프로세스

소프트웨어 수명 주기 프로세스

소프트웨어 라이프 사이클 단계, 프로세스와 단계의 관계

또한 읽기

급여가 좋은 직업을 찾을 수 있는 곳: 벨로루시에서 가장 높은 급여를 받는 직업 벨로루시에서 구인 광고

영국에서의 취업 및 취업

추천서를 작성하는 방법

벨