Лабораторная работа №1 «Разработка описания и анализ информационной системы» icon

Лабораторная работа №1 «Разработка описания и анализ информационной системы»


Скачать 40.87 Kb.
НазваниеЛабораторная работа №1 «Разработка описания и анализ информационной системы»
Размер40.87 Kb.
ТипЛабораторная работа

Лабораторная работа № 1

«Разработка описания и анализ информационной системы»

1.     Цель работы:

Описать и проанализировать информационную систему, распределить роли в группе разработчиков.

2.      Методические указания

Лабораторная работа направлена на ознакомление с процессом описания информационной системы и получение навыков по использованию основных методов анализа ИС.

Требования к результатам выполнения лабораторного практикума:

  1. наличие описания информационной системы;

  2. проведение анализа осуществимости выполнения проекта;

  3. наличие заключения о возможности реализации проекта, содержащего  рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению.

^ 3.     Теоретические сведения

Общие сведения о разработке программного обеспечения

Проблемы управления программными проектами впервые проявились в 60-х - начале 70-х годов, когда провалились многие большие проекты по разработке программных продуктов. Были зафиксированы задержки в создании ПО, оно было ненадежным, затраты на разработку в несколько раз превосходили первоначальные оценки, созданные программные системы часто имели низкие показатели производительности. Причины провалов коренились в тех подходах, которые использовались в управлении проектами. Применяемая методика была основана на опыте управления техническими проектами и оказалась неэффективной при разработке программного обеспечения.

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

^ Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контролировать ход выполнения работ и соблюдения всех требуемых стандартов. Постоянный контроль за ходом выполнения работ необходим для того, чтобы процесс разработки не выходил за временные и бюджетные ограничения. Хорошее управление не гарантирует успешного завершения проекта, но плохое управление обязательно приведет к его провалу. Это может выразиться в задержке сроков сдачи готового ПО, в превышении сметной стоимости проекта и в несоответствии готового ПО спецификации требований.

Процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами:

  1.  ^ Программный продукт нематериален. Программное обеспечение нематериально, его нельзя увидеть или потрогать. Руководитель программного проекта не видит процесс "роста" разрабатываемого ПО. Он может полагаться только на документацию, кото­рая фиксирует процесс разработки программного продукта.

  2. ^ Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программно­го продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только последнее время. Поэтому пока нельзя точно предсказать, на каком этапе процесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту.

  3. ^ Большие программные проекты - это часто "одноразовые" проекты. Большие программные проекты, как правило, значительно отличаются от проектов, реализованных ранее. Поэтому, чтобы уменьшить неопределенность в планировании проекта, ру­ководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изменения в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. Знания и навыки, накоп­ленные опытом, могут не востребоваться в новом проекте.

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

^ Процесс управления разработкой программного обеспечения

Невозможно описать и стандартизировать все работы, выполняемые в проекте по созданию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие:

  • Написание предложений по созданию ПО.

  • Планирование и составление графика работ по созданию ПО.

  • Оценивание стоимости проекта.

  • Подбор персонала.

  • Контроль за ходом выполнения работ.

  • Написание отчетов и представлений.

Первая стадия программного проекта может состоять из написания предложений по реализации этого проекта. Предложения должны содержать описание целей проектов и способов их достижения. Они также обычно включают в себя оценки финансовых и вре­менных затрат на выполнение проекта. При необходимости здесь могут приводиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков.

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

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

^ Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Руководитель дол­жен постоянно отслеживать ход реализации проекта и сравнивать фактические и пла­новые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторинга работ, опытный руководитель может составить яс­ную картину о стадии развитии проекта просто путем неформального общения с разра­ботчиками.

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

В течение реализации проекта обычно происходит несколько формальных контроль­ных проверок хода выполнения работ по созданию ПО. Такие проверки должны дать об­щую картину хода реализации проекта в целом и показать, насколько уже разработанная часть ПО соответствует целям проекта.

Время выполнения больших программных проектов может занимать несколько лет. В те­чение этого времени цели и намерения организации, заказавшей программный проект, могут существенно измениться. Может оказаться, что разрабатываемый программный продукт стал уже ненужным либо исходные требования к создаваемому ПО просто устарели и их необходи­мо кардинально менять. В такой ситуации руководство организации-разработчика может при­нять решение о прекращении разработки ПО или об изменении проекта в целом с тем, чтобы учесть изменившиеся цели и намерения организации-заказчика.

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

  1. Бюджет проекта не позволяет привлечь высококвалифицированный персонал. В таком случае за меньшую плату привлекаются менее квалифицированные специалисты.

  2. Бывают ситуации, когда невозможно найти специалистов необходимой квалифика­ции как в самой организации-разработчике, так и вне ее. Например, в организации "лучшие люди" могут быть уже заняты в других проектах.

  3. Организация хочет повысить профессиональный уровень своих работников. В этом случае она может привлечь к участию в проекте неопытных или недостаточно квалифицированных работников, чтобы они приобрели необходимый опыт и по­учились у более опытных специалистов.

Таким образом, почти всегда подбор специалистов для выполнения проекта имеет оп­ределенные ограничения и не является свободным. Вместе с тем необходимо, чтобы хотя бы несколько членов группы разработчиков имели квалификацию и опыт, достаточные для работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО.

Руководитель проекта обычно обязан посылать отчеты о ходе его выполнения как заказ­чику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извлекаемой из подробных' отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта.

^ В рамках курса выделены следующие роли в группе по разработке ПО:

  • Руководитель – общее руководство проектом, написание документации, общение с заказчиком ПО

  • Системный аналитик – разработка требований (составление технического задания, проекта программного обеспечения)

  •  Тестер – составление плана тестирования и аттестации готового ПО (продукта), составление сценария тестирования, базовый пример, проведение мероприятий по плану тестирования

  • ^ Разработчик – моделирование компонент программного обеспечения, кодирование

Планирование проекта разработки программного обеспечения

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

Процесс планирования начинается, исходя из описания системы, с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ.

Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) про­ектные ограничения.

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

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

Детализация планов проектов очень разнится в зависимости от типа разрабаты­ваемого программного продукта и организации-разработчика. Но в любом случае боль­шинство планов содержат следующие разделы.

  1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.

  2. Организация выполнения проекта. Описание способа подбора команды разработчи­ков и распределение обязанностей между членами команды.

  3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявле­ния и стратегий, направленных на их уменьшение.

  4. ^ Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень ап­паратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.

  5. ^ Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание резуль­татов ("выходов") каждого этапа и контрольные отметки.

  6. ^ График работ. В этом графике отображаются зависимости между отдельными про­цессами (этапами) разработки ПО, оценки времени их выполнения и распределе­ние членов команды разработчиков по отдельным этапам.

  7. ^ Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются пре­доставляемые руководителем отчеты о ходе выполнения работ, сроки их предостав­ления, а также механизмы мониторинга всего проекта.

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

^ Общие сведения о требованиях к информационным системам

Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно чётко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований.

Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя.

^ Первые шаги по разработке требований к информационным системам - анализ осуществимости

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

  1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?

  2.  Можно ли реализовать систему, используя существующие на данный момент техно­логии и не выходя за пределы заданной стоимости?

  3. Можно ли объединить систему с другими системами, которые уже эксплуатируются?

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

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

  1. Что произойдет с организацией, если система не будет введена в эксплуатацию?

  2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?

  3. Каким образом система будет способствовать целям бизнеса?

  4. Требует ли разработка системы технологии, которая до этого не использовалась в организации?

Далее необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, техноло­ги, конечные пользователи и т.д.

После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе.

4.     Порядок выполнения работы

  1. Изучить предлагаемый теоретический материал.

  2. Составить подробное описание информационной системы.

  3. На основании описания системы провести анализ осуществимости. В ходе анализа ответить на вопросы:

  • Что произойдет с организацией, если система не будет введена в эксплуатацию?

  •  Какие текущие проблемы существуют в организации и как новая система поможет их решить?

  • Каким образом система будет способствовать целям бизнеса?

  • Требует ли разработка системы технологии, которая до этого не использовалась в организации?

Результатом анализа должно явиться заключение о возможности реализации проекта.

  1. Распределить роли в группе  (руководитель проекта-разработчик, системный аналитик-разработчик, тестер-разработчик).

  2.  Заполнить разделы плана:

  •  Введение

  • Организация выполнения проекта

  •  Анализ рисков

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

  1. Составить отчет о проделанной работе.

5.     Содержание отчета

В отчете следует указать:

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

  2. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом

  3. Описание информационной системы (ПО) - наличие заключения о возможности реализации проекта, содержащего  рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению

  4. Анализ осуществимости (согласно требованиям к результатам выполнения лабораторного практикума п.2), указать возможные проблемы и пути их решения.

  5. Роли участников группы разработки ПО.

  6. Программно-аппаратные средства, используемые при выполнении работы.

  7. Заключение (выводы)

  8. Список используемой литературы

 6.     Литература

  1. Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом “Вильямс”, 2002. – 624 с.

  2. Якобсон А., Буч Г., Рамбо Дж.  Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с.

  3. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.:Питер, 2004. – 592 с.

  4. Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

Похожие:

Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconЛабораторная работа №1 «Разработка описания и анализ информационной системы»
Описать и проанализировать информационную систему, распределить роли в группе разработчиков
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconЛабораторная работа №1 «Разработка описания и анализ информационной системы сети библиотек»
Описать и проанализировать информационную систему сети библиотек, распределить роли в группе разработчиков
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconКурсовая работа по Информационной безопасность
Разработка системного алгоритма шифрования информации на примере шифра Цезаря с ключевым словом
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconКурсовая работа по Информационной безопасность
Разработка системного алгоритма шифрования информации на примере шифра Цезаря с ключевым словом
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconВопросы для проведения зачета по дисциплине «Информационные технологии в менеджменте» Менеджмент – Финансовый менеджмент одо 2 курс (3 семестр)
Понятия корпорации, информационной системы, корпоративной информационной системы (кис)
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconРазработка элементов системы хассп на кондитерском предприятии
Разработка проекта системы качества хассп на примере производства шоколадных паст
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconЛабораторная работа №7 Тема : «Системы счисления»
Цель работы: Рассмотреть позиционные системы счисления, а также получить навыки по представлению числовых данных в различных системах...
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconОпд. Ф. 04 Статистика лабораторная работа. Корреляционно-регрессионный анализ Методические указания
Рекомендовано к изданию методической комиссией экономического факультета (протокол №7 от «29» мая 2006 г.)
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconЛабораторная работа №5 по курсу «Технологии электронного бизнеса»
Выбрать любой интернет-продукт, имеющий цифровую природу и провести его анализ по следующим критериям
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconПроектирование. Этапы проектирования: синтез и анализ
Проектирование – это процесс создания описания, необходимого для построения в заданных условиях еще не существующего объекта, на...
Лабораторная работа №1 «Разработка описания и анализ информационной системы» iconЛабораторная работа №8 Разработка интерфейса пользователя в соответсвии с требованиями тп
Получить практические навыки по проведению этапов предварительного и высокоуровневого проектирования интерфейса пользователя
Вы можете разместить ссылку на наш сайт:
Документы


При копировании материала укажите ссылку ©ignorik.ru 2015

контакты
Документы