Дипломная работа: Исследование и разработка информационной системы приема и анализа заявок технической поддержки на примере Администрации г. Новый Уренгой
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
64
Вспомогательные. Это процессы документирования, управления
конфигурацией, верификации, процессы обеспечения качества, процессы
аттестации, оценки, аудита и решения проблем.
Организационные. Это процессы управления проектами, создание
инфраструктуры проекта, определения, оценка и улучшение самого
жизненного цикла, процессы обучения.
Указанный стандарт ISO/IEC 12207 не определяет конкретной модели
жизненного цикла и методов его разработки. Он содержит общие
рекомендации, предназначенные для любых моделей жизненного цикла. Эти
рекомендации ориентированы на разработку информационной системы в
рамках организации. Есть стандарты, которые более ориентированы на
производителей информационных систем. Они подразумевают более четкие
требования.
В настоящее время наиболее распространена каскадная модель.
Каскадная модель создания информационной системы является однородной и
ее программное обеспечение определяется как единое (с ней) целое. Каскадная
модель обеспечивает хорошие результаты. Она показана на рисунке 9.
65
Рисунок 9. Каскадная модель жизненного цикла
Именно каскадная модель была выполнена для реализации проекта в
данной работе.
Весь процесс разработки, в соответствии с данной моделью разбивается
на несколько этапов, переход от одного этапа к другому происходит только
после полного выполнения предыдущего этапа.
Это означает, что на каждом этапе формируется законченный набор
проектной документации, этого набора должно быть абсолютно достаточно
для передачи проекта другой группе разработчиков, функционирующих на
следующем этапе жизненного цикла по разработке информационной системы.
Так же одним из положительных моментов каскадной модели является
возможность планирования сроков завершения работ и затрат на их
выполнение. Как и у любой модели, у каскадной модели есть свой недостаток.
Он заключается в том, что сложно уложить реальный процесс создания
66
программного обеспечения в такую жесткую схему. В связи с этим часто
возникает потребность возврата на предыдущий этап, с целью уточнения и
пересмотра решений, принятых ранее.
Весь процесс разработки программного обеспечения начинается с
изучения предметной области. В случае разработки данного приложения
изучение ведется в направлении набора уже используемых программ на
предприятии для информационного обмена.
При данной модели разработки сначала осуществляется чертеж на
бумаге. Этот этап называется проектированием. Проектируется база данных, а
именно, наименование таблиц, наименование и структура полей таблиц,
связей между таблицами. Далее осуществляется чертеж эскиза форм и прочих
элементов интерфейса. Чертеж начинается с основной формы MDI и ее меню.
Далее, последовательно чертятся формы, информация в которых отображается
из справочных таблиц и формы, содержащие информацию из учетных
(оперативных) таблиц. А именно, делается эскиз форм Организации,
Сотрудники, Входящие письма, Исходящие письма. Делается эскиз форм
промежуточного диалога, такие как подтверждение удаления записи и
информационный формы.
Следующим этапом разработки является проектирование дизайна в
среде программирования, то есть построение пользовательского интерфейса.
Осуществляется в той же последовательности. На данном этапе интерфейс
пока еще не выполняет своих функций.
При наступлении третьего этапа начинается "оживление"
пользовательского интерфейса посредством записи процедур и функций.
Последовательность разработке такая же, как при составлении эскизов.
Разрабатываются различные модули для осуществления рабочих функций
приложения. Тестируется каждый модуль на наличие возможных ошибок.
После кодирования созданное приложение необходимо протестировать
на наличие ошибок уже комплексно. Здесь следует предусмотреть все нелепые
67
операции, которые может осуществить пользователь, который будет работать
с данным программным обеспечением.
После успешного прохождения теста, программе необходима
техническая поддержка по внесению определенных изменений, которые будут
происходить в регламенте организации.
68
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
При проектировании системы следует прежде всего хорошо разобраться
в предметной области, изучить все необходимые функции, которые
потребуется автоматизировать. После этого уже можно передавать проект на
следующий этап разработки. Изучением предметной области должны
заниматься все три члена команды-разработчиков, а именно руководитель
проекта, программисты-техники и программист-разработчик.
Далее, программисты-техники, которые являются техническими
специалистами. готовят на техническое задание для программиста-
разработчика. Основной риск здесь может заключаться в том, что сами же
технические специалисты могут не предусмотреть все функции, которые им
потребуются для дальнейшей работы. В этом случае программист-
разработчик может вернуть проект на доработку (на предыдущий этап).
Уже после повторной доработки техническими специалистами
технического задания станет ясно, достаточно ли данной информации для
проектирования базы данных, либо нет. В процессе возврата проекта на
предыдущий этап нет ничего необычного. Это процесс доработки. Именно так
и должна проходить любая разработка программного обеспечения. Процесс
проектирования базы данных сначала делается на обычном листе карандашом.
Чертятся таблицы, дается название полям, чертятся связи между таблицами по
ключевым полям. После успешного проектирования на бумаге начинается
непосредственное проектирования на выбранного для проекта СУБД. В
данном случае был выбран СУБД MySQL 5.2.
После проектирования базы данных наступает следующий этап
проектирование. Это процесс проектирования экранных форм. Начинается он
так же с бумажного проектирования. Процессом проектирования форм в
команде занимается программист-разработчик, поскольку команда проекта не
предусматривает наличие работников-дизайнеров. Вообще дизайнеры – это
Источник: https://baza.diplomsite.ru/previewfile/8703