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

В современной ситуации программное обеспечение разрабатывается не для личного использования, а для людей, мало разбирающихся в компьютерной технике. Иногда ПО разрабатывается по специальным заказам клиентов; постепенно набирает темп разработка так называемого коробочного ПО (shrink-wrapped software) для общего (потребительского) рынка; ПО может встраиваться в другие потребительские продукты. Все три перечисленные ситуации добавляют программным продуктам новые характеристики, не существовавшие в прежние времена. Теперь программное обеспечение является обычным продуктом, который необходимо поставить на рынок, продать и установить на разных компьютерах в разных областях народного хозяйства. Пользователям необходимо обучаться работе с ним и получать помощь при возникновении каких-либо нештатных ситуаций.

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

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

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

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

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

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

Как уже упоминалось, что несостоятельность модели кодирования и исправления привела к осознанию так называемого кризиса программирования и, в свою очередь, к появлению учебного предмета, названного инженерией программного обеспечения. В частности, понимание того, что процессу производства ПО остро не хватало методики, привело к появлению концепции жизненного цикла программного обеспечения и структурных моделей для его точного описания, чтобы сделать процесс предсказуемым и управляемым. Боэм (Воепт) [1988] утверждает, что целями структурных моделей процесса являются следующие. Определение порядка этапов, вовлеченных в разработку и развитие программного обеспечения, а также установление критериев перехода от одного этапа к другому. В их число входят критерии завершения текущего этапа, критерии выбора и критерии входа в новый этап. Таким образом, модель процесса призвана дать ответы на следующие вопросы:

• "Что делать дальше?"
• "Как долго продолжать это делать?"

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

2.2. Важность моделей процесса создания ПО

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

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

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

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

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

Рис 2. Прозрачный процесс

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

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

2.3. Основные этапы создания программного обеспечения

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

2.3.1. Анализ осуществимости

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

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

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