Файл: Основы проектирования программ. Этапы создания программного обеспечения.pdf

В результате разработки рабочего проекта системы получается комплект документов, в состав которого входят:

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

2.2 Свойства модели программного продукта

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

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

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

Рисунок 14. Закрытость модулей программных продуктов.

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

Таким образом можно заключить, что принцип информационной закрытости означает следующее:

• все модули программного продукта являются независимыми, они обмениваются только теми данными, которые необходимы для их работы;
• доступ к операциям и структурам данных модуля ограничен.

К достоинствам применения принципа информационной закрытости относятся:

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

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

Связность модуля (Cohesion) – это свойство, показывающее меру зависимости модулей программного продукта друг от друга. Связность — это внутреннее свойство модуля. Степень связности модуля является прямо пропорциональной результату проектирования.

Для измерения степени связности модулей используют понятие силы связности (СС). Различают 7 степеней связности:

1. Связность по совпадению (СС=0) – когда в модуле отсутствуют явно выраженные внутренние связи.
2. Логическая связность (СС=1) – когда части модуля объединены по принципу функционального подобия.
3. Временная связность (СС=3) – когда части модуля не являются связанными, но необходимы в один и тот же период работы системы.
4. Процедурная связность (СС=5) – когда части модуля связаны порядком выполняемых действий, реализующих некий сценарий поведения.
5. Коммуникативная связность (СС=7) – когда части модуля связаны по данным (работают с одной и той же структурой данных).
6. Информационная (последовательная) связность (СС=9), в которой выходные данные одной части используются как входные в другой части модуля.
7. Функциональная связность (СС=10), в которой части модуля вместе реализуют одну функцию.

Определить степень связности модуля можно по следующему алгоритму:

1. Если модуль является единичной проблемно-ориентированной функцией, то уровень связности является функциональным.
2. Если действия внутри модуля связаны, то перейти к пункту 3. Если действия внутри модуля никак не связаны, то перейти к пункту 6.
3. Если действия внутри модуля связаны данными, то перейти к пункту 4. Если действия внутри модуля связаны потоком управления, перейти к пункту 5.
4. Если порядок действий внутри модуля важен, то уровень связности — информационный. В противном случае уровень связности — коммуникативный.
5. Если порядок действий внутри модуля важен, то уровень связности — процедурный. В противном случае уровень связности — временной.
6. Если действия внутри модуля принадлежат к одной категории, то уровень связности — логический. Если действия внутри модуля не принадлежат к одной категории, то уровень связности — по совпадению.

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

1. Правило параллельной цепи: Если все действия модуля имеют несколько уровней связности, модулю присваивают самый сильный уровень связности.
2. Правило последовательной цепи: Если действия в модуле имеют разные уровни связности, то модулю присваивают самый слабый уровень связности.

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

Количественно сцепление измеряется степенью сцепления (СЦ). Различают следующие виды сцепления:

1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В. Все входные и выходные параметры вызываемого модуля – простые элементы данных.
2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных.
3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В, посылая ему управляющие данные.
4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.
5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных.
6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (через его точку входа).

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

Рисунок 15. Иерархическая структура программной системы.

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

• Высотой называют количество уровней управления;
• Шириной называют максимальное из количеств модулей, размещенных на уровнях управления.

Локальными характеристиками модулей структуры являются коэффициент объединения по входу и коэффициент разветвления по выходу.

Заключение

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

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

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

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

Список литературы

1. ISO/IEC 10746-2:1996, Information technology — Open Distributed Processing — Reference Model: Foundations.3.2.5.
2. ISO/IEC 15288:2008 «Разработка систем и программного обеспечения – Процессы жизненного цикла систем».
3. ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы».
4. Беккер Й., Велкова Л. Менеджмент процессов. / Й. Беккер, Л. Велкова - М.: Эксмо, 2014. 384с.
5. Венделева М.А. Информационные технологии управления: учебное пособие для бакалавров: по специальности «Менеджмент организации» / М.А. Венделева, Ю.В. Вертакова. - Москва : Юрайт, 2012. 462 с.
6. Киселев Г.М. Информационные технологии в экономике и управлении: учебное пособие для вузов / Г.М. Киселев, Р.В. Бочкова, В.И. Сафонов. - Москва : Дашков и К, 2012. 268 с.
7. Корнейчук Б.В. Информационная экономика: учеб. пособие / Б.В. Корнейчук. - Санкт-Петербург [и др.] : Питер, 2016. 394 с.
8. Ловцев Д.А. Информационная теория эргасистем. / Д.А. Ловцев. М.: ВАРВСН, 2013. 124 с.
9. Меняев. М.Ф. Основы разработки программного обеспечения / М.Ф. Меняев. — М.: Омега-Л, 2015. 458 с.
10. Острейковский, В.А., Полякова, И.В. Информатика. Теория и практика / В.А. Острейковский, И.В. Полякова. — М.: Оникс, 2014. 608 с.
11. Попов, В.Л. Управление инновационными проектами: Учебное пособие / В.Л. Попов. - М.: Инфра-М, 2013. 336 с.
12. Пятков М.А. Экономика информационных технологий / М.А. Пятаков М.:Наука, 2012. 335 с.
13. Романова Ю.Д. Информатика и информационные технологии / Ю.Д. Романова. — М.: Эксмо, 2014. 592 с.
14. Румянцева, Е.Л., Слюсарь, В.В. Информационные технологии / Е.Л. Румянцева, В.В. Слюсарь. - М.: Инфра-М, 2007. 256 с.
15. Соболь Б.Ф. Информатика / Б.В. Соболь. - Ростов-на-Дону: Феникс, 2013. 446 с.
16. Степанов, А.Н. Информатика/А.Н. Степанов. - СПб.: Питер, 2016. 684с.
17. Тронин Ю.Н.Информационные системы и технологии в бизнесе / Ю.Н. Тронин. - Москва : Альфа-Пресс, 2015. 236 с.
18. Хакен Г. Информация и самоорганизация/Г.Хакен. М.: Мир, 2013. 240с.
19. Хубаева Г.Н. Информатика / Г.Н. Хубаева. - Ростов-на-Дону: МарТ, 2012. 288 с.
20. Шуремов, Е.Л., Чистов Д.В., Лямова Г.В. Информационные системы управления предприятиями / Е.Л. Шуремов, Д.В. Чистов, Г.В. Лямова. - М.: Изд-во «Бухгалтерский учет», 2012. 112 с.