Файл: Учебное пособие по курсу Технология разработки программного обеспечения для студентов.doc

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

• 
  Технологический процесс разработки ПО, применяемые в нем методы и средства.
  
• 
  Изучение методов управления проектами при разработке ПО.
  

---

2Жизненный цикл ПО. Модели жизненного цикла

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ).

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

Принято выделять следующие этапы ЖЦ ПО:

• 
  анализ требований;
  
• 
  проектирование;
  
• 
  кодирование;
  
• 
  тестирование и отладка;
  
• 
  эксплуатация и сопровождение;
  
• 
  вывод из эксплуатации и замена.
  

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

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

Модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. Наибольшее распространение получили следующие модели:

Каскадная модель ЖЦ ПО (1970-1980 гг.) – предполагает переход к следующему этапу после полного завершения предыдущего (рис.1).

Поэтапная модель с промежуточным контролем (1980-1985 гг.) – итерационная модель разработки ПО с циклами обратной связи между этапами (рис. 2). Преимущество модели – уменьшение трудоемкости благодаря межэтапным корректировкам. Недостаток – отсутствие четко выделенных этапов разработки, растягивание их на весь ЖЦ.

Спиральная модель (1986–1990 гг.) – упор делается на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проводится проверка и обоснование реализуемости технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, уточняются цели и параметры проекта и в результате выбирается обоснованный вариант, который доводится до реализации (рис. 3).

---

Преимущества модели:

• 
  Накопление и повторное использование программных средств, моделей и прототипов.
  
• 
  Ориентация на развитие и модификацию ПО в процессе проектирования.
  
• 
  Анализ риска и издержек в процессе проектирования.
  

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

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

1. 
   Каскадная модель жизненного цикла программного обеспечения.
   

2. 
   Поэтапная модель жизненного цикла программного обеспечения
   

3. 
   Спиральная модель жизненного цикла программного обеспечения
   

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

Список требований к разрабатываемой системе должен включать:

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

---

Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:

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

Этап проектирования дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе.

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

Обычно этот этап разделяют на два подэтапа:

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

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

Кодирование. На этом этапе должны быть получены следующие результаты:

1. 
   Верифицированная детальная спецификация каждого блока:
   

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

---

Одобренный план приемных испытаний.

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

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

Проверка всех вариантов ввода и вывода, включая сообщения об ошибках.

Выполнение всех операторов и всех ветвей передачи управления.

Проверка выполнения стандартов разработки.

Завершение помодульного документирования внутренней структуры.

Эксплуатация и сопровождение. Содержание данного этапа следующее:

1. 
   Проверка удовлетворения приемных испытаний системы.
   
2. 
   Проверка удовлетворения системных требований.
   
3. 
   Проверка производственной готовности, аппаратуры, средств обслуживания и персонала.
   
4. 
   Завершение всех специфицированных работ и ввод системы в действие.
   

Вывод из эксплуатации и замена. На данном этапе решаются следующие задачи:

1. 
   Выбор новой системы.
   
2. 
   Миграция данных в новую систему.
   
3. 
   Очистка системы от старого ПО.
   
4. 
   Утилизация материальных носителей (диски, документация и т.п.).
   
5. 
   Документирование вывода и замены ПО.
   

---