Главная База знаний "Allbest" Менеджмент и трудовые отношения Совершенствование процесса разработки средств автоматизации управления на ЗАО "Авиастар-СП"

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

Характеристика процесса разработки средств автоматизации управления на промышленном предприятии. Обоснование эффективности от внедрения плана мероприятий по совершенствованию процесса разработки средств автоматизации управления на ЗАО "Авиастар-СП".

Рубрика Менеджмент и трудовые отношения
Вид дипломная работа
Язык русский
Дата добавления 09.06.2012
Размер файла 158,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Внесение изменений в существующий проект процесса должно проводиться по следующим этапам:

1. Сформулировать принципы изменений;

2. Определить сущность изменений;

3. Определить наилучшее нацеленное на будущее решение;

4. Разработать детали изменений в соответствии с выбранной методикой документирования.

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

Рассмотрим каждый этап отдельно.

1. Формулировка принципов. Здесь необходимо определить, какие именно результаты должны быть достигнуты благодаря изменениям процесса. Для каждого (под)процесса нужно сопоставить следующие моменты:

-степень, в которой цели достигаются в текущей ситуации;

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

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

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

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

2. Определение сущности модификаций. Для определения сущности модификаций необходимо иметь документацию о существующих процессах, которые будут модифицироваться. В документации должны быть указаны:

-мероприятия и задачи, составляющие процесс;

-порядок выполнения этих мероприятий и задач;

-место проведения мероприятия;

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

-информация, задействованная в процессе;

-нормативы процесса.

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

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

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

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

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

-адаптируемость нацеленного на будущее процесса;

-затраты на внедрение нацеленного на будущее процесса;

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

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

Можно разработать ряд нацеленных на будущее решений, основанных на различных целях.

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

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

Выводы

По результатам проведённого исследования по проблеме совершенствования процессов разработки САУ на промышленном предприятии мною была обоснована необходимость рассмотрения объекта совершенствования как процесса, выделены 3 группы процессов по разработке САУ:

-основные процессы;

-вспомогательные процессы;

-организационные процессы.

Также в результате исследования были выделены основные этапы совершенствования:

-моделирование существующего процесса разработки САУ;

-анализ процесса разработки на основе модели;

-проектирование мероприятий по улучшению процессов разработки.

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

Кроме того, мною были сформулированы основные направления анализа процесса:

-анализ эффективности управления процессом;

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

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

-анализ эффективности организации системы внутреннего контроля;

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

-выявление дублирующих и избыточных процедур и мероприятий.

В результате исследования было выявлено четыре подхода направленных на совершенствование процессов:

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

-бенчмаркинг процесса;

-перепроектирование процесса;

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

2. АНАЛИЗ ПРОЦЕССА РАЗРАБОТКИ СРЕДСТВ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ НА ЗАО «АВИАСТАР-СП»

2.1 Характеристика объекта исследования

ЗАО “Авиастар - СП” является закрытым акционерным обществом. Полное официальное наименование общества:

на русском языке - Закрытое акционерное общество «Авиастар-СП»;

сокращённое наименование на русском языке - ЗАО «Авиастар-СП».

Местонахождение, юридический и почтовый адрес ЗАО «Авиастар СП»:

Россия, 432072, г. Ульяновск, проспект Антонова, 1.

Организационно-правовая форма - закрытое акционерное общество.

Закрытое акционерное общество «Авиастар-СП» зарегистрировано Администрацией Заволжского района г. Ульяновска решением № 461 от 02.12.1997 года.

Уставный капитал общества на момент регистрации составляет 4.500.000.000 руб. (четыре миллиарда пятьсот миллионов) именных обыкновенных акций номинальной стоимостью 1 (один) рубль каждая.

В оплату уставного капитала ЗАО “Авиастар-СП” передано имущество в составе зданий, оборудования, оснастки, инструмента, материалов, незавершенного производства, необходимых для производства самолетов Ан-124-100 и Ту-204.

