Кто ввел понятие руководство по

Лютер Халси Гулик[260] (1892–1993) – американский исследователь проблем организации и управления, специалист по государственному управлению, последователь и популяризатор административной теории А. Файоля, представитель «второго поколения классической школы».

Л. Гулик родился в Осаке. В 1919 г. был назначен главой специального училища при Бюро муниципальных исследований, преобразованного позднее в Национальный институт государственного управления США. С 1921 г. – президент Национального института государственного управления. В 1930-х гг. вошел в состав Комитета Браунлоу, занимавшегося реорганизацией управления при президенте США, а также помогал созданию государственной администрации Расчетной палаты. Долгое время Л. Гулик занимал многие ответственные посты в правительстве, включая Комитет по производству вооружений, Комиссию ООН по репарациям в Москве, Потсдаме, Токио и Маниле, а также президентский Комитет по административному управлению. Л. Гулик являлся консультантом во многих международных организациях, например Всемирной организации здравоохранения при ООН и ЮНЕСКО. В 1960-е гг. стал консультантом президента Г. Насера по вопросам создания новой конституции Египта. Читал лекции по вопросам управления в Мичиганском университете.

Основные работы. В период с 1920 по 1990 г. самостоятельно и в соавторстве с другими учеными Л. Гулик написал пятьдесят книг и около двухсот статей. Наиболее известная публикация – «Доклады о науке управления» (1937). Она была подготовлена к печати совместно с Линдалом Урвиком и представляет собой интернациональный сборник работ, написанных известными специалистами в области классической теории управления: Г. Денниссоном, А. Файолем, М. Фоллетт, Дж. Ли, Дж. Муни и др.

В этом однотомном сборнике содержатся наиболее исчерпывающие формулировки классических теорий организационных структур, и его можно рассматривать, по сути, как работу по истории управленческой мысли в области теории организации. Из одиннадцати разделов работы «Доклады о науке управления» две статьи принадлежат Л. Гулику: «Заметки по теории организации» и «Наука, ценности и общественная организация». Кроме того, к числу основных работ Л. Гулика можно отнести: «Административные размышления о Второй мировой войне» (1948), «Политическое и административное руководство» (1963).

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

По общему мнению западных ученых, статья Лютера Гулика «Заметки по теории организации», открывающая сборник «Доклады о науке управления», стала окончательным утверждением подхода к управлению организациями, основанного на «принципах», и является самым ясным и наиболее подробным выражением взглядов автора на философию управления[261].

Теория разделения и координации труда. Л. Гулик начинает статью «Заметки по теории организации» с изложения классической концепции разделения труда и видит в этом явлении основную причину происхождения организации. По мнению Л. Гулика, вопрос «разделения труда – это вопрос человеческой сущности, времени и пространства»[262]. На каждом широкомасштабном и сложно структурированном предприятии, требующем большого количества людей, наилучший результат будет достигнут при разделении труда между ними. Разделение труда необходимо, поскольку, во-первых, оно делает возможным более эффективное использование разнообразных умений и навыков работников, а во-вторых, уменьшает потери времени.

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

1. Когда оно создает задачи, решение которых требует участия менее чем одного работника.

2. Когда оно связано с технологией и привычным образом действий в данное время в данном месте.

3. Когда физическое разделение переходит в органическое разделение. Например, «если отправить переднюю часть коровы пастись на луг, а заднюю часть оставить в амбаре и постоянно ее доить».

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

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

Л. Гулик выделил два основных способа к осуществлению координации:

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

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

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

Л. Гулик выделил несколько ограничивающих факторов в развитии процесса координации. Основные из них:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В целом в работе Л. Гулика «Заметки по теории организации» было выделено десять «универсальных» принципов организации:

1) разделение труда и специализация;

2) департаментализация на основе цели, процесса, клиентуры или места;

3) координация посредством иерархии;

4) координация посредством идеи;

5) координация посредством комиссий;

6) децентрализация;

7) единство командования;

штаб и линия;

9) делегирование;

10) диапазон управления.

В своих более поздних сочинениях Л. Гулик продолжал выступать за признание и одобрение принципов управления.

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

Функции управления. Теория управления Л. Гулика основывается на файолевском понимании «пяти элементов администрации». При этом Л. Гулик считал сферу деятельности высшего управленческого звена более обширной и сложной, чем она была представлена у А. Файоля. Поэтому Л. Гулик расширил функции администрации А. Файоля и выделил семь направлений деятельности и обязанностей любого руководителя высшего звена.

В своей статье «Заметки по теории организации» Л. Гулик ввел знаменитую мнемоническою аббревиатуру POSDCORB, отражающую функции управления: планирование, организация, подбор персонала, руководство, координация, отчетность, бюджетирование. Он подчеркивал, что «POSDCORB – это аббревиатура, составленная, чтобы привлечь внимание к различным функциональным элементам деятельности руководителя, так как понятия “администрирование ” и “ менеджмент ” потеряли свой конкретный смысл». POSDCORB задумывался как связующее звено между теорией управления и реальной управленческой практикой.

Понятие POSDCORB составлено из начальных букв слов, означающих следующие виды деятельности:

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

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

• Staffing (управление персоналом) – комплекс функций, связанных с приемом на работу, обучением персонала, а также

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

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

• Co-ordinating (координация) – всевозможные обязанности и полномочия по созданию связей между различными частями работы.

• Reporting (отчетность) – постоянное информирование тех, перед кем руководитель несет ответственность, о том, что происходит; это подразумевает информирование как руководителя, так и подчиненных путем ведения документации, исследований, проверок.

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

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

По мнению Л. Гулика, «если эти семь элементов могут являться основными обязанностями руководителя высшего звена, значит, они могут быть преобразованы в отдельные подразделения исполнительной власти». Необходимость и возможность их создания определяется размером и сложностью структуры предприятия. Исследователь пишет, что «на крупных предприятиях, где руководитель высшего звена не в состоянии справиться с возлагаемой на него работой, необходимо организовать одно или несколько подразделений POSDCORB».

В более поздних работах Л. Гулик изменил формулу POSDCORB на POSDECORB. Был добавлен еще один элемент – Evaluation (оценка)[263]. Автор также пришел к признанию важности принципа децентрализации, делегирования полномочий служащим низшего звена и их участия в принятии решений.

По мнению Л. Гулика, люди, находящиеся на вершине управленческой иерархии, должны обладать широким набором качеств. Он подчеркивает необходимость наличия у руководителей организаторских способностей и умения повести за собой подчиненных. При этом Л. Гулик указал и на факторы, которые могут ограничивать возможности руководителя. К ним относятся: 1) неопределенность будущего; 2) недостаточность знаний у самих руководителей; 3) отсутствие у них необходимых административных навыков и отработанных методов; 4) общая нехватка предписанных и научно обоснованных процедур и программ; 5) огромное количество переменных факторов и неполнота человеческого знания, в частности о человеке и его жизни.

В работе «Административные размышления о Второй мировой войне» Л. Гулик акцентирует внимание на необходимости замены руководителей, в случае если они оказываются не соответствующими ситуации. В то же время Л. Гулик рекомендует сохранение престижа высшего руководства. По его мнению, «это жестоко по отношению к нижестоящим организациям и подчиненным, но сохраняет целостность общего управления в мире испытаний и ошибок… Высшее руководство должно отвечать за общий результат, а не за каждый подотчетный ему сегмент»[264].

Рассматривая вопросы управления и роли руководителя на государственном уровне, Л. Гулик формулировал вопрос так: «Должен ли администратор быть динамичным, активным лидером города, или он должен заниматься чисто административным руководством в узком смысле этого слова, а решение всех стратегических (политических) вопросов предоставить совету?»[265] Л. Гулик пришел к выводу, что политическую функцию нельзя отделить от административной, поскольку многие политические решения неразрывно связаны с администрированием.

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

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

• развитие профессиональных ассоциаций работников;

• поиск путей решения проблем, возникающих на рабочем месте;

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

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

Таким образом, в своей теории организации Л. Гулик рассматривает процесс управления как единое целое, не ограниченное только формальными аспектами. Он подчеркивает важность учета неформальных факторов организации, особенностей человеческих отношений. Однако Л. Гулику не удалось до конца понять значение человеческого элемента в организациях. Как подчеркивал Д. М. Гвишиани, в большинстве своем разработанные им организационные принципы касаются в основном лишь архитектоники формальной организации[266].

В 1950–60-е гг. ХХ в. в большинстве стран Запада актуализировалась задача планирования и прогнозирования экономики. Л. Гулик также занимался разработкой вопросов планирования. Основываясь на анализе американской экономики, Л. Гулик пришел к выводу о том, что планирование является важнейшим элементом управления. По его мнению, необходимо непрерывное планирование – как до разработки программы, так и во время ее реализации в качестве источника информации для размышления и анализа: «Планирование, исследования и текущая работа идут рука об руку; они являются параллельными и взаимовлияющими видами деятельности. Планирование должно также быть гибким, не создающим помех; но не следует чрезмерно увлекаться планированием, так как это сокращает возможности осуществления выбора в настоящем и будущем»[267].

Хотя основное внимание Л. Гулик уделял разработке целостной управленческой теории, он пришел к выводу о том, что всесторонне разработанной теории управления так и не существует. То, что имелось вместо нее, он называл «более или менее достоверными и частично подтвержденными предположениями», а не доказанной управленческой теорией.

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

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

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

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

_____________________________________________________________________________________________________________________

[260] Фамилия Guliсk иногда передается по-русски как Гьюлик.

[261] Классики теории государственного управления: американская школа / под ред. Дж. Шафритца, А. Хайда. Москва : Издательство Московского университета, 2003. С. 88 ; Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 261–262.

[262] Здесь и далее цитирование работы Л. Гулика «Заметки по теории организации» будет проводиться по сборнику трудов ведущих теоретиков американской управленческой мысли: Классики теории государственного управления: американская школа / под ред. Дж. Шафритца, А. Хайда. Москва : Издательство Московского университета, 2003. С. 100–118.

[263] Государственное управление : словарь — справочник по материалам «International Encyclopedia of Public Policy and Administration» : пер. с англ. Санкт-Петербург : Петрополис, 2001. 630 с.

[264] Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 265.

[265] Gulick L. Political and Administrative Leadership // Public Management. 1963. November

[266] Гвишиани Д. М. Организация и управление. Москва : Наука, 1972. С. 267.

[267] Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 266.

Выходные данные учебного пособия: 

История менеджмента : учебное пособие / Е. П. Костенко, Е. В. Михалкина ; Южный федеральный университет. — Ростов-на- Дону: Издательство Южного федерального университета, 2014. — 606 с. 

Вернуться к оглавлению «История менеджмента: учебное пособие» 

Software is a set of programmed instructions stored in the memory of stored-program digital computers for execution by the processor. Software is a recent development in human history, and it is fundamental to the Information Age.

Ada Lovelace’s programs for Charles Babbage’s Analytical Engine in the 19th century is often considered the founder of the discipline, though the mathematician’s efforts remained theoretical only, as the technology of Lovelace and Babbage’s day proved insufficient to build his computer. Alan Turing is credited with being the first person to come up with a theory for software in 1935, which led to the two academic fields of computer science and software engineering.

The first generation of software for early stored-program digital computers in the late 1940s had its instructions written directly in binary code, generally written for mainframe computers. Later, the development of modern programming languages alongside the advancement of the home computer would greatly widen the scope and breadth of available software, beginning with assembly language, and continuing on through functional programming and object-oriented programming paradigms.

Before stored-program digital computers[edit]

Origins of computer science[edit]

Computing as a concept goes back to ancient times, with devices such as the abacus, the Antikythera mechanism, Astrolabes, Mechanical Astronomical clocks and Mechanical Calculators.^[1] The Antikythera mechanism is an example for a highly complex ancient mechanical Astronomical device.^[2]

However, these devices were pure hardware and had no software — their computing powers were directly tied to their specific form and engineering.

Software requires the concept of a general-purpose processor — what is now described as a Turing machine — as well as computer memory in which reusable sets of routines and mathematical functions comprising programs can be stored, started, and stopped individually, and only appears recently in human history.

The first known computer algorithm was written by Ada Lovelace in the 19th century for the Analytical Engine, to translate Luigi Menabrea’s work on Bernoulli numbers for machine instruction.^[3][3] However, this remained theoretical only — the lesser state of engineering in the lifetime of these two mathematicians proved insufficient^{[citation needed]} to construct the Analytical Engine.

The first modern theory of software was proposed by Alan Turing in his 1935 essay Computable numbers with an application to the Entscheidungsproblem (decision problem).^[4]

This eventually led to the creation of the twin academic fields of computer science and software engineering, which both study software and its creation. Computer science is more theoretical (Turing’s essay is an example of computer science), whereas software engineering is focused on more practical concerns.

However, prior to 1946, software as we now understand it – programs stored in the memory of stored-program digital computers – did not yet exist. The very first electronic computing devices were instead rewired in order to «reprogram» them. The ENIAC, one of the first electronic computers, was programmed largely by women who had been previously working as human computers.^{[5] [6]} Engineers would give the programmers blueprints of the ENIAC wiring and expected them to figure out how to program the machine.^[7] The women who worked as programmers prepped the ENIAC for its first public reveal, wiring the patch panels together for the demonstrations.^{[8] [9][10]} Kathleen Booth developed Assembly Language in 1950 to make it easier to program the computers she worked on at Birkbeck College.^[11]

Grace Hopper worked as one of the first programmers of the Harvard Mark I.^[12] She later created a 500-page manual for the computer.^[13] Hopper is often falsely credited with coining the terms «bug» and «debugging,» when she found a moth in the Mark II, causing a malfunction;^[14] however, the term was in fact already in use when she found the moth.^[14] Hopper developed the first compiler and brought her idea from working on the Mark computers to working on UNIVAC in the 1950s.^[15] Hopper also developed the programming language FLOW-MATIC to program the UNIVAC.^[14] Frances E. Holberton, also working at UNIVAC, developed a code^{[clarification needed]}, C-10, which let programmers use keyboard inputs and created the Sort-Merge Generator in 1951.^[16][17] Adele Mildred Koss and Hopper also created the precursor to a report generator.^[16]

Early days of computer software (1948–1979)[edit]

In his manuscript «A Mathematical Theory of Communication», Claude Shannon (1916–2001) provided an outline for how binary logic could be implemented to program a computer. Subsequently, the first computer programmers used binary code to instruct computers to perform various tasks. Nevertheless, the process was very arduous. Computer programmers had to provide long strings of binary code to tell the computer what kind of data it should store. Code and data had to be loaded onto computers using various tedious mechanisms, including flicking switches or punching holes at predefined positions in cards and loading these punched cards into a computer. With such methods, if a mistake was made, the whole program might have to be loaded again from the beginning.

The very first time a stored-program computer held a piece of software in electronic memory and executed it successfully, was 11 am 21 June 1948, at the University of Manchester, on the Manchester Baby computer. It was written by Tom Kilburn, and calculated the highest factor of the integer 2^18 = 262,144. Starting with a large trial divisor, it performed division of 262,144 by repeated subtraction then checked if the remainder was zero. If not, it decremented the trial divisor by one and repeated the process. Google released a tribute to the Manchester Baby, celebrating it as the «birth of software».

