надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
Действие Действием (action), как уже говорилось, является непреры- ваемое поведение, осуществляющееся как часть перехода. Входные и выходные действия показывают внутри состояний, поскольку они оп- ределяют, что происходит, когда объект входит или выходит из него. Большую часть действий, однако, изображают вдоль линии пере- хода, так как они не должны осуществляться при входе или выходе из состояния. Действие рисуют вдоль линии перехода после имени события, ему предшествует косая черта. Событие или действие могут быть поведением внутри объекта, а могут представлять собой сообщение, посылаемое дру- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко гому объекту. Если событие или действие посылается другому объекту, перед ним на диаграмме помещают знак « ^ ». Рис. 4.18. Пример диаграммы состояний Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма. Диаграммы размещения Диаграмма размещения (deployment diagram) отражает физи- ческие взаимосвязи между программными и аппаратными компо- нентами системы. Она является хорошим средством для того, что- бы показать маршруты перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве слу- чаев, часть аппаратуры. Эта аппаратура может быть простым устрой- ством или датчиком, а может быть и мэйнфреймом. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 4.19. Пример диаграммы размещения Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персо- налом, чтобы понять физическое размещение системы и располо- жение еѐ отдельных подсистем. Диаграммы компонентов Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты про- граммного обеспечения и связи между ними. При этом на такой диа- грамме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в ком- понент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изобра- жают зависимости, соответствующие зависимостям на этапе компи- ляции или выполнения программы. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 4.20. Пример диаграммы компонентов Диаграммы компонентов применяются теми участниками про- екта, кто отвечает за компиляцию системы. Из нее видно, в каком по- рядке надо компилировать компоненты, а также какие исполняе- мые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода. Объединение диаграмм компонентов и развертывания В некоторых случаях допускается размещать диаграмму ком- понентов на диаграмме развертывания. Это позволяет показать какие компоненты выполняются и на каких узлах. Порядок выполнения работы 1. Изучить предлагаемый теоретический материал. 2. Постройте диаграмму вариантов использования для выбран- ной информационной системы. 3. Выполните реализацию вариантов использования в терминах взаимодействующих объектов и представляющую собой набор диаграмм: диаграмм классов, реализующих вариант использования; диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм), отражающих взаимодейст- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко вие объектов в процессе реализации варианта использо- вания. 4. Разделить классы по пакетам использую один из механизм разбиения. 5. Постройте диаграмму состояний для конкретных объектов информационной системы. 6. Построить отчѐт, включающий все полученные уровни моде- ли, описание функциональных блоков, потоков данных, хра- нилищ и внешних объектов. Содержание отчета В отчете следует указать: 1. Цель работы 2. Введение 3. Программно-аппаратные средства, используемые при выпол- нении работы. 4. Основную часть (описание самой работы), выполненную со- гласно требованиям к результатам выполнения лабораторного практикума. 5. Заключение (выводы) 6. Список используемой литературы Литература: 1. http://www.uml.org 2. http://www.uml.ru 3. http://www.uml2.ru 4. http://www.omg.org/technology/documents/formal/uml.htm 5. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – С-П.: Издательство «Питер», 2003. – 432 с. 6. Шмуллер Дж. Освой самостоятельно UML 2 за 24 часа. Прак- тическое руководство. - М.: «Вильямс», 2005. - 416 с. Контрольные вопросы 1. Дайте определение понятию «вариант использования». 2. Какие типы связи могут присутствовать на диаграмме ва- риантов использования? 3. Дайте определение понятию «действующее лицо». 4. Какие типы сообщений могут присутствовать на диаграм- мах взаимодействия? 5. Дайте определение понятию класс, объект класса. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 6. Кем и для чего может быть использована диаграмма раз- мещения? Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Лабораторная работа №5 «Методология управление проектами» Цель работы: Изучение методологии управления проектами. Получение навыков по применению данных методологий для плани- рования проекта. Лабораторная работа направлена на ознакомление с основны- ми понятиями методологии управления проектами, получение навы- ков по применению данных понятий при построении плана проекта, построения графика работ, распределения исполнителей, управления рисками. Требования к результатам выполнения: Построить модель управления проектом. Модель включает: определение всех этапов проекта, зависимых этапов, определение длительности этапов; построение на основе полученных данных сетевой и временной диаграмм; построение диаграммы распределения работников по этапам; при определении этапа указывается его название – от- ражающее суть этапа (например, определение пользо- вательских требований, проектирование интерфейса и т.д.); этапов должно быть не менее 7, срок реализации про- екта – пол года; в проекте задействовано 6 человек персонала, некото- рые из них участвуют на нескольких этапах проекта. Теоретический материал Основные понятия Проблемы управления программными проектами впервые проявились в 60-х — начале 70-х годов. Руководители программных проектов выполняют такую же работу, что и руководители техниче- ских проектов. Вместе с тем процесс разработки ПО существенно от- личается от процессов реализации технических проектов, что порож- дает определенные сложности в управлении программными проекта- ми. Ниже приведѐн краткий список этих отличий. 1. Программный продукт нематериален. Менеджер техническо- го проекта видит результаты выполнения своего проекта. Если реализация проекта отстает от графика, это также видно во- очию. В противоположность этому программное обеспечение Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко нематериально. Его нельзя увидеть или потрогать. Менеджер программного проекта не видит процесс "роста" разрабаты- ваемого ПО. Он может полагаться только на документацию, которая фиксирует процесс разработки программного продук- та. 2. Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий много- кратно опробованы и проверены. Процессы создания боль- шинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только не- сколько последних лет. Поэтому пока нельзя точно предска- зать, на каком этапе процесса разработки ПО могут возник- нуть проблемы, угрожающие всему программному проекту. 3. Большие программные проекты - это часто "одноразовые" проекты. Большие программные проекты, как правило, значи- тельно отличаются от проектов, реализованных ранее. Поэто- му, чтобы уменьшить неопределенность в планировании про- екта, руководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изме- нения в компьютерной технике и коммуникационном обору- довании обесценивают предыдущий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проек- те. Перечисленное выше может привести к тому, что реализация проекта выйдет из временного графика или превысит бюджетные ас- сигнования. Программные системы зачастую оказываются новинками как в "идеологическом", так и в техническом плане. Технические про- екты, которые являются инновационными (например, новая транс- портная система), также часто нарушают временные графики работ. Поэтому, предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно вы- ходить за рамки временных и бюджетных ограничений. Планирование проекта Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает менеджеру предвидеть проблемы, кото- рые могут возникнуть на каких-либо этапах создания ПО, и разрабо- тать превентивные меры для их предупреждения или решения. План, Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первона- чальный план должен максимально подробно описывать все этапы реализации проекта. Кроме разработки плана проекта, на менеджера ложится обя- занность разработки других видов планов. Эти виды планов кратко описаны в табл. 5.1. Таблица 5.1 - Виды планов План Описание План качества Описывает стандарты и мероприятия по под- держке качества разрабатываемого ПО План аттестации Описывает способы, ресурсы и перечень работ, необходимых для аттестации программной сис- темы План управления конфигурацией Описывает структуру и процессы управления конфигурацией План сопровож- дения ПО Предлагает план мероприятий, требующихся для сопровождения ПО в процессе его эксплуатации, а также расчет стоимости сопровождения и необ- ходимые для этого ресурсы План по управле- нию персоналом Описывает мероприятия, направленные на по- вышение квалификации членов команды разра- ботчиков В листинге 1 показан процесс планирования создания ПО в виде псевдокода. Здесь сделан акцент на том, что планирование — это итерационный процесс. Поскольку в процессе выполнения проекта постоянно поступает новая информация, план должен регулярно пере- сматриваться. Важными факторами, которые должны учитываться при разработке плана, являются финансовые и деловые обязательства ор- ганизации. Если они изменяются, эти изменения также должны найти отражение в плане работ. Листинг 1. Процесс планирования проекта Определение проектных ограничений Первоначальная оценка параметров проекта Определение этапов выполнения проекта и контрольных отме- ток while пока проект не завершится или не будет остановлен loop Составление графика работ Начало выполнения работ Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Ожидание окончания очередного этапа работ Отслеживание хода выполнения работ Пересмотр оценок параметров проекта Изменение графика работ Пересмотр проектных ограничений if (возникла проблема) then Пересмотр технических или организационных параметров проекта end if end loop Процесс планирования начинается с определения проектных ограничений (временные ограничения, возможности наличного пер- сонала, бюджетные ограничения и т.д.). Эти ограничения должны оп- ределяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, ка- кие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого (обычно через 2-3 недели) проводится контроль выполне- ния работ и отмечаются расхождения между реальным и плановым ходом работ. Далее, по мере поступления новой информации о ходе выпол- нения проекта, возможен пересмотр первоначальных оценок парамет- ров проекта. Это, в свою очередь, может привести к изменению гра- фика работ. Если в результате этих изменений нарушаются сроки за- вершения проекта, должны быть пересмотрены (и согласованы с за- казчиком ПО) проектные ограничения. Конечно, большинство менеджеров проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Жела- тельно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять "песси- мистические" графики работ, чем "оптимистические". Но, конечно, невозможно построить план, учитывающий все, в том числе случай- ные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта. План проекта Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной гра- фик выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта. План, представленны ниже, принадлежит именно к последне- му типу планов. Детализация планов проектов очень разнится в зави- симости от типа разрабатываемого программного продукта и органи- зации-разработчика. Но в любом случае большинство планов содер- жат следующие разделы. 1. Введение. Краткое описание целей проекта и проектных огра- ничений (бюджетных, временных и т.д.), которые важны для управления проектом. 2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды. 3. Анализ рисков. Описание возможных проектных рисков, веро- ятности их проявления и стратегий, направленных на их уменьшение. Тема управления рисками рассмотрена ниже. 4. Аппаратные и программные ресурсы, необходимые для реали- зации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, при- водится их стоимость совместно с графиком закупки и постав- ки. 5. Разбиение работ на этапы. Процесс реализации проекта раз- бивается на отдельные процессы, определяются этапы выпол- нения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. Эта тема представлена ниже. 6. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов ко- манды разработчиков по отдельным этапам. 7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко План должен регулярно пересматриваться в процессе реализа- ции проекта. Одни части плана, например график работ, изменяются часто, другие более стабильны. Для внесения изменений в план требу- ется специальная организация документопотока, позволяющая от- слеживать эти изменения. Контрольные отметки этапов работ Менеджеру для организации процесса создания ПО и управле- ния им необходима информация. Поскольку само программное обес- печение неосязаемо, эта управленческая информация может быть по- лучена только в виде документов, отображающих выполнение оче- редного этапа разработки программного продукта. Без этой информа- ции нельзя судить о степени готовности создаваемого продукта, не- возможно оценить произведенные затраты или изменить график ра- бот. При планировании процесса определяются контрольные от- метки— вехи, отмечающие окончание определенного этапа работ. Для каждой контрольной отметки создается отчет, который предоставля- ется руководству проекта. Эти отчеты не должны быть большими объемными документами; они должны подводить краткие итоги окон- чания отдельного логически завершенного этапа проекта. Этапом не может быть, например, "Написание 80% кода программ", поскольку невозможно проверить завершение такого "этапа"; кроме того, подоб- ная информация практически бесполезна для управления, поскольку здесь не отображается связь этого "этапа" с другими этапами создания ПО. Обычно по завершении основных больших этапов, таких как разработка спецификации, проектирование и т.п., заказчику ПО пре- доставляются результаты их выполнения, так называемые контроль- ные проектные элементы. Это может быть документация, прототип программного продукта, законченные подсистемы ПО и т.д. Кон- трольные проектные элементы, предоставляемые заказчику ПО, могут совпадать с контрольными отметками (точнее, с результатами выпол- нения какого-либо этапа). Но обратное утверждение неверно. Кон- трольные отметки — это внутренние проектные результаты, которые используются для контроля за ходом выполнения проекта, и они, как правило, не предоставляются заказчику ПО. Для определения контрольных отметок весь процесс создания ПО должен быть разбит на отдельные этапы с указанным "выходом" (результатом) каждого этапа. Например, на рис. 5.1 показаны этапы разработки спецификации требований в случае, когда для ее проверки используется прототип системы, а также представлены выходные ре- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко зультаты (контрольные отметки) каждого этапа. Здесь контрольными проектными элементами являются требования и спецификация требо- ваний. Рис. 5.1. Этапы процесса разработки спецификации |