Основные методологии разработки программного обеспечения

• Группа процессов инициирования
• Группа процессов планирования
• Группа процессов исполнения
• Группа процессов мониторинга и управления
• Группа завершающих процессов.

  ---

Рассматривает области знаний по управлению проектами:

• Управление интеграцией проекта
• Управление содержанием проекта
• Управление сроками проекта
• Управление стоимостью проекта
• Управление качеством проекта
• Управление человеческими ресурсами проекта
• Управление коммуникациями проекта
• Управление рисками проекта
• Управление поставками проекта

MSF

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.

MSF содержит:
модели:

• модель проектной группы
• модель процессов

дисциплины:

• дисциплина управление проектами
• дисциплина управление рисками
• дисциплина управление подготовкой

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.
MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды:
Распределение ответственности при фиксации отчетности
Наделяйте членов команды полномочиями
Концентрируйтесь на бизнес-приоритетах
Единое видение проекта
Проявляйте гибкость — будьте готовы к переменам
Поощряйте свободное общение
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):
Команда соратников
Сфокусированность на нуждах заказчика
Нацеленность на конечный результат
Установка на отсутствие дефектов
Стремление к самосовершенствованию
Заинтересованные команды работают эффективно
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из её ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над её достижением.
В проектную группу входят такие ролевые кластеры:
управление программой
управление продуктом
разработка
тестирование
управление релизом
удовлетворение потребителя
Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:
управление программой (program manager) — разработку архитектуры решения, административные службы;
разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;
тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;
управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;
управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
Роль команды разработчиков не может быть объединена ни с какой другой ролью.
Избежание сочетания ролей, имеющих предопределенные конфликты интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней — в эффективно работающей команде каждый её член имеет необходимые полномочия для выполнения своих обязанностей и уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.
Процесс MSF ориентирован на «вехи» (milestones) — ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.
Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:
Подход, основанный на фазах и вехах.
Итеративный подход.
Интегрированный подход к созданию и внедрению решений.
Модель процессов включает такие основные фазы процесса разработки:
Выработка концепции (Envisioning)
Планирование (Planning)
Разработка (Developing)
Стабилизация (Stabilizing)
Внедрение (Deploying)
Кроме этого существует большое количество промежуточных вех, которые показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки. Для каждой фазы модели процессов MSF определяет:
что (какие артефакты) является результатом этой фазы
над чем работает каждый из ролевых кластеров на этой фазе
В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения.
Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.
Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение — вплоть до момента, когда решение начинает давать отдачу.
Управление рисками[править | править исходный текст]
Управление рисками (risk management) — это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF — мы не боремся с рисками — мы ими управляем.
Управление проектами[править | править исходный текст]
Проект (project) — ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Управление проектами (project management) — это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют так называемый «треугольник компромиссов». Нахождение верного баланса между ресурсами, временем разработки и возможностями — ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.
Другое весьма полезное средство для управления проектными компромиссами — матрица компромиссов проекта (project tradeoff matrix). Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам.
Для иллюстрации использования матрицы компромиссов Майкрософт предлагает использовать следующее предложение (вместо пропущенных слов могут быть вставлены «календарный график», «ресурсы» и «функциональность»): «Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________».
Как уже говорилось выше, в MSF нет роли «менеджер проекта». Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером «Управление программой».
Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ (Work Breakdown Structure — WBS) — это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.
Управление подготовкой[править | править исходный текст]
Управление подготовкой — это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.
Следует отметить, что MSF не навязывает использование других продуктов Microsoft. Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland, хотя будущая версия MSF 4.0 будет жестко привязана к Microsoft Team System — новому инструментальному средству Майкрософт для поддержки командной работы над проектами.

Agile

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики экстремальное программирование, DSDM, Scrum.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

Принципы[править | править исходный текст]

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.
Основные идеи:
Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto[2]:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Критика[править | править исходный текст]

Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

RUP

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

Принципы

В основе RUP лежат следующие принципы:

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

Жизненный цикл разработки

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

 Процессный подход

