13.Определение технологии проектирования. Технологическая операция проектирования.
ТП определяется как совокупность:
Пошаговые процедуры, определяющие последовательность операций технологического проектирования;
Критерии правил, используемых для оценки результатов выполнения операций.
Графических и текстовых средств, используемых для описания разрабатываемых систем.
Каждая технологическая операция состоит из 4-х компонентов:
Вход для каждой технологической операции: исходные данные в стандартном представлении (различные данные, схемы и др. рабочие материалы, а также результаты будущих операций).
Снизу: Исполнители, инструментально-технологические средства для программы.
Сверху: Управление, методические материалы (инструкции, нормативы, стандарты, критерии оценки результатов)
Выход: Результат в стандартном представлении.
Основное содержание технологии – технологические инструкции, состоящие из описания технологических операций, их последовательности и условий в зависимости от которых должна выполняться та или иная операция.
Требования к технологии проектирования
Чтобы правильно спроектировать технологию:
Технология должна поддерживать полный ЖЦ ИС.
Технология должна обеспечивать гарантированное достижение целей разработки с заданным качеством и в установленные строки.
Технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем, т.е. должна быть декомпозиция на составные части, разработанные отдельными группами исполнителей ограниченной численности с последней интеграцией составных частей.
Лучше всего проект разбивать на слабо связанные подсистемы, реализацию каждой из которых поручить отдельной группе разработчиков.
При этом надо обеспечить координацию проектов и исключить дублирование результатов каждой группы.
Технология должна обеспечивать возможность проектирования отдельных подсистем группами от 3-х до 7-ми человек.
Технология должна обеспечивать минимальное время получения работоспособности ИС. Минимальное время – не готовность системы в целом, а полная рабочая готовность отдельных функциональных узлов.
Чтобы сделать полностью ИС в короткие сроки, требуется большое количество разработчиков, при этом качество создания системы будет не самым высоким, чем при реализации отдельных подсистем в более короткие сроки меньшим количеством разработчиков.
Технология должна позволять управлять конфигурацией проекта, вести версии проекта и его составляющих, возможность ведения автоматических отчетов.
Технология должна обеспечивать независимость выполненных проектных решений от средств проектирования.
14.Виды стандартов используемых разработчиками: стандарт проектирования, стандарт оформления проектной документации, стандарт пользовательского интерфейса.
Для реального применения технологии проектирования на предприятии разработчикам необходимо существование локального стандарта проектирования.
К таким стандартам относятся 3 вида:
1. Проектирование;
2. Стандарт оформления проектируемой документации;
3. Стандарт пользовательского интерфейса.
Стандарт проектирования должен установить список необходимых моделей (схем, диаграмм) на каждой стадии проектирования, степень их детализации
Правило фиксации проектных решений на схемах:
Правило именования объектов;
Список характеристик;
Правило оформления схем и моделей с точностью до форм и размеров объекта;
Требование к конфигурации рабочих мест разработчиков (настройки ОС, ПО);
Механизм обеспечения совместной работы над проектом, в т.ч. правила объединения подсистем проекта, правила обмена проектной информации;
Правила хранения общих объектов;
Правила проверки на непротиворечивость.
Стандарт оформления проектной документации должна включать в себя:
Комплектность, состав и структуру документации на каждой стадии проектирования;
Требования к содержанию разделов, подразделов и пунктов, таблиц и правил нумерации.
Стандарт интерфейса пользователя должен устанавливать правила оформления экрана, в т.ч. состав, расположение окон, элементов управления, вид шрифтов, цветовое решение интерфейсов.
Правило использования клавиатуры и мыши;
Правило оформления текстов помощи;
Перечень стандартов сообщений;
Правило обработки реакции пользователя.
15.Технико-экономического обоснование необходимости и реализуемости разработки ИС назначение и содержание. Место составления приближенной оценки и сметы в структуре процесса проектирования по ГОСТ 34.602-89. Основные способы оценки стоимости проектирования единичных и массовых ИС.
Технико-экономического обоснование – документ, в котором математически или логически обосновывается необходимость и целесообразность создания ИС.
Для обоснования необходимости создания ИС используются следующие критерии:
1. Наличие существующих проблем, препятствующих эффективной работе объекта, которые могут быть решены с помощью автоматизации. Это любые ошибки человеческих факторов, потери документов, искажение при передаче, различия квалификаций пользователей, и т.д.
2. Потери, обусловленные несовершенством структуры управления (недостаточное количество информации для анализа, неоправданное поступление информации, избыток ненужной информации, трудность анализа большого количества информации).
3. Наличие предпосылок по расширению функциональности объекта, что приведет к обострению пунктов 1 и 2.
4. Изменение внешних условий, приводящих к неправильной работе объектов.
Чтобы обосновать необходимость создания ИС, нужно:
1. Перечислить все явные проблемы, согласно приведенным критериям.
2. Определить место возникновения этих проблем на функциональной модели и составить список функций, которые нуждаются в изменении при решении перечисленных проблем.
3. Определить в денежном эквиваленте потери по каждой из проблем за отчетный период.
Основная задача – выяснить список всех проблем и определить суммарную стоимость этих проблем за некоторый отчетный период. Обычно составляется клиентом.
Определение стоимости создания ИС.
За расчет по фактическим затратам
Группы расходов:
1. Прямые
расходы на оплату труда;
материальные для реализации данного проекта (носители информации, базовое ПО);
расходы на создание модели;
2. Косвенные – расходы, которые нужны для поддержания деятельности и развития фирмы-разработчика
Компьютеры
ПО (ОС, проектирование)
3. Хозяйственные
Электричество (коммунальные платежи)
Аренда помещения.
С т. з. разработчика, желаемая стоимость S=D+R;
С т. з. заказчика, Q=∑Pi*K1*K2*Ki
K1 - коэф. Платежеспособности предприятия
K2 – коэф. Готовности заказчика принять ИС
Ki – коэф. Различных факторов.
Реальная стоимость с т. з. разработчика, Q’=S+P+N
P=10-40%
Стоимость массового продукта ∑Q=∑Qi
Цена одного экземпляра равна сумме стоимости затрат Q’ / количество реальных пользователей ∑Qi.
16.Документационное обеспечение проектирования ИС. Виды документации в процессе проектирования согласно структуре ГОСТ 34.601-90, ее назначение, используемые при составлении стандарты, и критерии обоснования необходимости составления.
Ниже приводится описание каждого документа из набора IEEE со ссылками на полные. Другие стандарты внутренне организованы по тому же принципу.
SVVP (Software Verification and Validation Plan): План экспертизы про¬граммного обеспечения. Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам про¬дукт на соответствие поставленным требованиям. Верификация — это процесс проверки правильности сборки приложения; валидация проверя¬ет тот факт, что собран требуемый продукт.. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (IV&V — Independent V&V).
SQAP (Software Quality Assurance Plan): План контроля качества про¬граммного обеспечения. Этот план определяет, каким образом проект должен достигнуть соответствия установленному уровню качества.
SCMP (Software Configuration Management Plan): План управления кон¬фигурациями программного обеспечения. SCMP определяет, как и где должны храниться документы, программный код и их версии, а также устанавливает их взаимное соответствие. Было бы крайне неразумным начинать работу без такого плана, так как самый первый созданный до¬кумент обречен на изменения, а мы должны знать, как управлять эти¬ми изменениями до того, как мы начнем составлять документ. В этой главе приводится описание IEEE SCMP. Таким образом, инже¬нерам требуется только научиться следовать предписанным процедурам в соответствии с SCMP.
SPMP (Software Project Management Plan): План управления программ ным проектом. Этот план определяет, каким образом управлять проектом Обычно он соответствует известному процессу разработки, например стандартному процессу компании.
SRS (Software Requirements Specification): Спецификация требований к программному обеспечению. Этот документ определяет требования к приложению и является подобием контракта и путеводной нити для заказчика и разработчиков.
SDD (Software Design Document): Проектная документация программно обеспечения. SDD представляет архитектуру и детали проектирования приложения, обычно с использованием диаграмм объектных моделей и потоков данных.
STD (Software Test Documentation): Документация по тестированию программного обеспечения. Этот документ описывает, каким образом должно проводиться тестирование приложения и его компонентов.
Иногда в проектах привлекается дополнительная документация. Документация для итеративной разработки может быть организована двумя способами. Некоторые документы, в частности SDD, могут содержать свою версию для каждой итерации. Другой способ — дописывать дополнения, которые появляются по мере развития приложения.