Модели разработки

Содержание:

Введение

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

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

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

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

Кроме книг, указанных в библиографии, основным источником информации для данной курсовой работы является девятое издание книги “Программная Инженерия” (англ. “Software Engineering”) британского академика компьютерных наук и системной инженерии Иана Соммервиля (англ. Ian Sommerville). Книга является популярной среди профессиональных программистов и используется в качестве учебного пособия в ряде зарубежных высших учебных заведений.

Глава 1. Модели разработки

Существует множество разных методологий и процессов создания программного обеспечения, но все они включают в себя 4 базовых этапа:

1. Спецификация - формулировка функциональных требований и эксплуатационных ограничений.
2. Проектирование и разработка - проектирование и создание программного продукта согласно спецификации.
3. Валидация - проверка соответствия продукта требованиям клиента.
4. Эволюция - дальнейшее развитие продукта для удовлетворения меняющихся потребностей клиента.

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

Под процессами или этапами создания программного обеспечения (software processes) мы подразумеваем все действия, напрямую связанные с созданием программного продукта^[1]. Зачастую большинство этих процессов взаимосвязаны, исполняются в определённом порядке, и исход одних процессов зависят от результатов других, вышестоящих процессов. В рамках данной курсовой работы обозначим, что термины процесс и этап создания программного обеспечения тождественны и взаимозаменяемы.

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

На основе вышесказанного процессы разработки программного обеспечения можно условно разделить на две категории: плановая разработка (англ. Plan-driven) и гибкая разработка (англ. Agile). В плановой разработке, как видно из названия, все этапы разработки и связанные с ними процессы предварительно планируются, и прогресс разработки оценивается согласно этому плану. В случае гибкой разработки планирование этапов и процессов инкрементальное, или поэтапное, поэтому есть возможность изменять тот или иной процесс по мере изменения требований клиента. В общем случае необходимо соблюдать баланс между плановой и гибкой разработкой.

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

1. Каскадная модель (Waterfall Model) - в этой парадигме основные этапы разработки, такие как спецификация, разработка, валидация и эволюция представляются в виде отдельных последовательно выполняемых процессов, таких как формулировка требований, разработка архитектуры, разработка программы, тестирование и так далее.
2. Поэтапная разработка (Incremental Development) - в этой модели чередуются этапы спецификации, разработки и валидации. Программный продукт разрабатывается поэтапно, с каждой новой версией добавляя новый функционал.
3. Reuse-oriented software engineering или разработка основанная на повторном использовании программных компонентов. Как видно из названия, эта модель базируется на большом количестве различных программных компонентов, пригодных для повторного использования, вместо разработки новых компонентов с нуля.

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

1.1. Каскадная модель разработки

Каскадная модель разработки впервые была опубликована в 1970 году, и основывалась она на общей модели инженерного проектирования систем^[4]. Из-за последовательной реализации этапов разработки эту модель также называют каскадной моделью (waterfall) или жизненный цикл программы (software lifecycle). Эта модель разработки является примером плановой разработки - в общем случае необходимо предварительно спланировать и назначить сроки исполнения всех этапов разработки.

Основные этапы разработки в каскадной модели напрямую отражают базовые процессы разработки программного обеспечения:

1. Анализ и определение требований - на этом этапе проходит опрос пользователей системы или заказчика, и детально формулируются требования, функциональность, ограничения и цели системы. Результаты анализа в дальнейшем служат техническим заданием.
2. Проектирование программного и аппаратного обеспечения - создается архитектура, которая определяет требования как к аппаратному так и к программному обеспечению всей системы. При проектировании программного обеспечения определяются все основные программные абстракции и их взаимодействие.
3. Реализация и модульное тестирование - на этом этапе проект программного обеспечения реализуется в виде набора программ или программных модулей. Модули и подпрограммы тестируются на предмет соответствия спецификациям.
4. Интеграция и системное тестирование - отдельные модули и подпрограммы интегрируются в единую систему и проводятся тесты всей системы на предмет соответствия изначальным требованиям. После успешного прохождения тестов система поставляется заказчику.
5. Эксплуатация и техническое обслуживание - обычно это самый длинный этап жизни программного обеспечения. Система устанавливается и вводится в эксплуатацию. Техническое обслуживание сводится к устранению не выявленных ранее ошибок, к улучшению и оптимизации реализации и к добавлению нового функционала в соответствии с новыми требованиями заказчика.

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