При процессном подходе управление рассматривается как процесс — серия взаимосвязанных непрерывных действий. Эти действия называют управленческими функциями.
Каждая управленческая функция тоже представляет процесс, потому что также состоит из серии взаимосвязанных действий. Процесс управления является общей суммой всех функций.
Существует несколько взглядов на состав функций управления, наиболее признанными считаются следующие функции — ПЛАНИРОВАНИЕ, ОРГАНИЗАЦИЯ, МОТИВАЦИЯ И КОНТРОЛЬ. Эти четыре первичных функции управления объединены связующими процессами коммуникации и принятия решения.
Функция планирования
Функция планирования предполагает решение о том, какими должны быть цели организации и что надо делать, чтобы достичь этих целей. По своей сути, функция планирования отвечает на три следующих основных вопроса:
: а) Где мы находимся в настоящее время? Руководители должны оценивать сильные и слабые стороны организации в таких важных вопросах как: финансы, производство, сбыт, научные исследования и разработки, трудовые и другие ресурсы. Все это осуществляется для определения реальных возможностей организации. С другой стороны необходимо изучить состояние в данный момент и сделать прогноз возможных состояний внешней среды организации.
б) Куда мы хотим двигаться? Оценивая возможности и угрозы в окружающей организацию среде, такие как конкуренция, заказчики, законы, экономические условия, технология, снабжение, социальные и культурные изменения, руководство определяет цели организации.
в) Как мы собираемся сделать это? Руководители должны решать как в общих чертах, так и конкретно, что надо делать для достижения поставленных целей.
Таким образом, планирование — это один из способов, с помощью которого руководство обеспечивает единое направление усилий всех членов организации к достижению её общих целей. (Следует отметить, что это определение планирования дано с точки зрения функций управления. Есть другие более общие определения планирования).
Планирование в организации не представляет собой одноразового события. Во-первых, решив задачу данного этапа, которой соответствовал данный план, организация переходит к следующему этапу и планирование продолжается. Вторая причина, по которой планирование должно осуществляться непрерывно, — это постоянная неопределенность будущего. В силу изменений в окружающей среде или ошибок в суждениях, события могут развиваться не так, как это предвидело руководство при выработке планов. Поэтому планы должны пересматриваться, чтобы они согласовывались с реальностью.
Организация как функция
Организовать — значить создать некую структуру, чтобы предприятие могло выполнить свои планы и тем самым достигать своей цели. На любом предприятии работу выполняют люди, важным аспектом функции организации является определение, кто именно должен выполнять каждое конкретное задание из большого количества таких заданий, существующих в рамках организации, включая работу по управлению. Руководитель подбирает людей для конкретной работы, делегируя отдельным работником задания и полномочия или права использовать ресурсы организации. Эти субъекты делегирования принимают на себя ответственность за успешное выполнение своих обязанностей. Поступая таким образом, они соглашаются считать себя подчиненными по отношению к руководителю. Делегирование — это средство, с помощью которого руководство осуществляет выполнение работы с помощью других лиц. Концепция внесения систематического начала в организацию работы и деятельности людей может быть расширена до создания структуры организации в целом.
Мотивация
Руководитель должен всегда помнить, что даже прекрасно составленные планы и самая совершенная структура организации не имеют никакого смысла, если кто-то не выполняет фактическую работу организации. Задача функции мотивации заключается в том, чтобы члены организации выполняли работу в соответствии с порученными им обязанностями и в соответствии с планом.
Руководители всегда осуществляли функцию мотивации своих работников, осознавали они это сами или нет. В древние времена служили для этого хлыст и угрозы, а для немногочисленных избранных — награды. С конца ХVIII и по ХХ век было широко распространено убеждение, что люди всегда будут работать больше, если у них имеется возможность заработать больше. Считалось, таким образом, что мотивирование — это простой процесс, сводящийся к предложению соответствующих денежных вознаграждений в обмен за прилагаемые усилия. На этом основывался подход к мотивации школы научного управления.
Исследования в области поведенческих наук показали недостаточность чисто экономического подхода. Руководители узнали, что мотивация, то есть создание внутреннего побуждения к действиям, является результатом сложной совокупности потребностей, которые постоянно меняются. Установлено, что для того, чтобы мотивировать своих работников эффективно, руководителю следует определить, каковы же на самом деле потребности, и обеспечить условия для работников, удовлетворить эти потребности через хорошую работу.
Контроль
Контроль — это процесс обеспечения того, что организация действительно достигает своих целей. В схеме функций управления, из блока контроля стрелка возвращает процесс управления к планированию, обеспечивая обратную связь. Существуют три аспекта управленческого контроля.
УСТАНОВЛЕНИЕ СТАНДАРТОВ — это точное определение целей, которые должны быть достигнуты в обозначенный отрезок времени. Оно основывается на планах, разработанных в процессе планирования. Второй аспект — это ИЗМЕРЕНИЕ того, что было в действительности достигнуто за определенный период времени, и сравнение достигнутого с ожидаемыми результатами. Если обе эти фазы выполнены правильно, то руководство организации может достаточно точно сформулировать (описать) проблему. Это, в свою очередь, необходимо для успешного осуществления третьей фазы — стадии, на которой предпринимаются действия, для коррекции отклонений от первоначального плана. Одно из возможных действий — пересмотр целей, для того, чтобы они стали более реалистичными и соответствовали новой ситуации.
Связующие процессы
Четыре функции управления — планирование, организация, мотивация и контроль — имеют две общие характеристики. Все они требуют принятия решений, и для всех необходима коммуникация, обмен информацией, чтобы получить информацию для принятия правильного решения и сделать это решение понятным для других членов организации. Из-за того, что эти две характеристики связывают все четыре управленческие функции, обеспечивая их взаимозависимость, коммуникации и принятие решений часто называют связующими процессами. ПРИНЯТИЕ РЕШЕНИЙ. Управленческая работа — это, в основном, работа интеллектуальная. Она напоминает попытку сложить мозаичный узор из отдельных кусочков. При этом руководителям приходится перебирать многочисленные комбинации возможных действий для того, чтобы найти правильное действие для данной ситуации в данное время и в данном месте. Выбор одной из альтернатив — это решение. Следовательно, принятие решения — это выбор того, как и что, планировать, организовать, мотивировать и контролировать. В самых общих чертах именно это составляет основное содержание деятельности руководителя.
Наличие точной информации является основным требованием для принятия эффективного объективного решения или даже для понимания истинных масштабов проблемы является. Единственным способом получения такой информации является коммуникация.
Коммуникация
Коммуникация — это процесс обмена информацией, её смысловым значением между двумя и более людьми.
Информация в процессе коммуникации передается не только для того, чтобы могли приниматься разумные решения, но также и для того, чтобы они могли выполняться. Например, до тех пор пока работники не понимают, какое вознаграждение им может предложить организация за хорошо выполненную работу, они не могут быть достаточно мотивированы и хорошо работать на неё. Коммуникация также важна и в функции контроля. Руководители нуждаются в информации относительно того, что было выполнено для правильной оценки достижения целей организации.
Основная цель коммуникационного процесса — обеспечение понимания информации, являющейся предметом обмена, то есть сообщения. Однако сам факт обмена информацией не гарантирует эффективности общения участвующих в обмене людей. Чтобы лучше понимать процесс обмена информацией и условия его эффективности, необходимо рассмотреть основные стадии процесса, в котором участвуют двое или большее число людей.
В процессе обмена информацией можно выделить четыре базовых элемента.
1. Отправитель — лицо, генерирующее идеи или собирающее информацию и передающее её.
2. Сообщение — собственно информация, закодированная с помощью символов.
3. Канал — средства передачи информации.
4. Получатель — лицо, которому предназначается информация и которое интерпретирует её.
При обмене информацией отправитель и получатель проходят несколько взаимосвязанных этапов. Задача этих этапов — составить сообщение и использовать канал для его передачи таким образом, чтобы обе стороны поняли исходящую идею (информацию). Это трудно, так как каждый этап является одновременно точкой, в которой смысл информации может быть искажен или полностью утрачен. Обычно выделяют четыре взаимосвязанных этапа коммуникации:
1. Зарождение идеи (сбор информации).
2. Кодирование и выбор каналов.
3. Передача.
4. Декодирование.
Хотя весь процесс коммуникации может занять несколько секунд, во время прохождения отдельных этапов могут возникать различные проблемы, снижающие эффективность коммуникации.
ЗАРОЖДЕНИЕ ИДЕИ. Обмен информацией начинается с формирования идеи или отбора информации. Отправитель решает, какую значимую идею или сообщение следует сделать предметом обмена. Без необходимой проработки (обдумывания) этого этапа процесс коммуникаций может не состояться. Необходимо учитывать, что идея ещё не трансформирована в слова или не приобрела другой такой формы, в которой она послужит обмену информацией. К примеру, руководитель, желающий обменяться информацией об оценке результатов работы, должен четко понимать, что идея состоит в том, чтобы сообщить подчиненным конкретную информацию об их сильных и слабых сторонах и о том, как можно улучшить результаты их работы. Идея не может заключаться в чисто эмоциональном одобрении или критике поведения подчиненных.
Когда руководитель собирается сообщить о предстоящих изменениях рабочим, то процесс коммуникации будет эффективным, если передаваемая информация будет содержать конкретные указания — какие изменения нужны, почему эти изменения нужны и каким образом следует осуществить эти изменения.
КОДИРОВАНИЕ И ВЫБОР КАНАЛА. Прежде чем передать идею, отправитель должен с помощью символов закодировать её, использовав для этого слова, интонацию и жесты. Такое кодирование превращает идею в сообщение. Отправитель должен также выбрать канал совместимый с типом символов, используемых для кодирования. К некоторым общеизвестным каналам относятся передача речи и письменных материалов, а также электронные средства связи, включая компьютерные сети.
Часто используются несколько средств сообщения — приказ на доске информации может дополняться устными разъяснениями руководителя.

