Типы стратегий. 1 Запланированная стратегия

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

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

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

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

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

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

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

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

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

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

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

Основные фазы эволюции методов обеспечения качества. Роль стандартов в обеспечении качества.

1.3.2 Эволюция методов обеспечения качества

В истории качества существует пять перекрывающихся и продолжающихся фаз:

фаза отбраковки;

фаза контроля качества;

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

фаза менеджмента качества;

фаза качества среды.

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

Пример. Выдающийся вклад в развитие этой фазы внесли американские автомобилестроители – Генри Мартин Леланд (основатель фирмы «Кадиллак») и Генри Форд. Леланд впервые применил в автомобильном производстве работу по калибрам и придумал пару – «проходной» и «непроходной» калибр. В марте 1908 г. эксперты Британского автомотоклуба отобрали случайным образом три экземпляра из экспортной партии автомобилей «Кадиллак», прибывшей в Англию, и разобрали их до последнего винтика. Все детали свалили в кучу, а затем кое-какие детали заменили запчастями, позаимствованными, опять же наугад, в местном агентстве по продаже и обслуживанию автомобилей «Кадиллак». Потом группа механиков, вооружённая только отвёртками и гаечными ключами, собрала машины заново и запустила моторы. Две машины завелись с первой попытки, одна – со второй, и все они отправились на длительную обкатку по только что сданному в эксплуатацию автодрому Бруклэндс. И когда вновь собранные машины подтвердили полную идентичность своих ходовых характеристик параметрам автомобилей заводской сборки, Британский автомотоклуб выдал фирме «Кадиллак» диплом и серебряный кубок с надписью «За стандартизацию». После этого на табличке с логотипом фирмы на автомобилях «Кадиллак» появилась надпись «Standardoftheworld» – мировой стандарт.

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

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

труда.

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

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

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

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

Фаза контроля качества начинается с 20-х годов ХХ века как попытка если не разрешить, то ослабить противоречие в форме, свойственной предыдущей фазе развития качества. Точкой отсчёта считаются работы, выполненные в отделе технического контроля фирмы «Вестерн электрик», США. В мае 1924 г. сотрудник отдела доктор Шухарт передал своему начальнику короткую записку, которая содержала метод построения диаграмм, известных теперь как контрольные карты Шухарта. Статистические методы, предложенные Шухартом, дали в руки управленцев инструмент, который позволил сосредоточить усилия не на том, как обнаружить и изъять негодные изделия до их отгрузки покупателю, а на том, как увеличить выход годных изделий в технологическом процессе.

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

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

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

Фаза управления качеством. Начало данной фазы управления качеством принято отсчитывать с 1950 г. Поворотным событием стало выступление с лекциями перед ведущими промышленниками Японии американца доктора Эдварда Деминга. За 12 лекций доктор Деминг встретился с сотнями ведущих менеджеров японских фирм. Им, а также Джозефом М. Джураном, другим американцем, также приглашённым в порядке правительственной технической помощи в Японию, была разработана программа, главная идея которой состояла в следующем: «Основа качества продукции – качество труда и качественное управление на всех уровнях, то есть такая организация работы коллективов людей, когда каждый работник получает удовольствие от своей работы».

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

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

В 50 – 60-х годах в странах Европы стали уделять большое внимание документированию систем обеспечения качества и их регистрации или сертификации третьей (независимой) стороной. Особенно следует отметить британский стандарт BS7750, значительно поднявший интерес европейцев к проблеме обеспечения качества и сертификации систем качества.

В середине 50-х годов в Советском Союзе возникла первая система качества – Саратовская система бездефектного изготовления продукции и сдачи её с первого предъявления. Она предусматривала постоянное внимание всего коллектива предприятия к качеству продукции.

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

Всё больше внимания стало уделяться учёбе. В Японии и Южной Корее работники стали учиться в среднем от нескольких недель до месяца, используя в том числе самообучение.

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

- стоимость всего комплекса НИОКР, предшествующих серийному производству;

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

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

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

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

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

Основой концепции новой фазы стали:

