Постановка задачи, оценка осуществимости
Обычно заказчик выдаёт две-три страницы текста задания и сразу же просит оценить время исполнения заказа и его стоимость. Надо быть сумасшедшим, чтобы с этим согласиться. Не редки случаи, когда целые коллективы ошибаются в пять-десять раз и попадают в кабалу или теряют профессиональную репутацию. Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на две-четыре недели, с тем, чтобы два-три системных аналитика разобрались в задаче, с помощью каких-то инструментальных средств выполнили декомпозицию системы на компоненты, прикинули возможные объёмы этих компонент и, соответственно, время их реализации. Такая начальная стадия ЖЦП называется "оценкой осуществимости". A{ST}P – проверка корректность её решения, на практике невозможно.
Постановка задачи – наиболее творческая часть ЖЦП, которая содержит в себе почти что философские проблемы.
Надо описать поведение разрабатываемой системы. Эта система получает какие-то сигналы из её окружения, поэтому вам надо описать поведение окружения, но окружение само зависит и изменяется под влиянием системы, её сигналов, особенно аварийных.
Разрешают это противоречие с помощью постепенного уточнения поведения, как системы, так и её окружения (т.е. делают декомпозицию).
Декомпозицию необходимо производить обязательно – лишь она позволяет вычислить более-менее реальные сроки реализации.
Сегодня, когда мы говорим "формализация постановки задачи", мы подразумеваем разработку последовательности моделей, каждая из которых описывает систему и её окружение с различных точек зрения с постепенной детализацией. Существенно, что все представления о системе, полученные в разных моделях, должны собираться в едином репозитории (некоторой специальным образом устроенной базе данных) с тем, чтобы иметь возможность сквозного проектирования, при котором каждая следующая модель использует результаты предыдущей и уж никак им не противоречит. Соответственно, и всевозможные проверки должны быть сквозными.
Планирование
При планировании полезно строить сетевой график. Есть 2 выдел. вершины - начало и конец. Дуги – работы (вместе с длительностью), вершины – промежуточные состояния (в вершина написаны действия в совершенном виде – «оборудование закуплено», «коллектив сформирован»). На таком графике видна последовательность работ, их длительность.
Критический путь – самый длинный путь от начала до конца.
Все ветви должны быть равнонагружены (хотя это тоже плохо – нет резерва).
Е
сли
сроки срываются, то либо увеличивать
ресурсы, либо раздвигать сроки.
Планирование неразрывно связано с управлением.
Добавлять людей, деньги («стимулирование»). //У МикроМягких же за срыв сроков лишают премии весь коллектив.
Кроме сетевого графика можно также строить диаграмму Ганта:
-По вертикали выписываем работы, по горизонтали – сроки, ставим промежутки исполнения – удобно смотреть, что должно быть завершено в настоящий момент, какие работы идут. //Диаграмма Ганта более удобна при управлении, чем при планировании.
Управление должно быть постепенным, регулярным. Должен быть запас ресурсов.
Если горит работа на критическом пути, то надо сокращать сроки на последующие работы (увеличивать технологии производства).
//Основа всего – ТЕХНИЧЕСКАЯ ВООРУЖЕННОСТЬ