logo
GOSy_raspredelenie_otvety_10_06_11_v_7-ITOG

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

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

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

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

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

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

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

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

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

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

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

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

Для диаграмм языка 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) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация терминологии, названий модулей и элементов проекта.

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

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

Критика

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

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

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

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

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

Категории.