52. Модель rup. Основные диаграммы модели rup.

Рациональный унифицированный процесс (Rational Unified Process, RUP) — одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

Итерационная разработка программного обеспечения в RUP предполагает разделение проекта на несколько мелких проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены. RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект:

• итеративная разработка;

• управление требованиями;

• использование модульных архитектур;

• визуальное моделирование;

• проверка качества;

• отслеживание изменений.

Графические изображения моделей системы в UML называются диаграммами . В терминах языка UML определены следующие их  виды:

• диаграмма вариантов использования или прецедентов (use case diagram)

• диаграмма классов (class diagram)

• диаграммы поведения (behavior diagrams)

• диаграмма состояний (statechart diagram)

• диаграмма деятельности (activity diagram)

• диаграммы взаимодействия (interaction diagrams) 

• диаграмма последовательности (sequence diagram) 

• диаграмма кооперации (collaboration diagram) 

• диаграммы реализации (implementation diagrams)

• диаграмма компонентов (component diagram)

• даграмма развертывания (deployment diagram)

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

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

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

• связи , которые представляются различными линиями на плоскости;

• текст , содержащийся внутри границ отдельных геометрических фигур;

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

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

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

• представленные на диаграмме сущности модели должны быть одного концептуального уровня;

• вся информация о сущностях должна быть явно представлена на диаграмме;

• диаграммы не должны содержать противоречивой информации;

• диаграммы не следует перегружать текстовой информацией;

• каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов;

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

• модели системы должны содержать только те элементы, которые определен

22. Проектирование ИС []

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
22	12.2.	Проектирование информационных систем. Особенности стадии внедрения, эксплуатационной поддержки и утилизации ИС.	Алексеев Пётр Сергеевич	Тоня Аркуша	ОПЛ (Ден), ОПЛ (Мадина), готовый ответ Тони

Готовый ответ Тони

Дополнены ответы Дениса Ковалевича

Стадия внедрения

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

Одна из главных причин неудачных внедрений – это слабая проработка проекта ИС на этапе управленческого консалтинга. В результате ИС оказывается в недостаточной степени интегрирована в общую систему управления компанией.

Если на этой стадии возникают проблемы, то они связаны со следующими тремя основными причинами:

• недостаток поддержки основного персонала, особенно когда надо уделить достаточно времени и энергии на критических стадиях;

• слишком амбициозные планы вместо пошагового, мудрого подхода;

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

Стадия эксплуатации

• Ввод информационной системы в эксплуатацию

  • ввод в опытную эксплуатацию технических средств;

  • ввод в опытную эксплуатацию программных средств;

  • обучение и сертифицирование персонала;

  • проведение опытной эксплуатации компонентов и системы в целом;

  • сдача в эксплуатацию и подписание актов приемки-сдачи работ.

• Эксплуатация информационной системы

  • повседневная эксплуатация;

  • сопровождение программных, технических средств и всего проекта.

Стадия поддержки (сопровождения)

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

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

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

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

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

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

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

Утилизация

Ликвидация изделия с обращением входящих в него компонентов во вторичное сырье (с соблюдением экологических требований), сопровождающаяся исключением всех относящихся к ликвидируемому экземпляру изделия ИО из ИИС.

Ответ прошлых лет (Мадина)

Внедрение.

2.1. Составление технических проектов (ТП).

В соответствии с утвержденным регламентом

консультанты исполнителя и ИТ-специалисты заказчика составляют ТП;

Заказчик утверждает ТП.

Уточняются объемы работ, сроки и стоимость.

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

Состав ТП:

структура хранимых данных;

алгоритмы;

используемые ресурсы системы, их структура и связи;

пользовательский интерфейс.

2.2. Планирование работ.

В соответствии с утвержденным регламентом

менеджеры проекта исполнителя и заказчика составляют рабочие программы (РП);

заказчик и исполнитель утверждают РП.

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

Состав РП:

перечень работ: настройка, тестирование, приемка (в перечень работ могут входить ТЗ и ТП);

сроки выполнения работ;

ответственный за каждый пункт РП.

2.3. Заполнение основных справочников.

Особенности этапа:

может потребовать от 1 до 18 месяцев;

требует централизации ввода информации;

является необходимым условием работы системы.

Способы реализации:

конвертирование данных;

ручной ввод данных пользователями (операторами).

2.4. Настройка, тестирование, приемка.

Особенности этапа:

самый трудоемкий и ответственный;

существенно зависит от предварительной подготовки (регламенты, ТЗ, ТП, РП);

требует жесткой дисциплины как со стороны исполнителя, так и со стороны заказчика;

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

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

2.5. Опытная эксплуатация.

Особенности этапа:

требует оперативности и надежности отклика от исполнителя;

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

имеет значительную длительность (1-3 месяца);

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

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

Содержание этапа:

оформление инструкций для пользователей;

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

доработка технической документации;

формирование иных (заранее оговоренных) документов.

2.7. Завершение проекта.

Содержание этапа:

юридическое закрытие договорных отношений;

окончательные финансовые расчеты;

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

Утилизации ИС – осушествляется кнопкой DELETE.

Ответ прошлых лет (Ден)

Стадия внедрения

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

Если на этой стадии возникают проблемы, то они связаны со следующими тремя основными причинами:

недостаток поддержки основного персонала, особенно когда надо уделить достаточно времени и энергии на критических стадиях;

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

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

Стадия эксплуатации

• Ввод информационной системы в эксплуатацию

  • ввод в опытную эксплуатацию технических средств;

  • ввод в опытную эксплуатацию программных средств;

  • обучение и сертифицирование персонала;

  • проведение опытной эксплуатации компонентов и системы в целом;

  • сдача в эксплуатацию и подписание актов приемки-сдачи работ.

• Эксплуатация информационной системы

  • повседневная эксплуатация;

  • сопровождение программных, технических средств и всего проекта.

Стадия поддержки (сопровождения)

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

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

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

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

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

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

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

Утилизация

Ликвидация изделия с обращением входящих в него компонентов во вторичное сырье (с соблюдением экологических требований), сопровождающаяся исключением всех относящихся к ликвидируемому экземпляру изделия ИО из ИИС.

Очень подробно данная тема проработана на http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 и на http://www.rus-lib.ru/book/38/men/21/2.3.html

23. Проектирование ИС []

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
23	8.2.	Проектирование информационных систем. Паттерны проектирования.	Алексеев Пётр Сергеевич	Денис Никаноров	ОПЛ (Ден), ОПЛ (Мадина), готовый ответ Дениса

Готовый ответ Дениса Никанорова

Проектирование информационных систем. Паттерны проектирования

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

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

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

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

• Модель системы, построенная в терминах паттернов проектирования, фактически является структурированным выделением тех элементов и связей, которые значимы при решении поставленной задачи.

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

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

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

• Трудно переоценить роль использования паттернов при интеграции информационных систем организации.

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

Польза

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

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

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

Критика

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

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

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

Для преодоления этих недостатков используется рефакторинг.

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

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

• архитектурные паттерны;

• паттерны интегрирования информационных систем.

Категории.

• Архитектурные

• Проектирования

• Анализа

• Тестирования

• Реализации