FORTRAN was developed by a team led by John Backus at IBM in the 1950s. The first compiler was released in 1957. The language proved so popular for scientific and technical computing that by 1963 all major manufacturers had implemented or announced FORTRAN for their computers.^[18][19]

COBOL was first conceived of when Mary K. Hawes convened a meeting (which included Grace Hopper) in 1959 to discuss how to create a computer language to be shared between businesses.^[16] Hopper’s innovation with COBOL was developing a new symbolic way to write programming.^[13] Her programming was self-documenting.^[20] Betty Holberton helped edit the language which was submitted to the Government Printing Office in 1960.^[21] FORMAC was developed by Jean E. Sammet in the 1960s.^[21] Her book, Programming Languages: History and Fundamentals (1969), became an influential text.^[21][22]

Apollo Mission[edit]

The Apollo Mission to the moon depended on software to program the computers in the landing modules.^[23][24] The computers were programmed with a language called «Basic» (no relation with the BASIC programming language developed at Dartmouth at about the same time).^[25] The software also had an interpreter which was made up of a series of routines and an executive (like a modern-day operating system), which specified which programs to run and when.^[25] Both were designed by Hal Laning.^[25] Margaret Hamilton, who had previously been involved with software reliability issues when working on the US SAGE air defense system, was also part of the Apollo software team.^[23][26] Hamilton was in charge of the onboard flight software for the Apollo computers.^[23] Hamilton felt that software operations were not just part of the machine, but also intricately involved with the people who operated the software.^[25] Hamilton also coined the term «software engineering» while she was working at NASA.^[27]

The actual «software» for the computers in the Apollo missions was made up of wires that were threaded through magnetic cores.^[28] Where the wire went through a magnetic core, that represented a «1» and where the wire went around the core, that represented a «0.»^[28] Each core stored 64 bits of information.^[28] Hamilton and others would create the software by punching holes in punch cards, which were then later processed on a Honeywell mainframe where the software could be simulated.^[23] When the code was «solid,» then it was sent to be woven into the magnetic cores at Raytheon, where women known as «Little Old Ladies» worked on the wires.^[23] The program itself was «indestructible» and could even withstand lightning strikes, which happened to Apollo 12.^[28] Wiring the computers took several weeks to do, freezing software development during that time.^[29]

While using the simulators to test the programming, Hamilton discovered ways that code could produce dangerous errors when human mistakes were made while using it.^[23] NASA believed that the astronauts would not make mistakes due to their training.^[30] Hamilton was not allowed to program code to prevent errors that would lead to system crash, so she annotated the code in the program documentation.^[23] Her ideas to add error-checking code was rejected as «excessive.»^[23] However, exactly what Hamilton predicted would happen occurred on the Apollo 8 flight, when human error caused the computer to wipe out all of the navigational data.^[23]

Bundling of software with hardware and its legal issues[edit]

Later, software was sold to multiple customers by being bundled with the hardware by original equipment manufacturers (OEMs) such as Data General, Digital Equipment and IBM. When a customer bought a minicomputer, at that time the smallest computer on the market, the computer did not come with pre-installed software, but needed to be installed by engineers employed by the OEM.^{[citation needed]}

This bundling attracted the attention of US antitrust regulators, who sued IBM for improper «tying» in 1969, alleging that it was an antitrust violation that customers who wanted to obtain its software had to also buy or lease its hardware in order to do so. However, the case was dropped by the US Justice Department, after many years of attrition, as it concluded it was «without merit».^[31]

Data General also encountered legal problems related to bundling – although in this case, it was due to a civil suit from a would-be competitor. When Data General introduced the Data General Nova, a company called Digidyne wanted to use its RDOS operating system on its own hardware clone. Data General refused to license their software and claimed their «bundling rights». The US Supreme Court set a precedent called Digidyne v. Data General in 1985 by letting a 9th circuit appeal court decision on the case stand, and Data General was eventually forced into licensing the operating system because it was ruled that restricting the license to only DG hardware was an illegal tying arrangement.^[32] Even though the District Court noted that «no reasonable juror could find that within this large and dynamic market with much larger competitors», Data General «had the market power to restrain trade through an illegal tie-in arrangement», the tying of the operating system to the hardware was ruled as per se illegal on appeal.^[33]

In 2008, Psystar Corporation was sued by Apple Inc. for distributing unauthorized Macintosh clones with OS X preinstalled, and countersued. One of the arguments in the countersuit — citing the Data General case — was that Apple dominates the market for OS X compatible computers by illegally tying the operating system to Apple computers. District Court Judge William Alsup rejected this argument, saying, as the District Court had ruled in the Data General case over 20 years prior, that the relevant market was not simply one operating system (Mac OS) but all PC operating systems, including Mac OS, and noting that Mac OS did not enjoy a dominant position in that broader market. Alsup’s judgement also noted that the surprising Data General precedent that tying of copyrighted products was always illegal had since been «implicitly overruled» by the verdict in the Illinois Tool Works Inc. v. Independent Ink, Inc. case.^[34]

Packaged software (Late 1960s-present)[edit]

This section needs expansion. You can help by adding to it. (March 2019)

An industry producing independently packaged software — software that was neither produced as a «one-off» for an individual customer, nor «bundled» with computer hardware — started to develop in the late 1960s.^[35]

Unix (1970s–present)[edit]

Unix was an early operating system which became popular and very influential, and still exists today. The most popular variant of Unix today is macOS (previously called OS X and Mac OS X), while Linux is closely related to Unix.

The rise of Microcomputers[edit]

In January 1975, Micro Instrumentation and Telemetry Systems began selling its Altair 8800 microcomputer kit by mail order. Microsoft released its first product Altair BASIC later that year, and hobbyists began developing programs to run on these kits. Tiny BASIC was published as a type-in program in Dr. Dobb’s Journal, and developed collaboratively.

In 1976, Peter R. Jennings for instance created his Microchess program for MOS Technology’s KIM-1 kit, but since it did not come with a tape drive, he would send the source code in a little booklet to his mail-order customers, and they would have to type the whole program in by hand. In 1978, Kathe and Dan Spracklen released the source of their Sargon (chess) program in a computer magazine. Jennings later switched to selling paper tape, and eventually compact cassettes with the program on it.

It was an inconvenient and slow process to type in source code from a computer magazine, and a single mistyped – or worse, misprinted – character could render the program inoperable, yet people still did so. (Optical character recognition technology, which could theoretically have been used to scan in the listings rather than transcribe them by hand, was not yet in wide use.)

Even with the spread of cartridges and cassette tapes in the 1980s for distribution of commercial software, free programs (such as simple educational programs for the purpose of teaching programming techniques) were still often printed, because it was cheaper than making and attaching cassette tapes to magazines.

However, eventually a combination of four factors brought this practice of printing complete source code listings of entire programs in computer magazines to an end:

• programs started to become very large
• floppy discs started to be used for distributing software, and then came down in price
• regular people started to use computers – and wanted a simple way to run a program
• computer magazines started to include cassette tapes or floppy discs with free or trial versions of software on them

Very quickly, commercial software started to be pirated, and commercial software producers were very unhappy at this. Bill Gates, cofounder of Microsoft, was an early moraliser against software piracy with his famous Open Letter to Hobbyists in 1976.^[36]

1980s–present[edit]

This section needs expansion. You can help by adding to it. (September 2013)

Before the microcomputer, a successful software program typically sold up to 1,000 units at $50,000–60,000 each. By the mid-1980s, personal computer software sold thousands of copies for $50–700 each. Companies like Microsoft, MicroPro, and Lotus Development had tens of millions of dollars in annual sales.^[37] They similarly dominated the European market with localized versions of already successful products.^[38]

