3 Внутрифирменные методологии 35

Вид материала

Реферат

Подобный материал:

• Вопросы к экзамену по курсу «Проектирование ис». (9-й семестр 2009г), 37.96kb.
• Программа тренинга: День 1: Как конструировать тренинговые игры и упражнения По окончании, 31.95kb.
• Методология и методика исторического исследования, 36.8kb.
• Gutter=47> Директор департамента о департаменте методологии бюджетных процедур, 9.25kb.
• Методика, 377.89kb.
• Курс. Маркетинг социально значимой проблемы как новое направление в стратегии повышения, 52.93kb.
• А. Р. Анализ современных тенденций в методологии макрофинансового прогнозирования, 376.06kb.
• Данный курс направлен на изучение методологии и методики проведения исследования методом, 114.63kb.
• Рабочая программа обсуждена и утверждена на заседании кафедры теории и методологии, 277.54kb.
• В. А. Ацюковский начала эфиродинамического естествознания книга, 3555.05kb.

3Внутрифирменные методологии

3.1Опыт аналитиков фирмы

В целом, рекомендуется следующая последовательность этапов:

• Обследование.
  
• Разработка Спецификаций технических требований (и, если есть время, - Концепции проектируемой системы).
  
• Утверждение Технического задания.
  
• Системное проектирование (разработка ERD, Спецификации на программирование и пр.).
  
• Программирование (кодирование и генерация БД).
  
• Наполнение и тестирование.
  
• Документирование.
  
• Внедрение.
  
• Сопровождение.
  

3.2Используемые стандарты и документы

При разработке внутрифирменной методологии ведения проектов были использованы, главным образом, опыт аналитиков фирмы и следующие стандарты:

• ГОСТ 34.602-89 (Техническое задание) [см. 2.1.2].
  
• IEEE Std 830-1993 (Спецификация требований к ПО) [см. 2.4.2].
  
• ISO 12207:1995 (ЖЦПО) [см. п. 2.2.3].
  
• DATARUN (ЖЦПО) [см. п. 2.3.1].
  
• ORACLE CDM (ЖЦПО) [см. п. 2.3.2].
  
• RUP (ЖЦПО) [см. п. 2.3.3].
  

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

• Денис Королев. Инновационный цикл в разработке проектов [3].
  
• С.С.Гайсарян. Объектно-ориентированные технологии проектирования прикладных программных систем [4].
  
• Владимир Липаев. Стандарты, регламентирующие жизненный цикл сложных программных комплексов [7].
  
• Проект создания ПО (фирма «Архивные Системы») [7].
  
• Предпроектное исследование задачи (фирма «Интегро», г. Уфа) [13].
  
• Жизненный цикл разработки ПО [14].
  
• Руководство по управлению внедренческими проектами на базе MS Project 2000 и рекомендаций PMI [15].
  

3.3Методология разработки новой системы

Под разработкой новой системы понимается весь процесс создания информационной системы от системного обследования до внедрения. Этот процесс включает следующие этапы (по международному стандарту ISO 12207:1995):

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

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

3.3.1Стратегия

3.3.1.1Назначение и особенности

Стратегия - этап определения назначения проекта, предварительного анализа предмета, планирования и оценки объема работ. На этом этапе Заказчик предоставляет Исполнителю краткие сведения о целях и объектах информатизации, на основе чего Исполнитель предоставляет Заказчику информацию об ориентировочных сроках и расходах по проекту.

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

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

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

3.3.1.2Выходные документы

Во время и по окончании этапа Стратегии разрабатываются следующие документы:

• «Описание общих требований» [3.5.5]. Основной целью документа является формирование границ проекта, т.е. выявление и описание общих требований.
  
• Предварительная версия «Календарного плана работ». В этом документе четко оценивается трудоемкость, продолжительность и сроки этапа Анализа и ориентировочно – по остальным этапам.
  
• Предварительная версия «Сметы». В этом документе четко оцениваются затраты и общая стоимость работ на этапе Анализа и ориентировочно – по остальным этапам (на основании оценки трудоемкости, приведенном в «Календарном плане работ»).
  
• «Договор о проведении обследования» - договор на выполнение бизнес-обследования предметной области [3.5.2].
  
