Проeктированиe экономичeских информационных систeм (эис) м 2003 156 с 5

Правила установки статических условий осуществляют выбор варианта БП в зависимости от выполнения условия. Если значение условия правила ложно, то данный вариант в процессе эксплуатации не выполняется и на диаграмме процесса соответствующая неактивная ветвь дерева изображается в затененном виде. Например, если БФ оформление аккредитива не используется в фазе внедрения, то запретить процесс оформления.  Технологическая сеть  модельно-ориентированного проектирования ЭИС   В силу сложности комплексной типовой ИС для МО проектирования характерны следующие особенности.   1. Привязка типовой ИС к условиям конкретного экономического объекта осуществляется в результате совместных усилий фирмы-производителя программного продукта и проектной группы предприятия.   2. Консультанты со стороны фирмы-производителя программного продукта принимают участие на всех этапах внедрения системы и, особенно на этапе анализа требований.   3. Возрастает роль руководства предприятия в организации и контроле за созданием ИС.   Технологическая сеть МО проектирования ЭИС включает операции:   1) выбор типовой ЭИС;   2) разработка проектной модели;   3) реализация проекта;   4) ввод в эксплуатацию.  Выбор типовой ЭИС — анализ требований   Внедрение типовой ИС начинается с анализа требований конкретной ОЭ системы предприятия к ЭИС.

 

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

 

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

 

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

 

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

 

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

 

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

 

В предварительной модели предприятия ее элементы могут быть представлены достаточно обобщенно, детализация модели предприятия произойдет после выбора типовой ЭИС.   После завершения этапа построения предварительной модели предприятия руководство предприятия принимает решение о выборе типовой ИС, модель предприятия которой в наибольшей степени соответствует целям автоматизации и набору остальных критериев.   Далее на основе принятого решения выполняется оформление договора с фирмой производителем ТИС о продаже, проведению работ по внедрении, собственно закупка, формирование проектной группы, формирование календарного графика работ. В результате формируется технико-экономическое обоснование и ТЗ на внедрение ТЭИС.  Разработка проектной модели предприятия   Для МО технологии проектирования ЭИС характерна привязка модели предприятия к функциональности типовой ЭИС, на основе которой в последующем автоматически выполняется конфигурация ИС. Поэтому на входе задаются предварительная модель предприятия, референтная модель функциональности типовой ЭИС и набор бизнес-правил отображения модели, а на выходе формируется проектная модель предприятия, в которой определяются компоненты типовой ЭИС, компоненты других программных продуктов и компоненты, которые должны быть специально разработаны с помощью инструментальных средств.   На этапе разработки проектной модели предприятия выполняются следующие работы:  1) инсталляция программного продукта, реализующего типовую ЭИС;  2) проведение обучения проектной команды;  3) привязка модели предприятия к компонентам типовой ИС;  4) проектирование внешних интерфейсов системы.   Рассмотрим ТС привязки модели предприятия к компонентам типовой ИС, состоящую из операций:  1) уточнение модели предприятия;  2) привязка модулей ТЭИС к БП;  3) привязка БО к модулям;  4) привязка организационных единиц к модулям БП.   В начале разработки проектной модели консультанты по ТИС совместно с проектной группой на основе предварительно построенной модели БФ и референтной модели уточняют модель БФ. Правильность выбора БФ контролируется на основе использования бизнес-правил.   Далее осуществляется привязка программных модулей ТЭИС к функциональным блокам модели БП, связанным с моделью бизнес-функций.

 

Для оригинальных компонентов в модели БП задаются спецификации на разработку программных модулей. Корректность выбора БП для БФ и условий привязки и выполнения программных модулей проверяется по бизнес-правилам.

 

В операции Привязки бизнес-объектов к программным модулям характер программных модулей уточняется составом используемых БО. В результате формируется структура используемых БО.

 

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

 

Корректность привязки контролируется с помощью бизнес-правил.

 

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

 

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

 