Основным видом деятельности предприятия ЗАО «Авиастар-СП» является производство среднемагистральных самолетов семейства Ту-204 и широкофюзеляжных транспортных самолетов Ан - 124 «Руслан». Конкурентами самолета Ту-204 не только на внешнем, но и на внутреннем рынке России являются Боинг 757, 737, Эрбас Индастри А319, А320, А321. Основным преимуществом Ту-204 является низкая цена по сравнению зарубежными.

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

Структура общества и численность по подразделениям

Таблица 2

Наименование подразделения

Численность за 1999 год

Весь персонал

10674

В т.ч. ППП

10541

Из него:

1.

Основное производство

4386

1.1

Металлургическое производство

523

1.2.

Производство неметаллических конструкций

665

1.3.

Заготовительно-каркасное производство

709

1.4.

Механосборочное производство

721

1.5.

Агрегатно-сборочное производство

1505

1.6

Летно-испытательная станция

263

2.

Вспомогательное производство

2210

2.1.

Производство технологической оснастки и инструмента

696

2.2.

Производство по обслуживанию технологического оборудования

760

2.3.

Производство по обслуживанию энергетического оборудования

754

3.

Литейное производство с отдельным балансом

136

4.

Производство технологической оснастки с отдельным балансом

227

5.

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

3715

По бухгалтерским данным предприятия за 1999 год была получена прибыль в сумме 79130 т.руб., в т.ч. налог на прибыль составил 25137 т.руб. Чистая прибыль предприятия 53954 т.руб. была направлена на пополнение оборотных и прирост основных средств.

Вместе с тем, общая задолженность перед бюджетом и внебюджетными фондами за 1999 год составила 202013,2 тыс.рублей. Загрузка производственных мощностей составила 7,3%.

За период с 1999 года до 2003 года в целом обстановка мало изменилась. ЗАО «Авиастар-СП» продолжает находиться в тяжёлом финансовом положении. Оздоровление финансового состояния предприятия основано на увеличении программы выпуска и реализации самолетов Ту-204 и Ан-124.

В ближайшие 10 лет ЗАО «Авиастар - СП» прогнозирует следующие рынки сбыта своей продукции:

-авиакомпании России и СНГ - 50 - 70 самолетов;

-авиакомпании Восточной Европы, Ближнего и Среднего Востока - 80 - 100 самолетов;

-авиакомпании Китая и Индии - 60 - 80 самолетов.

На предприятии ЗАО «Авиастар-СП» существует комплексная автоматизированная система управления (КАСУ), которая включает в себя следующие функциональные элементы:

-АСАД (автоматизированная система административной деятельности);

-АСУП (автоматизированная система управления предприятием);

-АСУ ТП (автоматизированные системы управления технологическими процессами);

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

-АСУ-эксплуатация (автоматизированная система управления гарантийным и послегарантийным обслуживанием изделий авиационной техники);

-АСПИ (автоматизированная система производством испытаний авиационной техники).

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

-управление основным производством;

-управление конструкторской подготовкой производства;

-управление технологической подготовкой производства;

-управление финансово-бухгалтерской деятельностью;

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

-управление трудом и заработной платой;

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

-управление отдельными цехами и складами;

-управление инструментальной подготовкой производства;

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

-технико-экономическое управление.

Далее в работе будут анализироваться процессы разработки САУ, применительно именно к этим видам деятельности. Данную работу на предприятии осуществляет отдел проектирования АСУП (отдел №041), организационная структура которого представлена в приложении 3.

Все бюро отдела 041 разделены функционально. Бюро проектирования АСУ УМТС занимается автоматизацией функций управления материальным техническим снабжением, бюро проектирования АСУ ТЭУ - функций технико-экономического управления, бюро цеховых разработок АСУ - функций управления трудовыми ресурсами, бюро проектирования АСУ ТПП функций управления, связанных с технологической подготовкой производства, бюро проектирования УФБД - функций бухгалтерского учёта. Результатом их работы являются машинограммы (отчёты на бумажном носителе), для формирования которых программисты этих подразделений разрабатывают на больших машинах необходимое программное обеспечение.

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

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