• «Соглашение о конфиденциальности» - соглашение о неразглашении конфиденциальной информации, полученной при обследовании предприятия (составляется по инициативе Заказчика) [3.5.3].
  

3.3.1.3Трудоемкость и состав исполнителей

Этап носит непродолжительный характер (около 2 недель) и минимальное количество участвующих лиц (кроме руководителей и главных бухгалтеров – по 1-3 экспертов с обеих сторон).

3.3.2Анализ

3.3.2.1Назначение и особенности

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

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

3.3.2.2Состав этапа (подэтапы)

При этом, в первую очередь, проводится анализ следующих аспектов (в скобках – условные коды подэтапов):

• Определение основной цели бизнеса предприятия, описание решаемых задач и стоящих проблем («Обзор»).
  
• Анализ организационной структуры предприятия («Организация»).
  
• Анализ производственных, технологических и других объектов учета («Объекты»).
  
• Анализ сфер деятельности, подлежащих автоматизации, и эксплуатируемых информационных систем («Информационные системы»).
  
• Анализ состава бизнес-процессов, потоков управления и данных между ними, запускающими событиями, контролирующих органов и клиентов («Бизнес-процессы»).
  
• Определение используемой терминологии («Термины»).
  

Результаты интервьюирования экспертов оформляются в виде пакета протоколов, а результаты названных работ по анализу предметной области - в виде отдельных документов или разделов общего документа «Модель предметной области».

Далее (или одновременно) исследуется целесообразность использования какой-либо существующей информационной системы или разработки новой. При этом осуществляются и документируются (в виде разделов «Концепции» или отдельных документов) следующие подэтапы:

• Анализ существующих на рынке информационных систем, используемых или которые можно использовать для данной предметной области («Рынок систем»).
  
• Обоснование целесообразности применения какой-либо из существующих систем или используемых в ней подходов, либо разработки принципиально новой системы («Обоснование»).
  

Затем уточняются системные требования, и на их основе определяются стратегические направления будущих работ. При этом проводятся и документируются (в виде разделов «Концепции» или отдельных документов) следующие подэтапы:

• Уточнение функциональных, технических, информационных и пр. требований к системе («Требования»). Фактически, здесь разрабатывается текст, который войдет в главу 3 Технического задания (Требования к системе) [3.5.4.3] наряду с частью текста из документа «Описание общих требований».
  
• Определение общей стратегии (концепции) проектирования («Концепция»). В первую очередь определяется стратегия проектирования системы. При необходимости, также могут быть описаны стратегии реализации, внедрения и дальнейшего развития системы. Фактически, здесь разрабатываются прототипы ко всем будущим проектным документам.
  

3.3.2.3Выходные документы

Таким образом, на этапе Анализа разрабатываются следующие выходные документы:

• «Модель предметной области» [3.6.2] с прилагаемыми протоколами интервью [3.6.1].
  
• «Концепция системы» [3.6.3].
  
• «Техническое задание» - как приложение к Договору или отдельный документ [3.5.1]. Составляется на основе предшествующего (разработанного на этапе Стратегии) документа «Описание общих требований» и раздела «Уточненные требования к системе» документа «Концепция».
  
• «Календарный план работ» - как приложение к Договору или к ТЗ.
  
• «Смета» - как приложение к Договору или к ТЗ.
  
• «Договор» - договор на выполняемые работы: на проектирование, разработку, развитие, внедрение системы и т.п. В договоре определяется состав и содержание результирующих документов.
  

3.3.2.4Трудоемкость и состав исполнителей

Трудоемкость работ на этапе Анализа оценивается на основании указанных в п. 3.3.2.1 подэтапов, а также в соответствии с количеством экспертов, которых предполагается интервьюировать.

Работы на этом этапе рекомендуется выполнять группе аналитиков – специалистов по исследуемой предметной области, по информационным технологиям, которые предполагается использовать в проекте, по методологиям обследования и проектирования (3-6 человек, при ограниченных сроках - больше).

3.3.3Проектирование

3.3.3.1Назначение и особенности

На этапе Проектирования создаются документы, на основании которых программисты будут разрабатывать компоненты системы, а затем внедрять готовую систему.

3.3.3.2Состав этапа (подэтапы)

3.3.3.3Выходные документы

