Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
методичка к КП-230115.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
728.06 Кб
Скачать

2.2.1 Формирование требований к проекту

Программный продукт может разрабатываться как по индивидуальному заказу в соответствии с требованиями заказчика, так и для широкого коммерческого применения; в последнем случае роль заказчика выполняет рынок, требования которого обязан всесторонне учитывать разработчик. Основной вид деятельности на этом этапе — сбор требований пользователей и их тщательное документирование.

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

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

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

2.2.2 Техническое задание

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

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

Этап архитектурного проектирования — этап "принятия решения". Цель этого этапа — определить совокупность компонент программного изделия и их интерфейсы, чтобы дать каркас для последующей разработки программного изделия.

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

2.2.3 Эскизный проект

Эскизный проект разрабатывают, если это предусмотрено техническим заданием. Эскизный проект разрабатывают с целью установления принципиальных (конструктивных, схемных и др.) решений изделия, дающих общее представление о принципе работы и (или) устройстве изделия, когда это целесообразно сделать до разработки технического проекта или рабочей документации.

На стадии разработки эскизного проекта рассматривают варианты изделия и (или) его составных частей. Эскизный проект может разрабатываться без рассмотрения на этой стадии различных вариантов.

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