- идея, что большая часть дефектов изделий закладывается на стадии разработки из-за недостаточного качества проектных работ;

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

- концепция «удовлетворённого потребителя», занявшая место концепции «ноль дефектов»;

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

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

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

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

Пример.В 70-е годы ХХ века среди специалистов был популярен пример всемирно известной компании «Volvo». Компания достигла резкого экономического подъёма, когда перешла от чисто конвейерного производства к образованию рабочих групп. В конвейерном производстве рабочий монотонно изо дня в день выполнял одну и ту же операцию, практически абстрагируясь от результата своего труда. В поисках возможности резкого повышения качества своих автомобилей руководство фирмы пришло к идее создания рабочих групп, которые выполняли бы определённую законченную часть процесса сборки. Если раньше, у конвейера, рабочий мог выполнять лишь ограниченное число простейших операций, то в группе благодаря созданию соответствующего микроклимата появилась необходимость и обязанность освоить все операции, закреплённые за группой. Производственные навыки и общий кругозор каждого рабочего расширились. Повысилась компетентность каждого в отдельности и, естественно, группы в целом. Принятие решений облегчилось, уровень дефектности снизился, а производительность увеличилась.

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

Фаза качества среды. В 90-е годы ХХ века усилилось влияние общества на предприятия, а последние стали всё больше учитывать интересы общества. Это привело к появлению стандартов ИСО 14000, устанавливающих требования к системам менеджмента с точки зрения защиты окружающей среды, к безопасности продукции. В соответствии со стандартом ИСО 14000 в каждой организации должны быть:

- введены определённые экологические процедуры;

- осуществлены меры по строгому их соблюдению;

- подготовлены пакеты документов;

- назначены ответственные за определённые области экологической деятельности.

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

1) организационном – через улучшение экологического «поведения» фирм;

2) национальном – через создание государственной экологической политики;

3) международном – через улучшение условий международной торговли.

Сертификация систем качества на соответствие стандартам

ИСО 14000 становится не менее популярной, чем на соответствие стандартам ИСО 9000. существенно возросло влияние гуманистической составляющей качества. Усиливается внимание руководителей предприятий к удовлетворению потребностей своего персонала.

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

SO12207. Процессы обеспечения качества, верификации и аттестации.

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

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

Процесс обеспечения качества включает действия:

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

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

обеспечение качества процесса предполагает гарантирование соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам;

обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом ISO 9001.

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

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

Процесс верификации включает следующие действия:

подготовительную работу;

верификацию;

В процесс верификации проверяются следующие условия:

непротиворечивость требований к системе и степень учета потребностей пользователей;

возможности поставщика выполнять заданные требования;

соответствие выбранных процессов ЖЦ ПО условиям договора;

адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

соответствие проектных спецификаций ПО заданным требованиям;

корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

соответствие кода проектным спецификациям и требованиям;

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

корректность интеграции компонентов ПО в систему;

адекватность, полнота и непротиворечивость документации.

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

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

27.Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

28.

Что такое СММ

Модель технологической зрелости (СММ) согласно определению, приведенному в [3], — это описание стадий эволюции, которые проходят организации-разработчики по мере того, как они (организации) определяют, реализуют, измеряют, контролируют и совершенствуют процессы создания ПО. Эта модель помогает организации выбрать адекватную стратегию усовершенствования этих процессов, предоставляя методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО. В основу СММ положен ряд фундаментальных понятий [2, 3]:

Технология, Технологический процесс, Процесс (Process) — последовательность шагов (действий), предпринимаемых с заданной целью [IEEE-Std-610].

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

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

Зрелость технологии (Process Maturity) — степень определенности, управляемости, наблюдаемости, контролируемости и эффективности данной технологии. Фактически, это индикатор полноты технологии и степени последовательности (настойчивости) организации в ее применении на всех проектах. Зрелость определяет потенциал дальнейшего роста совершенства технологии/процесса.

Пять уровней технологической зрелости