A pivotal moment in computing history was the publication in the 1980s of the specifications for the IBM Personal Computer published by IBM employee Philip Don Estridge, which quickly led to the dominance of the PC in the worldwide desktop and later laptop markets – a dominance which continues to this day. Microsoft, by successfully negotiating with IBM to develop the first operating system for the PC (MS-DOS), profited enormously from the PC’s success over the following decades, via the success of MS-DOS and its add-on-cum-successor, Microsoft Windows. Winning the negotiation was a pivotal moment in Microsoft’s history.

Free and open source software[edit]

Recent developments[edit]

App stores[edit]

Applications for mobile devices (cellphones and tablets) have been termed «apps» in recent years. Apple chose to funnel iPhone and iPad app sales through their App Store, and thus both vet apps, and get a cut of every paid app sold. Apple does not allow apps which could be used to circumvent their app store (e.g. virtual machines such as the Java or Flash virtual machines).

The Android platform, by contrast, has multiple app stores available for it, and users can generally select which to use (although Google Play requires a compatible or rooted device).

This move was replicated for desktop operating systems with GNOME Software (for Linux), the Mac App Store (for macOS), and the Windows Store (for Windows). All of these platforms remain, as they have always been, non-exclusive: they allow applications to be installed from outside the app store, and indeed from other app stores.

The explosive rise in popularity of apps, for the iPhone in particular but also for Android, led to a kind of «gold rush», with some hopeful programmers dedicating a significant amount of time to creating apps in the hope of striking it rich. As in real gold rushes, not all of these hopeful entrepreneurs were successful.

Formalization of software development[edit]

The development of curricula in computer science has resulted in improvements in software development. Components of these curricula include:

1. Structured and Object Oriented programming^[39]
2. Data structures^[40]
3. Analysis of Algorithms^[41]
4. Formal languages^[42] and compiler construction^[43]
5. Computer Graphics Algorithms^[44]
6. Sorting and Searching^[45]
7. Numerical Methods,^[46] Optimization and Statistics^[47]
8. Artificial Intelligence^[48] and Machine Learning^[49]

How software has affected hardware[edit]

As more and more programs enter the realm of firmware, and the hardware itself becomes smaller, cheaper and faster as predicted by Moore’s law, an increasing number of types of functionality of computing first carried out by software, have joined the ranks of hardware, as for example with graphics processing units. (However, the change has sometimes gone the other way for cost or other reasons, as for example with softmodems and microcode.)

Most hardware companies today have more software programmers on the payroll than hardware designers^{[citation needed]}, since software tools have automated many tasks of printed circuit board (PCB) engineers.

Computer software and programming language timeline[edit]

The following tables include year by year development of many different aspects of computer software including:

1. High level languages^[50][51]
3. Operating systems^[52]
5. Networking software and applications^[53]
7. Computer graphics hardware, algorithms and applications^[54][55]
9. Spreadsheets
11. Word processing
13. Computer aided design^[56]

1971–1974[edit]

	1971	1972	1973	1974
Programming languages	CDL KRL SUE	C INTERCAL PL/M Prolog Smalltalk SQL	COMAL LIS ML Speakeasy-3	BASIC FOUR CLU GRASS PROSE
Operating systems	DEC RSTS-11	Data General RDOS	Soviet ALGOL 68	DEC DOS-11
Computer networks		Wozniak’s Blue Box	Bob Metcalfe develops Ethernet
Computer graphics		Newell & Sancha visible surface algorithm		Catmull & Straber develop z-buffer
CAD/CAM	MCS founded	ADAM	Auto-Draft	Tektronix 4014

1975–1978[edit]

	1975	1976	1977	1978
Programming languages	ABC Altair BASIC CS-4 Modula Scheme	Mesa Plus Ratfor S SAM76 SAS Smalltalk-76	Blue Bourne Shell Commodore BASIC FP Icon IDL Red Standard MUMPS Yellow IDL	C shell HAL/S MATLAB RPG III SMALL VisiCalc SQL
Operating systems	CP/M	Cambridge CAP	1BSD	2BSD Apple DOS
Computer networks	Telenet packet switching
Computer graphics	EDS founded		Antialiasing
Word processors		Electric Pencil		AppleWriter
CAD/CAM	Solid modeling	McDonnell Douglas buys Unigraphics	Forerunner to CATIA	Raster graphics display

1979–1982[edit]

	1979	1980	1981	1982
Programming languages	AWK Icon Modula-2 REXX Vulcan dBase-II	Ada 80 C with classes CBASIC	BBC BASIC IBM BASICA	Draco PostScript Speakeasy-IV
Operating systems	Atari DOS	86-DOS	MS-DOS 1 Acorn MOS	Commodore DOS
Computer networks	Usenet	TCP/IP
Computer graphics				Silicon Graphics founded
Word processors	Wordstar	WordPerfect for DG Mini	Bank Street AppleWriter II	WordStar 3.0 WordPerfect for DOS
Spreadsheet	VisiCalc		Lotus 1-2-3
CAD/CAM	IGES	VersaCAD	Dassault Systems	Autodesk founded

1983–1986[edit]

	1983	1984	1985	1986
Programming languages	ABAP Ada 83 C++ GW-BASIC Korn Shell Objective-C occam True BASIC Turbo Pascal	CLIPPER Common Lisp Good Old MAD (GOM) OPL Redcode RPL Standard ML Matlab Framework FRED	Paradox QuickBASIC Framework II FRED	CorVision Eiffel GFA BASIC Informix-4GL LabVIEW Miranda Object Pascal PROMAL
Operating systems	MS-DOS 2 Lisa Office SunOS 1	MS-DOS 3 System Software	Windows 1.0 Atari TOS AmigaOS	AIX 1
Computer networks	ARPANET splits off MILNET	Novell NetWare Research In Motion founded	NSFNET connects 5 Supercomputers
Computer graphics			ATI founded	Intel 82786 coprocessor
Word processors	Word 1 for DOS	Word 1 for Mac	WordPerfect 4.2 for DOS
Spreadsheet			Excel for Mac
CAD/CAM	Autodesk releases AutoCAD 1.2,1.3,1.4	AutoCAD 2	Bentley Systems Parametric Technology	AutoLISP

1987–1990[edit]

	1987	1988	1989	1990
Programming languages	Ada ISO 8652 Clean Erlang HyperTalk Mathematica Oberon occam 2 Perl Self Turbo Basic	A+ Hamilton C shell Object REXX Octave RPG/400 SPARK STOS BASIC Tcl Mathematica Framework III FRED	Bash LPC Modula-3 PowerBASIC Turbo Pascal OOP VisSim FL	AMOS BASIC AMPL EuLisp Haskell J Object Oberon Z Shell
Operating systems	Windows 2.0	MS-DOS 4 Windows 2.1x OS/2 A/UX	EPCO	Windows 3.0
Computer networks		Morris worm	World Wide Web starts	HTML
Computer graphics	JPEG and GIF	Pixar’s Tin Toy wins Oscar	AutoDesk 3D Studio
Word processors	Microsoft Works for DOS	PC Magazine Reviews 55 Packages	WordPerfect 5.1 Word for Windows	Microsoft Office for Windows
Spreadsheet	Excel for Windows	Quattro Pro
CAD/CAM	Deneba releases Canvas X AutoCAD 9	CATIA 3 AutoCAD 10	Parametric T-Flex	Visionary Design Systems founded AutoCAD 11 ACIS 1

1991–1994[edit]

	1991	1992	1993	1994
