Джозеф Фокс - Программное обеспечение и его разработка

Нам следует быть осторожными и не путать методы, применяемые в одном из разделов разработки программного обеспечения, с методами, используемыми в других частях этого процесса. Люди, занимающиеся торговлей программной продукции, приклеивают слово «структурный» к любому применяемому методу. Раз метод «структурный», товар будет продан.

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

В моду входит термин «структурные требования». Он ничего общего не имеет с терминами структурное программирование и структурное проектирование. Сейчас уже появляется структурная документация, структурный английский язык и т. д. и т. п.

Если мы можем точно определить данный термин, как это сделали для структурного программирования Милс, Лингер и Уитт, то может быть этот термин и окажется полезным. В общем случае, все это отдает торгашеским духом, о чем можно только пожалеть — ведь у метода наверняка есть свои достоинства, просто его не надо называть «структурным».

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

Полная стоимость системы программного обеспечения часто складывается всего из двух частей — стоимости первоначальной разработки и стоимости продолжающейся разработки. (См. рис. 6.24)

Продолжающаяся разработка (сопровождение) может составлять большую часть полной стоимости — до 70 или 80 %. Но может быть и так, что ее доля будет очень небольшой. Такие колебания зависят от нескольких факторов. Наиболее важными среди них оказываются продолжительность срока использования программного обеспечения — 1 год или 20 лет; стабильность внешнего окружения, влияющего на программное обеспечение; а также качество программного обеспечения, достигнутое во время разработки.

Мне не раз демонстрировали схемы, на которых указано, что «70 % затрат на программное обеспечение было сделано при его сопровождении». Это чрезмерное упрощение! Для очень большого числа программных систем это просто неправда.

Почему наши оценки столь оптимистичны? Часто мы просто боимся, что узнав наши настоящие прогнозы, начальство остановит работы над проектом. И мы выдаем оптимистические планы, основанные на том, что все пойдет без сучка, без задоринки. Получив их, руководство скорее всего просмотрит их поверхностно, поскольку оно мало что понимает в программном обеспечении. А мы будем продолжать нарушать графики и перерасходовать бюджет.

Все это, конечно же, относится и к аппаратным проектам! Но может быть в программном обеспечении число серьезных проблем превышает нормальную дозу, которая имеется во всех сложных областях человеческой деятельности? Да, это связано с новизной отрасли, а следовательно, с отсутствием в ней должного уровня дисциплины, применением новейших методов. Добавим сюда высокий уровень абстрактности.

Когда опасность угрожает всему проекту в целом, когда его пытаются отменить из-за слишком больших затрат, разработчики с новой энергией выдают новую порцию оптимистических прогнозов. Программное обеспечение подвергается наибольшим переделкам, наверное потому, что его мало кто понимает. Уменьшить стоимость спутника на часть, которая относится к программному обеспечению, представляется часто наиболее очевидным решением.

Определение требований и проектирование с начала 1950-х годов и до конца 1960-х имело целью помочь программисту. С начала 1970-х годов была поставлена цель облегчить руководство программным обеспечением. Определение требований и проектирование программного обеспечения должно оказывать помощь руководителям системы, особенно в части определения требований и проектирования ее развития.

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

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

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

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

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

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

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