Управление программным проектом (УПП)



Процесс создания ИС

1. Программная инжинерия (SE)

-Является отраслью компьютерной науки,

-изучает вопросы построения программ для компьютеров,

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

-Охватывает все аспекты создания ПО, начиная от концептуального и бизнес-анализа до создания, сопровождения и снятия с эксплуатации ПО,

-а также оценку трудозатрат, производительности и качества.

2. Проект в SE

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

3. Процесс, методология разработки ПО

-Американский словарь Miriam-Webster:

"ряд связанных между собой методов или техник".

-Оксфордский словарь:

"изучение методов".

-Толковый словарь русского языка" Ожегова:

"принципы и способы организации теоретической и практической деятельности" ;

"совокупность методов, применяемых в какой-либо науке".

-А.Коберн:

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

4. Каскадный

Анализ- проектирование-реализация- внедрение-сопровождение

5. Спиральный

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

6. Инкрементный

-Инкремент = приращение.

-Разработка начинается с предоставления набора требований и реализации системы путем последовательного конструирования и фиксации промежуточных продуктов (1, …, N) системы, постепенно приближающейся к итоговой системе.

7. Гибкий.

-Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов

-Работающее программное обеспечение ВЫШЕ всесторонней документации

-Сотрудничество с клиентами ВЫШЕ переговоров по контракту

Реакция на изменения ВЫШЕ следования плану

8. Продукт SE

Продукт (в данном контексте программный продукт) является выходом процесса.

9. Артефакт SE

10. Жизненный цикл ПО

Жизненный цикл АИС - это непрерывный процесс, который начинается с момента принятия решения о необходимости ее создания и заканчивается в момент полного изъятия из эксплуатации.

11. Вид деятельности SE

 

 

12. Работник

13. Этап

14. Стадия (фаза)

15. Итерация

16. Веха

17. Выпуск

18. RUP

19. ISO IEC 12207

-Процесс

- Работа

- Задача

 

20. Компоненты методологии разработки ПО

 

 

 

 

21. Виды деятельности SE (перечень)

-Формирование видения

-Бизнес-анализ

-Анализ требований

-Разработка архитектуры

-Тестирование

-Управление проектом

-Управление средой

-Управление конфигурацией

-Управление требованиями

-Усовершенствование

-Детальное проектирование

-Реализация

-Экспертиза (испытание)

-Документирование

-Обучение

-Внедрение

-Эксплуатация

-Сопровождение

22. SWEBOK

-Американское объединение компьютерных специалистов ACM (AssociationforComputingMachinery)

-Компьютерный союз при институте инженеров по электронике и электротехнике (IEEE ComputerSociety).

-Объединенными усилиями подкомиссий этого комитета было создано ядро SWEBOK (1999 г.)

23. MSF

24. XP

Бизнес-анализ

1. Бизнес-анализ (анализ деловых процессов)

2. Моделирование бизнес-процессов

-Общего назначения (SADT, IDEF5, IDEF2,…)

-Направленные на улучшение бизнес-процессов (SWOT, BPR, CPI/TQM,…)

-Направленные на автоматизацию предприятий (ARIS, DFD, IDEF3, BSP,…)

3. Совершенствование бизнес-процессов

-Категориимоделей и методов (М&М)

-Дляанализа иулучшенияорганизационнойсистемы

-М&М общегоназначения

-М&М,предназначенныедля использованияпри автоматизации

4. Бизнес-процесс

Бизнес-процесс(деловой процесс, БП) – это логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности организации, направленный на достижение поставленных целей.

Согласно ISO9000,БП – это совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы, представляющие ценность для потребителя

5. Основной БП

Основными БП являются процессы, добавляющие ценность для потребителя.

Они ориентированы на производство товаров или оказание услуг, составляющих основную деятельность организации и обеспечивающих получение дохода.

6. Вспомогательный БП

Вспомогательные (обеспечивающие, инфраструктурные) бизнес-процессы

