Дипломная работа: Автоматизация процесса ведения документации и отчетности в МАУ "Многофункциональном центре предоставления государственных и муниципальных услуг" Краснобродского городского округа

Скачать файл

Заказать новую работу

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Стандартом, который используется для создания ЖЦ задачи, является

ГОСТ ISO/IEC 12207 [31]. Он выбран на основании того, что.:

 данный стандарт является более ориентированным на совершенно

любые виды ПО и типы проектов автоматизированных систем (АС).

 стадии и этапы работы по этому стандарту соответствуют

каскадной модели.

Первый этап отражает то, как аналитик проводит планирование и анализ

требований задачи учета и обработки заявок и формирует документацию. Он

состоит из следующих задач: «Исследование и анализ задачи», «Определение

требований к задаче» и «Оформление технико-экономического обоснования

(ТЭО) и технического задания (ТЗ) задачи. В этом этапе участвует начальник

отдела, который контролирует процесс выполнения этапа в целом. После

завершения первого этапа ЖЦ происходит переход на второй этап, где

проектировщик на основании документации аналитика проводит

проектирование задачи и формирует документацию. Он состоит из следующих

задач: «Разработка функциональной архитектуры (ФА) и системной

архитектуры (СА) задачи» и «Оформление технического проекта задачи».в этом

этапе участвует начальник отдела, который контролирует процесс выполнения

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

этапа, т.е. третьего этапа, а именно реализации задачи, который подразумевает

разработку (программирование) программы учета и обработки заявок. Данный

этап проводится на основании той документации, которую дал ему

проектировщик. Он состоит из таких задач, как «Разработка и настройка СУ»,

«Создание рабочей инструкции по СУ» и «Оформление рабочей СУ». Также в

этом этапе участвует начальник отдела, который контролирует процесс

выполнения этапа в целом.

После завершения третьего этапа осуществляется переход к четвертому

этапу внедрения той задачи, которую разработал программист (внедрение задачи

учета и обработки заявок). Внедрение автоматизированного решения – процесс

ввода в практическую эксплуатацию этого решения на различных сферах

деятельности предприятиях. Четвертый этап состоит таких задач, как [1]:

 установка программы;

 обучение работе с программой;

 тестовая эксплуатация программы;

 оформление акта о приемо-сдаточных испытаний (ПСИ);

Первая задача этапа - установка программы - выполняется системным и

сетевым администратором. Второй задачей является задача обучения работе с

программой менеджера. Она проводится тем, кто проектировал данную задачу,

т.е. проектировщиком. Далее, выполняется третья задача – тестовая

эксплуатация программы. Она проводится менеджером, который ведет и будет

вести учет заявок. После выполнения третьей задачи начинается выполнение

четвертой, т.е. оформления акта о ПСИ, где менеджер демонстрирует программу

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

данную разработку, которое в последующем будет официально принято как

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

этапов ЖЦ составляет полгода.

После того, как была разработана и установлена программа по учету

внутренних заказов оборудования, начинается пятый этап ЖЦ – эксплуатация

задачи учет заявок. Эксплуатация автоматизированного решения – практическое

использование автоматизированного решения в разных сферах деятельности

предприятиях. Этап эксплуатации состоит из следующих задач:

 проведение учета заявок;

 администрирование учета заявок;

 проверка программной и технической документации;

 выявление недостатков задачи учета и обработки заявок и

формирования технического задания (ТЗ);

 создание новой версии ПОк задаче учета и обработки заявок.

Проведение учета заявок – задача менеджера, который участвует в этой

задаче на 100%, его функции регулируются должностной инструкцией.

Администрирование учета и обработки заявок – задача контроля и

устранения возникших программных, информационных и технических проблем

в данной предметной области. Данная задача выполняется системным и сетевым

администратором, который участвует в ней на 100% и регулируется

должностной инструкцией.

Проверка программной и технической документации - задача проверки в

реальных условиях теоретического построения схем, методов, моделей,

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

соответствия документарных и практических данных, как в общем случае, так и

проведя детальный анализ задачи. Она выполняется аналитиком, который

участвует в этой задаче на 100%, и регулируется должностной инструкцией.

Выявление недостатков задачи учета и обработки заявок и формирование

ТЗ - задача выявления недостатков (нарушений работы) ПО задачи, по которым

формируется ТЗ к модифицированному решению, которые выявляются при

проверке программной и технической документации. Все эти недостатки

проявляют себя в течение срока эксплуатации. После этого заканчивается

процесс выявления недостатков и начинается внедрение модифицированного

решения. Он выполняется аналитиком, который участвует в этой задаче на

100%, и регулируется должностной инструкцией.

Создание новой версии ПО для учета и обработки заявок – задача

переработки технологии задачи: добавление новых методов, действий и

функций, а также, вероятно, изменение всей структуры ПО и его интерфейса. Ее

