Разработка автоматизированного рабочего места инспектора по начислению пенсии

- лишние работы, проводимые инспектором;

- дублирующие работы;

- неэффективный документооборот.

Модель ТО-ВЕ нужна для оценки последствий внедрения разрабатываемой ИС и анализа альтернативных, лучших, путей выполнения работы и документирования того, как фонд будет функционировать в будущем. Модели AS-IS и ТО-ВЕ позволяют описать начальное и конечное состояние предприятия - до и после внедрения ИС.

Внедрение информационной системы неизбежно приводит к перестройке существующих бизнес-процессов предприятия. В моем случае по требованиям заказчика, данную перестройку необходимо избежать. Поэтому функциональные модели AS-IS и TO-BE будут абсолютно идентичны.

Выводы к разделу

В результате анализа бизнес-процессов разработана функциональная структура ИС места инспектора по начислению пенсии. Было рассмотрено логическое представление системы, было представлено физическое представление системы, проведено моделирование структуры данных. Все эти действия были необходимы для реализации программного обеспечения удовлетворяющего все требования заказчика.

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

На данном этапе происходит реализация приложений. Этот этап создания ИС является наиболее сложным и трудоемким для разработчика. Это происходит из-за того, что на этом этапе должны быть реализованы в полном объеме все требования предъявляемые заказчиком к разрабатываемой системе. Эти требования должны быть четко и в нужной форме отображены в разрабатываемой системе. Иначе, если этого не произойдет, придется процесс реализации выполнять заново. Каждый разработчик должен выбрать для себя оптимальную среду для разработки системы, но следует заметить, что при реализации приложения никак не обойтись без написания программного кода. Именно при написании программного кода, будут реализовываться некие функции, которые должна выполнять система. В зависимости от выбранной среды реализации системы, программный код будет выглядеть по-разному.

В разрабатываемой мной системе реализация приложения выполнялась в MS Access 2003. В данном продукте компании Microsoft содержится ограниченный набор инструментариев создания информационной системы, но есть встроенный язык программирования - Visual Basic. Именно с помощью данного языка реализовывались те функции, которые должна была выполнять разрабатываемая система по требованию заказчика, но которые нельзя было выполнить встроенного набора инструментов MS Access 2003.

Ниже будут описаны основные функции системы:

- стартовая форма системы (рисунок 3.1). Данная форма является кнопочной формой и соответственно выполняет свою функцию. При нажатии этой кнопки открывается следующая форма, где пользователь должен авторизироваться.

- форма «Авторизации» (рисунок 3.2) состоит из текстовых полей, где нужно ввести свои логин и пароль и двух кнопок: далее и выход из программы. После правильной авторизации, при нажатии на кнопку «Далее» (програмный код кнопки «Далее» представлен в приложении Г рисунок Г.1), открывается форма на которой есть еще две кнопки (рисунок 3.4). Кнопка «Регистрация пенсионера» - форма регистрации пенсионера (рисунок 3.5). Программный код кнопки представлен в приложении Г рисунок Г.4. Кнопка «На главную», - позволяет вернуться для выхода из программы при нажатии на кнопку «Выход» (программный код кнопки представлен в приложении Г рисунок Г.2). «Расчет пенсии»(программный код кнопки представлен в приложении Г рисунок Г.5) позволяет перейти на форму «Расчет» для расчета пенсии (рисунок 3.6.). На всех этих присутствуют кнопки со своими кодами. Если пользователь неправильно ввел логин или пароль, программа выдает ошибку и повторную возможность ввода (рисунок 3.3.).

- на форме «Расчет» (рисунок 3.6) есть кнопка с названием одинаковым кнопкам всех форм «На главную», имеет идентичный код (программный код кнопки представлен в приложении Г рисунок Г.3). При нажатии на кнопку «Итоговые начисления» производится итоговый расчет пенсии (программный код кнопки представлен в приложении Г рисунок Г.6). А при нажатии на кнопку «Сформировать отчет» (рисунок 3.7) (программный код кнопки представлен в приложении Г рисунок Г.8) открывается форма «Отчет», где представлении четыре кнопки: «Итоговые начисления», «По месту жительства», «Расчет ИКП», для формирования отчетов и «Отправить по почте», для перевода отчетов в финансовые учреждения (программный код кнопки «Отправить по почте» представлен в приложении Г рисунок Г.9).



Рисунок 3.1 - Стартовая форма системы

Рисунок 3.2 - Форма «Авторизация»

Рисунок 3.3 - Повторная авторизация

Рисунок 3.4 - Стартовая форма для инспектора



Рисунок 3.5 - Форма «Оформление пенсионера»

Рисунок 3.6 - Форма «Расчет пенсии»

Рисунок 3.7 - Форма «Отчет»



Рисунок 3.8 - Форма «Итоговые начисление»

Рисунок 3.9 - Отчет «По месту жительства»

Рисунок 3.10 - Отчет «Расчет ИКП»

Общий вид схемы данных системе предоставлен в приложении Д.

3.2 Взаимодействие приложения с источниками данных

Чтобы информационная система производила работу с большими объемами информации, она должна взаимодействовать с источниками данных. В моем случае таким источником будет выступать MS Access 2003, а взаимодействие приложения с этим источником будет осуществляться благодаря запросам.

Запросы часто используются с целью выборки данных для анализа и создания отчетов.

Примерами таких запросов могут послужить:

- определение числа строк в таблице (либо числа строк, которые удовлетворяют какому-то условию или содержат определенное значение);

- получение суммы по набору строк в таблице;

- поиск наибольшего, наименьшего и среднего значений из столбца таблицы (из всех или из каких-то конкретных строк);

- определение данных по заданному критерию (по дате, по реквизитам пенсионера и т.д.), который задает пользователь системы.

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

- запрос на формирование отчета по начислению пенсии;

- запрос на расчет ИКП;

- запрос на формирование статистики по месту жительства пенсионеров.

Запрос на формирование отчета по начислению пенсии. Данный запрос формирует все необходимые данные для формирования отчета по начислениям. Результат запроса можно увидеть на рисунке 3.11. Программный код sql-запроса можно увидеть на рисунке Е.1 приложения Е.

Запрос на формирование статистики по месту жительства пенсионеров. Смысл данного запроса состоит в том, чтобы выбрать из таблицы «Оформление пенсионера», данные поля - Адрес прописки, и составить отчет по этому параметру. Результат запроса на рисунке 3.12. Программный код запроса на рисунке Е.2 приложения Е.

Запрос на формирование данных для составления отчета на расчет ИКП. Данный запрос выводит информацию благодаря которой можно сделать вывод о страховых взносах. Результат запроса на рисунке 3.13. Программный код sql-запроса показан на рисунке Е.3 приложения Е.

Благодаря данным запросам создавались отчеты системы.

Рисунок 3.11 - Результат запроса «Итоговые начисления»

Рисунок 3.12 - Результат запроса «По месту жительства»

Рисунок 3.13 - Результат запроса «Расчет ИКП»

3.3 Тестирование приложения

Тестирование проводится для повышения качественных характеристик разрабатываемого ПО. Это происходит потому, что процесс тестирования подразумевает многократное выполнение программы с целью выявления каких-либо ошибок, чтобы потом их исправить. А так как все ошибки будут исправлены, то соответственно, качество разработанного ПО будет хорошим.

Из определения тестирования вытекает ряд принципов.

Принцип 1. Процесс тестирования более эффективен, если проводится не автором программы. Тестирования направленно на выявление ошибок поэтому, чем больше ошибок выявлено, тем эффективно прошло тестирование.

Принцип 2. Описание предполагаемых значений результатов тестовых прогонов должно быть необходимой частью тестового набора данных.

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

Принцип 3. Необходимо досконально изучать результаты применения каждого теста.

Принцип 4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также тщательно, как для правильных, предусмотренных.

Принцип 5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.

Принцип 6. Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части.

Разработанная мной ИС тестировалась с помощью метода «черного ящика». При построении тестов по стратегии «черного ящика» программа рассматривается как «черный ящик» (не известны текст программы и ее логика), а исходной информацией для тестовых наборов служат ее спецификации.

Тестирование программы «Автоматизация места инспектора по начислению пенсии» методом «черного ящика». Тестирование проводилось вручную. При обнаружении ошибок система подвергалась доработке, а после доработки отправлялась опять на тестирование. Тестирование системы производилось частично.

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

- ввод входных данных;

- обработка запроса;

- формирование отчета;

- вывод отчета на экран.

Входными данными будет служить информация о пенсионере: ФИО, заработная плата за период 60 месяцев, ИКП, страховой стаж, стажевый коэффициент;

Выходными данными будут служить отчеты, в которых должна содержаться необходимая статистическая информация (итоги начисления пенсии). Ниже будут приведены примеры тестирования системы.

Тестирование.

Тест 1. Необходимо вывести результаты начислений в этом месяце. Результат отчета показан на рисунке 3.14.

Рисунок 3.14 - Результат теста по выводу итоги начисления пенсии

Тест 2. Необходимо вывести отчет по месту жительства.

Входными данными будут являться ФИО пациента и адрес проживания. Результат теста показан на рисунке 3.15.



Рисунок 3.15 - Отчет по месту жительства

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

Тест 3. Необходимо вывести отчет по расчету ИКП. Результат тестирования можно посмотреть на рисунке 3.16

Рисунок 3.16 - Отчет по расчету ИКП

На данной стадии тестирования, тест прошел успешно т.к. входные данные (ФИО пенсионера и ИКП) полностью совпадают с результатами выходных данных. Отчет по результатам тестирования представлен в таблице 3.1

Таблица 3.1 - Отчет по результатам тестирования системы

Тестируемая группа отчетов
Номер теста	Название отчета	Последовательность действий	Ожидаемый результат	Результат теста
1	Итоговые начисления	Отображение отчета.	отчет отобразился; запрос на выборку выполняется правильно.	ОК
2	Отчет по месту жительства	Отображение отчета.	отчет отобразился; запрос на выборку выполняется правильно.	ОК
3	Отчет по расчету ИКП	Отображение отчета.	отчет отобразился; запрос на выборку выполняется правильно.	ОК

Из проведенного тестирования ИС можно сделать вывод, что система работает хорошо. В ней производится все, что необходимо инспекторам для их повседневной работы.

3.4 Методика развертывания приложения

Чтобы разработанной системой могли пользоваться работники предприятия заказчика, необходимо разработать методику развертывания системы. Развертываете приложения, является главным этапом функционирования системы.

Требования к развертыванию программного продукта.

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

MS Access 2003. Данный продукт входит в пакет Microsoft Office;

Технические требования, которые должны быть выполнены для работы системы «Автоматизированное место инспектора по начислению пенсии»:

- рабочая станция с процессором не ниже Pentium II;

- сетевая карта 100 Mb/s или выше;

- оперативная память не ниже 64 Mb;

- необходимое свободное место на жестком диске не менее 50 Mb.

План развертывания системы.

В папке с установочными файлами запустите ACCESS_INSTAL.EXE и выберете удобный для вас путь распаковки. Вы можете создать ярлык и поместить его на «рабочий стол». Далее система сама проведет процедуру инсталляции, при этом на экране появиться несколько сообщений, указывающих, что происходит копирование файлов. Извлеченный файл будет являться эталонной базой данных. В данном файле содержится необходимый программный комплекс системы. Эталонная база будет работать только с собственной Access - базой.

3.5 Выводы к разделу

В данном разделе были рассмотрены вопросы, связанные с реализацией приложения, взаимодействия приложения с источниками данных (sql-запросы), была протестирована система и разработана методика развертывания созданной информационной системы.

4. Управление информационными проектами

4.1 Выбор жизненного цикла разработки ПО

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

В стандарте ISO/IEC 12207 не конкретизируются в деталях методы реализации и выполнения действий и задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области.

К настоящему времени наибольшее распространение получили следующие две основные модели жизненного цикла:

- каскадная модель, иногда также называемая моделью «водопад» (waterfall);

- спиральная модель.

Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими.

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

Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:

- на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное;

- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.

Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и при построении определенных информационных систем. Имеются в виду системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы реального времени.

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

Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен:

- существенная задержка получения результатов;

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

- сложность распараллеливания работ по проекту;

- чрезмерная информационная перенасыщенность каждого из этапов;

- сложность управления проектом;

- высокий уровень риска и ненадежность инвестиций.

Спиральная модель, представленная на рисунке 4.1, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы. При этом возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов.

Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой.



Рисунок 4.1 - Спиральная модель жизненного цикла информационной системы

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

Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работы на текущем -- недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации -- как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.

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

Рассмотрим преимущества итерационного подхода более подробно:

- итерационная разработка существенно упрощает внесение изменений в проект при изменении требований клиента;

- при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта);

- уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации и при выполнении начальных итераций выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т. п.

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

- итерационный подход упрощает повторное использование компонентов (позволяет использовать компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;

- спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что при использовании каскадной модели выполняется только перед внедрением системы;

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

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

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

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

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

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

В таблице 4.2 представлены итоговые результаты процесса выбора модели жизненного цикла.

Таблица 4.2 - Определение оптимальной модели жизненного цикла в баллах

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	2	2	5	7	4	4
Участники команды разработчиков	3	2	8	9	3	3
Коллектив пользователей	2	2	2	5	1	4
Типы проектов и рисков	4	5	8	9	4	6
Итого	13	11	23	30	12	17

4.2 Определение цели и области действия программного проекта

Цель данного программного проекта автоматизация рабочего места инспектора по начислению пенсии в Государственном учреждении - Управление Пенсионного фонда РФ .... Автоматизация будет заключаться в:

- ускорении формирования отчетов по итогам начисления;

- возможности в любой момент времени получить достоверную информацию о сбережениях клиента;

- ускорении и упрощении распечатки отчетов;

- получении любой интересующей инспектора информации в течении нескольких секунд.

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

Будет:

- использоваться для приема и передачи данных;

- предназначаться для автоматизации рабочего места инспектора по начислению пенсии;

- использовать мобильные технологии.

Не будет:

- использоваться в учебных целях;

- переносится на другие платформы;

4.3 Создание структуры пооперационного перечня работ

Структура пооперационного перечня работ разрабатывалась в приложении Microsoft Office Project 2003/16/.

Эта структура включает следующие задачи и подзадачи, представленные на рисунке 4.3.



Рисунок 4.3 Структура поперечного перечня работ

4.4 Идентификация задач и действий

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

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

Разработка требований к программному обеспечению;

- анализ существующих решений по автоматизации места инспектора;

- анализ предметной области;

- выбор методологии проектирования информационной системы;

- сбор требований;

- анализ и моделирование требований;

- спецификация требований;

- аттестация требований;

Проектирование информационной системы;

- архитектурное проектирование;

- проектирование пользовательского интерфейса;

- проектирование баз данных;

- обоснование выбора платформы создания ИС;

- проектирование модулей;

Реализация информационной системы;

- реализация приложения;

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

Тестирование приложения;

- тестирование модулей компонента в соответствии со спецификой продукта;

- изменение кода продукта;

- повторное тестирование измененного кода;

Развертывание;

- закупка необходимого оборудования;

- установка информационной системы;

- установка и настройка оборудования;

- обучение персонала.

Наглядно ресурсы необходимые для реализации ИС автоматизации рабочего инспектора по начислению пенсии представлены на рисунке 4.4.



Рисунок 4.4 Ресурсы необходимые для реализации ИС

4.5 Оценка размера и повторного использования ПО

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

Своевременность (timeliness) (в том смысле, который определен при обсуждении показателей качества: быстрота доведения проектов до завершения и продукции до рынка). При использовании уже существующих компонентов нужно меньше разрабатывать, а, следовательно, ПО создается быстрее.

Сокращение объема работ по сопровождению ПО (decreased maintenance effort). Если кто-то разработал ПО, то он же отвечает и за его последующее развитие. Известен парадокс компетентного разработчика ПО: "чем больше вы работаете, тем больше работы вы себе создаете". Довольные пользователи вашей продукции начнут просить добавления новых функциональных возможностей, переноса на новые платформы. Единственное решение парадокса - стать некомпетентным разработчиком, - чтобы никто больше не был заинтересован в вашей продукции.

Надежность. Получая компоненты от поставщика с хорошей репутацией, вы имеете определенную гарантию, что разработчики предприняли все нужные меры, включая всестороннее тестирование и другие методы контроля качества. В большинстве случаев можно ожидать, что кто-то уже испытал эти компоненты до вас и обнаружил все возможно остававшиеся ошибки. Для разработчиков создаваемые компоненты - будь то графические модули, интерфейсы баз данных, алгоритмы сортировки - это служебная обязанность, цель работы. Для вас это лишь второстепенная, рутинная работа, поскольку вашей целью является создание некоторой прикладной системы в вашей собственной области деятельности.

Эффективность. Факторы, способствующие возможности повторного использования ПО, побуждают разработчиков компонентов пользоваться наилучшими алгоритмами и структурами данных, известными в их конкретной сфере деятельности. Следует стремиться к достижению наилучших решений в своей области знаний, а в остальном использовать профессиональные разработки.

Инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в постоянные.

Многие из тех, кто признает повторное использование желательным, имеют в виду лишь первый из факторов в этом списке, - повышение производительности. Но это не всегда самый важный вклад повторного использования в процесс разработки ПО. Повышение надежности, например, является не менее существенным фактором. Тоже можно сказать и об эффективности.

Повторное использование можно рассматривать как особый показатель, отличающийся от других факторов. Его улучшение дает возможность улучшить почти все остальные факторы качества ПО. А причина чисто экономическая: если элемент ПО служит не для одного, а для многих проектов, то экономически разумно использовать лучшие методы создания высококачественного ПО - формальную верификацию, всестороннюю оптимизацию. В обычных разработках от таких приемов зачастую отказываются как от ненужного излишества. Однако для повторно используемых компонентов аргументация существенно изменяется - улучшение всего лишь одного элемента может оказаться выгодным для тысяч разработок.

Разрабатываемое ПО будет применяться в IT-отделе для регистрации пенсионеров, расчета пенсии и формированию отчетов. Разрабатываемое приложение позволяет повысить качество работы инспекторов, занимающихся расчетом пенсии, внутренней IT-инфраструктуры фонда. Система обеспечивает своевременное и эффективное взаимодействие с потребителями ИТ-услуг.

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

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

- соблюдение оговоренных сроков окончания работ;

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

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

Поэтому в данном случае уместно использовать автоматизированное средство Microsoft Project являющееся широко распространённой системой управления проектами.

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

Управление проектами в пакете Microsoft Project 2003 первым шагом подразумевает построение календарного графика работ.

Календарный график строится на основе так называемой диаграммы Ганта. Диаграмма Ганта - это линейный график, задающий сроки начала и окончания взаимосвязанных работ, с указанием ресурсов, используемых для их выполнения. Построенная диаграмма Ганта приведена в приложении Ж.

Помимо диаграммы Ганта для формирования календарного графика используется структурное планирование. Основная цель структурного планирования заключается в описании состава и взаимосвязи технологических операций, которые требуется выполнить для реализации проекта. Результатом структурного планирования является сетевой график проекта.

При идентификации задач и действий проекта, определении связей и времени выполнения задач можно рассчитать длительность выполнения всех задач.

4.6 Оценка длительности и стоимости разработки ПО

Оценка длительности и стоимости разработки программного обеспечения в пакете Microsoft Project 2003 производится на основе диаграммы Ганта (смотри приложение Ж). Диаграмма Ганта - это линейный график, задающий сроки начала и окончания взаимосвязанных работ, с указанием ресурсов, используемых для их выполнения /10/. Построенная диаграмма Ганта приведена в приложении Ж. Оценка длительности разработки ПО приведена на рисунке 4.5.



Рисунок 4.5 - Оценка длительности разработки ПО

4.7 Распределение ресурсов проекта

Под ресурсами в MS Project понимается всё то, что необходимо для реального выполнения работ проекта: исполнители (люди или механизмы), электроэнергия, различные расходные материалы.

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

Рисунок 4.6 - Список ресурсов

На рисунке 4.7 представлены трудозатраты ресурсов проекта.



Рисунок 4.7- Трудозатраты ресурсов проекта.

4.8 Оценка экономической эффективности

Под экономической эффективностью информационной системы понимают сопоставления результатов использования информационной системы с затратами на ее внедрение и эксплуатацию. Сопоставимость затрат и результатов предполагает их представление в денежной форме.

Методика оценки экономической эффективности проекта предполагает использование метода расчета чистого приведенного дохода, который предусматривает дисконтирование денежных потоков: все доходы и затраты приводятся к одному моменту времени. Чистый приведенный доход иногда называют чистым экономическим эффектом от внедрения проекта.

Центральным показателем в рассматриваемом методе является показатель NPV (net present value) - текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении.

Управление Пенсионного фонда РФ ... рассматривает эффективность внедрения информационного проекта.

Существует пять показателей для расчета экономической эффективности проекта: чистый приведенный доход, коэффициент возврата инвестиций, дисконтированный индекс доходности, внутренняя норма доходности и срок окупаемости проекта. Рассмотрим подробнее каждый показатель.

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

Расходы на проектирование включают в себя:

- расходы на лицензированное ПО MS Access = 20000 (рублей);

Расходы на оплату труда:

- разработчика = 5000;

- тестировщика = 2000;

- аналитика - консультанта = 3000;

- на обучение пользователей = 1000;

- на внедрение = 1000.

Расчет экономической эффективности проекта

Входные данные:

Срок, на который рассчитывается проект (кол-во мес n): 3 месяца.

Дополнительная прибыль от реализации проекта(DP): 30000р.

Ежемесячные затраты на реализацию проекта(Z1): 12000р.

Ежемесячные затраты на реализацию проекта(Z2): 12000р.

Ежемесячные затраты на реализацию проекта(Z3): 12000р.

Стартовые инвестиции (IC): 32000р.

Ставка дисконтирования (i): 1%.

Рассчитаем:

Чистый приведенный доход

NPV (net present value) является центральным показателем - текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении. При разовой инвестиции расчет чистого приведенного дохода можно представить следующим выражением:

(4.1)

где - ежемесячные денежные поступления в течение n месяцев, определяются по формуле:

- ежемесячная дополнительная прибыль от реализации проекта;

- ежемесячные затраты на реализацию проекта;

- стартовые инвестиции;

- ставка дисконтирования.

(руб.)

( 18000 / (1.01) + 18000 / (1.01)2 + 18000 / (1.01)3 )- 32000 = (17822 + 17645 + 17471) - 32000 = 20938

Коэффициент возврата инвестиций

Коэффициент возврата инвестиций ROI (Return of Investment) позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула расчета:

(4.2)

где - чистый приведенный доход,

- стартовые инвестиции.

т.к - проект прибылен.

Срок окупаемости

Для анализа инвестиций применяют и такой показатель, как срок окупаемости (payback period method) - продолжительность времени, в течение которого дисконтированные на момент завершения инвестиций прогнозируемые денежные поступления равны сумме инвестиций. Иными словами - это сумма лет, необходимых для возмещения стартовых инвестиций:

(4.3)

т.е. = 0.

= Число лет до года окупаемости + (Не возмещенная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)

Рассчитаем дисконтированный денежный поток:

Период	0	1 мес	2 мес	3 мес
Денежный поток	- IC	R1	R2	R3
Дисконтированный денежный поток	- IC	R1/(1+i)	R2/(1+i)2	R3/(1+i)3
Накопленный дисконт. денежный поток	- IC	NPV1	NPV2	NPV3
Период	0	1	2	3
Денежный поток	-32000	18000	18000	18000
Дисконтированный денежный поток	-32000	17821,78	17645,3289	17470,6227
Накопленный дисконтированный денежный поток	-32000	-14178,22	3467,11	20937,73

= 2 + 1174,58 / 13161,44 = 2,19 мес

Срок окупаемости проекта составляет 2 месяца 19 дней.

Дисконтированный индекс доходности (рентабельности)

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

(4.5)

Таким образом, индекс прибыльности равен:

= 1,65

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

Выводы к разделу

В данном разделе дипломного проекта определена цель и область действия программного продукта. Осуществлён выбор модели жизненного цикла процесса разработки. Составлена структура пооперационного перечня работ и на её основе построен график выполнения работ, приведена диаграмма Ганта и приведен расчет экономической эффективности проекта.

Заключение

В ходе выполнения дипломного проекта была разработана информационная система «Автоматизация рабочего места инспектора по начислению пенсии», выполняющая главную проблему, поставленную передо мной руководством пенсионного фонда - расчет пенсии.

Введение раскрывает актуальность выбранной темы дипломного проектирования, а также цели и задачи этого проектирования. Целью было - создание информационной системы «Автоматизация рабочего места инспектора по начислению пенсии» и эта цель была выполнена.

Первая глава уделена описанию моделирования бизнес - процессов пенсионного фонда, сбору требований выдвигаемых заказчиком для разрабатываемой системы. Данные требования являются основой разработки данной информационной системы. Также в первой главе была выбрана методология проектирования информационной системы. Было проведено моделирование бизнес - процессов фонда, сбор требований и их утверждение заказчиком. Также был произведен анализ уже существующих решений проблемы заказчика, и, проанализировав все эти решения, было решено, что нужно доработать уже имеющуюся информационную систему, отвечающую всем требованиям заказчика.

Вторая глава была посвящена проектированию пользовательского интерфейса, который в свою очередь является важным моментом реализации системы. Данный интерфейс получился, прост для понимания пользователями. После проектирования интерфейса программы, осуществлено проектирование баз данных, где были созданы логическая и физическая модели. Так как одним из требований заказчика является многопользовательский доступ, то выбор при создании данной информационной системы пал на MS Access 2002. MS Access 2002 для создания интерфейса пользователя и для хранения базы, а также предоставления многопользовательского доступа.

В третьей главе была описана основная функциональность разрабатываемой системы. Функции строились помощью стандартного набора MS Access, на некоторые. Некоторые функции прописывались самостоятельно на языке программирования Visual Basic, который является встроенным языком MS Access.

Извлечение всех необходимых пользователям разработанной информационной системы данных было осуществлено с помощью sql - запросов. В дипломной работе было произведено описание всех этих запросов.

Было произведено тестирование системы методом «черного ящика», были описаны входные и выходные данные производимых тестов, обоснован результат выполненного тестирования системы. Результат тестирования был положителен, т.е. при проведении тестирования ошибок вывода данных в системе не обнаружено.

Четвертая глава посвящена управлению разрабатываемым информационным проектом. Был произведен выбор жизненного цикла разработки данной информационной системы, обоснование выбора именно этого цикла. Выбор был сделан в пользу итерационной модели, так как следующий этап заканчивается только после завершения предыдущего, но также есть и возможность вернуться на предыдущий этап в случае обнаружения ошибок. Были выделены цели и область действия данного разрабатываемого продукта. Разработан пооперационный перечень работ выполняемых в ходе разработки и реализации данной системы. Были определены необходимые ресурсы для разработки и внедрения информационной системы, также было сделано распределение данных ресурсов. Также был осуществлен расчет экономической эффективности данного проекта. Работа была выполнена с использованием следующих программных продуктов: MS Access 2003, BPWin 4.0, ERWin 4.0, MS Project 2002, MS Word 2003, MS Excel 2003, MS Power Point 2003

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

Список литературы

1. Аглицкий Д.С., Аглицкий И.С. Российский рынок информационных технологий: проблемы и решения. - М.: 2000. ~ 208с.

2. Акперов И. Г. Управление проектами: учебно-методический комплекс / И. Г. Акперов, В. А. Долятовский. - Ростов-на-Дону: ИУБиП, 1999.

3. Андерсен, В Microsoft Access 2000: пер. с англ. / Вирджиния Андерсен. - М.: АСТ: Астрель,2005. - XXV, 641с.

4. Администрирование Microsoft SQL Server 2000. Учебный курс MCSA/ MCSE, MCDBA/Пер. с англ. -- 2-е изд., испр. -- М.: Издательско-торговый дом «Русская Редакция», 2002. -- 640 стр.: ил.

5. Алехин 3. ITIL -- основа концепции управления IT-службами / Открытые системы, № 3 (59), март 2001.

6. Амблер, С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. / С. Амблер. - СПб.: Питер, 2005.

7. Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. - СПб.: ПИТЕР, 2003.

8. Баронов В.В. и др. Автоматизация управления предприятием. - М.: ИНФРА-М, 2000.- 239с.

9. Виллариал Б.Программирование Access 2002 в примерах: Пер. с англ. -М.: КУДИЦ-ОБРАЗ, 2003. - 496 с.

10. Вигерс, К. Разработка требований к программному обеспечению.: Пер. с англ. / К. Вигерс.:- М.: Издательско-торговый дом «Русская редакция», 2004.

11. Вирджиния Андерсен «Microsoft Access 2003» пер. с англ.М.:АСТ:Астрель 2005; 678 стр

12. Вендров А.М.. Проектирование программного обеспечения экономических информационных систем - М.: Финансы и статистика, 2002 - 448 с.

13. Годин В.В. Управление информационными ресурсами: 17-модульная программа для менеджеров «Управление развитием организации». Модуль 17. - М.: ИНФРА-М, 1999.-432с

14. Гультяев, А. К. MS Project 2002. Управление проектами. Русифицированная версия: Практическое пособие / А. К. Гультяев. - СПб.: КОРОНА принт, 2003.

15. Дик В.В. Методология формирования решений в экономических системах и инструментальные среды их поддержки. - М.: Финансы и статистика, 2000. - 300с.

16. Дж. Макконнелл Основы современных алгоритмов.2-е дополненное издание Москва:Техносфера, 2004. - 368с.

17. Долятовский, В. А. Управление проектами. Учебное пособие. / В. А. Долятовский, В. Н. Долятовская. - Ростов-на-Дону: ИУБиП,2003.

18. Избачков, Ю.С. Информационные системы. Учебник для вузов / Ю.С. Избачков, В.Н. Петров. 2-е изд. - СПб.: Питер, 2005.

19. Информационные системы в экономике / учебник.- М.: Финансы и статистика, 1996. - 272с.

20. Костров А.В. Основы информационного менеджмента: учебное пособие. - М.: Фи­нансы и статистика, 2001. - 336 с.

21. Колесников С.Н. Инструментарий бизнеса: современные методологии управления предприятием. - М.: Издательско-консультационная компания «Статус-Кво 97», 2001. -336с.

22. Костров А.В. Введение в информационный менеджмент / учебное пособие. - Влади­мир: государственный технический университет, 1996. - 132с.

23. Легард Д. Современная технология выбирает сетевые компьютеры / Computerworld, № 39, 1996.

24. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход: Пер. с англ. - М.: Издательский дом «Вильямс», 2002 - 448 с

25. Липунцов Ю.П. Управление процессами. Методы управления предприятием с исполь­зованием информационных технологий. - М.: ДМК Пресс; М.: Компания АйТи, 2003. - 224с

26. Маклаков, С.В. BPwin и ERwin. CASE - средства разработки информационных систем. Учебник / С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

27. Маклаков, С. В. Создание информационных систем с AllFusion Modeling Suite / С. В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2003.

28. Магрегор, Д. Тестирование программного обеспечения. Практическое пособие / Д. Сайкс. - Киев.: ООО «ТИД «ДС»», 2002.

29. Мацяшек, Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ./ Л. А. Мацяшек. - М.: Издательский дом «Вильямс», 2002.

30. Просиз Дж Программирование для Microsoft .NET /Пер. с англ. -- М.: Издательско-торговый дом «Русская Редакция», 2003. -- 704 стр.: ил.

31. Скрипкин К.Г. Экономическая эффективность информационных систем. - М.: ДМК Пресс, 2002.-256с

32. Смирнова, Г. Н. Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин / Под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2003.

33. Соммервилл, Иан. Инженерия программного обеспечения.: Пер. с англ. / Иан Соммервилл. 6-е изд. - М.: Издательский дом «Вильямс», 2002.

34. Тютюнник А.В., Шевелев А.С. Информационные технологии в банке. - М.: Издатель­ская группа "БДЦ-пресс", 2003. - 368с.

35. Устинова Г.М. Информационные системы менеджмента: Основные аналитические технологии в поддержке принятия решений / учебное пособие. - СПб: Издательство «ДиаСофтЮП», 2000. - 368с

36. Управление проектами в Microsoft Project: Учебный курс (+ CD) / В. В. Богданов. -- СПб.: Питер, 2003. -- 640 с.: ил.

37. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер. - М.: Издательский дом “Вильямс”, 2003.

38. Форта, Бен.Освой самостоятельно SQL. 10 минут на урок, 3-е издание. :Пер. с англ. -- М. : Издательский дом "Вильяме", 2005,- 288 с.

39. Хаммер М., Чампи Д. Реинжениринг корпорации: манифест революции в бизнесе. -- СПб: Издательство Санкт-Петербургского университета, 1999.

40. Хендерсон, К. Профессиональное руководство по SQL Server: хранимые процедуры, XML, HTML (+CD) / К. Хендерсон. - СПб.: Питер, 2005.

41. Ховард М., Лебланк Д. Защищенный код: Пер. с англ, -- 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция», 2004. -- 704 стр.: ил.

42. Шеер, А.В. Бизнес - процессы. Основные понятия. Теория. Методы. Учебное пособие / А.В. Шеер / Под ред. М.С. Каменовой. - М.: Весть - Метатехнология, 1999.

43. Школин, А. Легковесная автоматизация. IT - системы для небольших предприятий //Финанс. - 2005. №15. - С. 56 - 61. (Журнал)

44. Шафер, Дональд. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. - М.: Издательский дом “Вильямс”, 2004. - 1136 с.: ил.

45. Эрик, Дж. Проектирование баз данных с помощью UML. Учебное пособие / Дж. Эрик, А.М. Роберт - СПб.: Издательский дом "Вильямс", 2002.

46. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. - СПб.: Питер, 2002. - 496с.

ПРИЛОЖЕНИЕ А - Техническое задание (ТЗ)

Приложение Б - Логическая модель базы данных

Приложение В - Физическая модель базы данных

Приложение Г - Программный код системы

Рисунок Г.1 - Программный код кнопки «Далее» в форме «Главная»

Рисунок Г.2 - Программный код кнопки «Выход» в форме «Главная»

Рисунок Г.3 - Программный код кнопки «На главную»



Рисунок Г.4 - Программный код кнопки «Регистрация пенсионера»

Рисунок Г.5 - Программный код кнопки «Расчет пенсии»

Рисунок Г.6 - Программный код кнопки «Итоговые начисления»



Рисунок Г.7 - Программный код кнопки «Расчет ИКП»

Рисунок Г.8 - Программный код кнопки «Сформировать отчет»

Рисунок Г.9 - Программный код кнопки «Отправить по почте»

Приложение Д - Схема данных системы

7

Размещено на http://www.allbest.ru/

Рисунок Д.1 Схема данных автоматизированной информационной системы

Приложение Е - программный код SQL-запросов

Рисунок Е.1 - Программный код sql-запроса «Итоговые начисления»

Рисунок Е.2 - Программный код sql-запроса «По месту жительство»

Рисунок Е.3 - Программный код sql-запроса «Расчет ИКП»

Приложение Ж - диаграмма ганта

Размещено на Allbest.ru