СДЕЛАЙТЕ СВОИ УРОКИ ЕЩЁ ЭФФЕКТИВНЕЕ, А ЖИЗНЬ СВОБОДНЕЕ

Благодаря готовым учебным материалам для работы в классе и дистанционно

Скидки до 50 % на комплекты
только до 12.07.2025

Готовые ключевые этапы урока всегда будут у вас под рукой

Организационный момент

Проверка знаний

Объяснение материала

Закрепление изученного

Итоги урока

Модели жизненного цикла программного обеспечения

Категория: Информатика

Нажмите, чтобы узнать подробности

Данный методический материал предназначен для подготовки и проведения уроков при изучении дисциплины "МДК.04.01. Моделирование и анализ программного обеспечения" специальности 09.02.03 "Программирование в компьютерных системах" СПО углубленной подготовки.

Просмотр содержимого документа
«Модели жизненного цикла программного обеспечения»

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

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

Модели жизненного цикла  На протяжении последних тридцати лет в программировании сменились три модели жизненного цикла программного обеспечения; каскадная, модель с промежуточным контролем и спиральная.   Каскадная модель  Первоначально (1970-1985 годы) была предложена и использовалась каскадная модель разработки программного обеспечения, которая предполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все

Модели жизненного цикла

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

Каскадная модель

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

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

Достоинствами такой модели являются:

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

• простота планирования процесса разработки.

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

Каскадная модель разработки программного обеспечения

Каскадная модель разработки программного обеспечения

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

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

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

• изменение требований заказчика непосредственно в процессе разработки;

• быстрое моральное устаревание используемых технических и программных средств;

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

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

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

Модель с промежуточным контролем

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

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

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

Модель разработки программного обеспечения с промежуточным контролем

Модель разработки программного обеспечения с промежуточным контролем

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

Спиральная модель

Для преодоления перечисленных проблем в середине 80-х годов XX в, была предложена спиральная модель.

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

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

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

На первой итерации проектируют, реализуют и тестируют интерфейс пользователя.

На второй - добавляют некоторый ограниченный набор функций.

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

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

  • сократить время до появления первых версий программного продукта;

• заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;

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

• уменьшить вероятность морального устаревания системы за время разработки.

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

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

Изменение жизненного цикла программного обеспечения при использовании CASE- технологий

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

В основе любой CASE-технологии лежит парадигма методология/метод/нотация/средство .

Методология строится на базе некоторого подхода и определяет шаги работы, их последовательность, а также правила распределения и назначения методов.

Метод определяет способ достижения той или иной цели - выполнение шага работы.

 Нотацией называют систему обозначений, используемых для описания некоторого класса моделей.  Нотации бывают графические (предоставление моделей в виде графов, диаграмм, таблиц, схем и т. п.) и текстовые (описания моделей на формальных и естественных языках).  В CASE-технологиях нотации используют для описания структуры проектируемой системы, элементов данных, этапов обработки и т. п.  Средства - инструментарий для поддержки методов: средства создания и редактирования графического проекта, организации проекта в виде иерархии уровней абстракции, а также проверки соответствия компонентов разных уровней. Различают: • CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первое поколение CASE-I );

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

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

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

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

CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первое поколение CASE-I );

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

CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки программного обеспечения ( второе поколение CASE-II ).

CASE-I в основном включают средства для поддержки графических моделей, проектирования спецификаций, экранных редакторов и словарей данных.

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

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

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

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

В табл. 1.1 показаны качественные изменения процесса разработки программного обеспечения происходят при переходе к использованию CASE-средств.

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

Ускорение разработки ПО  Современные технологии проектирования, разработки и сопровождения программного обеспечения, должны отвечать следующим требованиям: • поддержка полного жизненного цикла программного обеспечения; • гарантированное достижение целей разработки с заданным качеством и в установленное время; • возможность выполнения крупных проектов в виде подсистем, разрабатываемых группами исполнителей ограниченной численности (3-7 человек) с последующей интеграцией составных частей, и координации ведения общего проекта; • минимальное время получения работоспособной системы;

Ускорение разработки ПО

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

• поддержка полного жизненного цикла программного обеспечения;

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

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

