лабы тоип. !!! Лаб раб по _ТОИП Челябинск. Учебнометодическое пособие 1 оу во ЮжноУральский институт управления и экономики
 Скачать 2.3 Mb.
|
|
Ход работы Задание 1. Создайте диаграмму Ганта по проекту «Зимняя сессия». 31 Последовательность действий. 1. Создать и заполнить таблицу с перечислением этапов, датами начала, длительности каждого этапа и конца. 2. Для выделенной таблицы создать диаграмму (тип «Линейчатая с накоплением»). 3. На вкладке «Диапазон данных» выбрать «Ряды в столбцах». 4. На вкладке «Ряд» нажать кнопку «Добавить», установить курсор в поле «Значения» и выделить ячейки с длительностями этапов. 5. Уберите «Легенду». 6. В контекстном меню вертикальной оси с названиями этапов выбрать пункт «Формат оси». 7. На вкладке «Шкала» поставить две галочки: «Обратный порядок категорий» и «Пересечение с осью Y в максимальной категории». 8. Сделайте двойной щелчок мышью по любому их синих столбиков, установите прозрачную заливку и невидимую рамку. 9. Настройте диапазон отображаемых на диаграмме данных. Для этого необходимо узнать реальное содержимое ячеек, с которых начинается и на которых заканчивается временная шкала (первая ячейка в столбце Начало и последняя в столбце Конец). Дело в том, что Excel только отображает в ячейке дату как день-месяц-год, а на самом деле любую дату хранит в ячейке как количество дней, прошедших с 1.1.1900 до текущей даты. Выделите желтую и зеленую ячейки и по очереди попробуйте установить для них «Общий формат» (меню «Формат» – «Ячейки»). Например, получилось 38350 и 38427, соответственно. Прибавим к дате окончания еще три дня – получим 38340. Запомним эти числа. 10. Щелкните правой кнопкой мыши по горизонтальной оси времени и выбрать «Формат оси» и ввести эти числа на вкладку «Шкала»: в минимальное и максимальное значение соответственно. Задание 2. Создайте диаграмму Ганта по следующей таблице, отражающей этапы проекта (рис. 12). 32 Рис. 12. Образец таблицы планирования Воспользуйтесь быстрым способом создания диаграмм Ганта. При помощи условного форматирования можно заставить Excel заливать ячейку любым выбранным цветом, если она по дате попадает между началом и концом этапа. Проще всего для этого использовать логическую функцию И, которая в данном случае проверяет обязательное выполнение обоих условий (5 января позже, чем 4-е и раньше, чем 8-е) (рис. 13). Рис. 13. Пример условного форматирования Задание 3 (индивидуально). Создайте диаграмму Ганта по разрабатываемому вами программному проекту онлайн средствами (Приложение 1). Контрольные вопросы 1. Для чего производится временное планирование проекта? 33 2. Укажите назначение диаграмм Ганта. 3. В чем особенность диаграмм Ганта? 4. Назовите типы связей на диаграмме Ганта, приведите примеры. 5. Какие программными продуктами можно построить диаграммы Ганта? По завершении занятия студент должен: 1. Знать назначение временного планирования проекта. 2. Называть методы разработки временного планирования. 3. Создавать диаграммы Ганта различными способами. 4. Осуществлять временное планирование программного проекта. 34 Лабораторная работа №4 Этап выявления потребностей Цель: выявить потребности заинтересованных в проекте лиц. Теоретические вопросы: Процесс работы с требованиями к продукту можно разделить на четыре этапа: 1. Определение концепции продукта. 2. Сбор требований. 3. Анализ требований. 4. Проектирование системы. На этапе определения концепции продукта проводится работа с его инвестором. Цель этапа – выработка единого видения будущего продукта. По окончанию этого этапа делается вывод о том, будет ли этот продукт разрабатываться или нет. На этапе сбора требований ведется основная работа с заказчиком системы и ее будущими пользователями. Цель этапа – точно определить функции продукта и способы его интеграции в существующие процессы. Качественное выполнение работ на этом этапе гарантирует, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки. На этапе анализа требований осуществляется структуризация уже собранных ранее требований. Цель этапа – предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, полученных на предыдущем этапе. Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет проекта. На этапе проектирования системы группа разработки принимает проектные решения о том, какую функциональность будет нести продукт, 35 чтобы удовлетворить пользователей. Результатом служит законченное техническое задание (ТЗ) к продукту: полное описание поведения будущего продукта без неоднозначностей и вопросов. На основе ТЗ начинается моделирование работы продукта с конечными пользователями и производится его тестирование. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт. Однако при работе с заказчиками проекта и будущими пользователями программы возникают различные ситуации. Сложившие ситуации часто называют «синдромами». Выделяют три основных «синдрома». 1. Синдром «Да… Но!». Эта возникновение противоположных реакций пользователя, когда он впервые видит реализацию системы. С одной стороны, это то, о чем он говорил, с другой – это не то, что он ожидал увидеть. 2. Синдром «неоткрытых руин». Со временем появляется некая закономерность: чем больше выявлено требований, тем больше деталей заказчик стремится добавить в свои требования. 3. Синдром «Говорить на языке пользователя». Во время общения с заказчиком не следует использовать профессионализмы – термины, которые могут быть неизвестны пользователю или неправильно им истолкованы. Дисциплина управления проектами предлагает различные методы выявления требований, проблем и желаний заказчика: − интервью и анкеты; − семинары/совещания (заинтересованные лица собираются для интенсивных, насыщенных дискуссий); − сценарии приложения (использование визуальных/графических инструментов для демонстрирования поведения системы) для исключения синдрома «Да… Но!»; − ролевые игры (каждому члену группы назначается определенная роль, обычно роль одного из пользователей); − метод «мозгового штурма»; − использование прототипов (как можно раньше предоставить пользователю интерфейс); 36 − сценарии использования (Use Cases – взаимодействие между пользователем и системой, представленное в виде последовательности шагов); − анализ существующих документов (извлечение информации из документов Microsoft Word, электронной почты и записей); − наблюдение и демонстрирование задач (наблюдение за пользователями, выполняющими определенную задачу); − анализ существующих систем (сбор требований от морально устаревших заменяемых систем или от систем, разработанных в ходе конкуренции). Рассмотрим особенности метода интервью. Его преимущество – интерактивность, предоставляющая возможность внесения дополнений или доработки вопросов в зависимости от полученных ответов. На сегодняшний день это хороший способ собрать требования по удобству использования системы, надежности, производительности и удобству сопровождения. Обычно заказчики не упоминают эти нефункциональные требования, пока их явно не спросить об этом. При выборе заинтересованных лиц для интервью следует убедиться, что команда разработчиков понимает, какую именно группу заинтересованных лиц они представляют. Можно следовать следующим советам. 1. Рекомендуется написать первоначальный список вопросов. 2. Желательно проговорить ответы своими словами, чтобы убедиться, что Вы понимаете смысл. 3. Не следует предлагать ответ на заданный вопрос. (Какое время реакции системы Вы ожидаете? Три секунды?). 4. Не следует соединять несколько вопросов в один. (Необходимо ли Вам печатать ответ, отправлять его по электронной почте и факсу?). Быть может,пользователю нужна только возможность печати отчета и отправки его по электронной почте, но нет необходимости в факсе. 5. Не следует спрашивать пользователя о деталях реализации. (Вы предпочитаете list-box или radio-buttons для выбора метода оплаты?). 6. Не следует использовать слишком длинные и сложные вопросы. 37 7. Не рекомендуется задавать следующий вопрос, если еще не получен ответ на предыдущий. 8. В ситуации, когда ответ непонятен, стоит задать дополнительные вопросы, даже если их нет в сценарии интервью. 9. Не стоит перебивать пользователей, когда они отклоняются от темы. Надо позволить им высказать свои мысли, на какую бы тему они не размышляли. Если ответ на изначальный вопрос не получен, следует задать его снова. 10. Фиксировать каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным. 11. Обязательно следует спросить пользователей о дополнительной информации (экранные формы системы). 12. При разговоре с заказчиками не стоит говорить, будет ли их требование выполнено или нет. Это решение можно принять позже. 13. В конце разговора обязательно задайте вопрос для получения дополнительной информации. (Что еще я должен знать?). 14. После получения списка требований, следует выяснить у заинтересованного лица приоритет каждого требования. 15. По ходу интервью стоит делать примечания и/или использовать записывающее устройство. 16. Вопросы должны быть контекстно-свободными, т. е. не содержать желаемый ответ. 17. Все требования заносятся в «архив требований», т. е. должны документироваться. Ход работы Задание 1. Уточните список пользователей и заинтересованных лиц для проекта Автоматизированная информационная система «Университет» (АИС «Университет»). (По желанию студентов можно осуществить реализацию другого программного проекта. Например, «Склад», «Поликлиника», «Сайт организации», «Поиск тура» и др.). Задание 2. Распределите в группе роли согласно списку, полученному в задании 1. Например, Ректор, Проректор, Декан, Заведующий кафедрой, Преподаватель кафедры, Студент, Секретарь деканата и т. д. В соответствии 38 с ролью изучите возможные должностные обязанности (поиск в сети Интернет), обсудите с преподавателем возможные потребности, проблемы, возникающие с выполнением должностных обязанностей, составьте легенду вашего пользователя. Задание 3. Реализуйте деловую игру. Каждый участник по очереди будет играть роль выбранного им пользователя, остальные – члены команды разработчиков. Методом интервьюирования выявите потребности, проблемы пользователя, подлежащие решению в проекте. Помните о том, что с пользователем необходимо общаться на его языке. Обязательно ведите документирование полученных данных. Задание 4. Согласно своей роли, заполните таблицу описания заинтересованных лиц и пользователей (таблица 9). Таблица 9 – Характеристика заинтересованного лица Представитель Кто в проекте является представителем пользователя? Можно ссылаться на заинтересованных лиц Описание Краткое описание типа пользователя Тип Уровень знаний пользователя, его техническое образование и степень осведомленности. Например, гуру, случайный пользователь Ответственность Список ключевых ответственностей пользователя по отношению к разрабатываемой системе, т.е. фиксирует детали, составляет отчеты, координирует работу и т.д. Критерий успеха Как пользователь видит успех? Каким образом компенсируется труд пользователя? Вовлеченность Каким образом пользователь может быть вовлечен в проект (рецензирование требований, архитектурных и технических решений, тестирование ПО и т.д.)? Поставляемые артефакты (документы) Существуют ли какие-либо выходные артефакты, требуемые пользователю? Если да, то какие (например, отчеты о…, сводка за… и т.д.)? Комментарии/ Проблемы Проблемы, мешающие достижению успеха, и любая подобная информация. Можно включать тенденции, которые делают работу пользователя проще или тяжелее. Контрольные вопросы 1. Кто такие заинтересованные лица проекта? 2. Как связаны понятия «заинтересованное лицо» и «пользователь»? 39 3. Какими методами осуществляется выявление потребностей заинтересованных лиц проекта? 4. Каковы преимущества метода интервьюирования? 5. Укажите основные принципы проведения интервьюирования. 6. Всегда ли заказчик проекта имеет представление о реальных потребностях? По завершении занятия студент должен: 1. Знать основные преимущества метода интервьюирования для выявления потребностей заинтересованных лиц проекта. 2. Знать понятие «заинтересованные лица проекта». 4. Иметь представление о принципах проведения интервью с пользователем. 5. Уметь проводить интервью с пользователем. 6. Осуществлять ведение документации: выявленных и зафиксированных потребностей заинтересованных лиц проекта. 40 Лабораторная работа №5 Этап выявления проблемы Цель: выявить возможные проблемы проекта, достигнуть соглашения с заказчиком об определении проблемы. Ход работы Задание 1. Работая в группе разработчиков над АИС «Университет» (или другой, выбранной студентами) с заказчиком (здесь заказчиком выступает преподаватель), выявите проблемы, которые должны быть решены в проекте на основании выявленных потребностей (см. предыдущую лабораторную работу). Задание 2. Представьте, что магазин канцелярии, состоящий из руководителя, продавца, начальника склада и бухгалтера имеет следующую проблему: низкое качество обслуживания клиентов. Предложите возможное решение данной проблемы, заполнив таблицу (таблица 10). Таблица 10 – Описание проблемы Проблема: Описание (в двух-трех предложениях) Воздействует на: Указание лиц, на которых оказывает влияние выявленная проблема Результатом чего является: Указание причины возникновения проблемы К чему приводит: Описание воздействия данной проблемы на заинтересованных лиц и деятельность компании заказчика Выигрыш от: Указание предлагаемого командой решения Успешное решение должно: Список ключевых преимуществ успешного решения Задание 3. Из полученного в задании 1 списка возможных проблем окончательно определите одну, которая будет решающей для проекта АИС «Университет». Заполните для нее таблицу (таблица 10). Задание 4. Осуществите в сети Интернет поиск основных методов выявления причин проекта. Из предложенных методов выберите один и выделите основные причины существования проекта АИС «Университет» – проблем, стоящих за проблемой. Контрольные вопросы 1. Какими методами возможно выявить проблему заказчика? 41 2. Всегда ли выявленная проблема совпадает с проблемой, с которой заказчик приходит к разработчику? 3. Для чего необходимо согласование выявленной проблемы с заказчиком? 4. Каким образом прийти к согласованию проблемы с заказчиком, что для этого надо сделать команде разработчиков? 5. Назовите методы выявления причин существования проекта. 6. Что делать, когда выявленная причина проблемы не может быть решена средствами информационных технологий? (Например, проблема – низкая успеваемость в классе, причины – высокая температура в учебных помещениях). По завершении занятия студент должен: 1. Знать особенности выявления проблем заказчика для реализации проекта. 2. Уметь выявлять проблемы заказчика. 3. Уметь выявлять причины существования проекта. 4. Осуществлять анализ проблемы. 5. Осуществлять согласование проблемы. 42 Лабораторная работа №6 Этап анализа проблемы Цель: выявить заинтересованных лиц проекта. Теоретические вопросы Помимо команды разработчиков проекта и заказчика, существует также множество людей, которые прямо или косвенно получают от решения проблемы прибыль. Их называют заинтересованными лицами проекта (stakeholder). Таким образом, можно выделить: − инвестора проекта, который оплачивает проект; − заказчика проекта, который заказывает проект и отвечает за его приемку; − пользователей проекта, которые будут в конечном счете работать с программой; − других заинтересованных лиц проекта, которые напрямую или косвенно получат прибыль от решения проекта. Не всегда инвестор и заказчик являются одним лицом, и не всегда заказчик будет конечным пользователем программы. Следовательно, важно знать всех заинтересованных лиц проекта, их вклад в проект и самое главное – их требования. В качестве заинтересованных лиц также можно рассматривать [5]: − любого, участвующего в разработке системы (системные аналитики, дизайнеры интерфейса, программисты, тестеры ПО, менеджеры проекта и др.); − любого, привносящего свои знания в систему (эксперты предметной области, авторы документов, используемых для сбора требований и др.); − руководство (руководитель компании-заказчика, руководитель отдела, проектирующего систему); − лица, непосредственно вовлеченные в управление, настройку и сопровождение системы (например, для сайта это хостинговая компания); − поставщики регламентов, стандартов. Помимо интервью рассмотрим еще один метод – анкетирование. 43 Анкеты наиболее полезны, когда есть возможность задать одни и те же вопросы многим заинтересованным лицам и не надо задавать дополнительные вопросы в процессе беседы. По сравнению с интервью анкетирование обычно влечет за собой меньше расходов. С одной стороны, анкеты структурированы и не интерактивны, с другой – они обеспечивают меньший контроль над результатами. При составлении вопросов для анкеты следует придерживаться правила: вопросы должны быть понятными и прямолинейными, потому что отсутствует возможность прояснить непонятные моменты или спорные ситуации. Основная работа состоит не только в разработки анкеты и в проведении анкетирования, но и в обработке результата. Эти процессы можно автоматизировать специальными средствами. Например: − онлайн-формы Google; − бесплатный онлайн-сервис http://webanketa.com/ru/; − бесплатный онлайн-сервис http://www.createsurvey.ru/; − и др. Ход работы Задание 1. После того, как выявлены все заинтересованные лица проекта, а также пользователи, ответьте на следующие вопросы: 1. Кто пользователь будущей автоматизированной системы? 2. Кто заказчик (экономический покупатель программного продукта)? 3. На кого еще окажут влияние результаты работы АИС? 4. Кто будет оценивать и принимать систему после ее установки? 5. Существуют ли другие пользователи, чьи потребности надо учесть (это могут быть как внутренние, так и внешние пользователи)? 6. Кто будет заниматься сопровождением системы? 7. Не забыли ли мы кого-нибудь? Задание 2. После ответов на вопросы при появлении новых пользователей или заинтересованных лиц проекта, которые ранее не были нами учтены, заполните для них таблицу, представляющую их характеристику (таблица 8). 44 Задание 3. Разработайте анкету (с помощью одного из предложенных сервисов) для выбранной вами роли пользователя в проекте АИС «Университет», позволяющую выявить потребности, проблемы, характеристики этого пользователя. Контрольные вопросы 1. Всех ли пользователей и заинтересованных лиц можно выявить изначально? 2. Какими методами можно выявить неучтенных пользователей и/или заинтересованных лиц проекта? 3. Для чего необходимо знать и иметь характеристику всех пользователей проекта? 4. Каковы особенности метода анкетирования при работе с пользователями проекта? В чем его преимущества, недостатки? По завершении занятия студент должен: 1. Осуществлять выявление пользователей и заинтересованных лиц проекта, неучтенных на ранних этапах проектирования. 2. Знать основные особенности метода анкетирования пользователей проекта. 3. Уметь составлять анкеты для выявления потребностей пользователя, его характеристик. 45 Лабораторная работа №7-8 Определение границ системы Цель: определить границы разрабатываемой системы «Университет»: что программа будет делать, и что делать не будет. Теоретические вопросы Все требования в проекте делятся на две основных категории: потребности (пользователей) и решения (функции, feature), которые будут реализованы в проекте для удовлетворения потребностей. Если в процессе работы над продуктом требуется изменить решение, то достаточно утверждения нового решения проектной командой. Если изменениям подвергается потребность, то это обязательно должно быть обговорено с клиентом. Требование определяется как «условие или особенность, которой должна удовлетворять система» [5]. Требованием может быть: − функциональность, необходимая заказчику или пользователю для разрешения проблем (получения прибыли); − функциональность, которая должна быть реализована в системе в соответствии с контрактом, стандартом, спецификацией, инструкцией или другим официальным документом; − ограничение, наложенное заинтересованным лицом. Типы требований, наиболее часто использующихся в проектах: − потребности заинтересованного лица: требование от заинтересованного лица; − функциональная особенность: функциональность, предоставляемая системой; формулируется системным аналитиком; назначение – удовлетворить потребности заказчика; − сценарий использования (Use Case): описание поведения системы в терминах последовательности действий; − дополнительное требование: другое требование (обычно нефункциональное), не охваченное сценариями использования; − тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов; 46 − сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования. Их взаимосвязи отражены с помощью пирамиды требований (рис. 14). Рис. 14. Пирамида требований Главное отличие между потребностями и функциональными особенностями заключается в источнике требований. Потребности озвучиваются заинтересованными лицами, а функциональные особенности формулируются аналитиками. Последовательность этапов от выявления потребностей до разработки тестовых сценариев, т.е. сверху вниз, является процессом проектирования системы. Движение по пирамиде от тестовых сценариев и удовлетворения потребностей пользователя, т.е. снизу вверх, демонстрирует работу системы. Рассмотрим процесс формирования сценариев использования с помощью диаграммы прецедентов языка UML. В нотации языка UML данный вид диаграмм называется по-разному: диаграммы сценариев использования, вариантов использования или диаграммы прецедентов (английский вариант – Use Cases). Это диаграмма взаимодействия пользователя (актора, эктера, актёра, англ. actor) с системой для получения результата. Здесь эктор – находящееся вне системы нечто (некто), взаимодействующее с системой. Это может быть как пользователь, так и другая программа. При взаимодействии пользователя с системой первый ожидает определенного, предсказуемого действия последней. В свою очередь 47 прецедент (сценарий использования) выступает одним из способов определения реакции системы [2]. С помощью прецедентов описывают поведение разрабатываемой программы, не определяя ее реализацию. С помощью наглядного изображения диаграмм можно достичь взаимопонимания между заинтересованными лицами проекта: разработчиками, аналитиками, пользователями и др., – а также проверить архитектуру системы во время ее разработки. Составление диаграммы прецедентов – это способ перейти от функциональных особенностей к конкретным сценариям. Каждый отдельный прецедент представляет функциональные требования в целом и отражает выполнение некоторого объема работ. Для конечного пользователя – эктора – прецедент реализует нечто ценное, например, формирует отчет, вычисляет, обрабатывает данные и проч. Прецеденты в свою очередь не должны быть слишком общими или чересчур специфичными. Изображение системы на диаграмме осуществляется в виде прямоугольника. Прецедент – в виде эллипса, находящегося в границах системы. Для каждого прецедента должно быть определено уникальное имя – текстовая строка внутри эллипса. Эктор – на рис. 15. Рис. 15. Нотация эктора на диаграмме Между экторами и прецедентами определяются отношения – ассоциации в виде соединяющих их линий. Задание: нарисуйте диаграмму прецедентов для системы «Оплата сотовой связи». Задание: нарисуйте диаграмму прецедентов для системы «Электронная почта». Прецеденты делятся на два вида: высокого уровня и развернутые. Прецеденты высокого уровня(high-level use case) – это очень краткие описания процессов, обычно состоящие из двух-трех предложений. Их используют начальном этапе при формулировании требований к системе. Это способ осознать степень сложности разрабатываемой системы, которые имеет слабое отношение к конкретному проектному решению. 48 Развернутые прецеденты(expanded use case) представляют собой более подробное описание, чем прецеденты первого вида. Они позволяют углубить понимание требований и процессов. Обычно оформляются в виде диалога между пользователем и программой. При этом всегда важно помнить: любой прецедент описывает, что делает система, но не определяет, каким образом она это делает. Ход работы Задание 1. На основании выбранной вами роли в АИС «Университет» и ранее проведенной ранее работы по выявлению характеристик данного пользователя (должностная инструкция, таблица характеристик (таблица 9), анкета, интервьюирование, анализ аналогов АИС и др.), составьте список требований этого пользователя к программе. Оформите их в виде предложений «система должна». При необходимости возможно повторить интервью для выявления требований пользователя. Задание 2. Работа в группе: составьте полный список требований к системе, удаляя дублирующиеся требования. Из полученного списка выделите требования, которые не подлежат реализации. Задание 3. Для выбранного вами пользователя на основании уточненного в задании 2 списка требований создайте диаграмму прецедентов высокого уровня. Для создания диаграмм можно воспользоваться: 1. Microsoft Visio. 2. Microsoft Visual Studio. 3. Онлайн сервис: http://creately.com/Draw-UML-and-Class-Diagrams- Online. 4. Онлайн сервис: https://www.draw.io/ 5. Онлайн сервис: http://yuml.me/. Если вы работаете в Microsoft Visio, то изучите следующую информацию. Назначение Visio Visio представляет собой векторный редактор, являющийся средством построения схем и диаграмм различного назначения. Visio позволяет создавать различные диаграммы, например, IDEF0, DFD, ERD, блок-схемы, диаграммы UML и др. 49 Общие сведения об интерфейсе Visio Вид окна Visio 2013 представлен на рис. 16. Рис. 16. Векторный редактор Visio Создание и редактирование диаграмм UML 1. Запустите программу Microsoft Visio 2013. 2. При первом запуске выберите опции и нажмите «Принять». Откроется окно выбора схемы. 3. Выберите вверху категорию «Программное обеспечение». 4. Нажмите левой кнопкой мыши по «Схема вариантов использования UML». 5. Затем «Создать». 6. С помощью инструментов на панели «Фигуры» создайте диаграмму, перемещая их на рабочее поле методом Drag&Drop. 7. Сохраните диаграмму. Рассмотрим некоторые особенности при работе с Visio: − изменение размеров объекта выполняется с помощью изменения положения прямоугольников, расположенных по контуру объекта. Если 50 менять положение прямоугольников, расположенных по серединам граней объекта, при нажатой клавише Shift, размеры фигуры меняются пропорционально; − поворот объекта вокруг его центра выполняется с помощью изменения положения круглой стрелки над объектом; − для изменения положения, размера или угла наклона группы объектов необходимо вначале выделить эти объекты при нажатой клавише Shift, а затем выполнить требуемое действие; − для создания надписи внутри объекта выполнить двойной щелчок левой кнопкой мыши при нахождении указателя мыши над объектом. Задание 4. Распределите сформулированные прецеденты между членами рабочей группы. Осуществите документирование предецентов любым из возможных способов. Например, в виде таблицы (таблица 11). Таблица 11 – Описание прецедента Прецедент Название прецедента (русское и английское). Исполнители Исполнители, работающие с прецедентом. Тип Какой тип (типы прецедентов будут рассмотрены ниже). Описание Словесное описание прецедента, состоящее из двух - трех предложений. Задание 5. Ответьте на следующие вопросы о проекте АИС «Университет»: 1. Кто является поставщиком информации в систему? 2. Кто будет пользоваться информацией из системы? 3. Кто будет удалять информацию из системы? 4. Кто будет управлять системой? 5. Где будет использоваться система? 6. Откуда пользователи будут получать информацию? 7. Имеются ли внешние системы, с которыми программа будет взаимодействовать? Укажите их. Задание 6. После ответов на вопросы из предыдущего задания посмотрите, все ли требования к системе вы учли? При необходимости дополните их и документируйте в виде диаграммы прецедентов. Контрольные вопросы 1. Что такое границы разрабатываемой системы? 51 2. Перечислите методы выявления требования заказчика, пользователей системы. 3. Укажите особенности диаграммы прецедентов UML. 4. Назовите возможные средства создания диаграмм UML. Каковы их преимущества, недостатки? 5. Какого уровня бывают прецеденты? 6. Как осуществляется документация прецедентов? По завершении занятия студент должен: 1. Знать способы выявления требований заказчика, пользователей. 2. Иметь представление о границах разрабатываемой системы. 3. Создавать списки требований к системе. 4. Иметь представление о диаграммах прецедентов UML, их назначении, возможностях при проектировании ИТ-проектов. 5. Создавать диаграммы прецедентов. 6. Добавлять новые варианты отчетов, в том числе с диаграммами. 7. Осуществлять документирование прецедентов высокого уровня. 52 Лабораторная работа № 8 Сценарии использования Цель: разработка прецедентов следующих уровней – развернутых прецедентов (сценариев использования). Теоретические вопросы Как уже было сказано ранее, на диаграмме прецедентов между прецедентами и экторами определяются только отношения ассоциации. При этом между элементами диаграммы прецедентов могут существовать различные отношения. Например, взаимодействие экземпляров экторов и вариантов использования. В языке UML существует несколько стандартных видов отношений между актерами или вариантами использования: − ассоциации (association relationship); − расширения (extend relationship); − общения (generalization relationship); − включения (include relationship). Обобщение представляет собой отношение между предком и потомком, а стрелка всегда указывает на предка. Кроме того, стрелка направлена в ту сторону, от которой что-то требуется, чьими сервисами пользуются. Пример отношения обобщения на рис. 17. Рис. 17. Отношение обобщения между прецедентами Отношение включения определяет, что внутри базового прецедента содержится поведение другого прецедента. Включаемый прецедент не существует сам по себе, это часть базового. Обозначается в виде пунктирной 53 линией со стрелкой на конце и подписью «include» (рис. 18). Стрелка направлена в сторону включаемого прецедента. Рис. 18. Пример отношения включения Такой вид отношения помогает избежать многократного описания одного и того же набора действий, т. к. общее поведение описывается в виде прецедента, включаемого в базовые. Отношения расширения дополняет прецедент другими прецедентами, выполняемых при некоторых условиях. Это позволяет добавить в исходный прецедент последовательность действий, содержащуюся в другом прецеденте. Обозначается в виде пунктирной линией со стрелкой на конце и подписью «extend» (рис. 19). Стрелка направлена в сторону расширяемого прецедента. Рис. 19. Пример отношения расширения При разработке диаграмм прецедентов с отношением расширения можно указать условия возникновения расширенного поведения и точку 54 расширения прецедента (Extension Point), куда подключаются действия из расширяющих прецедентов (рис. 20). Рис. 20. Обозначения точки расширения Согласно логике пирамиды требований, после формирования сценариев использования осуществляется разработка сценариев работы. Такие сценарии позволяют перейти от представления о том, «Что сделать», к пониманию того, «Как сделать» (рис. 21). Рис. 21. Переход от сценариев использования к сценариям работы Сценарий работы представляют собой конкретную последовательность действий, иллюстрирующих поведение системы. Существует несколько форм сценариев: 1. Текстовая форма. Пример создания сценария для использования банкомата: 55 − вставляем карту; − запрос PIN; − ввод PIN; − проверка PIN и т. д. 2. Табличная форма. Пример для использования банкомата в виде таблицы 12. Таблица 12 – Табличная форма сценария Действие пользователя Реакция системы Вставляем карту Запрос PIN Ввод PIN Проверка PIN 3. Текстовая форма от имени клиента. Например, как клиент санатория я хочу выбрать номер и забронировать его на определенный срок и …. Ход работы Задание 1. Для каждого прецедента первого уровня, полученного на основании предыдущей работы, провести его детализацию в виде диаграммы прецедентов. Задание 2. Произвести документирование каждого из детализированных прецедентов любым из возможных способов. Например, в виде таблицы (таблица 13). Таблица 13 – Описание развернутого прецедента Прецедент Имя прецедента Исполнители Перечень исполнителей (внешних агентов), а также те из них, кто инициирует данный прецедент Цель Цель прецедента Краткое описание Копия содержимого прецедента высокого уровня или некоторая аналогичная обобщенная информация Тип 1. Главный, второстепенный или дополнительный 2. Идеальный или реальный Ссылки Связанные прецеденты и (или) функции системы Задание 3. На основании сформированных диаграмм прецедентов предложить пользователям системы дальнейшие сценарии использования. Их можно оформить в виде таблицы (таблица 14). 56 Таблица 14 – Сценарии использования Типичный ход событий Действия исполнителя Отклик системы Пронумерованные действия исполнителей Пронумерованные описания откликов системы Альтернатива Описание Альтернатива, которая может возникнуть в строке с номером. Описание исключения, либо ссылка на соответствующий прецедент Задание 4. Для любого развернутого прецедента создайте сценарий в виде описания действий пользователя. Задание 5. С помощью любых средств нарисуйте PrintScrin для выбранного вами пользователя АИС «Университет» определенного ранее прецедента. Можно воспользоваться: 1. Средой разработки Visual Studio, Delphi и др. 2. Онлайн сервис для создания внешнего вида мобильных приложений и сайтов https://moqups.com/home/. 3. Онлайн сервис для создания диаграмм https://www.gliffy.com/. 4. Графические редакторы и др. Контрольные вопросы 1. Чем отличается прецедент высокого уровня от развернутого прецедента? 2. Какими методами можно документировать развернутые прецеденты? 3. Для чего формируются сценарии использования? 4. Как в дальнейшем могут использоваться эти сценарии? По завершении занятия студент должен: 1. Знает виды прецедентов: высокого уровня и развернутые. 2. Умеет описывать прецеденты различного уровня. 3. Осуществляет документирование прецедентов различного уровня. 4. Описывает типичный ход событий в сценариях использования, а также предусматривает возможность появления альтернативного хода. 57 Лабораторная работа №9 Ограничения проекта Цель: выявить возможные ограничения проекта АИС «Университет». Теоретические вопросы Если взглянуть на схему окружения проекта (рис. 22), то можно увидеть, как много всего необходимо учесть при его разработке. В связи с этим на проект и разрабатываемую систему накладываются ограничения. Рис. 22. Окружение проекта Выделают следующие ограничения, накладываемые на систему. 1. Экономические. К ним относят бюджет проекта, кроме того, сюда включается лицензия на программное средство разработки, аппаратное обеспечение, заработная плата и т. д. 2. Политические. Данный вид ограничений считается самым сложным. К ним могут относиться различного рода саботажи или особенности внутренней политики компании. 3. Технические. Здесь в качестве примера могут выступать технические мощности парка компьютеров компании, для которой ведется разработка проекта. 4. Системные, т.е. ограничения на стандарты. 5. Эксплуатационные. Это могут быть отключения электроэнергии, ограничения на использование сети Интернет и т. д. 58 6. График и ресурсы – аспекты, которые касаются графика работы компании, сроков разработки, количества задействованных лиц и т.п. Ход работы Задание 1. Методом мозгового штурма определите ограничения, накладываемые на АИС «Университет». Результат представьте в виде таблицы (таблица 15). Таблица 15 – Ограничения проекта АИС «Университет» Вид ограничения Ограничение проекта Экономические Политические Технические Системные Эксплуатационные График и ресурсы Задание 2 (индивидуально). Представьте в таблице (таблица 15) ограничения вашего проекта (Приложение). Контрольные вопросы 1. Что такое ограничение проекта? 2. Перечислите виды ограничений проекта. 3. Приведите примеры ограничений различных видов. По завершении занятия студент должен: 1. Знать понятие «ограничение проекта». 2. Иметь представление о видах ограничений. 3. Приводить примеры ограничений проекта. 59 Лабораторная работа № 10-11 Техническое задание для проекта АИС «Университет» Задание 1. Изучите значение термина «Техническое задание» с помощью сети Интернет. Дайте определение. Задание 2. Определите документы, регламентирующие составление технического задания на территории РФ. Задание 3. Определите преимущества и недостатки составления технического задания. Задание 4. Скачайте с сайта http://www.mastertz.ru/ программу «Мастер Технического Задания», изучите с помощью поиска в сети Интернет документацию по техническому заданию (ГОСТ 19, ГОСТ 34). Задание 5. Распределите роли в группе и с помощью программы «Мастер Технических Заданий» создайте документ Техническое задание для проекта АИС «Университет». 1. Из распакованного архива запустите программу mastertz.exe. Внешний вид программы представлен на рис. 23. Рис. 23. Внешний вид программы 60 2. На панели инструментов нажмите кнопку для создания нового ТЗ. Откроется следующая форма (рис. 24). Рис. 24. Окно создания ТЗ 3. Введите название проекта и выберите вид ТЗ (рис. 25). Рис. 25. Выбор ТЗ 4. По нажатию вида ТЗ откроется форма, которую необходимо заполнить (рис. 26). 61 Рис. 26.Форма заполнения ТЗ 5. По завершению ввода данных нажмите кнопку экспорта данных для формирования печатной формы ТЗ (рис. 27). Рис. 27. Печатная форма ТЗ 62 Задание 6. Защитите техническое задание. Контрольные вопросы 1. Что такое техническое задание? 2. На основании каких документов формируется техническое задание для разработки автоматизированной информационной системы? 3. Приведите примеры программных продуктов для формирования технического задания. По завершении занятия студент должен: 1. Знать понятие «техническое задание». 2. Иметь представление о содержании ГОСТ 19, ГОСТ 34. 3. Приводить примеры содержания технического задания информационной системы. 63 Лабораторная работа № 12–13 Реинженириг информационных систем Цель: осуществлять реинженириг информационных систем. Задание 1. Распределитесь в группы по 3-4 человека. Выберите одну из информационных систем для проведения анализа. 1. 1С:Университет http://solutions.1c.ru/catalog/university. 2. АИС «Университет» http://site.bsu.ru/univer/index.html. 3. Университетская информационная система НГУ http://www.nsu.ru/exp/university/uis. 4. Информационная система вашего университета. По выбранной системе представьте полный анализ (таблица 16). Таблица 16 – Анализ информационной системы Разработчик Требования к системе Стоимость Возможности Примеры внедрения Недостатки Задание 2. Для анализируемой системы составьте список возможных пользователей. Для каждого пользователя представьте список возможностей в системе. Задание 3. На основании полученного списка возможностей составьте список требований одного пользователя к системе. Задание 4. На основании списка требований к системе создайте диаграмму прецедентов. Задание 5. Выберите один прецедент и детализируйте его: уточните диаграмму прецедентов. Создайте документацию к нему. Задание 6. На основе детализации составьте сценарий работы пользователя, используя Printscreen’ы продукта. Задание 7. Подумайте, какие еще возможности, требования могут появиться у пользователя в ходе работы с системой. Выявились ли в ходе ре- инжениринга недостатки системы? Контрольные вопросы 1. Что такое реинжениринг? 64 2. С какой целью проводится реинжениринг? По завершении занятия студент должен: 1. Знать понятие «реинжениринг». 2. Иметь представление о возможностях методах реинжениринга при проектировании программных продуктов. 65 Лабораторная работа №14-16 Конвейер проектов Цель: использование методов программной инженерии при разработке курсового проекта. Теоретические вопросы Наверно, вы уже сталкивались в сети Интернет с таким комиксом (рис. 28). Он хоть и в шутливой форме отражает порой реальный процесс проектирования. Следовательно, задача группы разработчиков прийти в единому пониманию и видению проекта. Рис. 28. Действия группы разработчиков проекта После того как проект создан, его надо подготовить к передаче заказчику. Если это касается курсового проекта, то можно говорить о его презентации. Презентация также понадобится, если хотите представить проект будущим инвесторам, т. е. провести коммерциализацию проекта. 66 Самым наглядным пониманием того, что сам проект и его презентация – разные вещи, является инсталляция из музея современного искусства (рис. 29). Рис. 29. Инсталляция Следовательно, даже самый плохой проект может произвести хорошее впечатление, если его правильно презентовать. Однако на самом деле – презентация не главное (рис. 30). 67 Рис. 30. Представление презентации проекта В качестве презентации можно представить несколько слайдов, распечатку или тизер проекта (под тизером понимается небольшое предложение о проекте). Однако в самой презентации не всегда указывают модель бизнеса и его детали (например, способы продвижения проекта, его производственный цикл, будущих клиентов, способы их обслуживания, необходимые ресурсы, возможных партнеры), планы работы, бюджет и т. п. Задание: представьте тизер вашего проекта. Например, Instagram – это бесплатное мобильное приложение для обмена, создания, редактирования и распространения фото и видео с элементами социальной сети. Если вы составляете распечатку особенностей своего проекта, то необходимо уложиться на одну страницу формата А4 (например, рис. 31). 68 Рис. 31. Пример информации о проекте При создании презентации проекта для инвесторов, можно придерживаться следующей структуры: − титульный слайд (название проекта, контакты команды); − команда (состав команды, контакты членов команды, можно фото); − содержание проекта (основные предложения, целевая аудитория, решаемая проблема); − состояние рынка (аналоги или похожие компании, с указанием объемов рынка, цен на программные продукты и т. п.); − финансовая модель (необходимая сумма, статьи расходов). Необходимо уложиться в 10-12 слайдов. Изложение должно быть простым, понятным, кратким, сопровождаться фактами и аргументироваться |