На этом этапе разрабатываются следующие модели и методики:

• «Модель данных» или «Информационная модель». Документ содержит:
  

• описание архитектуры БД (серверы, клиенты, обмен данными, доступ к данным, сегменты данных);
  
• описание объектов системы и их взаимосвязей;
  
• концептуальные и физические ER-диаграммы.
  

• «Методики информационного наполнения» - методики сбора и обработки исходных данных (для тестирования и внедрения). Документ разрабатывается вслед за Моделью данных.
  
• «(Программная) архитектура» или «Функциональная модель» - описание компонентов системы, их группировки и взаимосвязей.
  
• «Модель представления интерфейса» - описание структуры экранных форм и отчетов, бизнес-логики процедур преобразования входных и выходных данных.
  
• «Модель процессов» - описание работы системы и с системой на этапах внедрения и эксплуатации, сопровождаемое диаграммами DFD или UML.
  
• «Спецификация на программирование» - описание входных и выходных параметров, обработки исключительных ситуаций модулями и функциями системы.
  
• «Методики функционального наполнения» или «Встраивание в бизнес-процессы» - варианты планов дальнейшего расширения функциональных возможностей системы, описание перспектив ее развития.
  
• «Технические требования» - требования к аппаратной части и программному окружению серверов и рабочих мест. Предназначено для тестировщиков и клиентов (в первую очередь – администраторам системы).
  

3.3.3.4Трудоемкость и состав исполнителей

3.3.4Реализация

3.3.4.1Назначение и особенности

Назначением этапа является создание БД, кодирование, тестирование и документирование разработанной системы.

3.3.4.2Состав этапа (подэтапы)

1. Разработка модулей системы в соответствии с требованиями ТЗ и проекта.
   
2. Разработка тестов.
   
3. Подготовка тестовой БД (заполнение системы минимально необходимым для стендовых испытаний набором данных).
   
4. Стендовое тестирование и доработка.
   
5. Опытная эксплуатация («пилотное» внедрение системы на реальном предприятии).
   

3.3.4.3Выходные документы

Выходные документы:

• Новая техническая документация на модифицированные серверную и клиентскую части системы, новые подсистемы:
  

• Описание системы.
  
• Руководство пользователя.
  
• Руководство администратора.
  

• Задание на тестирование (планы тестирования модулей и системы).
  
• Отчет о тестировании и выявленных несоответствиях ТЗ.
  
• Отчет по ликвидации ошибок и несоответствий ТЗ.
  
• Отчет о результатах пилотного внедрения (о соответствии работы системы требованиям ТЗ).
  

3.3.4.4Трудоемкость и состав исполнителей

3.3.5Внедрение

3.3.5.1Назначение и особенности

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

3.3.5.2Состав этапа (подэтапы)

1. Сбор данных.
   
2. Создание справочников, классификаторов, кодификаторов.
   
3. Наполнение БД системы производственными и др. (например, географическими) данными.
   
4. Конфигурирование системы для решения задач предметной области (встраивание в бизнес-процессы).
   

3.3.5.3Выходные документы

Выходные документы:

• Отчет о наполнении системы данными.
  
• Отчет о соответствии работы системы требованиям ТЗ.
  

3.3.5.4Трудоемкость и состав исполнителей

3.3.6Сопровождение и развитие

3.3.6.1Назначение и особенности

Назначение этапа состоит в сопровождении промышленной эксплуатации системы (абонентском обслуживании), главным образом в устранении проблем при эксплуатации системы и ее развитие включает в себя следующие основные работы:

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

3.3.6.2Исполнительные документы

Выходные документы:

• Договор на абонентское обслуживание.
  
• Журнал регистрации консультаций.
  
• Журнал регистрации и устранения ошибок.
  
• Журнал регистрации доработок и тиражирования обновленных релизов (с указанием инициаторов доработок).
  
• Технические задания на доработку системы (в рамках абонентского обслуживания).
  

3.3.6.3Трудоемкость и состав исполнителей

3.3.7Развитие

Назначение этапа состоит в развитии программного продукта в объемах, превосходящих задачи абонентского обслуживания системы.

Фактически, этот этап является итерацией ЖЦ системы с какого-либо этапа (в основном – с этапа ее проектирования, а иногда даже обследования), в то время как доработка системы в рамках абонентского обслуживания – в основном, итерация с этапа ее реализации.