выполнение происходит в конце этапа эксплуатации ЖЦ, и после окончания

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

внутренних заказов оборудования. Эта задача реализуется программистом.

Степень его участия в этом виде задач равна 100%, регулируется задача

должностной инструкцией. Все этапы ЖЦ регулируются его регламентом ЖЦ

задачи.

Каждый этап ЖЦ задачи имеет свои цели достижения и результаты,

которые должны быть получены в конце каждого его этапа. Целью первого этапа

(планирование и анализ требований задачи учета и обработки заявок) является

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

ней требований, а его результатом является список функций учета, т.е. принятия

к рассмотрению заказа, проверка наличия оборудования в резерве, поиск

поставщиков, отмена заказа, приостановление/восстановление заказа,

согласование заказа и отправка заказа.

Целью второго этапа (проектирование задачи учета и обработки заявок)

является разработка концепции технологии задачи и программы по учету

внутренних заказов оборудования, а его результатами служат [31]:

 информационная модель задачи;

 функциональные модели программы в целом и подсистем,

реализуемых отдельными командами разработчиков;

 точно определенные с помощью CASE-средства интерфейсы между

автономно разрабатываемыми подсистемами;

 построенные прототипы экранов, отчетов и диалогов.

Целью третьего этапа (реализация задачи учет заявок) является разработка

автоматизированного решения программы по учету внутренних заказов

оборудования и ввод ее в эксплуатацию, а его результатом является полностью

законченное ПО, готовое к его использованию.

Целью четвертого этапа (внедрение задачи учета и обработки заявок)

является замена ПО на автоматизированное, а его результатом является

официально-зарегистрированное внедрение ПО.

Целью последнего пятого этапа (эксплуатация задачи учета и обработки

заявок) является сам непосредственный учет и обновление версии данной

программы, а его результатом является обновленная версия ПО.

Типичная каскадная модель, несмотря на негативную оценку за последние

несколько лет, исправно служила специалистам по программному инжинирингу

долгое время. Понимание ее сильных сторон и недостатков значительно

улучшает оценочный анализ других, даже более эффективных моделей ЖЦ,

базирующихся на данной модели.

Каскадная модель включает в себя много преимуществ, если ее применять

в проекте, для которого она предназначена и приемлема. Далее указаны эти

преимущества:

• Модель отлично известна потребителям, не относящимся к

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

используется другими компаниями для отслеживания проектов, не связанных с

созданием ПО);

• Она логичнее справляется со сложностями и отлично показывает

себя в тех проектах, где все достаточно понятно, но все равно трудно

разрешимо;

• Она вполне доступна для понимания, поскольку преследует

простую цель — реализовать нужные действия;

• Она удобна и проста в использовании, поскольку сам процесс

разработки реализован поэтапно;

Но в случае применения каскадной модели для проекта, который нельзя

назвать подходящим для нее, выявляются некоторые недостатки:

• Модель основана на последовательной линейной структуре,

поэтому каждая попытка возврата на одну или две фазы назад для исправления

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

и сбою в графике;

• Модель не предотвращает возникновение итераций между фазами,

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

согласно обычному циклу аппаратного инжиниринга;

• Модель не показывает главное свойство создания ПО, направленное

на решение задач. Отдельные фазы жестко связаны с конкретными действиями,

что входит в разрез с реальной работой персонала или коллективов;

• Модель создает ошибочное впечатление о работе над проектом.

Понятие типа "25% выполнено" не имеет никакого смысла и не может являться

показателем для менеджера проекта.

Ввиду недостатков каскадной модели ее использование ограничено

ситуациями, в которых требования и их реализация максимально четко

прописаны и понятны.

Каскадная модель замечательно функционирует при ее использовании в

циклах разработки ПО, в которых применяется неизменяемое определение

продукта и четко понятны технические методики.

V-образная модель создается для поддержки работающей над проектом

команды в планировании с реализацией дальнейшей возможности проверки

системы. В этой модели главное значение придается действиям, направленным

на подтверждение и проверку продукта. Она отражает, что проверка продукта

Источник: https://baza.diplomsite.ru/previewfile/2039

Смотрите также:

783
otchet_po_netyagovym_83
Авторы 'Сеанса' как носители регионального культурного самосознания: анализ первых девяти номеров журнала
Анализ ликвидности организации ООО 'Мис-с'
Гі де Мопассан: життя та творчість
Жедел респираторлы аурудан кейін 28 жастаы йелде ра, иын блінетін жтел пайда болды, жтелге бірнеше кннен кейін шырышты аыры осылды.
К вопросу о профессиональной компетентности лингвиста-переводчика
Кадровое обеспечение органов государственной и муниципальной службы
Китайская интеллигенция в эпоху Хань и эпоху Шести династий
Культура, как инструмент 'мягкой силы' в сфере международных отношений