Разработка автоматизированной информационной системы дистанционного обучения по дисциплине "Финансы и кредит" (стр. 13 из 18)

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

· общая информационная модель системы;

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

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

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

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

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

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

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

Перечислим основные принципы методологии RAD:

· разработка приложений итерациями;

· необязательность полного завершения работ на каждом из этапов жизненного цикла;

· обязательное вовлечение пользователей в процесс разработки ИС;

· необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

· необходимое использование генераторов кода;

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

· тестирование и развитие проекта, осуществляемые одновременно с разработкой;

· ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

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

Рис. 4.1 - Организационная схема обучения дисциплине «Финансы и кредит

На рис. 4.1. представлена организационная схема обучения по дисциплине «Финансы и кредит». Обучение начинается со знакомства с тематическим содержанием курса, списком рекомендуемой литературы. Производится инсталляция и изучение приёмов работы с автоматизированной системой дистанционного обучения (блок №1). Последовательно, начиная с первого, изучаются разделы дисциплины (блок №2). Раздел состоит из нескольких тем. После изучения очередной темы (блок №3) производится контроль знаний по ней. Студент отвечает на контрольные вопросы по пройденному теоретическому материалу, решает практические задачи по данной теме (блок №4). Для решения возникших во время изучения темы и выполнения заданий вопросов студент консультируется с преподавателем (блоки №5 и №6). После полного усвоения темы студент участвует в семинаре по этой теме (блок №7). Если изученная тема – последняя в изучаемом разделе (блок №8), то студент сдаёт зачёт по этой теме (блок №9), в противном случае он начинает изучать следующую тему (переходит к блоку №3). Студенту предоставляется 3 попытки для сдачи зачёта и последний срок его сдачи (блок №12). Если он не уложился в эти рамки, то производится его отчисление (блок №16). В случае успешной сдачи зачёта по изученному разделу, студент переходит к изучению следующего (блок №11). Если изучены все разделы дисциплины (блок №11), студент сдаёт экзамен по все дисциплине. Если экзамен сдан успешно (блок №14), студент получает отметку об успешном прохождении курса «Финансы и кредит», в противном случае производится его отчисление.

4.5 Защита информации

Рассмотрим в целом организационные мероприятия и процедуры, используемые для решения проблем безопасности информации на всех этапах проектирования и эксплуатации автоматизированных систем (АС). Существенное значение при проектировании АС различного уровня и назначения придается предпроектному обследованию объекта автоматизации. На этой стадии: - устанавливается наличие или отсутствие секретной (конфиденциальной) информации в разрабатываемой АС, оценивается уровень ее конфиденциальности и объемы; - определяются режимы обработки этой информации, тип АС, состав комплекса основных технических средств вычислительной техники (СВТ), общесистемные программные средства, предполагаемые к использованию в разрабатываемой АС; оценивается возможность использования имеющихся на рынке сертифицированных средств защиты информации; - определяется степень участия персонала ВЦ, функциональных и производственных служб, научных и вспомогательных работников объекта автоматизации в обработке информации, характер взаимодействия между собой и со службой безопасности; - определяются мероприятия по обеспечению режима секретности на стадии разработки. Предпроектное обследование может быть выполнено собственными силами или, как законченная научно-техническая работа, может быть поручено специализированному предприятию, имеющему лицензию на этот вид деятельности. На основании результатов предпроектного обследования разрабатывается аналитическое обоснование создания системы защиты секретной информации (СЗСИ) и раздел технического задания на ее разработку. В комплексе работ по созданию АС должна предусматриваться опережающая разработка и внедрение СЗСИ, реализуемой в виде подсистемы АС и включающей в себя комплекс организационных, программно-технических средств, систем и мероприятий по защите информации от НСД. СЗСИ состоит из системной и функциональной частей. Системная часть является общей и применяется при разработке, внедрении и эксплуатации всех или большинства задач АС, функциональная часть обеспечивает защиту информации при решении конкретной задачи и специфична защите информации от НСД в АС различных классов. Важное место в системе организации работ по обеспечению безопасности информации на предприятиях занимают так называемые специальные научно-технические подразделения (СИТИ) - службы защиты информации, основной направленностью которых являются организация работ по выявлению возможностей и предупреждению утечки информации, методическое руководство и участие в разработке требований позащите информации от НСД, аналитического обоснования необходимости создания СЗСИ, согласование выбора СВТ (в том числе общесистемного программного обеспечения), программно-технических средств и систем защиты. В случае привлечения для разработки СЗСИ специализированных предприятий, функции и задачи различных служб могут изменяться и перераспределяться, но координация должна остаться за предприятием-заказчиком АС. Кроме того в обеспечении безопасности информации, особенно на стадии эксплуатации АС, задействованы службы обеспечения безопасности информации или секретный орган, службы администратора АС. Все указанные службы активно взаимодействуют в целях достижения эффективной разработки и эксплуатации АС и ее СЗСИ. Для эффективной и надежной, с точки зрения обеспечения безопасности информации, работ АС необходимо правильно организовать разрешительную систему доступа пользователей к информации в АС т.е. предоставить пользователям право работать с той информацией, которая необходима им для выполнения своих функциональных обязанностей, установить их полномочия по доступу к информации. Среди организационных мероприятий по обеспечению безопасности информации важное место занимает охрана объекта, на котором расположена защищаемая АС (территория, здания, помещения, хранилища информационных носителей), путем установления соответствующих постов технических средств охраны или любыми другими способами, предотвращающими или существенно затрудняющими хищение СВТ, информационных носителей, а также НСД к СВТ и линиям связи. Технология обработки информации в АС различна и зависит от используемых СВТ, программных средств, режимов работы. Не вдаваясь в особенности технологического процесса, обусловленные различиями в технике, программном обеспечении и другими причинами, можно констатировать, что основной характерной особенностью, связанной с обработкой секретной или иной подлежащей защите информации является функционирование системы защиты информации от НСД (СЗИ НСД) как комплекса программно-технических средств и организационных (процедурных) решений, предусматривающей учет, хранение и выдачу пользователям информационных носителей, паролей, ключей, ведение служебной информации СЗИ НСД (генерацию паролей, ключей, сопровождение правил разграничения доступа), оперативный контроль за функционированием СЗСИ, контроль соответствия, общесистемной программной среды эталону и приему включаемых в АС новых программных средств, контроль за ходом технологического процесса обработки информации путем регистрации анализа действий пользователей, сигнализации опасных событий. Следует отметить, что без надлежащей организационной поддержки программно-технических средств защиты информации от НСД и точного выполнения предусмотренных проектной документацией процедур, в должной мере не решит проблему обеспечения безопасности информации в АС, какими бы совершенными эти программно-технические средства не были.