Особенности управления проектами в области разработки программного обеспечения, Курсовая работа

метки: Управление, Разработка, Продукт, Программный, Представлять, Набор, Внедрение, Дальнейший

КУРСОВАЯ РАБОТА, Особенности управления проектами в области разработки программного обеспечения

управление программный проектный

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

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

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

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

Подход к управлению проектами уже доказал свою эффективность на практике и используется ведущими компаниями мира, успешно применяется IBM, Motorola, Boeing, Intel и многими другими.

.1 История и основные понятия

Программное обеспечение (далее ПО) появился в 1958 году благодаря трудам статистика Джона Тьюкей.

8 стр., 3520 слов

Управление реализацией проекта

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

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

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

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

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

28 стр., 13919 слов

«Облачные технологии работы с документами». Лекционное занятие ...

... которых предстоит разобраться. Выбор облачных технологий для работы с документами актуален в связи с тем, что он предполагает ... распространено определение облачных технологий, которое было предложено Национальным институтом стандартов и технологий США: «Облачные технологий, представляют собой модель ... но и программы. Мурзин Ф. А., Батура Т. В., Семич Д. Ф. Облачные технологии: основные понятия, ...

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

3 стр., 1489 слов

Программы для проектирования

... Использует ЗАО «Тюменьнефтегазпроект». проектирование программа трехмерный презентация Примеры SolidWorks SolidWorks (Солидворкс) -- программный комплекс САПР для автоматизации ... расчет контактных задач и так далее. инженерного анализа на ранних стадиях разработки изделия ... справочной документации. Русскоязычная версия локализована полностью, включая интерфейс командной строки и всю документацию, ...

6 стр., 2817 слов

Разработка проекта по обоснованию концепции, проектированию, ...

... Цель данной курсовой работы - разработка проекта по обоснованию концепции, проектированию, созданию и эксплуатации объекта - жилой дом. Задачами курсовой работы являются : предварительное формулирование цели и задач проекта; формирование команды проекта, распределение ролей и работ; разработка обоснований, ...

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

Модель процесса разработки ПО — формализованное представление процесса разработки ПО. Часто при описании процессов вместо слова модель употребляется термин методология, что приводит к неоправданному расширению данного понятия.

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

13 стр., 6245 слов

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

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

Software requirements — программные требования.
Software design — дизайн (архитектура).
Software construction — конструирование программного обеспечения.
Software testing — тестирование.
Software maintenance — эксплуатация (поддержка) программного обеспечения.

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

Software engineering management — управление в программной инженерии.
Software engineering process — процессы программной инженерии.
Software engineering tools and methods — инструменты и методы.

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

Дополнительные области знаний включают в себя:

Computer engineering — разработка компьютеров.
Computer science — информатика.
Management — общий менеджмент.
Mathematics — математика.
Project management — управление проектами.
Quality management — управление качеством.
Systems engineering — системное проектирование.

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

.2 Эволюция подходов к управлению программными проектами

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

«Как получится». Разомкнутая система управления. Полное доверие техническим лидерам. Представители бизнеса практически не участвует в проекте. Планирование, если оно и есть, то неформальное и словесное. Время и бюджет, как правило, не контролируются. Аналогия: баллистический полет без обратной связи. Можно, но недалеко и неточно.

«Водопад» или каскадная модель. Жесткое управление с обратной связью. Расчет опорной траектории (план проекта), измерение отклонений, коррекция и возврат на опорную траекторию. Лучше, но не эффективно.

«Гибкое управление». Расчет опорной траектории, измерение отклонений, расчет новой попадающей траектории и коррекция для выхода на нее. «Планы — ничто, планирование — все» (Эйзенхауэр, Дуайт Дэвид)

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

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

28 стр., 13798 слов

Проектирование продукта, стоимостной анализ при проектировании продукта

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

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

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

Известно, что производительность разных программистов может отличаться в десятки раз. Утверждаю, что производительность одного и того же программиста может так же отличаться в десятки раз. Заставьте лучшего в мире бегуна бегать в мешке, и он покажет в 10 раз худший результат. Заставьте лучшего программиста заниматься «сизифовым трудом»: плодить документацию (которую, как правило, никто не читает) в угоду «Методологии» (именно с большой буквы ‘М’), — и его производительность снизится в 10 раз.

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

.3 Оценка успешности проекта разработки программного обеспечения

Стив Макконнелл в своеих работах приводит тест программного проекта на выживание. Это перечень из 33-х пунктов. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих процессов.

Чтобы программный проект стал успешным, необходимо:

Четко ставить цели.
Определять способ достижения целей.
Контролировать и управлять реализацией.
Анализировать угрозы и противодействовать им.
Создавать команду.
Ставим цели

1. Концепция определяет ясные недвусмысленные цели.