3.3.8Оценка сроков работ

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

По поводу распределения времени в проекте Брукс в своей книге «Мифический человеко-месяц» приводит следующие эмпирические данные для этапов разработки информационных систем:

• 1/3 – планирование (этапы Стратегии, Анализа и Проектирования).
  
• 1/6 - написание программ (начало этапа Реализации).
  
• 1/4 - тестирование компонентов и предварительное системное тестирование (завершение этапа Реализации).
  
• 1/4 - системное тестирование при наличии всех компонентов (завершение этапа Реализации).
  

Таким образом, этап Реализации занимает 2/3 времени ЖЦ ПО, причем работы по тестированию – 50% времени ЖЦ ПО.

Далее, условно будем считать, что:

• Малые проекты: несложные АРМ (типа «Кадры»).
  
• Средние проекты, например:
  

• сложные АРМ (например, «Бухгалтерия», «Операционный день банка»);
  
• АСУ (например, системы диспетчеризации);
  
• ГИС;
  
• САПР;
  
• системы паспортизации;
  
• контроля исполнения договоров и т.д.
  

• Крупные проекты: проект масштаба всего предприятия (ERP-система) и т.д.
  

Для среднего проекта оценка трудоемкости выглядит следующим образом:

• Стратегия: 1-2 недели.
  
• Анализ (бизнес-обследование): от 4 месяцев.
  
• Проектирование: от 4 месяцев.
  
• Реализация (кодирование и тестирование) – не менее 7 месяцев.
  
• Внедрение и обучение– от 1 недели до 1 месяца (с полным вводом данных) в 1 филиале.
  

Итого, на анализ предметной области, проектирование и реализацию среднего проекта необходимо не менее 15 месяцев.

Приведем более детальную схему работ по указанным этапам.

• Стратегия – 1-2 недели:
  

• Разработка предварительной версии «Технического задания» - 4-7 дней.
  
• Разработка предварительной версии «Календарного плана» (в документе точно оцениваются только работы на этапе Анализа) – 1 день.
  
• Разработка предварительной версии «Сметы» (в документе точно оцениваются только работы на этапе Анализа) – 1-3 дня.
  
• Согласование и утверждение «Договора о проведении обследования» (для этапа Анализа) – 1-3 дня.
  
• Согласование и утверждение «Соглашения о конфиденциальности» – 1-2 дня.
  

• Анализ – 4-6 месяцев:
  

• Интервьюирование экспертов, протоколирование интервью и утверждение протоколов – от 3 недель (на каждого эксперта 2-3 дня, всего интервьюируется не менее 10 экспертов).
  
• Разработка Модели предметной области – 9-10 недель:
  

• Обзор предметной области – 2 недели.
  
• Организационная структура предприятия – 1-2 дня.
  
• Эксплуатируемые информационные системы – 1 неделя.
  
• Словарь терминов – 1-2 недели.
  
• Составление диаграмм бизнес-процессов и их уточнение у экспертов – от 1 месяца.
  
• Описание первичных данных (потоков между бизнес-процессами) – 2-3 дня.
  

• Разработка Концепции системы - около 1 месяца:
  

• Обзор существующих систем – 2-3 дня.
  
• Экономическое обоснование целесообразности проекта – 1-2 дня.
  
• Уточненные технические требования – 1 неделя.
  
• Стратегия проектирования системы (фактически, наметки ко всем 8 будущим проектным документам, по 2-3 дня для каждого) – 16-24 дня.
  

• Составление окончательной документации на последующие этапы – 1-2 недели:
  

• Разработка Технического задания – от 2-3 дней.
  
• Составление Календарного плана работ – 1-2 дня.
  
• Калькуляция работ - 2-5 дней.
  
• Составление и согласование Договора на проектирование, разработку и внедрение системы - 2-5 дней.
  

• Проектирование – от 4 месяцев:
  

• Разработка Модели данных (архитектура базы данных и ER-диаграммы с описанием) – от 3 недель.
  
• Разработка Методик информационного наполнения (для тестирования и внедрения) – 1 неделя.
  
• Разработка Программной архитектуры (описание компонентов и их взаимосвязей) – от 2 недель.
  
