Добавлен: 25.10.2018
Просмотров: 4941
Скачиваний: 3
59
туре ВКР обусловлен тем, что эти этапы связаны с совершенно разными ас-
пектами системы, поскольку отвечают на вопрос, что делать, а не как делать.
Кроме того, они выполняются в разное время и требуют совершенно разных
навыков и опыта.
Физическое проектирование базы данных – процесс подготовки описания
реализации базы данных на вторичных запоминающих устройствах. На этом
этапе рассматриваются основные отношения, организация файлов и индексов,
предназначенных для обеспечения эффективного доступа к данным, а также
все связанные с этим ограничения целостности и средства защиты. Приступая
к физическому проектированию БД, прежде всего необходимо выбрать кон-
кретную целевую СУБД, поскольку специфика конкретной СУБД может
включать в себя ограничения на именование объектов базы данных, ограниче-
ния на поддерживаемые типы данных, и т. П
В результате физического проектирования в пояснительной записке
представляется разработанная схема данных, а также для всех таблиц базы
данных ИС представляются характеристики полей и размер записей в них.
Правильность физического проектирования должен подтвердить тот факт, что
поля в таблицах базы данных ИС являются неизбыточными по их количеству
и размерности, а взаимосвязь между таблицами должна позволять осуще-
ствить преобразование информационных объектов в соответствии с информа-
ционной моделью.
2.4 Разработка главы 3 «Оценка проектных решений»
Третья глава включает три следующих раздела:
3.1
Оценка уровней зрелости автоматизируемых процессов;
3.2
Управление проектом автоматизации;
3.3. Оценка экономической целесообразности выполнения проекта авто-
матизации;
60
3.3.1Анализ затрат на ресурсное обеспечение (Оценка совокупной стои-
мости владения);
3.3.2 Анализ качественных и количественных факторов воздействия
проекта на бизнес-архитектуру и деятельность организации.
Раздел 3.1. Оценка уровней зрелости автоматизируемых процессов
В международном стандарте ISO/IEC 15504 [6]оценка процессов опре-
делена как деятельность, которая выполняется либо в составе программы со-
вершенствования процессов, либо как часть подхода к определению возмож-
ностей процессов. Совершенствование процессов производится с целью по-
стоянного повышения результативности и рациональности организации.
Для оценки процессов часто используют уровни их зрелости. Зрелость
показывает, насколько деятельность определена, управляема, контролируема и
эффективна, а сама модель зрелости предоставляет основные принципы
управления, которые необходимо применить для повышения зрелости. Счита-
ется, что чем выше уровень зрелости, тем деятельность более продуктивна,
что позволяет постепенно улучшать качество результатов, а также управлять
стоимостью и временем выполнения бизнес-процесса.
Методология COBIT 4.1 предлагает систему оценки процессов, называя
ее «Моделью зрелости» (COBIT 4.1 Maturity Model). В основе системы ис-
пользуется шкала оценки и модель зрелости способностей (Capability Maturity
Model, CMM) Института разработки программного обеспечения (the Software
Engineering Institute, SEI), широко известная как «Интегрированная модель
зрелости» (Capability Maturity Model Integration, CMMI). Оценка процессу вы-
ставлялась по принципу: «Насколько вероятно, что процесс в заданных
условиях приведет к ожидаемому результату?».
В COBIT 4.1 Предусмотрено 6 уровней зрелости процессов [7]:
«0»: Не существующий процесс
«1»: Начальный процесс
«2»: Интуитивно повторяющийся
61
«3»: Определенный (документированный) процесс
«4»: Измеряемый и управляемый
«5»: Оптимизируемый
В COBIT 4.1 имеются инструменты, с помощью которых можно опреде-
лить, какую из этих оценок нужно поставить рассматриваемому процессу.
Прежде всего, это шесть атрибутов зрелости:
1.
Осведомленность и коммуникации;
2.
Политики, планы и процедуры;
3.
Инструменты и автоматизация;
4.
Навыки и квалификация;
5.
Ответственность и подотчетность;
6.
Цели и измерение.
По характеристикам этих шести атрибутов зрелости студенту необходи-
мо определить уровень зрелости процесса ДО и ПОСЛЕ автоматизации. Срав-
нение уровней зрелости следует выполнить в виде диаграмм.
Необходимо отметить, что студенты часто необоснованно завышают
уровень зрелости автоматизируемого ими процесса, причем иногда даже до
уровня, превышающего лучшие мировые практики. Поэтому в данном разделе
следует убедительно обосновать, почему присвоен именно этот уровень зре-
лости автоматизируемому процессу.
Необходимо отметить, что существуют и другие модели оценки зрело-
сти автоматизируемых процессов: COBIT 5 PAM,
модель оценки на основе
стандарта ISO 15504 и др. Студент в ВКР может использовать любые модели
оценки зрелости процессов, обосновав их преимущества перед другими.
Раздел 3.2 Управление проектом автоматизации
Проекты по созданию информационных систем характеризуются с вы-
сокими рисками неудач, которые, как правило, заключаются в срыве сроков
сдачи проекта, превышении его бюджета или неудовлетворительном качестве
62
разработанного программного продукта. В связи с этим требуется управление
проектом автоматизации, которое предусматривает описание проекта автома-
тизации, плана-графика автоматизации и сетевой модели задач.
При формировании плана-графика автоматизации целесообразно ис-
пользовать АС управления проектами: PRIMAVERA, с которой студенты ра-
ботали при изучении дисциплины «Автоматизированные системы управления
проектами» или программным продуктом MS Project, который входит в со-
став подписки MSDN и выдается каждому студенту бесплатно для использо-
вания на домашнем компьютере.
Первоначально следует представить задачи, выполняемые в ходе реали-
зации ВКР, а затем привести диаграмму Гантта, отражающую план-график
проекта. На диаграмме Гантта в левом крайнем столбце приводится название
задачи, во втором – еѐ длительность, в последующих столбцах – начало и
окончание задачи и, наконец, задействованные при выполнении задачи ресур-
сы. Под задачами в данном случае следует понимать выполняемые работы по
созданию информационной системы, которые проводит студент в рамках вы-
полнения ВКР. Затем приводится краткое словесное описание этапов выпол-
нения проекта автоматизации. При этом указываются: название входящих
подэтапов, их начало и окончание, длительность подэтапа, используемый тру-
довой ресурс (кто выполняет данную задачу иди подэтап) и результат выпол-
нения
На все работы проекта следует произвести назначение ресурсов. Напри-
мер, такими ресурсами могут быть трудовые (программист, консультант и пр.)
и материальные (бумага, компьютер, принтер и пр.) ресурсы. Пример пред-
ставления ресурсов проекта приведен на рис. 5
Рисунок 5– Окно «Назначение ресурсов»
63
Затем для каждого ресурса назначаются соответствующие характери-
стики. Например, ресурсу «Программист» назначена дневная ставка в размере
500 рублей (рис. 6).
Рисунок 6 – Окно «Сведения о ресурсе»
Для каждого ресурса автоматически рассчитываются суммарные затра-
ты на его использование. В рассматриваемом нами примере за выполнение
программной разработки программисту была начислена зарплата в размере
27500 руб. (рис. 7).
Рисунок 7 – Окно «Сведения о суммарной задаче»