Для проведения анализа процессов разработки САУ на ЗАО «Авиастар-СП», сначала необходимо эти процессы описать.

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

Для наиболее полного представления процессов разработки дадим сначала вербальное описание.

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

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

Таким образом, основной процесс разработки САУ на ЗАО «Авиастар-СП» включает следующие стадии:

1. Описание постановки задачи;

2. Разработка ТЗ на программирование;

3. Разработка рабочего проекта;

4. Формирование эксплуатационного пакета;

5. Опытная эксплуатация.

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

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

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

При составлении ТЗ единственным документом, кроме ОПЗ, который регламентирует деятельность разработчика ТЗ, является «Сборник положений по разработке задач АСУ» [33], введённым в действие с 15 февраля 1995 года. Этот документ предписывает формирование следующего содержания ТЗ:

-вводная часть;

-организационно-экономическая сущность;

-нормативно-справочная информация;

-информационная связь с другими задачами;

-выходная информация;

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

-система внесения изменений;

-алгоритм решения задачи.

Алгоритм решения задачи (разработки САУ) основывается на методике формирования выходных результатов, описываемый в ОПЗ (пример алгоритма представлен в приложении 4). Таким образом, алгоритм разработки задаёт подразделение-заказчик. Алгоритм выполняется в виде блок-схемы. При построении блок-схемы поле листа условно разбивается на три зоны. В левой крайней - вычерчиваются массивы в виде символов, являющиеся входными для очередного блока алгоритма. В средней - вычерчиваются блоки алгоритмов задачи, представляющие собой вычислительные или логические операции. В правой крайней зоне вычерчиваются массивы или машинограммы (их символы), являющиеся результатом реализации того или иного блока алгоритма.

ТЗ разрабатывается силами подразделения разработчика САУ. Первая редакция документа (черновик) подписывается непосредственным разработчиком, соисполнителями, руководителем темы (начальником бюро), предварительно согласовывается в подразделении, для которого проектируется ПО и проверяется нормоконтролёром БТВР. Проверенный экземпляр первой редакции документа перепечатывается на машинный носитель. Окончательная редакция проходит повторное согласование и утверждается руководителем СИТ. Утверждённый документ сдаётся в архив отд.045 для хранения и размножения.

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

1. Изучение ТЗ на программирование;

2. Разработка ПО на основании алгоритма решения задачи;

3. Проверка работоспособности ПО и выполнения требований ТЗ;

4. Разработка и утверждение необходимого пакета документов рабочего проекта задачи.

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

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

1. описание технологического процесса решения задачи;

2. паспорт на задачу (только для секретных задач );

3. цикловой график решения задачи;

4. инструкция по приёму, контролю и выдаче информации;

5. инструкция по записи информации на машинный носитель;

6. руководство пользователя;

7. исходные тексты программ.

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

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

ЭП формируется на основном и резервном томе магнитного носителя, отведённого для хранения серийного программного обеспечения ИВЦ. После формирования всех наборов ЭП ответственный за АС совместно с разработчиком проводит проверку ЭП в полном объёме на контрольном примере, при этом ответственный за АС разрабатывает сценарий контрольного примера и выполняет его, а разработчик готовит данные контрольного примера. В случае выявления ошибок в ЭП разработчик устраняет их и процедура формирования ЭП повторяется заново. При успешном завершении контрольного примера, разработчик выполняет работы по оформлению акта о формировании ЭП, и его согласованию с системным программистом.

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

Для обеспечения эксплуатации задачи выполняются следующие мероприятия:

-разработка, согласование и утверждение документации;

