Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
81
ГЛАВА 3. ПРОЕКТИРОВАНИЕ
И ДОКУМЕНТИРОВАНИЕ
3.1. Этапы канонического проектирования
Процесс проектирования ПО в соответствии с применяе-
мым в нашей стране ГОСТ 19.102-77 содержит стадии разработки (табл. 3.1).
Таблица 3.1
Стадии разработки по ГОСТ 19.102-77
Стадии
Этапы работ
Содержание работ
1
2
3
1. Техни-
ческое
задание
Обоснование
необходимости
разработки
программы
Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев
эффективности и качества
разрабатываемой программы.
Обоснование необходимости
проведения научноисследовательских работ
Научноисследовательские
работы
Определение структуры входных и
выходных данных
Предварительный выбор методов
решения задач
Обоснование целесообразности
применения ранее разработанных
программ
Определение требований к
техническим средствам
Обоснование принципиальной
возможности решения поставленной задачи
82
Стадии
Этапы работ
Содержание работ
1
2
3
Разработка и
утверждение технического задания
Определение требований к программе
Разработка техникоэкономического обоснования разработки программы
Определение стадий, этапов и сроков разработки программы и документации на нее
Выбор языков программирования
Определение необходимости
Проведения НИР на последующих
стадиях
Согласование и утверждение технического задания
2. Эскизный
проект
Разработка
эскизного проекта
Предварительная разработка
структуры входных и выходных
данных Уточнение методов решения задачи
Разработка общего описания алгоритма решения задачи
Разработка ТЭО
Утверждение
эскизного проекта
Разработка пояснительной записки.
Согласование и утверждение эскизного проекта
3. Технический проект
Разработка технического проекта
Уточнение структуры входных и
выходных данных
Разработка алгоритма решения
задачи Определение формы представления входных и выходных
данных
Определение семантики и синтаксиса языка. Разработка структуры
программы Окончательное определение
конфигурации технических
средств
83
Стадии
Этапы работ
Содержание работ
1
2
3
Утверждение
технического
проекта
Разработка плана мероприятий по
разработке и внедрению программ
Разработка пояснительной записки
Согласование и утверждение ТП
4. Рабочий
проект
Разработка
программы
Программирование и отладка
программы
Разработка
программной
документации
Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77
Испытания
программы
Разработка, согласование и утверждение порядка и методики испытаний
Проведение предварительных
приемосдаточных и других видов
испытаний Корректировка программы и
программной документации по
результатам испытаний
5. Внедрение
Подготовка и
передача
программы
Подготовка и передача программы
и документации для сопровождения
Оформление и утверждение акта о
передаче программы на сопровождение
Передача программы
Каноническое проектирование — это классическое после-
довательное выполнение этапов (стадий) проектирования
(рис. 1.1), в основе которого лежит каскадная модель жизненного цикла ИС. Оно является образцом проектирования 70-х годов
прошлого века, когда проектирование ПО стало жестко регламентироваться. Все его аспекты детально стандартизированы.
Название стадий разработки по ГОСТ 19.102-77 (табл. 3.1)
и их названия как этапов жизненного цикла ПО (рис. 1.1), то они
не совпадают. Таблица 3.2 устанавливает их соответствие по
сути работ, которые подразумевает каждый этап.
84
Таблица 3.2
Соответствие стадий разработки и этапов ЖЦ ПО
Название стадии
по ГОСТ 19.102-77
Название соответствующего этапа жизненно-
го цикла
Техническое
задание
Анализ, прогнозирование и планирование
Эскизный проект
Разработка архитектуры проекта
Проектирование
Технический проект
Детальное проектирование
Рабочий проект
Кодирование
Верификация и аттестация
Внедрение
Внедрение
Напомним, что под каноническим проектированием понимается проектирование оригинальное, предполагающее разработку программного обеспечения (ПО) «с нуля» (см.
разд. «Введение в дисциплину»). Каждая стадия разработки ПО
документируется. На рис. 3.1 указана основная документация,
которая разрабатывается в процессе выполнения каждого этапа.
Предварительные сведения о каждом этапе жизненного
цикла ПО рассматривались в гл. 1. Рассмотрим подробнее первые два этапа (анализ и проектирование) и документацию, их
сопровождающую.
Рис. 3.1. Этапы разработки ПО и поэтапная документация
85
3.2. Этап системного анализа
Это начальный этап разработки любого ПО (см. рис. 1.2),
он состоит из выполнения ряда работ, каждая из которых заканчивается разработкой документа, которые затем обобщаются в
итоговом документе — техническом задании (ТЗ):
а) предпроектные исследования (см. разд. 1.1.1) цель кото-
рых исследовать проблему, потребности заказчика, имеющийся
рынок программных продуктов. В результате делается вывод о
необходимости проведения разработки ПО, или напротив, о нецелесообразности разработки. Эти выводы излагаются в «отчете
об осуществимости»;
б) сбор и анализ требований (см. разд. 1.1.2) проводится,
если на предыдущей стадии был сделан вывод в пользу новой
разработки. Это сложный и ответственный этап. Требования не
только собираются с учетом потребностей всех категорий пользователей, но и:
– систематизируются;
– анализируются на полноту и непротиворечивость;
– упорядочиваются в соответствии с приоритетностью
(приоритет присваивается каждому требованию);
– идентифицируются;
– регистрируются;
– аттестуются.
Итогом этой работы является спецификация требований,
которая с одной стороны составит основу ТЗ (итогового документа системного анализа), а с другой является базой, на которой строятся прогнозы об основных параметрах проекта: разме-
ре, трудоемкости, стоимости и длительности;
в) прогнозирование работ — спецификация требований
анализируется экспертами, которые, основываясь на собственном опыте и на метрических данных от аналогичных проектов
делают прогнозы о величине проекта, его сложности, необходимых работах для его проведения. И составляется ТЭО — техникоэкономическое обоснование;
г) планирование на основе проведенных предварительных
оценок проводится планирование работ и финансовых затрат,
весь объем работ разбивается на этапы, для каждого из которых
86
определяются стоимость, трудоемкость и длительность, а также
в каком виде должны быть предоставлены результаты его выполнения. В итоге формируется календарный график работ.
3.2.1. Техническое задание
Техническое задание определяет проект, а имен, его цели,
требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
ГОСТ 19.201–78 устанавливает порядок построения и
оформления технического задания на разработку программы или
программного изделия для вычислительных машин, комплексов
и систем независимо от их назначения и области применения.
Основные его положения сведены в табл. 3.3.
Таблица 3.3
Разделы ТЗ на разработку ПО по ГОСТ 19.201–78
Наименование
раздела
Содержание
1
2
Введение
Наименование;
Краткая характеристика области применения программы или программного изделия и объекта, в котором
используют программу или программное изделие
Основания для
разработки
Документ (документы), на основании которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения;
Наименование и (или) условное обозначение темы
разработки
Назначение
разработки
Указано функциональное и эксплуатационное
Назначение программы или программного изделия
Требования к программе или программному изделию
Требования к функциональным характеристикам;
(требования к составу выполняемых функций,
организации входных и выходных данных,
временным характеристикам);
87
Наименование
раздела
Содержание
1
2
Требования к надежности; требования к обеспечению надежного функционирования (обеспечения
устойчивого функционирования, контроль входной и
выходной информации, время восстановления после
отказа и т. п.;
Условия эксплуатации (температура окружающего
воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых
должны обеспечиваться заданные характеристики, а
также вид обслуживания, необходимое количество и
квалификация
персонала;
требования к составу и параметрам технических
средств; требования к информационной и программной совместимости;
требования к маркировке и упаковке; требования к
транспортированию и хранению; специальные
требования
Требования к
программной
документации
Предварительный состав программной документации и, при необходимости, специальные требования
к ней
Техникоэкономические
показатели
Ориентировочная экономическая эффективность;
предполагаемая годовая потребность;
экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами
Стадии и этапы
разработки
Необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и
утверждены), а также, как правило, сроки разработки
и определяют исполнителей
Порядок
контроля и приемки
Указаны виды испытаний и общие требования к
приемке работы
В ТЗ допускается
включать приложения
88
Техническое задание (ТЗ) — это основной документ, определяющий соглашение между разработчиком и заказчиком на
разработку ПО. Это единственный документ (кроме акта о приемке проекта), который подписывается как руководством заказчика, так и руководством разработчика. Именно он служит основанием в случае предъявления претензий в суде. И поэтому
следует ответственно относиться к его составлению.
ТЗ читает множество разных людей (рис. 3.2), начиная от
высшего руководства компании заказчика системы и заканчивая
рядовым разработчиком системы.
Если проанализировать содержательную часть, то можно
видеть, что ТЗ основано на:
– спецификации требований к ИС;
– технико-экономическом обосновании (ТЭО);
– плане выполнения работ.
Собственно, план работ часто рассматривают как составную часть ТЭО, но рассмотрим их последовательно. Надо сразу
оговорить, что и план работ, и ТЭО, входящие в состав ТЗ, весьма приблизительны. Они будут дорабатываться и уточняться в
процессе проектирования.
Рис. 3.2. Востребованность ТЗ
89
Для разработки ТЗ надо проделать в полной мере все работы по сбору, анализу и специфицированию требований к разрабатываемой ИС. Методы этих работ описаны в гл. 1, поэтому
рассмотрим подробнее, что подразумевается под ТЭО и планированием работ.
3.2.2. Планирование разработки
Планирование — это составная часть начального этапа ра-
боты над проектом. Итогом планирования является график работ
и ТЭО. Планирование на стадии создания ТЗ носит весьма приблизительный характер и уточняется на всех дальнейших стадиях разработки. Планирование проекта осложняется одновременным участием многих исполнителей, необходимостью параллельного выполнения работ, зависимостью начала многих работ
от результатов других. Может возникнуть вопрос, зачем детально продумывать все аспекты проекта, если прогнозы, построенные на этапе ТЗ, заведомо неточны (в некоторых случаях реальные затраты и длительность разработки проекта отличаются от
предварительной оценки в 4 раза)? Такой вопрос неправомерен,
поскольку без предварительных оценок невозможно заключить
договор на разработку с заказчиком и, следовательно, осуществить проект.
Последовательность работ по планированию представлена
на рис. 3.3.
Рис. 3.3. Последовательность работ по планированию на этапе ТЗ
90
Пооперационный перечень работ
Пооперационный перечень работ (ППР) — это основа
планирования. Он необходим и для разработки графика работ, и
для прогноза размеров стоимости и трудозатрат, то есть для
ТЭО. Обычно он имеет вид многоуровневого списка. Но возможно его составление в виде дерева или с помощью простых
электронных таблиц.
Пример ППР для проекта по созданию С-компилятора:
1.0 Программное обеспечение для С-компилятора (опре-
деление инструментальной среды для разработки, в которой будет создаваться С-компилятор);
1.1 Создание С-компилятора.
1.1.1 Построение пользовательского интерфейса.
1.1.2 Построение файловой системы.
1.1.3 Построение лексического анализатора.
1.1.4 Создание интерфейса кода.
1.2 Построение тестовой оболочки для компилятора.
1.2.1 Прочее.
1.3 Написание документации.
1.4 Создание инсталляционной программы.
1.5 Управление разработкой ПО (то есть всем вышепере-
численным).
ППР отражает иерархию работ, но не их параметры и зависимость друг от друга. Получив ППР, надо провести оценку
работ, а именно, выяснить размер, длительность, стоимость, необходимые для их выполнения ресурсы. Оценка производится
обычно «снизу вверх», то есть все перечисленные параметры
выявляются для нижнего уровня иерархии и суммируются при
переходе на более высокие уровни. Особенностью проекта по
созданию ИС в том, что основные ресурсы — это разработчики
(программисты). Конечно, есть потребность и в других ресурсах,
например, в АО и ПО, которые используются в проекте.
Параллельно с проведением оценок надо исследовать зависимость работ (действий).
Типы зависимостей
Перечень — это иерархический список работ или действий, которые необходимо проделать в рамках проекта. Если
эти действия выполнять строго последовательно, то длитель-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]