Читать онлайн «Программное обеспечение и его разработка». Страница 39

Подсистемы обработки данных (ОД) состоят из вычислительных машин и программного обеспечения. Программное обеспечение должно «соответствовать» аппаратуре, оно должно быть спроектировано так, чтобы увеличивать производительность как этой аппаратуры, так и всей системы в целом.

Звучит это просто; однако чаще всего ответственный за аппаратуру ОД мало знает о программном обеспечении, он выбирает машину, только исходя из ее стоимости и скорости работы. Разработка программного обеспечения игнорируется. Я видел, как подобные ошибки допускают даже в тех случаях, когда всеми признавалось, что разработка программного обеспечения будет ключевой во всей схеме разработки системы.

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

Существуют десятки и даже сотни методов, которые позволяют производить проектирование параллельно. Иллюстрации этого утверждения приведены на рис. 5.11 — 5.17.

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

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

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

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

И конечно, каждая из этих подсистем тоже может подразделяться. Чтобы изобразить «окончательное» разбиение на отдельные части, нам нужно построить целое «дерево» проектирования, что и сделано на рис. 5.17.

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

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

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

Итерации при проектировании идут постоянно. По самому своему характеру работа проектировщика полна сюрпризов. Если бы он мог представить себе весь ход работ в деталях, то это значит, что у него имеется не готовый проект, а лишь иллюстрация к нему. Итерации случаются на всех уровнях, даже на уровне микропроектирования. События и открытия, приводящие к изменениям, не обязательно должны подчиняться общей иерархии, некоторые могут влиять на последующие стадии, а некоторые на стадии, проходящие параллельно. Схема февральских работ показывает, что одновременно происходит детализация и определение четырех различных процессов, значит, эти процессы не существует независимо друг от друга, они чаще всего взаимодействуют между собой Эти взаимодействия нужно исследовать, детализировать и иногда специально проектировать Взаимодействия и детали одной или нескольких работ или функций, возможно, придется видоизменить в соответствии с тем, как проектировщик решил выполнять некоторую другую работу. Может случиться, что после определения работы Ф, нам придется модифицировать П.

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

Из всего сказанного можно логически вывести такое заключение: утверждение «проектирование завершено на 90 %» — это не факт, а лишь его оценка, поскольку никто в точности не знает, не встретится ли нам какой-нибудь сюрприз, который заставит нас вернуться несколько назад и начать переделку проекта, который мы считали завершенным.