Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (2/2) на 80 заседании Русского отделения INCOSE, 25 сентября 2013г.
Доклад Михаила Гайворонского "Опыт разработки САУ (FADEC) двигателя в соответствии с требованиями стандарта DO-178" на 115 заседании Русского отделения INCOSE, 25 мая 2016г.
Б.Позин -- катастрофоустойчивая банковская система (1/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (1/2) на 78 заседании Русского отделения INCOSE, 10 июля 2013г.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
TMPA-2015: Information Support System for Autonomous Spacecraft Control Macro...Iosif Itkin
Information Support System for Autonomous Spacecraft Control Macro-Programming
Andrew Tyugashev, Anton Nasekin, Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
Доклад Михаила Гайворонского "Опыт разработки САУ (FADEC) двигателя в соответствии с требованиями стандарта DO-178" на 115 заседании Русского отделения INCOSE, 25 мая 2016г.
Б.Позин -- катастрофоустойчивая банковская система (1/2)Anatoly Levenchuk
Доклад Бориса Позина "Опыт разработки крупномасштабной катастрофоустойчивой банковской системы" (1/2) на 78 заседании Русского отделения INCOSE, 10 июля 2013г.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
TMPA-2015: Information Support System for Autonomous Spacecraft Control Macro...Iosif Itkin
Information Support System for Autonomous Spacecraft Control Macro-Programming
Andrew Tyugashev, Anton Nasekin, Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
При разработке любого нового наукоемкого продукта требуется на стадии проектирования провести компьютерное моделирование, этому служат системы инженерного компьютерного анализа САЕ (также называемые расчетными пакетами).
Обычно такие системы для промышленного использования создаются, как универсальные, т.е. ориентированные на несколько отраслей промышленности, где необходимы такие расчеты (например, на прочность).
Все используемые в России САЕ системы западные.
Пакет прочностного анализа FIDESYS является первым российским пакетом САЕ такого уровня, и делает рынок прочностных расчетов в России (как минимум) не зависимым от пакетов САЕ зарубежных производителей, превосходит по точности и производительности, имеющиеся пакеты, и в ряде случаев пакет станет единственным на рынке.
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34Alexandra Varfolomeeva
1. СОЗДАНИЕ СТРАТЕГИИ ТЕСТИРОВАНИЯ НА ОСНОВЕ АНАЛИЗА ТЗ ПО ГОСТ 19/34
2. КОРОТКО ОБО МНЕ
3. ПОСТАНОВКА ЗАДАЧИ: формализовать требования и разработать тест-план и тестовую стратегию ДЛЯ существующей системы по готовому ТЗ, которое писал другой Исполнитель
4. ПОДЗАДАЧИ
5. СТАНДАРТЫ
6. КАК ВЫГЛЯДИТ ТЗ ПО ГОСТ
7. ОСОБЕННОСТИ ТЗ ПО ГОСТ
8. ХАРАКТЕРИСТИКИ ХОРОШЕГО ТРЕБОВАНИЯ
9. ПРИМЕР ТЗ
10. АНАЛИЗ ТЗ
11. АНАЛИЗ ТЗ
12. РЕЗУЛЬТАТ АНАЛИЗА
13. РЕЗУЛЬТАТ АНАЛИЗА
14. РЕЗУЛЬТАТ АНАЛИЗА
15. НА ЧТО ОБРАТИТЬ ВНИМАНИЕ!
16. СОЗДАНИЕ ТЕСТОВОГО ПОКРЫТИЯ
17. СТРАТЕГИЯ ТЕСТИРОВАНИЯ
18. СПАСИБО ЗА ВНИМАНИЕ!
19. КОНТАКТЫ ДЛЯ СВЯЗИ
20. ВОПРОСЫ
Лучшие практики исполнения проекта в соответствии с методологией IBM RationalLuxoftTraining
В своем выступлении Михаил рассматривает различные аспекты реализации проекта, начиная от управления требованиями и заканчивая управлением изменениями и конфигурациями. Описывает лучшие практики минимизации рисков провала проекта, в соответствии с методологией IBM Rational:
Итеративная разработка;
Подход к управлению требованиями;
Компонентная архитектура;
Визуальное моделирование;
Постоянный контроль качества;
Управление изменениями и конфигурациями.
А также рассматривается специфика Agile-проектов в сравнении с другими методологиями.
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Training objective: Introduction to requirements engineering, as well as an understanding of the role and responsibilities of an engineer on demand. Familiarization with the techniques for identifying and documenting requirements. Defining approaches to validation and requirements management.
Алексей Иванов -- курс по стыку системной и программной инженерийAnatoly Levenchuk
Доклад Алексея Иванова «Стык системной и программной инженерии в учебном курсе моделеориентированной разработки программоёмких систем» на 75 заседании Русского отделения INCOSE, 24 апреля 2013г.
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахAnatoly Levenchuk
Доклад Юрия Бабий "Опыт применения инструментария многокритериальной оптимизациии для повышения эффективности сложных технических систем" на 65 заседании Русского отделения INCOSE, 24 октября 2012г.
При разработке любого нового наукоемкого продукта требуется на стадии проектирования провести компьютерное моделирование, этому служат системы инженерного компьютерного анализа САЕ (также называемые расчетными пакетами).
Обычно такие системы для промышленного использования создаются, как универсальные, т.е. ориентированные на несколько отраслей промышленности, где необходимы такие расчеты (например, на прочность).
Все используемые в России САЕ системы западные.
Пакет прочностного анализа FIDESYS является первым российским пакетом САЕ такого уровня, и делает рынок прочностных расчетов в России (как минимум) не зависимым от пакетов САЕ зарубежных производителей, превосходит по точности и производительности, имеющиеся пакеты, и в ряде случаев пакет станет единственным на рынке.
Создание стратегии тестирования на основе анализа ТЗ по ГОСТ 19/34Alexandra Varfolomeeva
1. СОЗДАНИЕ СТРАТЕГИИ ТЕСТИРОВАНИЯ НА ОСНОВЕ АНАЛИЗА ТЗ ПО ГОСТ 19/34
2. КОРОТКО ОБО МНЕ
3. ПОСТАНОВКА ЗАДАЧИ: формализовать требования и разработать тест-план и тестовую стратегию ДЛЯ существующей системы по готовому ТЗ, которое писал другой Исполнитель
4. ПОДЗАДАЧИ
5. СТАНДАРТЫ
6. КАК ВЫГЛЯДИТ ТЗ ПО ГОСТ
7. ОСОБЕННОСТИ ТЗ ПО ГОСТ
8. ХАРАКТЕРИСТИКИ ХОРОШЕГО ТРЕБОВАНИЯ
9. ПРИМЕР ТЗ
10. АНАЛИЗ ТЗ
11. АНАЛИЗ ТЗ
12. РЕЗУЛЬТАТ АНАЛИЗА
13. РЕЗУЛЬТАТ АНАЛИЗА
14. РЕЗУЛЬТАТ АНАЛИЗА
15. НА ЧТО ОБРАТИТЬ ВНИМАНИЕ!
16. СОЗДАНИЕ ТЕСТОВОГО ПОКРЫТИЯ
17. СТРАТЕГИЯ ТЕСТИРОВАНИЯ
18. СПАСИБО ЗА ВНИМАНИЕ!
19. КОНТАКТЫ ДЛЯ СВЯЗИ
20. ВОПРОСЫ
Лучшие практики исполнения проекта в соответствии с методологией IBM RationalLuxoftTraining
В своем выступлении Михаил рассматривает различные аспекты реализации проекта, начиная от управления требованиями и заканчивая управлением изменениями и конфигурациями. Описывает лучшие практики минимизации рисков провала проекта, в соответствии с методологией IBM Rational:
Итеративная разработка;
Подход к управлению требованиями;
Компонентная архитектура;
Визуальное моделирование;
Постоянный контроль качества;
Управление изменениями и конфигурациями.
А также рассматривается специфика Agile-проектов в сравнении с другими методологиями.
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Training objective: Introduction to requirements engineering, as well as an understanding of the role and responsibilities of an engineer on demand. Familiarization with the techniques for identifying and documenting requirements. Defining approaches to validation and requirements management.
Алексей Иванов -- курс по стыку системной и программной инженерийAnatoly Levenchuk
Доклад Алексея Иванова «Стык системной и программной инженерии в учебном курсе моделеориентированной разработки программоёмких систем» на 75 заседании Русского отделения INCOSE, 24 апреля 2013г.
Юрий Бабин -- многокритериальная оптимизация в инженерных проектахAnatoly Levenchuk
Доклад Юрия Бабий "Опыт применения инструментария многокритериальной оптимизациии для повышения эффективности сложных технических систем" на 65 заседании Русского отделения INCOSE, 24 октября 2012г.
Доклад Михаила Бухарина "Разбивка на модули в архитектурном проектировании. Практика DSM (design structure matrix)" на 94 заседании INCOSE, 8 октября 2014г.
А.Левенчук -- основные альфы системной инженерии в EssenceAnatoly Levenchuk
Доклад АнатолияЛевенчука «Essence для системной инженерии: опыт моделирования» на 76 заседании Русского отделения INCOSE (совместно с Русским отделением SEMAT), 22 мая 2013г.
Talk of Ali Mousavi "Event-Modelling An Engineering Solution for Control and Analysis of Complex Systems" at 116th regular meeting of INCOSE Russian chapter, 14-Sep-2016
Tim Weilkiens - Systems engineering: consulting services, masters curriculum ...Alexander Shamanin
Tim Weilkiens (Тим Вайлькинс ) "Системная инженерия: консалтинг, магистерская программа и работа с INCOSE в Германии (oose)/ Systems engineering: consulting services, masters curriculum and INCOSE collaboration (oose
Доклад А.Левенчука "Инженерия систем с плохой модульностью и гранулярностью: предприятия, искусственные нейросети, психика" на 112 заседании Русского отделения INCOSE, 23 марта 2016г.
Вячеслав Мизгулин - Результаты работы на INCOSE WS 2017Alexander Shamanin
Доклад Вячеслава Мизгулина (к.т.н., ИТ-консультант, Доцент кафедры интеллектуальных информационных систем УрФУ, Руководитель программы магистратуры "Системная инженерия" Инженерной школы новой индустрии УрФУ, Казначей Русского отделения INCOSE)
-- Результаты работы на INCOSE WS 2017
1. Общий обзор мероприятия INCOSE WS 2017 и рефлексия "по горячим следам".
2. Стратегия INCOSE и пути развития Русского отделения INCOSE, интерес к Русскому отделению.
3. Перевод INCOSE Handbook и перспективы сертификации на русском языке, тренинги и образовательные программы.
4. Краткий обзор деятельности некоторых рабочих групп - возможность подключиться к международной деятельности:
- MBSE
- PM-SE
- Systems science
- Requirement engineering
- Agile SE and Systems science
- и т.д.
5. Методологии работы на воркшопах.
Доклад Марка Акоева (Уральский федеральный университет) "Системная динамика как вид системного мышления" на 119 заседании Русского отделения INCOSE, 26 октября 2016г.
КГТУ Лекция 2: Обеспечение Качества Программного ОбеспеченияIosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 2: Жизненный цикл ПО и технологические основы биржевой торговли
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Сергей Смирнов, Гибкая разработка ИС в рамках ГОСТScrumTrek
Предъявляемые требования к ГК (оформление, порядок работ, документирование), ограничения/препятствия
Опыт гибкой разработки ИС в рамках ГОСТ (оформление ТЗ, процесс работ, документация)
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
Тренинг "Анализ, проектирование и разработка корпоративных информационных сис...ph.d. Dmitry Stepanov
в тренинге рассматриваются типовые этапы внедрения корпоративных информационных систем: жизненный цикл системы, жизненный цикл проекта внедрения системы, методологии внедрения систем, этап подготовки, этап проектирования, этап реализации, этап подготовки к опытно-промышленной эксплуатации / опытной эксплуатации, этап ОПЭ/ОЭ, этап перехода к промышленной эксплуатации, этап ПЭ, отличие этапов, декомпозиция и вариация этапов, внедрение с нуля, тиражирование, пилотный проект, PMBoK, типовые этапы внедрения систем.
Usually, software engineering changes appear with a 10-15 year lag in systems engineering as a general practice. Therefore we can reliably predict what will be changed in the systems engineering mainstream in the nearest future and perform these practices today rather than tomorrow. There are a lot of changes: systems architecture established itself as a new separate discipline that deals with -ilities as architectural concerns/characteristics, requirements engineering disappears, manufacturing operates by developers (DevOps concept), and ubiquitous usage of continuous development and continuous delivering principles. The presentation gives an overview of these changes reflected in the "Systems engineering 2022" textbook published by Anatoly Levenchuk a couple of months ago.
Слайды лекции по современной методологии в составе интеллект-стека как идущей на смену праксиологии, на базе которой были сделаны наработки австрийской школы экономики.
Доклад А.Левенчука "SysArchi -- системное моделирование в ArchiMate 3.0" на семинаре "Дни инженерии организаций" факультета информатики, математики и компьютерных наук НИУ ВШЭ. Москва-Нижний Новгород, 11 сентября 2018
Доклад А.Левенчука "Системное мышление за пределами инженерии и менеджмента. Пример: системный фитнес" на конференции "Системный менеджмент" Школы системного менеджмента и Русского отделения INCOSE, 16 апреля 2017г.
3. EC-лизингЗатраты на сопровождение и развитие ППО АС
3
В жизненном цикле эти затраты составляют 70-80%.
Именно этот вид затрат должен быть оптимизирован.
Должны быть созданы:
•Определен порядок взаимодействия функциональных служб
(функциональных заказчиков) и ИТ – службы
•Положения и регламенты взаимодействия персонала при решении
задач сопровождения и развития
• Порядок создания и ввода в действие новых выпусков (релизов,
версий) ППО, НСИ и выпусков метаданных
• Определен состав, функции и порядок создания стендов для
отработки выпусков ППО и отработки ввода в действие новых
версий и релизов системного ПО (ОС, СУБД и т.п.)
• Автоматизированные системы сопровождения
• Обучен персонал
Это окружение эксплуатируемой системы и есть пример enabling
system, хотя могут быть и другие элементы, например, тренажёры
и т.п.
Создание системы обеспечения жизненного цикла АС позволяет
продлить срок ее службы на несколько лет (5-10 и более)
4. EC-лизинг
Состав процессов СОЖЦ
СОЖЦ
Положение по
обеспечению ЖЦ
Обеспечение
развития
Обеспечение
функционирования
Обеспечение
нефункционального
развития
(масштабирование)
Обеспечение
сопровождения
КТС и СПО
Обеспечение
сопровождения
ППО
Обеспечение
поддержки
пользователей
Обеспечение
функционального
развития
Обеспечение
эксплуатации
5. EC-лизингОбщая схема ЖЦ информационной системы:
от процесса к требованиям
Описание
бизнес-процесса
Описание
бизнес-процесса
Функциональные требования
к автоматизации бизнес-процесса
Функциональные требования
к автоматизации бизнес-процесса
Требования регламентов
к показателям назначения
АС
Требования регламентов
к показателям назначения
АС
Эксплуатационные характеристики и
автоматизированные функции АС (ИТ-сервисов)
ИТ-служба
Бизнес-подразделения
∆
Изменения
нормативной базы
Изменения
нормативной базы
Развитие и тестирование
АС и ППО АС
Развитие и тестирование
АС и ППО АС
Модернизация
АС
Модернизация
АС
Эксплуатация АСЭксплуатация АС
Сопровождение ППО АССопровождение ППО АС
5
10. EC-лизинг Задачи автоматизированного тестирования
при разработке и сопровождении
ВидыВиды
тестированиятестирования
РазработкаРазработка СопровождениеСопровождение
Функциональное Многократный контроль
корректности сборки прикладной
системы
Систематический контроль соответствия внесенных
изменений требованиям нормативных документов
Проверка правильности
реализации функций,
предусмотренных ТЗ,
Периодический контроль целостности прикладной
системы после внесения изменений по функциям и в
полном объеме требований нормативных документов
Проверка корректности
реализации интерфейсов с
конечным пользователем
Проверка корректности функционирования прикладной
системы в составе АБС на стенде сопровождения
Проверка корректности
функционирования прикладной
системы в составе АБС на стенде
Проверка корректности функционирования прикладной
системы в составе АБС на целевой платформе, близкой
к промышленной конфигурации
Нагрузочное Оценка достижимых
эксплуатационных характеристик
прикладной системы на стенде
разработчика
Оценка достижимых эксплуатационных характеристик
прикладной системы на стенде, максимально
приближенном к промышленной конфигурации
Систематический контроль деградации
эксплуатационных характеристик АБС после внесения
изменений в прикладную программную систему на
стенде, максимально приближенном к промышленной
конфигурации
11. EC-лизинг
Корректный цикл тестирования приКорректный цикл тестирования при
разработке/сопровожденииразработке/сопровождении
Система,
Программа
Система,
Программа
Y = f(X,t)
Требования
Y = f( X)
Y = f(X,t)Y = f(X,t)
Требования
Y = f( X)Y = f( X)Y = f( X)
Производственное тестирование: тестовый эксперимент
должен быть повторяемым, документируемым, проверяемым
12. EC-лизинг
Общая схема функционального тестированияОбщая схема функционального тестирования
Тестируемая программаФункциональные требования
к программе
Функциональные требования
Функциональные требования
Тестовые требования
Тестовые требования
Тестовые требования
Тестовые требования
Тестовые требования
Тестовые требования
Тестовые требования
Тестовые требования
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Результаты
прогона
тестов
Проверяемые требования
Функциональные требования
Тестовые треб.
Тестовые треб.
Тестовые треб.
Тестовые треб.
Тесты
13. EC-лизинг
Город 4Город 4
Организация работ по функциональному тестированию
ЕС-лизинг
Стенд
АБС1
Стенд
АБС1
Стенд
ИБ АБС1
Стенд
ИБ АБС1
Стенд
АБС1 на
платформе Z
Стенд
АБС1 на
платформе Z
Город 3Город 3
Стенд
АБС2
Стенд
АБС2
Город 5Город 5 РегрессионноеРегрессионное
тестированиетестирование
на платформена платформе
РегрессионноеРегрессионное
тестированиетестирование
на платформена платформе
Город 1Город 1
Город 2Город 2
Стенд
АБС2 на
платформе Z
Стенд
АБС2 на
платформе Z
ФункциональноеФункциональное
тестированиетестирование
ФункциональноеФункциональное
тестированиетестирование
ТестированиеТестирование
информационнойинформационной
безопасностибезопасности
ТестированиеТестирование
информационнойинформационной
безопасностибезопасности
Стенд
АБС1
на платформе Z
Стенд
АБС1
на платформе Z
Стенд
АБС2
на платформах
х и z
Стенд
АБС2
на платформах
х и z
14. EC-лизинг Как контролировать и прогнозировать величины
показателей назначения системы?
(«Градусник» архитектуры)
Прикладная
система
Прикладная
система
IT-
инфраструктура
IT-
инфраструктура
Поток
изменений
ПО
Поток
изменения
инфраструктуры
1.1. Динамические параметрыДинамические параметры
2. Параметры безопасности2. Параметры безопасности
3. Технико-экономические3. Технико-экономические
параметрыпараметры
1.1. Динамические параметрыДинамические параметры
2. Параметры безопасности2. Параметры безопасности
3. Технико-экономические3. Технико-экономические
параметрыпараметры
15. EC-лизинг Виды нагрузочного тестирования
Общая проблема: обеспечение адекватности результатов
тестируемой системе
Оценочное - оценка пропускной способности, времен
пребывания задач в системе
Аналитическое - выявление зависимостей (например,
производительности от вычислительных ресурсов)
Настроечное - настройка и оптимизация нагрузочных
характеристик
Регрессионное - многократное тестирование при
неизменных условиях для выявления признаков
деградации тестируемой системы
17. EC-лизинг Характеристики производительности
РеактивностьРеактивностьРеактивностьРеактивность
Характеристики производительностиХарактеристики производительностиХарактеристики производительностиХарактеристики производительности
Время ожидания обслуживанияВремя ожидания обслуживания
ПродуктивностьПродуктивностьПродуктивностьПродуктивность
ИспользованиеИспользованиеИспользованиеИспользование
Время обслуживанияВремя обслуживания
Время реакцииВремя реакции
Пропускная способностьПропускная способность
ВыработкаВыработка
Утилизация ресурсаУтилизация ресурса
Относительная пропускная
способность
Относительная пропускная
способность
Характеристики производительности всегда оцениваются статистически
18. EC-лизинг Какие выводы могут делаться по итогам
нагрузочного тестирования
• Необходимость и направления масштабирования
вычислительного комплекса
• Направления доработки ПО в «узких местах»
• Пути оптимизации настроек ОС, СУБД, другого системного ПО
• Необходимость смены вычислительной платформы
• Предложения по изменению архитектуры ПО
19. EC-лизинг Модели для нагрузочного тестирования
Модель
требований
Модель
требований
Модель
нагрузки
Модель
нагрузки
Модель
системы
Модель
системы
Модель
измерений
Модель
измерений
Цели тестирования
Характеристики и показатели,
которые надо определить.
Критерии, которым они должны
соответствовать
Объект тестирования:
какая часть системы
подвергается
тестированию
Какие параметры
надо измерять и
в каких точках
Каковы потоки
требований
к системе от
управляемого
процесса
20. EC-лизинг
Характеристики систем автоматизированного нагрузочного
тестирования АБС 1 и АБС 2
АБС 1АБС 1 АБС 2АБС 2
20052005 20062006 20072007 20082008 20092009 20102010 200200
55
20062006 20072007 20082008 20092009 20102010
Разработка программного
обеспечения (IBM Rational
Performance Tester)
Количество скриптов - - 10 25 38 56 - - 8 17 31 52
Разработка программного
обеспечения (Java)
Число строк программного
кода (генераторы)
- - 15300 32500 55000 82000 - - 17400 43700 63000 95000
Количество
сгенерированных ЭПД для
проведения нагрузочного
тестирования
Среднее количество ЭПД на
одно испытание (млн. шт.)
0,8 1,1 1,5 1,9 2,1 2,3 0,4 0,9 1,4 1,6 1,8 2,0
Частота проведения
испытаний
Количество испытаний 3 4 8 12 12 26 2 5 9 12 12 26
22. EC-лизинг
Ядро SEMAT
< применяет
(applies)
Определяют
рамкии
ограничивают
(Scopesand
constrains)>
устанавливаетпорядокреализации
(setuptoaddress)>
< определяют (identifies)
изменяет
(updates and changes) >
поддерживают(support)>
уточняет
focuses>
<
направляет/
устанавлива
ет правила
(guides)
< планирует и осуществляет
(performs and plans)
< удовлетворяет (fulfils)
используют
(useand
consume)>
<производит
(produces)
< формируют
(demand)
Работа
Work
Способ работы
(Way of Working)
Команда
Team
Требования
Requirements
Программная
система
Software System
Возможность
Opportunity
Заинтересован-
ные лица
Stakeholders
23. EC-лизинг
Пространства деятельностей
Исследовать возможности
Explore Possibilities
Обеспечить удовлетворенность
заинтересованных лиц
Ensure Stakeholder
Satisfaction
Спроектировать
систему
Shape
the System
Реализовать систему
Implement the System
Протестировать
систему
Test
the System
Развернуть систему
Deploy
the System
Использовать систему
Use the System
Использовать
систему
Operate
the System
Понять потребности
заинтересованных лиц
Understand Stakeholder Needs
Подготовиться к работе
Prepare to do the Work
Координировать
деятельность Coordinate
Activity
Поддерживать команду
Support the Team
Прекратить работу
Stop the Work
Отслеживать прогресс
Track Progress
Понять требования
Understand the
Requirements
24. EC-лизинг
Участники процесса сопровождения и зоны их
ответственности
Функциональный
заказчик
Контроль актуальности состояния ППО, обеспечивающем автоматизацию задач Банка
России в соответствии с согласованными требованиями
Задачи:
• стратегическое управление процессом сопровождения ППО АС
• определение требований к автоматизируемому бизнес-процессу
• инициация внесения изменений в ППО АС
Заказчик Обеспечение сопровождения ППО в соответствии с требованиями «Функционального
Заказчика»
Задачи:
• организация процесса сопровождения ППО
• обеспечение стратегии управления сопровождением ППО
• инициация работ по внесению изменений в сопровождаемое ППО АС в
соответствии с требованиями, поступающими от Функционального заказчика
Сопроводитель Реализация изменений ППО АС в заданный срок с приемлемым качеством
Задачи:
• обеспечение взаимодействия между участниками процесса
• тактическое и оперативное управление сопровождением
• контроль процесса сопровождения
• Служба анализа Обеспечение актуальности требований к ППО АС
Задачи:
• выявление требований к сопровождаемому ППО АС
• поддержание требований к сопровождаемому ППО АС в актуальном состоянии
• Служба
тестирования
Обеспечение качества и целостности сопровождаемого ППО.
Задачи:
• разработка и актуализация тестов ППО АС
• проведение тестирования ППО
Подрядчик Разработка/модернизация ППО АС Банка России
25. EC-лизинг
На пути к определению здоровья процесса
сопровождения
Функциональный
заказчик
Функциональные
требования
Требования
к системе
ППО
(выпуск ППО)
Типовой состав работ
по сопровождению
Порядок сопровождения
Команда
сопровождения
КлиентПродуктСлужба
сопровождения