Главная страница
Навигация по странице:

  • Пример отчѐта

  • Название поля Тип Условия видимос ти Условия

  • Задание № 4

  • има. МУ к ПР приложение 2 (1). Методические указания для выполнения практических лабораторных занятий по мдк. 05. 01 Проектирование и дизайн информационных систем


    Скачать 1.34 Mb.
    НазваниеМетодические указания для выполнения практических лабораторных занятий по мдк. 05. 01 Проектирование и дизайн информационных систем
    Дата02.03.2023
    Размер1.34 Mb.
    Формат файлаdoc
    Имя файлаМУ к ПР приложение 2 (1).doc
    ТипМетодические указания
    #964444
    страница6 из 6
    1   2   3   4   5   6

    1. Оформить отчет к лабораторной работе.

      • Титульный лист.

      • Цель работы.

      • Навигационная схема (карта навигации).

      • Макеты графического интерфейса пользователя.

      • Описание элементов управления по таблице.

      • Выводы.

    Пример отчѐта

    Сперва составляем навигационную схему выбранного сайта. Для примера взята карта навигации интернет-банкинга ОАО «АСБ Беларусбанк» (ibank.asb.by). Информация на карте навигации аналогична разделу «Содержание» обычной книги. В карте представлен полный перечень разделов и/или всех страниц, имеющихся на сайте. Нередко, заголовки страниц в списке служат ссылками на эти страницы.



    Рисунок 1. Интерфейс
    Карту навигации можно составить в виде дерева.

    Рисунок 2. Карта навигации

    Далее необходимо составить Макеты графического интерфейса пользователя (не менее 3 макетов): чтобы создать макет можно использовать программу Microsoft Visio.




    Рисунок 3. Начальная страница (ibank.asb.by)

    Теперь нужно описать элементы управления для каждого составленного макета. В столбце Название поля нужно перечислить все элементы, размещѐнные на макете. В столбце Тип – указать тип, т.е. чем является элемент (ссылка, текст, поле для ввода, кнопка, чекбокс и т.п.). В столбцах Условия видимости и Условия доступности нужно указать кому виден и доступен каждый элемент интерфейса. В столбце Описание нужно немного подробнее описать для чего этот элемент, какие он действия совершает.

    Таблица 1. Описание элементов управления

    Название поля

    Тип

    Условия

    видимос ти

    Условия

    доступно сти

    Описание

    Логотип

    Ссылка

    Виден всем

    Доступе н всем

    Ссылка на сайт

    belarusbank.by

    Вход в систему

    Начальная страница

    Начальная страница

    Инструкция

    пользователя

    Ссылка

    Ссылка на другую

    страницу сайта

    Online-

    регистрация

    Ссылка

    Ссылка на другую

    страницу сайта

    Часто задаваемые вопросы

    Ссылка







    Ссылка на другую страницу сайта

    Логин

    Текстовое поле







    Текстовое поле для ввода логина указанного при

    регистрации на сайте

    Пароль

    Текстовое

    поле







    Текстовое поле для

    ввода пароля (типа













    password)



    Войти



    Кнопка







    При правильно введѐнном логине и пароле пользователь

    может зайти на сайт

    Разблокировать

    по СМС


    Ссылка







    Ссылка на другую

    страницу сайта

    Контактные

    данные банка


    Ссылка







    Ссылка на сайт

    belarusbank.by


    Задание №2

    1. Откройте в браузере сайт Eskone по адресу https://esk.one/.

    2. Пройдите регистрацию.

    3. В левом верхнем углу выберите Создать проект.

    4. Нажмите на новый проект для редактирования.




    Рисунок 1. Интерфейс сервиса

    5 выберите меню Страницы

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

    7 покажите результат преподавателю
    Задание № 3

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

    Задание № 4

    Изучить CASE-средство Rational Rose: функциональные возможности.

    Задание № 5

    Изучить средство автоматизированного документирования SoDA.

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

    По задаваемым пользователем шаблонам SoDA «компилирует» документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в Rational Rose. Далее пользователь может отредактировать полученный документ с помощью Microsoft Word или Adobe FrameMaker. Как и любая система отчетности, SoDA базируется на тех данных, которые получает из сторонних программ.

    SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. Плюс ко всему SoDA имеет доступ к данным из Microsoft Project.

    Основные возможности системы:

    • автоматическое извлечение информации из файлов, созданных различными инструментальными средствами. SoDA «понимает» структуру информации, хранимой теми системами, с которыми она интегрирована, а сама информация доступна ей через API этих систем;

    • сохранение при «перекомпиляции» текста и графики, введенных пользователем вручную в текстовом процессоре. Если пользователь, скажем, в Microsoft Word, добавил какие-нибудь комментарии или иллюстрации в сгенерированный с помощью SoDA документ, то при перестраивании данного документа SoDA его не испортит;

    • настройка шаблонов, по которым генерируется документация. С помощью удобного визуального редактора можно создавать шаблоны, соответствующие всевозможным внешним стандартам (таким, как ISO 9000, IEEE, MIL-STD-498 и DOD-STD-2167A) или внутренним стандартам компании;

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

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

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

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

    • документирование всех этапов работы над проектом;

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

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

    Давайте немного остановимся на первом режиме, когда за основу берется стандартный шаблон. Известно, что компания Rational не только полностью описала процесс выпуска программного обеспечения, но и создала программные средства для каждого этапа этого процесса. Следовательно, каждый продукт сохраняет данные, а SoDA по ним строит («компилирует») отчет.

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

    1. Бизнес-моделирование.

    2. Определение требований.

    3. Анализ и проектирование.

    4. Тестирование.

    5. Реализация.

    6. Внедрение.

    Естественно, все этапы детально описаны, и на каждом из них предполагается получение документа строго определенного образца (согласно RUP), после того как соответствующие данные были обработаны той или иной программой из набора средств Rational. Так, на первом этапе при помощи SoDA можно получить документы «Оценка организации заказчика», «Словарь терминов предметной области», «Коммерческое предложение», «Бизнес-правила» и т.д. На втором этапе можно получить документы «Спецификация на программную систему», «Спецификация на функции системы».

    Каждый из этих отчетов будет соответствовать RUP, а форма изложения – отражать требования ISO. В дальнейшем такой документ можно согласовать с заказчиком. Обратите внимание: первый этап называется «Бизнес-моделирование», что подразумевает использование на данном этапе средств визуального проектирования. Согласно технологии RUP, этим средством является Rational Rose, позволяющее на основе различных диаграмм получить полную бизнесмодель предприятия и модель проектируемой системы. Соответственно, опять же по технологии RUP, на этапе проектирования аналитик или

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

    Заказчик же, к сожалению, зачастую плохо ориентируется в мире диаграмм... Из меню Rose запускается составитель отчетов, пользователь выбирает тип отчета и через 1-5 минут получает готовый документ с разметками, комментариями и фрагментами моделей в формате Word. При этом все элементы документа представляют собой внедренные объекты, а это значит, что изменения, внесенные в модель, автоматически отражаются в документе.

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

    Таблица 1



    В таблице 2 даны расшифровка и описание типов диаграмм в Rose.

    Можно выделить 10 важнейших моментов, когда без системы отчетности невозможно обойтись. Это бывает в тех случаях, когда необходимо:

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

    • выработать план;

    • идентифицировать и смягчить риски;

    • устанавливать и отслеживать проблемы;

    • проанализировать прецеденты;

    • разработать компонентную архитектуру;

    • создавать и тестировать продукт;

    • проверять и оценивать результаты;

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

    • обеспечивать ввод в коммерческую эксплуатацию и поддержку пользователей.

    Таблица 2






    1   2   3   4   5   6


    написать администратору сайта