Кроме того, организация должна учитывать продолжительность пилотного проекта (и в целом процесса внедрения). Слишком продолжительный проект связан с риском потери интереса к нему со стороны руководства.
3.2. Планирование пилотного проекта
Планирование пилотного проекта должно по возможности вписываться в обычный процесс планирования проектов в организации. План должен содержать следующую информацию:
Цели, задачи и критерии оценки
Ожидаемые результаты пилотного проекта должны быть четко определены. Степень соответствия этим результатам представляет собой основу для последующей оценки проекта. Для определения целей, задач и критериев оценки необходимо выполнить следующие действия:
· описать проект в терминах ожидаемых результатов (т.е. конечного продукта). Описание должно включать форму представления и содержание результатов. Должны быть четко определены договорные требования и соответствующие стандарты.
· определить общие цели проекта. Примером цели может быть определение степени улучшения качества проектной документации в результате применения CASE-средств.
· определить конкретные задачи, реализующие поставленные цели. Каждой цели можно поставить в соответствие одну или несколько конкретных задач с количественно оцениваемыми результатами. Примером такой задачи может быть сравнительный анализ качества документации, полученной с помощью CASE-средства и без него. Документация может включать спецификацию требований к ПО, высокоуровневые и детальные проектные спецификации.
· определить критерии оценки результатов. Чтобы определить степень успеха пилотного проекта, необходимо использовать набор критериев, основанных на упомянутых выше задачах. Примером критерия может быть степень непротиворечивости проектной документации и контролируемости выполнения требований к ПО. Значения критериев должны сравниваться с базовыми значениями, полученными до выполнения пилотного проекта.
Персонал
Специалисты, выбранные для участия в пилотном проекте, должны иметь соответствующий авторитет и влияние и быть сторонниками новой технологии. Группа должна включать как технических специалистов, так и менеджеров, заинтересованных в новой технологии и разбирающихся в ее использовании. Группа должна обладать высокими способностями к коммуникации, знанием особенностей организационных процессов и процедур, а также предметной области. Группа не должна, тем не менее, состоять полностью из специалистов высшего звена, она должна представлять средний уровень организации.
Многие CASE-средства обеспечивают возможности, связанные с генерацией проектной документации и конфигурационным управлением. Специалисты, связанные с этими и другими смежными аспектами разработки и сопровождения ПО, также должны быть включены в состав группы.
После завершения пилотного проекта группа должна быть открыта для обмена информацией с остальными специалистами организации относительно возможностей нового средства и опыта, полученного при его использовании. Может оказаться желательным рассредоточить членов проектной группы по всей организации с целью распространения их опыта и знаний.
Процедуры и соглашения
Необходимо четко определить процедуры и соглашения, регулирующие использование CASE-средств в пилотном проекте. Эта задача скорее всего может оказаться более долгой и сложной, чем ожидается, при этом может оказаться необходимым привлечение сторонних экспертов. Примерами процедур и соглашений, которые могут повлиять на успех пилотного проекта, являются методология, технические соглашения (в частности, по наименованиям и структуре каталогов, стандарты проектирования и программирования - см. подраздел 1.3) и организационные соглашения (в частности, учет использования ресурсов, авторизация, контроль изменений, процедуры экспертизы и подготовки отчетов, стандарты проверки качества).
В пилотном проекте по возможности должны использоваться принятые в организации процедуры и соглашения. С другой стороны, в течение пилотного проекта процедуры и соглашения имеют тенденцию к развитию и совершенствованию по мере накопления опыта применения средства. Существующие процедуры и соглашения могут оказаться неэффективными или чересчур ограничивающими. При этом те изменения, которые предлагается в них вносить, должны документироваться.
Обучение
Должны быть определены виды и объем обучения, необходимого для выполнения пилотного проекта. При планировании обучения нужно иметь в виду три вида потребностей: технические, управленческие и мотивационные. Ресурсы, требуемые для обучения (учебные аудитории и оборудование, преподаватели и учебные материалы), должны соответствовать плану пилотного проекта.
График обучения должен определять как специалистов, подлежащих обучению, так и виды обучения, которое они должны пройти. Обучение, которое проводится в период выполнения проекта, должно начинаться как можно быстрее после начала проекта. Обучение средствам, процессам или методам, которые не будут использоваться в течение нескольких месяцев после начала проекта, должно планироваться на то время, когда в них возникнет реальная потребность.
Поставщики CASE-средств обычно предлагают обучение использованию поставляемых ими средств. Помимо этого, для некоторых средств может быть необходимо обучение методологии. Некоторые виды обучения должны выполняться собственными силами. Такие виды обучения включают использование CASE-средства в контексте процессов, происходящих в организации, а также в совокупности с другими средствами в данной среде. Часть плана пилотного проекта, связанная с обучением, должна использоваться в качестве входа для плана практического внедрения.
При выборе необходимого обучения должны приниматься во внимание следующие факторы:
График и ресурсы
Должен быть разработан график, включающий ресурсы и сроки (этапы) проведения работ. Ресурсы включают персонал, технические средства, ПО и финансирование. Данные о персонале могут определять конкретных специалистов или требования к квалификации, необходимой для успешного выполнения пилотного проекта. Финансирование должно определяться отдельно по каждому виду работ: приобретение CASE-средств, установка, обучение, отдельные этапы проектирования.
В заключении хотелось еще раз отметить нецелесообразность сравнения отдельно взятых CASE – средств, поскольку не одно из них не решает в целом все проблемы создания и сопровождения программного обеспечения. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы жизненного цикла программного обеспечения. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченный необходимый технической и методической поддержкой.
Исходя из всего этого можно сделать такой вывод, что методология развивается стремительными темпами приобретая и развивая новые средства проектирования ИС, так как проектирование постоянно добавляет в себя новые пункты и информационные технологии приобретают все более новые свойства.
При выполнении курсовой работы я изучил и рассмотрел:
1. Выполнение оценки CASE – средств.
2. Изучил процесс выбора CASE – средств.
3. Узнал критерии оценки и выбора CASE – средств.
В ходе работы выявил какие классы информационных систем существуют (например, такие как ручные, автоматические и автоматизированные), как и на чем основывается эти классы и каждый из них в частности, а также использование этих классах в проектировании и программировании.
Из работы следует, что современные принципы и особенности проектирования оценки и выбора это CASE – средств основано на использовании структурного анализа, объектно-ориентированного моделирования, CASE – систем.
1. Алексеев А.А., Попенко Р.А. CASE-средства в информационной системе – СПб.: ЮНИТИ, 2003.
2. Баркин Р.С. CASE-метод. Моделирование – М.: Центр, 2003.
3. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений // СУБД – 2003. – №3.
4. Вендров А.М. Проектирование программного обеспечения экономических систем – М.: Финансы и статистика, 2005.
5. Вендров А.М. Объектно-ориентированный анализ и проектирование информационных систем c использованием языка UML и case-средства Rational Rose – М.: Академия АйТи, 2000.
6. Гнатуш А. CASE-технологии: что, когда, как? // IT-менеджер – 2004. – №16 (4).
7. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие – М.: Центр Информационных Технологий, 2002.
8. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение) – М.:Лори, 2003.
9. Королёв К.З. Информационные технологии и программное обеспечение. Учебник. М.: ДАНА, 2003.
10. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования – М.: МетаТехнология, 2003.