Программное обеспечение и его разработка - [20]
Рис. 4.5. Жизненный цикл административного здания.
Мы должны ломать стены, строить новые, переделывать отопительную систему, менять энергосеть и т. д. (см. рис. 4.5).
В связи с этим, если мы предполагаем возможность каких-либо изменений в здании в будущем, то при исходном проектировании здания (и составлении проектных документов) должны позаботиться о том, чтобы текущий и капитальный ремонт проходил без затруднений.
Обратите внимание на то, что при переходе к программному обеспечению (рис. 4.6) мы меняем слова, стоящие на правой нижней линии схемы.
Рис. 4.6. Жизненный цикл программы
Вместо слова «ремонт» стоят слова «внесение изменений». Слово «строительство» также заменяется словом «разработка».
Рис. 4.7. Жизненный цикл программного обеспечения.
Однако в большей степени для программного обеспечения, особенно для больших систем, подходит схема на рис. 4.7. В исходном программном обеспечении имеются ошибки, которые прошли сквозь фазу тестирования и могут быть обнаружены только после того, как заказчик начнет пользоваться сделанной для него системой. Таким образом, теперь усилия будут тратиться на продолжение разработки, которая, однажды начавшись, практически никогда не заканчивается.
Рис. 4.8 показывает принципиальное отличие жизненного цикла аппаратуры от жизненного цикла программного обеспечения.
На этом рисунке показано, что в процессе разработки аппаратуры есть такие фазы, как фаза производства, фазы повышения технологичности и ремонтопригодности.
Рис 4.8 Жизненный цикл аппаратуры.
Простое перечисление этапов разработки аппаратуры, особенно указание на необходимость затрат на повышение технологичности и ремонтопригодности, говорят нам о многом. Инженеры специально анализируют прибор, который им необходимо создать, и старательно разрабатывают конвейер, так что заводские затраты в расчете на одно устройство будут минимальны. При этом всегда получается так, что серийный образец существенно отличается от опытного, построенного при разработке. Программное обеспечение не запускается в производство, и при его разработке фаза повышения технологичности отсутствует.
Рис. 4.9 Одна группа руководит работами на всех стадиях жизненного цикла
Рис. 4.10 Три руководящие группы; один жизненным цикл.
Другой функцией при разработке аппаратуры является повышение ремонтопригодности. Здесь инженеры вносят в прибор такие изменения, которые облегчат его текущий и капитальный ремонт в условиях использования. Их деятельность направлена на то, чтобы минимизировать требования к людям, производящим ремонт, к запасным частям, процедурам наладки и проверки. Процесс разработки обеспечения также включает в себя задачу снижения затрат на сопровождение, причем этой стороне должно уделять значительное внимание. Очень часто дата сдачи программы настолько связывает разработчиков, что все их усилия направляются только на то, чтобы уложиться в отведенные сроки, и никто не предпринимает никаких усилий дня облегчения последующей фазы сопровождения. Как мы увидим, правильно проводимая разработка должна включать в себя работы по обеспечению легкости сопровождения.
Другая причина того, что работы по облегчению будущего продолжения разработки зачастую не проводятся, заключается в том, что руководство различными фазами обычно проводится разными людьми. Рис. 4.9 показывает, что иногда руководство всеми тремя фазами находится в одних руках. Но это исключения.
Чаще же действует схема, изображенная на рис. 4.10. Имеются три ведущие группы, по каждой фазе своя. Руководители разработки мало заботятся о затратах на сопровождение и проблемах, возникающих на этой фазе.
При разном руководстве создаются условия для возникновения ошибок. Стрелки А на рис. 4.10 направлены в обе стороны, поскольку пользователи должны иметь возможность передавать свои требования разработчикам. Часто они лишены такой возможности.
Разработчики должны сформулировать, что именно может быть использовано в фазе использования и каким образом. Однако во многих случаях этого нельзя достичь без подробных инструкций для пользователей.
Все это относится и к стрелке С, с той лишь дополнительной проблемой, что очень часто группа сопровождения даже не существует в тот момент, когда разработка уже идет полным ходом. Слишком часто все озабочены только своими проблемами.
Смысл стрелки В вполне понятен и ясен, но она обычно игнорируется до тех пор, пока не случится какой-нибудь казус!
Нарисуем простейшую схему жизненного цикла программного обеспечения двумя разными способами, что даст нам возможность выделить основные моменты.
Рис. 4.11. Патологический жизненный цикл программного обеспечения, пример 1 (вверху).
Рис. 4.12. Патологический жизненный цикл программного обеспечения, пример 2 (внизу).
Первая схема (рис. 4.11) иллюстрирует разрыв между разработкой и продолженной позднее разработкой. Во многих случаях за эти этапы отвечают совершенно разные организации. Заключившая контракт группа в Новой Англии разрабатывает, а где-то на юге другая группа ведет сопровождение. Пунктирная линия между разработкой и продолжающейся разработкой показывает, что этот переход не гладкий и не простой. В действительности во многих случаях мы можем нарисовать такую схему, как на рис. 4.12.