не добавляют ценность продукта или услуги для потребителя,

но увеличивают их стоимость.

Они необходимы для деятельности предприятия и предназначены для поддержки выполнения основныхбизнеспроцессов.

Примеры:

Бухгалтерский учет, обеспечение кадрами, юридическое обеспечение, администрирование, обеспечение безопасности, поставка комплектующих и материалов, ремонт и техническое обслуживание.

7. Модель "как есть"

8. Модель "как надо"

9. DFD

10. ARIS

Организационная. Определяет структуру организации — иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений;

Функциональная. Определяет функции, выполняемые в организации;

Подсистемы входов/выходов. Определяют потоки используемых и производимых продуктов и услуг;


Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным);

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

Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса;

Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства;

Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации;

Подсистема расположения организационных структур. Описывает территориальное расположение организационных единиц.


Для устранения избыточности методология ARIS ограничивает число типов представлений пятью:

организационные модели, описывающие иерархическую структуру системы — иерархию организационных подразделений, должностей, полномочий конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений;

функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

модели входов/выходов, описывающие потоки материальных и нематериальных входов и выходов, включая потоки денежных средств.

11. BSP

Методика BSP, BusinessSystemPlanning (Мартин) определяется как “подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшие и перспективные информационные потребности”.

Требования

1. Требование

Требование – это условие или возможность, которой должна соответствовать система

Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы

2. Классификация по предмету (требование к чему?)

Виды требований: требования к продукту, требования к проекту.

3. Классификация по уровню

     Обычно выделяют три уровня требований.

· На верхнем уровне представлены так называемые бизнес-требования. Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

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

· 3 уровень – функциональный. Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

4. Функциональные и нефункциональные требования

Функциональные требования задают “что” система должна делать;

Нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) UseСase.

Функциональные требования регламентируют функционирование или поведение системы.

Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы.

5. Системные требования и требования к ПО

Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.

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

6. Свойства требований

7. Полнота

-Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования.

-Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.

8. Ясность

  • Синонимы:

ü недвусмысленность,

ü определённость,

ü однозначность спецификаций.

  • Требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы

9. Корректность

  • Свойство корректности задаёт дихотомию: требование либо корректно, либо нет.
  • Корректное требование –

ü непротиворечивое,

ü обеспечивающее требуемую точность,

ü обеспечивающее связь с источниками

10. Согласованность

  • Вертикальная согласованность:

ü непротиворечивость требованиям родительского уровня иерархии.

Горизонтальная согласованность:

ü непротиворечивость требованиям своего уровня иерархии.

11. Верифицируемость

  • Верифицируемость означает пригодность к проверке.
  • Основано на:

ü ясности,

ü полноте,

ü трассируемости.

12. Необходимость

Необходимыми следует считать свойства, без выполнения которых невозможно, либо затруднено выполнение автоматизированных бизнес-функций пользователей;

13. Осуществимость

  • Выполнимость требования определяется комбинацией следующих факторов:

ü технической возможностью осуществления;

 разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами.

14. Полезность

Полезными при эксплуатации следует считать любые свойства, повышающие применимость продукта.

15. Трассируемость

Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.)

Различают трассируемость в прямом и обратном направлениях.

16. Упорядоченность по важности и стабильности

Приоритет требования представляет количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.

Стабильность требования характеризует прогнозную оценку неизменности требований во времени.

17. Наличие количественной метрики

Количественные метрики играют важную роль в верификации и аттестации информационных систем.

В первую очередь это относится к нефункциональным требованиям, которые, как правило, должны иметь под собой количественную основу

Функциональные требования также могут расширяться количественными мерами, например при помощи аспектов применимости

Процесс требований

1. Совладелец, заинтересованное лицо (stakeholder)

Тот кто совместно с кем либо владеет чем либо. Заинтересованное лицо- лицо или группа лиц с общей заинтересованностью в работе организации-поставщика и условиях, в которых она действует. Участник совместного дела.

2. Цели потока работ "Требования"

