Невозможно отобразить презентацию
Программное обеспечениеПохожие презентации:
Методологии разработки ПО
1 Методологии разработки ПО 1 Жизненный цикл информационной системы 2 Каскадная модель 3 Итеративный подход 4 Спиральная модель 5 Гибкая методология разработки Учебные вопросы: Вопрос №1 Жизненный цикл информационной системы2 Жизненный цикл информационной системы Автоматизированная система- система, состоящая из персонала, комплекса средств автоматизации его деятельности и регламентов работы, реализующая информационную технологию выполнения установленных функций.
Если автоматизируемый процесс связан в основном с обработкой информации, то такая система называется автоматизированной информационной системой.
Информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств» Специальное программное обеспечение автоматизированной системы (СПО АС): часть программного [обеспечения] АС, представляющая собой совокупность программ, разработанных при создании данной АС Жизненный цикл информационной системы Процесс разработки программного обеспечения— структура, согласно которой построена разработка программного обеспечения (ПО).
Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.
Сопутствующие области знаний Управление проектами Управление требованиями Конфигурационное управление Документирование Жизненный цикл информационной системы Стандарты жизненного цикла ПО Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла.
Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
ГОСТ 34.601-90 ISO/IEC 12207:1995 (Российский аналог — ГОСТ Р ИСО/МЭК 12207-99) Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ГОСТ 34.601-90 предусматривает ряд стадий и этапов создания автоматизированной системы.
Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО.
Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ГОСТ 34.601-90 предусматривает ряд стадий и этапов создания автоматизированной системы.
1 Формирование требований к АС 2 Разработка концепции АС 3 Техническое задание 4 Эскизный проект 5 Технический проект 6 Рабочая документация 7 Ввод в действие 8 Сопровождение АС.
Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» Структура стандарта имеет гибкий, модульный скелет, что позволяет быть адаптируемым к потребностям любого пользователя.
Набор процессов, действий и задач может быть адаптирован согласно проекту программного обеспечения.
Процессы делятся на три типа: основные вспомогательные организационные Жизненный цикл информационной системы Стандарты жизненного цикла ПО - ISO/IEC 12207:1995 Группа основных процессов Заказ Поставка Разработка Эксплуатация Сопровождение Группа вспомогательных процессов процесс документирования процесс управления конфигурацией процесс обеспечения качества процесс верификации процесс аттестации процесс совместного анализа процесс аудита процесс решения проблем Жизненный цикл информационной системы Стандарты жизненного цикла ПО - ISO/IEC 12207:1995 Группа организационных процессов процесс управления: процесс создания инфраструктуры: процесс усовершенствования: процесс обучения: Жизненный цикл информационной системы Модели и методологии разработки ПО 1 Каскадная модель 2 Итеративная модель 2.1 Методология Rational Unified Process (RUP) 3 Спиральная модель 4 Гибкая методология разработки (Agile) 4.1 Методология Scrum 4.2 Методология экстремального програмирования 5 Методология Microsoft Solutions Framework (MSF) Жизненный цикл информационной системы Жизненный цикл ПО с точки зрения пользователя 1 Осознание потребности 2 Выбор3 Приобретение 4 Внедрение 5 Эксплуатация 6 Расширение функций 7 Осознание необходимости в более мощном ПО Жизненный цикл информационной системы Системная интеграция — это разработка и внедрение комплексных решений по автоматизации технологических и бизнес-процессов предприятия Предмет автоматизации - технологические процессы и бизнес-процессы предприятия Цель системной интеграции – повышение эффективности управления процессами предприятия Системный интегратор – компания, занимающаяся системной интеграцией Жизненный цикл информационной системы Основные критерии повышения эффективности: Унификация процессов -> упорядоченная деятельность, единая точка зрения на процессы Автоматизация типовых операций -> уменьшение времени выполнения Электронные хранилища информации -> возможность оперативного доступа к информации и формирования отчетов Жизненный цикл информационной системы Проблемы системной интеграции Нехватка квалифицированных специалистов Высокая стоимость и долгие сроки выполнения проектов Низкий уровень подготовки пользователей - непонимание целей, и открывающихся перспектив - неумение полноценно использовать внедренное ПО, как следствие - неудовлетворенность Жизненный цикл информационной системы Вопрос №2 Каскадная модель17 Процесс разработки ПО Каскадная модель (модель водопада) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке: Определение требований Проектирование Конструирование (также «реализация» либо «кодирование») Интеграция Тестирование и отладка (также «верификация») Инсталляция Поддержка Процесс разработки ПО Критика каскадной модели и гибридные методологические решения Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству.
Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным.
Начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов Вопрос №3 Итеративный подход20 Процесс разработки ПО Итеративный подход (англ.
iteration — повторение)— выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка.
Процесс разработки ПО Преимущества итеративного подхода: снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение организация эффективной обратной связи проектной команды с потребителем (заказчиками) и создание продукта, реально отвечающего его потребностям акцент усилий на наиболее важные и критичные направления проекта;
Процесс разработки ПО Преимущества итеративного подхода: непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
более равномерная загрузка участников проекта;
эффективное использование накопленного опыта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
затраты распределяются по всему проекту, а не группируются в его конце.
Процесс разработки ПО Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией RationalSoftware.
В основе RUP лежат следующие принципы: Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (сбор требований, вариантов использования)).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Процесс разработки ПО 1 Начальная стадия (Inception) Формируются видение и границы проекта.
Создается экономическое обоснование.
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении начальной фазы оценивается достижение вехи целей жизненного цикла которое предполагает соглашение заинтересованных сторон о продолжении проекта.
Процесс разработки ПО 2 Уточнение (Elaboration) Производится анализ предметной области и построение исполняемой архитектуры.
Документирование требований (включая детальное описание для большинства прецедентов-вариантов использования).
Спроектированная, реализованная и оттестированная архитектура.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.
Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла Процесс разработки ПО 3 Построение (Construction) Происходит реализация большей части функциональности продукта.
Фаза завершается первым внешним релизом системы и вехой начальной функциональной готовности.
Процесс разработки ПО 4.
Внедрение (Transition) Создается финальная версия продукта и передается от разработчика к заказчику.
Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта.
В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова.
Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Вопрос №4 Спиральная модель30 Процесс разработки ПО Спиральная модель , предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО.
Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование.
Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
Процесс разработки ПО Боэм формулирует десять наиболее распространённых (по приоритетам) рисков: Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
Перфекционизм - ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Процесс разработки ПО Боэм формулирует десять наиболее распространённых (по приоритетам) рисков: Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Процесс разработки ПО Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.
Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Каждый виток разбит на 4 сектора: оценка и разрешение рисков, определение целей, разработка и тестирование, планирование.
Процесс разработки ПО RAD (от англ.
rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы.
Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.
С конца XX века RAD получила широкое распространение и одобрение.
Концепцию RAD также часто связывают с концепцией визуального программирования.
Процесс разработки ПО RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки.
Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.
Процесс разработки ПО Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации,- выработка требований к системе.
Выполнение этих условий подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы.
Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше.
Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
Процесс разработки ПО Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ высокой скорости разработки, низкой стоимости высокого качества.
Основные принципы Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Процесс разработки ПО Основные принципы Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки.
Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн Процесс разработки ПО Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз Процесс разработки ПО 1 Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла.
На этом этапе пользователи, менеджеры и IT- специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке.
Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.
Процесс разработки ПО 2 Пользовательское проектирование - на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции.
3 Конструирование - этап, в котором основная задача заключается в разработке программ и приложений.
В RAD пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов.
Процесс разработки ПО 4 Переключение - включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей.
Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени.
Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.
Процесс разработки ПО Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.
Необходимо выполнение проекта в сжатые сроки Нечетко определены требования к ПО.
Проект выполняется в условиях ограниченности бюджета.
Интерфейс пользователя (GUI) есть главный фактор.
Возможно разбиение проекта на функциональные компоненты.
Низкая вычислительная сложность ПО Вопрос № Гибкая методология разработки45 Процесс разработки ПО Гибкая методология разработки (Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения.
Существует несколько подобных методик.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется AgileManifesto.
Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto cодержит 4 основные идеи и 12 принципов.
Методология Scrum Методология экстремального програмирования (XP) Процесс разработки ПО Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся 2-3 недели.
Каждая итерация - программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини- прироста по функциональности (планирование, анализ требований, проектирование, кодирование, тестирование и документирование).
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Процесс разработки ПО Основной метрикой agile-методов является рабочий продукт.
Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами.
Это привело к критике этих методов, как недисциплинированных.
Процесс разработки ПО Основные идеи: Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.
Процесс разработки ПО Принципы, которые разъясняет Agile Manifesto: удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
Процесс разработки ПО Принципы, которые разъясняет Agile Manifesto: проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее ПО — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
постоянное внимание на улучшение технического мастерства и удобный дизайн;
простота — искусство НЕ делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Процесс разработки ПО Критика Многие руководители проектов, работающие в традиционных методологиях вроде "водопада", критикуют Agile.
Один из повторяющихся пунктов критики - при Agile- подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется оная «карта».
Процесс разработки ПО Критика Подход Agile к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии) - подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта.
Такое иногда приводит к катастрофическим «авралам» с массовым переделками практически на каждой очередной итерации.
Процесс разработки ПО Критика Считается, что работа в Agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - "работает, и ладно", при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжелые к воспроизводству дефекты после реального
Если автоматизируемый процесс связан в основном с обработкой информации, то такая система называется автоматизированной информационной системой.
Информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств» Специальное программное обеспечение автоматизированной системы (СПО АС): часть программного [обеспечения] АС, представляющая собой совокупность программ, разработанных при создании данной АС Жизненный цикл информационной системы Процесс разработки программного обеспечения— структура, согласно которой построена разработка программного обеспечения (ПО).
Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.
Сопутствующие области знаний Управление проектами Управление требованиями Конфигурационное управление Документирование Жизненный цикл информационной системы Стандарты жизненного цикла ПО Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла.
Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
ГОСТ 34.601-90 ISO/IEC 12207:1995 (Российский аналог — ГОСТ Р ИСО/МЭК 12207-99) Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ГОСТ 34.601-90 предусматривает ряд стадий и этапов создания автоматизированной системы.
Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО.
Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ГОСТ 34.601-90 предусматривает ряд стадий и этапов создания автоматизированной системы.
1 Формирование требований к АС 2 Разработка концепции АС 3 Техническое задание 4 Эскизный проект 5 Технический проект 6 Рабочая документация 7 Ввод в действие 8 Сопровождение АС.
Жизненный цикл информационной системы Стандарты жизненного цикла ПО Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» Структура стандарта имеет гибкий, модульный скелет, что позволяет быть адаптируемым к потребностям любого пользователя.
Набор процессов, действий и задач может быть адаптирован согласно проекту программного обеспечения.
Процессы делятся на три типа: основные вспомогательные организационные Жизненный цикл информационной системы Стандарты жизненного цикла ПО - ISO/IEC 12207:1995 Группа основных процессов Заказ Поставка Разработка Эксплуатация Сопровождение Группа вспомогательных процессов процесс документирования процесс управления конфигурацией процесс обеспечения качества процесс верификации процесс аттестации процесс совместного анализа процесс аудита процесс решения проблем Жизненный цикл информационной системы Стандарты жизненного цикла ПО - ISO/IEC 12207:1995 Группа организационных процессов процесс управления: процесс создания инфраструктуры: процесс усовершенствования: процесс обучения: Жизненный цикл информационной системы Модели и методологии разработки ПО 1 Каскадная модель 2 Итеративная модель 2.1 Методология Rational Unified Process (RUP) 3 Спиральная модель 4 Гибкая методология разработки (Agile) 4.1 Методология Scrum 4.2 Методология экстремального програмирования 5 Методология Microsoft Solutions Framework (MSF) Жизненный цикл информационной системы Жизненный цикл ПО с точки зрения пользователя 1 Осознание потребности 2 Выбор3 Приобретение 4 Внедрение 5 Эксплуатация 6 Расширение функций 7 Осознание необходимости в более мощном ПО Жизненный цикл информационной системы Системная интеграция — это разработка и внедрение комплексных решений по автоматизации технологических и бизнес-процессов предприятия Предмет автоматизации - технологические процессы и бизнес-процессы предприятия Цель системной интеграции – повышение эффективности управления процессами предприятия Системный интегратор – компания, занимающаяся системной интеграцией Жизненный цикл информационной системы Основные критерии повышения эффективности: Унификация процессов -> упорядоченная деятельность, единая точка зрения на процессы Автоматизация типовых операций -> уменьшение времени выполнения Электронные хранилища информации -> возможность оперативного доступа к информации и формирования отчетов Жизненный цикл информационной системы Проблемы системной интеграции Нехватка квалифицированных специалистов Высокая стоимость и долгие сроки выполнения проектов Низкий уровень подготовки пользователей - непонимание целей, и открывающихся перспектив - неумение полноценно использовать внедренное ПО, как следствие - неудовлетворенность Жизненный цикл информационной системы Вопрос №2 Каскадная модель17 Процесс разработки ПО Каскадная модель (модель водопада) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке: Определение требований Проектирование Конструирование (также «реализация» либо «кодирование») Интеграция Тестирование и отладка (также «верификация») Инсталляция Поддержка Процесс разработки ПО Критика каскадной модели и гибридные методологические решения Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству.
Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным.
Начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов Вопрос №3 Итеративный подход20 Процесс разработки ПО Итеративный подход (англ.
iteration — повторение)— выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка.
Процесс разработки ПО Преимущества итеративного подхода: снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение организация эффективной обратной связи проектной команды с потребителем (заказчиками) и создание продукта, реально отвечающего его потребностям акцент усилий на наиболее важные и критичные направления проекта;
Процесс разработки ПО Преимущества итеративного подхода: непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
более равномерная загрузка участников проекта;
эффективное использование накопленного опыта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
затраты распределяются по всему проекту, а не группируются в его конце.
Процесс разработки ПО Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией RationalSoftware.
В основе RUP лежат следующие принципы: Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (сбор требований, вариантов использования)).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Процесс разработки ПО 1 Начальная стадия (Inception) Формируются видение и границы проекта.
Создается экономическое обоснование.
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении начальной фазы оценивается достижение вехи целей жизненного цикла которое предполагает соглашение заинтересованных сторон о продолжении проекта.
Процесс разработки ПО 2 Уточнение (Elaboration) Производится анализ предметной области и построение исполняемой архитектуры.
Документирование требований (включая детальное описание для большинства прецедентов-вариантов использования).
Спроектированная, реализованная и оттестированная архитектура.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.
Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла Процесс разработки ПО 3 Построение (Construction) Происходит реализация большей части функциональности продукта.
Фаза завершается первым внешним релизом системы и вехой начальной функциональной готовности.
Процесс разработки ПО 4.
Внедрение (Transition) Создается финальная версия продукта и передается от разработчика к заказчику.
Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта.
В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова.
Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Вопрос №4 Спиральная модель30 Процесс разработки ПО Спиральная модель , предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО.
Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование.
Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
Процесс разработки ПО Боэм формулирует десять наиболее распространённых (по приоритетам) рисков: Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
Перфекционизм - ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Процесс разработки ПО Боэм формулирует десять наиболее распространённых (по приоритетам) рисков: Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Процесс разработки ПО Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.
Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Каждый виток разбит на 4 сектора: оценка и разрешение рисков, определение целей, разработка и тестирование, планирование.
Процесс разработки ПО RAD (от англ.
rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы.
Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.
С конца XX века RAD получила широкое распространение и одобрение.
Концепцию RAD также часто связывают с концепцией визуального программирования.
Процесс разработки ПО RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки.
Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.
Процесс разработки ПО Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации,- выработка требований к системе.
Выполнение этих условий подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы.
Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше.
Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
Процесс разработки ПО Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ высокой скорости разработки, низкой стоимости высокого качества.
Основные принципы Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Процесс разработки ПО Основные принципы Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки.
Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн Процесс разработки ПО Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз Процесс разработки ПО 1 Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла.
На этом этапе пользователи, менеджеры и IT- специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке.
Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.
Процесс разработки ПО 2 Пользовательское проектирование - на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции.
3 Конструирование - этап, в котором основная задача заключается в разработке программ и приложений.
В RAD пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов.
Процесс разработки ПО 4 Переключение - включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей.
Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени.
Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.
Процесс разработки ПО Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.
Необходимо выполнение проекта в сжатые сроки Нечетко определены требования к ПО.
Проект выполняется в условиях ограниченности бюджета.
Интерфейс пользователя (GUI) есть главный фактор.
Возможно разбиение проекта на функциональные компоненты.
Низкая вычислительная сложность ПО Вопрос № Гибкая методология разработки45 Процесс разработки ПО Гибкая методология разработки (Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения.
Существует несколько подобных методик.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется AgileManifesto.
Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto cодержит 4 основные идеи и 12 принципов.
Методология Scrum Методология экстремального програмирования (XP) Процесс разработки ПО Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся 2-3 недели.
Каждая итерация - программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини- прироста по функциональности (планирование, анализ требований, проектирование, кодирование, тестирование и документирование).
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Процесс разработки ПО Основной метрикой agile-методов является рабочий продукт.
Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами.
Это привело к критике этих методов, как недисциплинированных.
Процесс разработки ПО Основные идеи: Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.
Процесс разработки ПО Принципы, которые разъясняет Agile Manifesto: удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
Процесс разработки ПО Принципы, которые разъясняет Agile Manifesto: проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее ПО — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
постоянное внимание на улучшение технического мастерства и удобный дизайн;
простота — искусство НЕ делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Процесс разработки ПО Критика Многие руководители проектов, работающие в традиционных методологиях вроде "водопада", критикуют Agile.
Один из повторяющихся пунктов критики - при Agile- подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется оная «карта».
Процесс разработки ПО Критика Подход Agile к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии) - подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта.
Такое иногда приводит к катастрофическим «авралам» с массовым переделками практически на каждой очередной итерации.
Процесс разработки ПО Критика Считается, что работа в Agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - "работает, и ладно", при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжелые к воспроизводству дефекты после реального