Разработчики модели СММ (SEI) определили пять уровней технологической зрелости, по которым заказчики могут оценивать потенциальных поставщиков (претендентов на получение контракта), а поставщики могут совершенствовать процессы создания ПО Каждому из показанных на рисунке уровней технологической зрелости внутри модели СММ дано следующее краткое определение:

Уровень 1: Начальный (Initial) — технология разработки ПО характеризуется как произвольная (импровизированная), в некоторых случаях — даже хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников.

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

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

Уровень 4: Управляемый (Managed) — детальные метрики (объективные данные) о качестве исполнения процессов и выходной продукции собираются и накапливаются. Управление процессами и выходной продукцией осуществляется по количественным оценкам.

Уровень 5: Оптимизируемый (Optimized) — совершенствование технологии создания ПО осуществляется непрерывно на основе количественной обратной связи от процессов и пилотного внедрения инновационных идей.

29 ISO15504. Эталонная и совместимая модели стандарта ISO15504.

. СО/МЭК ТО 15504-2 определяет эталонную модель процессов и их зрелости, которая формирует базис для любой модели, используемой для аттестации процессов. Эталонная модель содержит двумерный подход к оцениванию зрелости процессов - одно измерение определяет процессы, подлежащие аттестации, другое описывает шкалу для измерения зрелости. Любая модель или модели, совместимые с эталонной моделью, могут использоваться для аттестации, и результаты любых соответствующих стандарту аттестаций можно будет привести к единой баз

е.

Совместимая модель – это модель, отвечающая требованиям, сформулированным в ИСО/МЭК ТО 15504-2. Вкратце, совместимая модель, это модель:

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

чьи фундаментальные элементы могут быть сопоставлены и сопоставляются с измерениями «процесс» и «зрелость» эталонной модели из ИСО/МЭК ТО 15504-2;

которая содержит набор показателей для применения во время аттестации для сбора информации о процессах и их атрибутах;

которая имеет формальный механизм преобразования информации, собранной с применением модели, в рейтинги атрибутов процессов, как описано в ИСО/МЭК ТО 15504-2.

30. ISO15504. Схема проведения и факторы успеха процесса аттестации.

Факторы успеха аттестации процессов

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

[ИСО/МЭК ТО 15504-3, 4.4.1]

Безотносительно типа аттестации или выбранного подхода, аттестация должна проводится в соответствии с документированным процессом. Некоторые ключевые элементы кратко описаны ниже и более детально – в разделах 5, 6 и 7. Следует однако заметить, что приведенные указания не составляют полного, документированного процесса. Их роль в том, чтобы помочь интерпретировать требования из ИСО/МЭК ТО 15504-2 и ИСО/МЭК ТО 15504-3 и обеспечить отправную точку для выбора или создания документированного процесса.

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

Следующие факторы существенны для успешной аттестации процессов.

4.7.1 Обязательства

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

4.7.2 Мотивация

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

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

4.7.3 Конфиденциальность

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

4.7.4 Релевантность

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

4.7.5 Доверие

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

31.

32компьютинг

Определения в Интернете

вычисление, выполняемое на компьютере

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

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

Программная инженерия, как наука, обладает рядом особенностей:

• Основанием программной инженерии является информатика, а не естественные науки.

• Основной упор делается на дискретную, а не на непрерывную математику.

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

• Отсутствие «производственной» фазы в традиционном промышленном смысле.

• «Сопровождение» программного обеспечения, в основном, связано с продолжающейся разработкой или эволюцией, а не с традиционным физическим износом.

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

33.

" Основы программной инженерии" -- это российский перевод (с замечаниями и комментариями) известного руководства Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 Version.

Проект SWEBOK был инициирован Software Engineering Coordinating Committee, совместным комитетом IEEE и ACM, в 1998 году. Учитывая значимость этого проекта для индустрии, SWEBOK Advisory Committee (SWAC) принял решение сделать SWEBOK общедоступным – https://www.swebok.org. Проект SWEBOK планировался в виде трех фаз. К 2004 году была выпущена версия Руководства по Своду Знаний максимально приближенная к окончательному варианту и одобренная IEEE в феврале 2005 года к публикации в качестве Trial-версии.

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

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

