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

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

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

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

Создание даже небольшого и технически простого программного обеспечения зависит от четкого выполнения каждой фазы, то есть деятельности всех отделов, задействованных в процессе разработки. Четкий план выполнения необходимых мероприятий с указанием конечных целей становится неотъемлемой частью работы разработчиков, которые планируют оставаться широко востребованными на рынке труда специалистами. Только правильно составленное техническое задание позволит добиться нужного результата и осуществить разработку по-настоящему качественного и конкурентного программного обеспечения для любой платформы — серверной, стационарной или мобильной [17].

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

Глава 2. Проектирование программного обеспечения

---

2.1. Моделирование бизнес-процессов

Перед разработкой программного средства необходимо проанализировать бизнес-процессы, которые осуществляются в организации. Выделение процессов и их формальное описание в одной из стандартных нотаций позволяет проводить анализ деятельности предприятия и сравнивать различные варианты реорганизации деловых процессов [26].

Моделирование позволяет:

• представлять всю информацию о бизнес-процессах в понятном и удобном, обычно графическом, виде;
• осуществлять непосредственную on-line-связь всех исполнителей бизнес-процесса друг с другом;
• передавать изменяющуюся информацию об исполнении отдельных операций бизнес-процесса всем заинтересованным исполнителям бизнес-процесса;
• -использовать электронные средства защиты информации при передаче и хранении данных, с возможностью установки персональных паролей и уровней доступа к информации [7, 10].

Термин «моделирование» может применяться применяется в двух значениях:

• как процесс изучения модели ее функционирования;
• как процесс создания модели системы.

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

• анализ, оценка и внесение предложений, направленных на оптимизацию функционирования организации;
• подготовка и проведение сертификации организации согласно требованиям качества ISO серии 9000:2000.
• разработка АСУ организацией, проекта запуска комплексной информационной системы организации.

Концептуальные вопросы моделирования решаются в форматах международных стандартов качества ISO серии 9000:2000, ключевым объектом которых является процесс, который является логичным, последовательным, взаимосвязанным набором мероприятий, потребляющим ресурсы, создающим ценность и выдающим результаты. Моделирование бизнес-процессов является эффективным средством поиска путей оптимизации работы организации, дающим возможность определения, как компания функционирует в общем и как организована работа на всех рабочих местах.

На практике моделирование бизнес-процессов организации включает два этапа - структурное и детальное. Наиболее популярная методология структурного моделирования IDEF – это методология IDEF0. Методология IDEF0 может считаться новым этапом в развитии хорошо известного графического языка описания функциональных систем SADT. IDEF0 как стандарт разработали в 1981 г. в рамках широкой программы автоматизации предприятий промышленности, называвшейся ICAM. Семейство стандартов IDEF собственное обозначение унаследовало от наименования данной программы, и его последнюю редакцию выпустил в декабре 1993 г. Национальный Институт по Стандартам и Технологиям Соединенных Штатов Америки (NIST). В Российской Федерации приняты официальные рекомендации по использованию IDEF0 [5].

---

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

Структурным моделированием бизнес-процесса отражается следующее:

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

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

Модели в нотации IDEF0 необходимы для высокоуровневого описания бизнеса фирмы в функциональном аспекте. Нотация DFD дает возможность отражения последовательности работ, которые выполняются по ходу процесса, и потоков сведений, циркулирующих между данными работами [1].

Цель методологии IDEF0 – построить функциональную схему исследуемой системы, которая описывает все необходимые процессы с точностью, которой достаточно для однозначного моделирования деятельности системы. В IDEF0 моделируемую систему представляют как совокупность взаимосвязанных работ (функций, активностей). Методология IDEF0 широко распространилась в бизнес-моделировании, так как данная методология легко представляет управление, обратную связь, исполнителей. Помимо этого, методология IDEF0 обладает развитыми процедурами поддержки коллективной работы.

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

