Анализ требований к ПО

Август 6, 2022

Главная
Информатика
Анализ требований к ПО

Содержание

2. Формальная сторона 9 лк, 3 пз, 3 лб Комбинированный экзамен = 20б 2 лб – 5б,
3. Как успешно сдать курс? Сдача лабораторных работ в срок Проект выполнен ( подготовлена документация и работающая
4. Причины неудачных проектов Недостаточно адекватное управление требованиями Несогласованность требований, проектных решений и реализации Жесткая архитектура ПО
5. Отсутствие моделей при разработке ПО Не позволяет справиться с растущей сложностью разрабатываемых программных систем Не позволяет
6. Лучшие практики разработки ПО Использование визуальных моделей при разработке ПО Итеративная разработка ПО Управление требованиями Управление
7. Что такое визуальное моделирование? Визуальное моделирование есть моделирование с использованием некоторой графической нотации На входе –
8. Основные понятия визуального моделирования Нотация – система условных обозначений для графического представления визуальных моделей Семантика –
9. CASE-средства 1-е поколение: генерация схем БД (Oracle Designer 2000, ERwin) 2-е поколение: генерация программного кода (Borland
10. Визуальные модели представляют архитектуру программных систем Визуальная модель системы не должна зависеть от языка ее реализации!
11. Визуальные модели являются средством коммуникации Бизнес-аналитики, системные аналитики, архитекторы, chief information officer (CIO), management information system
12. Визуальные модели – основа многократного использования кода Моделирование охватывает существенные (основные, релевантные) аспекты структуры и поведения
13. ООП – основные понятия Объектно-ориентированное программирование (Object-Oriented Programming) — совокупность принципов, технологии и инструментальных средств для
14. ООАП – основные понятия Объектно-ориентированный анализ и проектирование (Object-Oriented Analysis/Design) — технология разработки программных систем, в
15. Классификация проектов по сложности Высокая техническая сложность Встроенные системы реального времени Распределенные высоконадежные системы Высокопроизводительные системы
16. Использование языка UML обязательно! Классификация проектов по типу приложений Проекты для использования внутри компании (IIT-проекты) Моно
17. ERP & MES системы MES (сокр. от англ. Manufacturing Execution System) — исполнительная система производства. Системы
18. ERP & MES системы их отличия ERP системы ориентированы на планирование выполнения заказов, т.е. отвечают на
19. Использование языка UML в проектах по отраслевой принадлежности Банки и инвестиционные фонды Связь и телекоммуникации Нефтегазовая
20. Взаимосвязь нотации, методологии и инструментальных средств
21. Графические нотации моделирования UML (Unified Modeling Language) – отраслевой стандарт OMG, поддерживают более 50 CASE-средств, основной
22. Взаимосвязь нотации UML, методологии и инструментальных средств + дополнительная интеграция с линейкой продуктов IBM Rational Нотация
23. Взаимосвязь нотации UML, методологии и инструментальных средств Методология ARIS House of Business Engineering (HOBE) Средство ARIS
24. Взаимосвязь нотации UML, методологии и инструментальных средств Нотация – UML 2.х Методология ALM (Application Lifecycle Management)
25. Популярные графические нотации визуального моделирования (конец 80-х гг.) ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь» DFD (Data
26. Основные разработчики языка UML (Three amigos) Grady Booch Гради Буч Dr. James Rumbaugh Джеймс Рамбо (Джим
27. История развития языка UML Спецификация языка UML 2.1.2: Суперструктура: 07-11-02.pdf – 736 стр. Инфраструктура: 07-02-04.pdf –
28. Основные разработчики языка UML 2 Don Baisley Morgan Bjorkander Conrad Bock Steve Cook Philippe Desfray Nathan
29. Определение языка UML Unified Modeling Language — унифицированный язык моделирования для описания, визуализации и документирования объектно-ориентированных
30. Назначение языка UML Предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки
31. Особенности изображения графического элементов диаграмм языка UML
32. Особенности изображения диаграмм в нотации UML Графические узлы на плоскости, которые изображаются с помощью геометрических фигур
33. Общие рекомендации по изображению диаграмм в нотации языка UML Каждая диаграмма должна служить законченным представлением соответствующего
34. Противоречивость и адекватность моделей в нотации UML Модель, соответствующая правилам нотации или семантики языка UML называется
36. Скачать презентацию

Слайд 2

Формальная сторона
9 лк, 3 пз, 3 лб
Комбинированный экзамен = 20б
2 лб

– 5б, тест – 10б, проект – 15 б = 30б
Не защищенные 2 лб в срок (до 3 лб) – не допуск к проекту!
За курс 50 б = 5 б – 2 лб + 10 б - 1 тест + 15 б – проект + 20 б экзамен (30 б во время курса и 20 б за экзамен).
Во время курса выполнение проекта.
В бригаде 4-5 чел.
Задача: к 1 пз подготовить 2-4 идеи для обсуждения со мной
На 1 пз определяем группы и разрабатываемый проект.
Каждая лб не в срок – понижение балла, если не согласовано со мной.
Сдача проекта на 3 лб.

Слайд 3

Как успешно сдать курс?
Сдача лабораторных работ в срок
Проект выполнен ( подготовлена

документация и работающая программа) к 3 лабораторной работе, готова презентация, создан демо-ролик, все докладываются излагая мысли правильно!
Экзамен написан хорошо

Слайд 4

Причины неудачных проектов
Недостаточно адекватное управление требованиями
Несогласованность требований, проектных решений и реализации
Жесткая

архитектура ПО
Нарастающая сложность ПО
Неточная и противоречивая коммуникация
Недостаточное тестирование
Субъективное отношение к приоритетам отдельных артефактов проекта
Игнорирование рисков и отсутствие процедур управления рисками
Бесконтрольное внесение изменений в артефакты проекта
Недостаточное использование CASE-средств и средств поддержки отдельных этапов проекта

Слайд 5

Отсутствие моделей при разработке ПО
Не позволяет справиться с растущей сложностью разрабатываемых

программных систем
Не позволяет эффективно управлять разработкой в условиях изменяющихся требований
Создает барьеры непонимания: аналитик не понимает руководителя проекта, разработчик – аналитика, тестировщик – разработчика и пр.
Не позволяет обеспечить контроль изменений в процессе выполнения работ
Не позволяет избежать субъективности в оценке качества разрабатываемых продуктов
Модель (model) — абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме

Слайд 6

Лучшие практики разработки ПО
Использование визуальных моделей при разработке ПО
Итеративная разработка ПО
Управление

требованиями
Управление изменениями и конфигурацией артефактов ПО
Использование компонентных архитектур
Непрерывное тестирование и верификация качества ПО
Использование паттернов проектирования
Использование CASE-средств и RAD-средств
Управление рисками:
Технологическими рисками
Связанными с требованиями
Связанными с квалификацией персонала проекта
Политическими рисками

Слайд 7

Что такое визуальное моделирование?
Визуальное моделирование есть моделирование с использованием некоторой графической

нотации

На входе –
Неструктурированная
информация

На выходе –
Модели ПО и
бизнес-процессов

Слайд 8

Основные понятия визуального моделирования
Нотация – система условных обозначений для графического представления

визуальных моделей
Семантика – система правил и соглашений, определяющая смысл и интерпретацию конструкций некоторого языка
Методология – совокупность принципов моделирования и подходов к логической организации методов и средств разработки моделей
CASE (Computer Aided Software Engineering) – методология разработки программного обеспечения, основанная на комплексном использовании компьютеров не только для написания исходного кода, но и для анализа и моделирования соответствующей предметной области
CASE-средства (CASE-tools) – программное обеспечение, которое предназначено для разработки визуальных моделей программных систем и генерации исходного кода или схемы базы данных на некотором языке

Слайд 9

CASE-средства
1-е поколение: генерация схем БД (Oracle Designer 2000, ERwin)
2-е поколение: генерация

программного кода (Borland Together Designer 2005)
3-е поколение: прямая и обратная кодогенерация (IBM Rational Rose 2002/2003, Borland Together Developer 2005, Sparx Enterprise Architect)
4-е поколение: синхронизация программного кода и моделей (IBM Rational Software Architect 6/7, Borland Together Architect 2006, Borland Development Studio 2006)

Разработка визуальных моделей сложных систем, в виду значительного объема решаемых задач, должно опираться на специальные средства программной поддержки

Слайд 10

Визуальные модели представляют архитектуру программных систем
Визуальная модель системы не должна
зависеть от

языка ее реализации!

Интерфейсы
пользователя
(Delphi,
Visual Basic,
Java, Visual Studio и т.д.)

Бизнес-логика
(C++, Java)

Базы данных
(SQL и т.д.)

Слайд 11

Визуальные модели являются средством коммуникации
Бизнес-аналитики, системные аналитики, архитекторы, chief information officer

(CIO), management information system (MIS), chief privacy officer (CPO)

Программисты, тестировщики, менеджеры проектов

Визуальные модели описывают бизнес-процессы

Визуальные модели используются для проектирования и разработки программных систем

Графическая нотация (язык UML)

Артефакты ПО

Артефакты БП

Слайд 12

Визуальные модели – основа многократного использования кода
Моделирование охватывает существенные (основные, релевантные)

аспекты структуры и поведения системы

ERP Системы

Многократно используемые компоненты
(Reusable Components)

Интернет порталы

Базы данных

Слайд 13

ООП – основные понятия
Объектно-ориентированное программирование (Object-Oriented Programming) — совокупность принципов, технологии

и инструментальных средств для создания программных систем, в основу которых закладывается архитектура взаимодействия объектов
Абстракция — характеристика сущности, которая отличает ее от других сущностей
Наследование — принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории
Инкапсуляция — сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей
Полиморфизм — свойство элементов модели с одинаковыми именами имеют различное поведение

Слайд 14

ООАП – основные понятия
Объектно-ориентированный анализ и проектирование (Object-Oriented Analysis/Design) — технология

разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов
Предметная область (domain) – часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы
Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика
Нотация канонических диаграмм является основным средством разработки моделей на языке UML

Слайд 15

Классификация проектов по сложности
Высокая техническая сложность
Встроенные системы реального времени
Распределенные

высоконадежные системы
Высокопроизводительные системы

Низкая техническая сложность
- Использование макроязыков или 4GL
- Реинжиниринг приложений баз данных
- Разработка учетно-расчетных приложений

Высокая
сложность
управления
- Большой масштаб
- Контрактные заказы
- Много пользователей
- «Проекты»

Низкая
сложность
управления
- Малый масштаб
- Неформальные заказы
- Один пользователь
- “Продукты”

Использование языка UML не обязательно

Использование языка UML обязательно!

Слайд 16

Использование языка UML обязательно!
Классификация проектов по типу приложений
Проекты для
использования внутри
компании

(IIT-проекты)

Моно
пользовательские
приложения

Проекты в интересах
внешнего заказчика,
аутсорсинг
(EIT-проекты)

Проекты разработки
«коробочных»
Приложений
(ISV-проекты)

Web-
приложения

Встроенные
Системы
мониторинга

ERP & MES
Системы

Слайд 17

ERP & MES системы
MES (сокр. от англ. Manufacturing Execution System) — исполнительная система

производства. Системы такого класса решают задачи синхронизации, координируют, анализируют и оптимизируют выпуск продукции в рамках какого-либо производства.
ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства) — организационная стратегия интеграции производства и операций) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности.
ERP-система — конкретный программный пакет, реализующий стратегию ERP.

Слайд 18

ERP & MES системы их отличия
ERP системы ориентированы на планирование выполнения заказов, т.е.

отвечают на вопрос: когда и сколько продукции должно быть произведено?
MES-системы фокусируются на вопросе: как в действительности продукция производится? и оперируют более точной информацией о производственных процессах.

Слайд 19

Использование языка UML в проектах по отраслевой принадлежности
Банки и инвестиционные фонды
Связь

и телекоммуникации
Нефтегазовая промышленность
Страховые фонды
Энергетика
Машиностроение
Торговля
Фармацевтическая промышленность
Оборонная промышленность
Федеральная таможенная служба
Учебные заведения

Средний проект по разработке ПО:
5-10 человек
10-15 месяцев
10-15 внешних интерфейсов
Незначительная неопределенность и риски

Слайд 20

Взаимосвязь нотации, методологии и инструментальных средств

Слайд 21

Графические нотации моделирования
UML (Unified Modeling Language) – отраслевой стандарт OMG, поддерживают

более 50 CASE-средств, основной инструмент IBM Rational Rose/ IBM RSA (IBM Rational Software)
IDEF – семейство нотаций, стандарт МО США, рекомендован Правительством РФ для применения в государственных учреждениях, основной инструмент AllFusion Pricess Modeller (Computer Associations)
ARIS (ARchitecture of Integrated Information Systems) – методология и нотация для профессионального моделирования бизнес-процессов, инструмент ARIS Toolset (IDS Scheer AG)

Слайд 22

Взаимосвязь нотации UML, методологии и инструментальных средств
+ дополнительная интеграция с линейкой

продуктов IBM Rational

Нотация – UML 1.х

Методология - RUP

Средство – IBM Rational Rose

Best Practices

Слайд 23

Взаимосвязь нотации UML, методологии и инструментальных средств
Методология
ARIS House
of Business
Engineering (HOBE)
Средство
ARIS Toolset
Методология
MSF

(Microsoft Solutions Framework)

Средство
MS Visual Studio/.NET

Нотация – UML 1.х

варианты

Слайд 24

Взаимосвязь нотации UML, методологии и инструментальных средств
Нотация – UML 2.х
Методология
ALM (Application
Lifecycle
Management)
Средство
Borland

Together Architect 2006

Нотация - UML 2.х

Методология
RUP

Средство
IBM Rational Software Architect

варианты

Слайд 25

Популярные графические нотации визуального моделирования (конец 80-х гг.)
ERD (Entity-Relationship Diagrams) –

диаграммы «сущность-связь»
DFD (Data Flow Diagrams) – диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем
STD (State Transition Diagram) – диаграммы перехода состояний для проектирования систем реального времени
SADT (Structured Analysis and Design Technique) – технология структурного анализа и проектирования
ICAM (Integrated Computer Aided Manufacturing) – интегрированное компьютерное производство
FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции
Структурные карты Джексона и Константайна – проектирование межмодульных взаимодействий и внутренней структуры объектов

Слайд 26

Основные разработчики языка UML (Three amigos)
Grady Booch
Гради Буч
Dr. James Rumbaugh
Джеймс Рамбо
(Джим Румбах)
Dr.

Ivar Jacobson
Айвар Джекобсон
(Ивар Якобсон)

OMG (Object Management Group) — название консорциума, созданного в 1989 году для разработки индустриальных стандартов с их последующим использованием в процессе создания масштабируемых неоднородных распределенных объектных сред.
В настоящее время входит более 800 софтверных компаний
Официальный сайт: www.omg.org

Слайд 27

История развития языка UML
Спецификация языка UML 2.1.2:
Суперструктура:
07-11-02.pdf – 736 стр.
Инфраструктура:

07-02-04.pdf – 218 стр.
Object Constrain Language v.2.0:
2005-06-06.pdf – 185 стр.
Diagram Interchange:
03-07-03.pdf – 34 стр.
Model Driven Architecture
03-06-01.pdf – 62 стр.

Слайд 28

Основные разработчики языка UML 2
Don Baisley
Morgan Bjorkander
Conrad Bock
Steve Cook
Philippe Desfray
Nathan Dykman
Anders

Ek
David Frankel
Eran Gery
Oystein Haugen
Sridhar Iyengar

Cris Kobryn
Birger Moller-Pedersen
James Odell
Gunnar Overgaard
Karin Palmkvist
Guus Ramackers
Jim Rumbaugh
Bran Selic
Thomas Weigert
Larry Williams

Слайд 29

Определение языка UML
Unified Modeling Language — унифицированный язык моделирования для описания,

визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования
Язык UML предоставляет стандартный способ написания проектной документации на системы, включая концептуальные аспекты, такие как бизнес процессы и функции системы, а также конкретные аспекты, такие как выражения языков программирования, схемы баз данных и повторно используемые компоненты ПО

Язык UML не является методологией
Язык UML не является процессом
Язык UML не является языком программирования
Язык UML не является формальным языком

UML = нотация + семантика !

Слайд 30

Назначение языка UML
Предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования,

специально предназначенный для разработки и документирования моделей сложных систем различного целевого назначения
Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области
Графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования
Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП
Способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств
Интегрировать в себя новейшие и наилучшие достижения практики ООАП

Слайд 31

Особенности изображения графического элементов диаграмм языка UML

Слайд 32

Особенности изображения диаграмм в нотации UML
Графические узлы на плоскости, которые изображаются

с помощью геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML
Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические узлы
Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы, которая не может увеличивать свои размеры, чтобы разместить внутри себя дополнительные символы.
Строки текста. Служат для представления различных видов информации в некоторой грамматической форме.

Слайд 33

Общие рекомендации по изображению диаграмм в нотации языка UML
Каждая диаграмма должна

служить законченным представлением соответствующего фрагмента моделируемой предметной области
Все сущности на диаграмме модели должны быть одного концептуального уровня
Вся информация о сущностях должна быть явно представлена на диаграммах
Диаграммы не должны содержать противоречивой информации
Диаграммы не следует перегружать текстовой информацией
Каждая диаграмма должна быть само достаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов

Слайд 34

Противоречивость и адекватность моделей в нотации UML
Модель, соответствующая правилам нотации или

семантики языка UML называется непротиворечивой (well-formed model)
Модель, нарушающая правила нотации или семантики языка UML называется противоречивой (ill-formed model)
Здесь могут быть использованы формальные критерии – соответствие спецификации языка UML!
Модель, достаточно полно и правильно отражающая предметную область или решаемую проблему называется адекватной
Модель, не достаточно полно или неправильно отражающая предметную область или решаемую проблему называется не адекватной
Здесь могут быть использованы только неформальные критерии – субъективное мнение экспертов!
Моя модель – это не ваша модель, а ваша модель – не моя… (Мартин Фаулер «UML в кратком изложении»)

Анализ требований к ПО

Содержание

Формальная сторона9 лк, 3 пз, 3 лбКомбинированный экзамен = 20б2 лб

Как успешно сдать курс?Сдача лабораторных работ в срокПроект выполнен ( подготовлена

Причины неудачных проектовНедостаточно адекватное управление требованиямиНесогласованность требований, проектных решений и реализацииЖесткая

Отсутствие моделей при разработке ПОНе позволяет справиться с растущей сложностью разрабатываемых

Лучшие практики разработки ПОИспользование визуальных моделей при разработке ПОИтеративная разработка ПОУправление

Что такое визуальное моделирование?Визуальное моделирование есть моделирование с использованием некоторой графической

Основные понятия визуального моделированияНотация – система условных обозначений для графического представления

CASE-средства1-е поколение: генерация схем БД (Oracle Designer 2000, ERwin)2-е поколение: генерация

Визуальные модели представляют архитектуру программных системВизуальная модель системы не должназависеть от

Визуальные модели являются средством коммуникацииБизнес-аналитики, системные аналитики, архитекторы, chief information officer

Визуальные модели – основа многократного использования кодаМоделирование охватывает существенные (основные, релевантные)

ООП – основные понятияОбъектно-ориентированное программирование (Object-Oriented Programming) — совокупность принципов, технологии

ООАП – основные понятияОбъектно-ориентированный анализ и проектирование (Object-Oriented Analysis/Design) — технология

Классификация проектов по сложностиВысокая техническая сложность Встроенные системы реального времени Распределенные

Использование языка UML обязательно!Классификация проектов по типу приложенийПроекты для использования внутрикомпании

ERP & MES системыMES (сокр. от англ. Manufacturing Execution System) — исполнительная система

ERP & MES системы их отличияERP системы ориентированы на планирование выполнения заказов, т.е.

Использование языка UML в проектах по отраслевой принадлежностиБанки и инвестиционные фондыСвязь