(Рис 1.)

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

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

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

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

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

Формальные процессы разработки, например, основанные на методе B^[5][6], очень хорошо подходят для разработки систем, к которым предъявляют строгие требования к безопасности, надежности или безопасности. Формальный подход позволяет продемонстрировать клиентам или регулирующим органам, что система фактически соответствует ее требованиям безопасности

1.2. Модель поэтапной разработки

Основная идея поэтапной разработки (англ. incremental development) заключается в реализации базового функционала, которая передается заказчику на тестирование. Получив комментарии заказчика о результатах тестирования, исполнитель начинает дальнейшую доработку текущей реализации и внедрение нового функционала. Эта последовательность действий выполняется в несколько итераций до тех пор, пока в итоге разработки не получится система, удовлетворяющая всем требованиям^[7]. (см. Рис. 2)

(Рис. 2)

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

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

По сравнению с каскадной моделью разработки, у поэтапной модели есть три важных преимущества:

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

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

С точки зрения менеджмента у поэтапной разработки имеются два недостатка:

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

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

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

1.3. Разработка основанная на повторном использовании программных компонентов

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

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

(Рис. 3)

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

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

Есть три вида программных компонентов, которые могут быть использованы в этой модели разработки:

1. Веб сервисы, разработанные в соответствии с стандартом, и которые могут быть вызваны удаленно.
2. Наборы или коллекции объектов, разработанные в виде пакетов и предназначенные для интеграции с компонентной средой, таких как .NET и J2EE.
3. Автономные программные системы, настроенные для использования в конкретной среде.

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

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

Глава 2. Этапы создания программного обеспечения

На практике процессы или этапы создания программного обеспечения

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

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

2.1. Спецификация

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

Разработка требований к программному обеспечению сводится к четырем основным процессам:

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

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

2.2. Проектирование и разработка программного обеспечения

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

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

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

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

Рассмотрим четыре этапа, которые могут быть чатьсю процесса проектирования информационных систем:

1. Проектирование архитектуры - этап, в котором вы определяете общую структуру системы, основные компоненты (иногда называемые подсистемами или модулями), их взаимосвязи и способы их распределения.
2. Проектирование интерфейса - на этом этапе определяются интерфейсы между различными компонентами системы. Спецификация интерфейсов должна быть предельно четкой и однозначной, для того, чтобы при реализации одного компонента не требовалось разбираться в внутреннем устройстве других компонентов. После согласования спецификаций интерфейсов различные компоненты системы могут проектироваться и разрабатываться одновременно.
3. Проектирование компонентов - на этом этапе вы проектируете то, как будет работать каждый отдельный компонент системы. Результатом этого этапа может быть просто список функциональных требований к компоненту, а конкретную реализацию вы можете оставить прикладному программисту. В случае, если используется модель повторного использования программных компонентов, это может быть списком необходимых изменений в повторно используемый компонент. Если имеется необходимый инструментарий, результатом этого этапа также может быть и детальная модель компонента, которая будет использована при автоматической генерации конкретной реализации компонента.
4. Проектирование базы данных - на этом этапе проектируется структура данных, обрабатываемых системой и их представление в базе данных. Опять же, работа здесь зависит от того, будет ли использоваться существующая база данных или будет создана новая база данных.

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

Структурированные методы проектирования были разработаны в 1970-х и 1980-х годах и были предшественниками UML и объектно-ориентированного проектирования^[8]. Они полагаются на создание графических моделей системы и, во многих случаях, на автоматическую генерацию кода из этих моделей. Модельно-ориентированная разработка (MDD) или модельно-ориентированная разработка^[9], где модели программного обеспечения создаются на разных уровнях абстракции, является эволюцией структурированных методов. В MDD больше внимания уделяется архитектурным моделям с разделением между абстрактными независимыми от реализации моделями и моделями, специфичными для реализации. Модели разработаны достаточно подробно, чтобы из них можно было создать исполняемую систему

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

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

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

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