RUP предлагает следующие цели для потока работ АТ:

  • добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
  • дать разработчикам наилучшее понимание требований к системе;
  • определить границы системы;
  • определить интерфейс пользователя и системы.

3. Виды работ с требованиями

-Формирование видения

-Выявление требований

-Классификация и спецификация требований

-Расширенный анализ требований (моделирование и прототипирование)

-Документирование требований

-Проверка требований

-Управление требованиями

-Совершенствование процесса работы с требованиями

4. Формирование видения

Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно "увидеть" в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить.

5. MSF - Видение и Рамки

Видение – это ничем не ограничиваемое представление о том, каким должно быть решение

Рамки же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

Согласно белой книге MSF, на фазе выработки концепции (envisioningphase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения.

Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования.

MicrosoftSolutionsFramework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. MSF представляет собой согласованный набор концепций, моделей и правил.

6. Выявление требований

Стратегии выявлений требований: интервью, анкетирование, наблюдение, самостоятельное описание требований, совместные семинары, прототипирование.

Источники требований:

- документы: описывающие предприятия, эталонные модели.

-результаты наблюдений

-результаты опроса: представители заказчика, внешние эксперты.

7. Классификация (упорядочение) требований

  • Функциональные и нефункциональные требования
  • Внутренние (с другими требованиями) или внешние зависимости
  • Требования к процессу или продукту
  • Приоритет требований
  • Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения
  • Изменяемость/стабильность требований

8. Требования совладельцев

  • Результатом выявления требований является реестр требований.
  • Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации.

9. Реестр требований

Результатом выявления требований является реестр требований. Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации.

10. Актор

Актор – это некто или нечто, обладающее активностью по отношению к программной системе.

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

11. Вариант использования (прецедент)

Вариант использования (прецедент) в первом приближении можно рассматривать, просто, как функцию, реализуемую системой.

вариант использования должен быть полезен конкретномуактору.

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

12. Форматы описания usecase

13. Глосссарий

Служит основой для единообразного понимания описаний требований Заказчиком и Разработчиком.

Является отправной точкой для построения более развёрнутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).

Оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем.

