Стратегическое использование программной архитектуры
В любой организации архитекторы помогают преобразовать бизнес-стратегию в стратегию техническую. В ряде случаев архитектор может внести свой вклад в формирование бизнес-стратегии. В этом случае архитектура гарантированно будет согласована с корпоративной стратегией, что позволит эффективно использовать предоставляемые архитектурой стратегические перспективы.
Стратегическое планирование
Архитектура может служить средством позиционирования предприятия на рынке.
Cистема формируется как набор уровней, которые делятся на модули архитектуры в соответствии с вероятностью изменения последних. Оценить такую вероятность можно на основе уже накопленных данных и прогнозов о предполагаемом изменении технологии и предметной области.
Архитектура может повлиять на стратегические планы выпуска продуктов компании.
Корпоративная архитектура
Корпоративная архитектура дает руководству предприятия целостное представление обо всей инфраструктуре используемых в ней ИТ, показывает, как согласуются друг с другом все компоненты вычислительной среды. Корпоративная архитектура включает в себя не только программные архитектуры; она определяет контекст их координации.
В тех компаниях, которые критическим образом зависят от программного обеспечения, технические соображения иногда учитывать необходимо. Предприятия принимают стратегии, предопределенные стандартными архитектурами той предметной области, в которой они работают.
Эталонные архитектуры
Выбор эталонной архитектуры программного обеспечения, скажем архитектуры J2EE, в качестве отправной точки для продукта или серии продуктов имеет стратегическое значение.
Главное, на что следует обратить внимание при выборе архитектуры, — ее готовность и
стоимость артефактов. Одно из технических соображений, которые существенно влияют на принятие бизнес-решений, — объем необходимых инвестиций и средств на обучение персонала. Как правило, для разработки нужны технические знания и навыки, которые нельзя приобрести при создании одного продукта. ИТ- менеджеры принимают решения об инвестициях до выработки требований к продукту, а эталонная архитектура и сопутствующая ей инфраструктура, с учетом их сложности, требуют значительного
времени на изучение. Принимая бизнес-решение о выборе иного стратегического направления (в результате которого большая часть знаний ИТ-специалистов окажется «за бортом»), следует иметь в виду: для получения нового опыта понадобятся существенные инвестиции. Хотя версии эталонной архитектуры выпускаются относительно редко, зачастую они сопровождаются значительными изменениями. Скорость появления новых версий имеет стратегическое значение, поскольку она определяет, насколько часто придется менять средства разработки. Существенные частые изменения в архитектуре требуют постоянной модификации средств разработки. Поставщики работают с последней версией стандарта, поэтому отказ от модернизации до этой версии может серьезно осложнить покупку компонентов и послужить для пользователей сигналом о том, что их решения вот-вот устареют. В данном отношении удачным вариантом является представление, которое содержит даты выпуска технологий, продуктов и стандартов.
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471-2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
Примеры видов:
* Функциональный/логический вид
* Вид код/модуль
* Вид разработки (development)/структурный
* Вид параллельности выполнения/процесс/поток
* Физический вид/вид развертывания
* Вид с точки зрения действий пользователя
* Вид с точки зрения данных
Архитектура ПО является реализацией нефункциональных требований к системе.
Архитектура ПО, которую также можно представить себе в виде разработки стратегии - это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством.
Есть много распространенных способов разработки программных модулей и их связей, в том числе:
* Blackboard
* Клиент-серверная модель (client-server)
* Архитектуры, построенные вокруг базы данных (database-centric architecture)
* Распределенные вычисления (distributed computing)
* Событийная архитектура (event-driven architecture)
* Front end and back end
* Неявные вызовы (implicit invocations)
* Монолитное приложение (monolithic application)
* Peer-to-peer
* Пайпы и фильтры (pipes and filters)
* Plugin
* Representational State Transfer
* Rule evaluation
* Поиск-ориентированная архитектуры
* Сервис-ориентированная архитектура
* Shared nothing architecture
* Software componentry
* Space based architecture
* Структурированная
* Трехуровневая
Дополнение Дениса
ADD-метод
(ADD)- систематический последовательный метод разработки программного обеспечения, архитектуры программного обеспечения.
ADD включает в себя известные функциональные требования, такие как, требования к качеству атрибутов и ограничений. Функциональные требования могут быть указаны со списком функций или вариантами использования. Атрибуты требования к качеству могут быть указаны с использованием качественных сценариев атрибутов, таких как атрибут SEI quality Ограничения проектных решений, которые вынуждены от внешних факторов.
· Выберите элемент системы к дизайну.
· Определить архитектурно значимые требования, которые применяются к элементу разработки. Архитектурно значимые требования сочетают качества бизнеса и функциональные цели, которые применяются к элементу, который разрабатывается, и который будет иметь наибольшее влияние на его архитектуру.
· Выбор моделей и тактики для удовлетворения архитектурных драйверов. Есть известные шаблоны для достижения различного качества и функциональности. Выберите решения, которые являются наиболее подходящими для первоочередного архитектурных драйвера.
· Создание экземпляра шаблона и тактики для создания новых элементов дизайна в рамках элемента.
· Уточнить качества, бизнеса и функциональных целей, и передайте их новым элементам дизайна, который будет предметом будущих итераций.
· Повторите деятельность пока все драйверы не будут удовлетворены.
Ответ прошлых лет (Ден)
Программная архитектура – многогранный подход, гарантирующий, что программное обеспечение будет отвечать своему предназначению.
Архитектура программной системы определяет ее структуру, точнее – несколько структур, каждая из которых включает в себя элементы и взаимосвязи между ними. Элементы могут быть вычислительными объектами, связанными потоком управления или бизнес-объектами, связанными семантическими ограничениями.
В целом процесс проектирования архитектуры состоит из систематической декомпозиции элементов верхнего уровня на совокупности более мелких элементов.
С помощью подхода ADD архитектор выбирает конкретную декомпозицию, стремясь улучшить определенные свойства конечного продукта. Следует, однако, иметь в виду, что каждая декомпозиция, как правило, какие-то свойства ухудшает.
Процесс создания архитектуры предполагает разработку системы с конкретными свойствами и функциональностью, причем каждое из таких свойств имеет заданный приоритет. Начиная с общей структуры, которая поддерживает всю требуемую функциональность, архитектор методично проводит декомпозицию функциональности и распределяет ее между компонентами. Другими словами, нужно достигнуть оптимального соотношения между характеристиками заданных свойств. Затем на предприятии могут быть созданы рабочие группы, каждая из которых станет заниматься проектированием и реализацией своего подмножества элементов архитектуры.
Архитектор создает разные диаграммы для отображения компонентной структуры, взаимодействий между компонентами и их размещения. Описание архитектуры содержит несколько «представлений», которые используются собственно для отображения разных типов информации о структуре программного обеспечения.
Выбрав эталонную архитектуру, можно использовать разработанные с ее помощью компоненты как основу проектирования. Немаловажный фактор при выборе архитектуры – формирующееся вокруг нее коммерческое сообщество. Чем оно больше и разнообразнее, тем больше вероятность приобретения компонентов, позволяющих существенно ускорить разработку продукта. Кроме того, для такой архитектуры существуют шаблоны, справочники, примеры и другие активы.
Разработка архитектуры – процесс в равной степени творческий и планируемый. Бизнес-цикл разработки побуждает предприятие подумать о своей стратегии с учетом конкуренции, тенденций в отрасли и эволюции технологии.
25. Проектирование ИС [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 9.2., 36.3. | Проектирование информационных систем. Управление конфигурациями. | Повышев Владислав Вячеславович | Денис Никаноров | ОПЛ (Ден), ОПЛ (Мадина), готовый ответ Милы |
Готовый ответ Милы
Управление конфигурацией – один из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО ИС.
Конфигурация ПО - совокупность функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.
Процесс управления конфигурацией включает:
· идентификацию конфигурации;
· контроль конфигурации;
· учёт состояния конфигурации;
· оценку конфигурации;
· управление выпуском и поставку.
При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO/IEC 12207.
Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
К управлению конфигурацией следует отнести функции анализа производительности и оптимизации системы.
Большинство систем имеют оптимальные настройки по умолчанию и не требуют особого вмешательства. Однако, производители сетевых операционных систем включают в них наборы эмпирических правил, помогающих администратору вносить изменения в настройки с минимальным риском ухудшить другие показатели или сделать систему неработоспособной. Администратору следует их изучить и знать перечень параметров, которые необходимо контролировать. Многих проблем можно избежать еще на стадии планирования сети.
Сюда же можно отнести задачу, связанную с учётом системных ресурсов. Учёт ресурсов позволяет заметить тенденции к появлению узких мест до того, как появятся проблемы с производительностью и провести соответствующую модернизацию. Кроме того, система учёта необходима при платном использовании ресурсов, например, контроль использования дискового пространства, печати, учёт трафика.
проекта была возможность реализовать требования, предъявляемые к ИС на различных стадиях ее жизненного цикла. Она определяет отношения между видами деятельности, непосредственно касающимися процессов проекта и характеристик создаваемой ИС, в их числе функции управления конфигурацией, проектирование ИС, материально-техническое обеспечение, заключение контрактов, управление информацией и т. п.
ИС на каждом этапе ее построения обладает определенной базовой для данного этапа конфигурацией. Соответственно и процессы проекта должны быть выстроены таким образом, чтобы в результате их осуществления была достигнута именно эта конфигурация.
Управление конфигурацией ИС и процессами проекта позволяет координировать управление перечисленными видами деятельности, исходя из тех изменений, которые постоянно возникают в ходе реализации проекта.
В плане управления конфигурацией в компании следует:
· установить и поддерживать базовые конфигурации;
· иметь опись (карту) ИС, актуализируемую с учетом жизненного цикла, в которую входят аппаратура, программное обеспечение и документация;
· установить и обеспечить практическое применение настроек для конфигурирования средств безопасности в продуктах, входящих в ИС.
Управление конфигурацией: базовая конфигурация и опись компонентов информационной системы. При установке новых компонентов изменяются базовая конфигурация информационной системы и опись компонентов ИС.
Управление конфигурацией: контроль изменений конфигурации. Документируются и контролируются изменения в информационной системе; соответствующие должностные лица санкционируют изменения ИС в соответствии с принятыми в организации политикой и процедурами.
Управление конфигурацией: мониторинг изменений конфигурации. Необходимо отслеживать изменения в информационной системе и осуществлять анализ их воздействия на безопасность, чтобы определить эффект изменений.
Управление конфигурацией: ограничение доступа для изменений. Организация проводит в жизнь физические и логические ограничения доступа, связанного с изменениями в информационной системе, и генерирует, сохраняет и пересматривает записи, отражающие все подобные изменения.
Управление конфигурацией: минимизация функциональности. Следует конфигурировать информационную систему так, чтобы обеспечить только необходимые возможности, и явным образом запретить и/или ограничить использование определенных функций, портов, протоколов и/или сервисов.
Один из процессов, позволяющих существенно повысить качество как самого процесса разработки ПО, так и выходного продукта, — управление конфигурацией (УК) программных средств. Составной частью этого процесса является другой процесс — управление изменениями (УИ), в том числе отслеживание обнаруженных ошибок и других запросов заказчиков на изменения в продукте.
Цели:
* контроль вносимых изменений;
* улучшение качества продукта или услуги;
* повышение степени удовлетворенности пользователей и/или заказчиков;
* организация взаимодействия различных рабочих групп. Действия:
* создание или обновление рабочего пространства по заданному профилю;
* внесение изменений в файлы проекта;
* интеграция изменений с изменениями, внесенными другими участниками;
* фиксирование базовой линии текущих версий файлов проекта;
* регистрация запросов;
* назначение исполнителей и сроков;
* контроль исполнения (периодический контроль).
Важные составляющие процессов:
* автоматизированная процедура сборки версии программного средства;
* автоматизированное уведомление участников проекта об изменении файлов, важных с точки зрения проекта, а также о других ключевых событиях;
* возможность количественной и качествен ной оценки проделанной разработчиками работы;
* совместный доступ к информации о запросах на изменения.
Эффект от внедрения на уровне руководства
Рассмотрим основные преимущества внедрения этих дисциплин с точки зрения руководства:
1. Прозрачное управление проектом (за счет строгой формализации процессов). Процесс выстраивается таким образом, что все случаи, требующие принятия решений, контролируются на должном уровне.
2. Четкое представление о том, кто и чем занимается в проекте, сколько ошибок исправлено, сколько ошибок найдено и т.д.
3. Полное документирование всех ключевых изменений.
4. Планирование деятельности каждого разработчика, который точно знает, что ему нужно сделать сегодня, завтра и послезавтра.
5. Графическое представление метрик проекта, формируемых при определении процесса (типы, количество и т.д.).
6. Формирование статистических отчетов по проекту (часто называемых срезами). Сформированные метрики проекта ранжируются в зависимости от уровня руководства: руководитель департамента, начальник отдела, менеджер проекта и т.д.
Срезы позволяют избавить участников проекта от ненужной информации, а также могут служить рабочими инструментами для персонального планирования задач и анализа за траченного времени.
Правильная реализация дисциплины управления конфигурацией при разработке и сопровождении ПО позволяет значительно сократить финансовые потери. При принятии решения о внедрении процесса УК в организации необходимо учитывать как прямые, так и кос венные преимущества и затраты.
К прямым преимуществам можно отнести повышение производительности труда, которое обычно поддается подсчету. К косвенным преимуществам относится увеличение доли рынка за счет более быстрого вывода на рынок новых продуктов, что довольно сложно поддается подсчету, но может принести большую выгоду.
Ответ прошлых лет (Ден)
Управление конфигурациями определяется как процесс, с помощью которого администрация программы или проекта может систематически идентифицировать, устанавливать связи, сопровождать и управлять различными компонентами программы или проекта. Этот процесс гарантирует целостность компонент и трассируемость всех изменений, возникающих в любой момент жизненного цикла программы или проекта.
Управление конфигурациями позволяет команде разработчиков программы или проекта точно определять статус любой компоненты во все время ее жизненного цикла и позволяет перевоссоздать любую версию в любой момент времени. Компонентами могут быть любые комбинации аппаратуры, программ, обслуживания и обучения.
Управление конфигурациями построено как композиция четырех подпроцессов, функционирующих одновременно:
· Идентификация конфигурации - Процесс идентификации конфигураций требует выполнения следующих шагов:
o Определение объектов конфигурации
o Выбор схемы наименования объектов конфигурации
o Определение утверждаемых схем
o Определение внутренних схем
· Управление конфигурациями – Управление конфигурациями непосредственно взаимодействует с процессом управления изменений. Первоначально этот шаг обеспечивает информацией управление изменениями о влиянии предлагаемого изменения. Когда (и если) это изменение принимается, процесс управления конфигурациями гарантирует, что объекты конфигурации, на которые влияет данное изменение, будут пересмотрены, для чего он подготовит соответствующие идентификационные номера, а затем будет модифицирована и схема, на которую изменение оказало влияние. Таким образом, управление конфигурациями обрабатывает объекты конфигурации и контролирует редакции и схемы. Эти два шага обсуждаются более детально в следующих подразделах. Еще более детальную информацию можно найти в Digital Program Methodology Technique: Change Control. Процесс обработки изменений управляется Подразделением Контроля за Конфигурациями.
· Вычисление статусов конфигураций – После того, как изменение объекта конфигурации санкционировано, должна возникнуть некоторая временная задержка на время реализации изменения. ВСК есть механизм, используемый для прослеживания эволюции каждого объекта системы и его текущего статуса, соотносящегося со спецификациями, обозначенными в общедоступной схемной документации и письменными соглашениями. ВСК подчеркивают условие ко всему продукту в любой момент времени жизненного цикла его разработки и используются для контроля развития программы/проекта. ВСК обеспечивает программного/проектного менеджера большим количеством информации о его продукте, включая то, как он разрабатывается и все ли требуемые свойства действительно реализованы. В конечном счете, ВСК обеспечивает документацию о статусе каждого объекта конфигурации в любой момент процесса разработки.
· Аудиты/Обзоры конфигураций – Менеджеры программы/проекта должны быть уверены, что требуемое управление конфигурацией реализуется - другими словами, все принятые изменения реализованы, а результат представляет собой то, что специфицировано в его проектной документации. Для достижения необходимо высокого уровня доверия они планируют регулярные аудиты и обзоры конфигурационного управления. Требования для этих аудитов и обзоров обычно специфицируются в Плане Управления Конфигурациями, но также они могут быть заданы в планах программы, проекта или качества, как это покажется подходящим. Ответственность за нормальную реализацию аудитов конфигураций лежит на менеджере конфигураций, если эта должность предусмотрена, а если нет - на менеджере программы/проекта или менеджере качества.
Очень подробно об этом на http://k98-224.narod.ru/conf_man.htm
Роль управления конфигурациями в рамках общей управленческой структуры программы/проекта зависит прежде всего от общего объема работ. Управление конфигурациями тесно завязано c некоторыми другими процессами, включая технологию (собственно разработку), управление изменениями и ГК. Этот процесс является центральным для управления всеми программными или проектными файлами, так как он централизует управление изменениями в этих файлах. Кроме того, он гарантирует своевременность обмена информацией между всеми подразделениями организации.
Взаимодействие управления конфигурациями и управления изменениями представляет собой хороший пример тесной связи между различными процессами и управлением конфигурациями. Когда запрос на изменение попадает в процесс управления изменениями, об этом событии уведомляется менеджер конфигураций. Это позволяет менеджеру конфигураций модифицировать запись, относящуюся к ВСК; затем объект от начала до конца прослеживается процессом управления конфигурации, пока не будет завершена его обработка процессом управления изменениями. Разработчик завершает задачу, затребованную процессом управления изменениями, и затем уведомляет менеджер конфигураций об этом. В заключение менеджер конфигураций передает изменение в ГК для последующей окончательной верификации. В действительности существует неявный контакт между разработчиком и ГК в ходе внесения изменения.
Ответ прошлых лет (Мадина)
Управление конфигурациями
 |
Те или иные аналоги процесса управления конфигурациями имеются в любой компании. В обязательном порядке осуществляется учет активов (оборудование, программы и документация). Однако под такой учет не попадают ни бесплатные программные системы (поскольку для бухучета их не существует) ни собственные разработки, если только они не выполнялись в коммерческих целях и не были поставлены на баланс организации. Это касается и самостоятельно разработанной документации. В связи с этим многие специалисты ИТ различных направлений ведут собственный учет находящихся под их контролем элементов инфраструктуры. Такой учет, как правило, носит неформальный характер. Частичное улучшение ситуации малоэффективно. Формальный учет информации можно организовать по каждому направлению в отдельности. Но тогда вряд ли получится согласовать данные для различных направлений. Будет трудно получать сквозные отчеты, учитывающие несколько подразделений организации. Между тем для бизнеса особый интерес представляют именно совокупные данные, а не отдельные элементы инфраструктуры. Таким образом, реально полезной для компании с точки зрения управления инфраструктурой ИТ и предоставляемыми ею услугами является информация об Учётных Элементах, хранение которой организовано в едином центральном хранилище, в соответствии с общими для всех типов Учётных Элементов правилами и возможностью легкого и быстрого доступа к ней. Пути построения системы управления с подобными требованиями рассматриваются в материалах библиотеки в области инфраструктуры информационных технологий (Information Technology Infrastructure Library – ITIL). Целью построения такой системы является:
Рекомендуется поэтапное внедрение, начинающееся с тщательного определения сервисов и корпоративных данных. Можно начать с контроля отдельных наиболее приоритетных Учётных Элементов, то есть тех, для которых контроль наиболее важен и перспективен. На начальном этапе следует определить, что входит в ИТ инфраструктуру и насколько подробно предполагается отслеживать её Учётные элементы. Излишне высокая степень детализации позволяет при необходимости учесть даже минимальные возможности и отклонения, однако требует существенных ресурсов на ведение Базы Данных Учётных Элементов. Стоит учитывать только те Учётные Элементы, которые действительно необходимы, и работа с которыми осуществляется регулярно или критична для бизнеса. Существенное внимание следует уделить разработке системы кодирования. Простейший вариант – перенумеровать всё по порядку, является самым дешёвым, но слабо будет помогать в дальнейшей деятельности. По Учётному коду должно быть понятно, к какому типу относится Учётный Элемент, и какой он версии. Таким образом, структурированная система кодирования намного полезнее. Для гарантии качества информации и соответствия данных реальному состоянию необходимы регулярные аудиторские проверки. В случае успешного и правильного внедрения процесса Управления конфигурациями пользователи получат:
На практике для оценки эффективности данного процесса используются метрики, такие как количество обращений к Базе Данных Учётных Элементов и др. Динамика изменений таких показателей, как количество успешных изменений комплексов и систем, среднее время устранения инцидентов и т.п., позволяет качественно и количественно оценить эффект от внедрения процесса управления конфигурациями. В случае если на предприятии ведется классифицированный учет трудозатрат специалистов, то по нему можно определить, что до половины своего рабочего времени специалист ИТ может тратить на повторные проверки и описания конфигураций отдельных комплексов и систем. Процесс управления конфигурациями обеспечивает необходимой информацией и экономит их время. Консультанты компании «Ай-Теко» обладают достаточной квалификацией и практическим опытом проведения проектов по внедрению и созданию системы автоматизации процесса управления конфигурациями. Ниже предлагается примерный вариант построения процесса:
ITIL® is a registered trade mark of OGC - the UK's Office of Government Commerce |
26. Проектирование ИС [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 5.2., 45.2. | Проектирование информационных систем. Управление персоналом. Коммуникации в проекте. | Повышев Владислав Вячеславович | Мила Сергеева | ОПЛ (Ден), готовый ответ Милы |
Готовый ответ Милы
Персонал играет важнейшую роль в проекте, именно персонал определяет временные и качественные характеристики проекта. Опыт реализации проектов свидетельствует о том, что, только сформировав подготовленную команду проекта, можно обеспечить запланированные результаты, то есть удачный итог.
Персонал проекта должен иметь определенный уровень подготовки, то есть это должны быть не "люди с улицы", а профессионалы своего дела, которые способны работать на "длинных дистанциях".
Когда подобрана команда, которая будет реализовывать проект, необходимо выбрать лидера, который будет в силах управлять такой командой, и распределить полномочия между лидером и остальным персоналом проекта.
Руководитель проекта берет на себя обязанности по выполнению широкого перечня задач: формирование бюджета, контроль сроков проекта, участие в согласовании требований к задачам проекта, оценка эффективности управления ресурсами, организация взаимодействия между персоналом проекта и между представителями заказчика. Руководитель проекта имеет важное право, право принятия решений. Он так же должен уметь вовремя заметить слабые места проекта, нейтрализовать их, а если нейтрализация невозможна, то тут же оповестить об этом руководство заказчика.
При распределении полномочий, почетных ролей и будущих бонусов, нужно напомнить всему персоналу проекта о том, что на них возложены ещё и обязательства, о которых не стоит забывать. Помимо команды проекта, в компании есть и другие сотрудники, им необходимо узнать о новом персонале будущего проекта и познакомиться с новыми коллегами. Ну и в конце, конечно же, необходимо обеспечить мотивацию команды.
Основные концепции управления персоналом, которые присущи условия рыночной экономики:
· концепция управления персоналом по результатам (Management by results);
· концепция управления песроналом на основе интеграции и контроля (Management by integration and self-control);
· концепция делегирования полномочий (Management by delegation);
· концепция вмешательства в исключительных случаях (Management by exception);
· концепция через постановку целей (Management by objectives);
· концепция управления персоналом посредством информационной системы (Management by system).
Персонал является своеобразным объектом управления в проекте, он — плавный переход между внешней и внутренней средой проекта. Персонал проекта обладает своими специфическими особенностями, поэтому его и выделяют как самостоятельный объект, к которому применяют технологии управления.
Система управления персоналом должна быть продумана и просчитана еще на этапе инициации проекта, т.е. значительно раньше выхода людей на работу. Здесь нужно учесть оплату труда, обучение и развитие персонала, долгосрочные и среднесрочные социальные программы. При этом следует принять во внимание, что набор самостоятельных и не зависящих друг от друга действий обычно бывает малоэффективен. Риски минимизируются, а проекты будут исполняться только в том случае, если компания готова и способна воспринимать управление персоналом как комплексную систему, органично вписывающуюся в ее другие системы.
Подход к оценке рисков, связанных с персоналом, должен быть таким же, как и подход к оценке иных (производственных, финансовых) рисков проекта. В этом руководителю проекта должны помогать инженер по управлению рисками и специалист по управлению персоналом.
Если после начала проекта возникло еще несколько подобных проектов у конкурентов, они вполне могут заняться целенаправленным переманиванием ключевых игроков вашей проектной команды.
Необходимо также заранее оговорить и зафиксировать условия выхода участников команды из проекта.
Если известно, что команда проекта молодая и не обладает 100%-ной компетенцией или достаточным опытом, то с самого начала нужно рассчитать финансовые и временные затраты и риски на обучение и развитие персонала и обсудить их вместе с заказчиком и спонсором проекта.
Необходимо двустороннее понимание условий найма и письменно зафиксировать достигнутые договоренности.
Для эффективной работы команда должна чувствовать - что бы ни случилось, она защищена. Здесь срабатывают три ключевых фактора - прозрачность, честность и своевременность.
Как показывает практика, командообразующие мероприятия, которые выполняют внешние тренеры или консультанты, являются, как правило, вспомогательным этапом формирования и укрепления той команды, которая создана руководителем. Для объединения специалистов в команду лучше всего на ранних стадиях проекта (еще до найма) познакомить финальных кандидатов не только с его руководителем, но и со всеми его участниками.
Следует отметить, что стиль управления руководителя проекта может быть любым. Универсальных рекомендаций здесь не существует.
Авторитарный менеджер наберет свою команду, которая будет работать с ним как с авторитарным лидером. Демократичный создаст свою совсем иную команду, которая может оказаться не менее эффективной. Как правило, атмосфера доверия бывает обусловлена либо однозначными приемами управления, либо его однозначными реакциями на то или иное событие.
Важным фактором является система материального вознаграждения. Часть заработной платы сотрудников проектной группы, по крайней мере ее основных участников, необходимо привязать к этапам выполнения проекта, изначально разработав систему стимулирования труда и распределения бонусной части. В долгосрочном проекте обязательно найдутся ключевые точки, по достижению которых заказчик будет оплачивать работу проектной команды. С другой стороны, следует избегать излишнего перекоса в сторону увеличения переменной части заработной платы. Фиксированная часть должна составлять не менее 40% от общего годового дохода сотрудника.
Еще одна особенность - обеспечение лояльности персонала как к самому проекту, так и к компании в целом.
Успех проекта значительно зависит от скорости принятия управленческих решений в команде. Чтобы быстро и своевременно оповещать о данных решениях всех заинтересованных сотрудников, необходимо осуществить распределение ролей в рамках проекта. Если все каналы связи и взаимодействия замкнутся на руководителе, вероятность того, что произойдет потеря информации, составляет 95%. Поэтому следует создать внутригрупповые, "горизонтальные" каналы коммуникации.
Избежать серьезных сложностей можно, правильно рассчитав и распределив загруженность персонала.
Руководитель - контролер "правильного" использования ресурсов проекта.
Достаточно частая и позитивная роль руководителя - "координатор" всех действий участников проекта для достижения результата.
Имеет смысл отнестись к подбору команды как к самостоятельному проекту со всеми его традиционными этапами.
Мероприятия в рамках управления персоналом следует планировать, реализовывать и адаптировать под текущую ситуацию на протяжении всего проекта.
Соответствие особенностей личности сотрудника качествам того или иного типа участников проектной группы еще не гарантирует эффективность результатов ее работы — менеджеру по персоналу необходимо помнить, что проектная группа — временное образование, главная цель которой — работа над новой идеей.
Идеально, если все сотрудники в процессе взаимодействия друг с другом имеют направленность на дело, а также достаточно высокую мотивацию к достижению успеха.
Уже в процессе работы проектной группы рекомендуется диагностировать психологический климат в коллективе.
Основу концепции управления персоналом проекта составляют следующие компоненты:
· возрастающая роль личности работника;
· знание его мотивационных установок;
· умение их формировать и направлять в соответствии с задачами, стоящими перед командой проекта.
Основными задачами системы управления персоналом команды в современных условиях являются:
· определение общей стратегии формирования команды проекта;
· планирование обеспечения проекта человеческими ресурсами;
· привлечение, отбор и оценка персонала;
· повышение квалификации и переподготовка персонала команды проекта;
· система продвижения по службе (управление карьерой членов команды);
· эффективное использование персонала в плане организации работ, рабочих мест, условий труда, социальных условий;
· управление заработной платой и затратами на персонал.
Система управления персоналом проекта характеризуется рядом параметров:
1) соответствие персонала целям и миссии проекта (уровень образования, квалификация, понимание миссии, отношение к работе);
2) эффективность системы работы с персоналом — соотношение затрат и результатов, потребность в инвестициях, выбор критериев оценки результатов работы с персоналом;
3) избыточность или недостаточность персонала, расчет потребности, планирование количества и качества;
4) сбалансированность персонала по определенным группам профессиональной деятельности и социально-психологических характеристик;
5) структура интересов и ценностей, превалирующих в группах персонала управления, их влияние на отношение к труду и его результаты;
6) ритмичность и напряженность деятельности, определяющие психологическое состояние и качество работы;
7) интеллектуальный и творческий потенциал персонала управления, отражающий подбор и использование персонала, организацию системы его развития.
Особенности поведения персонала:
| Тип поведения | Характеристика, особенности |
| Индивидуальное поведение | • Индивидуальные способности, склонность и одаренность — предрасположенность к реализации какой-либо деятельности, ориентация на ее выполнение |
| • Специфика мотивации — специфика потребностей человека, представление о целях профессиональной деятельности | |
| • Индивидуальные ценности — общие убеждения, вера, мировоззрения, представления о мире | |
| • Демографические — половые и возрастные особенности | |
| • Национальные и культурные особенности — усвоенные в опыте способы, правила и нормы поведения, которые детерминируют конкретные реакции человека в конкретных ситуациях | |
| Групповое поведение | • Особенности корпоративной культуры — ценности, правила поведения, характерные для конкретного трудового коллектива |
| • Феномены групповой динамики — этап развития коллектива, особенности лидерства, способа поведения в ситуации конфликта | |
| Поведение руководителей, членов управленческой команды | Руководителей можно рассматривать как: |
| • субъектов, имеющих индивидуальные особенности; | |
| • членов группы, обладающих корпоративной культурой; | |
| • функционеров определенной управленческой технологии (типа управления), обладающей своими правилами поведения |
Стратегия формирования команды проекта
| Стратегия | Содержание стратегии |
| Подбор специалистов | Этап определяет успешность работы команды и включает: |
| • определение формальных требований (образование, опыт, специальные навыки); эти требования могут быть довольно точно измерены; | |
| • определение индивидуально-психологических требований, которые учитывают как специфику деятельности, так и особенности людей, с которыми предстоит взаимодействовать новому сотруднику; | |
| • проведение предварительно конкурса рекомендаций и резюме, собеседование; | |
| • проведение оценки претендентов на основе психодиагностических методик, профессионального тестирования и методов ситуативной диагностики | |
| Адаптация | Включает цели и средства, позволяющие члену команды в совпадающий с испытательным сроком промежуток времени освоить свои обязанности, стандарты деятельности и поведения и выйти на приемлемый уровень эффективности деятельности в команде проекта |
| На завершающем этапе адаптационного периода проводятся контрольные процедуры, позволяющие оценить, насколько сотрудник освоил свое рабочее место, и принять решение об окончании испытательного срока | |
| Кадровый мониторинг | Предполагает проведение аттестаций и планирование карьеры. Позволяет руководству проекта получить ряд результатов: |
| • позитивный, «будоражащий» эффект; | |
| • возможность объективно оценить персонал; | |
| • получить информацию о том, какие характеристики сотрудников являются наиболее проблемными; | |
| • поставить перед сотрудником цели на профессиональное и личностное развитие до следующей аттестации; | |
| • сообщение сотрудникам о возможностях по развитию их карьеры, в том числе за счет придания новых функций и повышения ответственности | |
| Обучение и развитие | Предполагается различие между повышением профессиональной квалификации (обучение) и совершенствованием личностных характеристик (развитие). В данной стратегии значимость личностных характеристик, благоприятствующих реализации профессиональных задач, существенно выше значимости уровня квалификации, поскольку индивидуально-психологические характеристики могут блокировать эффективность профессиональной деятельности. Стратегия обучения и развития формируется по результатам оценивания на этапе подбора специалистов и их аттестации |
| Используется три варианта обучения и развития: | |
| • постоянно обновляемая система инструктажей, которые реализуются внутренними ресурсами команды проекта; | |
| • совокупность краткосрочных обучающих и развивающих программ (лекционных курсов, семинаров, программ психологического тренинга, предполагающих привлечение внешних ресурсов); | |
| • фундаментальная подготовка управленцев и специалистов в высших учебных заведениях | |
| Мотивация и стимулирование | Стратегия направлена на то, чтобы члены команды испытывали желание интенсивно и результативно работать именно в этой команде |
| Выделяют следующие связанные между собой мотивационные подсистемы материального и нематериального стимулирования, связанные с: | |
| • результатами деятельности; | |
| • стажем деятельности; | |
| • стабильностью стилевых характеристик деятельности и соответствием поведения ценностям команды проекта; | |
| • статусом | |
| Обеспечение взаимодействия | Стратегия направлена на достижение ясности и отчетливости в стандартах взаимодействия сотрудников и интересах достижения командой проекта своих целей |
| В рамках этой стратегии достигаются цели согласованных стилей управления, постановки задач, обязательных стандартов коммуникации и взаимной поддержки | |
| Стабилизация персонала | Предназначение — стабилизировать и сохранить наиболее полезных и лояльных сотрудников, костяк команды проекта, ориентированный на долгосрочную и эффективную работу |
Часто успех проекта напрямую зависит от взаимоотношений, сложившихся между его участниками.
В процессе управления информации используются: телефон, факс, письмо, совещание, доклад, электронная почта, телекоммуникации, видеоконференции, телетекстовые устройства.
Коммуникации и сопутствующая им информация являются своего рода фундаментом для обеспечения координации действий участников проекта.
Функция управления информационными связями включает в себя следующие процессы:
1. Планирование системы коммуникаций - определение информационных потребностей участников проекта (состав информации, сроки и способы доставки).
2. Сбор и распределение информации - процессы регулярного сбора и своевременной доставки необходимой информации участникам проекта.
3. Отчетность о ходе выполнения проекта - обработка фактических результатов состояния работ проекта, соотношение с плановыми и анализ тенденций, прогнозирование.
4. Документирование хода работ - сбор, обработка и организация хранения документации по проекту.
Технологии или методы распределения информации между участниками проекта могут значительно различаться в зависимости от параметров проекта и требований системы контроля. Выбор технологий взаимодействий определяется:
1. Степенью зависимости успеха проекта от актуальности данных или детальности описания
2. Доступностью технологий.
3. Квалификацией и подготовленностью кадров.
Как наладить общение между участниками проекта:
− Обеспечьте релевантность сообщений. Общение облегчается, когда сообщение содержит информацию, ценную именно для адресата, и у того появляется интерес.
− Уменьшайте сообщения, выражайтесь как можно проще.
− Постройте сообщение как последовательность простых частей.
Ответ прошлых лет (Ден)
Управление персоналом (англ. Human Resource Management, HRM) – область знаний и практической деятельности, направленная на обеспечение организации «качественным» персоналом и оптимальное его использование. Оптимальное использование персонала с точки зрения «управления персоналом» достигается за счёт выявления положительных и отрицательных мотивов индивидуумов и групп в организации и соответствующего стимулирования положительных мотивов и «погашения» отрицательных мотивов, а также анализа таковых воздействий. Управление персоналом является неотъемлемой частью качественных систем управления (менеджмента) в концепции контроллинга.
Управление персоналом включает в себя:
· Предварительные работы по поиску персонала:
o Поиск персонала
o Предварительная оценка персонала
o Подбор и отбор персонала
· Оперативную работу с персоналом:
o Оперативная оценка персонала
o Обучение и развитие персонала
o Управление бизнес-коммуникациями
o Мотивацию персонала
o Организацию труда
· Стратегическую (только долгосрочную) работу с персоналом:
o Управление корпоративной культурой.
К основным методам управления персоналом относят:
Экономические методы – приемы и способы воздействия на исполнителей с помощью конкретного соизмерения затрат и результатов (материальное стимулирование и санкции, финансирование и кредитование, зарплата, себестоимость, прибыль, цена).
Организационно-распорядительные методы – методы прямого воздействия, носящие директивный и обязательный характер. Они основаны на дисциплине, ответственности, власти, принуждении.
Социально-психологические методы (мотивация, моральное поощрение, социальное планирование и т. п.).
Коммуникации в проекте
Содержание плана управления коммуникациями
Как документ план управления коммуникациями является составной частью плана управления проектом или включается в него в виде вспомогательного плана и обычно содержит:
· требования к коммуникациям со стороны участников проекта;
· сведения о передаваемой информации, включая формат, содержание и уровень детализации;
· имя сотрудника, ответственного за передачу информации;
· имя сотрудника или группы - получателей данной информации;
· методы или технологии, используемые для передачи информации (например, служебная записка, электронная почта и/или пресс-релизы);
· частоту коммуникации (например, еженедельно);
· процедуры согласования документов;
· схему эскалации проблем;
· метод обновления плана управления коммуникациями по мере развития проекта;
· глоссарий общепринятой терминологии.
В план управления коммуникациями могут также включаться принципы проведения совещаний по текущему состоянию проекта, собраний команды проекта, электронных совещаний и рассылкам электронной почты.
27. Проектирование ИС [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 4.2., 33.3., 44.2. | Проектирование информационных систем. Управление процессом создания ИС. Процессы жизненного цикла проекта. ГОСТ 12207-99, ГОСТ Р 15271-2002 . | Маятин Александр Владимирович | Тоня Аркуша | ОПЛ (Ден), готовый ответ Тони |
Готовый ответ Тони
ГОСТ 12207-99 «Информационная технология ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ» устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Настоящий стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств.
Настоящий стандарт также определяет процесс, который может быть использован при определении, контроле и модернизации процессов жизненного цикла программных средств.
ГОСТ Р 15271-2002содержит рекомендации по применению ГОСТ 12207-99. В стандарте особое внимание уделено особенностям, подлежащим учету при прикладном применении ГОСТ Р 12207 в условиях реальных проектов создания программных средств.