Programming languages	GNU E Oberon-2 Oz Q Visual Basic Python Framework IV FRED	Turbo Pascal Dylan	Ruby AppleScript Brainfuck K Lua NewtonScript R Transcript Self ZPL	CLOS ANS Forth ANSI Common Lisp Claire Pike RAPID
Operating systems	MS-DOS 5 Linux	Windows 3.1x 386BSD	MS-DOS 6 Newton OS Solaris	AIX 4.0, 4.1
Computer networks		Mosaic web browser	NetWare 4	Netscape Navigator
Computer graphics		OpenGL	Nvidia founded
Word processors	Microsoft Works			Novell buys WordPerfect
CAD/CAM	EDS buys Unigraphics	CADAM & CATIA begin unification	AutoCAD 12	Simple Vector Format

1995–1998[edit]

	1995	1996	1997	1998
Programming languages	Ada 95 ColdFusion Delphi Java JavaScript LiveScript PHP Ruby	Curl Lasso NetRexx OCaml Perl Data Language WebDNA	Component Pascal E ECMAScript F-Script ISLISP Pico REBOL Squeak Smalltalk Tea Rebol	M2001 Open Source Erlang Pikt PureBasic REALbasic Standard C++ UnrealScript
Operating systems	Windows 95 Digital UNIX	Windows NT 4.0 Palm OS	Inferno Mac OS 7.6 Mac OS 8	Windows 98 Solaris 7 64-bit
Computer networks	The research proposal for Google was formed.	Mosaic web browser Inter@ctive Pager	NetWare 4	Netscape Navigator
Computer graphics	Pixar Goes Public after Toy Story	3Dfx Voodoo	ATI Rage Pro	Voodoo Banshee
Word processors	Word 95 for Windows	Corel buys WordPerfect from Novell
CAD/CAM	MicroStation Advanced solid modeling	Canvas 5	ISO 13567 AutoCAD 14	Dassault Systems buys Matra Datavision products

1999–2002[edit]

	1999	2000	2001	2002
Programming languages	D GameMaker Language Harbour XSLT	ActionScript C# Ferite Join Java Joy XL Visual Basic .NET	AspectJ GDScript Processing RPG IV	Gosu Io
Operating systems	Mac OS X Server 1.0 Mac OS 9	Windows 2000 Windows ME Mac OS X Public Beta	v10.0 Cheetah v10.1 Puma Windows XP	Windows XP 64-bit Edition 10.2 Jaguar
Computer networks	BlackBerry 850		NetWare 4	Netscape Navigator
Computer graphics	S3 Savage 4 GeForce 256	Radeon DDR (R100)	Nvidia Kyro II GeForce 3
Word processors	Sun buys Star Division
CAD/CAM	Pro/Engineer 2000	AutoCAD 2000	EDS buys SDRC	Unigraphics NX Autodesk buys Revit

2003–2006[edit]

	2003	2004	2005	2006
Programming languages	Factor Nemerle Scala Squirrel	Alma-0 Boo FreeBASIC Groovy Little b Subtext	Ada 2005 F# Seed7	Cobra Links OptimJ Windows PowerShell
Operating systems	v10.3 Panther Red Hat Enterprise Linux Windows Server 2003		v10.4 Tiger Ubuntu 5 Windows XP Professional x64 Edition
Computer networks	802.11g Apple Safari	Gmail Facebook founded Mozilla Firefox		BlackBerry Pearl 8100

2007–2010[edit]

	2007	2008	2009	2010
Programming languages	Clojure Fantom Fortress LOLCODE Oberon-07 Vala	Genie Pure	CoffeeScript Go Idris Parasail	Chapel RPG Open Access Rust
Operating systems	Windows Vista v10.5 Leopard	Android	Windows 7 v10.6 Snow Leopard Android 1.5 «Cupcake» Android 1.6 «Donut» Android 2.0–2.1 «Eclair»	Android 2.2 «Froyo» Android 2.3 «Gingerbread»
Computer networks		Google Chrome Chromium	Wi-Fi 802.11n
Computer graphics		Assassin’s Creed	Up Cloth Simulation	Avatar wins «Best Picture»
Word processors		Oracle buys OpenOffice from Sun	Oracle releases OpenOffice to Apache Software Foundation
CAD/CAM	Siemens buys UGS

2011–2014[edit]

	2011	2012	2013	2014
Programming languages	Dart	Ada 2012 Elixir Julia TypeScript CryEngine#CryEngine 3 (BeamNG.drive)	Xojo	Hack Swift
Operating systems	v10.7 Lion Android 3.x «Honeycomb» Android 4.0 «Ice Cream Sandwich»	Windows 8 v10.8 Mountain Lion Android 4.1.x–4.2.x «Jelly Bean»	v10.9 Mavericks Windows 8.1 Android 4.3 «Jelly Bean» Android 4.4 «KitKat»	v10.10 Yosemite Android 5.0 «Lollipop»
Computer networks		802.11ac
Computer graphics	Hugo wins Oscar Visual Effects	CryEngine3 and its 3D soft body physics

See also[edit]

• Forensic software engineering
• History of computing hardware
• History of operating systems
• History of software engineering
• List of failed and overbudget custom software projects
• List of pioneers in computer science
• Women in computing
• Timeline of women in computing

References[edit]

Sources[edit]

• Ceruzzi, Paul E. (1998). History of Computing. Cambridge, Massachusetts: MIT Press. ISBN 9780262032551 – via EBSCOhost.
• Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.
• Gürer, Denise (1995). «Pioneering Women in Computer Science» (PDF). Communications of the ACM. 38 (1): 45–54. doi:10.1145/204865.204875. S2CID 6626310.
• Light, Jennifer S. (1999). «When Computers Were Women». Technology and Culture. 40 (3): 455–483. doi:10.1353/tech.1999.0128. JSTOR 25147356. S2CID 108407884.
• Mindell, David A. (2008). Digital Apollo: Human and Machine in Spaceflight. Cambridge, Massachusetts: The MIT Press. ISBN 9780262266680.
• Smith, Erika E. (2013). «Recognizing a Collective Inheritance through the History of Women in Computing». CLCWeb: Comparative Literature and Culture. 15 (1): 1–9. doi:10.7771/1481-4374.1972.

External links[edit]

• Media related to History of software at Wikimedia Commons

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

Программная инженерия

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

Дисциплина программной инженерии^[2] включается в круг вопросов компьютинга (англ. computing) и может рассматриваться как инженерная область, имеющая более тесные связи со своей базовой дисциплиной — компьютерными науками, — чем другие инженерные области. Среди других инженерных дисциплин она качественно выделяется нематериальностью программного обеспечения и дискретной природой его функционирования. Основываясь на математике и компьютинге, программная инженерия занимается разработкой систематических моделей и надежных методов производства высококачественного программного обеспечения, и данный подход распространяется на все уровни — от теории и принципов до реальной практики создания программного обеспечения, которая лучше всего заметна сторонним наблюдателям.

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

Основные сведения

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

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

Все же, несмотря на юность профессии, будущее области радужно, поскольку, Money Magazine и Salary.com оценили профессию разработчика программного обеспечения как лучшую работу в Америке в 2006.

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

История

Когда первые современные цифровые компьютеры появились в начале 1940-х годов [9] наборы исполняемых команд уже были встроены в машину. Специалисты быстро поняли, что этот подход не слишком удобен. Так появилась “архитектура хранимых программ” или архитектура фон Неймана. Таким образом, деление на «железо» и «программное обеспечение» началось с абстракции, используемой чтобы решить проблему сложности вычислений.