ТС конфигурации ЭИС включает операции:  1. Конфигурация программных модулей;  2. Генерация интерфейсов;  3. Настройка таблиц объектов БД;  4. Доработка модулей и интерфейсов.   Конфигурация программных модулей осуществляется путем установки параметров по модели БП, которая осуществляется либо автоматически, либо вручную аналогично параметрической настройке отдельных ППП.   Настройка таблиц объектов БД осуществляется по определению БО, либо автоматически на основе использования БП, либо вручную путем определения подмножества необходимых атрибутов.   Генерация пользовательских рабочих мест (интерфейсов) выполняется автоматически по модели взаимодействий исполнителей и программных модулей (описанию ролей пользователей).   Доработка программных модулей или разработка новых программных модулей функций и интерфейсов выполняется на основе определенных ранее спецификаций на доработку программных модулей и интерфейсов с учетом сконфигурированных других программных модулей, структур БД или БО, интерфейсов с использованием специальных языковых средств или других программных инструментов.   В завершении стадии реализации осуществляется комплексное тестирование всех компонентов КЭИС.  Ввод в эксплуатацию   Ввод в эксплуатацию типового проекта осуществляется поэтапно в соответствии с определенным планом. Перед началом эксплуатации должны быть выполнены следующие работы:  1) создание документации конечных пользователей и их обучение;  2) установка программно-технической среды эксплуатации ЭИС;  3) наполнение информацией новых БД или подключение и конвертация существующих БД.   В процессе эксплуатации ЭИС осуществляется системная поддержка для устранения возникающих замечаний. Особое внимание на стадии эксплуатации придается развитию проекта ЭИС. Для этого система должна накапливать статистику о характере функционирования ИС, на основе которой происходит технологическая отладка эффективности эксплуатации ЭИС. Важно также осуществлять анализ эффективности организации с помощью ИС БП на основе контроля экономических показателей, который приводит к непрерывному совершенствованию проектной модели предприятия, а, следовательно, к адаптации ЭИС к необходимым изменениям.  Вопросы ля самоконтроля   1. В чем заключается сущность типового проектного решения (ТПР)?   2. Какова классификация методов типового проектирования?   3. Определите основные понятия и сущность типового элементного метода проектирования.   4. Определите основные понятия и сущность типового подсистемного метода проектирования.   5. Определите основные понятия и сущность типового объектного метода проектирования.   6. В чем состоит отличие параметрически-ориентированного и модельно-ориентированного подходов к конфигурации типовых ЭИС?   7. Дайте определение функционального ППП.   8. Какова структура функционального ППП?

 

9.

 

Каковы критерии выбора функционального ППП?   10. В чем заключается сущность параметрической настройки ППП?   11. В чем заключается сущность адаптации ППП?

 

12. Что такое базовая, референтная, проектная модели предприятия?

 

ЛЕКЦИЯ 10  УПРАВЛЕНИЕ ПРОЕКТИРОВАНИЕМ ЭИС  ОРГАНИЗАЦИОННЫЕ СТРУКТУРЫ   ПРОЕКТИРОВАНИЯ ЭИС  ОБЩАЯ СТРУКТУРА ОРГАНИЗАЦИИ РАБОТ  ПО ПРОЕКТИРОВАНИЮ ЭИС   Процесс проектирования включает в себя большое количество взаимосвязанных элементов и предполагает построение соответствующей системы правления. В качестве объекта разработки проекта могут выступать либо вся ЭИС для предприятия заказчика, либо отдельная подсистема или совокупность систем, либо отдельные работы (например, установка ВС, оценка эффективности ИС).   Проект как вид деятельности проектирующей организации имеет следующие особенности:   * направлен на достижение конкретных действий;   * включает в себя координированное выполнение взаимосвязанных действий;   * имеет ограниченную протяженность во времени с определенным началом и концом;   * все проекты в определенной степени неповторимы и уникальны.   К причинам, обуславливающим сложность процессов разработки проекта, относятся:   * масштабы ЭИС;   * взаимосвязь различных по своей природе элементов проекта ЭИС (информационные, программные средства и технические средства обработки информации, экономико-математические модели, специалисты-разработчики);   * факторы старения указанных элементов;   * длительность процесса проектирования системы;   * коллективный характер труда многих специалистов различной квалификации.

 

Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях во времени, денежных средствах, качеству конечных результатов проекта. Управление как процесс характеризуется следующими компонентами:   * целью управления;   * ограничениями;   * объектом и субъектом управления;   * контуром управления;   * методами и средствами управления.   Глобальной целью управления проектированием ЭИС является получение проекта с заданными пользователем параметрами.   Ограничения — сроки, требуемые ресурсы.   Объект управления — процесс проектирования ЭИС как деятельность коллектива разработчиков системы, состояние используемых ресурсов.   Процесс проектирования ЭИС имеет специфические особенности, которые определяют специфику управления проектированием:   1. Процесс проектирования ЭИС по своему характеру является процессом творческим. Поэтому при отсутствии достаточно полного формализованного перечня операций проектирования и состояний проекта в процессе его разработки управление проектированием носит ситуационный характер.   2. Пользователь на этапе разработки системы может изменять требования к качеству системы, срокам и затратам проектирования. Затруднен контроль качества оценки проектных решений (нет общепринятых надежных способов).

 

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

 

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

 

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

 

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

 