-проведение пуско-наладочных работ технических средств;

-сдача задачи в опытную эксплуатацию;

-проведение опытной эксплуатации;

-сдача задачи в промышленную эксплуатацию.

Организацию работ по вводу задачи АСУ в опытную эксплуатацию осуществляет подразделение - разработчик задачи.

В общем случае комплект документации на задачу включает следующие документы:

-ведомость документов проекта;

-проектные решения по КТС;

-описание постановки задачи;

-ТЗ на программирование;

-паспорт на задачу (только для секретных задач );

-описание технологического процесса решения задачи;

-цикловой график решения задачи;

-инструкция по приёму, контролю и выдаче информации;

-инструкция по записи информации на машинный носитель;

-руководство пользователя;

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

Проведение пуско-наладочных работ проводит технический отдел СИТ.

Сдача задачи в ОЭ подтверждается актом сдачи задачи в ОЭ.

В период проведения ОЭ программного обеспечения заказчик совместно с разработчиком осуществляет комплексную проверку и анализ входных результатов задачи на реальной информации; ответственный за АС проводит ОЭ (ведёт журнал ОЭ) и отрабатывает технологию решения задачи; разработчик проводит комплексную проверку проектных решений задачи (алгоритма, программ, организации решения, тестирование задачи на сбойные ситуации и устраняет выявленные при этом недостатки, внесённые в журнал ОЭ, если требования заказчика задачи не выходят за рамки «Описания постановки задачи») путём непосредственного внесения изменений в выданных экземплярах документации, изменяет программное обеспечение; ИВЦ, разработчик, заказчик выполняют работы, указанные в акте сдачи задачи в ОЭ.

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

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

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

Кроме того, данная методология полностью поддерживается программным приложением моделирования и анализа процессов Bpwin, позволяющим четко документировать различные аспекты процессов: действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Так формируется целостная картина деятельности системы - от моделей организации работы в маленьких отделах до сложных иерархических структур. Таким образом, модель процессов разработки САУ на ЗАО «Авиастар-СП» в Bpwin имеет вид, представленный на рис. 5-11.

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

Условные обозначения, используемые в модели процесса разработки САУ Таблица 2

Обозначение

Описание обозначения

PP

Программное обеспечение

OPZ

Описание постановки задачи

TZ

Техническое задание

RPr

Рабочий проект

ExpPac

Эксплуатационный пакет

Oexp

Опытная эксплуатация

WU

Разработка

IVC

Информационно-вычислительный центр

Direct

Положение о создании САУ

Instr

Инструкции

Cust

Заказчик

Des

Проектный отдел

DirSIT

Директор СИТ

CorDoc

Корректирующий документ: служебная записка или извещение об изменении

Consent

Согласование

Copy, control

Размножение, учёт

CorDatе

Корректирующие данные

NormContr

Нормоконтроль

Ratif

Утверждение

Tests

Тестирование

Act1

Акт о формировании ЭП

Act2

Акт сдачи в ОЭ

Act3

Акт о передаче документов

Act4

Акт сдачи в ПЭ

Comp ExpPac

Компоненты ЭП

Data KPr

Данные контрольного примера (КПр)

Real KPr

Проведение КПр

Date FKPr

Данные об успешном завершении КПр

Change ExpPac

Доработка ЭП

Changed ExpPac

Доработанный ЭП

Registry

Регистрация факта успешного завершения КПр в журнале ОЭ

Sent Act1

Приложение акта о формировании ЭП в журнал ОЭ

LV ExpPac

Формирование окончательной версии ЭП

VedDoc

Ведомость документов проекта

Sent in tabel

Включение входной выходной информации в табель документооборота предприятия в условиях АСУ

Real OExp

Проведение ОЭ

Рисунок 5. Контекстная диаграмма процесса разработки САУ

Рисунок 6. Детализация контекстной диаграммы процесса разработки САУ

