надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ КАФЕДРА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ МОДЕЛИРОВАНИЯ И УПРАВЛЕНИЯ Методические указания к выполнению лабораторных работ по курсу «ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ» Для студентов бакалавриата, обучающихся по направлению – 230400 " Информационные системы и технологии ", дистанционной формы обучения Воронеж 2014 Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Номер индивидуального задания выбирается по 2-м по- следним цифрам шифра № вар. № вар. № вар. № вар. № вар. № вар. № вар. 01 1 16 16 31 3 46 18 61 5 76 20 91 7 02 2 17 17 32 4 47 19 62 6 77 21 92 8 03 3 18 18 33 5 48 20 63 7 78 22 93 9 04 4 19 19 34 6 49 21 64 8 79 23 94 10 05 5 20 20 35 7 50 22 65 9 80 24 95 11 06 6 21 21 36 8 51 23 66 10 81 25 96 12 07 7 22 22 37 9 52 24 67 11 82 26 97 13 08 8 23 23 38 10 53 25 68 12 83 27 98 14 09 9 24 24 39 11 54 26 69 13 84 28 99 15 10 10 25 25 40 12 55 27 70 14 85 1 11 11 26 26 41 13 56 28 71 15 86 2 12 12 27 27 42 14 57 1 72 16 87 3 13 13 28 28 43 15 58 2 73 17 88 4 14 14 29 1 44 16 59 3 74 18 89 5 15 15 30 2 45 17 60 4 75 19 90 6 Например, если 2 последние цифры вашего шифра – 95, то ваш вариант – 11 Задания по вариантам: 1. ИС Ресторан 2. ИС Отдел кадров 3. ИС Гостиница 4. ИС Больница 5. ИС Аптека 6. ИС Аэропорт 7. ИС Видеопрокат 8. ИС Компьютерная фирма 9. ИС Библиотека 10. ИС Туристическое агентство 11. ИС Сервисный центр 12. ИС Деканат 13. ИС Прокат автомобилей 14. ИС Ломбард 15. ИС Риэлтерская фирма 16. ИС Рекламное агентство 17. ИС Автосалон 18. ИС Продуктовый магазин Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 19. ИС Учет готовой продукции 20. ИС Банк 21. ИС Книжный магазин 22. ИС Магазин бытовой техники 23. ИС Успеваемость студентов 24. ИС Паспортный стол 25. ИС Склад товаров 26. ИС Кинотеатр 27. ИС Учет услуг спортивного клуба 28. ИС Косметический салон Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Лабораторная работа № 1 «Разработка описания и анализ информационной системы» Цель работы: Описать и проанализировать информационную систему, распределить роли в группе разработчиков. Лабораторная работа направлена на ознакомление с процес- сом описания информационной системы и получение навыков по ис- пользованию основных методов анализа ИС. Требования к результатам выполнения: наличие описания информационной системы; наличие заключения о возможности реализации проек- та, содержащего рекомендации относительно разра- ботки системы, базовые предложения по объѐму тре- буемого бюджета, числу разработчиков, времени и требуемому программному обеспечению. Теоретические сведения Общие сведения о разработке программного обеспечения Проблемы управления программными проектами впервые проявились в 60-х - начале 70-х годов, когда провалились многие большие проекты по разработке программных продуктов. Были за- фиксированы задержки в создании ПО, оно было ненадежным, затра- ты на разработку в несколько раз превосходили первоначальные оценки, созданные программные системы часто имели низкие показа- тели производительности. Причины провалов коренились в тех под- ходах, которые использовались в управлении проектами. Применяе- мая методика была основана на опыте управления техническими про- ектами и оказалась неэффективной при разработке программного обеспечения. Важно понимать разницу между профессиональной разработ- кой ПО и любительским программированием. Необходимость управ- ления программными проектами вытекает из того факта, что процесс создания профессионального ПО всегда является субъектом бюджет- ной политики организации, где оно разрабатывается, и имеет времен- ные ограничения. Работа руководителя программного проекта по большому счету заключается в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ПО. Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контролиро- вать ход выполнения работ и соблюдения всех требуемых стандартов. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Постоянный контроль за ходом выполнения работ необходим для то- го, чтобы процесс разработки не выходил за временные и бюджетные ограничения. Хорошее управление не гарантирует успешного завер- шения проекта, но плохое управление обязательно приведет к его про- валу. Это может выразиться в задержке сроков сдачи готового ПО, в превышении сметной стоимости проекта и в несоответствии готового ПО спецификации требований. Процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами: 1. Программный продукт нематериален. Программное обеспе- чение нематериально, его нельзя увидеть или потрогать. Руко- водитель программного проекта не видит процесс "роста" раз- рабатываемого ПО. Он может полагаться только на докумен- тацию, которая фиксирует процесс разработки программного продукта. 2. Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий много- кратно опробованы и проверены. Процессы создания боль- шинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только по- следнее время. Поэтому пока нельзя точно предсказать, на ка- ком этапе процесса разработки ПО могут возникнуть пробле- мы, угрожающие всему программному проекту. 3. Большие программные проекты - это часто "одноразовые" проекты. Большие программные проекты, как правило, значи- тельно отличаются от проектов, реализованных ранее. Поэто- му, чтобы уменьшить неопределенность в планировании про- екта, руководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изме- нения в компьютерной технике и коммуникационном обору- довании обесценивают предыдущий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проек- те. Перечисленные отличия могут привести к тому, что реализа- ция проекта выйдет из временного графика или превысит бюджетные ассигнования. Программные системы зачастую оказываются новинка- ми как в "идеологическом", так и в техническом плане. Поэтому, Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно выходить за рамки временных и бюджетных ограничений. Процесс управления разработкой программного обеспече- ния Невозможно описать и стандартизировать все работы, выпол- няемые в проекте по созданию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие: Написание предложений по созданию ПО. Планирование и составление графика работ по созданию ПО. Оценивание стоимости проекта. Подбор персонала. Контроль за ходом выполнения работ. Написание отчетов и представлений. Первая стадия программного проекта может состоять из напи- сания предложений по реализации этого проекта. Предложения долж- ны содержать описание целей проектов и способов их достижения. Они также обычно включают в себя оценки финансовых и временных затрат на выполнение проекта. При необходимости здесь могут при- водиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков. Написание предложений — очень ответственная работа, так как для многих организаций вопрос о том, будет ли проект выпол- няться самой организацией или разрабатываться по контракту сторон- ней компанией, является критическим. Не существует каких-либо ре- комендаций по написанию предложений, многое здесь зависит от опыт. На этапе планирования проекта определяются процессы, эта- пы и полученные на каждом из них результаты, которые должны при- вести к выполнению проекта. Реализация этого плана приведет к дос- тижению целей проекта. Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана. Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Руководитель должен постоянно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторинга работ, опытный руководитель Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко может составить ясную картину о стадии развитии проекта просто пу- тем неформального общения с разработчиками. Неформальный мониторинг часто помогает обнаружить по- тенциальные проблемы, которые в явном виде могут обнаружиться позднее. Например, ежедневное обсуждение хода выполнения работ может выявить отдельные недоработки в создаваемом программном продукте. Вместо ожидания отчетов, в которых будет отражен факт "пробуксовки" графика работ, можно обсудить со специалистами на- мечающиеся программистские проблемы и не допустить срыва графи- ка работ. В течение реализации проекта обычно происходит несколько формальных контрольных проверок хода выполнения работ по созда- нию ПО. Такие проверки должны дать общую картину хода реализа- ции проекта в целом и показать, насколько уже разработанная часть ПО соответствует целям проекта. Время выполнения больших программных проектов может за- нимать несколько лет. В течение этого времени цели и намерения ор- ганизации, заказавшей программный проект, могут существенно из- мениться. Может оказаться, что разрабатываемый программный про- дукт стал уже ненужным либо исходные требования к создаваемому ПО просто устарели и их необходимо кардинально менять. В такой ситуации руководство организации-разработчика может принять ре- шение о прекращении разработки ПО или об изменении проекта в це- лом с тем, чтобы учесть изменившиеся цели и намерения организа- ции-заказчика. Руководители проектов обычно обязаны сами подбирать ис- полнителей для своих проектов. В идеальном случае профессиональ- ный уровень исполнителей должен соответствовать той работе, кото- рую они будут выполнять в ходе реализации проекта. Однако во мно- гих случаях руководители должны полагаться на команду разработчи- ков, которая далека от идеальной. Такая ситуация может быть вызвана следующими причинами: 1. Бюджет проекта не позволяет привлечь высококвалифициро- ванный персонал. В таком случае за меньшую плату привле- каются менее квалифицированные специалисты. 2. Бывают ситуации, когда невозможно найти специалистов не- обходимой квалификации как в самой организации- разработчике, так и вне ее. Например, в организации "лучшие люди" могут быть уже заняты в других проектах. 3. Организация хочет повысить профессиональный уровень сво- их работников. В этом случае она может привлечь к участию в Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко проекте неопытных или недостаточно квалифицированных ра- ботников, чтобы они приобрели необходимый опыт и по- учились у более опытных специалистов. Таким образом, почти всегда подбор специалистов для выпол- нения проекта имеет определенные ограничения и не является сво- бодным. Вместе с тем необходимо, чтобы хотя бы несколько членов группы разработчиков имели квалификацию и опыт, достаточные для работы над данным проектом. В противном случае невозможно избе- жать ошибок в разработке ПО. Руководитель проекта обычно обязан посылать отчеты о ходе его выполнения как заказчику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извле- каемой из подробных' отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта. В рамках курса выделены следующие роли в группе по разработке ПО: Руководитель – общее руководство проектом, написание документации, общение с заказчиком ПО Системный аналитик – разработка требований (составле- ние технического задания, проекта программного обеспе- чения) Тестер – составление плана тестирования и аттестации го- тового ПО (продукта), составление сценария тестирования, базовый пример, проведение мероприятий по плану тести- рования Разработчик – моделирование компонент программного обеспечения, кодирование Планирование проекта разработки программного обеспе- чения Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предвидеть проблемы, ко- торые могут возникнуть на каких-либо этапах создания ПО, и разра- ботать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение кото- рого должно привести к успешному завершению проекта. Этот перво- начальный план должен максимально подробно описывать все этапы реализации проекта. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Процесс планирования начинается, исходя из описания систе- мы, с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть полу- чены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ. Далее, по мере поступления новой информации о ходе выпол- нения проекта, возможен пересмотр первоначальных оценок парамет- ров проекта. Это, в свою очередь, может привести к изменению гра- фика работ. Если в результате этих изменений нарушаются сроки за- вершения проекта, должны быть пересмотрены (и согласованы с за- казчиком ПО) проектные ограничения. Конечно, большинство руководителей проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Же- лательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять "песси- мистические" графики работ, чем "оптимистические". Но, конечно, невозможно построить план, учитывающий все, в том числе случай- ные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта. План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной гра- фик выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта. Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации- разработчика. Но в любом случае большинство планов содержат сле- дующие разделы. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 1. Введение. Краткое описание целей проекта и проектных огра- ничений (бюджетных, временных и т.д.), которые важны для управления проектом. 2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды. 3. Анализ рисков. Описание возможных проектных рисков, веро- ятности их проявления и стратегий, направленных на их уменьшение. 4. Аппаратные и программные ресурсы, необходимые для реали- зации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, при- водится их стоимость совместно с графиком закупки и постав- ки. 5. Разбиение работ на этапы. Процесс реализации проекта раз- бивается на отдельные процессы, определяются этапы выпол- нения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. 6. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов ко- манды разработчиков по отдельным этапам. 7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые руководителем отче- ты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта. План должен регулярно пересматриваться в процессе реализа- ции проекта. Одни части плана, например график работ, изменяются часто, другие более стабильны. Для внесения изменений в план требу- ется специальная организация документопотока, позволяющая от- слеживать эти изменения. Общие сведения о требованиях к информационным систе- мам Проблемы, которые приходится решать специалистам в про- цессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая про- граммная система инновационная. В частности, трудно чѐтко описать те действия, которые должна выполнять система. Описание функцио- нальных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирова- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко ния, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований. Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неѐ. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реа- лизации требований пользователя. Первые шаги по разработке требований к информацион- ным системам - анализ осуществимости Разработка требований — это процесс, включающий меро- приятия, необходимые для создания и утверждения документа, со- держащего спецификацию системных требований. Для новых про- граммных систем процесс разработки требований должен начинаться с анализа осуществимости. Началом такого анализа является общее описание системы и ее назначения, а результатом анализа — отчет, в котором должна быть четкая рекомендация, продолжать или нет про- цесс разработки требований проектируемой системы. Другими слова- ми, анализ осуществимости должен осветить следующие вопросы. 1. Отвечает ли система общим и бизнес-целям организации- заказчика и организации-разработчика? 2. Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости? 3. Можно ли объединить систему с другими системами, которые уже эксплуатируются? Критическим является вопрос, будет ли система соответство- вать целям организации. Если система не соответствует этим целям, она не представляет никакой ценности для организации. В то же время многие организации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая эти цели, либо под влиянием по- литических или общественных факторов. Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе и написание соответствующего отче- та. Сначала следует определить, какая именно информация необходи- ма, чтобы ответить на поставленные выше вопросы. Например, эту информацию можно получить, ответив на следующее: 1. Что произойдет с организацией, если система не будет введена в эксплуатацию? Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 2. Какие текущие проблемы существуют в организации и как но- вая система поможет их решить? 3. Каким образом система будет способствовать целям бизнеса? 4. Требует ли разработка системы технологии, которая до этого не использовалась в организации? Далее необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, технологи, конечные пользователи и т.д. После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе. Порядок выполнения работы 1. Изучить предлагаемый теоретический материал. 2. Составить подробное описание информационной системы по индивидуальномц варианту. 3. На основании описания системы провести анализ осуществи- мости. В ходе анализа ответить на вопросы: Что произойдет с организацией, если система не будет вве- дена в эксплуатацию? Какие текущие проблемы существуют в организации и как новая система поможет их решить? Каким образом система будет способствовать целям бизне- са? Требует ли разработка системы технологии, которая до этого не использовалась в организации? Результатом анализа должно явиться заключение о возможно- сти реализации проекта. 4. Распределить роли в группе (руководитель проекта- разработчик, системный аналитик-разработчик, тестер- разработчик). 5. Заполнить разделы плана: Введение Организация выполнения проекта Анализ рисков Разделы должны содержать рекомендации относительно раз- работки системы, базовые предложения по объѐму требуемого бюд- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко жета, числу разработчиков, времени и требуемому программному обеспечению. 6. Составить отчет о проделанной работе. Содержание отчета В отчете следует указать: 1. Цель работы 2. Введение. Краткое описание целей проекта и проектных огра- ничений (бюджетных, временных и т.д.), которые важны для управления проектом 3. Описание информационной системы (ПО) - наличие заключе- ния о возможности реализации проекта, содержащего реко- мендации относительно разработки системы, базовые предло- жения по объѐму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению 4. Анализ осуществимости, указать возможные проблемы и пути их решения. 5. Роли участников группы разработки ПО. 6. Программно-аппаратные средства, используемые при выпол- нении работы. 7. Заключение (выводы) 8. Список используемой литературы Литература 1. Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом ―Вильямс‖, 2002. – 624 с. 2. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с. 3. Константайн Л., Локвуд Л. Разработка программного обеспе- чения. – СПб.:Питер, 2004. – 592 с. 4. Иванова Г.С. Технология программирования: Учебник для ву- зов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Лабораторная работа № 2 «Разработка требований к информационной системе» Цель работы: Составить и проанализировать требования к информационной системе, оформить техническое задание на разра- ботку программного обеспечения. Лабораторная работа направлена на ознакомление с процес- сом разработки требований к информационной системе и составления технического задания на разработку программного обеспечения, по- лучение навыков по использованию основных методов формирования и анализа требований. Требования к результатам выполнения: наличие диаграммы идентификации точек зрения и диаграммы иерархии точек зрения; наличие сценариев событий (последовательности дей- ствий); наличие пользовательских требований, четко описы- вающих будущий функционал системы; наличие системных требований, включающих требова- ния к структуре, программному интерфейсу, техноло- гиям разработки, общие требования к системе (надеж- ность, масштабируемость, распределѐнность, модуль- ность, безопасность, открытость, удобство пользования и т.д.); наличие составленного технического задания. Теоретические сведения Общие сведения о требованиях к информационным сис- |