Предварительные замечания к проекту

Введение

Разработка информационной системы состоит из трех этапов:

анализа, проектирования и реализации, в результате итеративного выполнения которых происходит пошаговое «наращивание» системы. На этапах анализа и проектирования происходит построение архитектуры будущей информационной системы. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной.

Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания. Цель данных методических указаний – изучение на практике применения в проектировании подходов и методов, позволяющих получать успешные архитектуры информационных систем. Методические указания построены по принципу выдачи заданий на лабораторные работы и приведения комментариев и примеров к их выполнению. Лабораторные работы взаимосвязаны между собой и предполагают последовательное выполнение.

1. Лабораторная работа №1 «Установление требований»

Задание

Предложить для разработки информационную систему (ИС). ИС должна представлять собой программный комплекс, наделенный функциональностью, автоматизирующей конкретную деятельность в рамках предметной области, для которой разрабатывается система. Примером таких систем могут служить:

 автоматизированные системы управления (АСУ)

 электронные магазины, аукционы

 веб-порталы

 сервисы

Что надо сделать?

Составить документ описания требований к разрабатываемой ИС согласно шаблону (см. рис.1).

Установление требований

Документ описания требований

Документ, описывающий требования, является осязаемым результатом этапа установления требований. Большинство организаций вырабатывает документ описания требований в соответствии с заранее определенным шаблоном. Шаблон определяет структуру (содержание) и стиль документа. Ядро документа описания требований состоит из формулировок (изложения) требований. Требования могут быть сгруппированы в виде формулировок сервисов (зачастую называемых функциональными требованиями) и формулировок ограничений. Формулировки сути сервисов могут быть затем разделены на требования к функциям (function requirements) и требования к данным (data requirements). (В литературе термин «функциональные требования» (functional requirements) в широком и в узком смысле используется как взаимозаменяемый. При использовании в узком смысле он соответствует тому, что мы называем требованиями к функциям). Не говоря уже о самих требованиях, документ описания требований должен обращаться к проектным вопросам. Обычно проектные вопросы рассматриваются в начале документа, а затем в конце документа. Во вводной части документа рассматривается бизнес-контекст

проекта, включая цель проекта, участников проекта и основные ограничения. Ближе к заключительной части документа поднимаются другие проектные вопросы, включая план-график выполнения проектных работ, бюджет, риски, документацию и т. д.

Шаблоны документа

Шаблоны для документов описания требований широко доступны. Их можно найти в учебниках, стандартах, выпускаемых такими организациями как ISO, IEEE и т. д., на Web-страницах консалтинговых фирм, программных средствах разработки и т. д. Со временем каждая организация разрабатывает свои собственные стандарты, которые соответствуют принятой в организации практике, корпоративной культуре, кругу читателей, типам азрабатываемых систем и т. д.

Шаблон документа описания требований определяет структуру документа и содержит подробные указания о содержании каждого из разделов документа. Указания могут включать содержание вопросов, мотивацию, примеры и дополнительные соображения. На рис. 1 показано типичное оглавление документа описания требований. Последующие разделы включают объяснение к приведенному оглавлению.

Предварительные замечания к проекту

Часть документа описания требований, содержащая предварительные замечания к проекту, преимущественно дает ориентиры тем руководителям и участникам проекта, ответственным за принятие решений, которые, вероятно, не станут подробно изучать документ целиком. В начале документа необходимо ясно обозначить цели и рамки проекта, а затем описать деловой контекст системы. Документ описания требований должен создать прецедент для системы. В частности, необходимо упомянуть обо всех усилиях, приложенных для обоснования необходимости системы на этапе планирования системы. Документ описания требований должен прояснить вопрос о том, каким образом предлагаемая система может способствовать достижению деловых целей и решению задач организацией. Необходимо обозначить участников проекта системы. Важно, чтобы заказчик выступал не в виде безликого подразделения или офиса — необходимо привести конкретные имена. К концу дня человек должен быть в состоянии решить, приемлемо ли поставляемое программное обеспечение (ПО) для организации.