Рисунок 7. Детализация этапа разработки ОПЗ

Рисунок 8. Детализация этапа разработки ТЗ.

Рисунок 9. Детализация этапа разработки рабочего проекта

Рисунок 10.Детализация этапа разработки эксплуатационного пакета

Рисунок 11. Детализация этапа опытная эксплуатация

Как видно рисунок 5 является контекстной диаграммой всего процесса разработки, рисунок 6 детализирует контекстную диаграмму на совокупность этапов (мероприятий), а рисунки 7-11 детализируют каждый отдельный этап процесса. Результатом выполнения процесса разработки САУ на предприятии является эксплуатационная документация, которая включает как само САУ, так и необходимый комплект документов.

Проведём сначала анализ эффективности управления.

Анализируя организационные структуры управления предприятия, СИТ и 041 отдела, представленные в приложениях 1,2,3 имеем, что на ЗАО «Авиастар-СП» применяется линейно-функциональная организационная структура управления, принадлежащая к бюрократическому типу организационных структур. На предприятии имеют место трудности, характерные для такого типа структур, связанные с преувеличением правил, процедур и норм, обеспечивающих надлежащее выполнение сотрудниками своих задач, а также с взаимодействием субъектов процесса разработки. Это утрачивает гибкость поведения, поскольку все возникающие здесь вопросы и проблемы решаются только исходя из прецедентов. Каждое изменение, дополнение должно поступать с извещением об изменении или служебной запиской, а сами изменения будут вноситься только после распоряжения своего функционального руководителя с занесением их в план работы исполнителя.

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

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

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

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

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

Далее проведём анализ длительности цикла процесса разработки.

Так как на ЗАО «Авиастар-СП» в документах ОПЗ и ТЗ не ставятся конкретные сроки разработки, проводить анализ своевременности выполнения процесса нет смысла, так как нет норм (заданных сроков), на которые можно было бы опираться.

Тем не менее, анализ длительности цикла можно провести, используя средние, фактические, временные характеристики этапов разработки, показанные в модели в нижнем левом углу. Данные цифры показывают, сколько времени затрачивается на выполнение отдельного этапа без учёта времени на доработку при возврате с последующих этапов. На модели процессов разработки САУ обратная связь представлена линиями CorDoc.

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

На предприятии ЗАО «Авиастар-СП» 70% изменений проводится вследствие некачественного ОПЗ (однако возврат осуществляется на этап проектирование ТЗ), 10% изменений - вследствие некачественного ТЗ (возврат осуществляется на этап проектирование ТЗ), 15% изменений - вследствие ошибок в ПО (возврат осуществляется на этап проектирование рабочего проекта), 5% изменений - вследствие изменения начальных условий (возврат осуществляется на этап проектирование ТЗ ). Таким образом, подавляющее большинство возвратов происходит на этап проектирование ТЗ.

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

Существует зависимость, показывающая как меняются затраты на изменения в зависимости от этапа, на котором выявлена необходимость в изменениях. Данная зависимость показана на рисунке 12.

Рисунок 12. Зависимость затрат на изменения от этапов разработки

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

Итак, при сложении данных временных характеристик, получим относительно наилучшую длительность цикла процесса разработки. Относительность объясняется тем, что необязательно данная последовательность этапов от разработки ОПЗ до ОЭ является оптимальной для ЗАО «Авиастар-СП».

В результате сложения получим, что в лучшем случае, процесс разработки САУ выполняется за 214 рабочих дней. Однако, по статистическим данным предприятия в среднем реальный процесс разработки занимает 275 рабочих дней.

Таким образом, 61 рабочий день (что составляет примерно 22% всего времени процесса разработки) затрачивается на разного рода изменения, доработки, дополнения.

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

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

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

