ГОСТ Р ИСО/МЭК 14764-2002
- избегать неструктурированных программных кодов;
- устранять классические ловушки путем учета слабых мест используемого языка;
- выявлять ошибки в техническом проекте;
- использовать методы, облегчающие выявление ошибок.
6.8.2.5 Квалификационные испытания программного средства
Данная работа обеспечивает проверку соответствия реализаций каждого требования к программному средству (ГОСТ Р ИСО/МЭК 12207). Во время данной работы тестируют требования к программному средству, связанные с его качеством. При регрессионном тестировании программного средства после внесения в него изменений применяют контрольные примеры, использованные при разработке данного средства. Кроме того, при сопровождении должен быть доступен архив разработки программы, чтобы избежать повторения ошибок, допущенных при ее разработке.
6.9 Передача программного средства
Передача программного средства является контролируемой и координируемой последовательностью действий, при выполнении которых разработанное программное средство переходит от организации, выполнявшей его первоначальную разработку, к организации, проводящей его сопровождение. Должен быть разработан план передачи, если обязанности, относящиеся к сопровождению, передают от одной организации к другой. В данном плане должны быть отражены:
- требования к передаче технических и программных средств, данных и знаний (опыта) от разработчика к сопроводителю;
- задачи сопроводителя, необходимые для реализации стратегии сопровождения программного средства (например, комплектование персонала, его обучение, ввод в действие программного средства, распространение опыта по сопровождению).
6.10 Документы
Сопроводители часто сталкиваются с необходимостью сопровождать программный продукт с минимальным набором документов или при отсутствии таковых. При отсутствии документов сопроводитель должен их создать. Создание документов является частью полного сопровождения. Отсутствие документов вызывает трудности при выполнении функции сопровождения. Столкнувшись с подобной ситуацией, сопроводитель при подготовке к сопровождению должен:
a) определить проблемную область (тип приложения); изучить любые доступные документы, по возможности обсудить программный продукт с разработчиками и поработать с данным продуктом;
b) изучить структуру и организацию программного продукта; провести инвентаризацию программного продукта, подвергнуть продукт управлению конфигурацией, выстроить продукт в соответствии с библиотеками управления конфигурацией, создать деревья вызовов и проанализировать структуру данного продукта;
c) определить функции, реализуемые программным продуктом; по возможности рассмотреть технические требования (спецификации) к данному продукту, его общую структуру, проанализировать деревья вызовов, прочитать программные коды, предоставить данный продукт другим сопроводителям и прокомментировать программные коды;
d) установить низшие приоритеты ПР или ОП.
Сопроводители должны документально описать программный продукт в соответствии с приведенными выше рекомендациями. Должны быть обновлены или разработаны (при необходимости) следующие документы: технические требования (спецификации), руководства программиста по сопровождению, руководства пользователя и руководства по вводу в действие (инсталляции). Имеется ряд факторов, влияющих на создание или обновление документов. Некоторыми из них являются доступ к исходным программам, наличие инструментальных средств анализа программ и наличие среды тестирования программного средства (СТПС).
7 Стратегия сопровождения программного средства
7.1 Введение
В настоящем разделе рассмотрена разработка политики сопровождения программного средства. Данная политика ориентирована на людские и материальные ресурсы, необходимые для обеспечения сопровождения программного продукта. В качестве целей при планировании сопровождения должны быть использованы результаты анализа сопровождаемости. Этот анализ является исходным пунктом при разработке стратегии сопровождения. Политика сопровождения программного средства должна охватывать следующие элементы:
- концепцию сопровождения;
10