🗊Презентация Технологии разработки программного обеспечения (ПО). Традиционные технологии разработки ПО

Лекция № 1 Тема 1. Технологии разработки программного обеспечения (ПО). Часть 1. Традиционные технологии разработки ПО. Кафедра «Инженерии программного обеспечения» Подготовила: к.т.н., доцент Фролова Г.А.

Содержание лекции Содержание лекции 1.1.Технологии разработки программного обеспечения (ПО). 1.1.1. Исторический и современный взгляд на разработку ПО. 1.1.2. Типичная схема разработки ПО. 1.2.Традиционные технологии разработки ПО. 1.2.1. Водопадная (waterfall) модель. 1.2.2. Спиральная (spiral) модель. 1.2.3. Инкрементная (iterative and incremental development) модель. 1.2.4. Макетирование или прототиппирование (prototyping). 1.3. Гибкие технологии разработки ПО. Основные положения Agile Manifesto. 1.3.1. Экстремальное программирование (Extreme Programming). 1.3.2. Scrum. 1.3.3. Microsoft Solutions Framework. 1.3.4. Feature Driven Development. 1.4. Сравнение традиционных и гибких технологий разработки ПО.

Рекомендуемая литература Рекомендуемая литература

1.1.Технологии разработки программного обеспечения (ПО) 1.1.Технологии разработки программного обеспечения (ПО) Технология разработки программного обеспечения (ПО) — система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.

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

1.1.2. Исторический и современный взгляд на разработку ПО 1.1.2. Исторический и современный взгляд на разработку ПО Разработка ПО. 1950-1980 Этап вплоть до конца 1970х годов можно считать "темными веками" индустрии разработки ПО. Особенностями данного периода ее развития являются: Общая неразвитость индустрии. Это вызвано несовершенством как технических средств, так и отсутствием теоретического базиса. Специфическое ПО. ПО является, по сути дела, штучным продуктом, в основном используемым там же, где и велась его разработка, причем основная масса ПО – это научные и инженерные задачи.

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

Понятно, что при такой постановке работ получить ответ на вопрос "Сколько нам понадобится времени для создания того-то и того-то" не представляется возможным. Однако, уже к середине 1970х годов появляются внутрикорпоративные стандарты разработки, соответствующие водопадной модели. Понятно, что при такой постановке работ получить ответ на вопрос "Сколько нам понадобится времени для создания того-то и того-то" не представляется возможным. Однако, уже к середине 1970х годов появляются внутрикорпоративные стандарты разработки, соответствующие водопадной модели. Также в 1976 году выходит ставшая классикой книга Брукса "Мифический человеко-месяц", которая не утратила своей актуальности и поныне, и всячески рекомендуется к прочтению.

Разработка ПО. 1980-1996 Разработка ПО. 1980-1996 Данный период отрасли можно охарактеризовать как "осознание того, что так жить дальше нельзя". Аппаратные средства стали доступными как организациям, так и индивидуальным пользователям, что вызвало грандиозное увеличение объема рынка для программного обеспечения. И можно по праву назвать это время эпохой "триумфального шествия бизнес-приложений". ПО стали "потреблять" не только в местах его разработки, что вызывало, ужесточение требований как к самому ПО, так и усложнению процесса разработки.

Чаще всего часто заказчик располагался за сотни миль от места воплощения его идей в жизнь. Более того, разработчики перестали являться специалистами в предметной области заказчика (как это было ранее). Вместе с повышенной сложностью ПО и увеличившимися трудозатратами на его создание эти факторы привели к тому, что на выходе, после водопадной модели, чаще всего заказчик получал совсем не то, что ему нужно, и продукт отправлялся в мусорную корзину, а вместе с ним – и миллионы долларов. Чаще всего часто заказчик располагался за сотни миль от места воплощения его идей в жизнь. Более того, разработчики перестали являться специалистами в предметной области заказчика (как это было ранее). Вместе с повышенной сложностью ПО и увеличившимися трудозатратами на его создание эти факторы привели к тому, что на выходе, после водопадной модели, чаще всего заказчик получал совсем не то, что ему нужно, и продукт отправлялся в мусорную корзину, а вместе с ним – и миллионы долларов. Выходом из подобной ситуации стала инкрементальная и спиральная модели. Одновременно делается попытка приспособить существующие в промышленности стандарты качества для ИТ-индустрии. На западе – это стандарты ISO, в СССР – ГОСТы.

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

