Фаза Проектирования и разработки

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

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

Задачи

На данной фазе необходимо выполнить следующий ряд задач:

- создать проектные спецификации и модули для поддержки требований к сбору данных;

- завершить техническую архитектуру для всего соответствующего окружения;

- спроектировать базу данных и наполнить её данными для системы OFA;

- разработать модели, установить характеристики и настройки системы;

- разработать и создать отчеты, документы, и возможности доступа пользователей;

- завершить тестирование системы для обеспечения качества;

- передать документацию для дальнейшего обслуживания;

- передать хорошо спроектированную, тщательно протестированную и интегрированную систему.

Критичные факторы

При этом необходимо помнить о критичных факторах успеха фазы:

- понимание разработчиками требований к системе;

- понимание разработчиками возможностей и особенностей имеющихся технологий;

- своевременное решении вопросов;

- работоспособность сред разработки и тестирования;

- утвержденная система эксплуатационных требований;

- отсутствие серьезных изменений в проекте модуля или базе данных.

Предусловия

Для начала работ на данной фазе, в качестве предусловий, необходимо получить все артефакты фазы «Анализ»

 

Процессы

Данная фаза затрагивает все процессы.

Роли

- Бизнес-аналитик,

- Менеджер проекта,

- Системный архитектор,

- Технический писатель,

- Ведущий тестировщик,

- Аналитик доступа к данным;

- Аналитик сбора данных,

- Тренер,

- Проектировщик модулей;

- Разработчик,

- Проектировщик БД,

- Администратор БД.

 

Риски и способы их профилактики

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

 

Фаза Перехода к промышленной эксплуатации

Целью фазы «Переход к промышленной эксплуатации» является установка системы, подготовка персонала со стороны клиента, к использованию системы и её управлению, а также ввод в производство. Фаза начинается с приёмочного тестирования и заканчивается с переводом системы в промышленную эксплуатацию.

 

Задачи

На данной фазе необходимо выполнить следующий ряд задач:

- Создание производственной среды.

- Установка системы.

- Подготовка администраторов для поддержки и обслуживания системы.

- Подтверждение того, что новая система отвечает всем критериям приёмки.

 

Критичные факторы

При этом необходимо помнить о критичных факторах успеха фазы:

- своевременные и успешные поставка и установка произведённой системы

- активные, заинтересованные и вовлечённые пользователи, с чувством собственности, которые понимают ценность системы

- верно созданная техническая архитектура для поддержки предполагаемых объемов данных и количества пользователей

- успешные приемочные испытания

 

Предусловия

Для начала работ на данной фазе, в качестве предусловий выступают артефакты, созданные на предыдущей фазе.

 

Процессы

Данная фаза затрагивает три последних процесса:

1. Определение бизнес-требований;

2. Сбор данных;

3. Определение технической архитектуры;

4. Определение форм доступа к данным;

5. Проектирование и построение базы данных;

6. Документирование;

7. Тестирование;

8. Обучение;

9. Передача в промышленную эксплуатацию.

Роли

- Системный архитектор,

- Ведущий тестировщик,

- Проектировщик БД,

- Администратор произведённой БД (Production Database Administrator).

 

Риски и способы их профилактики

Риски	Профилактика рисков
тестирование не может осуществляться в различных окружениях приёмочного тестирования, ошибки неправильно протестированы и возвращены на этап приёмочного тестирования.	Создать нескольких сред (для тестирования, обучения) с чётким путём миграции модулей и данных между ними.
команде и клиенту не хватает времени провести обучение администраторов и пользователей в достаточной мере.	Разработать обучающий подход, который предоставляет различные варианты поставки на основе продолжающейся деятельности бизнеса и доступности персонала.
новые пользователи, которые впервые познакомились с системой, хотят внести предложения и уточнения, которые требуют произвести откат системы (that are not required to roll-out the system).	рассматривать любые улучшения, которые будут влиять на систему, которая будет развернута. Как и любой запрос, они должны быть оценены на основе их преимущества внедрения для бизнеса.
Непредвиденные проблемы производительности после перехода в эксплуатацию.	убедиться, что существует четкое, оперативное определение адекватной производительности.

 

