- •Введение
- •2 Проведение обследования объекта автоматизации
- •2.1 Сбор и анализ данных об объекте автоматизации. Краткое описание и список бизнес процессов.
- •2.2 Описание диаграммы с применением методологии idef0 ("as-is")
- •2.3 Описание диаграммы с применением методологии dfd ("as-is")
- •2.4 Оценка затрат и предварительный расчет ожидаемой эффективности асоиу
- •3.3 Сбор и анализ данных о зарубежных и отечественных аналогах
- •3 Анализ и выявление ключевых процессов
- •3.1 Формулирование целей и задач создания асоиу
- •3.2 Выбор и обоснование состава процессов, подлежащих автоматизации
- •Заключение
- •Список использованной литературы
- •3. Детальные требования
- •3.1. Требования к внешнему интерфейсу
- •3.1.1. Пользовательские интерфейсы
- •3.2.3. Диаграммы активности
- •Приложение н. Техническое задание
Заключение
В ходе преддипломной практики для проектируемой системы распределения учебной нагрузки кафедры были составлены комплекты документации, диаграммы и рекомендации, подробно описывающие систему и достаточные для перехода к этапу реализации системы.
Составленная документация включает в себя: спецификацию требований к программному обеспечению, проектную документацию программного обеспечения, техническое задание.
Спецификация требований к программному обеспечению подробно описывает C-требования и D-требования в приложение К(с точки зрения заказчика и разработчика) к функционалу, содержанию и внешнему виду системы, в ней приведены комплекты UML-диаграмм (диаграмма вариантов использования, диаграмма последовательности и деятельности), эскизы пользовательского интерфейса, а также рекомендации и информация для разработчиков; проектная документация содержит общее описание проектируемой системы; техническое задание содержит описание требований к системе, ее надежности, составлен график работ, контроля и приемки системы, аргументировано отсутствие описания лингвистического, организационного, методического, правового и других видов обеспечения, не играющих большой роли в проектируемой системе.
Эскизный проект содержит детализированное описание слоя источника данных, с приведением примерного вида таблиц БД и типовых запросов, инварианты, то есть рекомендации для разработчиков по контролю вводимой информации, также перечислены требования к интерфейсу, которые находят отражения при составлении эскизов интерфейса в приложении К.
Документация и рекомендации составляются в соответствии с ГОСТами, на основе собранных и проанализированных в начале проекта данных системе.
Список использованной литературы
Костромская государственная сельскохозяйственная академия // [Электронный ресурс] URL http://kgsxa.ru/ (дата обращения: 11.01.2013).
АРМ “Кафедра” руководство пользователя // [Электронный ресурс] URL http://zi.psue.ru/docs/armkaf/form1.htm (дата обращения: 11.01.2013).
http://isu.tisbi.ru Федеральное государственное бюджетное образовательное // [Электронный ресурс] учреждение высшего профессионального образования (дата обращения: 11.01.2013).
Самарский областной центр новых информационных технологий при аэрокосмическом университете (ЦНИТ СГАУ) // [Электронный ресурс] http://cnit.ssau.ru/kadis/ (дата обращения: 11.01.2013).
Автоматизированная система управления вузом Галактика. [Электронный ресурс] // Галактика управление вузом. 2013. URL: http://vuz.galaktika.ru/solutions/vuz/ (дата обращения: 1.01.2013).
Халл Э. Разработка и управление требованиями. Практическое руководство пользователя / Э. Халл, К. Джексон, Д. Дик. – Оксфорд: Springer, 2005. – 240 с.
CMCONSULT. [Электронный ресурс] // Управление конфигурациями и изменениями. 2013.
Брауде Э. Технологии разработки программного обеспечения / Э. Брауде – СПб.: Питер, 2004. – 655 с.
Вендров А. М. Проектирование программного обеспечения экономических информационных систем / А.М. Вендров – М.:Финансы и статистика, 2006. – 544 с.
Гагарина Л.Г. Технология разработки программного обеспечения: учебное пособие / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Виснадул ; под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА-М, 2008. – 400 с.
Приложение А. Структурно-функциональная модель системы «AS-IS» (как есть) (IDEF0).
Рисунок А.1 – Контекстная диаграмма
Рисунок А.0 – Декомпозиция первого уровня
Приложение Б. Диаграмма потоков данных системы «AS-IS» (как есть) (DFD).
Рисунок Б.1 – Контекстная диаграмма
Рисунок Б.2 – Декомпозиция первого уровня модели системы «AS-IS» (DFD)
Приложение В. Структурно-функциональная модель системы «TO-BE» (как будет) (IDEF0).
Рисунок В.1 – Контекстная диаграмма
Рисунок В.2 – Декомпозиция первого уровня
Приложение Г. Диаграмма потоков данных системы «TO-BE» (как будет) (DFD).
Рисунок Г.1 – Контекстная диаграмма
Рисунок Г.2 – Декомпозиция первого уровня
Приложение Д. Диаграмма процессов, происходящих в системе (IDEF3)
Рисунок Д.1 – Диаграмма процессов, происходящих в системе (IDEF3)
Приложение К. Спецификация требований к программному обеспечению.
1. Введение
1.1. Цель
Этот документ предоставляет все требования для проекта. Части 1 и 2 предназначены преимущественно для заказчиков приложения, но также будут интересны инженерам-разработчикам, разрабатывающим или поддерживающим его. Часть 3 предназначена в основном для разработчиков, но также представляет некоторый интерес и для заказчика.
1.2. Область применения
Этот документ охватывает требования информационной системы составления планов по учебно-методической, научно-исследовательской и организационной и воспитательной работам кафедры «Автоматизированные системы обработки информации и управления».
1.3. Определения, термины и сокращения
С-требование – cводка требований к приложению, сформулированных в форме, понятной клиенту. D-требование – cводка требований к приложению, сформулированных достаточно четко для использования программистами при проектировании и реализации. По возможности D-требования должны быть также понятны и клиенту.
1.4. Ссылки
План управления конфигурациями программного обеспечения (SCMP) для ИС.
Архитектура программного обеспечения (SDD) для ИС.
План управления программным проектом (SPMP) для ИС.
План контроля качества (SQAP) для ИС.
2. Общее описание
2.1. Перспективы продукта
В дальнейшем предполагается дополнить данную систему подсистемой ведения рейтинга студентов .
2.1.1. Концепции операций
Смотри раздел «Сбор и анализ данных об объекте автоматизации» ПЗ.
2.1.2. Концепции пользовательского интерфейса
После первых встреч с заказчиком был разработан прототип пользовательского интерфейса формы формирования журнала, изображение которой приведено на рисунке К.4 Основные элементы интерфейса:
Выпадающий список выбора преподавателя
Кнопка перехода на форму формирования журнала
Кнопка перехода на форму построения отчета
При разработке прототипа были использованы стандартные элементы управления (однострочные текстовые поля, кнопки, выпадающие списки, флажки). Посредством кнопок пользователь должен иметь возможность перейти к соответствующим формам для реализации необходимых функций.
2.1.3. Аппаратные интерфейсы
Нет.
2.1.4. Программные интерфейсы
Нет.
2.1.5. Коммуникационные интерфейсы
Нет.
2.1.6. Ограничения по памяти
Нет
2.1.7. Операции
Нет.
2.1.8. Требования по адаптации
Нет.
2.2. Функции продукта
Анализ, проведенный на страницах пояснительной записки, позволил показать, что варианты использования являются наиболее подходящим способом определения общей функциональности проектируемой ИС. Ниже приведена общая диаграмма вариантов использования проектируемой системы.
Рисунок К.1 –Диаграмма вариантов использования
2.3. Пользовательские характеристики
Пользователями программы будут заведующие кафедрами обладающие средним уровнем навыков пользования компьютером. Это значит, что интерфейс, обладающий стандартными наборами элементов управления и подсказками, будет прост и понятен пользователям.
2.4. Ограничения
Клиентская часть должна быть совместима с браузерами, поддерживающими стандарт CSS не ниже 2.0.
2.5. Предположения и зависимости
Нет.
2.6. Распределение требований
Требования, описанные в разделах 1 и 2 этого документа, называются «С-требованиями», в разделе 3 — «D-требованиями». Основной аудиторией С-требований является сообщество заказчиков, вторичной — разработчиков. Для D-требований ситуация обратная. Эти два уровня требований должны быть согласованными. Несогласованности должны быть отмечены отдельно как дефекты. В случае, когда требование сформулировано в С-требованиях и D-требованиях, приложение будет разрабатываться согласно D-требованиям, поскольку они более подробны.