Иногда проблемную область целесообразно сегментировать на ряд «подобластей» (subjectareas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

 

14. Описание нефункциональных требований

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

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

В случае, если нефункциональные требования носят общий характер, они выносятся в документ «Дополнительная спецификация».

15. Атрибуты требований

Атрибуты требований описываются матрицей атрибутов требований, где для каждого типа требований перечисляются требования по одной оси и атрибуты требований этого типа по другой.

Для каждого требования указываются значения его соответствующих атрибутов.

Примеры атрибутов: статус во времени, приоритет, важность, риск, № итерации (этапа) в плане.

16. Использование моделей при анализе требований

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

Во-вторых, анализ требований должен находить ответ на то, ЧТО делает система, абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим, диаграмма взаимодействия объектов, реализующих тот или иной вариант использования, можно рассматривать скорее, как иллюстрацию внутреннего устройства системы, полезную для программиста, чем модель для заказчика.

17. Использование прототипов при анализе требований

Параллельно с вариантами использования рекомендуется применять прототипы разрабатываемой системы.

 

Процесс требований – ii

1. Цели прототипирования

Основные цели, требующие применения прототипов.

· прояснить неясные требования к системе;

· выбрать одно из различных концептуальных решений;

· проанализировать осуществимость.

2. Горизонтальный прототип

моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных.

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

Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований.

3. Вертикальный прототип

Вертикальный или структурный прототип (verticalprototype, structuralprototype) не ограничивается интерфейсом пользователя.

Он реализует вертикальный «срез» системы, затрагивая все уровни её реализации.

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

Основные цели применения такого рода прототипов – анализ применимости, проверка архитектурных концепций.

4. Одноразовый прототип

Одноразовый или исследовательский прототип (throwawayprototype, exploratoryprototype) создаётся, когда нужно быстропромакетировать те или иные аспекты и компоненты системы.

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

В результате получается «сырой» код, который может содержать значительное количество дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого рода прототипы, не стали частью целевой системы.

5. Эволюционный прототип

Эволюционный прототип (evolutionaryprototype) создаётся, как первое приближение системы, призванное стать впоследствии самой системой.

Код эволюционного прототипа должен последовательно, в течении одной или более итераций, перерасти в код целевого приложения.

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

скрупулёзной разработки, применения технологических методов и приёмов, тестирования результатов и т.п.

6. Раскадровка

Виды: пассивная, активная, интерактивная.

Пассивная:

-Презентация, изготовленные при помощи средств электронного офиса (например, комбинации MicrosoftVisio и MicrosoftPowerPoint).

-В этом случае пользователь лишён свободы выбора, предоставляемой ему поведенческим прототипом.

-Но идею пошаговой смены экранов в процессе реализации сценария варианта использования вполне можно реализовать.

Активнаяраскадровка является дальнейшим развитием понятия пассивной раскадровки, с применением средств анимации и т.п.

Интерактивнаяраскадровка представляет собой электронный одноразовый горизонтальный прототип.

7. Бумажный прототип

Бумажный прототип (paperprototype) – отличная альтернатива рассмотренным выше разновидностям электронных прототипов в случае, когда Разработчик ограничен в ресурсах.

Его достоинства:

  • 1. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.
  • 2. Заказчик никогда не скажет, глядя на бумажный интерфейс: «Да вы, я вижу, уже создали систему на 85%! Давайте закончим её в течении недели».

8. Аспекты применимости :

Иллюстрированные сценарии прецедентов содержат дополнительные сведения – аспекты применимости, помогающие Разработчику лучше понять специфику проблемной области.

Аспект применимости – информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя.

9. Ориентиры

Ориентиры – это описание опциональных функциональных возможностей системы. Отсутствие таких возможностей не приводит к фатальной неудаче. Присутствие – улучшает применимость, снабжая полезной информацией. Ориентиры следует расценивать не как требования, а как пожелания или рекомендации.

10. Средние значения атрибутов и объемы объектов

Данная информация позволяет оптимальнее построить пользовательский интерфейс и оценить на ранних стадиях проекта «узкие места» в обработке данных, которые могут повлиять на производительность системы.

Так, при выборе из 2 возможностей лучше подойдёт элемент управления checkbox, при выборе, ограниченном 2-3 десятками позиций – выпадающий список, при многообразии, измеряемом тысячами вариантов, потребуются дополнительные средства фильтрации и поиска.

11. Средняя интенсивность использования

Средняя интенсивность использования позволяет выделить сценарии «массового» использования, в которых всё должно быть идеально (быстродействие, удобство пользования, минимум действий на выполнение операций). Например – интерфейс кассира в супермаркете.

Другая крайность – сценарии, выполняемые от случая к случаю, не каждый день и не требующие особой оперативности (например, расчёт заработной платы за месяц). Эти данные позволяют, структурировать подачу информации, убрать из «главных» интерфейсов редко используемые опции и т.п.

12. Документирование требований

13. Техническое задание, ГОСТ РФ

14. SRS, RUP

15. Проверка требований

-Требования должны удовлетворять свойствам требований

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

-Требования к ПО точно отражают системные требования, бизнес-правила и др.

-Требования обеспечивают качественную основу для проектирования и сборки ПО

16. Верификация

    1. verusверный => “правильность”
    2. отвечает на вопрос:«правильно ли мы делаем работу?»

a. Верификация – проверка продукта на соответствие входным данным(~ проектным требованиям, спецификациям

17. Валидация

    1. validusздравый=> “польза, ценность”
    2. отвечает на вопрос:«правильную ли работу мы делаем?»
    3. Валидация – проверка продукта на соответствие потребностям пользователя

Валидация как процесс оценивания системы или компонента во время или по окончании процесса разработки с целью определить, удовлетворяет ли она указанным требованиям.

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

ООП, введение в UML

1. Структурное программирование (Дийкстра)

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

¨ структуру последовательного действия,

¨ структуру выбора одного из двух действий

¨ структуру цикла, то есть многократного повторения некоторого действия с проверкой условия остановки повторения.

Недостатки структурного подхода

-Данные не защищены от неправильного использования.

-Расширение функциональных требований приводит

¡ к модификации кода;

¡ к созданию нового кода «с нуля».

-Требование уникальности имен приводит

¡ к конфликтам имен;

¡ к использованию различных имен для похожих операций.

2. Модульное программирование и проектирование

Основная идея: разбиваем сложную задачу на подзадачи, каждую из них при необходимости разбиваем снова и т.д.

Получаем простые задачи, их решаем, объединяем.

Модульное П/П – специфичный для задачи базис из модулей.

¡ Более высокий уровень абстракции.

¡ Настройка на конкретную задачу.

¡ Возможности повторного использования.

¡ Возможности коллективной разработки – разделение труда.

Недостатки модульного программирования

Модули вынуждены модифицировать данные за пределами своей области видимости, что приводит к зависимости модулей (coupling) и сложности тестирования и сопровождения.

3. Объектно-ориентированный подход

-Дальнейшая борьба со сложностью.

-Технология работает, начиная с этапа анализа.

-Анализ – Проектирование – Программирование.

-В основе – объектная модель и объектная декомпозиция.

¨ Основные принципы объектной модели:

¡ абстракция;

¡ инкапсуляция;

¡ иерархичность (наследование, агрегация);

¡ полиморфизм;

¡ модульность.

¨ Объектная декомпозиция (в отличие от алгоритмической): элементы проекта – классы и объекты (а не алгоритмы).
И только потом данные и алгоритмы.

4. абстракция;

Модель есть упрощение исходного объекта

Абстракция = выделение необходимых свойств объекта

Необходимость набора свойств определяется решаемой задачей

Однотипные объекты, обладающие одинаковыми наборами характеристик, объединяются в группы

В ООП такие группы называются Классами

Объект = экземпляр класса

5. инкапсуляция;

А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение.

Отделение внешних обязательств объекта от его реализации.

Б) Сокрытие внутренней структуры данных и реализации методов объекта от остальной программы.

Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие

6. иерархичность (наследование, агрегация);

Объект - этоэкземпляркласса.

В качестве экземпляра класса объект обладает всеми характеристиками своего класса

Наследовать могут не только объекты, но и классы.

Наследование – уточнение задаваемого множества объектов.

Более общий класс – «базовый» класс или «суперкласс».

Более частный класс – наследник.

Агрегация.

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

7. полиморфизм;

«Один интерфейс – много реализаций»

Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса.

Виды полиморфизма:

    1. Переопределение
    2. Перегрузка

Переопределение методов (override): в унаследованном классе можно переопределить метод базового класса.

Перегрузка методов (overload): один и тот же класс может иметь методы с одинаковыми именами, но разными сигнатурами.

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

8. Компонентный подход

Компонентный подход – развитие объектно-ориентированной идеологии.

Введен следующий уровень абстракции – классы объединяются в компоненты.

Основной принцип компонентного подхода: сборка приложения из готовых компонент, в общем случае написанных на разных языках

¨ Компонент:

¡ программный код в виде самостоятельного модуля

¡ м.б. использован в неизменном виде

¡ может допускать настройку

¡ обладает поведением (функциональностью).

¨ Компонент изолирован от внешнего мира своим интерфейсом – набором методов (их сигнатурами).

¨ Компонентная программа – набор независимых компонент, связанных друг с другом посредством интерфейсов.

9. UML

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

10. Логические диаграммы

Логические диаграммы, графический аппарат математической логики. Отношения между классами (объёмами понятий) с тех пор принято изображать с помощью систем взаимно пересекающихся кругов (или любых других односвязных областей); объединению классов соответствует при этом объединение изображающих их областей, пересечению — пересечение, дополнению (до универсального класса) — дополнение до некоторой "стандартной" объемлющей области. Отношению включения между изображаемыми классами при этом соответствует одноимённое отношение между их изображениями (причём случаи, когда объемлющий класс совпадает с объемлемым и когда он существенно шире последнего, здесь не различаются).

11. Диаграмма классов

Служит для представления статической структуры модели системы

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

Не указывает информацию о динамике функционирования системы.

12. интерфейс (в ООП)

Внешний вид класса, объекта или модуля, выделяющий его существенные черты и не показывающий внутреннего устройства и внутренних механизмов поведения

13. Виды отношений между классами

-ассоциация (именованная связь)

-зависимость (изменения в одном классе приводят к изменениям в другом)

-обобщение / генерализация (родовидовое отношение)

-агрегация (отношение «часть-целое»)

-композиция (отношение «часть-целое» », однозначно регламентирующее количество и состав частей целого)

14. диаграмма пакетов

Диаграммы пакетов унифицированного языка моделирования(UML) отображают зависимости между пакетами, составляющими модель.

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

Диаграмма пакетов показывает пакеты и зависимости между ними.

15. Usecase– диаграмма

Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) — диаграмма, на которой отраженыотношения, существующие между акторами и прецедентами.

Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю иразработчику совместно обсуждать функциональность и поведение системы.