Управление проектированием, как правило, рассматривают в двух аспектах: организационном и функциональном. В организационном аспекте управление проектированием рассматривается по уровням организационно — административной структуры с соответствующими правами и обязанностями субъектов процесса управления. В функциональном аспекте управление проектированием рассматривается как применение соответствующих методов и средств организации и ведения проектных работ.  ОРГАНИЗАЦИОННЫЙ АСПЕКТ   Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором, разработчиком.   Пользователь — это организация или группа подразделений, которые используют результаты обработки информации на ЭВМ. Для ЭИС под пользователем понимают прежде всего административно — управленческий аппарат, для которого создается эта система.

 

Пользователь выполняет следующие функции:  1) формирует исходные данные для проектирования и обработки;  2) определяет состав задач для автоматизации;  3) определяет основные требования к задачам и режим функционирования системы.   Заказчик — это ответственное лицо, под которым понимается организация ил подразделение, которое выполняет следующие функции:  1) формирует требования к системе и ее частям;  2) выдает техническое задание, финансирует разработку ЭИС;  3) обеспечивает проведение комплекса мероприятий по ее созданию;  4) проводит внедрение и прием проекта ЭИС.

 

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

 

Разработчик — это ответственное лицо (организация, подразделение), которое выполняет следующие функции:  1) разрабатывает ЭИС по техническому заданию заказчика;  2) принимает участие во внедрении;  3) осуществляет сдачу проекта заказчику;  4) осуществляет авторское сопровождение проекта.

 

Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научно-технический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных средств.

 

Существует несколько типов схем организации работ с участием четырех сторон, выбор которых зависит от объема заказа.   Если заказ имеет небольшие размеры по стоимости и по продолжительности работ, то принимают первую схему, в которой в одном лице выступают заказчик, разработчик и администратор.   К преимуществу данной схемы можно отнести минимальное кол-во организаций — участников процесса и минимальные сроки и стоимость работ. Однако совмещение в одной организации функций разрабатывающей и принимающей сторон имеет ряд недостатков: отсутствует действенный контроль за научно-техническим уровнем разработки, сроками выполнения работ; не достигается высокий профессиональный уровень разработчиков.   Пользователь Исходные данные  для проектирования Исходные данные для обработки Результаты  обработки данных Заказчик, разработчик, администратор Рис. 13.

 

Схема организации работ для небольших заказов   Для больших и сложных заказов применяют схему, согласно которой функции разработчика отделяют от функций заказчика и администратора и выполняются другой организацией.  Схема организации работ имеет вид:     Пользователь Исходные данные для проектирования Данные для обработки Результаты обработки данных Заказчик, администратор ТЗ, исходные данные для проектирования и финансирования Проектная документация ТП Разработчик   Рис. 14. Схема организации работ при наличии сложного заказа     К преимуществам данной схемы можно отнести: рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС; возможность привлечения к разработке специализированных организаций (НИИ, СКБ).   Однако эта схема имеет недостатки:  1) отсутствие прямой связи между разработчиком и пользователем, что создает трудности в своевременном получении и детализации исходных данных для проектирования;  2) определенные трудности при приеме проекта в эксплуатацию из-за желания администраторов получить методологическое обеспечение задач, максимально соответствующее идеальным условиям эксплуатации, что в свою очередь, требует больших сроков и объемов по доработке проекта.   В том случае, если заказчик — большая организация, которая курирует разработку нескольких проектов ЭИС, применяют следующую схему.     Пользователь Данные для обработки Исходные данные  для проектирования Администратор  Эксплуатационная  документация   Заказчик ТЗ, исходные данные для проектирования и финансирования Проектная документация ТП Разработчик Рис. 15. Схема организации работ  при полном разделении функций участвующих сторон     Данная сема характеризуется тем, что на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС. Преимуществами данной схемы являются:  1) более высокая степень специализации работников, следовательно, более высокий профессиональный уровень;  2) возможность организованного контроля за сроками и качеством работ.   Отделение заказчика от разработчика позволяет последнему привлекать к своей работе организации — соисполнителей разных уровней иерархии, что в свою очередь позволяет использовать труд специализированных и профессиональных организаций.   Основными документами, регулирующими отношения заказчика и проектировщика, являются ТЗ и договор на проведение работ.   Заказчик ТЗ Договор Головная организация  Частное ТЗ  Частный договор Организация — исполнитель  1-го уровня Положение о взаимодействии соисполнителей  Частное ТЗ  Частный договор Организация — исполнитель 2-го уровня Рис. 16.

 

