РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. - презентация

1 РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

2 ЛЕКЦИЯ 2 ТЕМА: МОДЕЛИ И СТАДИИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3 Сайт ссылки на учебники в электронном варианте; ссылки на учебники в электронном варианте; методические указания к практическому занятию 1; методические указания к практическому занятию 1; тесты по теме «Жизненный цикл ПО». тесты по теме «Жизненный цикл ПО».

4 Литература Для самостоятельного изучения: В. А. Благодатских, В. А. Волнин, К. Ф. Поскакалов. Стандартизация разработки программных средств. Глава 2. Жизненный цикл программных средств (стр ).

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

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

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

8 Примечание. ПО – более общее понятие, чем ПС, к которому относят технологическое ПО, разрабатываемое под данную систему, задачу, техническое устройство, или для создания новых прикладных программ. В литературе ПО и ПС часто объединяют под общим понятием – software.

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

10 При создании заказного ПО выделяют пять основных стадий ЖЦ: Анализ и формализация требований заказчика; Проектирование информационной системы; Тестирование; Реализация (разработка); Внедрение и эксплуатация.

11 Основным нормативным документом, регламентирующим процессы ЖЦ ПО, является международный стандарт ISO/IEC Information Technology –Software Life Cycle Processes. Этот стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Здесь ISO (International Organization for Standardization)международная организация стандартизации, IEC((International Electrotechnical Commission) - международная комиссия по электротехнике.

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

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

14 В РФ существует комплекс ГОСТов на создание автоматизированных систем. Однако вопросы разработки ПО отражены в них недостаточно, а отдельные их положения явно устарели. Поэтому в отечественных разработках целесообразно использовать современные стандарты.

15 В Стандарте ISO/IEC 12207:1995 процессы ЖЦ ПО разделены на 3 группы: основные процессы: приобретение; поставка; разработка; эксплуатация; сопровождение. вспомогательные процессы: документирование; управление конфигураций; обеспечение качества; верификация; аттестация; совместная оценка; аудит, разрешение возникающих проблем. организационные процессы: управление; совершенствование; создание инфраструктуры; обучение.

16 Организационные процессы Управление проектами Создание инфраструктуры проекта Усовершенствование ЖЦ Обучение Основные процессы Приобретение Поставка РазработкаЭксплуатация Сопровождение Вспомогательные процессы Документирование Обеспечение качества Управление конфигурацией Разрешение проблем Верификация АттестацияСовместная оценка Аудит

17 Понятие ЖЦ применяется для любой системы или технической разработки. Международный стандарт ISO/IEC 12207:1995 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов, но не конкретизирует в деталях, как реализовать и выполнить действия и задачи, включенные в эти процессы. Модель ЖЦ данного ПО определяет типы процессов и последовательность упорядоченных, взаимосвязанных и объединенных в стадии работ.

18 Различные подходы к составу и наименованию стадий

19 ГОСТ 34Барри У. БоэмOracle COMRational Unified Process Формирование требований к АС. Разработка концепции АС. Тех. задание Анализ осуществимости системы. Планирование и анализ требований к ПО Стратегия. Анализ Начальная стадия (Inception) Эскизный проект. Технический проект Проектирование изделия. Детальное проектирование Проектирование Разработка (Elaboration) Рабочая документация Кодирование РеализацияКонструиро- вание (Construction) Ввод в действие. Сопровождение АС Внедрение.Функ- ционирование (эксплуатация) и сопровождение Внедрение. Эксплуатация и сопровождение Ввод в действие (Transition)

20 Содержание некоторых стадий работ

21 Стадия Анализ и формализация требований заказчика В эту стадию входят: Планирование работ, предваряющее все остальные работы над проектом. Основными задачами планирования являются: -определение целей разработки; -предварительная экономическая оценка проекта; -построение плана-графика выполнения работ; -создание и обучение совместной рабочей группы.

22 Обследование деятельности автоматизируемого объекта, в рамках которого осуществляются задачи: 1) предварительное выявление требований к будущей системе; 2) определение структуры организации; 3) определение перечня целевых функций организации; 4) анализ распределения функций по подразделениям и сотрудникам; 5) выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к данной организации объектов и информационных воздействий; 6) анализ имеющихся средств автоматизации деятельности организации.