Более того, практика показала ограниченность применявшихся ранее инкрементальной и спиральной моделей, и на смену им появилась и была почти повсеместно принята итеративная модель разработки ПО. Стоит отметить, что большинство успешных проектов было создано именно на ее основе. Более того, практика показала ограниченность применявшихся ранее инкрементальной и спиральной моделей, и на смену им появилась и была почти повсеместно принята итеративная модель разработки ПО. Стоит отметить, что большинство успешных проектов было создано именно на ее основе. Итеративная модель была впервые предложена широким массам ИТ-специалистов компанией Rational (сейчас IBM), и является основой ее методологии RUP. Также она лежит в основе MSF (Microsoft Solutions Framework) и борландовской ALM (Application Lifecycle Management).

В связи с тем, что разработка ПО постоянно усложняется во всех аспектах, обнаружилась потребность давать четкий ответ на вопрос "Может ли эта организация разработать требуемый продукт?" И, как развитие вопроса, возникла необходимость в наборе свойств, признаков, критериев, позволяющих количественно оценить степень зрелости организации, вероятность ее успеха на ниве создания ПО, так сказать. Отсюда берет корни модель CMM (в дальнейшем развившаяся в CMMI), Capability Maturity Model. В связи с тем, что разработка ПО постоянно усложняется во всех аспектах, обнаружилась потребность давать четкий ответ на вопрос "Может ли эта организация разработать требуемый продукт?" И, как развитие вопроса, возникла необходимость в наборе свойств, признаков, критериев, позволяющих количественно оценить степень зрелости организации, вероятность ее успеха на ниве создания ПО, так сказать. Отсюда берет корни модель CMM (в дальнейшем развившаяся в CMMI), Capability Maturity Model. Вместе с тем продолжается совершенствование стандартов разработки ПО, организации самого процесса разработки, что нашло отражение в стандартах ISO 90003:2004 и ISO/IEC 15504.

1.1.2. Типичная схема разработки ПО 1.1.2. Типичная схема разработки ПО Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации [Стандарт IEEE Std 610.12, Глоссарий] Стандарты жизненного цикла ПО ГОСТ 34.601-90 ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС): Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС): 1. Формирование требований к АС Обследование объекта и обоснование необходимости создания АС. Формирование требований пользователя к АС. Оформление отчета о выполнении работ и заявки на разработку АС. 2. Разработка концепции АС Изучение объекта. Проведение необходимых научно-исследовательских работ. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей. Оформление отчета о проделанной работе.

3. Техническое задание 3. Техническое задание Разработка и утверждение технического задания на создание АС. 4. Эскизный проект Разработка предварительных проектных решений по системе и ее частям. Разработка документации на АС и ее части. 5. Технический проект Разработка проектных решений по системе и ее частям. Разработка документации на АС и ее части. Разработка и оформление документации на поставку комплектующих изделий. Разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация 6. Рабочая документация Разработка рабочей документации на АС и ее части. Разработка и адаптация программ. 7. Ввод в действие Подготовка объекта автоматизации. Подготовка персонала. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). Строительно-монтажные работы. Пусконаладочные работы. Проведение предварительных испытаний. Проведение опытной эксплуатации. Проведение приемочных испытаний. 8. Сопровождение АС. Выполнение работ в соответствии с гарантийными обязательствами. Послегарантийное обслуживание.

Стандартная последовательность шагов разработки ПО. Стандартная последовательность шагов разработки ПО. 1. Понять природу и сферу применения предлагаемого продукта. 2. Выбрать процесс разработки и создать план. 3. Собрать требования. 4. Спроектировать и собрать продукт. 5. Выполнить тестирование продукта. 6. Выпустить продукт и обеспечить его сопровождение.

Разновидности моделей процесса разработки ПО: Разновидности моделей процесса разработки ПО: – водопадная; – спиральная (итерационная); – инкрементная; – макетирование; – объектно-ориентированное программирование; – компонентный подход (COM, CORBA); – САSЕ-технологии; – RAD; – RUP; – гибкие (agile) технологии: экстремальное программирование (XP), Scrum, TDD, FDD.

1.2.Традиционные технологии разработки ПО 1.2.Традиционные технологии разработки ПО 1.2.1. Водопадная (waterfall) модель Водопадная или каскадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе (рис. 1.1).

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

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

1.2.2. Спиральная (spiral) модель 1.2.2. Спиральная (spiral) модель Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.

PDCA («Plan-Do-Check-Act») циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel, или Plan-Do-Study-Act. PDCA («Plan-Do-Check-Act») циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel, или Plan-Do-Study-Act.

Спасибо за внимание Спасибо за внимание