Разработка технического задания на внедрение программного комплекса "Похозяйственный учет" в администрацию села Ташбулатово

Декомпозиция процесса выдачи справок в нотации DFD. Исследование запросов к внедрению программного комплекса "Похозяйственный учет". Требования к защите информации от несанкционированного доступа. Главная особенность разработки системной архитектуры.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 29.04.2019
Размер файла 1,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

5. Технические средства. В данном разделе должны учитываться все технические средства, которые находятся у юридического лица в любой из форм собственности (правообладания). Должен быть реализован учет документов свидетельствующих о регистрации права, а также о прекращении правообладания (тип документа должен вноситься из справочника типов документов) и их реквизитов (серия, номер, дата выдачи, примечание). Модуль «Миграция, ЗАГС»
Модуль должен обеспечивать выполнение следующих функций:
1) учет листков прибытия
В системе должен быть реализован реестр листков прибытия. Пользователь должен иметь доступ только к тем листкам прибытия, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? территория;
? реквизиты документа; ? тип прибытия.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты.
1. Прибывшее физическое лицо. Физическое лицо должно подтягивается из реестра физических лиц;
2. Территория. Сельское поселение/населенный пункт - территория прибытия физического лица. Территория должна подтягивается из справочника территории;
3. Тип прибытия (извне, внутреннее перемещение, возвращение из временного отсутствия и т.д.) Тип прибытия должен выбираться из выплывающего списка;
4. Основание прибытия. Должно подтягиваться из справочника «Основания прибытия»;
5. Дата прибытия, Дата убытия (в случае временного пребывания);
6. Документ физического лица. Документ, удостоверяющий личность физического лица, реквизиты документа (серия, номер, дата выдачи, кем выдано). Сведения о документе должны автоматически фиксироваться в карточке физического лица;
7. Откуда прибыл. Адрес предыдущего место пребывания физического лица.
Адрес должен подтягиваться из справочника Классификатор Адресов РФ (КЛАДР).
Для отражения информации о прибытии физического лица в базе данных системы - необходимо реализовать механизм регистрации листка прибытия. При регистрации листка прибытия физическое лицо должно регистрироваться либо в хозяйстве, либо в специализированном учреждении.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться листки прибытия ранее даты рождения пребывающего физического лица, а также в случае, если физическое лицо уже зарегистрировано в хозяйстве или в специализированном учреждении.
2) учет листков убытия
В системе должен быть реализован реестр листков убытия. Пользователь должен иметь доступ только к тем листкам убытия, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? территория;
? реквизиты документа; ? тип убытия.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
1. Убывающее физическое лицо. Физическое лицо должно подтягиваться из реестра физических лиц;
2. Территория. Сельское поселение/населенный пункт, территория из которого убывает физического лица. Территория должна подтягивается из справочника территорий;
3. Тип убытия (временное или постоянное) Тип прибытия должен выбираться из выплывающего списка;
4. Основание убытия. Должен подтягиваться из справочника «Основания убытия»;
5. Дата убытия;
6. Куда убыл. Адрес населенного пункта, куда убыло физическое лицо.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться листки убытия с датой ранее даты рождения физического лица или даты регистрации в хозяйстве, а также в случае, если физическое лицо не зарегистрировано в хозяйстве или в специализированном учреждении.
3) учет листков прописки
В системе должен быть реализован реестр листков прописки. Пользователь должен иметь доступ только к тем листкам прописки, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? территория;
? реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? физическое лицо, подавшее заявление на регистрацию. Физическое лицо должно подтягиваться из реестра физических лиц;
? территория. Сельское поселение/населенный пункт, территория в котором регистрируется физическое лицо. Территория должна подтягиваться из справочника территорий;
? адрес регистрации. Адрес должен подтягиваться из КЛАДРа; ? дата регистрации.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться листки прописки с датой, ранее даты рождения физического лица.
4) учет листков выписки
В системе должен быть реализован реестр листков выписки. Пользователь должен иметь доступ только к тем листкам выписки, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? территория;
? реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? физическое лицо, подавшее заявление на снятие с регистрации.
Физическое лицо должно подтягиваться из реестра физических лиц;
? территория. Сельское поселение/населенный пункт, территория в котором зарегистрировано физическое лицо. Территория должна подтягиваться из справочника территорий;
? адрес прописки. Адрес должен подтягиваться из КЛАДРа; ? дата снятия с регистрации.
Для отражения информации о снятии с прописки физического лица в базе данных системы - необходимо реализовать механизм регистрации листка выписки. При регистрации листка выписки должна вноситься запись в карточку физического лица.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться листки выписки с датой, ранее даты рождения физического лица или прописки.
5) учет свидетельств о рождении
В системе должен быть реализован реестр свидетельств о рождении. Пользователь должен иметь доступ только к тем свидетельствам о рождении, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? Территория;
? Реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? Новорожденное физическое лицо. Физическое лицо должно подтягиваться из реестра физических лиц;
? Территория. Сельское поселение/населенный пункт - территория, к которой относится физическое лицо. Территория должна подтягиваться из справочника территории;
? Реквизиты свидетельства о рождении (серия, номер, дата выдачи);
? Данные о матери ребенка. Физическое лицо должно подтягиваться из реестра физических лиц;
? Данные об отце ребенка. Физическое лицо должно подтягиваться из реестра физических лиц.
Для отражения информации о рождении физического лица в базе данных системы - необходимо реализовать механизм регистрации свидетельств о рождении. При регистрации свидетельства о рождении физическое лицо должно регистрироваться либо в хозяйстве, либо в специализированном учреждении.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться свидетельства о рождении с датой, ранее даты рождения физического лица, а также в случае, если физическое лицо уже зарегистрировано в хозяйстве или в специализированном учреждении.
6) учет свидетельств о смерти
В системе должен быть реализован реестр свидетельств о смерти. Пользователь должен иметь доступ только к тем свидетельствам о смерти, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? Территория;
? Реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? Физическое лицо. Должно подтягиваться из реестра физических лиц;
? Территория. Сельское поселение/населенный пункт - территория, к которой относится физического лица.
? Реквизиты свидетельства о смерти (серия, номер, дата выдачи); ? Причина смерти, место смерти.
Для отражения информации о смерти физического лица в базе данных системы - необходимо реализовать механизм регистрации свидетельства о смерти.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться свидетельства о смерти с датой, ранее даты рождения физического лица.
7) учет свидетельств о регистрации брака
В системе должен быть реализован реестр свидетельств о регистрации брака. Пользователь должен иметь доступ только к тем свидетельствам, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? Территория;
? Реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? Физические лица, вступающие в брак; Физические лица должны подтягиваться из реестра физических лиц. Должна быть реализована проверка на принадлежность физических лиц к мужскому и женскому полу. В поле «муж» должно указываться физическое лицо мужского пола, в поле «жена» - женского пола.
? Территория. Сельское поселение/населенный пункт - территория, к которой относятся физические лица. Территория должна подтягиваться из справочника территории;
? Реквизиты свидетельства о регистрации брака (номер, дата выдачи);
? Фамилия мужа, Фамилия жены после регистрации брака (в случае ее смены);
? Место регистрации; ? Дата регистрации.
Для отражения информации о регистрации брака в базе данных системы - необходимо реализовать механизм регистрации свидетельств о регистрации брака. При регистрации свидетельства о регистрации барка должна добавляться информация о родственных отношениях в карточки физических лиц.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться свидетельства о регистрации брака с датой, ранее дат рождений физических лиц, а также в случае, если хотя бы одно физическое лицо уже состоит в зарегистрированном браке.
8) учет свидетельств о разводе
В системе должен быть реализован реестр свидетельств о расторжении брака. Пользователь должен иметь доступ только к тем свидетельствам, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? Территория;
? Реквизиты документа.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? Физические лица, расторгающие брачные отношения; Физические лица должны подтягиваться из реестра физических лиц. Должна быть реализована проверка на принадлежность физических лиц к мужскому и женскому полу. В поле «муж» должно указываться физическое лицо мужского пола, в поле «жена» - женского пола.
? Территория. Сельское поселение/населенный пункт - территория, к которой относятся физические лица. Территория должна подтягиваться из справочника территории;
? Реквизиты свидетельства о расторжении брака (номер, дата выдачи);
? Фамилия мужа, Фамилия жены после расторжения брака (в случае смены фамилии);
? Место регистрации расторжения брака;
? Дата регистрации расторжения брака.
Для отражения информации о расторжении брака в базе данных системы - необходимо реализовать механизм регистрации свидетельства о расторжении брака. При регистрации свидетельства должна обновляться информация о родственных отношениях в карточках физических лиц.
Должна быть реализована проверка на наложение дат. В системе не должны регистрироваться свидетельства о расторжении брака с датой, ранее дат рождений физических лиц, а также в случае, если хотя бы одно физическое лицо не состоит в зарегистрированном браке.
9) журнал внутренних перемещений
В системе должен быть реализован реестр документов по внутреннему перемещению. Перемещению из одного хозяйства (или специализированного учреждения) в рамках одной территории считается внутренним перемещением.
Пользователь должен иметь доступ только к тем документам, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Листок убытия; ? Листок прибытия.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
При внесении в систему нового документа должны заполняться следующие реквизиты:
? Физическое лицо. Физическое лицо должно подтягивается из реестра физических лиц;
? Основание убытия. Должно подтягиваться из справочника «Основания прибытия»;
? Дата перемещения;
? Хозяйство. Хозяйство, в которое перемещается физическое лицо.
После регистрации документа, должны автоматически сформироваться листки убытия и прибытия.
Должна быть реализована проверка корректности дат. В системе не должны регистрироваться листки прибытия ранее даты рождения пребывающего физического лица, а также в случае, если физическое лицо уже зарегистрировано в хозяйстве или в специализированном учреждении.
10) журнал регистрации документов
В системе должен быть реализован реестр всех документов модуля Миграции, ЗАГС. Пользователь должен иметь доступ только к тем документам, которые относятся к той же (или дочерней) территории, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О;
? Наименование документа;
? Связь. В данном столбце должно, отображаться в каком хозяйстве или специализированном учреждении зарегистрировано физическое лицо;
? Дата регистрации;
? Статус (Зарегистрировано/Не зарегистрировано).
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
В реестре должна быть реализована возможность отображения документов по категориям:
? Листки прибытия; ? Листки убытия;
? Листки прописки;
? Листки выписки;
? Свидетельства о рождении;
? Свидетельства о смерти;
? Свидетельства о регистрации брака;
? Свидетельства о расторжении брака.
Регистрация документов должна осуществляться через данный реестр. Механизм регистрации документов должен запускается путем нажатия на кнопку «Зарегистрировать». Должна быть реализована возможность отмены регистрации документа путем нажатия на кнопку «Разрегистрировать».
Модуль «Воинский учет»
Модуль должен обеспечивать выполнение следующих функций:
1) учет карточек офицеров запаса
В системе должен быть реализован реестр офицеров запаса.
Пользователь должен иметь доступ только к тем карточкам офицеров запаса, которые закреплены за той же (или дочерней) территорией, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О.;
? Звание;
? Пол;
? Дата рождения; ? Адрес.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
В реестре должна быть реализована возможность отображения физических лиц по категориям:
? Все;
? Имеющие мобилизационное предписание; ? Не имеющие мобилизационное предписание; ? Не состоящие на учете.
У каждого офицера запаса должна быть индивидуальная карточка, соответствующая действующему законодательству со следующими разделами:
1. Основные сведения. Сведения об офицере запаса (ФИО, дата рождения, место рождения, пол, место работы, Домашний адрес, гражданское образование) должны заполняться автоматически из карточки физического лица. Сведения о типе учета, категории годности, группе учета, звании, личном номере, военном образовании, военной специальности, мобилизационном предписании - должны заполняться в ручную.
2. Дети до 18 лет. В данном разделе должны указываться все дети не достигшие 18 лет. Вкладка должна заполняться автоматически в соответствии с данными из вкладки «Родственники» физического лица.
3. Отметки о воинском учете. В данной вкладке должна учитываться постановка и снятие офицера запаса с воинского учета.
2) учет карточек призывников
В системе должен быть реализован реестр призывников.
Пользователь должен иметь доступ только к тем карточкам призывников, которые закреплены за той же (или дочерней) территорией, что и сам пользователь.
Реестр должен отображаться в табличном виде с возможностью экспорта в Microsoft Excel (Open Office).
Выводить объекты необходимо по 25 записей на странице.
Должно отражаться общее количество страниц и записей в таблице.
Должна быть возможность перемещения по страницам и открытие конкретной страницы.
Должна быть реализована возможность добавления, редактирования, удаления записей, а также обновления реестра.
Таблица должна состоять из следующих столбцов:
? Ф.И.О.;
? Звание;
? Пол;
? Дата рождения; ? Адрес.
По каждому столбцу должна быть реализована возможность фильтрации и сортировки.
В реестре должна быть реализована возможность отображения физических лиц по категориям:
? Все;
? Не поставленные на воинский учет;
? Состоящие на воинском учете;
? Не состоящие на учета.
У каждого призывника должна быть индивидуальная карточка, соответствующая действующему законодательству со следующими разделами:
1. Основные сведения. Сведения о призывнике (ФИО, дата рождения, паспортные данные, реквизиты удостоверения призывника, Адрес регистрации, фактический адрес, образование, семейное положение, место работы(учебы), срок окончания учебы) должны заполняться автоматически из карточки физического лица. Сведения о воинской специальности, знании иностранных языков, наличии судимости, спортивных разрядов - должны заполняться в ручную.
2. Близкие родственники. В данном разделе должны указываться все родственники входящие в состав семьи физического лица. Вкладка должна заполняться автоматически в соответствии с данными из вкладки «Родственники» физического лица.
3. Отметки о воинском учете. В данной вкладке должна учитываться постановка и снятие призывников с воинского учета.
Модуль «Формирование отчетности»
Модуль должен обеспечивать оперативное построение и отображение многомерных аналитических отчетов на основе информации, хранящейся в базе данных.
Отчеты должны быть сгруппированы по группам и содержать следующие данные:
1) Государственное статистическое наблюдение:
? Форма №14;
? Приложение к форме №14.
Данные отчеты должны также отображаться в НТМL формате с возможностью «проваливания» в количественные показатели с целью их детализации.
2) Отчеты модуля «Миграция, ЗАГС»:
? Заявление о регистрации по месту жительства;
? Заявление о регистрации по месту пребывания;
? Заявление о снятии с регистрационного учета по месту жительства; ? Листки прибытия; ? Листки убытия.
3) Налоговые ведомости:
? Сведения о зарегистрированных правах на недвижимое имущество (в том числе земельные участки) и сделках с ним, правообладателях недвижимого имущества и об объектах недвижимого имущества (Приказ 23Н).
Должна быть реализована выгрузка данного отчета в xml формате для предоставления в налоговые органы. 4) Похозяйственная книга:
? Форма Похозяйственной книги утвержденная Приказом МСХ РФ от 11 октября 2010г. №345 «Об утверждении формы и порядка ведения похозяйственных книг органами местного самоуправления поселений и органами местного самоуправления городских округов».
5) Сводные ведомости:
Алфавитная книга хозяйств;
? Список проживающих;
? Список проживающих в сельском поселении более года (Форма 2В);
? Список проживающих в специализированных учреждениях (Форма 2С);
? Список проживающих до заданного возраста;
? Список населенных пунктов и населения;
? Список напоминаний о получении паспорта;
? Справка о количестве мужчин и женщин;
? Справка о молодых избирателях;
? Справка о национальном составе населения;
? Справка о численности населения до 18 лет;
? Справка о численности населения по полу и возрасту; ? Справка о количестве скота.
Данные отчеты должны также отображаться в НТМL формате с возможностью «проваливания» в количественные показатели с целью их детализации.
6) Справки населению:
? Бланк справки;
? Выписка из домовой книги;
? Выписка из финансово-лицевого счета;
? Справка в регистрационную палату;
? Справка о зарегистрированных жильцах;
? Справка о наличии личного подсобного хозяйства;
? Справка о наличной собственности и налогах; ? Справка о наследстве;
? Справка о незанятости;
? Справка о собственности; ? Справка о составе семьи.
Должен быть разработан удобный механизм просмотра взаимосвязей между элементами одного реестра с элементами другого реестра, путем перехода из одного реестра в другой.

2.2 Обоснование проектных решений по видам обеспечения АС

Требования к программному обеспечению

Для организации возможности доступа пользователей, Системы должна обеспечивать работу на следующих операционных системах:

? Windows XP и выше;

? Linux для рабочих станций и серверов;

? MacOS;

? любой другой операционной системы, в которой есть возможность запуска одного из web-браузеров (см. ниже);

Должна быть реализована возможность работы пользователей в следующих web-браузерах:

? Internet Explorer 7 и выше (только для Windows);

? Mozilla Firefox 1.5 и выше;

? Safari 3 и выше;

? Google Chrome 3 и выше.

Система должна обеспечивать комфортную работу пользователей при доступе к сети Интернет со скоростью 256 Кбит/сек.

Инсталлятор должен обеспечивать:

? проверку соответствия аппаратного комплекса минимальным требованиям с сообщениями о нарушениях;

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

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

? отсутствие паразитных файлов в системном каталоге;

? установку продукта без перезагрузки операционной системы.

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

Требования к организационному обеспечению системы
Организационное обеспечение системы должно быть достаточным для эффективного выполнения персоналом возложенных на него обязанностей при осуществлении автоматизированных и связанных с ними неавтоматизированных функций системы.
Заказчиком должны быть определены должностные лица, ответственные за:
? обработку информации АС;
? администрирование АС;
? обеспечение безопасности информации АС;
? управление работой персонала по обслуживанию АС.
К работе с системой должны допускаться сотрудники, имеющие навыки работы на персональном компьютере, ознакомленные с правилами эксплуатации и прошедшие обучение работе с системой.
Требования к аппаратному обеспечению серверов
Для организации возможности доступа и комфортной работы 2000 пользователей, обработки и хранения информации необходимо обеспечить функционирование [22] Системы на серверах со следующими характеристиками:
1. Сервер базы данных:
? 2 четырех ядерных процессора Xeon 2Ггц или эквивалент;
? Оперативная память: не менее 8 ГБ; ? Дисковое пространство: не менее 400 ГБ.
2. Web-сервер: ? Apache 2.2 и выше; ? Nginx 0.7 и выше.
3. Необходима возможность работы сервера базы данных Системы на следующих СУБД:
? IBM DB2 не ниже 6.0;
? Firebird 1.5 и выше;
4. Канал связи между серверами не менее 1Гбит.
5. Внешний канал связи не менее 10Мбит.

2.3 Разработка системной архитектуры

Системная архитектура в системе стандартов предприятия определяет правила формирования своих компонентов и обеспечения взаимодействия между ними [24].

Системная архитектура состоит из трех взаимосвязанных компонентов:

• прикладной архитектуры;

• архитектуры данных;

• технической архитектуры.

Прикладная архитектура включает в себя [23]:

1) прикладные системы (приложения), обеспечивающие исполнение

бизнес-функций и бизнес-процессов;

2) интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных; 3) средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

1) автоматизированные базы данных, обеспечивающие накопление, хранение и обработку данных, определяемых бизнес-архитектурой;

2) применяемые для этого системы управления базами данных или хранилищами данных;

3) правила и средства санкционирования доступа к данным.

Техническая архитектура состоит из:

1) сетевой архитектуры

2) архитектуры платформ.

Сетевая архитектура включает в себя:

1) локальные и территориальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру;

2) используемые в сетях коммуникационные протоколы, сервисы и системы адресации;

3) аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя [25]:

1) аппаратные средства вычислительной техники ? серверы, рабочие станции, накопители и другое компьютерное оборудование;

2) операционные и управляющие системы, утилиты и офисные программные системы;

Состав технической инфраструктуры и ее стоимость по ценам 2014г. с интернет источников (табл. 2).

Таблица 2 - Обоснование готовности технической инфраструктуры к внедрению

Характеристика

Цена (руб.)

1.

Монитор

Samsung

SyncMaster

191N

Тип: TFT/PVA

Диагональ: 19

Разрешение: 1280x1024 (5:4)

Яркость: 250 кд/м2

Котрастность: 500:1

8500

2.

Системный блок

14022

3.

Принтер

LaserJet

M225rdn

HP

Pro

6 234

4.

Телефон

898

5.

Факс

5 917

6.

Клавиатура

Oklick 110 M Standard

Keyboard Вlack USB

210

7.

Мышь

Genius NetScroll 100X

Black USB

250

8.

Операционная система:

Microsoft Windows 7

Домашняя Версия 2009

SP1;

Microsoft Office;

Adobe Reader X;

Антивирус: Kaspersky

2013;

Архиватор: 7 Zip;

Почта: MS Outlook;

Интернет браузер: Internet

Explorer, Google Chrome;

9.

Итого:

36 031*6

Все компьютеры осуществляют взаимосвязь посредством беспроводной сети, через интернет. Передача информации осуществляется через электронную почту. Каждый АРМ оснащен стандартным набором программного обеспечения, а также ПК, телефоном и принтером.

В настоящее время техническое оснащение рабочих мест соответствует корпоративным требованиям.

Интерфейс системы

Рисунок 7. Окно входа в программу

После входа в программу открывается главная форма (рис. 8). В этой же форме в меню справка выбирается вид справки.

Автоматизированная информационная система сельского муниципального образования [21] для ведения похозяйственной книги и форм организации ведения регистрационных записей «Похозяйственный учет». Открываем программу «ПОХОЗЯЙСТВЕННЫЙ УЧЕТ»

Рисунок 8. Главная форма.

При выборе вида справки открывается форма списка граждан (рис. 9). Из списка выбирается тот гражданин, которому нужно выдать справку и дальше

Рисунок 9. Форма списка гражданина

Дважды щелкаем левой кнопкой мыши по иконке «ПХУ_S1», появляется окно входа в программу (рис. 7), который содержит информацию о пути к программе в данном компьютере, номер версии (обновления), а также контактную информацию о фирме-разработчике программы «Похозяйственный учет».

В Форме предварительного просмотра справки (рис. 10), можно вывести справку в Word, в Excel, в PDF и в HTML форматы. Можно так же просто распечатать.

Рисунок 10. Форма предварительного просмотра.

В данной главе были сформированы требования к внедрению системы, разработаны требования к системе, построены диаграммы при помощи методологии Microsoft Visio, а именно модель процесса учета выдачи справок (TO-BE), инфраструктура Администрации села Ташбулатово.

В результате разработано техническое задание на внедрение программного средства «ПХУ», а также разработаны информационная инфраструктура.

Заключение

Целью данной работы является разработка технического задания на внедрение программного комплекса «Похозяйственный учет» в администрацию сельского поселения села Ташбулатово МР Абзелиловский район.

Согласно цели курсовой работы были выполнены следующие задачи:

• обследование объекта информатизации;

• анализ существующих разработок и обоснование выбора технологии;

• разработка проектных решений;

• разработка концепции;

• разработка системной архитектуры.

Были сформированы требования к внедрению системы, разработаны требования к системе, построены диаграммы при помощи методологии Microsoft Visio, а именно модель процесса учета выдачи справок (TO-BE), инфраструктура Администрации села Ташбулатово и DFD, был подробно рассмотрен основной процесс отдела выдачи справок Администрации СП Ташбулатово «Выдача справок». С помощью данной модели был проведен (Приложение А) анализ «узких мест».

Был проведен анализ существующих решений для упрощения приема населения. После анализа было принято решение внедрить АИС «ПХУ». Данная программа обеспечивает создание списков населения с разделением на трудоспособных, безработных, детей, учащихся, льготников, пенсионеров, инвалидов и т.п., отслеживает процесс миграции населения.

На основании проведенных обследований было разработано техническое задание (Приложение В) на внедрение программного комплекса «Похозяйственный учет»

Список используемых источников

1. Положение о территориальных отделах Администрации Абзелиловского муниципального района Республики Башкортостан, 2009.

2. ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

3. ГОСТ 34.601-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания.

4. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

5. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам.

6. ГОСТ 24.103-84 «Автоматизированные системы. Основные положения».

7. ГОСТ 24.104-85 «Автоматизированные системы. Общие требования».

8. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.

9. ГОСТ 7.1-2003. Библиографическая запись. Библиографическое описание. Общие требования и правила составления.

10. ГОСТ 7.32-2001 ССИБИД. Отчет о НИР. Структура и правила оформления.

11. ГОСТ Р 50922-96. Защита информации. Основные термины и определения.

12. ГОСТ Р 51275-99. Защита информации. Объект информации. Факторы, воздействующие на информацию. Общие положения.

13. ГОСТ Р ИСО/МЭК 15271-02 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 Процессы жизненного цикла программных средств

14. ГОСТ Р ИСО/МЭК 159 10-2002. Процесс создания документации пользователя программных средств.

15. Малюкова К.В., Назарова О.Б., Давлеткиреева Л.З. Развитие технической инфраструктуры страховой компании // Современные научные исследования и инновации. 2013.

16. Назарова, О. Б. Требования к курсовой работе по дисциплине «Проектирование информационных систем» : метод.указания для студ. 3 курса направления «Бизнес-информатика» / О. Б. Назарова. - Магнитогорск :МаГУ, 2009. - 22 с.

20. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

21. СМК-МИ 29.2-06. Общие требования к построению, содержанию, оформлению, обозначению и управлению Стандартом университета (организации) и Методической инструкцией.

22. СМК-СМГТУ-29-06. Система менеджмента качества. Стандарт организации. Структура, содержание и изложение, правила оформления и обозначения документации системы менеджмента качества.

23. Требования к выпускной квалификационной работы студентов специальности 080801 «Прикладная информатика (в экономике)»: метод. рекомендации / под общ. ред. О.Б. Назаровой. - Магнитогорск : МаГУ, 2009. - 82 с

24. Федерального закона от 06.10.2013 г. №131-ФЗ «Об общих принципах организации местного самоуправления в РФ».

25. Должностная инструкция специалиста 1 категории, 2009 г.

26. «Земельный кодекс Российской Федерации» от 25 октября 2010 года №136-ФЗ;

Приложение

Анализ «узких» мест «Узкие» места будем определять на основе анализа построенной модели ASIS. При этом анализ будем проводить по следующим направлениям:

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

? анализ функционального взаимодействия выбранной предметной области с внешними объектами;

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

? анализ информационных потоков и информационного взаимодействия с внешними объектами;

? анализ информационной инфраструктуры выбранной предметной области и предприятия в целом.

Анализ функциональной деятельности и функционального взаимодействия отдела выдачи справок
В нашей предметной области рассматриваются следующие основные документы:
• документы клиента
• справки
• ведомости
• отчет о работе отдела
Справка или ведомость может быть составлен неправильно, если сами данные введены неправильно в базу или были допущены ошибки при заполнении документа.
В обоих случаях это может быть связано с ошибкой персонала или ошибкой оборудования. Сбой оборудования мог произойти в случае поломки или отключения электричества. Оборудование могло сломаться, если изначально было не качественным или из-за ошибки пользователя. Если недостоверность документа произошел из-за ошибки персонала, то в случае несоблюдения процедуры проверки, потери или порчи документов и ошибки их учета.
В нашей предметной области рассматриваются следующие основные функции: учет выдачи справок, а именно прием заказа, выдача справки, формирование отчетности. В модели бизнес-процесса отражена деятельность одного сотрудника и соответствующих ему функций: формирование справок. Анализ внутреннего документооборота отдела выдачи справок Справка - это…
• документ, содержащий описание и подтверждение тех или иных фактов и событий.
• документ, подтверждающий факты биографического или служебного характера.
Для формирования более полного отчета, руководитель формирует требования к отчетности, в которых содержится информация о соответствии законодательству РФ, список необходимых для отчетности документов.
Отчет - электронный документ, представляет собой таблицу с данными о проделанной работе, в соответствии с требованиями к отчетности.
Техническое задание на внедрение программного средства «Похозяйственный учет»
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
На внедрение программного средства «Похозяйственный учет» в Администрацию села Ташбулатово Абзелиловского района
На 35 листах
Оглавление 1. Общие сведения ......... 51 2. Назначение и цели внедрения системы ...... 51 3. Характеристика объекта автоматизации ...... 53 4. Требования к системе «Похозяйственный учет» ............ 54 5. Состав и содержание работ по созданию системы...... 80 6. Порядок контроля и приемки системы ............ 81
7. Требования к составу и содержанию работ к вводу системы в действие ............... 82
8. Требования к документированию ............................. 83 9. Источники разработки
1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование системы
1.1.1. Полное наименование системы
Автоматизированная информационная система сельского муниципального образования для ведения похозяйственной книги и форм организации ведения регистрационных записей «Похозяйственный учет».
1.1.2. Краткое наименование системы Краткое название: ПХУ, Система. программный информация несанкционированный архитектура

2. НАЗНАЧЕНИЕ И ЦЕЛИ ВНЕДРЕНИЯ СИСТЕМЫ

2.1. Назначение системы
Система ПХУ предназначена для автоматизации деятельности Администрации села Ташбулатово по следующим направлениям:
? для ведения похозяйственных книг в электронном виде для учета населения;
? для электронного ведения паспортного и воинского учета;
? общего земельного учета, скота, техники и жилого фонда; ? для возможности выдачи разнообразных сведений, справок; ? для ведения статистической отчетности.
2.2. Цели внедрения системы
Общими целями системы ПХУ являются:
1. Объединение различных направлений учета в единую систему, обеспечение единообразия учета в муниципальных образованиях региона на основе использования единого информационного, методологического пространства.
2. Формирование качественной и достоверной базы данных, исключение дублирования, уменьшение количества ошибок.
3. Предоставление удобного инструмента для оперативного формирования срезов данных и справок для населения, планирования доходов, получения паспорта муниципального образования и расчета показателей, необходимых для прогноза социально-экономического развития.
4. Обеспечение возможности обмена данными с налоговыми органами, с администрацией муниципального района, с органами государственной статистики;
5. Повышение качества обслуживания населения.
6. Повышение собираемости собственных доходов как за счет налоговых, так и за счет неналоговых поступлений (самообложение граждан).
7. Обеспечение консолидации данных всех поселений в единой базе администрации района для выполнения сравнительного анализа и получения сводных отчетов по району в целом.
В общее число подразделений, включаемых в работу с системой, входят:
? отдел выдачи справок;
? отдел землеустройства; ? паспортный стол (ВУС).
2.2.1. Для реализации поставленных целей система должна решать следующие задачи
1. Паспортный стол:
Заявление о выдаче (замене) паспорта;
Карточка регистрации;
? История замены документа (Архивные данные);
? Сведения о регистрации / снятии физического лица;
? Свидетельство о регистрации;
? Сведения о фактах первичной выдачи или замены док., удостов.
личность гражд. РФ;
? Списки.
2. Воинский стол:
? Пользовательские отчеты;
? Карточки;
? Еженедельный отчет о движении военнообязанных запаса; ? Общий именной список.
3. Отчеты:
? Списки населения;
? Льготники;
? Занятость населения;
? Избиратели;
? Дети;
? Выбывшие;
? Страхование;
? Жилой фонд;
? Земли, скот, техника; ? Воинские; 4. Справки:
? О составе семьи;
? О местопроживании;
? О регистрации;
? Выписка из похозяйственной книги;
? О совместном проживании детей;
? Об отсутствии детей, временно выбывших;
? О временной регистрации;
? О выбытии;
? О смерти;
? О наличии печного \ центрального отопления;
? О праве собственности на жилье (+ состав семьи);
? О праве собственности на жилье;
? О наличии подсобного хозяйства;
? О составе семьи и наличии скота;
? О наличии скота в хозяйстве;
? Справка о наличии скота и техники;
? О составе личного подсобного хозяйства;
Справка в военкомат (регистрация);
Справка о приватизации;
? Справка о не работающем;
? Справка о прописке и выписке;
? Справка об отсутствии собственного жилья;
? Поквартирная карточка;
? Составная пользовательская справка.
5. Кадастровый учет земель (ЗУ):
? Юридические лица;
? Физические лица; ? Земли (собственность).
6. Земельные участки:
? Сведения о ЗУ;
? Выгрузка сведений о ЗУ;
? Загрузка сведений о ЗУ;
? Налог на ЗУ;
? Аренда ЗУ;
? Договора;
? Списки ЗУ;
? Настройка справочника кадастровых №.

3. Характеристика объекта автоматизации

3.1 Общие сведения о предприятии
Структура предприятия
Глава Администрации сельского поселения Ташбулатовский сельсовет Муниципального района Абзелиловский район разрабатывает схему управления, которая включает организационную структуру (рис.Б.1) территориального отдела и органы управления отраслевой и межотраслевой компетенции, и представляет ее на утверждение представительному органу муниципального образования.
Рисунок Б.1 Организационная структура
3.2 Существующее программное обеспечение
На момент написания ТЗ в отделах справок, зумлеустроительства и паспортного стола используются следующие ПО:
MS Office 2003, 2007(Word, Excel); Антивирус «Касперский».
3.3 Существующее нормативно-правовое обеспечение
Существующее нормативно-правовое обеспечение составляет следующие федеральные, муниципальные, локальные нормативные правовые акты:
? Конституция Российской Федерации;
? Трудовой кодекс Российской Федерации;
? Коллективный трудовой договор;
? Правовые и нормативные документы Администрации сельского поселения села Ташбулатово МР Абзелиловский район; ? Положение о внутреннем распорядке.

4. ТРЕБОВАНИЯ К СИСТЕМЕ «ПОХОЗЯЙСТВЕННЫЙ УЧЕТ»

4.1 Общие требования к системе
Система должна быть построена на основе модульной архитектуры и обеспечивать возможность наращивания функциональности путем добавления новых модулей. Система должна позволять при настройке рабочего места конкретного пользователя комбинировать эти модули в любых сочетаниях для обеспечения возможности выполнения одновременно нескольких функциональных ролей.
Система должна иметь открытые интерфейсы для обеспечения возможности интеграции со смежными информационными системами.
Система должна иметь централизованную базу данных с предоставлением удаленного защищенного доступа для сельских поселений и городских округов региона.
Система должна работать в режиме Web-интерфейса, функционирующего в различных операционных средах - Microsoft Windows, Unix (Linux), Apple MacOS.
Сервер базы данных должен поддерживать мультиплатформенность и устанавливаться на различные операционные системы - Microsoft Windows, Unix (Linux) и т.д.
Система не должна требовать регулярного администрирования. Штатные средства Системы должны позволять проводить удаленное администрирование базы данных и настройку Системы (при наличии технической возможности доступа к серверам Системы).
Пользовательский интерфейс Системы должен обеспечивать необходимое качество взаимодействия человека с машиной и комфортность работы пользователей.
4.2 Требования к структуре и функционированию системы
Система «Похозяйственный учет» должна быть установлена на рабочих местах (персональных компьютерах), объединенных между собой с помощью локальной сети и должна использовать единую базу данных, расположенную на выделенном сервере. Управление базой данных осуществляется по технологии клиент-сервер. Система должна функционировать в многопользовательском режиме, т. е. когда одновременно с базой данных взаимодействуют несколько пользователей, которые не только просматривают информацию, но и активно изменяют её.
В Системе должны быть разработаны следующие модули:
? Модуль «Ведение похозяйственного учета»;
? Модуль «Учет юридических лиц, зарегистрированных на территории муниципальных образований»;
? Модуль «Миграция, ЗАГС»;
? Модуль «Воинский учет»;
? Модуль «Формирование отчетности».
4.3. Требования к персоналу
Рисунок Б.2 - Диаграмма UseCase

Предполагается, что обслуживающий персонал будет состоять как минимум из следующих категорий работников, прошедших соответствующее обучение:

1. Специалист по справкам;
2. Землеустроитель;
3. Паспортистка (специалист ВУС).
Помимо персонала перечисленного выше, работу Системы обеспечивает также ремонтный персонал, непосредственно в функционировании Системы не участвующий, однако способный выполнить ремонт отказавших технических средств.
4.4 Требования к безопасности
Требования к эргономике
Пользовательский интерфейс Системы должен быть интуитивно понятен, и обеспечивать необходимое качество взаимодействия человека с машиной и комфортность работы персонала, удобство доступа пользователя к вводу и просмотру информации, наглядность ее представления. Пользовательский интерфейс должен быть настроен на конкретную роль пользователя.
Требования к защите информации от несанкционированного доступа
Средства Системы должны обеспечивать сохранность данных и предоставлять администратору Системы возможность выбора уровня защищенности базы данных от несанкционированного использования.
Вход в пользовательскую часть Системы и дальнейшая работа должны осуществляться только при указании имени пользователя и его пароля.
Должна быть реализована возможность назначения для каждого пользователя одной или более ролей, которые этот пользователь выполняет в Системе.
В Системе должна быть предусмотрена возможность настройки для каждой пользовательской роли прав доступа к информационным ресурсам и выполнения определенных операций. Для каждого справочника и архива документов должны задаваться права на создание в них новых записей, их редактирование и удаление.
Для каждой пользовательской роли должна быть предусмотрена возможность задать специфичное главное меню Системы с набором тех функций, которые доступны данной роли.
Доступ к системе посредством Web-интерфейса должен осуществляться с помощью SSL сертификатов и защищенного протокола HTTPS
Для целей защиты данных сервера БД от несанкционированного доступа конечные пользователи Системы не должны знать пароль доступа непосредственно к самому серверу БД. Авторизация в Системе должна предусматривать доступ к функциям приложения, а не к серверу базы данных.
...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.