2. Все члены команды считают концепцию реалистичной.

3. У проекта имеется обоснование экономической эффективности.

4. Разработан прототип пользовательского интерфейса.

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

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

Определяем способ достижения целей

1. Имеется детальный письменный план разработки продукта.

2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).

3. После каждой фазы проекта обновляется расписание и бюджет.

4. Архитектура и проектные решения документированы.

5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.

6. Определен план многоэтапной поставки продукта.

7. В плане учтены обучение, выходные, отпуска, больничные.

15 стр., 7351 слов

Автоматизация управленческого учета в строительстве. Основные ...

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

8. План проекта и расписание одобрен всеми участниками команды.

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

2. У проекта есть менеджер, причем только один!

3. В плане проекта определены «бинарные» контрольные точки.

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

5. Между руководством и разработчиками установлены доверительные отношения.

6. Установлена процедура управления изменениями в проекте.

7. Определены лица, ответственные за решение о принятии изменений в проекте.

8. План, расписание и статусная информация по проекту доступна каждому участнику.

9. Код системы проходит автоматическое рецензирование.

10. Применяется система управления дефектами.

Анализируем угрозы

1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.

2. Руководитель проекта отслеживает возникновение новых рисков.

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

Работаем над созданием команды

1. Опыт команды достаточен для выполнения проекта.

2. У команды достаточная компетенция в прикладной области.

3. В проекте имеется технический лидер.

4. Численность персонала достаточна.

5. У команды имеется достаточная сплоченность.

6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

0 — даже не слышали об этом;
1 — слышали, но пока не применяем;
2 — применяется частично;
3 — применяется в полной мере.

Поправочные коэффициенты:

для малых проектов (до 5 человек) — 1.5;
для средних (от 5 до 20 человек) — 1.25.

Результат:

<40 — завершение проекта сомнительно.
40-59 — средний результат. В ходе проекта следует ожидать серьезные проблемы.
60-79 — хороший результат. Проект, скорее всего, будет успешным.
80-89 — отличный результат. Вероятность успеха высока.
>90 — великолепный результат. 100% шансов на успех.

1.4 Критерии успешности проекта

Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника» (Рисунок 2).

Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие.

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

Например, чтобы уменьшить время, потребуется увеличить стоимость и / или сократить содержание.

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

14 стр., 6549 слов

Математическое обеспечение и администрирование информационных ...

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

Программные продукты обычно представляют собой совокупность программ и необходимых

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

Выполнен в соответствие со спецификациями.
Выполнен в срок.
Выполнен в пределах бюджета.
Каждый участник команды уходил с работы в 18:00 с чувством успеха.

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

Эффективность это отношение полученного результата к произведенным затратам. Нельзя рассматривать эффективность, исходя только из результативности: чем больше ты производишь, чем больше делаешь, тем выше твоя эффективность.

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

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

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

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

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

.1 Особенности организации проектной команды

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

Роли и ответственности участников типового проекта разработки ПО можно условно разделить на пять групп:

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

Группа анализа включает в себя следующие роли:

Бизнес-аналитик. Построение модели предметной области (онтологии).
Бизнес-архитектор.

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

Системный аналитик. Отвечает за перевод требований к продукту в функциональные требования к ПО.
Специалист по требованиям. Документирование и сопровождение требований к продукту.
Менеджер продукта (функциональный заказчик).
Представляет в проекте интересы пользователей продукта.

Группа управления состоит из следующих ролей:

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

Куратор проекта. Оценка планов и исполнения проекта. Выделение ресурсов.

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

В производственную группу входят:

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

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

Группа тестирования в проекте состоит из следующих ролей:

Проектировщик тестов. Разработка тестовых сценариев.
Разработчик автоматизированных тестов.
Тестировщик.

Тестирование продукта. Анализ и документирование результатов.

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

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

В зависимости от масштаба проекта одну роль могут исполнять несколько человек. Например, разработчики, тестировщики, технические писатели.

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

Руководитель проекта + системный аналитик (+ системный архитектор)
Системный архитектор + разработчик
Системный аналитик + проектировщик тестов (+ технический писатель)
Системный аналитик + проектировщик интерфейса пользователя
Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик)

Крайне нежелательно совмещать следующие роли:

Разработчик + руководитель проекта
Разработчик + системный аналитик.
Разработчик + проектировщик интерфейсов пользователя.
Разработчик + тестировщик

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

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

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

Из профессиональных программистов получаются отличные тестировщики. Лучшая команда тестирования, которую я встречал, была в Luxoft. Это были маститые программисты из одного академического НИИ с опытом 20-30 лет.

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

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

В модели Scrum рекомендуются ежедневные совещания по состоянию работ — «Stand Up Meeting», но мне кажется, что это применимо, скорее, для небольших рабочих групп от 3 до 5 разработчиков. Хотя в критические периоды проекта, приходилось проводить и ежедневные совещания.

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

