3.1.5. Последовательность выполнения процессов разработки программного обеспечения

Большинство процессов разработки программного обеспечения – это процессы решения некоторых задач. Внешнее проектирование сводится к решению такой задачи: переведите множество целей системы во внешние спецификации. В задаче проектирования логики модуля даны внешние спецификации модуля, а на выход должен быть получен текст его про­граммы. Отладка – это задача на определение места ошибки и ее исправле­ния по описанию ее симптомов. Полностью процесс проектирования ПО будет представлен на рис. 3.2.

Решение задачи состоит из следующего ряда шагов.

Формулировка задачи. Прежде всего, проектировщик должен де­тально разобраться, в чем именно состоит задача очередного процесса. Худшая из ошибок, которые могут быть сделаны при решении задачи, – не вполне разобраться в ее постановке. Исследуя задачу, проектировщик должен также исследовать данные, чтобы убедиться, что их достаточно для решения задачи и они не противоречат друг другу.

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

Прежде всего, в плане нужно определить, чего вы хотите добиться. Десять человек могут иметь десять разных мнений относительно «пра­вильного» ответа на задачу проектирования; проектировщик должен пре­дусмотреть те конкретные аспекты решения, которые требуют наиболь­шего внимания. К сожалению, в большинстве проектов разработчики имеют слишком много свободы в этом отношении: каждый разработчик принимает компромиссные решения, основываясь на своем собственном мнении, что приводит к несогласованности многих решений в системе. Решением этой проблемы является идея целей проекта. Суть идеи состоит в том, что на уровне всего проекта определяются общие цели, которыми следует руководствоваться во всех решениях при проектировании.

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

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

3.1.6. Сравнение надежности аппаратуры и программного обеспечения

Для лучшего понимания надежности программного обеспечения стоит сравнить ее с надежностью аппаратуры (подразд. 2.1.3). Возможны три причины отказа аппаратуры некоторого устройства: ошибка проекти­рования, производственный дефект и износ. Изменение интенсивности от­казов аппаратуры (λ) в процессе эксплуатации графически можно предста­вить соответствующей кривой на рис. 3.1.

Надежность программного обеспечения существенно отличается от надежности аппаратуры. Программы не изнашиваются, поломка про­граммы невозможна. Более того, производственные дефекты (такие, как копирование системы для переноса ее на другой компьютер) не имеют особого значения, так как они сравнительно редки и быстро обнаружива­ются. Таким образом, ненадежность программного обеспечения системы – следствие исключительно ошибок проектирования, т.е. ошибок, внесенных в процессе разработки. В условиях, когда ошибки исправляются тотчас же, как только они обнаруживаются, изменение интенсивности отказов про­граммного обеспечения соответствует кривой «программного обеспече­ния» на рис. 3.1. Подчеркнем, что эта кривая отражает предположение, что при исправлении ошибок не вносятся новые. Это предположение обычно не справедливо.

Рис. 3.1. Различие между надежностью аппаратуры и программного обеcпечения

Сравнение кривых (см. рис. 3.1) показывает, что интенсивность отка­зов программного обеспечения и интенсивность отказов аппаратуры изме­няются по-разному. Надежность аппаратуры определяется случайными от­казами, надежность программного обеспечения – скрытыми в нем ошиб­ками, природа которых не является случайной.