2.3. Валидация

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

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

Процесс тестирования состоит из следующих этапов:

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

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

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

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

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

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

2.4. Эволюция, или дальнейшее развитие

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

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

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

Для уменьшения дополнительных затрат на внесение изменений, используются два взаимосвязанных подхода:

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

Здесь мы кратко рассмотрим рассмотрим следующие два подхода уменьшения стоимости внесения масштабных изменений в программный проект:

1. Прототипирование системы^[10] - это быстрая разработка демонстрационной версии системы или ее части, предназначенной для проверки требований заказчика и осуществимость некоторых проектных решений. Заказчик экспериментирует с прототипом, и при необходимости вносит изменения в требования к системе. Таким образом, мы избегаем значительных изменений в будущем, поскольку требования меняются до начала масштабных работ по разработке программы.
2. Поэтапная доставка - процесс поэтапной разработки, когда каждая новая итерация, или версия программы, доставляется заказчику на тестирование, после чего заказчик, при необходимости, вносит изменения в ту или иную часть системных требований. Это позволяет избежать преждевременной реализации системных требований и позволяет вносить изменения в последующих итерациях при относительно низких затратах.

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

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

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

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

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

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

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

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

1. В некоторых случаях может быть невозможно настроить прототип для удовлетворения нефункциональных требований, таких как требования к производительности, безопасности и надежности, которые были проигнорированы при разработке прототипа.
2. Резкие изменения в процессе разработки неизбежно означают, что прототип не документирован. Единственной спецификацией является код прототипа. Этого недостаточно для долгосрочного обслуживания.
3. Изменения, внесенные в ходе разработки прототипа, вероятно, скажутся негативно на структуре системы. Система будет сложной и дорогой в обслуживании.
4. Стандарты качества обычно не соблюдаются строго при разработке прототипа.

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

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

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

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

Поэтапная доставка имеет ряд преимуществ:

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

Тем не менее, есть у поэтапной доставки и недостатки:

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

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

Заключение

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

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

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

Библиография

Sommerville I. Software Engineering 9th Edition. N.Y.: Addison-Wesley, 2011.

Arlow, J. and Neustadt, I. UML2 and the Unified Process: Practical Object-Oriented Analysis and Design (Second Edition). Addison-Wesley, 2005.

Boehm, B. and Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, 2003.

Budgen, D. Software Design (Second Edition). Addison-Wesley, 2003.

Rettig, M. ‘Practical Programmer: Prototyping for Tiny Fingers’. Comm. ACM, 37 (4), 1994.

Royce, W. W. ‘Managing the Development of Large Software Systems: Concepts and Techniques’. IEEE WESTCON, L.A.: 1970. C 1–9.

Schmidt, D. C. ‘Model-Driven Engineering’. IEEE Computer, 39 (2), 2006. C 25–31.

Schneider, S. The B Method. Houndmills, UK, Palgrave Macmillan.: 2001.

Wordsworth, J. Software Engineering with B. Wokingham: Addison-Wesley: 2001.

1. Sommerville I. Software Engineering 9th Edition. N.Y.: Addison-Wesley, 2011 - C. 9. ↑

2. Boehm, B. and Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, 2003. ↑

3. Sommerville I. Software Engineering 9th Edition. N.Y.: Addison-Wesley, 2011. С - 29 ↑

4. Royce, W. W. Managing the Development of Large Software Systems: Concepts and Techniques. - 1970. - C.1-9. ↑

5. Wordsworth, J. Software Engineering with B. Wokingham: Addison-Wesley: 2001. ↑

6. Schneider, S. The B Method. Houndmills, UK, Palgrave Macmillan.: 2001. ↑

7. Sommerville I. Software Engineering 9th Edition. N.Y.: Addison-Wesley, 2011 - C. 33 ↑

8. Budgen, D. Software Design (Second Edition). Addison-Wesley, 2003. ↑

9. Schmidt, D. C. ‘Model-Driven Engineering’. IEEE Computer, 39 (2), 2006. C 25–31. ↑

10. С.44 ↑

11. Rettig, M. Practical Programmer: Prototyping for Tiny Fingers. Comm. ACM, 37 (4), 1994. ↑