vga's blog
Ведение проектной документации при разработке ПО
Sat Jan 26, 2008 11:26 am
В Данной статье описываются основные этапы подготовки технической документации на разработку Программного обеспечения. В зависимости от сложности проекта и требований заказчика, часть документов может быть упущена или включать в одном документе несколько.
Итак, любая разработка начинается:
1. Requirements (Запрос на разработку). Создается заказчиком.
Описывает поведение разработки с пользовательской точки зрения, включая подробное описание требований к продукту. Наряду с функциональными требованиями, он также описывает и нефункциональные, а также проектные требования и ограничения и другие факторы, необходимые для предоставления полного и ясного описания требований к продукту. Дается краткое описание используемых бизнес-процессов, желаемые возможности продукта, требования к Функциональности, данным, безопасности, пользовательской документации, описываются зависимости.
2. Project Proposal (Предложение на разработку).
После изучение системы заказчика, разработчик выставляется подготовленное "Предложение на разработку". Документ содержит общие требования, описания и предложения в соответствии с теми характеристиками и решениями, которые могут быть использованы. Он содержит оценку проектных рисков и предложения по управлению этими рисками, решения возможных проблем, примерную оценку времени и ресурсов проекта. Данный документ является отправной точкой для начала процесса выбора фирмы-разработчика и утверждения проекта.
После успешного проведения тендера и определения фирмы, которая будет производить разработку, подготавливается:
3. Functional Specification (Спецификация или Техническое задание (ТЗ).
Документ Functional Specification полностью описывает поведение проекта и как будут реализованы требования заказчика. Включает общее описание функциональности, надежности, производительности, безопасности, требования к данным и преобразованию данных, пользовательской документации и масштабируемости. Содержится подробное функциональное описание разработки, пользовательский и аппаратный интерфейсы, методы обработки ошибок, планирование работ, источники и преобразование данных, выходные формы и отчеты, ограничения и взаимные риски. Окончательная версия документа, включает исходные коды, справочники.
Основная цель написания технического задания - устранение всяких двусмысленностей о том, что именно будет являться конечным продуктом. Конечно, любому заказчику проще не составлять техническое задание, а вносить коррективы по ходу работ, однако такой подход в корне не устраивает любого разработчика, поскольку не позволит оценить затраты на оказание услуг и приведет к убыткам.
После составления технического задания становится возможна оценка времени и стоимости реализации проекта.
4. Test Plan (План Тестирования).
Начальное тестирование проводится разработчиком на этапе разработки программы на основании имеющихся в системе данных. При наличии у разработчика специальных тестировщиков, проводится пошаговое тестирование всего программного продукта, включая Стресс-тестинг (хаотичный запуск и переключение, совместное использование, выполнение при нехватке ресурсов). В процессе сдачи модулей и по окончании разработки должно происходить тестирование ключевыми пользователями.
5. Documentation (Документирование). К моменту сдачи разработки заказчику, подготавливается Пользовательская документация.
Основной этап разработки закончен. В процессе эксплуатации создаются следующие документы:
6. Change Request (Задание на исправление).
Документ Change Request описывает изменения, которые предлагается внести в разработку в связи с возникновением новых требований или обнаружением ошибок, включая подробное описание новых требований к продукту, с точки зрения бизнес-процессов. Наряду с функциональными изменениями, он также описывает и нефункциональные, а также изменения в проектных требованиях и ограничениях и другие факторы, необходимые для предоставления полного и ясного описания требований к продукту. Документ содержит Вид пользовательских экранов, типы и источники данных, алгоритм реализации.
В случае исправления ошибки описывается пошаговая последовательность действий, включающая скриншоты экранов, воспроизводящая ошибку.
Выявленные ошибки и порядок их воспроизведения вносится в существующий Test Plan, позволяющий при будущих изменениях в проекте заново провести тестирование и исключить вероятность, что старые ошибки возникнут вновь в результате изменения кода. Зачастую недостаточная документированность исходного кода и описание алгоритмов приводит к тому, что новый разработчик или по прошествии времени автор разработки, забыв или не достаточно поняв потребность в том или ином коде, удаляет или переписывает его, что приводит к повторному возникновению уже исправленных ошибок. Документ Test Plan позволяет избежать этого.
7. Release Notes (Информация о версиях).
Данный документ предоставляет исчерпывающую информацию о релизе продукта, включая общее описание релиза, новые возможности продукта, известные ошибки, недоработки, ограничения.
В России применяются следующие ГОСТы на технические задания
- ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
В следующих статьях я приведу подробное описание каждого из упомянутых здесь документов.
>>>More posts from this category: Шаблоны документовThe Trackback URL for this entry is:
http://www.sapnet.ru/trackback.php?e=4
| Author |
Message |
| There are no replies for this entry. |
|
Russian ABAP Developer's Club Forum Index
-> Blogs
-> vga's blog
-> Ведение проектной документации при разработке ПО
|
|
|