Добавлен: 25.10.2018
Просмотров: 4543
Скачиваний: 12
11
После определения ранга всех информационных характеристик системы приступают к расче-
ту функционального размера. Исходные данные для расчета общего количества информационных
характеристик сводят в табл. 2. Полученные в каждой строке значения суммируются, давая итоговое
значение для данной характеристики. Итоговые значения затем суммируются по вертикали, форми-
руя общее количество информационных характеристик.
Таблица 1
Ранг и оценка сложности внешних вводов
Ссылки на файлы
Элементы данных
1-4 5-15 >15
0-1
Низкий (3)
Низкий (3)
Средний (4)
2
Низкий (3)
Средний (4)
Высокий (6)
>2
Средний (4)
Высокий (6)
Высокий (6)
Таблица 2
Исходные данные для вычисления общего количества информационных характеристик
Имя характеристики
Количество
Низкий
Средний
Высокий
Итого
Внешние вводы _
х 3 =
_ х 4 =
_ х 6 =
Внешние выводы _
х 4 =
_ х 5 =
_ х 7 =
Внешние запросы _
х 3 =
_ х 4 =
_ х 6 =
Внутренние логические файлы _
х 7 =
_ х 10 =
_ х 15 =
Внешние интерфейсные файлы _
х 5 =
_ х 7 =
_ х 10 =
Общее количество
Функциональный размер вычисляется по следующей формуле [55, 89]:
FP = Общее количество х (0,65+ 0,01 x
∑
=
14
1
i
i
F
),
(1)
где F
i
– коэффициенты сложности. Каждый коэффициент F
i
в (1) может принимать следующие зна-
чения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное. Значение
каждого i-ого коэффициента определяется эмпирически в результате ответа на 14 вопросов, которые
характеризуют системные параметры приложения (см. табл. 3). В [57:439-444] приводится детальное
описание системных параметров, перечисленных в таблице 3, и даются рекомендации по определе-
нию величины сложности для каждого из них.
Таблица 3
Определение системных параметров приложения
№
Системный параметр
Описание
1 Передача данных
Сколько средств связи требуется для передачи или обмена информаци-
ей с приложением или системой?
2
Распределенная обработка
данных
Как обрабатываются распределенные данные и функции обработки?
3 Производительность
Нуждается ли пользователь в фиксации времени ответа или производи-
тельности?
4
Распространенность ис-
пользуемой конфигурации
Насколько распространена текущая аппаратная платформа, на которой
будет выполняться приложение?
5 Скорость транзакций
Как часто выполняются транзакции? (каждый день, каждую неделю,
каждый месяц)
6 Оперативный ввод данных Какой процент информации надо вводить в режиме онлайн?
7
Эффективность работы ко-
нечного пользователя
Приложение проектировалось для обеспечения эффективной работы
конечного пользователя?
8 Оперативное обновление
Как много внутренних файлов обновляется в онлайновой транзакции?
9 Сложность обработки
Выполняет ли приложение интенсивную логическую или математиче-
скую обработку?
12
№
Системный параметр
Описание
10 Повторная используемость
Приложение разрабатывалось для удовлетворения требований одного
или многих пользователей?
11 Легкость инсталляции
Насколько трудны преобразование и инсталляция приложения?
12 Легкость эксплуатации
Насколько эффективны и/или автоматизированы процедуры запуска,
резервирования и восстановления?
13
Разнообразные условия
размещения
Была ли спроектирована, разработана и поддержана возможность ин-
сталляции приложения в разных местах для различных организаций?
14 Простота изменений
Была ли спроектирована, разработана и поддержана в приложении
простота изменений?
Для оценивания затрат труда и продолжительности проекта рекомендуется использовать кон-
структивную модель стоимости СОСОМО (Constructive Cost Model), предложенную в 1981г. Барри
Боэмом [55, 89]. Подмодели СОСОМО могут применяться к трем типам программных проектов. По
терминологии Боэма, их образуют:
• распространенный тип – небольшие программные проекты, над которыми работает небольшая
группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;
• полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с раз-
ным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;
• встроенный тип – программный проект разрабатывается в условиях жестких аппаратных, про-
граммных и вычислительных ограничений.
Уравнения базовой подмодели COCOMO имеют вид:
Е=а x(KLOC)
b
[чел-мес];
(2)
D = c x (E)
d
[мес],
(3)
где Е – затраты в человеко-месяцах, D – время разработки, KLOC – количество тысяч строк в про-
граммном продукте. Коэффициенты а, b, с, d определяются по табл. 4.
Таблица 4
Коэффициенты для базовой подмодели СОСОМО
Тип проекта
а b c d
Распространенный 2,4
1,05
2,5
0,38
Полунезависимый 3,0
1,12
2,5
0,35
Встроенный 3,6
1,20
2,5
0,32
Для определения числа строк кода (KLOC) используют стандартные таблицы по функцио-
нальному размеру. Например, в таблице 2.13 [89:28] одной единице функционального размера соот-
ветствует 53 строки программного кода на языке программирования Java, 64 строки на С++, 29 стро-
ки на Delphi Pascal.
Из (2) следует, что согласно модели Боэма продолжительность проекта не зависит от количе-
ства привлекаемых для его реализации специалистов, а зависит от функционала и типа системы.
Модель Боэма проста в использовании и широко распространена, однако позволяет получить
весьма грубые оценки. При необходимости использования более точных оценок затрат и времени
разработки рекомендуется обратиться к литературным источникам [18, 21, 23, 32], а также материа-
лам сайтов [20, 25].
Полученные оценки позволят скорректировать сроки выполнения проекта и затраты на его
реализацию. Обсуждение этих результатов совместно с заказчиком может повлиять на итоговую вер-
сию договора.
4.6.2.4 Сбор и анализ данных о зарубежных и отечественных аналогах
Проводят более детальный, чем во введении поиск, анализ и описание архитектуры, техноло-
гических и программных решений систем, аналогичных проектируемой. Цель этого подраздела: под-
твердить актуальность проекта с учетом предъявляемых требований и наложенных ограничений, а
также выявить перечень стандартных компонентов, модулей, пакетов и т.д., использование которых в
проекте без существенных модификаций позволило бы сократить ресурсы на их повторное проекти-
рование.
13
Необходимо показать какие наработки, приемы современных информационных
технологий будут использованы в проекте, а также какие программные компо-
ненты (классы, интерфейсы и т.д.), многократно проверенные (протестирован-
ные) на практике, могут составить основу проекта.
Подходы проектирования информационных систем (ИС), основанные на повторном исполь-
зовании компонентов, к настоящему времени сформировались в несколько крупных направлений и
широко обсуждаются в литературе [42, 62, 101].
На основании проведенного анализа посредством сравнения затрат на проектирование задан-
ной системы и стоимости систем аналогичного класса делается заключение о целесообразности про-
ектирования АСОИУ с параметрами, указанными в задании на КП.
4.7. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ПРОЕКТИРУЕМОЙ АСОИУ (ИМС)
4.7.1 Обследование АСОИУ (ИМС)
4.7.1.1. Исходные материалы и документы по созданию АСОИУ (ИМС)
В данном параграфе проводят систематизацию нормативных документов, определяющих ос-
новные понятия в области автоматизированных систем (АС) и, устанавливающих термины и опреде-
ления [69], основные положения [66], общие требования [67], процессы жизненного цикла [73], ста-
дии создания АС [68, 70] и т.д.
В ПЗ приводят диаграмму, на которой изображают структуру нормативных до-
кументов, использованных при подготовке проекта, а также нормативно-
правовых документов, относящихся к организации, эксплуатации и обслужива-
нию технологического процесса, автоматизации которого посвящен проект.
При анализе нормативных документов необходимо иметь в виду следующее заключение, сде-
ланное специалистами в области стандартизации разработки программных средств [54:61]: «Процес-
сы создания автоматизированных систем (АС), в состав которых входит ПО, регламентированы стан-
дартами ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизирован-
ные системы. Автоматизированные системы. Стадии создания», ГОСТ 34.602-89 «Информационная
технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание
автоматизированной системы» и ГОСТ 34.603-92 «Информационная технология. Виды испытаний
автоматизированных систем». Однако процессы создания ПО для современных распределенных
АИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдель-
ные их положения явно устарели. В результате для каждого серьезного проекта АИС приходится соз-
давать комплекты нормативных и методических документов, регламентирующих процессы создания
конкретного прикладного ПО, поэтому в отечественных разработках целесообразно использовать со-
временные международные стандарты» (выделено автором). В этой связи, при выполнении курсового
проекта рекомендуется, основываясь на структуре ГОСТов 34.xxx, содержательную часть разделов
рассматривать, ориентируясь на стандарты, опубликованные Институтом инженеров по электротех-
нике и радиоэлектронике (Institute of Electrical and Electronics Engineers (IEEE)) [43].
Ввиду ограниченного объема времени, выделенного на курсовое проектирование, номенкла-
тура разрабатываемой технической документации отличается от предусмотренной действующими
нормативными документами и оговаривается в задании на курсовой проект. Минимальный комплект
документации, который необходимо разработать в ходе выполнения курсового проекта включает в
свой состав следующие основные документы [43, 55]:
1. план управления конфигурациями программного обеспечения (Software Configuration Manage-
ment Plan – SCMP) в соответствии со стандартом IEEE 828-1990;
2. план контроля качества программного обеспечения (Software Quality Assurance Plan – SQAP) в
соответствии со стандартом IEEE 730-1989;
3. план управления программным проектом (Software Project Management Plan – SPMP) в соответст-
вии со стандартом IEEE 1058.1-1987;
4. спецификация требований к программному обеспечению (Software Requirements Specification –
SRS) в соответствии со стандартом IEEE 830-1993;
5. техническое задание (ТЗ) в соответствии со стандартом ГОСТ 34.602-89;
6. проектная документация программного обеспечения (Software Design Document – SDD) в соот-
ветствии со стандартом IEEE 1016-1987.
14
4.7.1.2. Обоснование выбора модели жизненного цикла АСОИУ (ИМС)
Ключевую роль в успешной разработке многокомпонентных программно-аппаратных систем
играет организация стадий создания системы во времени. Модели организации жизненного цикла
ИС, появившиеся в конце 80-х, начале 90-х годов (каскадная (водопадной) и спиральная (итерацион-
ная)), в настоящее время находят весьма узкое применение. Вместе с тем, существует несколько со-
временных концепций организации жизненного цикла, которые необходимо проанализировать в раз-
деле «Обоснование выбора модели жизненного цикла АСОИУ».
Особое внимание следует уделить Унифицированному процессу разработки программно-
го обеспечения (Unified Software Development Process - USDP), разработанному сотрудни-
ками компании IBM Corporation [55, 56, 103].
Унифицированный процесс представляет собой попытку объединения водопадной и итера-
тивной моделей ЖЦ. При этом, ЖЦ при использовании USDP разделен на 4 фазы:
1. анализ и планирование требований: (i) создается упрощенная модель вариантов использования,
содержащая наиболее критичные с точки зрения реализации прецеденты; (ii) создается пробный
вариант архитектуры, содержащей наиболее важные подсистемы; (iii) проводится идентификация
и определение приоритетов рисков; (iv) планируется фаза проектирования; (v) грубо оценивается
весь проект в целом;
2. проектирование: детально описываются большинство вариантов использования и разрабатывает-
ся архитектура системы. В конце фазы проектирования менеджер проекта выполняет подсчет ре-
сурсов, необходимых для завершения проекта. Необходимо ответить на вопрос: достаточно ли
проработаны варианты использования, архитектура и план, чтобы можно было бы давать кон-
трактные обязательства на выполнение работы и переходить к подготовке и подписанию «Тех-
нического задания»?;
3. построение – создание продукта. В конце этой фазы продукт включает в себя все варианты ис-
пользования, которые разработчики и заказчик решили включить в текущий выпуск;
4. внедрение – выпуск продукта. Проводится тестирование бета-версии продукта отделом тестиро-
вания компании и одновременно организуется пробная эксплуатация системы пользователями.
После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложен-
ных улучшений в главный выпуск, подготавливаемый для широкого распространения.
Каждая фаза USDP может включать в свой состав одну или несколько итераций в зависимо-
сти от размера проекта (см. рис. 1). На протяжении каждой итерации может выполняться 5 основных
и некоторое количество дополнительных рабочих потоков. К основным рабочим потокам в USDP от-
носятся: определение требований (ОТ); анализ (А); проектирование (П); реализация (Р); тестирование
(Т). К дополнительным рабочим потокам могут относиться: работы по обеспечению качества (К), до-
кументирование (Д), управление проектом (У), управление конфигурацией (УК), создание и управле-
ние инфраструктурой (И) и другие.
Фазы
Анализ и
планирование
требований
Итер 1
Итер 2
Итерации
ОТ
А П Р Т
Основные
рабочие потоки
К Д
Дополнительные
рабочие потоки
Проектировние
Итер 3
Построение
Итер 4
Итер 5
Внедрение
Итер 6
Рис. 1. Модель ЖЦ согласно унифицированного процесса разработки ПО
Не смотря на популярность унифицированного процесса разработки программного обеспече-
ния, ставшего в настоящее время классическим, появляются новые подходы к организации и управ-
лению процессом разработки, объединяющие в себе накопленный при использовании USDP опыт, а
также использующие ряд новых инструментов и идей (например, ICONIX Process [40], экстремальное
программирование (Extreme Programming) [50, 52], быстрая разработка ПО (Agile Software
Development) [3], интегрированные методики [26, 44], технологии мультиагентных систем [22] и др.).
На страницах ПЗ необходимо с использованием литературных источников [3, 22,
26, 40, 44, 50, 52] проанализировать основные концепции процесса создания ПО,
выбранного в качестве базы для выполняемого курсового проекта.
15
Принятая к использованию в проекте модель организации жизненного цикла системы впо-
следствии должна найти отражение при составлении плана управления программным проектом (см.
п. 4.7.1.5).
4.7.1.3. План управления конфигурациями
Управление документацией программного проекта требует значительных организационных
навыков, поскольку документация крупного проекта представляет собой сложноорганизованную сис-
тему документов с множеством перекрестных связей, которая подвержена непрерывным изменениям
в ходе выполнения проекта.
Управление документацией подразумевает поддержание ее полноты, согласованности и
включает в себя управление конфигурациями.
Полнота документации обуславливается перечнем стандартов, использованных при разработ-
ке проекта.
Согласованность документации означает, что набор документов не содержит внутренних про-
тиворечий.
Обеспечение непротиворечивости достигается за счет создания целостной докумен-
тации, т.е. такой документации, в которой каждая спецификация располагается
только в одном месте.
Решение проблемы несогласованности возможно за счет использования гипертекстовых до-
кументов с поддержкой перекрестных ссылок.
Поддержка конфигурации – это координация различных версий и частей документации и про-
граммного кода. Для отслеживания частей проекта необходимо определить их границы, т.е. ввести
элементы конфигурации под которыми, как правило, понимают классы, значимые наборы данных,
редко - отдельные функции. Существуют специальные программные средства для управления конфи-
гурацией (например, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM
Rational ClearCase, Subversion и др.). Обычно системы управления конфигурациями удовлетворяют
следующим минимальным требованиям [55, 93]:
• возможность определения элементов конфигурации;
• отказ в праве на модификацию для предотвращения одновременной работы более чем одного че-
ловека над элементом конфигурации;
• авторизация доступа с правом модификации;
• процедура включения в проект;
• запись о предыдущих группировках согласующихся элементов конфигурации.
На страницах ПЗ необходимо с использованием литературных источников [53,
60, 93] проанализировать возможности, достоинства и недостатки наиболее рас-
пространенных систем управления конфигурацией и выбрать одну из них по
следующей общей методике.
Приведенная далее последовательность шагов может быть использована при решении задачи вы-
бора любой инструментальной системы (языка программирования, СУБД и т.д.) из нескольких аль-
тернатив:
1. Выявляются базовые показатели выбираемой системы, значимые при проектировании заданной
АСОИУ с учетом ее особенностей, ограничений, ресурсов и т.д.
2. Все показатели сводятся в таблицу (см. табл. 5), в которой на основании экспертных оценок каж-
дому показателю назначается весовой коэффициент V
j
(например, от 1 до 10), характеризующий
значимость данного показателя по сравнению с остальными. Сумма значений всех весовых ко-
эффициентов должна равняться его верхней границе (в рассматриваемом примере - 10).
3. С использованием данных, полученных из литературных источников и/или от экспертов, по каж-
дому j-ому показателю для каждой i-ой системы определяется степень полезности U
i,j
(от 1 – ми-
нимальная, до 10 - максимальная). Например, степень полезности системы управления конфигу-
рациями, стоимость которой является сравнительно высокой, может равняться 1, тогда как сте-
пень полезности свободно-распространяемой системы будет равна 10.
4. Для каждой i-ой сравниваемой системы вычисляется значение оценочной функции по формуле:
F
i
= V
1
x U
i,1
+ V
2
x U
i,2
+ …=∑ V
j
x U
i,j
5. На основании значения оценочной функции делается вывод о целесообразности использования
той или иной системы в данном проекте при учете выбранных критериев и заданных ограниче-
ний. Та система, для которой значение оценочной функции окажется больше, является лучшей из
числа сравниваемых альтернатив.