При работе с вариантами использования важно помнить несколько простых правил:

§ каждый прецедент относится как минимум к одному действующему лицу;

§ каждый прецедент имеет инициатора;

§ каждый прецедент приводит к соответствующему результату (результату с «бизнес-значением»).

16. Диаграмма деятельности

Основныекомпоненты описания системы:

-Функции (действия)

-Символы «старт» и «стоп»

-Потоки управления

-Разветвители

-Линейки синхронизации

Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности.

Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями.

17. Диаграмма состояний

Основные компоненты описания системы:

-Простые состояния,

-Составные состояния,

-Символы «старт» и «стоп»,

-Переходы,

-Линейки синхронизации.

Диаграмма состояний позволяет описать систему в более, чем одном варианте использования.

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

при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.

Событие

¨ Переход системы из состояния в состояние осуществляется при наступлении событий.

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

¨ В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий.

Переход

¨ При наступлении событий переход срабатывает.

¨ Переход может быть безальтернативным, либо содержать альтернативы.

¨ Альтернативный переход обусловлен наступлением сторожевых условий.

¨ Событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход.

18. Диаграмма последовательности

В первом случае взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности (sequencediagram).

19. Диаграмма кооперации

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


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

не только последовательность взаимодействия,

но и все структурные отношения между объектами, участвующими в этом взаимодействии.


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

Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе.

Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.
Кооперация может быть представлена на двух уровнях:

· На уровне спецификации - показывает роли классов и роли ассоциаций в рассматриваемом взаимодействии.

· На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.


Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во взаимодействии элементы.

Кооперация на уровне спецификации изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации.

20. Диаграммы реализации (физические)

    1. Диаграмма компонентов (componentdiagram)
    2. Диаграмма развертывания (deploymentdiagram)

21. Диаграмма компонентов

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

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы.


Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код.

Во многих средах разработки модуль или компонент соответствует файлу.

Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ.

Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.


Диаграмма компонентов разрабатывается для следующих целей:

  • Визуализации общей структуры исходного кода программной системы.
  • Спецификации исполнимого варианта программной системы.
  • Обеспечения многократного использования отдельных фрагментов программного кода.
  • Представления концептуальной и физической схем баз данных.

 

22. Диаграмма развертывания

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime).

При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками.

Она содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, ДР едина для системы в целом, поскольку должна всецело отражать особенности ее реализации.

Цели, преследуемые при разработке диаграммы развертывания:

  • Определить распределение компонентов системы по ее физическим узлам.
  • Показать физические связи между всеми узлами реализации системы на этапе ее исполнения.
  • Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

23. Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия

или в состоянии пассивного ожидания сообщений от других объектов.

Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focusofcontrol).

24. Линия жизни

