Файл: Модели разработки.pdf

Введение

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

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

Поэтому, следуя за требованиями рынка, с начала 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) и больше подходит для разработки систем, ориентированных на бизнес, онлайн торговлю и персональные систем нежели каскадная модель. Поэтапная разработка отражает то, как мы решаем поставленную задачу. В большинстве случаев, мы не планируем заранее полное решение задачи, а движемся в направлении решения небольшими шагами, постепенно приближаясь к нему и возвращаясь всякий раз, когда понимаем, что совершили ошибку на каком-либо этапе. Таким образом, в случае необходимости мы можем легко и дешево вносить изменения в программное обеспечение в процессе разработки.

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