6 ) Задачи и проблемы планирования разработки.

Задачи планирования:

1. Определение списка работ (WBS – Work Breakdown Structure)

2. Определение списка исполнителей

3. Проецирование исполнителей и работы на шкалу времени

Инструментарий: MS Project, Spyder Project, Primavera Project Planner.

Проблемы:

Известно, что оптимальный вариант плана приходится искать в «железном треугольнике», или «треугольнике компромиссов»:

• ресурсы (люди и деньги);

• качество (возможности, требования);

• время.

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

7 ) Понятие конфигурации и управления конфигурацией, задачи управления конфигурацией.

Конфигурация – это совокупность всех сведений о проекте в виде файлов и документов.

Управление конфигурацией позволяет:

• определить что надо хранить (выполнить конфигурационную идентификацию);

• организовать хранение всей истории изменений;

• организовать согласованность внесения изменений (контроль конфигурации);

• организовать хранение моментальных снимков (версий) конфигурации, то есть согласованных состояний проекта в некоторые важные моменты времени(2 variants: Lock – Modify – UnLock (в случае Check In – снимается блокировка и копия записывается в «мастер копий», после чего становится доступной для всех), Copy – Modify – Merge (хранит историю изменений + версию сравнений изменений в случае временного или постоянного отката)).

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

• выбор и внедрение системы управления версиями (version control system: borland star team, Microsoft TFS, SVN);

• разработка организационного обеспечения (регламента управления конфигурацией).

• Назначение ответственных лиц (распределение обязанностей)

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

• управление составом конфигурации (набором хранимых файлов);

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

• разрешение проблем;

• резервное копирование (backup).

8 ) Модель зрелости возможностей cmm.

CMM (Capability Maturity Model) — модель зрелости возможностей, созданная в 1987 г. организацией Software Engineering Institute (SEI) при университете Карнеги-Меллон, США.

Ключевым понятием стандарта CMM является зрелость организации.

1. Начальный уровень (Initial level). На этот уровень не сертифицируются, он описан как отправная точка. К данному уровню относится любая компания, которой удалось получить заказ на разработку программного продукта. В организации царит анархия при разработке, нет четких процессов управления и четких инженерных процессов. Могут существовать стандарты и инструкции, но им никто не следует. Успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственны неравномерность процесса разработки — наличие затиший и авралов в работе. Организация полностью зависит от конкретных разработчиков, которые «тянут» на себе всю работу, а их уход неминуемо означает крах проекта.

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

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

4. Управляемый уровень (Managed level). Кроме «примитивных» показателей качества (хорошо/плохо, быстро/медленно и т. п.) устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Информация обо всех проектах собирается в базе данных. Достигается полное управление проектами и предсказуемость программного процесса и качества программ.

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

В 2000 г. SEI предложил сменить CMM новой, улучшенной моделью — CMMI (Capability Maturity Model Integration). CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.).