В процессе разработки САУ на ЗАО «Авиастар-СП» принцип функционального разделения представлен слабо, так как многие мероприятия выполняются одним структурным подразделением. В частности, разработка ТЗ, рабочего проекта, эксплуатационного пакета выполняются проектным отделом. При этом ТЗ является документом, предъявляющим требования к будущему ПО, а рабочий проект представляет собой пакет документов, реализующий эти требования.

С другой стороны, особенности разработки программных САУ приводят к необходимости не только выполнения ТЗ разработчиком, но и совместного с заказчиком составления ОПЗ (как было описано выше, 70% изменений в процессе связано с некачественным составлением ОПЗ заказчиком), но и совместную с заказчиком разработку рабочего проекта.

Далее необходимо провести анализ эффективности процессов разработки.

Так как процесс разработки САУ является, в общем, интеллектуальным процессом, то основными ресурсами здесь являются человеческий умственный труд и информационный (компьютерное время), потребление которых прямо пропорционально времени, затрачиваемое на разработку. Следовательно, от того, как организован процесс (в том числе вспомогательный) во многом зависит совокупная стоимость будущего САУ. Так как при разработке в ОПЗ и ТЗ не ставятся конкретные сроки разработки, а также в силу многочисленных обратных связей, можно подсчитать лишь приблизительную стоимость процесса. Как уже говорилось ранее, основными потребляемыми ресурсами в процессе являются человеческий труд и компьютерное время. Исходя из того, что средняя заработная плата СИТ составляет 2100 рублей (с премией) в месяц, а рабочих дней в месяце-20, то за один рабочий день заработная плата составит 105 рублей (2100/20). Также, час работы на компьютере на предприятии стоит 28 рублей, соответственно рабочий день-224 рубля. Используя данные о количестве времени работы на компьютере на каждом этапе разработки, имеем, что из 275 рабочих дней, необходимых для создания готовой эксплуатационной документации 186 дней проводится за компьютером.

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

275 * 105 + 186 * 224 = 28875 + 41664 = 70539 (рубля)

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

При приобретении аналогичного САУ на стороне затраты бы составили приблизительно 800000 рублей. Выгода очевидна, однако при сокращении процента времени на изменения, доработки в лучшем случае затраты на разработку могли бы составить:

22470 + 32422 = 54892 (рубля).

Следовательно, перерасход в данном случае составляет 15647 рублей (70539-54892) при реализации одного процесса. Если учитывать, что в СИТ параллельно разрабатывается до 40 ПО, то совокупный перерасход данного подразделения составит 625880 рублей за 275 рабочих дней.

Итак, в ходе анализа процессов разработки САУ на ЗАО «Авиастар-СП» были выявлены следующие недостатки:

В документах задающих требования к разработке САУ не проставляются конкретные сроки;

Налицо недостатки каскадной модели ЖЦ ПО (громоздкие процессы внесения изменений);

Слабая проработка документа ОПЗ;

Отсутствует единый аппарат управления процессом разработки САУ как системой;

Недостаточная гибкость во взаимодействии субъектов процесса.

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

3. СОВЕРШЕНСТВОВАНИЕ ПРОЦЕССА РАЗРАБОТКИ СРЕДСТВ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ НА ЗАО «АВИАСТАР-СП»

3.1 Разработка плана мероприятий по совершенствованию процесса разработки средств автоматизации управления на ЗАО «Авиастар-СП»

В соответствии с выявленными проблемами выделим следующие цели улучшений и критерии достижения цели (КДЦ):

Заложение в документы, определяющие ход процесса разработки конкретных сроков выполнения как всей задачи в целом, так и отдельных этапов. КДЦ: наличие в ОПЗ И ТЗ сроков разработки и максимальное соблюдение этих сроков.

Создание единого руководящего органа каждой задачи. КДЦ: комплексное управление, контроль отдельной задачи.

Максимальное сокращение процента времени, затрачиваемого на изменения. КДЦ: 5%.