Первые языки программирования стали появляться в 1950-х годах, и это был еще один важный шаг в абстракции. Основные языки, такие как Fortran, Algol и Cobol были выпущены в конце 1950-х для решения научных, алгоритмических и бизнес-задач соответственно. Дейкстра написал свою известную статью, «Go To Statement Considered Harmful» в 1968 году, а Дэвид Парнас ввел ключевое понятие модульности и скрытия информации в 1972 году, чтобы помочь программистам справляться со все более и более сложными программными системами. Системное программное обеспечение для управления аппаратным, названное “операционная система” было представлено компанией Unix в 1969 году. В 1967 году язык Simula ввел понятие объектно-ориентированной парадигмы программирования.

Эти достижения в области программного обеспечения были встречены большим прорывом компьютерной технике. В середине 1970-х годов был представлен микрокомпьютер, что позволило любителям получить собственный компьютер и писать свои программы для него. Это, в свою очередь привело к появлению персональных компьютеров (ПК) и Microsoft Windows. Также в середине 1980-х появляются такие понятия как цикл разработки программного обеспечения в качестве некоторого консенсуса для централизованной разработки программного обеспечения. Конец 1970-х и начало 1980-х годов ознаменовались появлением нескольких новых Simula-подобных объектно-ориентированных языков программирования, в том числе Smalltalk, Objective-C и C++.

Open Source, появившийся в начале 90-х в форме Linux, а также других программ, ввел понятие “базара” или децентрализованного стиля разработки ПО. Затем мировая паутина и стремительная популяризация интернета в середине 90-х изменили программную инженерию еще раз. Распределенные системы получили широкое распространение, как способ устройства систем, а также язык Java с его собственной виртуальной машиной, сделали еще один шаг в абстракции. Сотрудничество программистов позволило появиться на свет документу, названному Agile Manifesto, который поддерживал облегчение процессов, что способствовало написанию более дешевых и регулярно обновляемых программ.

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

Профессия

Правовые требования к лицензированию и сертификации профессиональных программных инженеров отличаются во всем мире. В Великобритании, Британское компьютерное общество выдает лицензии программных инженеров и члены общества могут также стать «дипломированными инженерами» (C.Eng), а в некоторых районах Канады, например, Альберта, Онтарио и Квебек, программные инженеры могут также быть «профессиональными инженерами» (P.Eng) и / или «мастерами информационных систем» (ISP) ,однако, нет никаких правовых требований для данных специализаций.

Работа

В 2004 году американское Бюро статистики труда, насчитало 760 840 программных инженеров, занимающих рабочие места в США. В тот же период времени было около 1,4 млн. практиков, занятых в США в других смешанных инженерных специальностях. Благодаря своей относительной новизне, как формальная область изучения, программная инженерия часто преподается как часть учебной программы компьютерных наук, и многие программные инженеры имеют неплохие познания в информатике.

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

Большинство программных инженеров и программистов работает 40 часов в неделю, а около 15 процентов программных инженеров и 11 процентов программистов работали более 50 часов в неделю в 2008 году. Травмы в этих профессиях встречаются редко. Однако, как и в других профессиях, где надо проводить много времени перед компьютером, люди этих специальностей более подвержены к усталости глаз, болям в спине, а также болезням рук и запястий, таких как синдром запястного канала.

Сертификация

Институт Программной Инженерии предлагает сертификацию по конкретным специальностям, таким как: безопасность, оптимизация процессов, а также архитектура программного обеспечения. Apple, IBM, Microsoft и другие компании финансируют собственные экзамены для сертификации. Многие IT-программы сертификации ориентированы на конкретные технологии, и управляется поставщиками этих технологий. Эти программы сертификации разработаны с учетом места, на которое будут наниматься люди, использующие эти технологии.

Расширение сертификации «Общие навыки разработки программного обеспечения» доступны через различные профессиональные сообщества. В 2006 году IEEE сертифицировала более 575 специалистов в области программного обеспечения, как «Certified Software Development Professional»(CSDP). В 2008 году они добавили сертификат начального уровня известный как «Certified Software Development Associate» (CSDA). У ACM была профессиональная программа сертификации в начале 1980-х, которая была прекращена из-за отсутствия интереса.В ACM также рассматривали возможность сертификации профессиональных программных инженеров в конце 1990-х годов, но в итоге решили, что такая сертификация не подходит для профессиональной производственной практики разработки программного обеспечения.

В Великобритании, Британское компьютерное общество разработало юридически признанную профессиональную сертификацию, называемую «Chartered IT Professional» (CITP), и доступную только для полных членов (MBCS). Программные инженеры имеют право на членство в Институте Инженерии и Технологии и могут соответственно получить статус дипломированного инженера. В Канаде, Организация en:Canadian Information Processing Society также разработала юридически признанную профессиональную сертификацию, названную «Information Systems Professional» (ISP). [23] В Онтарио, Канада, Программные инженеры, которые заканчивают канадский Engineering Accreditation Board (CEAB), успешно сдавшие Professional Practice Examination (PPE) и, имеющие по крайней мере 48 месяцев опыта работы программным инженером, имеют право получить лицензию через PEO(«Профессиональные инженеры Онтарио») и могут стать Профессиональными инженерами (P.Eng).

Влияние глобализации

Первоначальное развитие аутсорсинга, а также относительно низкая стоимость человеческих ресурсов в развивающихся странах третьего мира привело к взрыву мыльного пузыря .com 1990-х годов. Это оказало негативное воздействие на многие аспекты профессии программного инженера. Например, некоторые студенты в развитых странах не хотели получать образование, связанное с программной инженерией из-за страха оффшорного аутсорсинга (импорт программных продуктов или услуг из других стран) и вытеснения иностранными рабочими. Хотя судя по статистике в настоящее время ничего не угрожает программной инженерии как таковой. Однако профессии, связанные с программированием кажется, действительно, были затронуты. Тем не менее, способность ловко использовать зарубежные рабочие ресурсы, улучшило общую работоспособность многих организаций. Когда североамериканцы будут уходить с работы, азиаты только прибывать на нее. Когда азиаты будут уходить с работы, европейцы будут на нее приезжать. Это обеспечивает непрерывную возможность иметь людей, следящих за критически важными бизнес-процессами 24 часа в сутки, без выплаты компенсации за сверхурочную работу и не лишая людей сна.

Образование

Знания в области программирования являются необходимым условием для того, чтобы стать программным инженером. В 2004 году IEEE Computer Society выпустил SWEBOK, который был опубликован в качестве стандарта ISO / IEC 19759:2004, описывающего объем знаний, который по их мнению, должен получить дипломированный программный инженер с четырехлетним опытом. Многие люди входят в эту профессии, получив высшее образование или отучившись в профессионально-техническом училище. Стандартный учебный план для международной степени бакалавра программной инженерии был определен CCSE, и обновлен в 2004 году. Ряд университетов имеют программы обучения программных инженеров. С 2010 года насчитывалось 244 очных программы, 70 Интернет-курсов, 230 программ для специалистов, 41 программ для ученых в этой области, а также 69 программ для сертификатов в Соединенных Штатах.

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

Сравнение с другими дисциплинами

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

Поддисциплины

Программная инженерия может быть разделена на десять поддисциплин. К ним относятся:

• Анализ системных требований: выявление, анализ, спецификация и проверка требований к программному обеспечению.
• Проектирование программного обеспечения: процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или компонента.
• Конструирование программного обеспечения: поэтапное создание работающего программного обеспечения
• Тестирование программного обеспечения: динамический контроль поведения программы на конечном множестве тестов, надлежащим образом выбранных из бесконечной области.
• Обслуживание программное обеспечение: совокупность мероприятий, необходимых для обеспечения экономически эффективной поддержки программного обеспечения.
• Управление конфигурацией: определение конфигурации системы на различные моменты времени для систематического контроля изменений конфигурации, а также сохранение целостности и прослеживаемости конфигурации на протяжении всего жизненного цикла системы.
• Управление разработкой программного обеспечения: применение мер управления, планирования, координации, измерения, мониторинга, контроля и отчетности, для того, чтобы разработка и сопровождение программного обеспечения являлась систематической и дисциплинированной.
• Процесс разработки программного обеспечения: определение, реализация, оценка, измерение, управление, изменение и улучшение процесса жизненного цикла программы как такового.
• Средства и методы разработки программного обеспечения: компьютерные средства, которые предназначены для оказания помощи процессам жизненного цикла программы (см. Computer Aided Software Engineering), а также методы, которые применяют к структуре деятельности разработки программного обеспечения с целью сделать разработку более систематической и в конечном счете иметь более шансов на успех.
• Качество программного обеспечения: проверка удовлетворения набором собственных характеристик программы требованиям к программному обеспечению.

