Лаборатория информационных технологий (ИТЛаб) При поддержке фирмы Intel  Учебно-исследовательский проект Обзор моделей жизненного цикла разработки программного.

Slides:



Advertisements
Similar presentations
Астрометрические каталоги К.В.Куимов, ГАИШ МГУ. Определение астрометрического каталога Астрометрический каталог – понятие неопределённое. Например, это.
Advertisements

Схема распределения грантов городам-участникам программы Тасис (TCAS) Экологические гранты для муниципалитетов.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 4. Реализация ПО: Проектирование с повторным использованием компонентов.
Глава 1 Принципы экономики 4. Кривая производственных возможностей.
Автоматическая генерация кода программ с явным выделением состояний Канжелев С.Ю. магистрант СПбГУ ИТМО Шалыто А.А. доктор технических наук профессор СПбГУ.
Чибиняева Ольга 4 курс.  Сущность профессии финансового аналитика  Составляющие квалифицированного аналитика  Преимущества и недостатки профессии 
Разработка и внедрение объектно-ориентированной библиотеки для автоматизации тестирования Кафедра системного программирования Студент: Олейник А.Л. 544.
Системы отбора. Условные обозначения (1) (2) (3) (4) (5) (6) (7) Математическое моделирование процессов отбора2.
Автоматизированная поддержка пользовательской документации Web-приложений, разрабатываемых в среде WebRatio Студент: Дорохов Вадим, 544 гр. Научный руководитель:
Елена Станиславовна Петрова Учитель-логопед высшей категории ГДОУ детский сад №47 комбинированного вида Фрунзенского района г. Санкт-Петербурга 2011 год.
ООО «Баркод Маркет».  Инвентаризация имущества – программная система, позволяющая организовать учет любого имущества компании.  Уменьшение неконтролируемых.
Астащенко Александр, 445 группа Научный руководитель: В.Г.Шистеров.
Тел. (495) Москва, а/я 212 Рабочая группа по реформе МВД Москва, 2010 Новикова Асмик, Фонд «Общественный вердикт»
Тушин Александр, ЗАО «Компания Либэр». 1) Предоставление полнотекстовых материалов 2) Поиск по внутреннему содержанию документа 3) Доступность в режиме.
Разработка информационной системы накопительной программы лояльности для мобильных устройств Автор: Дьяченко Василий Владимирович мат-мех, 545 группа Научный.
ПРИНЦИПЫ РАЗРАБОТКИ СИСТЕМЫ КЛАССА LEARNING MANAGEMENT SYSTEM И ОПЫТ ЕЕ ИСПОЛЬЗОВАНИЯ НА ФАКУЛЬТЕТЕ МЕНЕДЖМЕНТА Афанасьева С.В. Кафедра бизнес-информатики.
Управление содержанием проекта Курс «Управление проектами» Раздел стандарта PMBoK №5 Лектор: Рылов Всеволод Юрьевич, консультант, директор, старший преподаватель.
1 Современный набор сервисов для клиентов-алготрейдеров: продукты, услуги Конференция «Роботы в биржевой торговле» Секция «Алготрейдинг глазами брокера»
О ПЫТ ОРГАНИЗАЦИИ КОНТРОЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ СТУДЕНТОВ И КАЧЕСТВА ОБУЧЕНИЯ НА БАЗЕ ЦЕНТРА ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ Ю ЖНОГО ФЕДЕРАЛЬНОГО УНИВЕРСИТЕТА.
Миллер Дмитрий, 545 группа Научный руководитель: д.ф.-м.н., профессор, А.Н.Терехов Рецензент: к.ф.-м.н, доцент, А.Н. Иванов.
Инновационный проект Мягкий Авто
Оценка уровня развития базовых способностей обучающихся
Обзор последних достижений биометрических методов аутентификации РусКрипто 2005.
1 СПбГУ ИТМО, кафедра Компьютерных Технологий ПРИМЕНЕНИЕ АВТОМАТНОГО ПРОГРАММИРОВАНИЯ ДЛЯ ПОСТРОЕНИЯ СИСТЕМ УПРАВЛЕНИЯ БИЗНЕС- ПРОЦЕССАМИ Евгений Андреевич.
Параметризация устройств сетевого управления Казакова А.С. Научный руководитель: Венгерова Е.А. Рецензент: Ушаков К.С. Кафедра системного программирования.
Управление и Конфигурирование Встроенных Систем Ушаков Константин, 545 группа Руководитель: Елена Венгерова.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 6. Управление проектами.
Компонент 3 Разработка системы показателей для измерения результативности органа исполнительной власти Component 3 Development of a system of.
Разработка программного обеспечения (Software Engineering) Часть 2. Создание ПО.
1 Генерация контекстных ограничений для баз данных Выполнил: Жолудев В. Научный руководитель: Терехов А.Н. Рецензент: Иванов А.Н.
Оценка эффективности инвестиционных проектов. Показатели эффективности инвестиций. Критерии принятия инвестиционных решений.
Понятие риска применительно к инвестиционным проектам
Сравнение различных методов хранения XML в реляционных базах данных и в разных системах. Нгуен Тхань Хуен- 545 группа Руководитель : Б.А. Новиков Рецензент:
 Нужно много различных протоколов связи  Каждый из них может реализовываться на разных платформах Современные сети Много устройств, компьютеров и сетей.
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Семинар 4. Прохождение фазы выработки концепции в.
Часть 4. Реализация ПО: проектирование интерфейса пользователя
Оптимизация Just – in - time компилятора методом профилирования значений Соколов Андрей Владимирович, ФФ НГУ, 3 курс, Руководитель:
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 6. Оценка стоимости программного продукта.
ICAO Training Workshop Moscow, Применение EATMP Common Core Content в процессе разработки учебных курсов: опыт Латвии Учебный центр АНС, Латвия.
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Лекции 6. Методология Microsoft Solutions Framework.
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Решения Autodesk в нефтегазовой отрасли Наталья Тамеева Директор по работе с корпоративными заказчиками на территории СНГ.
Анализ и Проектирование качественных приложений Презентация по книге Крэга Лармана.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 4. Реализация ПО: Архитектурное проектирование.
Разработка программного обеспечения (Software Engineering)
Характеристика направления «Менеджмент» (бакалавриат)
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Лекция 2. Элементы программной инженерии.
ПРИМЕНЕНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ НАВИГАЦИОННОГО ТИПА ДЛЯ ОБЕСПЕЧЕНИЯ ФУНКЦИОНИРОВАНИЯ ЦЕНТРОВ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ А. В. Беляков, Е. Б. Крейсманн Информационно-вычислительный.
Предметно-ориентированное моделирование приложений для платформы Android Никонова Ольга СПбГУ Научный руководитель Брыксин Т.А.
Демидов А.В г. Операционные системы Лекция 4 Работа с файлами.
Формализованы ли цели? Устраивает ли вас команда? Каковы этапы процесса? Изменение ИТ структуры? Нужны подрядчики? 1.
Метрики качества программного проекта Лаборатория информационных технологий (ИТЛаб) Учебно-исследовательский проект по курсу технологии программирования.
Разработка программного обеспечения (Software Engineering) Часть 2. Создание ПО.
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Лекции 5. Методология Microsoft Solutions Framework.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 3. Требования к ПО: разработка требований.
TMG Tel: 8 (495) Fax: 8 (477) Technology Management Group ООО «TMG» PayKeeper.
___________________________ Грязнов В.Б. Директор по Информационным технологиям ОАО «Мосэнерго»
XML Схемы XML документов. XML Schema созданая Microsoft позволяет избавиться от DTD блоков. Основа – использование пространств имен и очень точная типизация.
Санкт-Петербургский Государственный Университет Экономики и Финансов
Обработка исключений в C# Единая техника обнаружения ошибок времени выполнения и передачи информации о них.
РУП «БЕЛГЕОДЕЗИЯ» Топографо-геодезическое республиканское унитарное предприятие "Белгеодезия" - ведущее предприятие Беларуси в производстве.
Motorola General Business Use, CiDDT-Overview.ppt, Rev.1.0, 23-Jun-2008 MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
СОСТАВЛЕНИЕ ОПТИМАЛЬНОГО ПЛАНА ПРОДАЖ НА ПРИМЕРЕ МНОГОКВАРТИРНОГО ДОМА ЖДАНОВА МАРИЯ 4 КУРС, НИУ ВШЭ СПБ, СПБШЭМ, ДЕПАРТАМЕНТ ЭКОНОМИКИ ГРУППА « АНАЛИТИЧЕСКАЯ.
О понятийном аппарате Национальной системы квалификаций Российской Федерации Есенина Екатерина Юрьевна, ведущий научный сотрудник Центра профессионального.
SDL TRADOS 2006 Сокращение затрат и удвоение производительности: лингвистические технологии на основе баз данных от ведущей компании.
Дробление – уменьшение крупности материала под воздействием внешних сил. ПодготовительнымСамостоятельным Процессы дробления Подготовительное дробление.
УПРАВЛЕНИЕ ПРОЕКТАМИ - ПОНЯТИЯ И ПРОЦЕССЫ. Понятия Управления Проектами  Проект - это временное предприятие, предназначенное для создания уникальных.
Settlement Engine система автоматизации процесса взаиморасчётов по торговым операциям с ценными бумагами в инвестиционном банке Сложность разработки обусловлена:
Presentation transcript:

Лаборатория информационных технологий (ИТЛаб) При поддержке фирмы Intel  Учебно-исследовательский проект Обзор моделей жизненного цикла разработки программного обеспечения Куратор проекта: Карпенко С.Н. Разработчики: Вершинина Е.В. Гонченко М.С. Нижний Новгород 2004г.

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО2 Введение Для разработки продукта в проекте должен применяться процесс. Вместо создания каждого проекта «с нуля» можно выбрать «начальный» жизненный цикл. Жизненный цикл – это «карта-путеводитель» для всех участников проекта. Модель ЖЦ разработки ПО является единственным видом процесса, в котором представлен порядок его осуществления.

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО3 Обобщенная схема жизненного цикла Фаза План Спецификация Разработка Эксплуатация Действие Разработка проекта Код Тестирование модуля Тестирование системы

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО4 Модели ЖЦ разработки ПО Каскадная V – образная Модель быстрого прототипирования RAD – модель Инкрементная Спиральная Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО5 Каскадная модель Это была первая модель, которая придала особое значение исходным требованиям и проектированию. Попытки оптимизации данной модели привели к возникновению других циклов разработки ПО. Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО6 Каскадная модель – описание фаз Исследование концепции Процесс системного распределения Процесс определения требований Процесс разработки проекта Процесс реализации Процесс установки Процесс эксплуатации и поддержки Процесс сопровождения Процесс вывода из эксплуатации Интегральные задачи

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО7 Каскадная модель – преимущества Хорошо известна потребителям Упорядоченно справляется со сложностями Удобна в применении Стабильность требований Дефекты можно обнаружить на ранних этапах Доступна для понимания Хорошо определены стадии модели Легко проследить ход выполнения проекта

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО8 Каскадная модель – недостатки В основе - последовательная линейная структура Требования должны быть известны вначале Процесс обучения происходит в конце ЖЦ Замораживание результативных данных по завершению каждой фазы Интеграция полученных результатов происходит на завершающей стадии работы модели Клиент не может ознакомиться с системой заранее Программный продукт разрабатывается за один раз

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО9 Каскадная модель – область применения В ситуациях, в которых требования и их реализация четко определены При переносе уже существующего продукта на новую платформу При выполнении больших проектов, в которых задействовано несколько больших команд разработчиков

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО10 V - образная модель В модели особое значение придается действиям, направленным на верификацию и аттестацию продукта После кодирования следуют фазы тестирования Эта модель была разработана как разновидность каскадной модели Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО11 V –образная модель жизненного цикла разработки ПО

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО12 V - образная модель – описание фаз Планирование проекта и требований Анализ требований к продукту Архитектура или проектирование на высшем уровне Детализированная разработка проекта Разработка программного кода Модульное тестирование Интеграция и тестирование Системное и приемочное тестирование Производство, эксплуатация и сопровождение Приемочные испытания

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО13 V – образная модель – преимущества Особое значение придается планированию Определяет продукты, которые должны быть получены в результате процесса разработки Предусмотрены аттестация и верификация и внешних полученных данных Определение требований – перед разработкой проекта системы Проектирование ПО – перед разработкой компонентов Можно отслеживать ход процесса разработки Проста в использовании

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО14 V - образная модель – недостатки Плохо справляется с параллельными событиями Не учтены итерации между фазами Поздно происходит тестирование требований Не предусмотрено внесение требования динамических изменений Не содержит действий, направленных на анализ рисков

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО15 V - образная модель – область применения В ситуациях, в которых информация о требованиях доступна заранее В случае, когда доступными являются информация о методе реализации решения и технология В системах, в которых требуется высокая надежность

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО16 Модель быстрого прототипирования Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО17 Модель быстрого прототипирования– преимущества Взаимодействие заказчика с системой начинается на раннем этапе разработки В процессе разработки можно внести новые требования Можно выявить проблему до привлечения дополнительных ресурсов Позволяет выполнять гибкое проектирование и разработку Позволяет максимально уменьшить количество неточностей в требованиях Небольшой объем доработок

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО18 Модель быстрого прототипирования– недостатки Репутация «разработанного на скорую руку» метода Может быть уделено недостаточно внимания качеству ПО или долгосрочной надежности Решение трудных проблем может отодвигаться на будущее При досрочном завершении проекта у пользователя останется только частичная система Прототипирование вызывает зависимость Нет информации о точном числе итераций

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО19 Модель быстрого прототипирования– область применения Требования не известны заранее Требования непостоянны Есть потребность в разработке пользовательских интерфейсов Выполняется не имеющая аналогов разработка Осуществляются временные демонстрации При средней и высокой степенях риска Применяется с каскадной моделью Вместе с элементами анализа и проектирования

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО20 Модель быстрой разработки приложений RAD (Rapid Application Development) Пользователь задействован на всех фазах ЖЦ Короткое время перехода от определения требований до создания полной системы Разработка продукта ограничивается 60 днями, называемыми временным блоком Использование мощных инструментальных средств разработки, высокий уровень фактора использования Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО21 Модель RAD – описание фаз

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО22 Модель RAD – преимущества Время цикла разработки проекта сокращается Требуется меньшее количество специалистов Уменьшаются затраты Создается обратная связь Повторно используются компоненты уже существующих программ Возможно произвести быстрый изначальный просмотр продукта

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО23 Модель RAD – недостатки Необходимо достаточное количество высококвалифицирован- ных разработчиков Неудачна при отсутствии компонент для повторного использования Требуются быстрые действия из-за жестких временных ограничений Необходим эффективный ускоренный процесс разработки; При использовании "вслепую" затраты не ограничены

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО24 Модель RAD – область применения В моделируемых и масштабируемых системах Требования хорошо известны При невысокой степени технических рисков В информационных системах При выполнении проектов в сокращенные сроки Пригодные к повторному использованию части можно легко получить В системах небольшого размера Затраты и соблюдение графика не являются самым важным вопросом

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО25 Инкрементная модель Это процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. На ранних этапах выполняется конструирование системы в целом Модель эффективна при использовании как в случае чрезвычайно больших, так и в небольших проектов. Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО26 Инкрементная модель Выполнимость системы План и требо- вания к ПО Разработка про- екта продукта Аттестация Инкремент 3 Верифи- кация Инкремент 2Инкремент 1

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО27 Инкрементная модель Инкремент Детализирован ная разработка проекта Кодирова- ние Интегра- ция Внедре- ние Эксплуатация и сопровождение Верификация Модульное тестирование Верификация прогр. продукта Системное тестирование Повторная аттестация

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО28 Инкрементная модель – описание фаз Кодирование Тестирование Поставка Планирование Анализ Разработка

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО29 Инкрементная модель – преимущества Не требуется заранее тратить средства, необходимые для разработки всего проекта При выполнении каждого инкремента получается функциональный продукт Заказчик может высказаться по поводу каждой разработанной версии системы Существует возможность поддерживать постоянный прогресс в ходе выполнения проекта Снижаются затраты на первоначальную поставку программного продукта Снижается риск неудачи и изменения требований Риск распределяется на несколько меньших по размеру инкрементов

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО30 Инкрементная модель – недостатки Не предусмотрены итерации в рамках каждого инкремента Определение полной функциональной системы должно осуществляться в начале ЖЦ Может возникнуть оттягивание решений трудных проблем на будущее Для инкрементов трудно выполнить анализ и проверку

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО31 Инкрементная модель – область применения Требования можно сформулировать заранее Существует потребность быстро поставить на рынок продукт На выполнение проектов предусмотрен большой период времени разработки При равномерном распределении свойств различной степени важности При выполнении проекта с применением новой технологии

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО32 Спиральная модель Воплощает в себе преимущества каскадной модели Включены анализ рисков, управление ими, процессы поддержки и менеджмента Разработка продукта с использованием метода прототипирования или быстрой разработки приложения Каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО33 Спиральная модель

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО34 Спиральная модель – описание стадий Определение целей, альтернативных вариантов и ограничений Оценка альтернативных вариантов, идентификация и разрешение рисков Разработка продукта следующего уровня Планирование следующей фазы

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО35 Спиральная модель – преимущества Модель разрешает пользователям "увидеть" систему на ранних этапах Обеспечивается определение непреодолимых рисков Пользователи принимают участие при планировании, анализе рисков, разработке Предусмотрена возможность гибкого проектирования Обеспечивается разбиение большого объема работы по разработке продукта на небольшие части Обратная связь от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели Не нужно распределять заранее финансовые ресурсы

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО36 Спиральная модель – недостатки При низкой степени риска или небольших размерах, модель может оказаться дорогостоящей Модель имеет усложненную структуру Нужда в высоко профессиональных знаниях для оценки рисков Спираль может продолжаться до бесконечности

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО37 Спиральная модель – область применения Для средней или высокой степени риска Когда пользователи не уверены в своих потребностях Когда ожидаются существенные изменения Когда речь идет о применении новой технологии В случае больших проектов При выполнении бизнес- проектов и проектов в области аэрокосмической промышленности, обороны и инжиниринга

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО38 Адаптированные модели Быстрое отслеживание. Параллельный инжиниринг. Спиральная модель "Win-Win". Эволюционный/инкрементный принцип. Принцип V-образной инкрементной модели. Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО39 Быстрое отслеживание. Ускоренное прохождение или пропуск фаз жизненного цикла или процессов разработки; Необходимость в применении возникает в случае критической нехватки времени; ЖЦ обычно является менее формальным. Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО40 Параллельный инжиниринг. Создание продуктов более высокого качества за меньший период времени; Все аспекты ЖЦ проекта учитываются в процессе от проектирования до производства как можно раньше; Состоит из нескольких действий, которые осуществляются одновременно; Необходимо оценивать возможные технические риски при использовании метода. Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО41 Спиральная модель "Win-Win". К начальной фазе каждого цикла добавляются так называемые действия Теории W; Теория W— это принцип менеджмента, при реализации которого особое значение придается ключевым организаторам совместного дела, выполняющим разработку системы (пользователь, заказчик, разработчик, наладчик, создатель интерфейсов и т.д.), которые станут "победителями", если проект окажется успешным. Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО42 Спиральная модель "Win-Win" – описание фаз Определение участников следующего уровня; Определение условий, необходимых для одержания участниками победы; Согласование "победных" условий; Формулирование целей, ограничений и альтернативных вариантов следующего уровня; Оценка альтернативных вариантов на уровне продукта и процесса, разрешение рисков; Определение следующего уровня продукта и процесса, включая сегментацию; Обоснование определений продукта и процесса; Обзор и комментарии.

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО43 Спиральная модель "Win-Win" - преимущества Более быстрая разработка ПО; Уменьшение стоимости программ; Более высокий уровень удовлетворения со стороны участников проекта; Более высокое качество ПО; Исследование большого количества вариантов построения архитектуры на ранних этапах разработки. Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО44 Эволюционный/инкрементный принцип. Разработка программного продукта при использовании принципа часто затруднена; Каждая инкрементная конструкция реализует небольшую часть возможностей разрабатываемой системы Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО45 Принцип V-образной инкрементной модели. В модели предпринята попытка сбалансировать потребность в административном контроле с нуждами в технической инновации Контрольные точки представляют собой механизмы, определяющие совместное принятие менеджерами и разработчиками решений по переходу к следующей фазе со стороны Вместе с периодическим проведением руководством обзоров и предварительных просмотров, контрольные точки побуждают к обсуждению вопросов, рисков и альтернатив Адаптированные модели

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО46 Выбор приемлемой модели ЖЦ разработки ПО 1. Проанализировать отличительные категории проекта.отличительные категории 2. Ответить на вопросы каждой категории, обведя кружочком слова "да" или "нет". 3. Расположить по степени важности категории или вопросы, относящиеся к каждой категории, относительно проекта. 4. Воспользоваться упорядоченными категориями для разрешения противоречий, возникающих при сравнении моделей. Конспект

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО47 Отличительные категории Требования Команда разработчиков Коллектив пользователей Тип проекта и риски

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО48 Отличительные категории - требования Требования Каскад- ная V-образ- ная Прототи пирова ние Спира льная RAD Инкрем ентная Являются ли требова- ния легко определи- мыми и/или хорошо известными? Да Нет ДаНет Могут ли требования заранее определяться в цикле? Да Нет Да Часто ли будут изме- няться требования в цикле? Нет Да Нет Нужно ли демонстри- ровать требования с целью определения? Нет Да Нет

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО49 Отличительные категории – требования (продолжение) Требования Каскад ная V-образ ная Прототи пирова ние Спира льная RAD Инкрем ентная Требуются ли для де- монстрации возмож- ностей проверка кон- цепции? Нет Да Нет Будут ли требования отражать сложность системы? Нет Да НетДа Обладает ли требова- ние функциональны- ми свойствами на раннем этапе? Нет Да Отличительные категории

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО50 Отличительные категории – команда разработчиков Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Являются ли пробле- мы предметной облас- ти проекта новыми для большинства раз- работчиков? Нет ДатДаНет Является ли техноло- гия предметной об- ласти проекта новой для большинства раз- работчиков? Да НетДаНетДа Изменяются ли роли участников проекта во время ЖЦ? Нет Да НетДа

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО51 Отличительные категории – команда разработчиков (продолжение) Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Являются ли инстру- менты, используемые проектом, новыми для большинства разра-ботчиков? Да НетДаНет Могут ли разработчи- ки проекта пройти обучение? НетДаНет Да Является ли структу- ра более значимой для разработчиков, чем гибкость? Да Нет Да

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО52 Отличительные категории – команда разработчиков (конец) Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будет ли менеджер проекта строго отсле- живать прогресс ко- манды? Да НетДаНетДа Важна ли легкость распределения ресур- сов? Да Нет Да Приемлет ли команда равноправные обзоры и инспекции, менедж- мент/обзоры заказчи- ка, а также стадии? Да НетДа Отличительные категории

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО53 Отличительные категории – коллектив пользователей Коллектив пользователей Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будет ли присутствие пользователей огра- ничено в жизненном цикле? Да НетДаНетДа Будут ли пользовате- ли знакомы с опреде- лением системы? Нет Да НетДа Буду ли пользователи ознакомлены с проб- лемами предметной области? Нет ДаНетДа

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО54 Отличительные категории – коллектив пользователей (продолжение) Коллектив пользователей Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будут ли пользовате- ли вовлечены во все фазы жизненного цикла? Нет ДаНетДаНет Будет ли заказчик от- слеживать ход выпол- нения проекта? Нет Да Нет Отличительные категории

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО55 Отличительные категории – тип проекта и риски Тип проекта и риски Каскад ная V-образ- ная Прототи пирова ние Спира льная RAD Инкре ментна я Будет ли проект иден- тифицировать новое направление продукта для организации? Нет Да НетДа Будет ли проект име- ть тип системной ин- теграции? НетДа Будет ли проект яв- ляться расширением существующей систе- мы? НетДаНет Да Должна ли быть вы- сокая степень надеж- ности? НетДаНетДаНетДа

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО56 Отличительные категории – тип проекта и риски (продолжение) Тип проекта и риски Каскад ная V-образ- ная Прототи пирова- ние Спираль ная RAD Инкре- ментна я Будет ли финансиро- вание проекта ста- бильным на всем про- тяжении ЖЦ? Да НетДаНет Ожидается ли дли- тельная эксплуатация продукта в организа- ции? Да НетДаНетДа Будет ли система из- меняться с применением непредвиденных методов, на этапе со- провождения? Нет Да НетДа Является ли график ограниченным? Нет Да

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО57 Отличительные категории – тип проекта и риски (конец) Тип проекта и риски Каскад- ная V-образ- ная Прототи пирова- ние Спира льная RAD Инкрем ентная Будет ли проект иден- тифицировать новое направление продукта для организации? Нет Да НетДа Являются ли "проз- рачными" интерфейс- ные модули? Да Нет Да Доступны ли повтор- но используемые ком- поненты? Нет Да Нет Являются ли доста- точными ресурсы (время, деньги, инст- рументы, персонал)? Нет Да Нет Отличительные категории

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО58 Подгонка модели жизненного цикла разработки ПО 1. Ознакомьтесь с различными моделями. 2. Просмотрите и проанализируйте возможные виды работ: разработка, модернизация, сопровождение и т.д. 3. Выберите самый подходящий жизненный цикл, используя матрицы критериев: высокая степень риска, пользовательский интерфейс, высокая надежность, время доставки на рынок/выпуска продукта, приоритеты пользователя, уточнение требований, ожидаемый срок эксплуатации системы, технология, размер и сложность, возможный параллелизм, интерфейсы для существующих и новых систем.

(c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО59 Подгонка модели жизненного цикла разработки ПО 4. Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам организации, заказчиков или типа проекта — ISO, IEEE и т.д. 5. Сформулируйте набор фаз и действий, образующих каждую фазу. 6. Определите внутренние и внешние производимые продукты. 7. Определите шаблоны и внутреннее содержимое поставляемых продуктов. 8. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта. 9. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо.