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

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

Результат: продукт и процесс с предсказуемой количественной оценкой качества.

Недостаток: нет механизма улучшения процесса.

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

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

22. Процесс приемки-сдачи ПО в эксплуатацию и необходимая документация.

 

23. Управление проектом: создание, продвижение  и сопровождение программного  продукта. Основные параметры: стоимость,  функциональность, качество, расписание.

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

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

Управление проектом охватывает:

♦ инфраструктуру (организационные моменты);

♦ управляющий процесс (нрава и ответственности участников);

♦ процесс разработки (методы, инструменты, языки, документация и поддержка);

♦ расписание (моменты времени, к которым должны быть представлены вы 
полненные фрагменты работы).

Основные параметры: стоимость, функциональность, качество и расписание

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

1. Общая стоимость проекта. Например, увеличивать расходы.

2. Возможности продукта. Например, удалять их из списка возможностей продукта.

3. Качество продукта. Например, увеличивать среднее время наработки на отказ (MTBF).

4. Длительность проекта. Например, сократить расписание на 20 % или отложить завершение проекта на один месяц.

Степень контроля над этими  четырьмя факторами зависит от проекта. Несмотря на то, что стоимость может быть оговоренной заранее и фиксированной, зачастую существуют различные гибкие варианты. Предположим, что наш заказчик — химик, которому необходима визуализация молекул в 2D-графике. 
После просмотра прототипа молекулярной модели в трехмерной графике заказчик может положительно отнестись к дополнительным расходам, поскольку 3D-прототип выглядит намного лучше, чем двумерный. Возможности продукта также не являются фиксированными, как это может показаться сначала. Например, заказчик может отказаться от некоторого требования, если это сократит длительность проекта на 15 %. Хотя это может показаться ерундой, но даже показатели качества могут варьироваться. Если целевые значения показателей качества установлены слишком низко, это может привести к увеличению расходов на переделки из-за неудовлетворенности заказчика. Если же целевые значения показателей качества установлены слишком высоко, то затраты на поиски самой последней незначительной ошибки могут оказаться недопустимо высокими.

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

Один из способов визуализировать значения данных четырех  переменных состоит в использования  так называемых лепестковых диаграмм. В диаграммах данного типа значение каждой переменной откладывается на оси, исходящей из центра. Оси рисуются симметрично относительно центра. Конкретный пример лепестковой диаграммы показан на рис. 2.2. Поскольку в данном случае осей 
четыре, они перпендикулярны. На каждой оси центру соответствует наименее желательное значение показателя, а целевое значение откладывается на некотором расстоянии от центра. Таком образом, получается четырехугольник (если бы показателей было пять, то получился бы пятиугольник, и т. д.). Например, на оси «Возможности» центр соответствует значению «О % требований выполнено», а единица — «100 % требований выполнено». Фактические значения обычно находятся где-то в промежутке, хотя могут и выходить за пределы многоугольника, если удается перекрыть плановые значения показателей. Состояние проекта отражается путем закрашивания многоугольника фактических значений. Чем больше целевой многоугольник заполняется фактическим, тем точнее мы достигаем поставленных целей. Такая визуализация позволяет руководителю проекта правильно расставить приоритеты при принятии решений.

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

 

24. Сопровождение ПО.

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

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

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

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

 

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

Управление персоналом проекта 

Профессионализм

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

С 1994 по 2000 год объединенная комиссия IEEE и АСМ работала над определением критериев, по которым можно выделить профессиональных разработчиков программного обеспечения.

Важность управления персоналом

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

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

Корпоративные аспекты

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

Управленческие  аспекты

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

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

Организация совещаний

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

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

Хорошей практикой является предварительная подготовка повестки дня совещания.