• Разработка Модели представления интерфейса (структура экранных форм и отчетов, бизнес-логика процедур преобразования данных) – от 3 недель.
  
• Разработка Модели процессов системы (DFD-диаграммы и описание работы системы на этапах внедрения и эксплуатации) – от 2 недель.
  
• Разработка Спецификации на программирование (модулей и функций) – от 3 недель.
  
• Разработка Методологии встраивания системы в бизнес-процессы (план расширения функциональных возможностей системы и описание перспектив ее развития) – 1 неделя.
  
• Разработка Технических требований к аппаратной части и программному окружению серверов и рабочих мест (для тестировщиков и клиентов) – 1 неделя.
  

• Реализация – от 7 месяцев (наиболее сложный этап для ориентировочной оценки):
  

• Кодирование компонент (модулей, драйверов, инструментов и пр.) – от 3 месяцев (зависит от количества компонент).
  
• Тестирование и доработка компонент – от 1 месяца (в среднем, 30% от этапа кодирования).
  
• Создание скриптов и генерация базы данных – от 1-3 месяцев, в т.ч.:
  

• Создание скриптов генерации табличных пространств и настройка конфигурационных параметров БД – 1 неделя.
  
• Создание скриптов генерации таблиц, последовательностей, индексов, несложных триггеров и функций – 1 неделя.
  
• Создание скриптов настройки репликации – 1 неделя.
  
• Разработка запросов к БД (на выборку данных для отчетов и пр.) – от 1 месяца.
  
• Разработка хранимых процедур – от 1 месяца.
  

• Информационное наполнение системы для стендового испытания – 1 неделя.
  
• Стендовое тестирование и доработка системы – от 1 месяца, в т.ч.:
  

• Тестирование и оптимизация запросов на выборку данных
  
• Тестирование транзакций при добавлении, изменении, удалении данных на правильную работу последовательностей, ограничений, триггеров, функций и пр.; исправление ошибок, оптимизация запросов и настройка БД, подготовка отчета – от 2 недель.
  
• Тестирование и настройка обмена данными для распределенной БД (репликации); исправление ошибок, оптимизация запросов и настройка БД, подготовка отчета – от 2 недель.
  

• Подготовка документации (описание системы, руководство пользователя, и руководство администратора с приложениями) – от 1 месяца.
  

• Внедрение в одном филиале – от 1 месяца:
  

• Инсталляция системы на рабочих местах пользователей и администратора – 1 неделя.
  
• Сопровождение пользователей при наполнении системы – 1-2 недели.
  
• Устранение проблем (если таковые будут) – до 1 недели.
  
• Обучение пользователей и администратора – до 1 недели.
  
• Подготовка и утверждение приемо-сдаточных актов – 1-3 дня.
  

3.3.9Общий план работ

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

№	Этапы и подэтапы	Документы (в скобках – трудоемкость разработки, ЧМ)	Трудо-ёмкость (ЧМ)	Продол-житель-ность (мес)	Персонал
1.	Стратегия	Описание общих требований (0,5) Календарный план НИР Смета затрат по НИР Соглашение о конфиденциальности Договор о проведении обследования	1	0,5	3 (рук-тель, гл.бухгалтер, аналитик)
2.	Анализ	Протоколы интервью (2-3) Модель предметной области (3) Концепция (3) Техническое задание (1,5-2) Календарный план (0,5) Калькуляция работ (0,5) Договор (0,5)	12	От 4	3 аналитика (и более)
3	Проекти-рование	Информационная модель (3) Методика наполнения (1-2) Функциональная модель (2) Модель интерфейса (2) Модель процессов (2) Спецификация (2-3) Методика встраивания в БП (1)	15	От 4	4 аналитика (и более)
4.	Реализация	Описание системы (0,5) Руководство пользователя (1) Руководство администратора (1) Отчеты о стендовых испытаниях и результатах пилотного внедрения (1)	20	От 7	4 (аналитик, прогр-сты)
	Итого по этапам 1-4		48	От 15	От 4
5.	Внедрение	Отчет о наполнении системы данными. Отчет о соответствии работы системы требованиям ТЗ.		Около 1 мес. на 1 объект	2 (прогр-сты клиента и сервера или прогр-ст и оператор)