Программное обеспечение и его разработка
Шрифт:
Строительство моста является результатом работы множества коллективов. Без организационной деятельности по управлению этими коллективами большой мост построить нельзя. Управление распределяет фонды, планирует, проектирует, нанимает, платит, строит графики работ, выдает директивы.
Аналогичное положение имеет место и при разработке программного обеспечения, особенно при разработке крупномасштабного обеспечения. Руководство должно осуществлять все те же самые функции; исполнителями большей частью являются программисты, те, которые пишут команды. Перед руководством стоит двойная задача: ему надо не только воздействовать на увеличение отдачи от программистов, но также объединять результаты их труда в единое целое. Эта вторая часть сильно зависит от результатов проектирования, за которым она следует, и от методов, которые применяются при соединении частей системы. Именно это объединение составных частей мы и называем компоновкой.
На рис. 5.46 представлена роль автоматических средств обеспечения разработок, сильно возросшая в 1970-е гг., а также роль аналогичных работ, проводимых вручную, которая все это время неудержимо ослабевала. Этот процесс происходит только при хорошей организации работ по созданию программного обеспечения.
Тестирование позволяет нам определить состояние того, что уже сделано, и показывает, на какое место надо обратить внимание и куда внести исправления. Верификация, прежде всего, призвана помочь нам избежать ошибок. Ошибки могут быть самыми разными — от неправильно закодированных операторов, которые могут приводить к остановке всей системы, и до чего-нибудь совершенно тривиального вроде ошибок при разбиении печатного текста на столбцы, из-за которых распечатка выглядит не так красиво, а ничто больше не затрагивается. Ошибки могут возникать из-за неправильной формулировки требований, неправильно проведенного проектирования, неправильного кодирования. В программах могут быть пропуски, или же туда может попасть лишнее. Причиной ошибок могут быть недоразумения, неоднозначные толкования, недоговоренности или путаница.
Верификация — это новый термин, он стал применяться около 5 лет назад. Обозначает он процесс проверки требований и проекта после того, как они документированы, а также разных частей программы по мере их появления. До того как возникла идея проводить верификацию, весь процесс выяснения того, отвечает ли программа сформулированным требованиям, откладывался до самого конца, до тестирования системы. Верификация передвинула процесс проверки ближе к началу, и ошибки и оплошности стали вылавливаться раньше, что дало возможность программистам избежать реализации неправильно сформулированных требований. Тестирование же обычно заключается в выполнении уже завершенных программ, чтобы убедиться, что они отвечают поставленным требованиям. Верификация выполняется с помощью инспекторских проверок или сквозного контроля. Коллеги, руководители, посторонние программисты, пользователи, если это возможно, собираются и просматривают результаты работы группы по определению требований (либо группы проектировщиков), пытаясь обнаружить в них пробелы, ошибки, неоднозначные высказывания и т. д. С каждым годом проведение верификации облегчается, поскольку методы формулирования требований и проектных решений становятся более четкими и легкими.
Сама идея тестирования предполагает некий «конечный продукт», который теперь надо протестировать и убедиться, что он работоспособен. Мы можем проверить, как работает автомобиль только после того, как этот автомобиль изготовлен.
Но очень хорошо известно, что если можно проверить отдельные части автомобиля еще до сборки, то машина более высокого качества будет получена с меньшими затратами. Своевременное выявление ошибок избавляет от них конечную продукцию или программу. Как же мы проверяем не готовую еще, не материальную
Тестирование есть деятельность, целью которой является установление того, что завершенная программа делает то, что ей надо делать. Лучшим тестированием любой системы является ее эксплуатация. В особенности это относится к системам реального времени. Однако слишком дорого обходятся ошибки и промахи, найденные слишком поздно. Мы желаем находить ошибки как можно раньше.
Вот в чем заключается деятельность группы тестирования:
понимании функций, которые должны выполняться системой,
обнаружении узких мест системы — временных ограничений и неустойчивости, вызванной входными параметрами, проектировании серии упражнений, приводящих систему в действие,
определении в тестирующей системе как аппаратных, так и программных компонент, построении тестирующей системы,
планировании фактического проведения тестирования и дирижирования им.
Для всего этого требуется и изобретательность, и широкие познания.
Тестирование есть сопоставление результатов разработки с процессом с целью выяснения, действительно ли разработанный процесс выполняет то, что предполагалось. Хотя речь о тестировании и верификации зашла в этой книге только сейчас, после разговора о компоновке, это связано лишь с необходимостью вести последовательное изложение. На практике правильнее будет провести большую часть действий по тестированию и верификации еще до компоновки. Мы включаем в систему тестирования все части программного обеспечения, по мере того как отдельные программисты и целые группы, работающие над нижними уровнями, объявляют об окончании своей деятельности.
Полезно будет еще раз взглянуть на рис. 5.7, иллюстрирующий процесс разработки. Заметим, что верификация и тестирование появляются уже на самых ранних стадиях проекта.
Часть усилий при проектировании следует направлять на то, чтобы сделать программное обеспечение легко тестируемым.
Принятие методов структурного программирования привело к тому, что программы стали читаемыми. Сложившееся положение являет собой разительный контраст с прежними временами, когда неструктурированные программы больше напоминали бетонные монолиты или мешанину из спагетти.
Структурированные программы делятся на абзацы, при их написании следуют строгим правилам, в них включаются специальные примечания. Если к тому же размеры модулей невелики, не больше 30–50 операторов на модуль, мы получаем очень хорошо читаемые программы. Прекрасным способом проведения проверок на протяжении всего процесса разработки является инспектирование программ, называемое сквозным контролем.
Несколько коллег, а возможно, и руководителей, знакомых с проектом и применяемой терминологией, садятся рядом с автором программы, который показывает им все, что он написал, и описывает все, что он сделал: алгоритм своей программы, оператор за оператором, результаты всех тестов и т. д. Это новый метод; он стал возможен благодаря применению структурного программирования.
Если подобные инспекции проводятся регулярно, то в течение всего запланированного времени можно избежать любых, самых неприятных сюрпризов. Руководство становится более наглядным и простым.
Преимущества этого метода велики. Свежий взгляд позволяет избежать положения, когда «из-за деревьев не видно леса». Появились новые подходы и предостережения, позволяющие избегать ошибок.
Важным фактором становится «рабочая гордость», так как теперь видны не только результаты работы программы, но и каждая команда программы. Многие программисты сообщают, что там, где раньше они позволяли себе проявлять беспечность и небрежность при программировании (хотя никто из них этого раньше не замечал), теперь изо всех сил стараются делать все наилучшим образом. Повышенная аккуратность в работе приводит к повышению качества программ.