Артефакты

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

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

Документирование при внедрении по модели внедрения Oracle Data Warehouse Method (DWM)

Различие в подходах и содержании мероприятий внедрения при использовании различных методологий внедрения

Этапы по ГОСТ 12207	Методология SAP	Методология 1С	Методология Oracle	Методология MS D AX
Подготовка	Подготовка проекта
Планирование	Концептуальный проект
Разработка	Реализация
Ввод
Эксплуатация

Требования к документированию при внедрении ИС

Рассмотрим формирование и перемещение документов в рамках проекта внедрения по этапам.

Этап/процесс	Входящие документы	Исходящие документы
ПОДГОТОВКА
Анализ заказа		Договор о сотрудничестве, протоколы встреч с заказчиком с предварительными целями и ограничениями проекта
Формализация задачи	Ранее полученные (рп в дальнейшем)	План работ, формализованные и непротиворечивые цели, перечень участников проекта
Анализ бизнес-системы (объекта автоматизации)	Цели и план исследования, все предыдущие документы	Модель объекта автоматизации, формализованная конечная цель проекта
Выработка требований	Рп	Модель “TO-BE”, документ о критериях оценки изменений, документы («надо сделать» и «не трогай! »J)
Оценка модели	Рп	Договор о сотрудничестве (на конкретную работу, реализующую модели), утверждённый перечень работ и ресурсов
ПЛАНИРОВАНИЕ
Выработка сценариев	Рп	Набор формализованных сценариев и модель тестирования данных сценариев
Отображение бизнес-системы	Модель объекта автоматизации “TO-BE”, сценарии Рп	Формализованная модель ИС до уровня функциональных модулей, проект ИС (набор необходимых и достаточных документов для разработчиков)
Планирование инфраструктуры проекта	ВСЁ Рп	Итоговый документ, содержащий модель элементов и их взаимодействия, модель интерфейсов, требования к сторонним ИС, график работ, контрольные точки, расписание и обязанности сотрудников.
Аудит	Вся документация	Утверждённые документы на разработку ИС
РЕАЛИЗАЦИЯ
Выбор модели ЖЦ	Описание ИС	Модель ЖЦ
Формирование надзорной группы	Описание системы на уровне конфигурации	Формализованный список надзорной группы
Формирование системной архитектуры	Модель объекта автоматизации, формализованная конечная цель проекта	Техническое описание системной архитектуры (модель данных, техническая инфраструктура, АРМы)
Конверсия данных	Текущие данные Заказчика и требования к данным в новой системе	Документация по новым, преобразованным и удалённым сущностям, новая структура данных
Системное документирование	Описания системной архитектуры и архитектуры данных, модель инфраструктуры предприятия	Проект внедрения КИС в объект заказчика
Системное управление	Документация по проекту (штатное расписание, требования к деятельности сотрудников в рамках проекта)	ТЗ для сотрудников, программа обучения и аттестации сотрудников
Создание инфраструктуры	Документ, содержащий требования к инфраструктуре с учётом её текущего состояния	-
Кодирование	Техническая документация и документация, полученная с «Конверсии данных»	-
Инсталляция программно-аппаратной среды	Инструкции по инсталляции	Поэтапный личностный план обучения с привязкой к АРМу
Пользовательское документирование	Модель “TO-BE”, user scenario	Документ, который может использоваться как средство обучения и поддержки
Верификация	Вся документация	Отчёт о результатах
Тестирование	Техническая документация	Отчёты о внутрисистемных ошибках
Квалификационное испытание	Вся документация	Экспертное заключение о готовности ИС к эксплуатации
ВВОД В ЭКСПЛУАТАЦИЮ
Ввод в эксплуатацию	Пользовательская документация	Набор эксплуатационных данных, замечания пользователей
Обеспечение качества	-	Отчёт о количестве ошибок
Сверка сальдо	Счета	Финансовый отчёт о совокупной стоимости владения
Промышленная эксплуатация	Пользовательская и техническая документация	Заявки на сопровождение/техническую поддержку
Снятие с эксплуатации	Документация о процессе	Документация по утилизации