ПЕРЕДАЧА. На третьем этапе отправитель использует каналы для доставки сообщения (закодированной идеи) получателю. Здесь осуществляется физическая передача информации, которую часто ошибочно считают коммуникацией.
ДЕКОДИРОВАНИЕ. После передачи сообщения отправителем получатель декодирует его. Декодирование — это перевод символов отправителя в мысли получателя. Если символы, выбранные отправителем, имеют точно такое же значение для получателя, то он поймет идею отправителя. Если реакции на идею не требуется, процесс обмена информацией на этом может закончиться.

ООП

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

Компонентное программирование — следующий этап развития ООП; прототип- и класс-ориентированное программирование — разные подходы к созданию программы, которые могут комбинироваться, имеющие свои преимущества и недостатки.
Компонентное программирование[править | править исходный текст]
Компонентно-ориентированное программирование — это своеобразная «надстройка» над ООП, набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни. Программная система в этой методологии представляет собой набор компонентов с хорошо определёнными интерфейсами. Изменения в существующую систему вносятся путём создания новых компонентов в дополнение или в качестве замены ранее существующих. При создании новых компонентов на основе ранее созданных запрещено использование наследования реализации — новый компонент может наследовать лишь интерфейсы базового. Таким образом компонентное программирование обходит проблему хрупкости базового класса.
Прототипное программирование[править | править исходный текст]
Прототипное программирование, сохранив часть черт ООП, отказалось от базовых понятий — класса и наследования.
Вместо механизма описания классов и порождения экземпляров язык предоставляет механизм создания объекта (путём задания набора полей и методов, которые объект должен иметь) и механизм клонирования объектов.
Каждый вновь созданный объект является «экземпляром без класса». Каждый объект может стать прототипом — быть использован для создания нового объекта с помощью операции клонирования. После клонирования новый объект может быть изменён, в частности, дополнен новыми полями и методами.
Клонированный объект либо становится полной копией прототипа, хранящей все значения его полей и дублирующей его методы, либо сохраняет ссылку на прототип, не включая в себя клонированных полей и методов до тех пор, пока они не будут изменены. В последнем случае среда исполнения обеспечивает механизм делегирования — если при обращении к объекту он сам не содержит нужного метода или поля данных, вызов передаётся прототипу, от него, при необходимости — дальше по цепочке.
Класс-ориентированное программирование[править | править исходный текст]
Question book-4.svg
в разделе не хватает ссылок на источники информации.
Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.
Эта отметка установлена 31 декабря 2012.
Класс-ориентированное программирование — это программирование, сфокусированное на данных, причем данные и поведение неразрывно связаны между собой. Вместе данные и поведение представляют собой класс. Соответственно в языках, основанных на понятии «класс», все объекты разделены на два основных типа — классы и экземпляры. Класс определяет структуру и функциональность (поведение), одинаковую для всех экземпляров данного класса. Экземпляр является носителем данных — то есть обладает состоянием, меняющимся в соответствии с поведением, заданным классом. В класс-ориентированных языках новый экземпляр создаётся через вызов конструктора класса (возможно, с набором параметров). Получившийся экземпляр имеет структуру и поведение, жёстко заданные его классом.

 IDEF0

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна?я последовательность (WorkFlow).
Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны : — стрелка входа приходит всегда в левую кромку активности, — стрелка управления — в верхнюю кромку, — стрелка механизма — нижняя кромка, — стрелка выхода — правая кромка.
Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку.
Также отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