Схема организации работ  с использованием организаций-исполнителей  ОРГАНИЗАЦИОННЫЕ ФОРМЫ УПРАВЛЕНИЯ  ПРОЕКТИРОВАНИЕМ ЭИС   В общем случае организационная структура управления проектированием регулирует взаимоотношения подразделений и должностных лиц в организации, устанавливает распределение ролей, полномочий и ответственности между ними, порядок функционально — технических связей, возникающих в процессе управления.   Формы управления, применяемые в организациях — разработчиках ЭИС, зависят от выполняемых работ. Формирование организационных форм управления осуществляется по функциональному и проектному (целевому) и матричному принципам.   Функциональный принцип построения структуры организации используется при выполнении задач проектирования постоянного характера. Для выполнения каждого вида задач (постановки задачи, создание информационного обеспечения) формируются функциональные подразделения из специалистов определенного профиля. Подобная структура организации обладает высокой степенью централизации управления. Встречается весьма редко.   Наиболее часто используется проектный принцип. На основе этого принципа формируется организационное подразделение — проектная группа, предназначенная для одноразовой разработки ЭИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель которой имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения работ может быть расформирован.   Матричное построение организационных структур предполагает формирование в организации — разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов.

 

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

 

Разделение труда на пооперационной основе базируется на свойстиве декомпозиции процесса проектирования ЭИС на технологические операции, которые выполняются отдельными специалистами. В этом случае требуется четкая регламентация взаимодействий между операциями (системный аналитик, программист, оператор).   Разделение труда на технологической основе затруднительно по следующим причинам:   1) невысокий уровень типизации технологических операций проектирования ЭИС;   2) невозможность получения объективно — точной качественной оценки промежуточных результатов проектирования;   3) отсутствие объективных критериев нормирования труда специалистов;   4) низкая степень стандартизации и унификации компонентов ЭИС.   Подсистемное разделение труда базируется на свойстве декомпозируемости проекта на подсистемы, каждая из которых независимо от числа технологических операций проектирования разрабатывается отдельной группой специалистов. В этом случае предполагаются стандартизация и унификация интерфейсов между подсистемами на каждом этапе процесса проектирования ЭИС Это приводит к системной специализации разработчиков (специалисты по экспертным системам., техническому обеспечению).   На практике при разделении труда в проектных коллективах возможно использование обоих вышеназванных принципов. Выбор целесообразного разделения труда зависит от ряда факторов, влияющих с разной степенью на решение проблемы.

 

Наиболее существенными являются следующие:  1) потенциал коллектива разработчиков;  2) объем и сложность разрабатываемых проектов;  3) технология проектирования системы;  4) модель жизненного цикла системы.   Степень влияния каждого фактора в конкретных случаях приводит к большому разнообразию разделения труда и связанных с ним организационных форм управления проектированием ЭИС. При этом, как правило, используются три типовые организационные структуры проектной группы: открытая, централизованная, децентрализованная.   Открытая организационная структура отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на отдельных этапах распределяются между разработчиками в соответствии с их знаниями, опытом, способностями. Административный руководитель в группе осуществляет, как правило, следующие действия:  1) взаимоотношения с заказчиком;  2) планирование и контроль сроков;  3) распределение ресурсов и координация работ;  4) отчетность перед руководством организации.   Такая организационная группа формируется из 7-10 человек для творческих решений задач и рекомендуется для выполнения работ на ранних стадиях проектирования системы — проведения обследования предметной области, анализе и разработке концепции проекта. Такая численность проектировщиков дает возможность полного обмена информацией между ними, а также возможность иметь относительно невысокие затраты на администрирование. Открытая структура позволяет варьировать количество разработчиков, привлекая для выполнения работ более квалифицированных специалистов, что способствует повышению качества проекта.   Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего администрирование и техническое руководство.

 

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

 

