презентации к урокам
презентация к уроку
презентации для групп исп
Скачать:
Предварительный просмотр:
Подписи к слайдам:
Процессы жизненного цикла программного обеспечения
Основные процессы жизненного цикла приобретение; поставка; разработка; эксплуатация; сопровождение.
Вспомогательные процессы жизненного цикла документирование; управление конфигурацией; обеспечение качества; верификация; аттестация; совместная оценка; аудит; разрешение проблем.
Организационные процессы управление; усовершенствование; создание инфраструктуры; обучение.
Процессы жизненного цикла Учебник § 1..3
Предварительный просмотр:
Подписи к слайдам:
Стандарты стандарт проектирования; стандарт оформления проектной документации; стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать: набор необходимых моделей на каждой стадии проектирования и степень их детализации; правила фиксации проектных решений, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов; требования к конфигурации рабочих мест разработчиков, включая настройки средств отладки, общие настройки проекта и т. д.; механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т. д.), правила проверки проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.); правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, если используются встроенные автоматизированные средства подготовки документации.
Стандарт интерфейса пользователя должен устанавливать: правила оформления элементов отображения данных; правила использования элементов управления (клавиатуры); правила оформления сообщений и их перечень; правила обработки реакции пользователя.
Стратегии разработки программного обеспечения Модель жизненного цикла ПО Каскадная стратегия разработки ПО - каскадная модель V образная модель Инкрементная стратегия разработки ПО Эволюционная стратегия разработки ПО
Достоинства КС Стабильность требований в течение ЖЦ разработки; Необходимость только одного прохода этапов разработки; Простата планирования, контроля и управления проектом; Доступность для понимания заказчиками
Недостатки КС Сложность формулирования требований в начале процесса разработки; Линейность структуры; Отсутствие промежуточных продуктов; Недостаточное участие пользователя в процессе разработки.
Достоинства и недостатки Инкрементная стратегия разработки ПО Эволюционная стратегия разработки ПО - Составить сравнительную таблицу стратегий разработки ПО
Стандарты и концепции Учебник § 2.1-2.2 конспект
Предварительный просмотр:
Подписи к слайдам:
Общие требования Требование Первичные требования Требования к компонентам ПО Управление требованиями Функциональные требования Нефункциональные требования
Анализ и структурирование первичных требований Что представляют собой первичные требования? Кем проводится анализ ПТЗ Что необходимо выяснить при анализе ПТЗ? Как происходит структурирование требований?
Моделирование предметной области Модель предметной области Предварительное моделирование предметной области Требования к МПО Построение системы моделей Язык моделирования Нотация Уровни модели
Требования к МПО Формализация, обеспечивающая однозначное описание структуры предметной области; Понятность на основе применения графических средств отображения модели; Реализуемость; Обеспечение возможности оценки эффективности реализации модели предметной области на основе методов и вычисляемых показателей
Системы моделей Объектная модель, отражает состав взаимодействующих в процессах материальных и информационных объектов предметной области; Функциональная модель, отражает взаимосвязь функций (действий) по преобразованию объектов в процессах Техническая модель, описывает топологию расположения и способы коммуникации комплекса ТС
Уровни модели Внешний (определение требований) Концептуальный (спецификации требований) Внутренний (реализация требований)
Основные этапы технологического процесса разработки программ
Требования к созданию программного продукта Учебник § 3.1,3.2, 4.4 Учебник §7.1-7.3
Предварительный просмотр:
Подписи к слайдам:
Категории документов документация разработки; документация продукции; документация управления проектом.
Цель разработки документов они являются средством связи между всеми вовлеченными в процесс разработки. Они описывают подробности решений, принятых относительно требований к программному обеспечению, проекту, программированию и тестированию; они описывают обязанности группы разработки. Они определяют, кто, что и когда делает, учитывая роль программного обеспечения, предмета работ, документации, персонала, обеспечивающего качество, и каждого вовлеченного в процесс разработки; они выступают как контрольные пункты, которые позволяют руководителям оценивать ход разработки. Если документы разработки отсутствуют, неполны или устарели, руководители теряют важное средство для отслеживания и контроля проекта программного обеспечения; они образуют основу документации сопровождения программного обеспечения, требуемой сопровождающими программистами как часть документации продукции; они описывают историю разработки программного обеспечения.
Типовые документы разработки анализы осуществимости и исходные заявки; спецификации требований; спецификации функций; проектные спецификации, включая спецификации программ и данных; планы разработки; планы сборки и тестирования программного обеспечения; планы обеспечения качества, стандарты и графики; защитная и тестовая информация.
Цели документации продукции она обеспечивает учебную и справочную информацию для любого использующего или эксплуатирующего программную продукцию; она облегчает программистам, не разрабатывавшим программное обеспечение, его сопровождение и модернизацию; она помогает продаже или приемке программной продукции.
Типовые документы продукции учебные руководства; справочные руководства и руководства пользователя; руководства по сопровождению программного обеспечения; брошюры и информационные листовки, посвященные продукции.
Документация управления проектом графики для каждой стадии процесса разработки и отчеты об изменениях графиков; отчеты о согласованных изменениях программного обеспечения; отчеты о решениях, связанных с разработкой; распределение обязанностей.
Определение качества документов качество содержания можно измерять в элементах точности, полноты и ясности; качество структуры можно измерять легкостью, с которой читатель имеет возможность определить местоположение информации; качество представления должно соответствовать типу проекта. Например, руководство пользователя может иметь форму набора машинописных страниц, скрепленных вместе, или может быть типографской книгой с обширными иллюстрациями, созданной специалистом по графике.
Типы документации архитектурная/проектная; техническая; пользовательская; маркетинговая.
Техническая документация техническое задание; технический проект.
Техническое задание Это документ, регламентирующий бизнес-цели, общее описание системы, объем работ, границы проекта, а также порядок разработки, оценки и приемки. Данный документ отвечает нам на вопрос «что нужно сделать?» и фактически является постановкой задачи.
Технический проект Это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы.
Разделы технического задания Введение 1Основаание для разработки. 2 Назначение разработки. 3 Требования к программе или программному изделию. 4 Требования к программной документации. 5 Технико-экономическое обоснование. 6 Стадии и этапы разработки. 7 Порядок контроля и приемки 8 Приложения
Техническая документация Учебник § 3.2 Учебник § 1.1
Предварительный просмотр:
Подписи к слайдам:
Анализ предметной области
Основные вопросы анализа В чем вы видите назначение будущей системы? Какие проблемы она должна решить? Какие возможности должна предоставить? Как должна выглядеть? Известны ли вам аналогичные продукты? Будет ли система единичной или тиражируемой? В каких странах она будет работать? Предполагается ли обмен данными с другими существующими продуктами? Сколько пользователей будет работать с системой к моменту реализации и в перспективе? С какими системами и как давно вы работаете?
Анализ предметной области Подробное описание информации об объектах предметной области Формулировку конкретных задач с кратким описанием алгоритмов их решения Описание входных документов, которые должны генерироваться в системе Описание входных документов, которые служат основанием для заполнения данными
Таблица анализа Уже имеются подобные приложения Положительные стороны Отрицательные стороны Интерфейс Удобство использования Вывод
Практическое занятие № 1 Анализ предметной области Способы анализа
Предварительный просмотр:
Подписи к слайдам:
Процесс работы с требованиями Определение концепции продукта. Сбор требований. Анализ требований. Проектирование системы
Разработка этапов создания программного обеспечения
Практическая работа 2 Разработка этапов создания программного обеспечения
Предварительный просмотр:
Подписи к слайдам:
Состав технического задания Цели разработки; Требования к ПП; Сроки и этапы разработки; Регламенты.
Последовательность разработки ТЗ Устанавливается набор выполняемых функций, а также перечень и характеристики исходных данных; Определяется перечень результатов, их характеристики и способы их представления; Уточняют среду функционирования ПО
Разделы технического задания Введение 1Основание для разработки. 2 Назначение разработки. 3 Требования к программе или программному изделию. 4 Требования к программной документации. 5 Технико-экономическое обоснование. 6 Стадии и этапы разработки. 7 Порядок контроля и приемки. 8 Приложения.
Практическое занятие № 3 Разработка и оформление технического задания д/з стр. 16-17
Предварительный просмотр:
Подписи к слайдам:
Понятия Жизненный цикл Модель жизненного цикла Стратегия
Базовые стратегии разработки программных средств и систем
Недостатками неструктурированность процесса разработки программных средств; ориентация на индивидуальные знания и умения программиста; сложность управления и планирования проекта; большая длительность и стоимость разработки; низкое качество программных продуктов; высокий уровень рисков проекта.
Базовые стратегии каскадная; инкрементная; эволюционная. ГОСТ Р ИСО/МЭК ТО 15271-2002 – Информационная технология – Руководство по применению ISO/IEC 12207 (Процессы жизненного цикла программных средств) Требования к стратегии
Стратегии дизайна Структурированный дизайн Функционально-ориентированный дизайн Объектно-ориентированный дизайн Дизайн сверху вниз Дизайн снизу вверх
Дополните конспект стратегий https://studfile.net/preview/1444535/page:3/ https://coderlessons.com/tutorials/akademicheskii/programmnaia-inzheneriia/strategii-razrabotki-programmnogo-obespecheniia
Стратегии разработки программного обеспечения Учебник § 2.1
Предварительный просмотр:
Подписи к слайдам:
Этапы разработки определение стратегии; анализ; проектирование; реализация; тестирование; внедрение; использование и техническая поддержка
Методологии Каскадная модель — переход на следующий этап означает полное завершение работ на предыдущем этапе. Поэтапная модель с промежуточным контролем — разработка ПО ведется итерациями с циклами обратной связи между этапами.
Методологии Спиральная модель — особое внимание уделяется начальным этапам разработки: выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Активное программирование и его клоны — наиболее популярным для данной модели стало экстремальное программирование (extreme Programming, XP).
Экстремальное программирование (XP) Короткий цикл обратной связи (Fine-scale feedback); Непрерывный, а не пакетный процесс; Понимание, разделяемое всеми; Социальная защищенность программиста (Programmer welfare).
Короткий цикл обратной связи (Fine-scale feedback): Разработка через тестирование (Test-driven development). Игра в планирование (Planning game). Заказчик всегда рядом (Whole team, Onsite customer). Парное программирование (Pair programming).
Непрерывный, а не пакетный процесс: Непрерывная интеграция (Continuous integration). Рефакторинг (Design improvement, Refactoring). Частые небольшие релизы (Small releases).
Понимание, разделяемое всеми: Простота (Simple design). Метафора системы (System metaphor). Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership). Стандарт кодирования (Coding standard or Coding conventions).
Социальная защищенность программиста (Programmer welfare): 40-часовая рабочая неделя (Sustainable pace, Forty-hour week).
RATIONAL UNIFIED PROCESS (RUP)
Принципы Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. Ранняя идентификация и непрерывное устранение возможных рисков. Концентрация на выполнении требований заказчиков к исполняемой программе. Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. Постоянное обеспечение качества на всех этапах разработки проекта.
Сайты в помощь https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/lektsiya-1-ch3-metodologii-razrabotki-programmnogo-obespecheniya.html https://compress.ru/article.aspx?id=11321 https://issoft.by/blog/podkhody-k-razrabotke-po-kak-pravilno/ https://proglib.io/p/sdlc-modeli-kak-vybrat-pravilnyy-podhod-k-razrabotke-i-ne-zavalit-proekt-2021-05-15
Методологии программного обеспечения Учебник § 2.2
Предварительный просмотр:
Подписи к слайдам:
Каскадная модель
Реальное проектирование
V -образная модель
Модель быстрой разработки
Модель быстрой разработки
Спиральная модель
Инкрементная модель
Модель прототипирования
Многопроходная модель
Эволюционная модель
Модель пошаговой разработки
Сравнительная таблица Название модели Особенности модели Достоинства модели Недостатки модели Использование стратегии
Модели разработки программного обеспечения Учебник § 2.2 -2.6 Глава 3, конспект
Предварительный просмотр:
Подписи к слайдам:
Модель быстрой разработки
Инкрементная модель
Практическое занятие № 7 Создание моделей разработки программного обеспечения Урок 33-34
Предварительный просмотр:
Подписи к слайдам:
Модель прототипирования
Эволюционная модель
Практическое занятие № 8 Создание моделей разработки программного обеспечения Урок 35-36
Предварительный просмотр:
Подписи к слайдам:
Многопроходная модель
Модель пошаговой разработки
Практическое занятие № 9 Создание моделей разработки программного обеспечения Урок 37-38
Предварительный просмотр:
Подписи к слайдам:
Спиральная модель
Практическое занятие № 10 Создание моделей разработки программного обеспечения Урок 39-40
Предварительный просмотр:
Подписи к слайдам:
Требования Требование Первичное требование заказчика Требования к компонентам ПО
Управление требованиями Систематический подход к выявлению, организации и документированию требований к программному обеспечению Процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменения требований к программному обеспечению
Цели управления требованиями Достижение соглашения с заказчиком и пользователями о том, что должен делать программный продукт Улучшение понимания требований к программному обеспечению со стороны разработчика Установление границ программного обеспечения, т.е. определение технических требований к аппаратуре компьютера, операционной среде и возможностям программного обеспечения Определение базиса для планирования
Виды требований Функциональные требования Нефункциональные требования
Нефункциональные требования Требования к применению Требования к производительности Требования к реализации Требования к надежности Требования к интерфейсу
Анализ и структурирование первичных требования Обобщенное описание Структурирование Детализация
Моделирование предметной области Модель предметной области Предварительное моделирование
Требования к модели предметной области Формализация, обеспечивающая однозначное описание структуры предметной области Понятность для заказчиков и разработчиков на основе применения графических средств отображения модели Реализуемость, подразумевающая наличие средств физической реализации модели предметной области Обеспечение возможности оценки эффективности
Системы моделей Объектная Функциональная Техническая
Требования для подсистемы
Примерная структура процесс Нетехнические средства Т ехнические средства Организационные средства Стандарты, книги процесса Осн . характеристики пр. Данные процесса Долгосрочные и опер планы Описание позиций планов Набор задач спецификация Список ответственных АРМ Разработки программного изделия Вспомогательные тс Компьютерная сеть База данных Генеральный директор Исполнительный директор Зам ГД Группа процесса Группа обеспечения качества Проект 1 тестировщик Руководитель проекта Ведущий инженер Старший инженер инженер Проект 2
Формулировка задачи Определение спецификации Предпроектные исследования предметной области Разработка технического задания
Выбор метода решения особенности данных конкретной задачи, связанные с предметной областью (погрешность, возможные особые случаи и т. п.); требования к результатам (допустимую погрешность); характеристики метода (точный или приближенный, погрешности результатов, вычислительную и емкостную сложности, сложность реализации и т. п.).
Выбор метода решения выбор архитектуры программного обеспечения; выбор типа пользовательского интерфейса и технологии работы с документами; выбор метода разработки; выбор языка и среды программирования.
Формальная постановка задачи • анализ условия задачи; • выбор математических абстракций, адекватно, т. е. с требуемой точностью и полнотой представляющих исходные данные и результаты; • формальную постановку задачи; • определение метода преобразования исходных данных в результат, т. е. метода решения задачи.
Разработка алгоритма обобщенной схемы алгоритма – раскрывает общий принцип функционирования алгоритма и основные логические связи между отдельными модулями на уровне обработки информации (ввод и редактирование данных, вычисления, печать результатов и т. п.); детальной схемы алгоритма – представляет содержание каждого элемента обобщенной схемы.
Проектирование структур данных. вид хранимой информации каждого элемента данных; • связи элементов данных и вложенных структур; • время хранения данных структуры («время жизни»); • совокупность операции над элементами данных, вложенными структурами и структурами в целом.
Программирование Тестирование и отладка Документирование
Компоненты технологического процесса организации архитектура ТП; элементы ТП; описания жизненных циклов (ЖЦ) ПО, рекомендованных для использования в организации; руководства и критерии для настройки стандартного ТП организации; база данных (БД) ТП организации; библиотека документации, связанной с процессом разработки.
Компоненты технологического процесса проекта Описание ТП проекта Стадии ( stages ) отражают распределение усилий на разработку ПО . Задача (технологическая операция) Релизы (продукты ПО ) План разработки ПО
https://studfile.net/preview/7209950/page:13 / https:// revolution.allbest.ru/programming/00426485_0.html
Технологический процесс Учебник §3.1-3.2 Учебник §7.3-7.4
Основные этапы технологического процесса
Предварительный просмотр:
Подписи к слайдам:
Проведение обследования предметной области Метод организации локального проведения обследования Метод системного обследования объекта Индивидуальное обследование Бригадное обследование Метод сплошного обследования Выборочное обследование Последовательное проведение работ Параллельное выполнение
Составление спецификаций Описание внешней информационной среды Определение функций программного обеспечения Описание исключительных ситуаций
Конструирование прототипа Горизонтальный Вертикальный Одноразовые Эволюционные Бумажные Электронные
Процесс создания прототипа Определение начальных требований Разработка первого варианта прототипа (интерфейс) Изучение прототипа, обратная связь Переработка прототипа с учетом замечаний
Технология проектирования ПО Процесс проектирования: Проектирование общей структуры Декомпозиция компонентов и построение структурных иерархий Проектирование компонентов
Аспекты проектирования Логическое проектирование Физическое проектирование
Составляющие технологии Пошаговая процедура, определяющая последовательность технологических операций проектирования Критерии и правила, используемые для оценки результатов выполнения технологических операций Нотация (графических и технических средств)
Требования к технологии Проект должен отвечать требованиям заказчика Максимальное отражение всех этапов ЖЦ Мин затраты на проект и сопровождение Технология должна быть основой связи между проектированием и сопровождением Технология должна способствовать росту производительности проектировщика Должна обеспечивать надежность проектирования и эксплуатации Простое ведение проектной документации
Принципы построения Урок 43-44
Предварительный просмотр:
Подписи к слайдам:
Проведение обследования предметной области Метод организации локального проведения обследования Метод системного обследования объекта Индивидуальное обследование Бригадное обследование Метод сплошного обследования Выборочное обследование Последовательное проведение работ Параллельное выполнение
Составление спецификаций Описание внешней информационной среды Определение функций программного обеспечения Описание исключительных ситуаций
Конструирование прототипа Горизонтальный Вертикальный Одноразовые Эволюционные Бумажные Электронные
Процесс создания прототипа Определение начальных требований Разработка первого варианта прототипа (интерфейс) Изучение прототипа, обратная связь Переработка прототипа с учетом замечаний
Технология проектирования ПО Процесс проектирования: Проектирование общей структуры Декомпозиция компонентов и построение структурных иерархий Проектирование компонентов
Аспекты проектирования Логическое проектирование Физическое проектирование
Составляющие технологии Пошаговая процедура, определяющая последовательность технологических операций проектирования Критерии и правила, используемые для оценки результатов выполнения технологических операций Нотация (графических и технических средств)
Требования к технологии Проект должен отвечать требованиям заказчика Максимальное отражение всех этапов ЖЦ Мин затраты на проект и сопровождение Технология должна быть основой связи между проектированием и сопровождением Технология должна способствовать росту производительности проектировщика Должна обеспечивать надежность проектирования и эксплуатации Простое ведение проектной документации
Принципы построения Урок 43-44
Предварительный просмотр:
Подписи к слайдам:
Сущность объектно-ориентированного подхода Объект Класс Операция Наследование Инкапсуляция Полиморфизм
Концептуальная основа – объектная модель Абстрагирование Инкапсуляция Модульность Иерархия: - структура классов - структура объекта
Достоинства и недостатки Найти и записать в тетради
Объектно-ориентированный анализ и проектирование Алгоритмическая и объектная декомпозиции. Составные части объектного подхода. Принципы объектного подхода. Повторное использование
Типовая схема решения задач
Объекты
Задание Составить диаграмму классов для работы организации Составить диаграмму классов для работы сети интернет
Результат
Результат 2
Объектно-ориентированный подход Урок 47-48
Предварительный просмотр:
Подписи к слайдам:
Методы 1 Метод нисходящего проектирования 2 Модульное проектирование 3 Структурное программирование 4 CASE- технологии 5 Технологии RAD 6 Data Warehouse 7 Система OLAP
Метод нисходящего проектирования Метод пошаговой детализации, метод иерархического проектирования, top - down -подход Этот метод является незаменимым при разработке сложных по характеру и больших по объему программ, когда к их разработке необходимо привлекать большое число программистов, работающих параллельно
Модульное проектирование Основное понятие модуль на модуль можно ссылаться (т.е. обращаться к нему) по имени, в том числе и из других модулей; по завершении работы модуль должен возвращать управление тому модулю, который его вызывал; модуль должен иметь один вход и выход; модуль должен иметь небольшой размер, обеспечивающий его обозримость.
Структурное программирование Состоит из трёх базовых управляющих конструкций: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».
CASE- технологии Совокупность средств системного анализа, проектирования, разработки и сопровождения сложных программных систем, поддерживаемых комплексом взаимоувязанных инструментальных средств автоматизации всех этапов разработки программ.
Технологии RAD Технология быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса.
Data Warehouse Базируется на концепции создания специального хранилища данных, концепция Data Warehouse поддерживается RAD средствами разработки прикладного ПО Основные типы метаданных Data Warehouse отражают: структуру и содержимое хранилища; соответствие между исходными и выходными данными; объемные характеристики данных; критерии архивирования; отношения между данными; информацию по кодированию; интервал жизни данных и т.п.
Система OLAP Предоставляет возможность разработки информационных систем, ориентированных на yна организацию многомерных баз данных и создание корпоративных сетей, а также обеспечивает поддержку Web -технологий в сетях Internet / Intranet
Сравнительная таблица методов Название метода Принцип действия О собенности Достоинства Недостатки Вывод
Современные методы и средства разработки программного обеспечения Урок 49-50
Предварительный просмотр:
Подписи к слайдам:
Методы 1 Метод нисходящего проектирования 2 Модульное проектирование 3 Структурное программирование 4 CASE- технологии 5 Технологии RAD 6 Data Warehouse 7 Система OLAP
Метод нисходящего проектирования Метод пошаговой детализации, метод иерархического проектирования, top - down -подход Этот метод является незаменимым при разработке сложных по характеру и больших по объему программ, когда к их разработке необходимо привлекать большое число программистов, работающих параллельно
Модульное проектирование Основное понятие модуль на модуль можно ссылаться (т.е. обращаться к нему) по имени, в том числе и из других модулей; по завершении работы модуль должен возвращать управление тому модулю, который его вызывал; модуль должен иметь один вход и выход; модуль должен иметь небольшой размер, обеспечивающий его обозримость.
Структурное программирование Состоит из трёх базовых управляющих конструкций: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».
CASE- технологии Совокупность средств системного анализа, проектирования, разработки и сопровождения сложных программных систем, поддерживаемых комплексом взаимоувязанных инструментальных средств автоматизации всех этапов разработки программ.
Технологии RAD Технология быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса.
Data Warehouse Базируется на концепции создания специального хранилища данных, концепция Data Warehouse поддерживается RAD средствами разработки прикладного ПО Основные типы метаданных Data Warehouse отражают: структуру и содержимое хранилища; соответствие между исходными и выходными данными; объемные характеристики данных; критерии архивирования; отношения между данными; информацию по кодированию; интервал жизни данных и т.п.
Система OLAP Предоставляет возможность разработки информационных систем, ориентированных на yна организацию многомерных баз данных и создание корпоративных сетей, а также обеспечивает поддержку Web -технологий в сетях Internet / Intranet
Сравнительная таблица методов Название метода Принцип действия О собенности Достоинства Недостатки Вывод
Современные методы и средства разработки программного обеспечения Урок 49-50
Предварительный просмотр:
Подписи к слайдам:
Анализ предметной области Анализ предметной области начинается с выделения сущностей и определения их свойств или атрибутов; Видимые сущности представляют собой объекты предметной области, которые может распознать человек; Поддерживаемые сущности или абстрактные сущности разрабатываются проектировщиком базы данных для физической поддержки общей логической модели .
Пример Нужно разработать информационную систему по обслуживанию хранилищ, музеев, выставок и аукционов предметов живописи Предметная Область? Музей живописи
Пример. Анализ предметной области Сущности:
Пример. Анализ предметной области Атрибуты сущности ФИО Дата рождения Дата смерти Страна
Пример. Анализ предметной области Атрибуты сущности Название Автор Жанр Средства создания Дата создания Цена Отдел хранения
Пример. Анализ предметной области Атрибуты сущности Наименование
Пример. Анализ предметной области Атрибуты сущности ФИО Должность Зарплата Дата начала работы Дата окончания работы Отдел
Пример. Связи между сущностями 1 1 1 1 1: N 1: N 1 1 1
Анализ предметной области Практическая работа 11
Предварительный просмотр:
Подписи к слайдам:
Анализ предметной области Анализ предметной области начинается с выделения сущностей и определения их свойств или атрибутов; Видимые сущности представляют собой объекты предметной области, которые может распознать человек; Поддерживаемые сущности или абстрактные сущности разрабатываются проектировщиком базы данных для физической поддержки общей логической модели .
Пример Нужно разработать информационную систему по обслуживанию хранилищ, музеев, выставок и аукционов предметов живописи Предметная Область? Музей живописи
Пример. Анализ предметной области Сущности:
Пример. Анализ предметной области Атрибуты сущности ФИО Дата рождения Дата смерти Страна
Пример. Анализ предметной области Атрибуты сущности Название Автор Жанр Средства создания Дата создания Цена Отдел хранения
Пример. Анализ предметной области Атрибуты сущности Наименование
Пример. Анализ предметной области Атрибуты сущности ФИО Должность Зарплата Дата начала работы Дата окончания работы Отдел
Пример. Связи между сущностями 1 1 1 1 1: N 1: N 1 1 1
Анализ предметной области Практическая работа 11
Предварительный просмотр:
Подписи к слайдам:
Правила разработки Пишите однозначно Выводить на главной странице сайта популярные товары Пишите однозначно Взять самые покупаемые товары за неделю и показывать их на первом экране сайта в блоке популярных товаров. С возможностью добавить товар в корзину за один клик.
Правила разработки Дайте подрядчику общую информацию Помогите разобраться в терминах и нюансах Покажите конкурентов Уточните важные технические требования Распишите сценарии использования продукта
Распишите сценарии использования продукта «Требование 1. На сайте есть корзина, пользователь по дополнительному запросу может получить список дополнительных товаров» «Когда пользователь заходит в корзину, сайт показывает ему всплывающий баннер. На этом баннере должны быть товары, которые могут пригодиться покупателю. Он может одним кликом добавить любой товар к заказу. Или закрыть окно».
Шаблон действие пользователя; ответ сайта; если пользователь делает так, то сайт делает так; если пользователь делает по-другому, то сайт отвечает так….
Правила разработки Опишите требования к проверке проекта Буду проверять корректное отображение в браузерах Chrome , Firefox , Mozilla трех последних версий. Отображение на экранах мобильника с разрешением 320 px на 480 px , монитора с разрешением 1024 px на 802 px , большого монитора с разрешением… Скорость разгрузки по сервису такому-то не больше 1 секунды.
Шаблоны и примеры ТЗ ГОСТ 34 . Это еще советская разработка сбора требований для создания автоматизированных систем. Не готовый шаблон, но много вопросов к заказчику, которые помогут структурировать пожелания. IEEE 29148-2011 — стандарт разработки сложных систем, в которых есть вопросы о требовании к функциям, а также рекомендация описать условия программного окружения, то есть платформ, которые будут работать вместе с вашим продуктом. Rational Unified Process — продвинутая спецификация для разработки требований к IT-продуктам. Много внимания отводится вариантам использования . https:// www.swrit.ru/doc/gost34/34.602-2020.pdf Ориентируемся на новый ГОСТ
Разработка и оформление технического задания Практическая работа 12
информация https:// kontur.ru/articles/5945#5
Предварительный просмотр:
Подписи к слайдам:
Проектирование архитектуры программного средства Определить архитектуру разрабатываемого программного средства. Описать взаимосвязи и взаимодействия частей системы. Представить описание архитектуры программного средства, а также его внутренние взаимосвязи в виде схем, диаграмм, графов. Каждое графическое представление сопроводить соответствующими подписями и пояснениями.
Архитектурные представления
Предварительный просмотр:
Подписи к слайдам:
Сущность структурного подхода Принцип «разделяй и властвуй» Принцип иерархического упорядочивания В структурном анализе используются группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными
Методы, определяющие модели Метод SADT (метод структурного анализа и проектирования) Метод DFD (диаграммы потоков данных) Метод ERD (диаграммы сущность-связь)
Моделирование SADT Отражают взаимные связи функций, для выявления основных функций и составных частей Для моделирования предметной области, определения требований и функций Разработки ПО с данными функциями и требованиями Главный компонент Диаграмма
Диаграммы SADT модели Имя функции управление механизм результаты исходные данные
П ример Приведите свои примеры
Типы связывания Случайная Логическая Временная процедурная Коммуникационная Последовательная Функциональная Рассмотреть примеры в учебнике
Пример
Пример
Пример
Предварительный просмотр:
Подписи к слайдам:
Понятия Диаграмма потоков данных Внешняя сущность Процесс Накопитель данных
Диаграмма потоков данных Средство моделирования функциональных требований к системе – проектируемой или реально существующей Для изображения диаграмм потоков данных используют 2 вида нотации Йордана Гейна-Сарсона Таблица страница 85
Правила и советы по построению диаграмм У каждого процесса должен быть как минимум один вход и один выход. Процесс , связанный с обработкой данных, должен иметь внешний входящий поток. Стрелки не могут проходить непосредственно между хранилищами, связь между ними возможна только через какой-либо процесса. Каждый процесс должен быть связан либо с другим процессом, либо с хранилищем данных. DFD-диаграмма предусматривает возможность декомпозиции крупных процессов на подпроцессы , которые будут подробно описаны. Возможно проведение декомпозиции до 3 – 4 уровней.
Пример логической схемы
Пример физической схемы
Нулевой уровень
Более высокий уровень Видео пример https:// bpmn.pro/process/dfd
Задание Разработайте физическую и логическую схему потоков данных к своему проекту темы курсовой работы Составьте функциональную схему
Предварительный просмотр:
Подписи к слайдам:
Основные понятия Объектно-ориентированный подход Объект Класс Операция Наследование Инкапсуляция Полиморфизм
Основные понятия Объектная модель Абстрагирование Инкапсуляция Модульность Иерархия
UML моделирование Процесс моделирования и UML язык Цели разработки UML стр. 99 Общие принципы моделирования стр. 99
Словарь языка Сущность Отношения Диаграммы
Виды диаграмм Диаграмма вариантов Диаграмма классов Диаграмма поведения (состояния, деятельности) Диаграммы взаимодействия (последовательности, кооперации) Диаграммы реализации (компонентов, развертывания)
Модели языка Структурные (статические модели) Модели поведения (динамические)
Уровни моделей языка Концептуальные Логические Физические
Виды графических конструкций Значки или пиктограммы Графические символы на плоскости Пути, которые представляют собой последовательность Строки текста
Примеры
Пример
Пример
Пример
Предварительный просмотр:
Подписи к слайдам:
Процесс обеспечения качества Подготовительную работу Обеспечение качества продукта Обеспечение качества процесса Обеспечение прочих показателей качества системы (стандарт качества)
Процесс верификации Доказательство того, что ПП полностью удовлетворяет требованиям или условиям Процесс включает в себя: Подготовительную работу Собственно верификацию
Подготовительная работа Координация с другими вспомогательными процессами и планировании самого процесса верификации с учетом используемых стандартов, методов, процедур и средств.
Верификация Формальное доказательство правильности ПП Включает в себя: Анализ Оценку Тестирование
Верификация проверяет Непротиворечивость требований к системе и степень учета потребностей пользователя Возможность поставщика выполнить заданные требования Соответствие выбранных процессов жизненного цикла ПП условиям договора Адекватность стандартов, процедур и среды разработки процессам ЖЦ ПП Соответствие проектных спецификаций ПП заданным требованиям Корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д. Соответствие кода проектным спецификациям и требованиям Тестируемость и корректность кода, его соответствие принятым стандартам Корректность интеграции компонентов ПП в систему Адекватность, полнота и непротиворечивость документации
Аттестация Определение полноты соответствия заданных требований к создаваемой системе или ПП функциональному значению последних. Подтверждение и оценку достоверности проведенного тестирования ПП, что гарантирует полное соответствие ПП спецификациям, требованиям и документации.
Процесс аттестации Процесс включает в себя: Подготовительную работу Собственно аттестаци ю
Процесс совместной оценки Оценка состояния работ по проекту и ПП. Контроль за планированием и управлением ресурсами, персоналом, аппаратурой и инструментальными средствами проекта
Процесс совместной оценки Подготовительная работа Оценка управления проектом Техническая оценка
Аудит Проверка, проводимая компетентным органом в целях обеспечения независимой оценки степени соответствия ПП или проводимых работ установленным требованиям, планам, условиям договора и контракта
Процесс решения проблем Анализ и решение проблем, обнаруженных в ходе разработки, эксплуатации, сопровождения и других процессов подготовительная работа Решение проблем
Показатели качества программного обеспечения Атрибут Внешнее качество Внешняя мера Внутреннее качество Внутренняя мера Измерение Мера Метрика Модель качества Оценка качества Характеристика качества ПО Качество ПО Функциональные возможности Надежность Применимость Стр. 161 схема
Качество ПО Метрики качества стр. 163 Надежность ПО: - сбои и отказы стр.167 - обеспечение надежности ПО на разных этапах стр. 171 - оценка рисков при разработке ПО
Задание Провести оценку рисков вашего ПО, оформить отчет Дайте оценку качеству ПО
Верификация д/з стр. 12-15 Стр. 161
Предварительный просмотр:
Подписи к слайдам:
Верификация «Верификация отвечает на вопрос "Делаем ли мы продукт правильно?", а валидация — на вопрос "Делаем ли мы правильный продукт?"»
Качество ПП
Место верификации в жизненном цикле ПО Существует несколько наиболее часто используемых способов организации различных видов деятельности в рамках жизненного цикла. Их называют моделями жизненного цикла ПО, часто используют каскадную модель, в рамках одной из многочисленных разновидностей итеративной модель жизненного цикл
Задачи верификации в рамках жизненного цикла ПО - Выявление дефектов (ошибок, недоработок, неполноты и пр.) различных артефактов разработки ПО (требований, проектных решений, документации или кода ), что позволяет устранять их и поставлять пользователям и заказчикам более правильное и надежное ПО. - Выявление наиболее критичных и наиболее подверженных ошибкам частей создаваемой или сопровождаемой системы. - Контроль и оценка качества ПО во всех его аспектах. - Предоставление всем заинтересованным лицам (руководителям, заказчикам, пользователям и пр.) информации о текущем состоянии проекта и характеристиках его результатов. - Предоставление руководству проекта и разработчикам информации для планирования дальнейших работ, а также для принятия решений о продолжении проекта , его прекращении или передаче результатов заказчику.
Методы верификации программного обеспечения
Задание https:// www.ispras.ru/publications/methods_of_software_verification.pdf Изучите документ ссылки. Сравните методы с помощью таблицы. Сделайте соответствующий вывод о методах
Предварительный просмотр:
Подписи к слайдам:
Тестирование программного обеспечения Процесс исследования и проверки программного обеспечения (программного кода и документации), преследующие две различные цели: Продемонстрировать заказчику и разработчику соответствие ПП требованиям Выявить ситуации, в которых поведение ПО является неправильным, нежелательным или несоответствующим спецификации
Тестирование Проверка соответствия ПО требованиям, осуществляемая при помощи наблюдения за его работой в специальных, искусственно построенных ситуациях
Задача тестирования Построить набор ситуаций, который был бы достаточно представлен и позволял бы завершить тестирование с достаточной степенью уверенности и правильности ПО вообще, и убедиться, что в конкретной ситуации По работает правильно
Тестировщик Осуществляет поиск вероятных ошибок и сбоев в функционировании ПО, моделирует различные ситуации, которые могут возникнуть в процессе использования ПП
Стратегия тестирования Система методов отбора и создания тестов Разработка детального плана тестирования Создание наборов тестов для проверки корректности Создание отчета
Тестирование Отладка Контроль Испытание
Т ребования Высокая вероятность выявления ошибок Набор тестов не должен быть избыточным Тест не должен быть простым и слишком сложным
Методы тестирования Урок 91-92
Методы тестирования Тестирование «Черного ящика» Тестирование «Белого ящика»
Тестирование «Черного ящика» Метод тестирования функционального поведения объекта с точки зрения внешнего мира. Подбор теста для нестандартных ситуаций. Основная задача – последовательная проверка соответствия поведения системы требованиям Проверка работы системы в критичных ситуациях (неверные данные)
Проблемы системы Несоответствие поведения системы требованиям Неадекватное поведение системы в ситуациях, не предусмотренных требованиям
Метод обеспечивает Эквивалентное разбиение Анализ граничных значений Применение функциональных диаграмм
Тестирование «Белого ящика » Ориентированно на проверку прохождения всех путей программ посредством применения и имитационного тестирования Применяется на уровне модулей и графовой модели программы путем выбора тестовых ситуаций, подготовки данных
Тестирование элементов Операторов, которые должны быть выполнены хотя бы один раз, без учета ошибок, которые могут остаться в программе из-за большого количества логических путей и необходимости прохождения подмножеств этих путей
Тестирование элементов Путей по заданному графу потоков управления для выполнения разных маршрутов передачи управления при помощи путевых предикатов, для вычисления которого создается набор тестовых данных, гарантирующих прохождение всех путей
Тестирование элементов Блоков, разделяющих программы на отдельные части-блоки, которые выполняются один раз или многократно при нахождении путей в программе, включающих совокупность блоков реализации одной функции либо нахождения входного множества данных, которые будут использоваться для выполнения указанного пути
Возможности белого ящика Направленность тестирования Полный охват кода Управление потоком команд Отслеживание целостности данных
Предварительный просмотр:
Подписи к слайдам:
Тестирование программного обеспечения Процесс исследования и проверки программного обеспечения (программного кода и документации), преследующие две различные цели: Продемонстрировать заказчику и разработчику соответствие ПП требованиям Выявить ситуации, в которых поведение ПО является неправильным, нежелательным или несоответствующим спецификации
Тестирование Проверка соответствия ПО требованиям, осуществляемая при помощи наблюдения за его работой в специальных, искусственно построенных ситуациях
Задача тестирования Построить набор ситуаций, который был бы достаточно представлен и позволял бы завершить тестирование с достаточной степенью уверенности и правильности ПО вообще, и убедиться, что в конкретной ситуации По работает правильно
Тестировщик Осуществляет поиск вероятных ошибок и сбоев в функционировании ПО, моделирует различные ситуации, которые могут возникнуть в процессе использования ПП
Стратегия тестирования Система методов отбора и создания тестов Разработка детального плана тестирования Создание наборов тестов для проверки корректности Создание отчета
Тестирование Отладка Контроль Испытание
Т ребования Высокая вероятность выявления ошибок Набор тестов не должен быть избыточным Тест не должен быть простым и слишком сложным
Методы тестирования Урок 91-92
Методы тестирования Тестирование «Черного ящика» Тестирование «Белого ящика»
Тестирование «Черного ящика» Метод тестирования функционального поведения объекта с точки зрения внешнего мира. Подбор теста для нестандартных ситуаций. Основная задача – последовательная проверка соответствия поведения системы требованиям Проверка работы системы в критичных ситуациях (неверные данные)
Проблемы системы Несоответствие поведения системы требованиям Неадекватное поведение системы в ситуациях, не предусмотренных требованиям
Метод обеспечивает Эквивалентное разбиение Анализ граничных значений Применение функциональных диаграмм
Тестирование «Белого ящика » Ориентированно на проверку прохождения всех путей программ посредством применения и имитационного тестирования Применяется на уровне модулей и графовой модели программы путем выбора тестовых ситуаций, подготовки данных
Тестирование элементов Операторов, которые должны быть выполнены хотя бы один раз, без учета ошибок, которые могут остаться в программе из-за большого количества логических путей и необходимости прохождения подмножеств этих путей
Тестирование элементов Путей по заданному графу потоков управления для выполнения разных маршрутов передачи управления при помощи путевых предикатов, для вычисления которого создается набор тестовых данных, гарантирующих прохождение всех путей
Тестирование элементов Блоков, разделяющих программы на отдельные части-блоки, которые выполняются один раз или многократно при нахождении путей в программе, включающих совокупность блоков реализации одной функции либо нахождения входного множества данных, которые будут использоваться для выполнения указанного пути
Возможности белого ящика Направленность тестирования Полный охват кода Управление потоком команд Отслеживание целостности данных Видение внутренних граничных точек Тестирование белого ящика-часть процесса программирования
Классификация тестирования по уровням Модульное тестирование Структурное тестирование Интеграционное тестирование Системное тестирование Выходное тестирование Приемочное тестирование Альфа-тестирование Бета - тестирование
Тестирование производительности программного обеспечения Подходы к тестированию: Тестирование в ситуациях, разных сценариев использования В рамках бета-теста, реальным пользователем Направления тестирования: Нагрузочное тестирование Стресс-тестирование Тестирование стабильности Конфигурационное тестирование
Регрессионное тестирование Проверку исправления вновь найденного дефекта Проверку того, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова Проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код был затронут при исправлении некоторых дефектов в другой функциональности
Т естирование Глава 8
Предварительный просмотр:
Подписи к слайдам:
Интеграция Процесс разработки и внедрения программного обеспечения, с помощью которого отдельные компоненты могут быть связаны в единую систем
Главная задача процесса О беспечение безопасного и бесперебойного обмена информацией между программными продуктами, которые изначально не предназначены для совместной работы .
По теме: методические разработки, презентации и конспекты
Методическая разработка, презентация, план урока по дисциплине "Tехническое черчение" по теме "Сборочный чертеж".
Метод проектов ориентирован на самостоятельную деятельность учащихся – индивидуальную, парную, групповую, которую учащиеся выполняют в течение определенного отрезка времени. Кроме того, этот мет...
Презентация к уроку "Урок будущему первокласснику"
В данной презентации представлен материал к уроку обучения грамоте "Звук и буква О ".Материал подобран с целью познакомить детей с буквой и звуком "О"....
Конспект урока по литературному чтению ,3класс.УМК "ПНШ". Тема :"Сравнительный анализ Венгерской сказки"Два жадных медвежонка"и корейской сказки"Как барсук и куница судились"Презентация к уроку.
Конспект урока по литературному чтению ,3класс.УМК "ПНШ". Тема :"Сравнительный анализ Венгерской сказки"Два жадных медвежонка"и корейской сказки"Как барсук и куница судились"В конспекте побробно распи...
Урок Мужества. Этот День Победы. Презентация к уроку
Внеклассное мероприятие (тематический классный час). Урок мужества: Этот День Победы.... Презентация к уроку. Мероприятие направлено на формирование и развитие знаний о Великой Отечественной и В...
Урок Мужества. Этот День Победы. Презентация к уроку
Внеклассное мероприятие (тематический классный час). Урок мужества: Этот День Победы.... Презентация к уроку. Мероприятие направлено на формирование и развитие знаний о Великой Отечественной и В...
Методическая разработка урока "Идеологическая составляющая победы в Великой Отечественной войне».презентация к уроку
Интегрированный урок обществознания и истории . Разработан в 2015 году. Ориентирован на решение задач духовно-нравственного воспитания молодёжии. формирования базовых национальных ценностей....
Презентация к уроку развития речи в 5 классе по теме урока: "Подготовка к сочинению по картине Ф,П, Решетникова "Мальчишки"
Презентация к уроку развития речи в 5 классе по теме урока: "Подготовка к сочинению по картине Ф,П, Решетникова "Мальчишки". В презентации есть необходимый материал к уроку, а име...