52
Рисунок 20. Последняя часть
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Разделение процесса разработки на множество этапов упрощает
процесс разработки, однако, не смотря на это, при разработке программы
предприятие может столкнуться с некоторыми рисками.
Самый главный и самый негативный риск – это неполучение
предприятием готового проекта или слишком большой (экономически
невыгодный) срок ожидания.
Возможны различные события, в результате которых готовый
программный продукт будет либо вовсе не реализован, либо срок
выполнения работы значительно превысит изначально установленные сроки.
Данные ситуации могут возникать как по вине руководства
предприятия, так и по вине информационного отдела.
Наиболее сложным этапом, и поэтому имеющим наибольшую
вероятность привести к осложнениям, это этапы создания технического
задания и проектирования базы данных.
53
Ошибки, произошедшие на этих этапах, приведут к череде ошибок в
дальнейшем, и единственным способом устранения этих ошибок станет
переработка технического задания, модели базы данных и, соответственно,
всего программного проекта.
В нашем случае, руководство является «заказчик» и устанавливает
задачи, которые должна решать информационная система. Если на этапе
создания технического задания руководство предприятия неправильно
сформулировало цели разработки, в то разработанная система не будет
отвечать желаемым требованиям. В данной ситуации будет либо проведено
изменение проекта, либо он будет полностью закрыт, если будет принято
решение о неэффективности переработки проекта.
Так как информационный отдел является разработчиком проекта, то на
этапе создания технического задания, глава отдела должен вносить свои
изменение в технического задание. Такое может происходить, например,
если требуется создать какой-либо механизм работы системы, создание
которого либо требует слишком больших трудозатрат, либо является
невозможным. Если будет утверждено техническое задание с такими
задачами, это может привести к тому, что на каком-то этапе разработки
команд столкнется с излишне трудными или не решаемыми задачами.
На этапе выбора инструментов разработки невозможно предсказать все
аспекты будущей работы, а главное сложности, с которыми столкнется
система на этапе внедрения и использования.
Информационный отдел может выбрать неправильную СУБД, которая,
например, не будет иметь возможности обрабатывать слишком большое
количество запросов за единицу времени.
Выбор языка программирования не является столь сложным, так как
многие современные языки программирования позволяют реализовывать
программы, отвечающие поставленным целям, а именно:
иметь удобный интерфейс;
иметь возможность взаимодействия с базой данных;
54
обеспечивать быстродействие работы системы.
На этапе реализации логики программы могут возникнуть различные
ошибки, но вероятность появления таких ошибок будет компенсироваться
опытом команды разработчиков.
Негативным образом на отношении клиентов к информационной
системе могут вылиться ошибки реализации, пропущенные на этапе
тестирования программы.
Так как программа работает с личными денежными средствами
клиентов, они будет особенно сильно реагировать в случае возникновения
каких-либо ошибок во время работы программы.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Лица, имеющие доступ к информационной системе, делятся на три
группы:
администратор;
клиент;
гость.
Администраторы базы данных имеют полный доступ ко всем данных.
Они могут модифицировать и изменять любые данные.
Клиенты могут только просматривать собственные данные, данные о
личных счетах, вкладах, целях, кредитах, операциях, а также добавлять
данные.
Гостям доступна только регистрация.
Для доступа к личному кабинету должен ввести логин и пароль,
указанные при регистрации.
Для защиты данных на случай взлома программы все вычисления и
обработка данных перенесены на сервер. Обработка происходит путем
запуска хранимых процедур, расположенных на сервере, куда из клиент-
приложения передаются необходимые аргументы.
Соединение между приложением и сервером является защищенным.
55
Все данные о текущем времени и дате берутся с сервера,
соответственно, изменение времени на компьютере, не внесет каких-либо
изменений в работу системы.
Приложение является свободно распространяемым поэтому
дополнительной защиты от копирования программы не требуется.
Для обеспечения безопасности данных, все операции со счетами,
вкладами и т.д. производятся на сервере.
Для этого используются хранимые процедуру, которые получают из
программы набор некоторых необходимых параметров и перед выполнением
операции проверяют, корректной ли будет данная операция и не приведет ли
она к нарушению целостности базы данных или нарушению бизнес-логики
автоматизированной информационной системы онлайн-банкинга.
Были реализованы процедуры для добавления, изменения, получения
данных, а также проверки выполнения некоторых условий:
addNewAccount(процедура добавления нового счета);
addNewCredit(процедура добавления нового кредита);
addNewDeposite(процедура добавления нового вклада);
addNewGoal(процедура добавления новой цели);
checkGetMoney(процедура проверки наличия необходимой
суммы средств на выбранном счете или вкладе);
checkLogin(процедура проверки наличия введенного логина);
checkNumberAccount(процедура проверки наличия счета с
заданным номером);
checkPassword(процедура проверки правильно введенного
пароля);
doTransAct(процедура выполнения операции перевода);
editPersonalData(процедура изменения персональных данных);
getIdClientByIdAccount(процедура получения номера клиента по
номер счета);
getIdNewAccount(получение номера добавленного счета);
56
getPersonalData(получение персональных данных);
loadAccount(загрузка счетов пользователя);
loadCredit(загрузка кредитов пользователя);
loadDeposite(загрузка вкладов пользователя);
loadGoal(загрузка целей пользователя);
loadOperations(загрузка операций пользователя);
loadSourceClient(загрузка возможных источников средств
пользователя);
loadTypeDeposite(загрузка типов вкладов);
loadTypeCredit(загрузка типов кредитов);
logInBase(авторизация в системе);
OpenCredit(открыть новый кредит);
OpenDeposte(открыть новый вклад);
OpenGoal(открыть новую цель);
Registration(зарегистрироваться в системе).
Исходный код процедур представлен в Приложение 2.
Процедуры вызываются как из программы так и из других процедуры.
Например, процедуры открытия кредитов, вкладов и целей, сначала
проверяют корректность данных (определяют при помощи процедуры
checkGetMoney можно ли перевести средства на создаваемый счет), а потом
вызывают соответствующие процедуры добавления новых данных.
Для вызова процедуры из программы, мы создаем объект типа
SqlCommand, для которого устанавливаем тип хранимая процедура
(StoredProcedure) и параметры, которые должны быть переданы в процедуру.
Пример вызова процедуры представлен на Рисунок 21.
57
Рисунок 21 Пример вызова хранимой процедуры
Пример вызова хранимой процедуры из другой процедуры представлен
на Рисунок 22.
Рисунок 22 Пример вызова хранимой процедуры
2.2 Управление проектом автоматизации
2.2.1 Описание системы принятий управленческих решений
Для определения того, какие работы, в какой последовательности
нужно начать и время начала каких работ можно передвинуть, чтобы
сократить сроки выполнения проекта, выделим основные работы по проекту,
внесем их в таблицу № 8, где пронумеруем их в хронологическом порядке и
укажем длительность выполнения в часах.
Таблица № 8
Характеристики работ по информационному проекту.
Ном
ер
работы
Название работы
Длительност
ь
1
Начало реализации проекта
0
2
Анализ предметной области
80
3
Анализ аналогов
16
58
4
Определение функций системы
40
5
Определение состава системы
24
6
Создание технического задания
80
7
Выбор средств реализации
8
8
Проектирование базы данных
40
9
Создание макета программы
32
10
Реализация логики программы
400
11
Тестирование информационной
системы
160
12
Внедрение
80
13
Завершение проекта
0
На основе данных из таблицы №8 построим сетевой график (рисунок №23).
Рисунок 23. Сетевой график работ информационной системы
Найдем критические работы и критический путь. Для этого построим
сетевые графики и вычислим на них время раннего и позднего начала работ
по каждой работе (рисунки №24, №25).
59
Рисунок 24. Сетевой график с вычислением раннего времени начала работ
Рисунок 25. Сетевой график с вычислением позднего времени начала работ
На основании данных полученных при построении сетевых графиков
внесем раннее время начала каждой работы в таблицу № 9, затем позднее
время начала каждой работы и внесем в ту же таблицу. Когда таблица будет
заполнена ранним и поздним временем начала каждой работы, посчитаем
разность по каждой работе и внесем результат в следующую строку. Те в
столбцы, в которых разность работ равна нулю выделим заливкой – это
критические работы, такие работы задержка начала которых приводит к
задержки срока окончания проекта в целом.
Таблица № 9
Сводные результаты расчетов по вычислению раннего и позднего времени
начала работ
Работа
1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
1
3
Ранне
е время
начала
0
0
8
0
8
0
8
0
1
20
2
00
2
08
2
08
2
48
6
48
8
08
8
88
Поздн
ее время
начала
0
0
1
04
8
0
9
6
1
20
2
00
2
08
2
16
2
48
6
48
8
08
8
88
Резерв
времени
0
0
2
4
0
1
6
0
0
0
8
0
0
0
0
На основании ранее построенных сетевых графиков и результатов расчетов
из таблицы №9 построим сетевой график, на котором обозначим
критический путь (рисунок №26).
60
Рисунок 26. Сетевой график. Критический путь
Выводы: усилия менеджера в первую очередь должны быть направлены на
своевременное выполнение критических работ. Для некритических работ
можно маневрировать временем начала и используемыми ими ресурсами.
2.2.2 Формирование команды проекта автоматизации
В данной работе банк «АСВ» выступает в качестве и заказчика и
разработчика.
В качестве заказчика выступает глава предприятия, который
постановил информационному отделу разработать автоматизированную
информационную систему онлайн-банкинга.
Соответственно, в качестве разработчика выступает информационный
отдел.
Как уже говорилось выше, информационный отдел состоит из отдела
разработки, отдела тестирования, отдела безопасноти и службы поддержки.
Управляет этим отделом директор по IT-технологиям.
В данном проекте на этапе разработки отдел службы поддержки не
учавствует, так как они работают только с готовым проектом.
В качестве технического лидера проекта выступает глава отдела
разработки. Он распределяет задачи между своими подчиненными и
оказывает взаимодействие с директором по IT-технологиям.
Разработка программного проекта лежит на отделе разработки.
Данный отдел состоит из 14 человек, считая главу отдела.
Так как веб-сайт банка «АСВ» успешно функционирует, то весь состав
отдела будет учавствовать в разработке проект.
61
Помимо технического лидера также выделим аналика требований,
данный сотрудник занимается разработкой формулированных требований,
вытекающих из технического задания.
Так как же в составе отдела разработки присутствует аналитик, его
задачей является разработка модели база данных.
В создании макета будущей программы учавствует программист-
дизайнер.
Все решений по поводу оформлений, выбора средств реализации и т.д.
согласовываются с техническим лидером.
Для тестирования будущего программного обеспечения привлечены
сотрудники отделов тестирования и безопасности.
Каждый из этих отделов состоит из 4 человек. По три человека из
каждого отдела задействованы в разработке проекта.
До тех пор, пока отдел разработки не предоставил для тестирования
готовый проект, отдел тестирования занимается проектированием будущих
тестов, изучает вероятные варианты и так далее. Как только отдел разработки
предоставляет первые варианты системы, тестировщики приступают к
тестированию и документированию результатов тестирования.
2.2.3 Средства коллективной работы над проектом автоматизации
В качестве инструмента для коллективной работы над проектом
автоматизации было решено выбрать какую-либо систему типа GIT[1].
Выбор на такой тип системы управления пал, так как данная система
позволяет множеству пользователей беспроблемно работать с одним
проектом. Изменения в проекте документируются и записывают, что
позволяет в случае чего, посмотреть кто и когда добавлил какое-либо
изменение.
Система позволяет создавать множество веток (branches), которые
сливаются (merge) в одну, только после того, как главой проекта будет
принято, что изменения, реализованные в подветке, являются правильными и
обоснованными.