2.2 Жизненный цикл проекта. Фазы и продукты

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

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

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

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

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

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

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

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

Распределение ресурсов по фазам проекта

Проект часто начинается с идеи, которая появляется у одного человека.

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

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

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

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

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

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

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

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

Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется.

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

В российской практике данный документ чаще называется Концепция проекта.

Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.

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

Приоритет любого проекта должен определяться на основе оценки трех его характеристик:

Финансовая ценность.
Стратегическая ценность.
Уровень рисков.

Шкала оценки финансовой ценности проекта может выглядеть

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

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

Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

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

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

Шкала оценки стратегической ценности проекта может иметь

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

Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года.

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

Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.

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

Примерная шкала оценки уровня рисков проекта может иметь

Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

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

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

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

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

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

2.4 Особенности рисков программных проектов и способы реагирования

В мировой практике выделяют пять основных причин неудачного исполнения проекта:

Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
Отсутствие необходимых ресурсов и опыта.
Отсутствие рабочего взаимодействия с заказчиком.
Неполнота планирования. «Забытые работы».
Ошибки в оценках трудоемкостей и сроков работ.

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

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

Функциональные

o Программы установки,

o Миграция данных.

o Интерфейсы с внешними системами.

o Справочная система.

Общесистемные

o Производительность.

o Надежность.

o Открытость.

o Масштабируемость.

o Безопасность.

o Кросплатформенность.

o Эргономичность.

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

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

Переоценка проекта каждый раз, когда требования добавляются / изменяются (уклонение).
Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).
Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).

Для большинства программных продуктов применим принцип Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

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

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

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

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

При планировании работ по проекту часто «забывают»:

Обучение.
Координация работ.
Управление конфигурациями.
Разработка и поддержка скриптов автосборки.
Разработка автотестов.
Создание тестовых данных.
Обработка запросов на изменения.

И еще. Не стоит надеяться, что участники проекта будут каждую неделю по 40 часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени. К списку наиболее распространенных причин этого относятся:

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

Рекомендация, планировать, что разработчики, которые назначены в проект на 100% будут реально работать над ваши ми задачами в среднем от 24 до 32 часов в неделю.

Не существует единственного правильного процесса разработки ПО.

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

Чтобы программный проект стал успешным, необходимо:

Четко ставить цели.
Определять способ достижения целей.
Контролировать и управлять реализацией.
Анализировать угрозы и противодействовать им.
Создавать команду.

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

Участников типового проекта разработки ПО можно условно разделить на пять групп ролей:

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

У программного проекта имеется четыре фактора, которые определяют его успешность:

Выполнен в соответствие со спецификациями.
Выполнен в срок.
Выполнен в пределах бюджета.
Каждый участник команды уходил с работы в 18:00 с чувством успеха.

1. Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: ДМК-Пресс.2002.

2. Грей К, Ларсен Э. Управление проектами. Пер. с англ. — М.: «Дело и Сервис».2003.

Дитхелм Г. Управление проектами. В 2 т.: Пер. с нем. — СПб.: Издательский дом «Бизнес — пресса», 2003.-258 с.
Кофанов Ю.Н.

Теоретические основы конструирования, технологии и надежности радиоэлектронных средств. — М.: Радио и связь, 1991.-360 с.

ЛитвакБ.Г. Экспертная информация. Методы получения и анализа. — М.: Радио и связь, 1982.
Руководство к Своду знаний по управлению проектами.

Третье издание (Руководство PMBOK)/. Американский национальный стандарт ANSI/PMI 99-001-2004.

Топка В.В. Вероятностное моделирование в управлении проектами. — М., 1995 (Препринт / Институт проблем управления).
Управление проектами.

Основы профессиональных знаний. Национальные требования к компетенции специалистов. — М.: Изд-во «Консалтинговое Агентство «КУБС Групп — Кооперация, Бизнес-Сервис», 2001.

Управление проектами: Основы профессиональных знаний. Национальные требования к компетентности специалистов. М.: Изд-во «Консалтинговое Агенство «КУБС Групп — Кооперация, Бизнес — Сервис», 2001-265 с.
Щедровицкий Г.П.

Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4).

М.: «Путь», 2000 — 384 с.

Примеры похожих учебных работ

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

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

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

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

Жизненный цикл информационных систем

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

По предмету Управление качеством : «Стандарты при разработке программного обеспечения»

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

Технология разработки программного обеспечения (2)

Выполнял функции техника-программиста: Участвовал в проектировании ПО; Участвовал в разработке ПО; Тестировал ПО; Разрабатывал программную документацию; Проводил техническое обслуживание ПЭВМ; Занимался поиском и устранением неисправностей ...