SWEBOK описывает 10 областей знаний:

Software requirements – программные требования

Software design – дизайн (архитектура)

Software construction – конструирование программного обеспечения

Software testing - тестирование

Software maintenance – эксплуатация (поддержка) программного обеспечения

Software configuration management – конфигурационное управление

Software engineering management – управление в программной инженерии

Software engineering process – процессы программной инженерии

Software engineering tools and methods – инструменты и методы

Software quality – качество программного обеспечения

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

Computer engineering

Computer science

Management

Mathematics

Project management

Quality management

Systems engineering

34/

Анализ и характеристика областей знаний SWEBOK

Ядро знаний SWEBOK является основополагающим научно-техническим документом, который отображает мнение многих зарубежных и отечественных специалистов в области программной инженерии [1.3-1.12] и согласуется с современными регламентированными процессами ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10 областей, каждая из которых представлена согласно принятой всеми участниками создания этого ядра общей схемы описания, включающей определение понятийного аппарата, методов и средств, а также инструментов поддержки инженерной деятельности. В каждой области описывается определенный запас знаний, который должен практически использоваться в соответствующих процессах ЖЦ.

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

Основные области знаний SWEBOK

Рис. 1.2. Организационные области знаний SWEBO

В каждой области приведены ключевые понятия, подходы и методы проектирования разных типов ПС. Данное разбиение областей на основные и вспомогательные соответствует структуре разбиения процессов стандарта ISO/IEC 12207 (см. раздел 1.2), выполнение которых определяется знаниями, содержащимися в ядре SWEBOK.

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

35Проектирование и конструирование программного обеспечения по SWEBOK.

Проектирование ПО (Software design)

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

базовые концепции проектирования ПО (Software Design Basic Concepts),

ключевые вопросы проектирования ПО (Key Issue in Software Design),

структура и архитектура ПО (Software Structure and Architecture),

анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),

нотации проектирования ПО (Software Design Notations),

стратегия и методы проектирования ПО (Software Design Strategies and Methods).

Базовая концепция проектирования ПО - это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др.), процессы ЖЦ (стандарт ISO/IEC 12207) и техники - декомпозиция, абстракция, инкапсуляция и др. На начальных стадиях проектирования предметная область декомпозируется на отдельные объекты (при объектно-ориентированном проектировании) или на компоненты (при компонентном проектировании). Для представления архитектуры программного обеспечения выбираются соответствующие артефакты (нотации, диаграммы, блок-схемы и методы).

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

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

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

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

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

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

Структурные нотации - это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. К нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания

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

Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений (Decision Tables), деятельности (Activity), кооперации (Colloboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM, RAISE), языки проектирования PDL и др.

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

В объектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов. Подходы, ориентированные на структуры данных, базируются на методе Джексона [1.8] и используются для задания входных и выходных данных структурными диаграммами. Метод UML предназначен для сценарного моделирования проекта [1.19] в наглядном диаграммном виде. Компонентное проектирование ориентировано на использование готовых компонентов (reusing), их интерфейсов и интеграцию для формирования конфигурации, служащей основой развертывания компонентного ПО и взаимодействия компонентов в операционной среде.

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

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

1.1.3. Конструирование ПО (Software Construction)

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

Область знаний " Конструирование ПО (Software Construction)" включает следующие разделы:

снижение сложности (Reduction in Complexity),

предупреждение отклонений от стиля (Anticipation of Diversity),

структуризация проверок (Structuring for Validation),

использование внешних стандартов (Use of External Standards)

Снижения сложности - это минимизация, уменьшение и локализация сложности конструирования.

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

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

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

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

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

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

Визуальный стиль является наиболее универсальным стилем конструирования ПО, он позволяет разработчикам проекта представлять конструируемый элемент в наглядном виде. Визуальный язык проектирования UML представляет разработчику набор удобных диаграмм для задания статической и динамической структуры ПО [1.17]. При применении визуального стиля конструирования создается текстовое и диаграммное описание конструктивных элементов ПО, которое выводится на экран дисплея не только для их наглядного представления, но и корректировки.

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

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

