Проектирование информационной системы "Eurasia" для ОАО Банк "Бумеранг"
Технико-экономическое обоснование значения разработки или реинжиниринга функциональной подсистемы автоматического выполнения кредитования клиентов банка. Оценка трудоемкости разработки программного обеспечения. Объектно-ориентированная модель системы.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 16.11.2012 |
Размер файла | 1,0 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru
Общие сведения
1.1. Полное наименование системы и ее условное обозначение - Информационная система выдачи кредитов «Eurasia» в банке «Бумеранг».
1.2. Шифр темы или шифр (номер) договора: ИА-1008.
1.3. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты:
Заказчиком системы является банк «Бумеранг»
Адрес заказчика: Вологодская обл., г.Череповец, ул. Коммунистов, 22
Разработчиком системы является Институт менеджмента и информационных технологий.
Адрес разработчика: г. Череповец, ул. Первомайская, д. 48.
1.4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы: Договор №41 на разработку ИС «Eurasia». Утвержден компанией-разработчиком и компанией-заказчиком 19.03.2010.
1.5. Плановые сроки начала, и окончания работы по созданию системы.
Разработка ИС «Eurasia» реализуется в следующие сроки: начало работ - 19.03.2010, окончание работ - 30.04.2010.
1.6. Сведения об источниках и порядке финансирования работ.
Работы по разработке и внедрению информационной системы оплачиваются в соответствие с договором № 41 от «19» марта 2010 г.
1.7. Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
Порядок оформления и предъявления Заказчикам результатов работ по созданию системы должен соответствовать требованиям Комплекса стандартов и руководящих документов на автоматизированные системы: ГОСТ 34.201-89, ГОСТ 34.602-89, ГОСТ 34.601-90.
2. Назначение и цели создания (развития) системы.
2.1. Назначение системы.
Назначением информационной системы является автоматизация решения о выдаче кредита физическому или юридическому лицу.
2.2. Цели создания системы.
2.2.1. Повышение оперативности обработки информации.
2.2.2. Снижение трудоемкости операций анализу платежеспособности клиента.
2.2.3. Уменьшение числа ошибок заполнении документов.
3. Характеристика объектов автоматизации.
3.1. Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию.
Объектом автоматизации является банк «Бумеранг» в частности кредитный отдел.
4. Требования к системе.
4.1. Требования к системе в целом.
4.1.1. Требования к структуре и функционированию системы.
4.1.1.1. Перечень подсистем, их назначение и основные характеристики
В состав ИС должны входить следующие подсистемы:
· Подсистема хранения данных;
· Подсистема управления базами данных;
· Подсистема формирования отчетности.
Подсистема хранения данных предназначена для хранения оперативных данных системы, данных для формирования аналитических отчетов, документов системы, сформированных в процессе работы отчетов и информации.
Подсистема управления предназначена для учета клиентов (ведение полной информации о клиенте, процедуры оценки и т.п.).
Подсистема формирования отчетности предназначена для создания и формирования отчетов в виде удобном для вывода на печатающие устройства на основе данных ИС, проектирования и разработки форм регламентированной отчетности, вывода подготовленных отчетных форм на печать.
4.1.1.2. Требования к способам и средствам связи для информационного обмена между компонентами системы.
Входящие в состав ИС подсистемы в процессе функционирования должны обмениваться информацией, используя для этого входящие в их состав модули информационного взаимодействия. В состав передаваемых данных входят:
· Сведения о операторе;
· Сведения о клиентах;
· Сведения о предоставляемых услугах.
4.1.1.3. Требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
ИС должна взаимодействовать с другими информационными системами.
Возможны следующие варианты обмена:
· Экспорт нормативно-справочной информации;
· Экспорт данных о клиенте;
· Импорт нормативно-справочной информации;
· Импорт данных о клиенте;
4.1.1.4. Требования к режимам функционирования системы.
Для ИС определены следующие режимы функционирования:
· Нормальный режим функционирования;
· Аварийный режим функционирования.
Основным режимом функционирования является нормальный режим.
В нормальном режиме функционирования системы:
· клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня;
· исправно работает оборудование, составляющее комплекс технических средств;
· исправно функционирует системное, базовое и прикладное программное обеспечение системы.
Аварийный режим функционирования системы характеризуется отказом одного или нескольких компонент программного и (или) технического обеспечения.
В случае перехода системы в предаварийный режим необходимо:
· завершить работу всех приложений, с сохранением данных;
· выключить все периферийные устройства;
· выполнить резервное копирование БД.
После этого необходимо выполнить комплекс мероприятий по устранению причины перехода системы в аварийный режим.
4.1.1.5. Требования по диагностированию системы.
Требования не предъявляются.
4.1.1.6. Перспективы развития, модернизации системы.
ИС должна реализовывать возможность дальнейшей модернизации как программного обеспечения, так комплекса технических средств. Также необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования.
4.1.2. Требования к численности и квалификации персонала системы и режиму его работы.
4.1.2.1. Требования к численности персонала (пользователей) АС.
Численность персонала АИС должна определяться исходя из потребностей бизнес-процессов предприятия. Численность пользователей системы определяется параметрами объекта автоматизации.
Рекомендуемая численность для эксплуатации ИС:
· Администратор - 1 штатная единица;
· Пользователь - число штатных единиц определяется структурой предприятия.
4.1.2.2. Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков.
Пользователи системы должны иметь опыт работы с персональным компьютером на базе операционных систем Microsoft Windows на уровне квалифицированного пользователя и свободно осуществлять базовые операции в стандартных программах Windows.
Специальная подготовка должна включать в себя получение навыков работы с данной системой в объеме навыков пользователей.
4.1.2.3. Требуемый режим работы персонала АС.
Персонал (пользователи) системы выполняют свои функции в режиме 8-часовой работы.
4.1.3. Показатели назначения.
Системы должна обеспечивать настройку и адаптироваться к изменению параметров и методов управления без проведения перепрограммирования на уровне общего программного обеспечения. Адаптация системы должна осуществляться путем проведения структурной и параметрической настройки соответствующих функциональных подсистем.
4.1.3.1. Степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления.
Система должна предусматривать возможность масштабирования путем модернизации используемого комплекса технических средств.
4.1.3.2. Допустимые пределы модернизации и развития системы.
Система должна обеспечивать возможность модернизации и развития при увеличении параметров объекта автоматизации, и при необходимости изменения состава требований к выполняемым функциям и видам обеспечения.
4.1.3.3. Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.
Минимальный срок эксплуатации:
· системы в целом - не менее 10 лет;
· модулей функциональных подсистем - не менее 5 лет;
· комплекса технических средств - не менее 15 лет (при проведении соответствующей технической модернизации и развития).
4.1.4. Требования к надежности.
4.1.4.1. Состав и количественные значения показателей надежности для системы в целом или ее подсистем.
Проектные решения должны обеспечивать:
· сохранение работоспособности системы при отказе или выходе из строя одного из компонентов комплекса технических средств или телекоммуникационной подсистемы;
· сохранение всей накопленной на момент отказа или выхода из строя информации.
Должны быть обеспечены два уровня надежности системы:
· уровень сохранности работоспособности;
· уровень сохранности информации.
Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок персонала (пользователей).
4.1.4.2. Перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей.
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
· при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла системы;
· при ошибках в работе аппаратных средств;
· при ошибках, связанных с программным обеспечением.
4.1.4.3. Требования к надежности технических средств и программного обеспечения.
Надежность рабочих мест должна быть обеспечена централизованным хранением данных и резервным копированием данных. Выход из строя рабочего места пользователя не должен влиять на работоспособность системы в целом.
4.1.4.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.
Оценка надежности осуществляется на стадии проектирования за счет анализа полноты архитектуры и технических решений по построению системы и их соответствия техническим требованиям данного ТЗ.
4.1.5. Требования безопасности.
Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление.
Система электропитания должна обеспечивать защитное отключение при перегрузках и коротких замыканиях в цепях нагрузки, а также аварийное ручное отключение.
Общие требования пожарной безопасности должны соответствовать нормам на бытовое электрооборудование.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм.
4.1.6. Требования к эргономике и технической эстетике.
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь».
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние.
Система должна соответствовать требованиям эргономики при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности.
4.1.7. Требования к транспортабельности для подвижных АС.
Требования не предъявляются.
4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.
4.1.8.1. Условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания.
Использование технических средств системы должно производиться с выполнением требований производителей оборудования, выполнением периодического обслуживания и регламентных работ.
4.1.8.2. Предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.
Размещение помещений и их оборудование должны исключать возможность бесконтрольного проникновения в них посторонних лиц и обеспечивать сохранность находящихся в этих помещениях конфиденциальных документов и технических средств.
Размещение оборудования, технических средств должно соответствовать требованиям техники безопасности, санитарным нормам и требованиям пожарной безопасности.
Все пользователи системы должны соблюдать правила эксплуатации электронной вычислительной техники.
4.1.8.3. Требования по количеству, квалификации обслуживающего персонала и режимам его работы.
Количество и квалификационный состав обслуживающего персонала определяется в зависимости от типа технических средств в соответствии с требованиями завода-изготовителя и действующими нормативными документами.
4.1.8.4. Требования к составу размещению и условиям хранения комплекта запасных изделий и приборов.
Требования не предъявляются.
4.1.8.5. Требования к регламенту обслуживания.
Обслуживание технических средств АИС осуществляется в соответствии с действующими технологическими процессами в организации с периодичностью, установленной заводами-изготовителями технических средств и согласовывается с фирмами, осуществляющими ремонт и профилактическое обслуживание системы.
4.1.9. Требования к защите информации от несанкционированного доступа.
ИС должна обеспечивать защиту от несанкционированного доступа (НСД). Компоненты подсистемы защиты от НСД должны обеспечивать:
· идентификацию пользователя;
· проверку полномочий пользователя при работе с системой;
· разграничение доступа пользователей на уровне задач и информационных массивов.
4.1.10. Требования по сохранности информации при авариях требования к защите от влияния внешних воздействии.
Программное обеспечение ИС должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации резервного копирования данных системы средствами программного обеспечения (ОС, СУБД).
4.1.11. Требования к средствам защиты от внешних воздействий.
Требования не предъявляются.
4.1.12. Требования к патентной чистоте.
Проектные решения разрабатываемой АСУ не содержат сведения, которые могут быть признаны изобретениями или открытиями.
4.1.13. Требования по стандартизации и унификации.
В ИС должны использоваться стандартные учетные и отчетные документы, международные и всесоюзные классификаторы технико-экономической информации. В АИС предусмотрено применение стандартных пакетов прикладных программ с целью снижения трудоемкости разработки и сопровождения системы и повышения надежности функционирования.
В качестве ППП предполагается использовать:
· стандартные ППП для организации СУБД;
· стандартные ППП для подготовки документации, типа Microsoft Excel, Microsoft Word.
4.1.14. Дополнительные требования.
ИС должна иметь в своем составе комплекс программных и технических средств для организации и проведения обучения (тренинга) персонала (пользователей) и обслуживающего персонала. Комплекс программных и технических средств обучения (тренинга) должен иметь необходимый комплект документации:
· методические материалы;
· учебные материалы.
4.2. Требования к функциям (задачам), выполняемым системой.
Система «Eurasia» предназначена для выполнения следующих функций:
· сохранение и передача информации о клиентах (личные данные, доход и т. д);
· выдача решения по предоставлению кредита;
· расчет кредитных платежей.
4.3. Требования к видам обеспечения.
4.3.1. Требования к математическому обеспечению системы.
В качестве математического обеспечения используются стандартные алгоритмы, методики и модели.
Математические методы и алгоритмы, используемые для шифрования/дешифрования данных, а также программное обеспечение, реализующее их, должны быть сертифицированы уполномоченными организациями для использования в государственных органах Российской Федерации.
4.3.2. Требования к информационному обеспечению системы.
4.3.2.1. Требования к составу, структуре и способам организации данных в системе.
Информационная ИС должна включать следующие основные составляющие:
· база данных клиентов содержит сведения о всех клиентах банка.
· база данных услуг содержит перечисление всех видов услуг, с указанием стоимости каждой из них.
· база данных записей клиентов содержит всю информацию обо всех выданных кредитах и их уплате.
4.3.2.2. Требования к информационному обмену между компонентами системы.
ИС должна обеспечивать однократный ввод данных, вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими функциональными подсистемами использоваться.
Обмен информацией между базами данных должен осуществляться с использованием операций импорта-экспорта, стандартных для выбранного прикладного программного обеспечения.
4.3.2.3. Требования по применению систем управления базами данных.
Для хранения всех информационных массивов ИС должна использоваться единая система управления базами данных (СУБД).
Общие требования к используемой СУБД:
· использование русского языка;
· поддержка реляционной или объектно-реляционной модели базы данных;
· автоматическое восстановление базы данных;
· наличие механизма блокировки транзакций;
· реализация SQL, совместимого со стандартом ANSI 1992 г.;
· наличие встроенных средств контроля целостности баз данных;
· наличие встроенных средств резервного копирования базы данных;
· импорт и экспорт данных.
4.3.2.4. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы.
Сохранность информации в ИС должна обеспечиваться при всех аварийных ситуациях. В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление базы данных до состояния на момент последней завершенной системой транзакции.
4.3.3. Требования к лингвистическому обеспечению.
Все прикладное программное обеспечение системы для организации взаимодействия с пользователем должно использовать русский язык.
Система не предусматривает специальных языковых средств. Диалоговый режим работы должен обеспечить ввод и обработку информации в естественном для персонала виде за исключением администратора системы.
4.3.3.1. Требования к применению языков высокого уровня.
Используемые при разработке языки высокого уровня должны обеспечивать решение всех задач по реализации функций системы. Допускается использование стандартных языков высокого уровня, отвечающих требованиям реализации задач предметной области.
4.3.3.2. Требования к применению языков подготовке отчетов.
В составе системы должен быть язык подготовки отчетов, позволяющий производить модификацию существующих и создание новых отчетов. Язык подготовки отчетов должен иметь встроенные средства создания графических представлений (диаграммы, графики и т.п.), а также обеспечивать экспорт результатов в форматы широкого применения (текстовый, XLS, DOC и т.п.).
4.3.3.3. Требования к способам организации диалога с пользователем.
Способ организации диалога с пользователем должен обеспечивать:
· уменьшение вероятности совершения оператором случайных ошибочных действий;
· предусматривать логический контроль ввода данных;
· возможность индивидуальной настройки пользователем с сохранением настроек.
4.3.3.4. Требования к средствам описания предметной области (объекта автоматизации).
В составе комплексов разработки должны быть средства описания предметной области и объекта автоматизации.
4.3.3.5. Требования к языкам манипулирования данных.
Языки манипулирования данных должны отвечать требованиям стандарта ANSI 1992 (реализация SQL) и поддерживать реляционную и объектно-реляционную модели баз данных, а так же стандарт ODBC.
4.3.3.6. Требования к кодированию и декодированию данных
Дополнительных требований к кодированию и декодированию данных не предъявляется.
4.3.4. Требования к программному обеспечению.
Программное обеспечение должно быть выполнено на языках высокого уровня и обеспечивать функционирование системы в режиме реального времени.
Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. Базовой программной платформой должна являться операционная система Windows.
Прикладное программное обеспечение ИС должно обладать следующими свойствами:
· допускается дополнительное программирование экранных форм и отчетов, а также создание дополнительных модулей программного продукта.
· русификация и наличие эксплуатационной документации на русском языке.
4.3.5. Требования к техническому обеспечению.
Техническое обеспечение системы должно максимально и наиболее эффективным образом использовать существующие технические средства.
В состав комплекса должны следующие технические средства:
· ПК пользователей и администраторов.
· печатные устройства.
4.3.6. Требования к метрологическому обеспечению.
Отсутствие ошибки округления при расчетах денежных единиц с округлением до единиц копеек. Отсутствие ошибок округления и отсутствие накопление ошибок расчетов при пересчетах по процентному содержанию.
4.3.7. Требования к организационному обеспечению.
4.3.7.1. Требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию.
Эксплуатацию и функционирование системы обеспечивает администратор.
4.3.7.2. Требования к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.
Функционирование системы организуется в рамках выполнения рабочих функций сотрудниками банка. Сотрудники являются пользователями ИС и выполняют свои непосредственные функции с использованием ресурсов системы.
При вводе системы в эксплуатацию необходимо провести обучение персонала работе с данной системой.
4.3.7.3. Требования к защите от ошибочных действий персонала системы.
Система должна обеспечивать защиту от ошибочных действий персонала и исключать возможность нарушения функционирования от неправильных действий персонала, обеспечивая стопроцентное сохранение данных системы при любых действиях персонала и одиночных отказах программно-технических средств.
4.3.8. Требования к методическому обеспечению.
Должны быть разработаны и внедрены методики и инструкции выполнения операций на автоматизированных рабочих местах ИС.
5. Состав и содержание работ по созданию системы.
№ этапа |
Название |
Срок |
Отчетность |
|
1 |
Оценка эффективности |
31.03.2010 - 01.04.2010 |
||
2 |
Разработка функциональной модели подсистемы |
02.04.2010 - 08.04.2010 |
Функциональная модель бизнес-процесса в виде SADT-диаграммы |
|
3 |
Разработка информационного обеспечения подсистемы (информационно-логической модели предметной области) |
09.04.2010 -15.04.2010 |
Информационно-логический граф (логическая модель в среде ER-WIN, физическая модель в среде ER-WIN), описания объектов |
|
4 |
Разработка концептуальной модели БД |
16.04.2010 -21.04.2010 |
Концептуальная схема БД, алгоритмы контроля целостности и согласованности БД, алгоритмы для работы с БД |
|
5 |
Проектирование интерфейса пользователя |
22.04.2010 -26.04.2010 |
Граф диалога, разработанные формы ввода-вывода информации |
|
6 |
Логическое проектирование |
27.04.2010 -03.05.2010 |
Спроектированная программа обработки данных, схема алгоритма решения задачи (схема работы подсистемы), сформированные запросы к БД на языке SQL |
|
7 |
Тестирование ИС и разработка программной документации |
04.05.2010 - 08.05.2010 |
Тесты, документация, программный продукт |
6. Порядок контроля и приемки системы.
Курсовую работу необходимо предоставить преподавателю за несколько дней до защиты. Дата защиты курсовой работы устанавливается методическим отделом.
В процессе контроля проводят испытания на тестовых данных (реальных и/или заведомо ложных), проверяя универсальность и надежность программного продукта.
В ходе приемки курсовой работы необходимо обратить внимание на ее соответствие техническому заданию, в частности - заявленным функциям, а также просмотреть содержимое пояснительной записки, оценить ее достоверность.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
1. Изменения, которые необходимо осуществить в объекте автоматизации. Дополнительных изменений в объекте автоматизации не требуется.
2. Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ. Требований не предъявляется.
При выполнении работ по созданию системы необходимо наличие аппаратно-программных средств, предусмотренных проектными решениями для установки соответствующих прикладных программ и ввода подсистем в эксплуатацию.
Необходимо, в соответствии с проектными решениями, провести обучение обслуживающего персонала.
8. Требования к документированию
Документация, разрабатываемая в соответствии с требованиями настоящего технического задания, должна соответствовать требованиям ГОСТ 34.201-89.
Полный перечень документации включает:
1) Техническое задание.
2) Пояснительная записка.
Вся разрабатываемая проектная документация должна быть выполнена на русском языке.
9. Источники разработки. ГОСТ 34.201-89;
1) ГОСТ 34.602-89;
2) ГОСТ 34.601-90;
3) ГОСТ РД 50-34.698-90;
4) ГОСТ ISO/IEC 12207.
(код ТЗ)
СОСТАВИЛИ
Наименование организации, предприятия |
Должность исполнителя |
Фамилия, имя, отчество |
Подпись |
Дата |
|
ИМИТ (филиал) СПбГПУ |
студент |
И.А.Ильин |
23.04.2010 |
СОГЛАСОВАНО
Наименование организации, предприятия |
Должность |
Фамилия, имя, отчество |
Подпись |
Дата |
|
ИМИТ (филиал) СПбГПУ |
Доцент кафедры ПО, канд. тех.наук |
Н. А. Щегряев |
23.04.2010 |
1. Общесистемная часть
1.1 Общая характеристика экономического объекта
Комсоцбанк "Бумеранг" образован на базе Череповецкого отделения Жилсоцбанка СССР решением собрания учредителей-пайщиков (протокол №1 от 05.10.1990 года). Зарегистрирован в ЦБ РФ 28 ноября 1990 года под номером 1002. Изменение организационно-правовой формы банка произошло: 9 июня 1994 года Комсоцбанк "Бумеранг" переименован в ТОО Комсоцбанк "Бумеранг", 8 мая 1997 года ТОО Комсоцбанк "Бумеранг" переименован в ООО Комсоцбанк "Бумеранг", 11 марта 1999 года ООО Комсоцбанк "Бумеранг" переименован в ОАО Комсоцбанк "Бумеранг".
Преобладающие виды деятельности:
Привлечение и размещение денежных средств юридических и физических лиц во вклады, депозиты, ведение ссудных счетов юридических и физических лиц, осуществление расчетов по поручению юридических и физических лиц по их банковским счетам, купля-продажа иностранной валюты в наличной и безналичной формах, инкассация, обслуживание кредита, расчетно-кассовое обслуживание физических и юридических лиц.
На данный момент число филиалов достигает четырёх вместе с центральным офисом.
Основные документы, определяющие функционирование ОАО Комсоцбанк "Бумеранг" в целом:
1. устав Коммерческого банка социального развития “Бумеранг”
2. миссия Коммерческого банка социального развития “Бумеранг”
3. Лицензия на осуществление банковских операций № 1002 от 11.02.2004г.
Организационная структура банка «Бумеранг» представлена на рисунке 1.
Рисунок 1 - Организационная структура банка «Бумеранг»
1. Можно выделить следующие основные направления деятельности:
1.1. Банк в праве осуществлять следующие банковские операции со средствами в рублях и иностранной валюте:
1.1.1. привлечение денежных средств физических и юридических лиц во вклады (до востребования и на определенный срок);
1.1.2. размещение привлеченных во вклады (до востребования и на определенный срок) денежных средств юридических и физических лиц от своего имени и за свой счет;
1.1.3. открытие и ведение банковских счетов физических и юридических лиц;
1.1.4. осуществление расчетов по поручению физических и юридических лиц, в том числе банков-корреспондентов, по их банковским счетам;
1.1.5. инкассация денежных средств, векселей, платежных и расчетных документов и кассовое обслуживание физических и юридических лиц;
1.1.6. купля-продажа иностранной валюты в наличной и безналичной формах;
1.1.7. привлечение во вклады и размещение драгоценных металлов (при наличии соответствующей лицензии Банка России);
1.1.8. выдача банковских гарантий;
1.1.9.осуществление переводов денежных средств по поручениям физических лиц без открытия банковских счетов (за исключением почтовых переводов).
1.2. Банк помимо перечисленных выше банковских операций вправе осуществлять следующие сделки:
1.2.1. выдачу поручительств за третьих лиц, предусматривающих исполнение обязательств в денежной форме;
1.2.2. приобретение права требования от третьих лиц исполнения обязательств в денежной форме;
1.2.3. доверительное управление денежными средствами и иным имуществом по договору с физическими и юридическими лицами;
1.2.4. осуществление операций с драгоценными металлами и драгоценными камнями в соответствии с законодательством Российской Федерации;
1.2.5. предоставление в аренду физическим и юридическим лицам специальных помещений или находящиеся в них сейфов для хранения документов и ценностей;
1.2.6. лизинговые операции;
1.2.7. оказание консультационных и информационных услуг.
В соответствии с основными направлениями деятельности можно выделить основные бизнес-процессы:
1. Обслуживание физических лиц.
2. Обслуживание юридических лиц.
3. Работа на финансовых и межбанковских рынках.
4. Административно-хозяйственное обеспечение.
5. Обеспечение безопасности.
6. Юридическое обеспечение.
7. ИТ-обеспечение и связь.
8. Внутренний контроль.
9. Бухгалтерский учет и отчетность.
10. Стратегическое управление.
11. Управление маркетингом.
12. Управление рисками.
13. Управление персоналом.
14. Управление бизнес-процессами и развитием.
15. Региональное управление.
16. Другие
Основные бизнес-процесс представлены на рисунке 2.
Рисунок 2 - Бизнес-процессы банка «Бумеранг»
1.2 Выделение функциональной подсистемы АЭИС
Для исследования был взят отдел кредитования банка «Бумеранг».
Банковский кредит -- денежная ссуда, выдаваемая банком на определённый срок на условиях возвратности и оплаты кредитного процента.
В соответствии с этим, отдел кредитования выполняет следующие функции:
1. Сбор и обработка финансовой информации о клиентах и перспективных заемщиках.
2. Анализ финансовой отчетности претендентов на получение ссуды.
3. Подготовка отчетов об утверждении кредитов и другой информации, необходимой для принятия решений о предоставлении кредитов.
4. Ведение картотеки кредитной информации (ККИ).
5. Подготовка ответов на запросы за кредитами из других банков и другие небанковские законные запросы.
6. Подготовка, регистрация и проверка основной документации, которая касается кредитных операций банка.
7. Хранение кредитных дел, включая оригиналы договоров, документов на залог, гарантийных обязательств, сообщений и т.п.
8. Поддержание юридических прав банка на залог регистрацией требований к заемщику и передачам права собственности банка.
9. Выставление клиентам счетов за процентными платежами за кредитами, комиссионным и другим собранием.
10. Подготовка документации, которая предупреждает об истечении срока кредитного соглашения.
Поступающая в отдел информация обрабатывается вручную сотрудниками данного отдела, каждый из которых имеет различные обязанности.
Информационные потоки отдела представлены на рисунке 3.
В качестве направления исследования был выбран бизнес-процесс выдачи кредитов. Данный бизнес-процесс является одним из основополагающих в деятельности всего отдела кредитования, так как на основании данных, полученных в результате анализа информации, представленной клиентом, происходит решение о выдаче или невыдаче, и, в случае выдачи, расчет и оформление кредита.
Рисунок 3 - Бизнес-процесс: выдача кредита.
Также можно представить функциональную модель бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов - стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте. Данная модель представлена на рисунке 4-5 (для большей точности была проведена двухуровневая детализация).
Рисунок 4 - Функциональную модель бизнес-процессов (1 уровень)
Рисунок 5 - Функциональную модель бизнес-процессов (2 уровень)
Кроме функциональной модели бизнес-процессов была построена диаграмма описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Данная диаграмма представлена на рисунках 6-7 (для большей точности была проведена двухуровневая детализация).
Рисунок 6 - Диаграмма описания потоков данных (1 уровень)
Рисунок 7 - Диаграмма описания потоков данных (2 уровень)
1.3 Технико-экономическое обоснование необходимости разработки или реинжиниринга функциональной подсистемы АЭИС
Рассматриваемый отдел в сфере функционирования имеет как положительные, так и отрицательные стороны.
Недостатки отдела:
1. Высокие риски утраты договоров и прочих документов.
2. Обработка большого объема информации вручную. Сотрудники расходуют слишком много времени на обработку информации.
Достоинства отдела:
1. Руководство банка благоволит автоматизации предприятия.
2. Сотрудники легко обучаемы.
На основе выявленных недостатков можно сформулировать следующие проблемы, которые возможно решить средствами автоматизации:
1. Ручная обработка большого количества информации.
Сотрудниками данного отдела выполняется ручная обработка документов клиента и банка.
2. Потенциальный риск утраты документов или их неправильное заполнение.
Документы будут храниться в электронных архивах в нескольких копиях.
Сотрудники данного отдела при заполнении могут совершать ошибки. Применение методов автоматизации поможет снизить их количество (или даже полностью их устранить).
В целом, можно сказать, что данный отдел выполняет свои функции в полном объеме и с приемлемым качеством, но естественно в его деятельности существуют и слабые стороны.
Можно выделить следующие необходимые ресурсы для реализации выбранной системы:
1. финансовые;
2. трудовые;
3. материальные.
Для разработки системы необходимы денежные средства. Они могут быть выделены из бюджета.
Трудовые ресурсы - это непосредственно разработчики данного программного продукта. Он может быть разработан как сотрудниками банка, обладающими такими знаниями и навыками, так и аутсорсинговой фирмой (что будет дороже).
Материальные ресурсы необходимы для разработки данной системы, так как без них эту разработку будет осуществить невозможно, это, например, рабочее место, включающее в себя рабочий стол, компьютер и прочее.
2. Проектная часть
2.1 Постановка задачи на разработку функциональной системы
2.1.1 Организационно-экономическая сущность задачи
Задача функциональной системы «Eurasia» заключается в передаче и хранении занесенных данных о клиентах и предоставлении сотрудникам банка информации о выданных кредитах.
Целями данной функциональной подсистемы является:
1. снижение трудоемкости выполняемых операций сотрудниками отдела;
2. повышение качества обработки информации.
Выдача кредитов осуществляется ежедневно в течение n-го месяца, а также рассчитывается итоговые значения на конец каждого месяца. Поэтому обращение к данной функциональной подсистеме будет осуществляться ежедневно.
2.1.2 Описание исходной (входной) информации
Как уже было сказано в п. 2.1.1, информация поступает в виде анкет клиентов. Они содержат сведения о клиенте.
Анкеты представлены в печатном виде, но заполняются сотрудником вручную, что, соответственно трудоёмко и непрактично. Так же эта информация проверяется в отделе безопасности.
2.1.3 Описание результатной (исходной) информации
Вся поступающая в отдел информация обрабатывается сотрудниками кредитного центра и на ее основе составляются итоговые анкеты, которые содержат информацию о клиенте, контактную информацию, сумме кредита, сроках кредита, процентной ставки кредита, реквизиты и прочее.
2.1.4 Описание алгоритма решения задачи
Основной задачей в системе «Eurasia» является расчет выплат по кредиту, в зависимости от сроков, размера кредита и процентной ставки. Процентная ставка -- это сумма, указанная в процентном выражении к сумме кредита, которую платит получатель кредита за пользование им в расчете на определенный период (месяц, квартал, год):
При многократном начислении простых процентов начисление делается по отношению к исходной сумме и представляет собой каждый раз одну и ту же величину. Иначе говоря.
,
где
P -- исходная сумма
S -- наращенная сумма (исходная сумма вместе с начисленными процентами)
I -- процентная ставка, выраженная в долях за период
N -- число периодов начисления
В этом случае говорят о простой процентной ставке.
При многократном начислении сложных процентов начисление каждый раз делается по отношению к сумме с уже начисленными ранее процентами. Иначе говоря,
S = ((1 + i)^n)P
В этом случае говорят о сложной процентной ставке.
Часто рассматривается следующая ситуация. Годовая процентная ставка составляет j, а проценты начисляются m раз в году по сложной процентной ставке равной j / m (например, поквартально, тогда m= 4 или ежемесячно, тогда m = 12). Тогда формула для наращенной суммы через k лет:
В этом случае говорят о номинальной процентной ставке.
Сравнение сложных процентных ставок с разными интервалами начисления производят при помощи показателя годовая процентная доходность(APY).
2.2 Разработка программного обеспечения подсистемы
2.2.1 Выбор языка разработки и технологии проектирования ЭИС
Разработка данного проекта велась в среде программирования Delphi. Delphi - это среда разработки, в которой в качестве языка программирования используется объектно-ориентированный язык программирования Delphi. Язык Delphi - это язык, в основе которого лежит Object Pascal.
Данный язык отвечает всем современным требованиям, применяемым к языкам программирования высокого уровня.
В качестве технологии проектирования было выбрано индустриальное автоматизированное проектирование, которое разбивается на два подкласса: автоматизированное (использование CASE-технологии) и типовое (параметрически-ориентированное или модельно-ориентированное). Из данных подклассов был выбран второй, то есть типовое проектирование.
Выбор может быть обоснован тем, что данный тип проектирования (типовой) является наиболее уместным в данной предметной области, и проект, разработанный на его основе, обладает большей адаптивностью, чем тот, которой был бы разработан с применением другой технологии.
2.2.2 Объектно-ориентированная модель системы «Eurasia»
Для построения объектно-ориентированной модели было использовано средство проектирования Rational Rose, которое является мощным инструментом анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, что позволяет с самого начала быть уверенным в адекватности их архитектуры. [4]
На первом этапе была построена диаграмма вариантов использования, которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций. [4]
На данной диаграмме представлено три действующих лица: Клиент, Кредитор и Кредитный центр (см. рис. 8).
Рисунок 8 - Диаграмма вариантов использования
Далее была построена диаграмма классов (class diagram). Она служит для отображения структуры совокупности взаимосвязанных классов объектов. На ней представлено 4 класса: Клиент, Кредитор и Кредитный центр и анкета. [4]
Атрибуты каждого класса отображаются под названием класса с определенным типом значений. Кроме этого, на диаграмме классов показаны отношения ассоциации и зависимости (см. рис.9).
Рисунок 9 - Диаграмма классов
После диаграммы классов были разработаны диаграммы взаимодействия: последовательности и кооперации. Диаграммы взаимодействия объектов (Interaction diagram) отображают динамическое взаимодействие объектов в рамках одного прецедента использования. Диаграммы последовательности организованы по времени, на кооперативных диаграммах отображается та же информация, но акцентируется внимание на статическом взаимодействии объектов (см. рис. 10-11). [4]
Рисунок 10 - Диаграмма последовательности
На основе диаграмма последовательности была построена диаграмма кооперации (см. рис. 11).
Рисунок 11 - Диаграмма кооперации
После диаграммы кооперации была разработана диаграмма состояний, которая описывает процесс изменения состояний только одного класса, а точнее -- одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне (см. рис. 12). [4]
Рисунок 12 - Диаграмма состояний
Далее была построена диаграмма деятельности, в которой каждое состояние соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами -- переходы от одного состояния действия к другому (см. рис 13). [4]
Рисунок 13 - Диаграмма деятельности
Затем была построена диаграмма компонентов, которая входит в состав диаграмм реализации (implementation diagrams). Диаграмма компонентов описывает особенности физического представления системы и позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код (см. рис. 14). [4]
Рисунок 14 - Диаграмма компонентов
Таким образом, диаграмма компонентов (Component diagram) отображает физические модули программного кода. [4]
Диаграмма размещения (Deployment diagram) отображает распределение объектов по узлам вычислительной сети. Диаграмма размещения содержит графические изображения процессоров, устройств, процессов и связей между ними. [4]
Рисунок 15 - Диаграмма компонентов
Данная диаграмма включает один процессор - любая машина, имеющая вычислительную мощность, в данном случае это ПК, а также одно устройство (принтер) - аппаратура, не имеющая вычислительной мощности. [4]
2.2.3 Оценка трудоемкости разработки программного обеспечения на основе диаграммы вариантов использования
2.2.3.1 Определение весовых показателей действующих лиц
Таблица 2 - Весовые показатели действующих лиц
Действующее лицо |
Тип |
|
Клиент |
Простое |
|
Кредитный центр |
Среднее |
|
Кредитор |
Сложное |
Таким образом, общий весовой показатель составляет: .
2.2.3.2 Определение весовых показателей вариантов использования
Таблица 3 - Весовые показатели вариантов использования
Вариант использования |
Тип |
|
Обработка анкет |
Средний |
|
Выдача ответов |
Средний |
|
Заключение договора |
Средний |
|
Заполнение анкет |
Простой |
|
Хранение в БД |
Простой |
|
Расчет кредита |
Средний |
Таким образом, общий весовой показатель вариантов использования составляет:
;
В результате показатель UCCP имеет значение:
.
2.2.3.3 Определение технической сложности проекта
Таблица 4 - Техническая сложность проекта
Показатель |
Описание |
Вес |
Значение |
Значение с учетом веса |
|
Т1 |
Распределенная система |
2 |
1 |
2 |
|
Т2 |
Высокая производительность (пропускная способность) |
1 |
2 |
2 |
|
Т3 |
Работа конечных пользователей в режиме он-лайн |
1 |
3 |
3 |
|
Т4 |
Сложная обработка данных |
1 |
1 |
1 |
|
Т5 |
Повторное использование кода |
1 |
0 |
1 |
|
Т6 |
Простота установки |
0,5 |
5 |
2,5 |
|
Т7 |
Простота использования |
0,5 |
5 |
2,5 |
|
Т8 |
Переносимость |
2 |
5 |
10 |
|
Т9 |
Простота внесения изменений |
1 |
4 |
4 |
|
Т10 |
Параллелизм |
1 |
0 |
1 |
|
Т11 |
Специальные требования к безопасности |
1 |
5 |
5 |
|
Т12 |
Непосредственный доступ к системе со стороны внешних пользователей |
1 |
0 |
0 |
|
Т13 |
Специальные требования к обучению пользователей |
1 |
2 |
2 |
|
? |
- |
- |
- |
36 |
Показатель TCF составляет:
.
2.2.3.4 Определение уровня квалификации разработчиков
Таблица 5 - Уровень квалификации разработчиков
Показатель |
Описание |
Вес |
Значение |
Значение с учетом веса |
|
F1 |
Знакомство с технологией |
1,5 |
5 |
7,5 |
|
F2 |
Опыт разработки приложений |
0,5 |
3 |
1,5 |
|
F3 |
Опыт использования ООП |
1 |
4 |
4 |
|
F4 |
Наличие ведущего аналитика |
0,5 |
1 |
0,5 |
|
F5 |
Мотивация |
1 |
3 |
3 |
|
F6 |
Стабильность требований |
2 |
3 |
6 |
|
F7 |
Частичная занятость |
-1 |
4 |
-4 |
|
F8 |
Сложные языки программирования |
-1 |
2 |
-2 |
|
? |
- |
- |
- |
16,5 |
Значение показателя EF для системы «Eurasia»:
;
В результате показатель UCP составляет:
.
2.2.3.5 Определение трудоемкости проекта
Первоначально необходимо определить количество человеко-часов на одну UCP: один из показателей F1-F6 имеет значение меньше трех и один показатель F7-F8 имеет значение больше трех. Поскольку общее значение равно двум: , то следует использовать 20 человеко-часов на одну UCP.
Для системы «Eurasia» общее количество человеко-часов равно , что составляет 24 недели при 40-часовой рабочей неделе.
Команда разработчиков состоит из 5 специалистов банка «Бумеранг», при этом необходимо учесть 1 неделю на различные непредвиденные ситуации, тогда в итоге получается недель на весь проект.
2.2.4 Инструкция по работе
Работа с системой «Eurasia» начинается с главного окна, которое имеет главное меню, содержащее пункты «Клиенты», «Отчеты» и другие. (см. рис. 16). [1]
Рисунок 16 - Главное окно подсистемы «Eurasia»
При выборе пункта меню «Клиенты» откроется список подменю для этого пункта, он содержит следующие команды: «Физические лица», «Юридические», «Предприниматели». Пункт меню «Отчеты» включает в себя подпункты «Договор» и «График платежей» (см. рис.17-18). [1]
Так же возможен вызов калькулятора для подсчета (см. рис.19)
Рисунок 17 - Выбор пункта меню «Клиенты»
Рисунок 18 - Выбор пункта меню «Печать»
Рисунок 19 - Выбор пункта меню «Сервис»
Рисунок 20 - Карточка
На данной форме располагаются пустые поля, которые предназначены для ввода данных о клиенте.[3]
При выборе подпункта «Договор» на форме откроется новая вкладка, которая отражает договоры с клиентами. Так же можно посмотреть оплату, просрочки и другое (см. рис. 21-22). [2]
Рисунок 21 - Договор
Рисунок 22 - Оплата
Для завершения работы с системой «Eurasia» необходимо нажать на «Выход» в правом верхнем углу меню на главной формы. [5]
кредитование банк программный обеспечение
Заключение
Спроектированная система «Eurasia» дает возможность непосредственному пользователю автоматически выполнять кредитование клиентов банка, при этом сэкономить время на обработке и повысить качество работы.
В процессе работы была разработаны: техническое задание, функциональная модель существующего бизнес-процесса, технико-экономическое обоснование разработки данного проекта и объектно-ориентированная модель системы «Eurasia».
Техническое задание было разработано в соответствии с ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
Функциональная модель существующего бизнес-процесса представлена в стандарте SADT, а объектно-ориентированная модель системы «Eurasia» представляет схемы алгоритмов на языке UML.
В процессе проектирование интерфейса пользователя был выбран вид интерфейса и разработаны формы ввода - вывода информации.
Результаты проделанной работы удовлетворяют требованиям технического задания.
Список использованных источников и литературы
1. Архангельский, А.Я. Программирование в Delphi 6/А.Я Архангельский. - М.: ЗАО «Издательство БИНОМ», 2001 г. - 1120 с.
2. Бобровский С.И. Delphi 7. Учебный курс/ С.И. Бобровский. - СПб: Питер, 2008. - 736 с.
3. Дунаев В.В. Базы данных. Язык SQL. / В.В. Дунаев. - СПб: БХВ-Петербург, 2006. - 288 с.
4. Смирнова Г.Н. Проектирование экономических информационных систем: Учебник/Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2003. - 512 с.
5. Фаронов В.В. Delphi. Программирование на языке высокого уровня./ В.В. Фаронов. - СПб: Питер, 2008.-640 с.
6. Фленов М.Е. Библия Delphi. / М.Е. Фленов -- СПб: БХВ - Петербург, 2004. -- 880 с.
Размещено на Allbest.ru
Подобные документы
Методика разработки объектно-ориентированной модели информационной подсистемы необходимой для учета успеваемости студентов факультета, которая спроектирована с помощью программного продукта Rational Rose 2003 и унифицированного языка моделирования UML.
курсовая работа [183,9 K], добавлен 25.06.2011Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Оценка организационной структуры и процесс реализации информационной подсистемы отдела менеджмента предприятия. Требования к информационной подсистеме и техническому обеспечению. Технико-экономическое обоснование разработки информационной подсистемы.
дипломная работа [2,1 M], добавлен 29.06.2011Технико-экономическое обоснование разработки информационной системы "План-меню". Выбор технических средств и стандартного программного обеспечения. Проектирование структуры базы данных. Разработка и структура пользовательского интерфейса и ER-модели.
курсовая работа [817,6 K], добавлен 07.05.2009Технико-экономические показатели разработки. Функциональные модели информационной системы и ее объектно-ориентированное проектирование. Анализ вариантов использования. Тестирование программного продукта, а также исследование технической документации.
курсовая работа [175,2 K], добавлен 14.09.2015Анализ функциональной структуры автоматизированной системы управления. Обоснование необходимости создания подсистемы учета материальных средств, проектирование информационной базы данных. Расчет себестоимости разработки внедряемого программного продукта.
дипломная работа [5,4 M], добавлен 26.06.2011Общая характеристика экономического объекта. Обоснование необходимости разработки или реинжиниринга системы "Страхование имущества граждан". Постановка задачи на разработку функциональной подсистемы. Описание используемой условно-постоянной информации.
курсовая работа [2,3 M], добавлен 08.11.2012Анализ предметной области. Технико-экономическое обоснование разработки программного обеспечения информационной системы отдела кадров. Проектирование пользовательского интерфейса. Оптимизация параметров микроклимата помещений, оборудованных ПЭВМ.
дипломная работа [6,8 M], добавлен 16.01.2015Описание методологии проектирования и создания выбранного компонента экономической информационной системы. Описание функциональной и информационной моделей автоматизируемого процесса. Формы первичных и результатных документов, дерево программных модулей.
курсовая работа [1,7 M], добавлен 27.05.2014Основы методологии проектирования информационной системы. Общая характеристика и классификация CASE-средств. Рассмотрение логической, функциональной и физической модели данных системы "Студент". Расчет трудоемкости разработки программного изделия.
дипломная работа [1,9 M], добавлен 16.03.2012