61. Технологии разработки программного обеспечения. Управление проектами.

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

Существует несколько разновидностей процесса разработки:

• водопадная модель (процесс представляется последовательностью фаз анализа требований, проектирования, реализации, интеграции и тестирования);

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

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

• унифицированный процесс разработки ПО (USDP) (USDP – итеративный процесс, классифицирующий итерации на 4 группы: начальные итерации, итерации проектирования, итерации конструирования, итерации перехода)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типичная схема процесса управления проектом:

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

1. Понять содержание проекта, область применения и временные рамки.

2. Определиться с процессом разработки (методы, инструменты, языки, документация и поддержка, модель процесса разработки).

3. Выделить организационную структуру (привлечение отделов организации).

4. Определить управляющий процесс (ответственность участников).

5. Разработать расписание проекта (моменты сдачи частей работы).

6. Разработать план подбора кадров.

7. Начать управление рисками.

8. Определить, какие документы необходимо выработать (например, документы SVVP и SRS стандарта IEEE).

Начать сам процесс.