В его группу входят главный специалист, его заместитель, аналитики (постановщики задач), программисты.   Главный специалист выполняет следующие функции:  1) отвечает за разработку концепции проектируемой ЭИС и соответствие проектных решений требованиям пользователя;  2) выполняет совместно с аналитиками декомпозицию системы;  3) контролирует сроки проектирования и полноту проектной документации;  4) несет ответственность за разработку проекта во всех аспектах.   Главный специалист осуществляет непосредственное управление проектом и определяет стратегию проектирования.   Заместитель главного специалиста ориентирован на тактические вопросы проектирования ЭИС, на анализ альтернатив в разработке проектных решений. Заместитель находится в курсе всех вопросов проекта и любой момент может взять на себя роль руководителя.   Аналитики и программисты осуществляют непосредственно разработку частей проекта.   Достоинствами данной организации труда являются применение нисходящего проектирования, повышение качества проектных решений, интенсивное обучение и эффективное использование начинающих разработчиков. В этом случае предъявляются высокие требования к квалификации и организаторским способностям главного специалиста.   Децентрализованная организационная структура имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью сотрудников (более 10), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач.

 

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

 

Как правило, подгруппы объединены по технологической специализации.  Вопросы для самоконтроля   1. Каковы особенности разработки проекта как вида деятельности?

 

2.

 

Каковы стадии жизненного цикла проекта как вида деятельности проектной организации?

 

3. Что понимается под управлением проектом?

 

4. Каков состав лиц, участвующих в разработке и эксплуатации проекта ЭИС?   5. Перечислите принципы разделения труда в проектных организациях.   6. Определите особенности централизованной и децентрализованной организационной структуры проектной группы.

 

ЛЕКЦИЯ 11  ПЛАНИРОВАНИЕ И КОНТРОЛЬ ПРОЕКТНЫХ РАБОТ  ОСНОВНЫЕ КОМПОНЕНТЫ  ПРОЦЕССА УПРАВЛЕНИЯ ПРОЕКТИРОВАНИЕМ ЭИС   Управление проектирование ЭИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимают действия, связанные с решением конкретных задач или реализацией функций управления, к которым относятся:   1. Процессы инициации, связанные с принятием решения о начале выполнения проекта или какого — либо очередного этапа или его фазы;   2. Процессы планирования — совокупность процедур, связанных с определение целей и критериев успеха проекта и разработкой рабочих схем их достижения;   3. Процессы исполнения, предназначенные для координации людей и других ресурсов для выполнения плана;   4. Процессы анализа, дающие возможность определить соответствие плана и исполнения проекта поставленным целям и критериям и принять решение о необходимости корректирующих воздействий;   5. Процессы оперативного управления и регулирования — совокупность процедур, предназначенных для определения необходимых корректирующих мер, их согласования, утверждения, применения;   6. Процессы завершения — процессы формализации выполнения проекта и составления отчетности.   Процессы управления проектами накладываются друг на друга и происходят с разной степенью интенсивности на всех стадиях проекта. Кроме того, процессы управления связаны между собой результатами; результат выполнения одного — информация для выполнения другого. Процессы управления связаны между собой входами и выходами.   Входы — документы или документированные показатели, согласно которым процесс исполняется   Выходы — документы, являющиеся результатом процесса.

 

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

 

