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

В противоположность предыдущему примеру со строительством второго уровня рассмотрим пример строительства моста-близнеца рядом со старым мостом! Посмотрите, какой мост построен через залив Чезапик. (См. рис. 4.22.)

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

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

При разработке больших систем типа V единственной по-настоящему важной проблемой является отсутствие ясных требований. Руководитель проекта не может понять, что ему делать.

Таблица 4.11 Какие требования могут меняться

Продукция Структура рынка Размах производства Разделение труда Заводы, их расположение Заказчики Организация Налоговое законодательство Ведущие специалисты Законы охраны собственности Число заводов Обмен продукцией между заводами Сети Аппаратура Процедуры Следовательно, прикладные программы Необходимые данные Следовательно, база данных

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

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

Резюме

Масштаб, сложность и ясность нужно принимать во внимание и планировать с самого начала работ. Построение системы в миллион команд — это такой же триумф, как и постройка моста, часто стоимости этих объектов тоже сравнимы. Однако программное обеспечение невидимо. Никто не видит его; только некоторые посвященные могут его оценить. В некотором смысле такое положение не очень-то радует. Когда создается что-нибудь достаточно сложное, хотелось бы, чтобы плоды труда были видны. Даже сама работа программы это как бы «верхняя часть айсберга». Нет никакого способа показать огромную сложность и достигнутые результаты. Только в процессе изучения и создания можно оценить сложность и масштаб подобных работ.

Программное обеспечение проекта и программное обеспечение как продукция

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

1. Пакеты программного обеспечения Программное обеспечение, которое может использоваться на любой вычислительной машине, например транслятор с Кобола 2. Системы с программным обеспечением различных компонент Получающиеся в результате системы, например системы обработки слов отличаются друг от друга именно своим программным обеспечением 3. Аппаратные комплексы с минимальными программными включениями Продукция с минимумом программного обеспечения, например копировальная установка, использующая ЭВМ для управления операциями Продукция и проекты

В разработке обеспечения как продукции есть два пункта (см. также табл. 4.12), отличающих ее от разработки программного обеспечения проектов:

1) процесс определения требований;

2) широта усилий в смысле разнообразия разрабатываемых функций.

Таблица 4.12. Различия между программным обеспечением проекта и продукцией

Продукция Проект Число пользователей Сотни Один или несколько Конкуренция После начала использования Только за право вести разработку Продолжающаяся разработка Критична Не так критична Контроль при использовании Очень Незначительный Весьма важен

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

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

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

Проще всего убедиться в полезности введения такой классификации, рассмотрев крайние случаи тех и других программ, не вдаваясь в сближающие их детали. У системы «Аполлон», т. е. проекта космических исследований и полета на Луну, был всего один пользователь, при этом этот пользователь жил и работал бок о бок с разработчиком. Между ними был установлен и поддерживался тесный и эффективный канал связи. В противоположность этому обобщенный пакет составления платежных ведомостей предназначен сразу сотням пользователей, большинство из которых никогда не разговаривали и не виделись с разработчиками. Кроме того, разработчики других подобных пакетов предлагают этим потенциальным пользователям свою продукцию. Главным вопросом здесь, следовательно, является не вопрос пригодности нашей программы, а вопрос ее конкурентоспособности. Это различие является определяющим, от него зависят и удачи, и неуспех.

В табл. 4.13 представлены некоторые примеры из сферы программного обеспечения. Там есть и товарные программы, и программные проекты, там же можно найти сведения о продукции, в которой программное обеспечение является только частью общей системы. Внимательное изучение схемы не раз приводило к удивительным результатам: разработчики считали, что они заняты созданием какой-нибудь системы, а потом оказывалось, что они неправильно оценивали, точнее, неправильно понимали, какие усилия нужны будут для завершения их работ.