Функциональный блок (activity box) является определенной функцией (активностью) в рамках изучаемой системы. Блок нужно называть в глагольном наклонении (к примеру, "Проверить документ" либо же "Проверка документа"). Пример функционального блока представлен на диаграмме прямоугольником.

---

Каждая из 4-х сторон функционального блока обладает своим определенным значением (ролью) и определяет тип интерфейса, то есть способы взаимодействия дуги и блока:

• верхняя сторона обладает значением "Управление" (control) – определяет управляющие элементы бизнес-процесса;
• левая сторона обладает значением "Вход" (input) – указывает ресурсы: которые находятся на входе в модель;
• правая сторона обладает значением "Выход (output) – отображает элементы, которые являются результатом работы процесса;
• нижняя сторона обладает значением "Механизм" (mechanism) – показывает объекты, которые задействованы в выполнении бизнес-процесса.

Дуга (arrow) отображает компонент системы, который обрабатывает функциональный блок или иным образом влияет на функцию, представленную этим функциональным блоком. Интерфейсные дуги нередко называются потоками или стрелками [5].

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

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

Вход (input) - материальные объекты либо данные, применяемые или преобразовываемые работой с целью получения результата (выхода). Допустимо, что у блока может не быть ни одной стрелки входа.

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

Управление (control) - правила, процедуры, стратегии, стандарты, временные и бюджетные ограничения, из которых исходит работа. Каждая работа должна обладать хотя бы одной стрелкой управления. Управление оказывает влияние на работу, но работой не преобразуется. При возникновении неопределенности в статусе стрелки (вход или управление) нужно отрисовать стрелку управления.

Выход (output) - информация или материальный объект, которые производит деятельность. Каждая активность должна обладать хотя бы одной стрелкой выхода. Работа без результата бессмысленна и ее не нужно моделировать.

---

Механизм (mechanism) - ресурсы, выполняющие работу, к примеру сотрудники организации, станки, устройства и т. д. На усмотрение проектировщика стрелки механизма в модели могут не отображаться.

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

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

Декомпозиция (decomposition) – ключевое понятие стандарта IDEF0. Принцип декомпозиции применяют в процессе разбиения сложного процесса на составляющие его функции. Декомпозиция дает возможность постепенного и структурированного представления модели системы в форме иерархической структуры отдельных диаграмм, за счет чего она становится менее перегруженной, а также легко усваиваемой [7].

Глоссарий (glossary) является набором соответствующих ключевых слов, определений, повествовательных изложений и т. п., описывающих объект, который отображает данный элемент. Данный набор – описание сущности этого элемента. Глоссарием дополняется наглядный графический язык, диаграммы получают необходимую дополнительную информацию.

Модель в методологии IDEF0 является совокупностью взаимосвязанных и иерархически упорядоченных диаграмм. Каждая диаграмма – это единица описания системы, она располагается на отдельном листе. В модели могут быть 4 типа диаграмм:

1. Контекстная диаграмма, представляющая всю систему в качестве одного блока и показывающая контекст системы, то есть связь системы с внешним миром. Модель может обладать только одной контекстной диаграммой.
2. Диаграммы декомпозиции, получаемые после разбиения контекстной диаграммы на отдельные активности. Данный процесс называют функциональной декомпозицией, а диаграммы, которые получились после декомпозиции, называют диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводят декомпозицию каждой получившейся диаграммы и т.п.
3. Диаграммы дерева узлов отражают иерархическую зависимость работ. Т. е., в форме дерева отражается, какие активности были получены после декомпозиции каждой активности.
4. Диаграммы только для экспозиции (FEO - for exposition only). Их построение осуществляется с целью отображения альтернативной точки зрения, с целью хранения старых версий. FEO является обычной картинкой. Суть в том, что альтернативные варианты декомпозиции не поддерживает методология. Если требуется каким-либо образом сохранить альтернативный вариант декомпозиции, то используется диаграмма только для экспозиции.

---