Линия жизни объекта (objectlifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности.

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

25. Сообщение

Сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий.

Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением.

26. Компонент (UML)

Для представления физических сущностей в языке UML применяется специальный термин - компонент (component).

Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели.

27. Компонент - рабочий продукт

Как правило - это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++ (г).

28. Компонент исполнения

компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе. Они обозначаются обычным образом.

 

29. Узел

Узел(node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом.

В качестве вычислительного ресурса узла может рассматриваться наличие некоторого объема электронной или магнитооптической памяти и/или процессора.

30. Диаграммы поведения

    1. Диаграмма состояний (statechartdiagram)
    2. Диаграмма деятельности (activitydiagram)
    3. Диаграммы взаимодействия (interactiondiagrams)

 

Архитектура

1. Размерно-ориентированные метрики

    1. LOC, KLOC
    2. Человеко-месяцы
    3. Производительность

2. Функционально-ориентированные метрики

    1. FP, functional points (Албрехт)
    2. Исходные характеристики
    3. Вводы, выводы, запросы, внутренние и интерфейсные файлы
    4. Системные параметры приложения
    5. Производительность

 

3. Архитектурно-значимые требования проекта

-Расширяемость

¨ Возможность добавления новых возможностей в разработанную систему

¨ Усложнение структуры системы

¨ Удлинение срока разработки

¨ Определение класса возможных расширений

¨ Роль необязательных требований

 

-Изменение требований

¨ Возможность изменений требований в процессе создания системы

¨ Те же приемы, что и на предыдущем слайде

¨ Подходы к управлению требованиями

¡ Формализованный подход

¡ Подход методологии ХP

 

-Производительность

¨ Выполнение тех или иных операций в установленное время

¨ Работа в режиме реального времени

¨ Множественные подключения

¨ Минимизация числа подсистем

¨ Минимизация взаимодействия между подсистемами

 

-Защищенность от НСД

¨ Многоуровневая структура

¨ Защита критических системных элементов на внутренних уровнях

¨ Проверка безопасности на более высоком уровне

 

-Исключение ошибок

¨ Минимизация числа подсистем, отвечающих за критичные операции

 

-Бесперебойная работа

¨ Добавление избыточных элементов

 

-Простота

¨ Простота понимания

¨ Простота реализации

¨ Простая и эффективная архитектура – затраты на создание

4. Архитектура программной системы

Архитектурное проектирование – это первый этап проектирования, цель - архитектура

На этом этапе определяются:

    1. Интерфейсы системы,
    2. Деление на подсистемы,
    3. Структура управления,
    4. Характер взаимодействия подсистем

Архитектура – уровень приложения, отражающий проблемы проектирования и представления комплексной системы вне алгоритмов вычислений и структур данных

Этот уровень отражает следующие вопросы:

-Организация и структура управления,

-Протоколы связи, синхронизации и доступа к данным,

-Деление на подсистемы,

-Распределение возможностей между подсистемами,

-Физическое распределение компонент системы и пр.

Архитектура - это набор значимых решений по поводу организации системы программного обеспечения,

набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе сих

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

5. Модель архитектуры 4+1 (RUP)

6. "Круг интересов" архитектуры

¨ Структура

¨ Поведение

¨ Значимые элементы

¨ Потребности заинтересованных лиц

¨ Логическое обоснование

¨ Архитектурный стиль

¨ Окружение

¨ Команда разработчиков

7. Структура

-Контекстная диаграмма (например, DFD)

-Диаграмма пакетов

-Диаграмма классов

-Диаграмма компонентов

-Диаграмма развертывания

8. Поведение

-Возможности

-Сервисы

-Варианты использования

9. Значимые элементы

-Критические прецеденты

-Главные классы

-Основные протоколы взаимодействия

-Схемы управленияи т.д.

  1. Потребности заинтересованных лиц

-Конечный пользовательзаинтересован в интуитивно понятном и корректном поведении, производительности, надежности, удобстве использования, доступности и безопасности;

-Системный администратор заинтересован в интуитивно понятном поведении, управлении и инструментах мониторинга;

-Специалист по маркетингу заинтересован в конкурентоспособных функциях, времени до выхода программы, позиционировании среди других продуктов и в стоимости;

-Клиент заинтересован в цене, стабильности и возможности планировать;

-Разработчик заинтересован в понятных требованиях и простом и непротиворечивом принципе проектирования;

-Руководитель проекта заинтересован в предсказуемости хода проектирования, планировании, продуктивном использовании ресурсов и бюджета;

-Специалист по сопровождению заинтересован в понятном, непротиворечивом и документируемом принципе проекта, а также в легкости, с которой можно вносить изменения.

 

11. Логическое обоснование

-Документирование архитектуры

-Документирование аргументов в пользу тех или иных архитектурных решений

-Логические обоснование этих решений

 

12. Окружение

-Окружение влияет на архитектуру («Архитектура в контексте»):

    1. Особенности бизнеса
    2. Позиции заинтересованных лиц
    3. Внутренние и внешние ограничения

-Архитектура влияет на окружение

 

13. Архитектурный стиль

-Архитектурный стиль определяет семейство систем в терминах шаблона организации структуры.

-Точнее, архитектурный стиль определяет

    1. номенклатуру компонентов и типов соединительных звеньев, а также
    2. набор условий, в соответствии с которыми они могут соединяться.

14. Метафора "что и как"

Требования- анализ- проектирование

15. Анализ и Проектирование

16. Когда использовать анализ?

-Как средство документирования (унаследованной, либо вновь разрабатываемой) системы

-Как «пробный шар», в проектах с высоким риском

-Как способ проработки альтернатив

17. Архитектор

-Несет ответственность за целостность аналитической модели, гарантируя ее правильность, согласованность и читаемость

-Модель анализа верна, если она реализует функциональные требования и только их

-Архитектор отвечает за существование архитектурно-значимых частей модели

-Архитектор не отвечает за непрерывно развивающиеся артефакты аналитической модели

18. Инженер по UC

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

-Реализация UCдолжна правильно реализовывать поведение соответствующего UCи только его

-Инженер по UCне несет ответственности за классы и отношения между ними

19. Инженер по компонентам

-Определяет и поддерживает обязанности, атрибуты, отношения и специальные требования одного или нескольких классов анализа,

-проверяя, выполняет ли класс требования, вытекающие из анализа соотв. варианта использования

-Сохраняет целостность одного или нескольких классов анализа.

20. Рабочий процесс анализа

 

Управление программным проектом (УПП)

1. Схема О"Коннела для УПП

АНАЛИЗ И ПЛАНИРОВАНИЕ

a) Наглядное представление цели

b) Сделайте список задач

c) Должен быть 1 руководитель

d) Распределите задач по людям

e) Управляйте ожиданиями

КОНТРОЛЬ И ВЫПОЛНЕНИЕ ПЛАНА

a) Используйте подходящий стиль руководства

b) Знайте, что происходит

c) Сообщайте людям, что происходит

d) Повторяйте пп. 1-8 до достижения п. 10

e) Приз

2. Наглядное представление цели

1.1. Точное определение цели

1.2. Обоснование цели (самомотивация)

1.3. Мотивация команды

1.4. Изменения цели и их контроль

3. Сделайте список задач

4. Должен быть 1 руководитель

-Лидерство

-Ответственность

-Полномочия

5. Распределите задач по людям

6. Управляйте ожиданиями

-Используйте подходящий стиль руководства

-Знайте, что происходит

-Сообщайте людям, что происходит

7. Приз

8. Треугольник компромиссов


Дата добавления: 2018-02-15; просмотров: 534; ЗАКАЗАТЬ РАБОТУ