Презентация «Математические и инструментальные методы в экономике»
Смотреть слайды в полном размере 
Вы можете ознакомиться с презентацией онлайн, просмотреть текст и слайды к ней, а также, в случае, если она вам подходит - скачать файл для редактирования или печати. Документ содержит 137 слайдов и доступен в формате ppt. Размер файла: 1.80 MB
Pic.1
Курс по дисциплине «Программная инженерия» Максимов Константин Викторович Аспирант, специализация 08. 00. 13 «Математические и инструментальные методы в экономике» Научный руководитель Денисов Д. В. …
Pic.2
СФЕРА НАУЧНЫХ ИНТЕРЕСОВ Автоматизация управления предприятием (ИС автоматизации отдельных задач, интегрированные ИС, корпоративные ИС, системная интеграция) Управление проектами разработки и …
Pic.3
ПРОГРАММА КУРСА 4 лекции 3 лабораторных практикума
Pic.4
ОСНОВНЫЕ ИСТОЧНИКИ КУРСА Курс базируется на: Стандарт ISO/IEC 12207:2007 System and software engineering. Software life cycle processes Информационная технология СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ …
Pic.5
ЛЕКЦИЯ 1 Основные темы: Проблемы разработки сложных программных систем Жизненный цикл и процессы разработки ПО Модели жизненного цикла Унифицированный процесс разработки и экстремальное …
Pic.6
ПРЕДМЕТ И ОБЪЕКТ Предметом изучения является технология, методы и средства разработки, тестирования и отладки программного продукта. Объектом изучения выступает жизненный цикл программного …
Pic.7
КАК ПРОЕКТИРУЮТСЯ ПРОГРАММЫ
Pic.8
ПРОБЛЕМЫ РАЗРАБОТКИ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ Сложные или «большие» программы, называемые также программными системами, программными комплексами, программными продуктами, отличаются от «небольших» …
Pic.9
ОСОБЕННОСТИ СЛОЖНОЙ ПРОГРАММЫ Решает одну или несколько связанных задач Ее низкая производительность на реальных данных приводит к значимым потерям для пользователей. Существенно, чтобы она была …
Pic.10
ПРОГРАММНАЯ ИНЖЕНЕРИЯ Часто программное обеспечение (ПО) нельзя рассматривать отдельно от программно-аппаратной системы, куда оно входит в качестве составной части.
Pic.11
ПРИНЦИПА РАБОТЫ СО СЛОЖНЫМИ ПРОГРАММАМИ Абстракция (abstraction) и уточнение (refinement). Модульность (modularity). Переиспользование.
Pic.12
ЖИЗНЕННЫЙ ЦИКЛ И ПРОЦЕССЫ РАЗРАБОТКИ ПО Весь период существования ПО, связанный с подготовкой к его разработке, разработкой, использованием и модификациями, начиная с того момента, когда принмается …
Pic.13
Проект Одним из ключевых понятий технологии разработки программного обеспечения, как и многих других областей деятельности, является понятие проекта. Проект есть уникальное временное предприятие, …
Pic.14
Четыре «П» разработки ПО Персонал (кто это делает) Процесс (способ, которым это делается) Проект (выполнение необходимых действий) Продукт (артефакты)
Pic.15
Продукт Артефакт – любой вид информации, создаваемый, изменяемый и используемый сотрудниками при создании системы Артефакты: Само приложение Спецификация требований Проектная модель Исходный и …
Pic.16
Проект Совокупность действий, необходимых для создания артефакта: контакт с заказчиком написание документации проектирование программирование тестирование …
Pic.17
Процесс Процесс создания ПО – определение полного набора видов деятельности, необходимых для преобразования требований пользователя в продукт. Процесс служит шаблоном для создания проекта. Процесс …
Pic.18
Стандарты жизненного цикла IEEE — читается «ай-трипл-и», Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике; ISO — International Standards …
Pic.19
Группа стандартов ISO ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes [1] (процессы жизненного цикла ПО, есть его российский аналог ГОСТ Р-1999 [2]). ISO/IEC 15288 …
Pic.20
Группа стандартов IEEE и CMM, разработанных SEI IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes [5] (стандарт на создание процессов жизненного цикла ПО). IEEE/EIA …
Pic.21
Модели жизненного цикла каскадная или водопадная (waterfall) модель жизненного цикла Итеративные или инкрементальные модели (известно несколько таких моделей) спиральная модель жизненного цикла ПО
Pic.22
Сводный график стандартов
Pic.23
Семейства процессов разработки ПО тяжеловесные (heavyweight) применяются при фиксированных требованиях и многочисленной группе разработчиков разной квалификации облегченные (lightweight, agile) …
Pic.24
Стратегии создания ПО
Pic.25
Технологии программирования Технология программирования (технология разработки ПО) — способ организации процесса создания программы, совокупность приемов и способов выполнения определенных видов …
Pic.26
Источники сложности проекта Наличие высококвалифицированных специалистов на рынке труда. Стабильность используемой технологической платформы, стабильность и функциональность инструментов разработки. …
Pic.27
Проблемы управления проектами Многие процессы разработки неуправляемы. Их исходные данные и желаемый результат неизвестны или определены очень нечетко. Процесс достижения желаемого результата не …
Pic.28
Водопадная модель жизненного цикла ПО:
Pic.29
Модель с промежуточным контролем:
Pic.30
Макетирование (прототипирование)
Pic.31
Инкрементная модель
Pic.32
Технология RAD Rapid Application Development — Быстрая разработка приложений. Ориентирована на максимально быстрое получение первых версий разрабатываемого ПО. Она предусматривает: ведение разработки …
Pic.33
Этапы RAD Бизнес-моделирование (моделируются информационные потоки между бизнес-функциями) Моделирование данных (набор объектов, которые требуются для поддержки бизнес-процессов) Моделирование …
Pic.34
Спиральная модель разработки ПО Программное обеспечение создается итерационно с использованием метода прототипирования. Прототипом обычно называют действующий программный продукт, реализующий …
Pic.35
Особенности спиральной модели Основным достоинством спиральной схемы является то, что, начиная с некоторой итерации, продукт можно предоставлять пользователю, что позволяет: сократить время до …
Pic.36
Гибкие технологии разработки ПО Минимизируют риски благодаря разделению процесса разработки на маленькие промежутки времени (итерации), обычно 1-4 недели. Каждая итерация может рассматриваться как …
Pic.37
Основные идеи agile • Личности и их взаимодействие важнее, чем процессы и инструменты. • Работающее программное обеспечение важнее, чем полная документация. • Сотрудничество с заказчиком важнее, чем …
Pic.38
Основы манифеста гибких технологий • Главное – удовлетворение требований заказчика путем скорой и непрерывной поставки ценного и работоспособного ПО. • Приветствуются изменяющиеся требования: их …
Pic.39
Проектирование в гибких технологиях Отказ от длительного проектирования перед началом работы и выполнение проектирования на протяжении всего выполнения проекта. В начале проекта выполняется лишь …
Pic.40
Разработчики получают задачу, берут соответствующий фрагмент разрабатываемого кода, выполняют рефакторинг, необходимый для упрощения написанного кода, составляют тесты, а только затем создают сам …
Pic.41
Экстремальное программирование Основная идея экстремального программирования (ХР) — устранить высокую стоимость изменений, вносимых в ПО в процессе как разработки, так и эксплуатации. Цикл разработки …
Pic.42
Основные принципы ХР Планирование Частая смена версий Метафора Простой проект Тесты Переработка системы Программирование в паре Непрерывная интеграция
Pic.43
Тестирование в ХР Тестирование модулей (unit testing): позволяет разработчикам убедиться, что код работает корректно, и без опасений выполнять рефакторинг (refactoring). помогает не авторам кода …
Pic.44
Scrum Основой Scrum является итеративная разработка. Scrum определяет итеративные правила управления проектом, которые призваны обеспечивать достижение максимального эффекта от реализованной …
Pic.45
Общие положения 3 роли: владелец продукта (Product Owner) - отвечает за определение требований к продукту команда (Team) - группа самостоятельных и инициативных разработчиков, ответственных за …
Pic.46
Реализация проекта в Scrum Фаза реализации разбита на последовательность итераций - спринтов (Sprint). В результате каждого спринта в продукте реализуется новый, заметный для владельца продукта, …
Pic.47
Документация в Scrum Всего 3 документа: журнал продукта (Product Backlog) высокоуровневый список функциональных и технических требований, необходимых для реализации продукта журнал спринта (Sprint …
Pic.48
Унифицированный процесс (RUP)
Pic.49
Характеристики УП управляемый вариантами использования архитектурно-ориентированный итеративный и инкрементный использует UML основан на компонентном подходе, использует стандарт визуального …
Pic.50
Преимущества управляемого УП Ограничивает финансовые риски затратами на одну итерацию Снижает риск непоставки продукта Ускоряет темпы процесса разработки в целом Облегчает адаптацию к неизбежным …
Pic.51
Жизненный цикл УП Каждый цикл состоит из 4х фаз, каждая фаза разделяется на итерации Результатом каждого цикла является новый выпуск системы Каждая фаза заканчивается вехой Веха определяется по …
Pic.52
Назначение вех По ним руководитель принимает решения перед тем, как перейти на следующую фазу Возможность отслеживать процесс Возможность прогнозирования оценок в других процессах
Pic.53
Цикл разработки
Pic.54
Содержание фаз Анализ и планирование требований: идея превращается в концепцию готового продукта создается бизнес-план разработки упрощенная модель вариантов использования пробный вариант архитектуры …
Pic.55
Построение уточнение базового уровня архитектуры реализация всех вариантов использования Внедрение бета-версия тренинги сотрудников заказчиков исправление дефектов
Pic.56
Модели УП Модели – наиболее важный тип артефактов. Каждая модель описывает систему с определенной точки зрения на определенном уровне абстракции. Вариантов использования Анализа Проектирования …
Pic.57
UML Язык для специфицирования, визуализации, конструирования и документирования программных продуктов. Также используется в бизнес-моделировании и моделировании любых иных (не программных) систем. …
Pic.58
Диаграммы вариантов использования (Use case diagrams)
Pic.59
Диаграммы деятельности (Activity diagrams)
Pic.60
Диаграммы последовательностей действий (Sequence diagrams)
Pic.61
Диаграммы компонент (Component diagrams)
Pic.62
Пример реального процесса разработки ПО
Pic.63
Обзор идеи Выдвигается идея нового продукта Назначается менеджер по продукту (PdM). Он оценивает идею и составляет ее краткий обзор, который направляет на утверждение HBU и HPdM. Назначается PjM …
Pic.64
Обзор проекта PjM назначает системного архитектора (SWA) и старшего тестера (CQA). PdM, PjM, представитель спонсора, SWA, CQA формируют руководящую группу (Steering Group), принимающую решения по …
Pic.65
Подготовка проекта PjM уточняет план проекта, назначает команду разработчиков, организует взаимодействие с другими отделами (документация, локализация, поддержка пользователей, технические тренинги и …
Pic.66
Разработка продукта (Development) - 1 SWA разрабатывает на утверждение SG дизайн продукта (Design Description) и спецификацию по Интерфейсу пользователя (UI description), проводит декомпозицию на …
Pic.67
Разработка продукта (Development) - 2 Выполняется итеративно: анализ, дизайн, программирование, тестирование. Milestones Dn – D1: завершение билда N, …, 1. Milestone D1: Фиксация - Code & feature …
Pic.68
Альфа-тестирование Итеративное тестирование продукта тестерами под руководством CQA. Как только серьезных проблем больше не обнаруживается, продукт переходит в статус beta version. Milestone V3: …
Pic.69
Бета-тестирование Продукт отсылается на ознакомление и тестирование ограниченному набору пользователей (User Support team, beta testers, sales engineers, external partners). Milestone V2: готов …
Pic.70
Подготовка к выпуску и выпуск PdM и HPdM проверяют, что продукт готов к выходу на рынок (все собрано, документация подготовлена, отделы поддержки и тренинга готовы, реклама дана, произведена …
Pic.71
все!
Pic.72
CASE-технологии Computer Aided Software/System Engineering – автоматизированная разработка ПО/систем Существуют САSЕ-технологии, поддерживающие как структурный, так и объектный (в т. ч. компонентный) …
Pic.73
Компонентный подход и САSЕ-технологии Компонентный подход предполагает построение программного обеспечения из отдельных компонентов — физически отдельно существующих частей программного обеспечения, …
Pic.74
Технологии СОМ Технология СОМ определяет общий принцип взаимодействия программ любых типов: библиотек, приложений, операционной системы, т. е. позволяет одной части программного обеспечения …
Pic.75
На базе технологии COM были разработаны компонентные технологии, решающие различные задачи разработки программного обеспечения. На базе технологии COM были разработаны компонентные технологии, …
Pic.76
Технологии СОМ MTS (Microsoft Transaction Server — сервер управления транзакциями) — технология, обеспечивающая безопасность и стабильную работу распределенных приложений при больших объемах …
Pic.77
Технология СОRВА Технология СОRВА, разработанная группой компаний ОМG, реализует подход, аналогичный СОМ, на базе объектов и интерфейсов СОRВА. Программное ядро СОRВА реализовано для всех основных …
Pic.78
ЛЕКЦИЯ 2 Основные темы: Анализ предметной области и требования к ПО Качество ПО и методы его контроля Тестирование Архитектура программного обеспечения
Pic.79
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ Для выявления этих потребностей, а также для выяснения смысла сказанных требований приходится проводить достаточно большую дополнительную работу, которая называется анализом …
Pic.80
СИСТЕМАТИЗАЦИЯ ИНФОРМАЦИИ О ПРЕДПРИЯТИИ Для систематизации сбора информации о больших организациях и дальнйшей разработки систем, поддерживающих их деятельность, применяется схема Захманана(автор — …
Pic.81
В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где и когда — и разные уровни …
Pic.82
СИСТЕМАТИЗАЦИЯ ИНФОРМАЦИИ О ПРЕДПРИЯТИИ
Pic.83
Pic.84
ФОРМИРОВАНИЕ ТРЕБОВАНИЙ Потребности, требования определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой. При этом требуется аккуратное выявление …
Pic.85
Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенных задач, с которыми придется работать разрабатываемой системе, можно составлять требования к ней, представляющие собой …
Pic.86
Pic.87
СТАНДАРТЫ РАБОТЫ С ТРЕБОВАНИЯМИ ПО IEEE830-1998 Recommended Practice for Software Requirements Specifications Описывает структуру документов для фиксации требований к ПО. Кроме того, он определяет …
Pic.88
IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications Описывает правила построения требований для …
Pic.89
ТЕХНИКИ ФИКСАЦИИ ТРЕБОВАНИЙ Вариантом использования (use case) называют некоторый сценарий действий системы, который обеспечивает ощутимый и значимый для ее пользователей результат. На практике в …
Pic.90
Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением (generalization), расширением (extend relationship) и включением (include relationship). Действующие лица также …
Pic.91
Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением (generalization), расширением (extend relationship) и включением (include relationship). Действующие лица также …
Pic.92
КАЧЕСТВО ПО И МЕТОДЫ ЕГО КОНТРОЛЯ Варианты ответов. • Его легко использовать. • Оно демонстрирует хорошую производительность. • В нем нет ошибок. • Оно не портит пользовательские данные при сбоях. • …
Pic.93
Общие принципы обеспечения качества процессов производства во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки ПО стандарты в его составе следующие: …
Pic.94
ISO 9004:2000 Quality management systems — Guidelines for performance improvements Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ Р-2001). ISO 9004:2000 Quality …
Pic.95
Качество программного обеспечения определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех …
Pic.96
Pic.97
Функциональность (functionality)Способность ПО в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает ПО, какие задачи оно решает. Функциональность …
Pic.98
Надежность (reliability). Способность ПО поддерживать определенную работоспособность в заданных условиях. Надежность (reliability). Способность ПО поддерживать определенную работоспособность в …
Pic.99
Удобство использования (usability) или практичность. Способность ПО быть удобным в обучении и использовании, а также привлекательным для пользователей. Удобство использования (usability) или …
Pic.100
Производительность (efficiency) или эффективность. Способность ПО при заданных условиях обеспечивать необходимую работоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и …
Pic.101
Удобство сопровождения (maintainability). Удобство проведения всех видов деятельности, связанных с сопровождение программ. Удобство сопровождения (maintainability). Удобство проведения всех видов …
Pic.102
Переносимость (portability). Способность ПО сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения. Переносимость …
Pic.103
МЕТОДЫ КОНТРОЛЯ КАЧЕСТВА Ответы на эти вопросы можно получить с помощью процессов верификации и валидации. Верификация обозначает проверку того, что ПО разработано в соответствии со всеми …
Pic.104
Методы контроля качества позволяют убедиться, что определенные характеристики качества ПО достигнуты. Методы контроля качества ПО можно классифицировать следующим образом: Методы контроля качества …
Pic.105
Тестирование — это проверка соответствия ПО требованиям, осуществляемая с помощью наблюдения за его работой в специальных, искусственно построенных ситуациях. Такого рода ситуации называют тестовыми …
Pic.106
Тестирование — наиболее широко применяемый метод контроля качества. Для оценки многих атрибутов качества не существует других эффективных способов, кроме тестирования. Тестирование — наиболее широко …
Pic.107
Выделяют виды тестирования, связанные с проверкой определенных характеристик и атрибутов качества — тестирование функциональности, надежности, удобства использования, переносимости и …
Pic.108
Проверка свойств на моделях (model checking) — проверка соответствия ПО требованиям при помощи формализации проверяемых свойств, построения формальных моделей проверяемого ПО (чаще всего в виде …
Pic.109
Pic.110
Ошибками в ПО, вообще говоря, являются все возможные несоответствия между демонстрируемыми характеристиками его качества и сформулированными или подразумеваемыми требованиями и ожиданиями …
Pic.111
АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Под архитектурой ПО понимают набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий …
Pic.112
Pic.113
Список стандартов, регламентирующих описание архитектуры, которое является основной составляющей проектной документации на ПО, выглядит так: Список стандартов, регламентирующих описание архитектуры, …
Pic.114
Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для решения таких задач, как следующие: Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для …
Pic.115
РАЗРАБОТКА И ОЦЕНКА АРХИТЕКТУРЫ НА ОСНОВЕ СЦЕНАРИЕВ Выделение компонентов Выбирается набор "основных" сценариев использования — наиболее существенных и выполняемых чаще других. Исходя из …
Pic.116
РАЗРАБОТКА И ОЦЕНКА АРХИТЕКТУРЫ НА ОСНОВЕ СЦЕНАРИЕВ Определение интерфейсов компонентов Для каждого компонента в результате выделяется его интерфейс — набор сообщений, которые он принимает от других …
Pic.117
РАЗРАБОТКА И ОЦЕНКА АРХИТЕКТУРЫ НА ОСНОВЕ СЦЕНАРИЕВ Уточнение набора компонентов Там, где это необходимо в силу требований эффективности или удобства сопровождения, несколько компонентов могут быть …
Pic.118
UML. ВИДЫ ДИАГРАММ UML Для представления архитектуры, а, точнее, различных входящих в нее структур, удобно использовать графические языки. На настоящий момент наиболее проработанным и наиболее широко …
Pic.119
Диаграммы UML делятся на две группы — статические и динамические диаграммы. Диаграммы UML делятся на две группы — статические и динамические диаграммы. UML предлагает использовать для описания …
Pic.120
СТАТИЧЕСКИЕ ДИАГРАММЫ Статические диаграммы представляют либо постоянно присутствующие в системе сущности и связи между ними, либо суммарную информацию о сущностях и связях, либо сущности и связи, …
Pic.121
Диаграммы классов (class diagrams) показывают классы или типы сущностей системы, характеристики классов ( поля и операции ) и возможные связи между ними. Диаграммы классов (class diagrams) показывают …
Pic.122
Pic.123
Диаграммы объектов (object diagrams) показывают часть объектов системы и связи между ними в некотором конкретном состоянии или суммарно, за некоторый интервал времени. Объекты изображаются …
Pic.124
Pic.125
Диаграммы компонентов (component diagrams) представляют компоненты в нескольких смыслах — атомарные составляющие системы с точки зрения ее сборки, конфигурационного управления и развертывания. …
Pic.126
Pic.127
Диаграммы развертывания (deployment diagrams) показывают декомпозицию системы на физические устройства различных видов — серверы, рабочие станции, терминалы, принтеры, маршрутизаторы и пр. — и связи …
Pic.128
Pic.129
ДИНАМИЧЕСКИЕ ДИАГРАММЫ Динамические диаграммы описывают происходящие в системе процессы. К ним относятся диаграммы деятельности, сценариев,диаграммы взаимодействия и диаграммы состояний.
Pic.130
Диаграммы деятельности (activity diagrams) иллюстрируют набор процессов-деятельностей и потоки данных между ними, а также возможные их синхронизации друг с другом. Деятельность изображается в виде …
Pic.131
Pic.132
Диаграммы сценариев (или диаграммы последовательности, sequence diagrams) показывают возможные сценарии обмена сообщениями или вызовами во времени между различными компонентами системы (здесь имеются …
Pic.133
Pic.134
Диаграммы взаимодействия (collaboration diagrams) показывают ту же информацию, что и диаграммы сценариев, но привязывают обмен сообщениями/вызовами не к времени, а к связям между компонентами …
Pic.135
Диаграммы состояний (statechart diagrams) показывают возможные состояния отдельных компонентов или системы в целом, переходы между ними в ответ на какие-либо события и выполняемые при этом действия. …
Pic.136
Pic.137
всё всё
Если вам понравился сайт и размещенные на нем материалы, пожалуйста, не забывайте поделиться этой страничкой в социальных сетях и с друзьями! Спасибо!