• минимальное время получения работоспособной системы;

• возможность управления конфигурацией проекта, ведения версий проекта и автоматического выпуска проектной документации по каждой версии; • независимость выполняемых проектных решений от средств реализации (СУБД, операционных систем, языков и систем программирования); • поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.  Этим требованиям отвечает технология RAD (Rapid Application Development – Быстрая разработка приложений ). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий разрабатываемого программного обеспечения.

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

• независимость выполняемых проектных решений от средств реализации (СУБД, операционных систем, языков и систем программирования);

• поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.

Этим требованиям отвечает технология RAD (Rapid Application Development – Быстрая разработка приложений ). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий разрабатываемого программного обеспечения.

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

Она предусматривает выполнение следующих условий:

• ведение разработки небольшими группами разработчиков (3-7 человек), каждая из которых проектирует и реализует отдельные подсистемы проекта - позволяет улучшить управляемость проекта;

• использование итерационного подхода способствует уменьшению времени получения работоспособного прототипа;

  • наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца, существенно увеличивает эффективность работы.

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

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

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

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

 Под функциональной точкой в технологии RAD понимают любой из следующих функциональных элементов разрабатываемой системы: • входной элемент приложения (входной документ или экранная форма); • выходной элемент приложения (отчет, документ или экранная форма); • запрос (пара «вопрос/ответ»); • логический файл (совокупность записей данных, используемых внутри приложения); • интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).  Нормы, рассчитанные исходя из экспертных оценок, для систем со значительной повторяемостью кодов определяются следующим образом:

Под функциональной точкой в технологии RAD понимают любой из следующих функциональных элементов разрабатываемой системы:

• входной элемент приложения (входной документ или экранная форма);

• выходной элемент приложения (отчет, документ или экранная форма);

• запрос (пара «вопрос/ответ»);

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

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

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

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

• менее 1 тыс. функциональных точек- 1 человек;

• от 1 до 4 тыс. функциональных точек - одна команда разработчиков;

• более 4 тыс. функциональных точек - одна команда на каждые 4 тыс. точек.

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

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

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

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

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

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

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

Для разработки больших проектов используют гибкие методологии.

Принципы гибкой методологии

  • Высшим приоритетом считать удовлетворение пожеланий заказчика.
  • Не игнорировать изменение требований.
  • Поставлять новые работающие версии ПО часто.
  • Заказчики и разработчики должны работать совместно.
  • Проекты должны воплощать в жизнь целеустремленные люди.
  • Эффективный метод передачи информации– разговор лицом к лицу.
Работающая программа – основной показатель прогресса в проекте. Гибкие процессы способствуют долгосрочной разработке. Непрестанное внимание к качественному проектированию. Простота. Самые лучшие решения выдают самоорганизующиеся команды. Команда должна регулярно задумываться над тем, как стать ещё более эффективной.
  • Работающая программа – основной показатель прогресса в проекте.
  • Гибкие процессы способствуют долгосрочной разработке.
  • Непрестанное внимание к качественному проектированию.
  • Простота.
  • Самые лучшие решения выдают самоорганизующиеся команды.
  • Команда должна регулярно задумываться над тем, как стать ещё более эффективной.

Гибкие методологии Agile Modeling  Адаптивная разработка программного обеспечения  Agile Unified Process Разработка, ориентированная на особенности (быстрый унифицированный процесс) DSDM Технология Scrum Agile Data Method MSF for Agile Software Development ( Microsoft Solutions Framework для гибкой разработки ПО)  Extreme programming  Экстремальное программирование

Гибкие методологии

Agile Modeling

Адаптивная разработка программного обеспечения

Agile Unified Process

Разработка, ориентированная на особенности (быстрый унифицированный процесс)

DSDM

Технология Scrum

Agile Data Method

MSF for Agile Software Development ( Microsoft Solutions Framework для гибкой разработки ПО)

Extreme programming

Экстремальное программирование


Скачать

Рекомендуем курсы ПК и ППК для учителей

Вебинар для учителей

Свидетельство об участии БЕСПЛАТНО!

Поделитесь с друзьями
ВКонтактеОдноклассникиTwitterМой МирLiveJournalGoogle PlusЯндекс