Родственные дисциплины

Программная инженерия является разделом информатики и связана с менеджментом. Она также считается частью общей инженерии систем.

Инженерия систем

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

Внешние ссылки

	Инженерия программного обеспечения на Викискладе?

• Computing Curricula 2005: The Overview Report by The Joint Task Force for Computing Curricula ACM/AIS/IEEE-CS
• Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering by The Joint Task Force on Computing Curricula ACM/IEEE-CS
• Guidelines for Associate-Degree Transfer Curriculum in Software Engineering by The ACM Two-Year College Education Committee and The IEEE Computer Society/ACM Joint Task Force on Software Engineering
• Guide to the Software Engineering Body of Knowledge
• Computer Software Engineers — Definition and statistics from the U.S. Bureau of Labor Statistics
• A Student’s Guide to Software Engineering Projects — a free online guide for students taking SE project courses
• The Open Systems Engineering and Software Development Life Cycle Framework OpenSDLC.org the integrated Creative Commons SDLC

См. также

• Компьютинг
• Компьютерные науки
• Информационные технологии
• Информационные системы
• Программирование
• Программное обеспечение
• Аппликативные вычислительные системы
• Разработка программного обеспечения
• Структурное программирование
• SWEBOK — Software Engineering Body of Knowledge

Литература

• Иан Соммервилл. Инженерия программного обеспечения, 2002 [1]
• Орлов С. А. Технологии разработки программного обеспечения: Разработка сложных программных систем Изд. 3-е, 2004
• Эрик Дж. Брауде. Технология разработки программного обеспечения, 2004
• Липаев, В.В. Программная инженерия. Методологические основы [Текст] : Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с. — 1000 экз. —

ISBN 5-7598-0424-3, УДК 004.41(075.8), ББК 32.973.26-018я73, Липаев, Высшая школа экономики, ТЕИС, 2006, pdf, экономика, программирование

Примечания

A Guide to the Project Management Body of Knowledge (далее PMBoK) — руководство к своду знаний по управлению проектами представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта.

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

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

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

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

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

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

Руководство PMBoK также предоставляет и содействует применению общего словаря терминов в профессии управления проектами для обсуждения, написания и употребления понятий управления проектами. Такой стандартный словарь является существенным элементом любой профессиональной дисциплины.

Институт управления проектами PMI (Project Management Institute) использует данный стандарт в качестве основного справочного материала по управлению проектами для своих программ профессионального развития и сертификации.

История Project Management Body of Knowledge

Первое издание PMBoK, было выпущено Институтом управления проектами (PMI — Project Management Institute) еще в 1986 году. Это была революционная методология, которую изначально ориентировали на помощь членам института в рамках подготовки к экзамену PMP (Project Management Professional), а так же данная методология по управлению проектами должна была оказать влияние на подход к управлению проектами в будущем.

Методология получила название «A guide to the Project Management Body of Knowledge» или PMBoK. Уже в 1991 году методологию PMBoK признают национальным стандартом ANSI (American National Standards Institute). Первую редакцию такого стандарта по управлению проектами опубликовали в 1994 году. Через два года была выпущена вторая редакция PMBoK, это произошло из-за быстрого роста членов PMI.

В скором будущем появилась третья редакция и называлась она — PMBoK Guide 2000. В 2004 году PMI выпускает своё очередное творение — PMBoK Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI.

31 декабря в 2008 году вышла в свет новая версия методологии — PMBoK Fourth Edition, которая, как и свой предшественник претерпела значительные изменения и стала по сути таким же революционным изданием. В этой версии были изменены сами методики PMI. В стандарт включили дополнительные методики: ведения аналитических работ, прототипирование, итеративность и применение систем искусственного интеллекта с целью построения прогноза реализации и завершения проекта в части сроков и бюджета.

В настоящее время выпущена еще одна версия — PMBoK Guide Fifth Edition, которая включает в себя уже 10 областей знаний и 5 дополнительных процессов (количество процессов всегда менялось от версии к версии, но вот дополнительная область знаний по управлению проектами, добавили впервые).

Дополнительная область знания — Управление заинтересованными лицами (разделили область знаний Communication Management на две: Communication Management и Stakeholders Management). Дополнительные процессы следующие — Plan Scope Management, Plan Schedule Management, Plan Cost Management, Plan Stakeholder Management, а также Control Stakeholder Engagement. Обновление программ сертификации произойдет с 1 июля 2013 года. Дата выпуска PMBoK Guide 6th Edition еще не известна, но PMI уже определились с годом — 2016 год.

Описание методологии PMBoK

Области знаний PMBoK

Руководство PMBoK описывает десять областей знаний, которыми должен обладать руководитель проекта (project manager). В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов.

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

Управление интеграцией проекта (Project Integration Management)

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

В частности даётся схема процессов разработки Устава проекта, Плана управления проектами, Руководства управлением исполнения проекта, Мониторинга и управления работами проекта, описываются процессы общего управления изменениями проекта и завершения проекта или фазы проекта.

Управление содержанием проекта (Project Scope Management)

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

Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ — ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

Управление качеством проекта (Project Quality Management)

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

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

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

Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.

Управление коммуникациями проекта (Project Communications Management)

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

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

Схема  процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Управление ожиданиями заинтересованных сторон проекта (начиная с пятой версии — PMBoK Fifth Edition, данные процессы вынесли в отдельную область знаний — Управление аинтересованными сторонами проекта Project Stakeholder Management), Отчеты об исполнении.

Управление рисками проекта (Project Risk Management)

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

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

Управление поставками проекта (Project Procurement Management)

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

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

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

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Группы процессов PMBoK

Все процессы в руководстве PMBoK разделяются на следующие группы:

Группа процессов инициации

Группа процессов инициации состоит из процессов, способствующих формальной авторизации начала нового проекта.

• Разработка Устава проекта (Develop Project Charter)
• Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования

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

• Разработка плана управления проектом (Develop Project Management Plan)
• План управления содержанием (Plan Scope Management)
• Сбор требований (Collect Requirements)
• Определение содержания (Define Scope)
• Создание иерархической структуры работ — ИСР (Create Work Breakdown Structure — WBS)
• Разработка плана управления расписанием (Develop Schedule Management Plan)
• Определение операций (Define Activities)
• Определение последовательности операций (Sequence Activities)
• Оценка ресурсов операций (Estimate Activity Resources)
• Оценка длительности операций (Estimate Activity Durations)
• Разработка расписания (Develop Schedule)
• Разработка плана управления стоимостью (Develop Cost Management Plan)
• Оценка стоимости (Estimate Costs)
• Определение бюджета (Determine Budget)
• Планирование качества (Plan Quality)
• Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)
• Планирование коммуникаций (Plan Communications)
• Планирование управления рисками (Plan Risk Management)
• Идентификация рисков (Identify Risks)
• Качественный анализ рисков (Perform Qualitative Risk Analysis)
• Количественный анализ рисков (Perform Quantitative Risk Analysis)
• Планирование реагирования на риски (Plan Risk Responses)
• Планирование закупок (Plan Procurements)
• Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

