Технология разработки программного обеспечения

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

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

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

Мы можем ожидать продолжения роста значения программной инженерии по целому ряду причин. Во-первых, мировые расходы на программное обеспечение выросли со 140 млрд долларов в 1985 г. до 800 млрд в 2000-м. Уже один этот факт гарантирует, что программная инженерия будет расти как отдельная отрасль компьютерных знаний. Во-вторых, программное обеспечение проникает в наше общество: все больше программ используется для управления важнейшими функциями самых разных машин, таких как самолеты и медицинские приборы, а также для поддержки глобальных процессов, подобных электронной коммерции. Этот факт гарантирует возрастающий интерес общества к надежному программному обеспечению, к расширению законодательной основы для соответствующих стандартов, требований и процедур сертификации. Нет сомнения, что останется важным и обучение тому, как наилучшим образом делать еще более совершенное программное обеспечение.

1.3. Роль программного инженера

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

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

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

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

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

1.4. Жизненный цикл программного обеспечения

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

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

1. Анализ и спецификация требований. Анализ требований — это обычно первый этап разработки крупномасштабного программного проекта. Его предпринимают после того, как выполнен анализ осуществимости проекта, точно определяющий затраты и экономический эффект программной системы. Назначение этого этапа — сформулировать и документировать четкие требования к системе. Такое исследование может быть выполнено заказчиком, разработчиком, маркетинговой фирмой или любой комбинацией из трех перечисленных. В тех случаях, когда требования не вполне ясны (например таких систем прежде не делали), взаимодействие между заказчиком и исполнителем должно быть заметно усилено. Требования на этой стадии должны быть сформулированы на языке заказчика, хотя это бывает нечасто. Различные методики разработки программных систем рекомендуют, чтобы на этой стадии также разрабатывались руководства пользователя и даже планы тестирования системы, выполняемого в самом конце, перед поставкой системы заказчику.
2. Проектирование системы с учетом спецификации. Как только требования к системе документированы, программные инженеры проектируют программную систему, которая бы отвечала этим требованиям. Этот этап иногда разбивают на два: архитектурное или высокоуровневое проектирование и рабочее проектирование. Архитектурное проектирование определяет общую организацию системы в терминах компонентов высокого уровня и взаимодействий между ними. По мере углубления в растущую детализацию уровней проектирования компоненты распадаются на модули нижнего уровня с точно определенными интерфейсами. Все уровни проектирования отражаются в технической документации, которая отслеживает проектные решения.

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

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

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

Рис 1. Каскадная модель жизненного цикла программного обеспечения

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

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

Вопросы для самоконтроля к главе 1:

1. Дайте определение инженерии программного обеспечения (ПО).
2. Объясните причины возникновения такой дисциплины как инженерия ПО.
3. Поясните роль инженерии ПО в проектировании систем.
4. Расскажите краткую историю инженерии ПО.
5. В чем заключается роль программного инженера?
6. Из каких стадий состоит жизненный цикл ПО?
7. Какие модели жизненного цикла вы знаете?
8. В чем состоит важность моделей процесса создания ПО?

2. Процесс производства программного обеспечения

2.1. Понятие модели процесса создания ПО

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

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

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

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

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