Практическая работа №1

Тема: Практическое применение жизненного цикла разработки программного обеспечения

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

Теоритическая часть

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

Жизненный цикл (ЖЦ) информационной системы – непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент её полного изъятия из эксплуатации.

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

Наиболее общим представлением жизненного цикла ПО является модель в виде базовых этапов – процессов, к которым относятся:

1. 
   – рисунок. Жизненный цикл разработки ПО.
   

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

В дальнейшем, рассматривая различные модели ЖЦ, для простоты будем использовать следующий набор этапов:

1. Анализ (разработка требований).

2. Проектирование (создание проекта).

3. Реализация (программирование).

4. Тестирование (исправление ошибок).

5. Внедрение (ввод в эксплуатацию).

К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ:

---

• 
  Каскадная (waterfall). Простая в реализации, подходит для коротких проектов с нулевым риском и фиксированными требованиями.
  
• 
  V-образная. Базируется на каскадной. Эта модель SDLC подразумевает контроль качества на каждом из этапов. Подходит для проектов, для которых ошибки могут иметь фатальные последствия, когда критически важна точность выполнения требований.
  
• 
  Модель эволюционного прототипирования. Опять же, в основе – waterfall. При прохождении каждого этапа сразу же происходят необходимые доработки проекта на основе отзывов клиента (заказчика). Создается несколько прототипов, один из которых в итоге дорабатывается и отправляется в продакшн.
  
• 
  Итеративная и инкрементальная. Решение разрабатывается модулями при реализации серии циклов. А при работе над каждым модулем используется все та же каскадная модель.
  
• 
  Спиральная. Включает в себя черты предыдущих. Используется для сложных, крупных проектов с частыми релизами, подходит для ПО с неясными требованиями.
  
• 
  Гибкие методологии. Их более 50. И многие, опять же, могут включать черты рассмотренных выше.
  

Начиная с этапа разработки SDLC для тестирования приложения безопасность обеспечивается с помощью:

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

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

Этап 1: планирование и анализ потребностей

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

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

---

, которые можно использовать для успешной реализации проекта с минимальными рисками.

Этап 2: определение требований

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

Этап 3: проектирование архитектуры продукта

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

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

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

Этап 4: Создание или разработка продукта

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

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

Этап 5: Тестирование продукта

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

---

исправляются и повторно тестируются до тех пор, пока продукт не достигнет стандартов качества, определенных в SRS.

Этап 6: развертывание на рынке и сопровождение

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

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

Практическая часть

Модель водопада – Применение

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

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

Требования очень хорошо задокументированы, понятны и зафиксированы.

Определение продукта является стабильным.

Технология понятна и не динамична.

Здесь нет двусмысленных требований.

Достаточные ресурсы с необходимым опытом доступны для поддержки продукта.

Проект короткий.

Итерационная модель – приложение

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

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

---

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

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

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

Применение спиральной модели

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

Следующие указатели объясняют типичное использование спиральной модели

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

При наличии бюджетных ограничений важна оценка рисков.

Для проектов со средней и высокой степенью риска.

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

Клиент не уверен в своих требованиях, как правило, так.

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

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

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

V- Модель ─ Применение

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

Следующие указатели являются одними из наиболее подходящих сценариев для использования приложения V-Model.

---

Смотрите также файлы

• В томске состоится молодежный кросскультурный Форум! 21 и 22 апреля 2017 года в Томске состоится молодежный кросскультурный Форум с международным участием Этнокультурная мозаика.doc

• Анализ предметной области различными методами.docx

• Занятие 3 Методы проведения организационных изменений.docx

• Лабораторной работы по дисциплине информационные технологии в психологии.docx

• Занятие 1 Задание Используя литературу, составьте таблицу Зарождение эксперимента в отечественной психологии.docx