Группа процессов исполнения

Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта. В группу процессов исполнения входят следующие процессы:

• Руководство и управление исполнением проекта (Direct and Manage Project Execution)
• Ообеспечение качества (Perform Quality Assurance)
• Набор команды проекта (Acquire Project Team)
• Развитие команды проекта (Develop Project Team)
• Управление командой проекта (Manage Project Team)
• Управление коммуникациями (Manage Communications)
• Осуществление закупок (Conduct Procurements)
• Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

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

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

• Мониторинг и управление работами проекта (Monitor and Control Project Work)
• Общее управление изменениямиОбщий контроль изменений (Perform Integrated Change Control)
• Подтверждение содержания (Validate Scope)
• Контроль содержанияУправление содержанием (Control Scope)
• Контроль расписанияУправление расписанием (Control Schedule)
• Контроль стоимостиУправление стоимостью (Control Costs)
• Процесс контроля качества (Perform Quality Control)
• Мониторинг и контроль коммуникаций (Monitor and Control Communications)
• Мониторинг и контроль рисков (Monitor and Control Risks)
• Контроль закупокконтрактов (Control Procurement)
• Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

Группа завершающих процессов

Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. Группа завершающих процессов содержит следующие процессы:

• Закрытие проекта или фазы (Close Project or Phase)
• Закрытие контрактов (Close Procurement)

Жизненный цикл по PMBoK

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

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

Инструменты и методы PMBoK

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

Данные инструменты и техники существуют сами по себе и уже давно применяются в различных направления деятельности человека. В процессах PMBoK существуют входы, выходы и методы. Именно при реализации методов определенных процессов и подразумевается применение руководителем проекта (Project Manager) тех или иных инструментов и техник. Ниже приведен список основных методов, инструментов и техник применимых к определенным процессам:

Методы

• Анализ дерева решений (Decision Tree Analysis).
• Анализ допущений (Assumptions Analysis).
• Анализ ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
• Анализ отклонений (Variance Analysis).
• Анализ сети (Schedule Network Analysis или Network Analysis).
• Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
• Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
• Aнализ чувствительности (Sensitivity Analysis).
• Быстрый проход (Fast Tracking).
• Выравнивание ресурсов (Resource Leveling).
• Декомпозиция (Decomposition).
• Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
• Метод Дельфи (дельфийский метод) (Delphi Technique).
• Метод критического пути (Critical Path Methodology, CPM).
• Метод критической цепи (Critical Chain Method).
• Метод Монте-Карло (Monte Carlo Analysis).
• Метод освоенного объема (Earned Value Technique, EVT).
• Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
• Мозговой штурм (Brainstorming).
• Оценка «снизу вверх» (Bottom-up Estimating).
• Планирование методом набегающей волны (Rolling Wave Planning).
• Управление освоенным объемом (Earned Value Management, EVM).

Инструменты

• Диаграмма Ганта (Gantt Chart).
• Диаграмма Парето (Pareto Chart).
• Иерархическая структура рисков (Risk Breakdown Structure, RBS).
• Информационная система управления проектами (Project Management Information System, PMIS).
• Матрица вероятности и воздействия (Probability and Impact Matrix).
• Матрица ответственности (Responsibility Assignment Matrix, RAM).
• Расписание контрольных событий (Milestone Schedule).
• Сетевая модель (Schedule Model).
• Система санкционирования выполнения работ (Work Authorization System).
• Система управления изменениями (Change Control System).
• Система управления конфигурацией (Configuration Management System).

Экзамены, сертификация и обучение

На данный момент в мире насчитывается более 470,000 менеджеров и специалистов по управлению проектами, имеющих сертификацию PMP – Project Management Professional. Степень по управлению проектами PMP, может получить каждый специалист из любой отрасли. PMP позволяет войти в ряды самого большого и престижного сообщества специалистов по управлению проектами.

Для получения степени PMP,  необходимо соответствовать определенным требованиям к образованию и опыту работы. Также необходимо пройти экзамен в виде теста на компьютере в специализированных аккредитованных центрах по всему миру (Registered Education Provider). Данный тест разработан для объективной оценки компетенций претендента в части управления проектами.

Требования к кандидату

Необходимо соответствовать первой или второй категории. Первая категория — высшее образование (не ниже бакалавра), 4,500 часов (36 непересекающихся месяцев за последние 6 лет) работы в области управления проектами (по пяти группам процессов) до подачи заявки. Также на момент подачи заявки, кандидат должен иметь 35 часов обучения (PDU).

При себе иметь подтверждающие документы:

1. Сведетельство о высшем образовании.
2. Форма подтверждения опыта
3. Перечень обучающих программ, пройденых кандидатом (35 PDU)

Посредством теста на степень PMP оцениваются применение знаний и навыков, использование инструментов и методов применяемых на практике при управлении проектами. Еще в 1997 году были разработаны требования к экзамену. Претенденту необходимо выбрать один правильный ответ из 4 вариантов по каждому из 200 вопросов. Сам тест состоит из 175 вопросов, остальные 25 вопросов определяются, как претестовые и в зачет не идут. Все вопросы в тесте разрабатываются комиссией, состоящей из специалистов со степенью PMP. Вопросы входящие в тест, ежегодно проверяются на соответствие экзаменационным требованиям. Для успешного прохождения теста, претенденту, за 4 часа, необходимо положительно ответить на 106 вопросов из 175. Получается, что проходной балл по экзамену составляет 61%.

Подготовка к экзамену PMP

Из множества учебников и материалов для подготовки к экзамену на степень PMP основным конечно же является сам свод знаний по управлению проектами — PMBoK Guide. Данный стандарт на двух языках (английский и русский) и множество дополнительных материалов (книг и учебников) по управлению проектами можно приобрести в специализированных on-line магазинах PMI.

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

Содержание экзамена PMP

Далее в процентном соотношении представлена разбивка вопросов экзамена по группам процессов:

• Инициация проекта (Project Initiating) – 13 % вопросов
• Планирование проекта (Project Planning) – 24 % вопросов
• Исполнение проекта (Project Executing) — 30 % вопросов
• Контроль проекта (Project Control) – 25 % вопросов
• Завершение проекта (Project Closing) – 8 % вопросов

В свое время, PMI провело исследование по описанию ролей (The Role Delineation Study), которое в последствии легло в основу Кодекса Профессиональной Этики (PMP Examination Specification). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Просмотры: 32 937

РУКОВО́ДСТВО, -а, ср.

1. Действие по глаг. руководить (в 1 знач.). Руководство революционной борьбой пролетариата. □ Людей поделили — одни под руководством Борейко занялись ремонтом орудий —, а другие со Звонаревым приступили к сборке новых. Степанов, Порт-Артур.

2. То, чем руководствуются или следует руководствоваться. Марксистско-ленинская теория не символ веры, не собрание догматов, а руководство к действию. М. Калинин, О коммунистическом воспитании. В моем положении ничего не оставалось, как взять это изречение за руководство в своем поведении на корабле. Новиков-Прибой, Цусима.

3. Учебник, пособие для изучения чего-л. Руководство по домоводству. □ На обязанности наставников семинарии должно также лежать составление учебных руководств, преимущественно для народных школ. Ушинский, Проект учительской семинарии. В русской литературе вовсе нет руководства к истории музыки, и было бы очень хорошо, если б я занялся составлением такой книги. Чайковский, Письмо Н. Ф. Мекк, 9 сент. 1880.

4. собир. Руководители. Руководство Союза писателей. Художественное руководство театра. □ — Этой выставкой мы целиком обязаны — да не в обиду будет сказано нашему руководству — одной из рядовых сотрудниц. Паустовский, Телеграмма.