EPC

Событийная цепочка процессов (EPC-диаграмма, англ. event-driven process chain) — тип блок-схемы, используемой для бизнес-моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия (ERP),[1] и для улучшений бизнес-процессов.
Описание

Организации используют EPC-диаграммы для планирования потоков работ бизнес-процессов. Существует ряд инструментов для создания EPC-диаграмм, например, набор инструментов ARIS и ARIS Express[2], Adonis от BOC Group[3], Mavim Rules от Mavim BV,[4], Business Process Visual Architect от Visual Paradigm, Semtalk от Semtation GmbH, или Bonapart от Pikos GmbH. Некоторые из этих средств поддерживают инструментонезависимый формат обмена данными EPC — язык разметки EPML. EPC-диаграммы используют символы нескольких видов, чтобы показать структуру потока управления (последовательность решений, функции, события и другие элементы) бизнес-процесса.
EPC-метод был разработан Августом-Вильгельмом Шеером в рамках работ над созданием ARIS в начале 1990-х годов.[5] Используется многими организациями для моделирования, анализа и реорганизации бизнес-процессов.
Элементы событийных цепочек процессов[править | править исходный текст]

Elements of an Event-driven Process Chain.svg
События являются пассивными элементами в EPC. Событием является состояние, которое встречается перед или после функции, то есть фиксирует состояние определённых параметров на определенный момент времени. Примеры событий: «договор подписан», «требование зафиксировано», «материал на складе». В EPC график событий представлен в виде шестиугольника. EPC-диаграммы должны как начаться с события, так и заканчиваются событием.
Функции являются активными элементами в EPC. Работа — определенное действие, выполняемое в течение некоторого промежутка времени. Каждая работа может быть декомпозирована.
Организационная единица — должность в организации (например, «старший мастер») или подразделение организации (например, «отдел закупок»), элемент, которому может быть поручено выполнение функции.
Информация, материал, или объект ресурса — объекты в реальном мире, например бизнес-объекты, различные сущности, которые могут быть как входными данными, выступающими в качестве основы функции, так и выходными данными, полученными с помощью функции. Примерами являются «материал», «заказ», изображается в виде прямоугольника.
Логический соединитель — элемент управления в диаграмме, определяющий ветвление потока работ в зависимости от завершения выполнения функции или возникновения событий.

Если функция F1 завершилось, то произойдет либо событие E1, либо событие E2

Если произошло либо событие E1, либо событие E2, тогда начинается функция F1
Логические взаимосвязи — элементы управления, отвечающие за сочленение потоков — конъюнкция, дизъюнкция или строгая дизъюнкция.
Поток управления соединяет события с функциями, путями процесса или логическими взаимосвязями, создавая хронологическую последовательность или логическую взаимозависимость между ними. Поток управления представлен как пунктирная стрелка.
Поток информации — соединение функции и входящих и исходящих данных, с которых функция считывает изменения или сама их вносит.
Назначение организационный единицы — связь между организационной единицей и функцией, за которую она ответственна.
Путь процесса — элемент, показывающий взаимосвязь с другими процессами.

UML

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

Использование

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