Иными словами, внешние и внутренние стандарты должны определить общие правила работы членов проектной команды с учетом процессов ЖЦ. Такими стандартами являются: языки программирования (например, Java Language Specification, С++), интерфейсы ЯП и прикладные интерфейсы платформ Windows и др. При конструировании используются стандарты: ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсных языков (POSIX, IDL, APL) [1.18], сценарии UML [1.17] и др.

Данная область пополнилась новым разделом (SWEBOK, 2004 г.), описываемым ниже.

Управление конструированием - это управление процессом конструирования ПО, которое базируется на моделях конструирования, планировании и внесении изменений.

Модели конструирования включают набор операций, последовательность действий и результатов. Виды моделей определяются стандартом ЖЦ, методологиями и практиками. Некоторые стандарты ЖЦ по своей природе ориентированы на конструирование, например, экстремальное программирование (XP - eXtreme Programming). Конструирование с помощью моделирования осуществляется в рациональном унифицированном процессе - RUP (Rational Unified Process) [1.19].

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

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

имается решение об изменении кода путем исправления обнаруженных ошибок или внесения изменений в требования к ПО.

36/Жизненный цикл проекта

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

Жизненный цикл определяет:

Какие технические работы должны быть проведены в каждой фазе;

В какой момент каждой фазы должны быть получены результаты;

Кто участвует в каждой фазе проекта;

Как контролировать и подтверждать каждую фазу.

Характеристики жизненного цикла проекта.

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

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

Затраты и персонал, задействованный в проекте

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

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

Влияние участников проекта в течение проекта

Характеристики фаз проекта.

Фаза характеризуется завершением и одобрением одного или нескольких результатов поставки.

Результат поставки — это измеримый, проверяемый продукт работы.

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

Следующая фаза может быть авторизована до окончания текущей.

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

Анализ в конце фазы (phase exit, phase gate, kill point) — группа процессов инициации, на выходе которой получается специфичный для данной фазы выход.

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

Взаимосвязь между жизненными циклами проекта и продукта.

Следует различать жизненные циклы проекта и продукта.

Проект является лишь одной из жизненных фаз продукта.

Участники проекта

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

Участники могут иметь как положительное, так и отрицательное влияние на проект.

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

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

К ключевым участникам проекта относятся:

Менеджер проекта;

Заказчик/пользователь;

Исполняющая организация;

Члены команды проекта;

Команда управления проектом;

Спонсор;

Источники влияния;

Офис управления проектами.

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

Влияние организации на проект

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

Факторы влияния организации на проект:

Организационные системы

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

Организации, в которых внедрено управление через проекты (см. главу 1).

Корпоративная культура и стиль

общие ценности, нормы, вверования и ожидания;

принципы и процедуры;

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

рабочая этика и рабочие часы.

Организационная структура

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

Влияние организационной структуры на проект

Функциональная организация

Проектная организация

Слабая матричная организация

Сбалансированная матричная организация

Сильная матричная организация

Смешанная организация

Роль офиса управления проектами в организационных структурах.

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

Система управления проектами.

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

37Процессы управления проектами

В самом общем виде методология проектного менеджмента определяет и формализует процедуры, методы и инструменты реализации пяти групп управленческих процессов (согласно стандарту PMBOK Guide):

Инициации проекта

Планирования

Организации исполнения;

Контроля исполнения;

Завершения проекта.

Группы процессов управления проектами

(согласно стандарту PMBOK Guide 3-d Edition)

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

Инициация проекта может включать следующие процедуры:

Разработка концепции проекта:

Анализ проблемы и потребности в проекте;

Сбор исходных данных;

Определение целей и задач проекта;

Рассмотрение альтернативных вариантов проекта.

Рассмотрение и утверждение концепции.

Принятие решения о начале проекта:

Определение и назначение менеджера проекта;

Принятие решения об обеспечении ресурсами выполнения первой фазы проекта.

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

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