Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
91
ность проекта будет максимально большой. Если выполнять их
параллельно, то она будет минимальна. Параллельное выполнение идеально подходит для тех работ, которые никак не зависят
друг от друга. Но оно возможно далеко не для всех работ. Потому что между работами (или действиями) существуют зависимости. Прежде, чем строить график работ надо определить типы
зависимостей между ними.
Зависимости можно классифицировать на управляемые
ресурсами и на управляемые действиями. Под ресурсами в случае разработки ПО в основном понимается персонал (команда
разработчиков, например).
Часто определенное действие не может быть начато потому, что работник, который должен его выполнять, занят работой
над другим действием. Аналогично часто действие не может
быть начато, пока не закончены какие-то другие действия, которые подготавливают условия для начала данного действия. Типы
зависимостей проиллюстрированы на рис. 3.4–3.7.
Рис. 3.4. Взаимосвязь финиш — старт
Рис. 3.5. Взаимосвязь старт — старт
92
Рис. 3.6. Взаимосвязь финиш – финиш
Рис. 3.7. Взаимосвязь старт — финиш
Реальные зависимости, конечно, не так просты. У них
могут быть и дополнительные характеристики, например, все
перечисленные типы зависимостей могут быть запаздывающими
и опережающими. На отставание обычно указывает положительное число, а на опережение — отрицательное. На рис. 3.8
демонстрируется действие В, которое выполняется через 10 дней
после завершения действия А, а действие Б может начать выполняться немедленно.
Рис. 3.8. Запаздывающая взаимосвязь
93
Рабочий график
Рабочий график — один из элементов планирования. С его
помощью можно избежать неопределенности и продуктивно
распределить рабочее время. Обычно рабочий график в процессе
работы над проектом часто обновляется.
Он строится на базе ППР, диаграмм зависимостей работ и
с учетом наличия ресурсов. Наиболее распространены рабочие
графики в виде диаграмм Ганта и сетевых диаграмм.
Название
задачи
Ресурсы
2010
2011
I
II
III
IV I II
III
IV
Фаза 1 —
подготовка
1.1…
1.2…
1.3…
Фаза 2 —
развитие
2.1…
2.2…
2.3…
…
Фаза N
…
N.M Завершить
проект
Рис. 3.9. Диаграмма Ганта
Диаграмма Ганта. Чаще всего для представления графика
работ используется диаграмма Ганта, которую еще иногда называют гистограммой. Она была изобретена Генри Гантом во время Первой мировой войны и первоначально использовалась для
составления графиков отправки солдат и техники из тыла на побережье США, откуда они должны были переправляться в Европу.
94
Фактически этот вид диаграмм (рис. 3.9) хорошо известен
даже тем, кто никогда не сталкивался с разработкой каких-либо
проектов.
На простой диаграмме Ганта слева перечислены производственные действия (они должны быть отсортированы по дате
начала или по какому-либо другому параметру), а справа — полоски, длина которых соответствует длительности выполнения
каждого этапа.
Сетевые диаграммы. Очень распространены методы сетевого планирования и управления. Они основаны на сетевых
моделях, допускающих использование современной вычислительной техники, позволяющих быстро определить последствия
различных вариантов управляющих воздействий и находить
наилучшие из них. Существует несколько различных методов
построения сетевых диаграмм:
– GERT-метод графической оценки и обзора; PERT — метод программной оценки и обзора; СРМ — метод критического
пути;
– PDM-метод предшествования;
– ADM-метод стрелочных диаграмм.
Рассмотрим метод СРМ. Он был изобретен в 1950-х годах.
Под методом CPM подразумевается общий процесс анализа с
использованием сетевых диаграмм. Он наиболее простой, так
как в нем предполагается, что фиксирована как продолжительность действий, так и логика определения приоритетов.
В общем виде сетевая диаграмма представляет собой
набор узлов и стрелок. В ней (рис. 3.10) содержится следующая
информация:
– название действия или идентификатор узла (при этом часто используется код ППР);
– время наискорейшего начала производственного этапа,
которое определяется на основании времени завершения предыдущего действия или какого-либо другого ограничения (например, даты, фиксированной в проекте);
– время быстрейшего завершения действия;
– продолжительность этапа (количество временных периодов, необходимых для выполнения работы);
95
– максимально возможный срок, когда действие может
быть завершено, не затронув стадию следующего действия.
Рис. 3.10. Представление узла на сетевой диаграмме
На сетевых диаграммах (рис. 3.11) хорошо прослежива-
ется старшинство узлов. В этом и заключается их основное преимущество.
Рис. 3.11. Сетевая диаграмма
Можно легко проследить порядок совершения действий
слева направо и увидеть взаимосвязь между различными последовательностями узлов. Подобные диаграммы широко исполь-
96
зуются при разработке проектных планов «с нуля», когда отсутствует даже шаблон структуры ППР.
Недостаток этих диаграмм аналогичен недостатку диаграмм Ганта и других графических представлений: в больших
проектах с огромным количеством действий они становятся
очень громоздкими и неудобочитаемыми. Тем не менее, сетевые
диаграммы очень удобны на начальном этапе планирования, а
также при разработке ППР.
3.2.3. Прогнозирование
ТЗ включает в том числе ряд показателей, которые нельзя
измерить для проекта, разработка которого еще только предстоит, а можно только прогнозировать. Основой для прогноза является опыт экспертов и (или) метрические данные об аналогичных проектах, которые уже разработаны.
Количественные характеристики
Основные количественные показатели проекта:
1) размер кода (измеряется количестве строк кода LOC —
Lines Of Codes);
2) трудозатраты (измеряется в чел. ч., чел. мес., чел. год);
3) стоимость, то есть размер необходимого финансирова-
ния (в рублях, долларах, евро);
4) длительность работы над проектом (в днях, месяцах, го-
дах).
Прогнозирование показателей 2–4 базируется на предполагаемом размере проектируемой ИС.
В свою очередь, размер ИС оценивается экспертами на основании как опыта собственных разработок, так и метрических
данных о уже разработанных ИС. Эти оценки предваряются составлением пооперационного перечня работ (ППР). На рис. 3.12
показана последовательность прогнозирования основных параметров проекта.
97
Рис. 3.12. Последовательность оценки
количественных характеристик проекта
Итак, размер ПО есть та отправная точка, от которой производятся остальные прогнозы базовых количественных характеристик проекта. Основой прогноза размера являются метрические данные. Метрические данные — это разнообразные сведения о ранее разработанных системах, как минимум, об их размерах, стоимости, трудоемкости, времени разработки.
Желательно сохранять сведения о допущенных при разработке ошибках, а именно, на каком этапе ошибка допущена, на
каком выявлена причина ее возникновения, стоимость ее устранения, время, требуемое на устранение, и другие сведения.
Как эксперты, так и разработчики используют метрические сведения, и чем большим объемом таковых они располагают, тем выше будет точность их оценки.
При планировании строительства Бруклинского моста
точность оценки по стоимости и времени разработки была ±1 %.
При прогнозировании затрат и времени разработки ПО начальное планирование не может быть точнее более чем в четыре раза. Причина этого в том, что мосты человечество строит не одну
тысячу лет, а программирует от силы лет 50, и, значит, накопленные метрические данные по строительству мостов несопоставимы с данными о программных продуктах.
98
Тем не менее оценки производить необходимо, так как без
предварительных оценок не будет производиться финансирование работ.
Для повышения точности экспертных оценок можно использовать три оценки, то есть эксперт дает оценку с его точки
зрения:
– максимальную;
– минимальную;
– реальную.
Например, прогнозируемая оценка:
Так как исходный код может быть в разных языках программирования, для учета сравнительной сложности работ введена единица SLOC, то есть количество строк в базовом
Assembler(e) (табл. 3.4).
Таблица 3.4
Соответствие LOC и SLOC для разных языков
программирования
Язык
SLOC (Basic
Assembler)
Средний показатель SLOC
на 1 функциональную точку
Basic Assembler 1 320
С \ C++
1,5 \ 6
320 \ 53
Basic
3
107
FORTRAN 3 105–106
PROLOG 5 64
JAVA
6
53
Pascal \ DELPHI
3,5 \ 11
91 \ 29
Языки 4 поколения
16
20
Языки б/д SQL
25
13–16
EXCEL (языки
электронных таблиц)
50
6
99
При подсчете LOC используются правила:
1) строка кода содержит только один оператор;
2) учитываются все выполняемые операторы;
3) определение данных учитывается один раз;
4) не учитывается отладочный (временный) код.
Зная примерный размер проекта, можно сделать приблизительные оценки его базовых количественных характеристик.
Все они носят эмпирический характер, то есть получены на базе
анализа опыта уже состоявшихся разработок.
Для примера рассмотрим оценку трудозатрат:
Трудозатраты = а (размере)b,
где a, b — эмпирические константы.
Собственно, формула не содержит других переменных,
кроме «размера кода», что может показаться странным, ведь
каждому, имеющему опыт программирования хотя бы в рамках
школьного курса информатики, ясно, что создание разных по
сложности программ требует разных усилий. Но дело в том, что
влияние сложности проекта учтено в значениях констант, то есть
a и b зависят от сложности проекта.
Рассмотрим, как сложность проекта влияет на вычисляемые значения на примере.
Пример. Для простого проекта, размер которого составля-
ет 200 kLOC, — а = 2,4, b = 1,05, и, значит:
Трудозатраты = 2,4(200)
1,05
= 2,4260,66 = 626 чел. мес.
Но если проект очень сложный, то для него а = 3,6, b = 1,2,
и, значит, при том же размере в 200 kLOC трудозатраты возрастают в 3,3 раза:
Трудозатраты = 3,6(200)
1,2
= 2077 чел. мес.
Технико-экономическое обоснование (ТЭО)
ТЭО есть анализ, расчет, оценка экономической целесообразности осуществления предлагаемого проекта. ТЭО основано
100
на сопоставительной оценке затрат и результатов, установлении
эффективности использования, срока окупаемости вложений.
ТЭО содержит расчет стоимости разработки ПО с момента
получения первого варианта ТЗ и заканчивая оформлением документации и сдачей проекта.
В ТЭО должна быть обоснована экономическая эффективность разработки.
Кроме этого, ТЭО может включать:
– характеристику исходных данных о предметной области;
– обоснование цели создания ЭИС;
– обоснование автоматизируемых подразделений, комплекса автоматизируемых задач, выбора комплекса технических
средств, программного и информационного обеспечения;
– разработку перечня организационно-технических мероприятий по проектированию системы;
– выводы о техническом уровне проекта и возможности
дальнейших разработок.
На этапе разработки ТЗ проводятся предварительные расчеты по ТЭО, которое является одним из разделов ТЗ. Расчеты
потом уточняются на стадиях эскизного, технического и рабочего проектирования.
3.3. Этап проектирования (синтез системы)
Проектирование — следующий после системного анализа
этап. Смысл этого этапа в общих чертах описан в п. 1.2. и
табл. 3.1. На этом этапе сначала создается эскизный проект, цель
которого — разработать архитектуру проекта.
Как правило, разрабатываются четыре архитектурные модели.
1. Статическая структурная модель, в которой представ-
лены подсистемы или компоненты, разрабатываемые в дальнейшем независимо.
2. Динамическая модель процессов, в которой представ-
лена организация процессов во время работы системы.
3. Интерфейсная модель, которая определяет сервисы,
предоставляемые каждой подсистемой через общий интерфейс.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]