23 Построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей: - модели «AS-IS» («как есть»), отражающей существующее на момент обследования положение дел в организации и позволяющее понять, каким образом функционирует данная организация, а также выявит узкие места и сформулировать предложения по улучшению ситуации; - модели «TO-BE» («как должно быть»), отражающей представление о предлагаемых новых технологиях работы организации.

24 Каждая из моделей включает в себя функциональную и информационную модели деятельности организации- заказчика, а также, в случае необходимости, модель, описываемую динамику поведения организации. Переход от модели «AS-IS» к модели «TO- BE» выполняют 2 способами: совершенствованием существующих технологий на основе оценки их эффективности; радикальным изменением и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов)

25 Фрагмент функциональной модели процесса планирования технической подготовки производства «Как есть - AS-IS» для конкретного предприятия в формате IDEF0.

26 Функциональная модель процесса ТПП «Как должно быть - AS TO BE»

27 Эта стадия включает этапы: Разработка системного проекта. На этом этапе проектирования определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, а также определяются требования к программным и информационным компонентам, состав исполнителей, сроки разработки. Дается ответ на вопрос: «Что должна делать будущая система?». Основу системного проекта составляют модели проектируемой ЭИС, которое строится на основе модели «TO-BE». Документальным результатом является согласованное ТЗ. Проектирование

28 Разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование Дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

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

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

31 Этот процесс предусматривает действия и задачи, выполняемые службой сопровождения. Согласно стандарта IEEE-90 под сопровождением понимается внесение изменений в ПО в целях исправления обнаруженных ошибок, повышения производительности и адаптации к изменившимся требованиям. Изменения, вносимые в существующее программное обеспечение, не должны нарушать его целостность. Сопровождение ПО

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

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

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

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

36 Организационные процессы Управление проектами Создание инфраструктуры проекта Усовершенствование ЖЦ Обучение Основные процессы Приобретение Поставка РазработкаЭксплуатация Сопровождение Вспомогательные процессы Документирование Обеспечение качества Управление конфигурацией Разрешение проблем Верификация АттестацияСовместная оценка Аудит

37 Вспомогательные процессы в ЖЦ

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

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

40 Управление конфигурацией позволяет организовать, тематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC : 1995 «Information Technology – Software Life cycle Processes.Part2. Configuration».

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

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

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

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

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

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

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

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

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

50 Процесс усовершенствования предусматривает оценку, изменение, контроль процессов ЖЦ ПО.

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

52 Модели жизненного цикла программных средств

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

54 Выбор модели зависит от специфики, масштаба, сложности проекта и специфики условий, в которых система создается и функционирует. Выделяют 3 основных типа моделей ЖЦ: I. последовательный, или каскадный ( ); II. эволюционный (или поэтапный); III. спиральный ( ). Реальные модели ЖЦ развития являются комбинацией этих типов.

55 Последовательный (каскадный) тип модели ЖЦ Данный тип ЖЦ предполагает, что каждая следующая стадия может быть начата только после завершения работ на предыдущей стадии.

56 В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ.

57 Каскадная схема разработки программного средства

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

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

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

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

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

63 В результате реальный процесс создания ПС принимал следующий вид

64 Эволюционный (поэтапный) тип модели ЖЦ Функциональные возможности системы в данном случае наращиваются поэтапно, эволюционно. Причём возможно одновременное выполнение и корректирующее повторение этапов разработки. Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке.

65 К недостаткам эволюционного типа относят: сложность в управлении и контроле выполнения проекта; сложность оценки затрат на разработку; риск бесконечного улучшения системы.

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

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

68 Спиральный тип модели ЖЦ

69 В середине 1980-х годов Барри Боэм предложил свой вариант итерационной модели под названием «спиральная модель» (spiral model), когда ПО создается не сразу, как в каскадной модели, а по частям, методом прототипирования.

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

71 1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; 6 – начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком.

72

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

74 Достоинства спиральной модели: ускорение разработки (раннее получение результата за счет прототипирования); постоянное участие заказчика в процессе разработки; разбиение большого объема работы на небольшие части; снижение риска (повышение вероятности предсказуемого поведения системы).

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

76 Выводы Проектирование ПО – это формальный процесс, который можно изучить и совершенствовать.