2.Программные системы

2.1.Управление программным проектом

2.1.1Введение

• “Программный кризис” 1960-ых и 1970-ых был так назван из-за вереницы крупных провалов проектов программного обеспечения: не уложились бюджет, не выполнили в срок и т.д.

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

• Были необходимы методы управления программными проектами.

Хорошее управление проектом не может гарантировать успех, но недостаточное управление значимыми проектами всегда ведет к провалу.

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

– Изделие неосязаемо.

Нельзя утверждать, что мост на 90 % построен, если нет 90 % моста в наличии.

Можно сказать, что программный проект на 90 % реализован, даже если нет видимых результатов.

– Отсутствие достаточного опыта в данной области.

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

– Большие проекты программного обеспечения - часто "делаются на заказ".

Большинство больших программных систем единичны, опыт, полученный в одном проекте не принесет большой помощи в другом.

– Технология изменяется очень быстро.

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

• Действия по управлению проектом программного обеспечения:

– планирование проекта;

– составление графика работ по проекту;

– управление рисками;

– управление людьми.

2.1.2Планирование проекта

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

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

• Типы плана:

– План разработки программного обеспечения.

Основной план, который описывает, каким образом система будет создана.

– План проверки качества.

Определяет процедуры для определения качества и стандарты, которые будут использоваться.

– План ратификации.

Определяет план приемки программного продукта заказчиком.

– План управления конфигурацией.

Определяет, как система будет сконфигурирована и установлена.

– План обслуживания.

Определяет, как система будет

сопровождаться.

– План обучения пользователей.

Описывает навыки, необходимые пользователям системы.

• Мы сосредоточимся на плане разработки программного обеспечения и плане проверки качества.

2.1.2.1План разработки программного обеспечения

• Обычно это то, что называется планом проекта.

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

• Может быть как маленьким и относительно неформальным так и большим и полностью официальным.

• Создание плана проекта столь же важно, как и само проектирование кода:

На основе плана проекта, подписываются контракты и достигается или не достигается успех...

• Важно не:

– переоценить способности вашей команды;

–говорить клиентам просто то, что они хотят услышать;

– оказываться под давлением разработчиков (“мы можем сделать это днем! ”)