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

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

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