15. Требования к формированию инфраструктуры проекта [A1] по внедрению ИС

В рамках процесса формирования инфраструктуры проекта должны быть формализованы следующие элементы:

 

1. модель элементов системы

2. модель взаимодействия элементов

3. модель интерфейсов (внутренних и пользовательских)

4. требования к сторонним ИС

5. график работ по проекту

6. контрольные точки проекта

7. штатное расписание

8. обязанности сотрудников

Требования к формированию бюджета проекта по внедрению ИС

Разработка бюджета проекта

Корректный план бюджета, который четко описывал бы все предстоящие расходы — это средство обеспечения адекватного финансирования проекта.

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

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

Шестью основными категориями затрат бюджета считаются:

- трудозатраты,

- обучение,

- затраты на оборудование и инфраструктуру,

- проезд и проживание,

- решения,

- затраты на поддержку проекта.

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

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

Затраты на обучение команды, включают:

- затраты на инструкторов и связанные расходы;

- затраты на бумажный и компьютерный учебный материал, включая программное и аппаратное обеспечение компьютера;

- затраты на оборудование, питание;

- затраты времени участников;

- затраты, связанные с размещением обучаемой команды.

Необходимо оценить затраты на проезд и проживание, включающие:

- затраты на транспорт,

- проживание,

- питание.

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

Можно использовать различные подходы к планированию затрат:

- Планирование затрат с использованием декомпозиции.

- Планирование с использованием затратных элементов (детальное планирование).

- Планирование затрат на производство единицы продукции (unit cost).

Инструменты и методы, используемые для оценки стоимости

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

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

- Оценка по аналогам представляет вид оценки сверху-вниз. При этом используется фактическая стоимость ранее выполненных проектов для оценки текущего проекта. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует много усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость подготовки такой оценки составляет 0, 04%-0, 15% от общей стоимости проекта.

- Оценка снизу-вверх применяется на этапе подготовки базового плана проекта и формировании контрольной оценки. Процесс начинается с оценки деталей проекта с последующим суммированием деталей на итоговых уровнях. Степень точности оценки зависит от уровня детализации ИСР. Оценка снизу-вверх обеспечивает точность от +0, 15/-10% до +5%/-5%, но имеет высокую стоимость (от 0, 45% до 2% от общей стоимости проекта) и продолжительность.

- Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода: для оценки стоимости проекта достаточно знать " ставки" привлекаемых ресурсов: недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической оценки составляет 0, 04%-0, 45% от общей стоимости проекта.

⇐ Предыдущая123456

Поделиться:

Популярное:

1. CASE-средства проектирования баз данных
2. IV. Порядок разработки дополнительных противопожарных мероприятий при определении расчетной величины индивидуального пожарного риска
3. Анализ принципов и последовательности разработки финансовой стратегии предприятия
4. Аппарат искусственной вентиляции легких с электроприводом «Фаза-5»
5. Билет №2. Кадровые технологии. Основные принцыпы разработки.
6. Другие книги и разработки автора
7. Задачи курсового и дипломного проектирования
8. ЗАЩИТА ЭЛЕКТРОДВИГАТЕЛЕЙ ОТ КОРОТКИХ ЗАМЫКАНИЙ МЕЖДУ ФАЗАМИ
9. Интегрированная среда разработки (IDE) MPLAB
10. Использования утратившей силу формы 1-НДФЛ для разработки налогового регистра
11. Какое понятие из перечисленных ниже не относится к фазам делового цикла?
12. Конструкция втачного рукава, этапы разработки. Взаимосвязь рукава с проймой. Развертка рукавов.