Обеспечение качественной разработки документа ОПЗ. КДЦ: сокращение возвратов вследствие ошибок в ОПЗ с 70% до 10%.

Определение предпочтений целей проведём методом парных сравнений. Для этого построим матрицу из чисел двоичной системы счисления (таблица3), где Cij - цели и

автоматизация управление промышленный предприятие

Матрица предпочтений целей Таблица 3

Ci

Cj

C1

C2

C3

C4

Ранг

C1

1

0

0

1

C2

0

0

0

0

C3

1

1

1

3

C4

1

1

0

2

Из матрицы предпочтений целей видно, что наиболее предпочтительной является цель №3, далее по важности следует цель №4, далее - цель№1 и наименее предпочтительной является цель №2.

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

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

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

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

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

Реорганизованная организационная структура управления предприятием представлена на рисунке 13

Рисунок 13. Реорганизованная организационная структура управления.

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

-назначение ответственного за задачу;

-назначение ассистентов задачи и разработчика;

-проведение первого организационно - ознакомительного совещания.

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

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

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

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

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

При такой форме оплаты ответственный за задачу будет заинтересован в разработке надлежащего САУ в срок.

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

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

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

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

Мероприятие2. В целях разработки качественного документа ОПЗ предлагается внести изменения в документ, регламентирующий данный подпроцесс («Сборник положений по разработке задач АСУ»), при которых в данный документ должен вноситься список требований к САУ. Данный список должен включать:

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

2. Описание выполняемых САУ функций;

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

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

Кроме того, в документ ОПЗ должна быть включена модель требований к САУ, включающая:

1. Полную функциональную модель требований к будущей системе с глубиной проработки до уровня каждой операции;

2. Спецификации операций нижнего уровня;

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

4. Концептуальную информационную модель требований;

5. Пакет отчётов и документов по информационной модели;

6. Архитектуру системы с привязкой к концептуальной информационной модели;

7. Предложения по оргштатной структуре для поддержки системы.

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

Обоснованиям включения в документ ОПЗ модели требований являются:

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

2. Составление модели требований позволит уменьшить затраты на разработку и внедрение системы.

3. Составление модели требований позволит оценить разработку по времени и результатам.

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

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

6. При использовании модели облегчается тестирование разрабатываемых САУ.

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

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

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

Таким образом, этап разработки проекта ОПЗ включает ряд мероприятий. Среди них следующие:

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

2. Разработка модели требований и разделов документа ОПЗ. Данное мероприятие предполагается осуществлять заказчиком и разработчиком совместно. Ответственный задачи должен разрешать все возникающие проблемы и утверждать выходящий документ «Проект ОПЗ».

3. Предварительное назначение сроков разработки. Данное мероприятие предполагается осуществлять заказчиком и разработчиком совместно.

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

Проект ОПЗ далее должен пройти согласование с директором СИТ и далее в отделе 054 учёт и размножение. Теперь данный документ должен формулироваться как «Описание постановки задачи» или «ОПЗ».

После осуществления данных мероприятий схема процессов разработки САУ в Bpwin будет выглядеть так как представлено на рисунках13-15.

Рисунок 13. Детализированная диаграмма процесса разработки САУ после совершенствования.

Рисунок 14. Детализация этапа назначения руководящего органа

Рисунок 15. Детализация этапа разработки проекта ОПЗ

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

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

Обозначение

Описание обозначения

DirectRing

Назначение группы разработки

DirRing

Члены группы

Org

Организационная информация

Dir meneger WU

Назначение ответственного за задачу

Dir assistants WU

Назначение ассистентов задачи

First conf

Проведение первого организационно-ознакомительного совещания

Meneger WU

Ответственный за задачу

Assistant WU

Ассистент задачи

Need in PP

Формирование потребностей в разрабатываемом ПО

WU parts OPZ

Разработка модели требований и разделов ОПЗ

First time

Установление первых сроков разработки

Project OPZ (lv)

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены