Совершенствование процесса разработки средств автоматизации управления на ЗАО "Авиастар-СП"

ВВЕДЕНИЕ

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

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

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

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

Вместе с тем, в жёстких условиях растущей конкуренции многие предприятия вынуждены всё больше средств и усилий направлять на совершенствование своей деятельности, увеличение эффективности использования всех своих ресурсов с одновременным повышением качества выпускаемых изделий и услуг. Кроме того, совершенствование как улучшение работы каких-то отдельных элементов в общей системе производства стало недостаточно. Новым шагом в этом направлении стало рассмотрение объекта совершенствования с точки зрения процесса. Такой процессный подход был заложен и в новой редакции стандарта ИСО 9000.

Таким образом, необходимость совершенствования процессов разработки программных средств автоматизации управления промышленным предприятием является обоснованной.

Объектом исследования является предприятие ЗАО «Авиастар-СП», специализирующееся на производстве самолётов.

Предметом исследования работы является процесс разработки средств автоматизации управления (САУ).

Целью дипломной работы является исследование и определение направлений совершенствования процесса разработки САУ на предприятии ЗАО «Авиастар-СП».

В соответствии с обозначенной целью в данной работе необходимо решить следующие задачи:

1. Дать характеристику процесса разработки САУ на промышленном предприятии;

2. Исследовать способы описания моделей и направления анализа процесса разработки;

3. Провести исследование подходов к совершенствованию процесса разработки;

4. Провести анализ существующего на предприятии ЗАО «Авиастар СП» процесса разработки САУ;

5. Определить основные направления и разработать план мероприятий по совершенствованию данного процесса на предприятии;

6. Провести анализ рисков внедрения предложенного плана мероприятий;

7. Провести расчёт эффективности от внедрения предложенного плана мероприятий.

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

1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ СОВЕРШЕНСТВОВАНИЯ ПРОЦЕССА РАЗРАБОТКИ СРЕДСТВ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ НА ПРОМЫШЛЕННОМ ПРЕДПРИЯТИИ

1.1. Характеристика средств автоматизации управления на промышленном предприятии

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

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

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

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

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

Программы, работающие на компьютере, можно разделить на три категории:

1. Системные программы,

2. Прикладные программы,

3. Инструментальные системы.

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

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

Примерами могут быть ОС MS DOS фирмы Microsoft, ОС Windows фирмы Microsoft в различных версиях, ОС OS/2 3.0 Warp фирмы IBM. В деловой сфере на рабочих местах часто используется ОС Windows NT Workstation.

Важным классом системных программ являются драйверы. Они расширяют возможности ОС, например, позволяя ей работать с тем или иным внешним устройством, обучая её новому протоколу обмена данными и т.д. Так, первоначально попавшие в нашу страну версии DOS, Windows и OS/2 были английскими и не поддерживали ввод русских букв с клавиатуры. Поэтому, различные программисты создали драйверы, обеспечивающие эти средства.

Весьма популярный класс системных программ составляют программы-оболочки. Они обеспечивают более удобный и наглядный способ общения с компьютером, чем штатные средства ОС. Наиболее популярными программами-оболочками для DOS являются Norton Commander, XTree Pro Gold и др. Имеются удобные программы-оболочки и для Windows.

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

-программы резервирования,

-антивирусные программы,

-программы-упаковщики (архиваторы),

-программы-русификаторы,

-программы для диагностики компьютера,

-программы-кэши,

-программы для оптимизации дисков,

-программы динамического сжатия,

-программы ограничения доступа и др.

Прикладные программы обеспечивают непосредственное выполнение необходимых пользователем работ: редактирование текстов, рисование картинок, обработку информационных массивов и т.д. Для IBM PC разработаны и используются сотни тысяч различных прикладных программ для различных применений. Наиболее широко применяются программы:

-подготовки текстов (документов) на компьютере - редакторы текстов,

-обработки табличных данных - табличные процессоры,

-подготовки документов типографского качества - издательские системы,

-обработки массивов информации - системы управления базами данных,

-подготовки презентаций (слайд-шоу),

-программы экономического назначения - бухгалтерские программы, программы финансового анализа, правовые базы данных и т.д.

-системы автоматизированного проектирования (САПР) и др.

Для целей исследования рассмотрим системы управления базами данных (СУБД) более подробно. Они позволяют управлять большими информационными массивами - базами данных. Простейшие СУБД позволяют обрабатывать на компьютере один массив информации, например, персональную картотеку. Более сложные СУБД поддерживают несколько массивов информации и связи между ними, то есть могут использоваться для задач, в которых участвует много различных видов объектов, связанных друг с другом различными отношениями. Обычно эти СУБД включают средства программирования, но многие из них удобны и для интерактивного применения. Так, весьма мощны и довольно легки в использовании СУБД Lotus Approach, DataEase, Paradox. При необходимости разработки небольших информационных систем часто применяются Microsoft Access, FoxPro, Clarion и др. Для создания больших многопользовательских информационных систем лучше подходят СУБД типа клиент - сервер. В них сама база данных располагается на мощном компьютере - сервере, который принимает от программ, выполняемых на других компьютерах - клиентов, - запросы на получение той или иной информации из базы Данных или осуществление тех или иных манипуляций с данными. Среди таких СУБД широко используются Oracle, Microsoft SQL Server , Sybase SQL Server, Informix и др. Более подробно СУБД рассматривается ниже.

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

Одним из базовых понятий при исследовании сущности программных средств автоматизации управления (САУ) является понятие жизненного цикла (ЖЦ ) ПО.

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации [7, с. 23].

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

-каскадная модель (70-85 г.г.);

-спиральная модель (86-90 г.г.).

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

Вендров А.М. в своей работе «CASE-технологии. Современные методы и средства проектирования информационных систем» [7, с. 41] предложил следующие этапы разработки ПО при каскадном подходе: анализ, проектирование, реализация, внедрение, сопровождение.

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

Положительные стороны применения каскадного подхода заключаются в следующем [6, с. 56 ]:

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

-выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

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

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

Для преодоления перечисленных проблем появилась спиральная модель ЖЦ [6, с. 62], делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

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

Под базой данных будем понимать совокупность объектов и их взаимоотношений, обеспечивающая хранение и обработку информации по определённым правилам [14, с. 13]. Таблица - ключевой элемент конструкции БД, представляющий собой набор записей.

Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые - предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).

К настоящему времени сформировались следующие БД:

-реляционные БД;

-дедуктивные БД;

-интегрированные или федеративные системы и мультибазы данных;

-объектно-ориентированные БД;

-распределённые БД;

Реляционные БД основаны на реляционной структуре данных, при которой любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение. Наименьшая единица данных реляционной модели - это отдельное атомарное (неразложимое) для данной модели значение данных.

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

Интегрированные или федеративные системы и мультибазы данных, которые появились в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД;

Объектно-ориентированные базы данных возникли в связи с потребностью в некоторой интегрированной среде построения сложных информационных систем, для которых технология предшествующих систем БД не была вполне удовлеторительной.

Под распределённой базой данных (Distributed DataBase - DDB) понимают базу данных, включающую фрагменты из нескольких баз данных, которые расплагаются на различных узлах сети компьютеров, и, возможно управляется различными СУБД. Распределённая база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово «распределённая» отражает способ организации базы данных, но не внешнюю её характеристику.

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

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

-средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

-средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

-средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

-средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

-средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+Bpwin, S-Designor, CASE.Аналитик.

1.2 Анализ и совершенствование процесса разработки средств автоматизации управления на промышленном предприятии

Много лет руководство и сотрудники компании во всём мире увлечены идеей улучшения деятельности организации. Необходимость в улучшении значительно усилилась в последнее время в связи с ускорением технологического прогресса, открывшем для мирового рынка компьютеры, спутниковую связь и самолёты. Высокая мобильность мирового бизнеса привела к значительным переменам в организационной стратегии. В 80-х, 90-х годах появилась первая волна программ по улучшению качества. Эти программы, сфокусированные на устранении дефектов и на постоянном повышении качества, были направлены на улучшение выполнения сотрудниками своих задач с целью достижения «нулевого уровня дефектов».

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

Одним из основополагающих принципов стандарта ИСО 9000 последней редакции стало рассмотрение деятельности компании как совокупности бизнес-процессов.

Среди основных факторов, побуждающих организацию сосредоточить своё внимание на улучшении процесса и/или системы можно выделить следующие:

-установка новой компьютерной системы;

-слияние двух или более организаций;

-необходимость сертификации в системе качества по стандартам ИСО серии 9000;

-необходимость сертификации в системе по защите окружающей среды по стандартам ИСО серии 14000;

-внедрение программы тотального управления качеством;

-необходимость снижения затрат и длительности цикла;

-необходимость подготовки к финансовому аудиту;

-необходимость реагирования на требования, предъявляемые потребителями и государством.

Итак, под процессом будем понимать логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы поставщика, создаёт ценность и выдаёт результат потребителю [25, с. 159]. Далее в работе под понятием процесс будет подразумеваться процесс по разработке САУ.

Основной процесс разбивается на подпроцессы, мероприятия (процедуры) и задачи.

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

Под задачами будут пониматься отдельные элементы и/или подгруппы элементов мероприятия, которые определяют то, как структурная единица выполняет определённую функцию.

Существует четыре различных подхода, направленных на совершенствование процессов:

1. Методика быстрого анализа решения (FAST);

2. Бенчмаркинг процесса;

3. Перепроектирование процесса;

4. Реинжиниринг процесса.

Методика быстрого анализа решения - «прорывной» подход, который концентрирует внимание группы на определённом процессе в ходе одно- двухдневного совещания для определения способов, которыми группа может улучшить процесс в течение следующих 90 дней. Перед окончанием совещания руководство одобряет или отвергает предложенные улучшения.

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

Под перепроектированием процесса понимается совершенствование существующего процесса и обычно применяется к тем процессам, которые достаточно успешно работают и в настоящий момент. При перепроектировании процессов строится имитационная модель текущего состояния (as-is). После этого могут применятся следующие рационализирующие средства:

-устранение бюрократии;

-анализ добавленной стоимости;

-устранение дублирования;

-упрощение методов;

-сокращение длительности цикла;

-защита от ошибок (анализ текущих проблем);

-модернизация процесса (реструктуризация организации);

-стандартизация;

-партнёрские отношения с поставщиками;

-автоматизация, механизация, применение информационных технологий.

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

В одном из стандартов серии ИСО (ИСО/МЭК 15504) определено понятие «зрелости процесса» (process maturity). Процессы предприятия образуют по этому параметру некоторую шкалу (от «неполного» до «совершенствуемого»). Данный стандарт ориентирован на деятельность по созданию и сопровождению программных средств. В основе стандарта заложена следующая идея постановки процессного управления компанией и дальнейшего её совершенствования:

- Должна быть построена модель процессов компании, т.е. должны быть идентифицированы все процессы компании и определена их степень зрелости, которая может быть выражена количественно;

- Данная модель должна быть задокументирована и представлена на аттестацию;

-В ходе аттестации модель процессов компании должна быть сопоставлена с эталонной моделью;

-Результаты аттестации применяются в планировании усовершенствования процессов компании.

Для любой организаций, занимающихся созданием и сопровождением программных средств, определены три группы процессов, которые должны быть обязательно поставлены в такой компании [7, с.66]:

-основные процессы ЖЦ ПО (разработка, эксплуатация, сопровождение);

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

-организационные процессы (управление проектами, управление реализацией ЖЦ, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом. Управление конфигурацией является также одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных информационных систем, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207.

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

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

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

Харрингтон Джеймс и другие в книге «Оптимизация бизнес-процессов: документирование, анализ, управление, оптимизация» [23, с.54] даёт описание этапов анализа и улучшения процессов. Среди них выделяются следующие:

1. Документирование процесса;

2. Анализ;

3. Проектирование;

4. Внедрение;

5. Управление.

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

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

Под термином «моделирование» будем понимать процесс создания точного, достаточного, лаконичного, удобного для восприятия и анализа описания системы, как совокупности взаимодействующих компонентов и взаимосвязей между ними [13, с.46]. Причём моделировать можно процессы как уже существующие, так и создаваемые с «нуля».

Моделирование предполагает наличие в обязательном порядке установленного набора изобразительных (выразительных) средств и правил - языка описания объекта. Среди наиболее распространенных языков описания и соответствующих им моделей можно выделить:

-вербальная модель - описание на естественном языке. Например, для стандартизации это наиболее характерная и привычная форма описания объекта. Следует отметить, что этот язык не всегда обеспечивает необходимой «прозрачности» и точности описываемого объекта.

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

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

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

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

Цели, факторы моделирования и уровень детализации процессов определяет выбор способа описания.

Можно выделить следующие цели описания:

1. Обеспечить понимание процессов;

2. Обеспечить основу для анализа и оценки процессов;

3. Помочь в передаче знаний при личных контактах.

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

Цели анализа и оценки процессов могут быть ориентировочно разбиты на четыре категории:

-достижение результативности процесса;

-достижение эффективности процесса;

-достижение адаптируемости процесса;

-внутренний контроль процесса.

Для правильного выбора способа документирования необходимо принять решение относительно того, какие факторы процесса должны быть описаны при моделировании процесса.

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

Можно выделить следующие факторы моделирования:

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

2. Элемент времени. Может быть подразделён на вопросы, касающиеся крайних сроков, отрезков времени, последовательности. Ключевую роль в осуществлении улучшений здесь играет анализ критического пути процесса разработки.

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

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

5. Географическое месторасположение. Определяет место или местоположение, где происходят операции; время или расстояние, которое необходимо преодолеть.

6. Местоположение организации (в организационной структуре, в которую входят мероприятия). Фактор тесно связан с фактором отдельных лиц и отделов, которые выполняют определённые операции.

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

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

9. Методика. Показывает как, с помощью каких инструментов, выполняются процедуры. В особенности это относится к методу сбора данных, их обработке и распространению.

Существует ещё множество факторов. Это такие как: эргономичность, степень свободы в процессах, удовлетворение сотрудников и т.д.

Количество факторов, которые могут быть понятно описаны с помощью какого-либо способа описания, принято ограничивать четырьмя или пятью. Если их число превышает эту цифру, то выбирается комбинация нескольких способов описания.

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

В данной работе выделим следующие способы описания процессов:

-методология составления схемы иерархического обзора;

-методология моделирования детальной схемы процесса;

-методология моделирования схемы управления формами;

-методология моделирования схемы движения форм;

-методология функционального моделирования процесса;

-методология моделирования потоков данных;

-методология моделирования данных;

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

Все эти способы реализуются для достижения определённых целей при определённом уровне детализации.

Рассмотрим эти способы описания отдельно.

1. Методология составления схемы иерархического обзора [23, c. 189]. Обеспечивает понимание структуры и связей во всей системе, показывает внутреннюю иерархию принципов процессов разработки САУ.

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

Функциональная декомпозиция проводится до тех пор, пока процессы разработки могут быть идентифицированы определённым способом.

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

2. Методология моделирования детальной схемы процесса [23, c. 210]. Эта схема обеспечивает понимание последовательности мероприятий (действий) и документопотока процесса разработки САУ и особенно подходит для достижения понимания и проведения анализа процессов.

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

Хорошим шагом на пути к построению обзора всех индивидуальных детальных схем процесса может стать моделирование схемы общего обзора. Одним из преимуществ детальной схемы процесса является то, что степень детализации, с которой описывается процесс, не влияет на схематическое изображение. Желание представить как можно больше факторов в схеме процессов часто приводит к представлению большого количества большого количества текста непосредственно рядом со схемой. Иногда выбирается детальная схема процесса, в которой схема приведена на левой странице, в то время как текст находится на правой. Текст соответствует мероприятиям и описывает как можно больше мероприятий, которые не могут быть изображены в схеме. Добавление текста позволяет увеличить количество представляемых факторов. Слева, рядом с мероприятиями, изображён отдел или сотрудник, вовлечённый в мероприятие, а также указан порядковый номер для каждого мероприятия.

ИСО разработала международный стандарт на символы, используемые при составлении блок-схем, которые могут использоваться при составлении детальных схем процесса. Этот стандарт - ИСО 1028, названный «Обработка информации. Символы, используемые в блок-схемах», отмечает, что концепция блок-схем также включает в себя так называемые блок-схемы системы, блок-схемы-программы, функциональные блок-схемы и блок-схемы конфигурации. Символы различаются в зависимости от типа и в соответствии с требованиями мероприятий, информации, логического решения или связи между символами или инструментами, для изображения которых они используются. Существуют следующие правила при составлении детальной схемы процесса:

-составление схемы таким образом, чтобы их можно было читать слева направо и сверху вниз;

-символы ввода-вывода необходимо помещать горизонтально, рядом с мероприятием, к которому они относятся;

-рисовать линии только горизонтально или только вертикально;

-рисовать как можно более короткие линии; читателю должно быть просто следить их направление;

-до предела сократить количество пересечений и стрелок;

-соединительные символы использовать для обозначения разрыва линии связи (выходной блок объединения) или продолжения разорванной линии связи (входной блок объединения);

-выходной блок объединения и входной блок объединения связаны одним и тем же символом.

3. Методология моделирования схемы управления формами [23, c.216]. Данная схема показывает использование и маршрутизацию форм в рамках процесса разработки САУ. Часто оказывается, что необходимо схематически изобразить маршрут и использование всех видов форм. Наряду с формами, книгами, картотеками, реестрами, распечатками, сюда входит информация с экрана, а также всевозможные технические инструменты, фотографии и т.д.

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

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

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

На пересечении строки (мероприятия) и столбца (объекта) отображаются действия (в виде символов) для каждого объекта, причём эти действия могут представляться в хронологическом порядке или сортироваться по отделам.

Как уже говорилось, действия в схеме управления формами представляются в виде символов. Это могут быть такие символы как:

X : объект подвергается описанному действию;

O : объект используется в действии, нацеленном на другой объект;

= : объект используется для контрольных действий;

V : объект контролируется;

H : (стоп) объект временно регистрируется или ожидает дальнейшего использования;

B : (регистрация) объект окончательно зарегистрирован;

S : (закрытие) объект уничтожается или покидает процесс;

T : (пояснение) текстовые пояснения для каждой линии в правой части формы;

X-X : действие совершается над несколькими объектами.

При этом, при составлении схемы управления формами, следует соблюдать следующие правила:

-символ "О" всегда должен использоваться в комбинации с символом "X" : новый объект (О) существует на основе другого (Х);

-символы "V" и "=" всегда должны фигурировать в строке вместе (объект контролируется на основе другого);

-каждая колонка объекта оканчивается символом "S", "H" или "В", или ссылкой на другую страницу.

Схема управления формами подходит для представления ряда факторов: документы, действия, характер действия, позиции и отделы.

Такие факторы как элементы времени, пространственное местоположение, периодичность, методика в этой схеме не представляются или представляются редко.

4. Методология моделирования схемы движения форм.

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

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

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

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

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

5. Методология функционального моделирования SADT (Structured Analysis and Design Technique) [7, c.112]. Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition, где ICAM, в свою очередь, обозначает программу «Интеграция компьютерных и промышленных технологий» разработанную по заказу ВВС США и получившую международное признание). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

1. графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

-ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

-связность диаграмм (номера блоков);

-уникальность меток и наименований (отсутствие повторяющихся имен);

-синтаксические правила для графики (блоков и дуг);

-разделение входов и управлений (правило определения роли данных).

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

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

Рис. 1. Функциональный блок и интерфейсные дуги

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

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

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