решение начать следующую фазу проекта.  Процессы планирования   Планирование имеет большое значение для проекта и включает сравнительно много процессов. К основным относятся:   1) планирование целей — разработка постановки задачи (проектное обоснование, основные этапы и цели проекта);   2) декомпозиция целей — разделение этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля;   3) определение состава операций (работ) проекта — составление перечня операций для различных этапов проекта;   4) определение взаимосвязей операций — составление и документирование технологических взаимосвязей между операциями;   5) оценка длительностей и объемов работ — оценка кол-ва рабочих временных интервалов либо объемов работ, необходимых для завершения отдельных операций;   6) определение ресурсов (людей, оборудования) проекта — определение общего количества ресурсов всех видов, которые могут быть использованы на работах проекта и их характеристики;   7) назначение ресурсов — определение ресурсов, необходимых для выполнения отдельных операций проекта;   8) оценка стоимости — определение составляющих стоимости операций проекта, оценка этих составляющих для каждой операции, ресурса и назначения;   9) составление расписания выполнения работ — определение последовательности выполнения работ проекта, длительности операций и распределения во времени потребностей в ресурсах и затрат с учетом наложенных ограничений и взаимосвязей;   10) оценка бюджета — приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам);   11) разработка плана исполнения проекта — интеграция результатов остальных подпроцессов для составления полного документа;   12) определение критериев успеха — разработка критериев оценки исполнения проекта.   Кроме перечисленных основных процессов планирования имеется ряд вспомогательных, необходимость использования которых зависит от конкретного проекта. Такие процессы включают:   * планирование качества — определение того, какие стандарты качества использовать в проекте, и того, как этих стандартов достичь;   * планирование организации — определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации;   * назначение персонала — назначение человеческих ресурсов на выполнение работ проекта;   * планирование взаимодействия — определение потоков информации и способов взаимодействия, необходимых для участников проекта;   * идентификация риска — определение и документирование событий риска, которые могут повлиять на проект;   * оценка риска — оценка вероятностей наступления событий риска, их характеристик и влияния на проект;   * разработка методов реагирования — определение необходимых действий для предупреждения рисков и реакции на угрожающие события;   * планирование поставок — определение того, что, как и когда должно быть поставлено;   * подготовка условий — выработка требований к поставкам и определение потенциальных поставщиков.    Процессы исполнения и контроля   Под исполнением понимают процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для выявления отклонений от намеченного плана и оценки их влияния на проект. Как и в планировании, процессы можно подразделить на основные и вспомогательные. К основным можно отнести сам процесс Исполнения плана проекта.

 

Среди вспомогательных процессов можно отметить:  1) учет исполнения — подготовку и распределение необходимой для участников проекта информации с требуемой периодичностью;  2) подтверждение качества — регулярную оценку исполнения проекта с целью подтверждения соответствия принятым стандартам качества;  3) подготовку предложений — сбор рекомендаций, отзывов, предложений, заявок;  4) выбор поставщиков — оценку предложений, выбор поставщиков и подрядчиков, заключение контрактов;  5) контроль контрактов — контроль исполнения контрактов поставщиками и подрядчиками;  6) развитие команды проекта — повышение квалификации участников команды проекта.  Процессы анализа   Процессы анализа включают анализ плана и анализ исполнения проекта.   Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана командой и другими участниками проекта.   На стадии планирования по результатам анализа плана может быть принято решение о необходимости изменения начальных условий и составлении новой версии плана либо принятие разработанной версии в качестве базовой. В дальнейшем под процессами анализа понимают процессы анализа исполнения.   Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования. Для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество, стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями.   Процессы анализа также можно подразделить на основные и вспомогательные. К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:  1) анализ сроков — определение соответствия фактических и прогнозных сроков исполнения операций проекта;  2) анализ стоимости — определение соответствия фактической и прогнозной стоимости операций и фаз проекта;  3) анализ качества — мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определение путей устранения причин нежелательных результатов исполнения качества проекта;  4) подтверждение целей — процесс формальной приемки результатов проекта его участниками.   Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:   1. Оценку исполнения — анализ результатов работы и распределения проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;   2. Анализ ресурсов — определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов, машинного времени и т.д. плановым значениям.

 

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

 

Если исполнение проекта идет в соответствии с намеченным планом, то управление сводится к доведению до участников проекта плановых заданий и контролю за их реализацией. Эти процессы включаются в процессы исполнения.   В том случае, если возникли отклонения, то требуется:  1) найти оптимальные корректирующие воздействия;  2) скорректировать план оставшихся работ;  3) согласовать намеченные изменения со всеми участниками проекта.   Процессы оперативного управления предназначаются для определения, согласования и внесения необходимых изменений в план проекта. Такие процессы часто называются управлением изменениями и инициируются процессами анализа.

 

К основным процессам оперативного управления относятся:   1. Общее управление изменениями — определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту;   2.

 

Управление ресурсами — внесение изменений в состав и назначение ресурсов на работы проекта;   3.

 

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

(Visited 1 times, 1 visits today)
Do NOT follow this link or you will be banned from the site! Пролистать наверх