|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Описание и список бизнес процессовСтр 1 из 5Следующая ⇒
Список сокращений
Аннотация
Объектом проектирования в курсовом проекте является автоматизация процессов проведения турниров для школьников с нестандартной системой проведения и подсчета очков по различным общеобразовательным предметам. Предмет проектирования – разработка АС «Карусель ikobu». Пояснительная записка к курсовому проекту состоит из введения, 5 глав и заключения. Во введении представлено краткое описание предметной области, обоснована актуальность исследования курсовой работы, определена цель создания АСОИУ и сформулированы задачи для ее достижения. В первой главе «Проведение обследования объекта автоматизации» проводится обзор аналогов проектируемой АСОИУ, делается вывод о целесообразности ее разработки, анализируются данные об объекте автоматизации, определяется состав процессов, подлежащих автоматизации, а также проводятся первоначальные оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ (на основе диаграммы потоков данных системы (DFD «AS - IS»). Во второй главе «Документация проекта» рассматривается ряд нормативных документов, использованных при подготовке проекта. В третьей главе «Формирование требований к проектируемой АСОИУ» формулируются цели и задачи создания АСОИУ, производятся выбор и обоснование состава процессов, подлежащих автоматизации, формирование требований к проектированной АСОИУ, проектирование ГПИ, а также, на основе диаграммы потоков данных системы (DFD «TO - BE»), проводятся дополнительные оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. В четвертой главе «Разработка концепции АСОИУ» производится выбор архитектуры проектируемой системы. В пятой главе «Эскизный проект» рассматривается структура автоматизированной системы, и разрабатываются ее предварительные проектные решения. В заключении подведены общие итоги проделанной работы и изложены основные выводы. Пояснительная записка изложена на 95 страницах, включает 61 рисунок, 11 таблиц и 13 приложений, представляющих собой документацию проекта и диаграммы IDEF0, DFD, IDEF3, ERD, UML. Библиографический список включает 15 наименований используемой литературы.
 Содержание
Список сокращений. 3 Введение. 6 Глава 1. Проведение обследования объекта автоматизации. 8 1.1 Описание и список бизнес процессов. 8 1.2 Структурно – функциональная модель системы. Методология IDEF0: AS - IS. 8 1.3 Диаграмма потоков данных системы. Методология DFD: AS - IS. 10 1.4 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: AS - IS. 12 1.5 Сбор и анализ данных об отечественных и зарубежных аналогах. 15 Глава 2. Документация проекта. 19 2.1 Исходные материалы и документы по созданию АСОИУ.. 19 2.2 План управления программным проектом.. 20 2.3 Техническое задание. 21 Глава 3. Формирование требований к проектируемой АСОИУ.. 22 3.1 Анализ и выявление ключевых процессов. 22 3.1.1 Формулирование целей и задач создания АСОИУ.. 22 3.1.2 Cостав процессов, подлежащих автоматизации. 23 3.2 Структурно – функциональная модель системы. Методология IDEF0: TO - BE.. 24 3.3 Диаграмма потоков данных системы. Методология DFD: TO - BE.. 25 3.4 Диаграмма последовательности системы. Методология IDEF3. 26 3.5 С – требования. 27 3.6 D – требования. 29 3.7 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: TO - BE.. 30 3.8 Проектирование графического пользовательского интерфейса (ГПИ) 32 3.8.1 Описание последовательности форм (диаграмма состояний) 32 3.8.2 Описание макета типовой формы.. 33 Глава 4. Разработка концепции АСОИУ.. 34 Глава 5. Эскизный проект. 36 5.1 Диаграмма деятельности для системы в целом.. 36 5.2 Диаграмма последовательности для Use Case. 36 5.3 Диаграмма классов по уровням.. 37 Заключение. 39 Список изпользуемой литературы.. 41 Приложение A IDEF0 «AS - IS». 42 Приложение B DFD «AS - IS». 50 Приложение C IDEF0 «TO - BE». 58 Приложение D DFD «TO - BE». 66 Приложение E IDEF3 «TO-BE». 74 Приложение G План управления. 75 Приложение H Техническое задание. 80 Приложение J Use Case. 84 Приложение K Диаграмма состояний. 85 Приложение L Макетные виды страниц. 86 Приложение M Диаграмма Активности. 91 Приложение N Диаграмма Последовательности. 92 Приложение P ER Диаграмма. 94 Введение
Международная комиссия ЮНЕСКО определяет два основных принципа современного образования: " образование для всех" и " обучение в течение всей жизни". Эти принципы, несомненно, верны, но в суровых российских условиях и под влиянием стереотипов возникает несколько проблем [13]: 1) Проблема неравномерной плотности населения на территории России. Поступление в ВУЗ в другом городе стоит отнюдь немаленьких денег, поэтому часто недопустимо – как и сам переезд в другой город обеспечивает множество значительных проблем. 2) Проблема времени. В наши дни темп жизни большинства современных людей вынуждает их расписывать свое время по минутам. Учиться необходимо всем, но как?! 3) Проблема денег. О том, сколько стоит сейчас образование, особенно высшее, и говорить не стоит. Конкурс на бюджетные места очень трудно выдержать, но ведь и платное обучение мало кто сможет «потянуть». Дистанционное образование является компромиссом для всех вышеперечисленных проблем – оно уверенно вошло в практику работы учебных заведений системы высшего и среднего профессионального образования. Активное внедрение в учебный процесс образовательных учреждений компьютерных интернет – технологий, оказывающих существенное влияние на повышение качества подготовки школьников и студентов, является неотъемлемой частью современного образования. Одними из самых больших плюсов ДО являются [14]: 1. Для учащихся: - доступность обучения для большого числа желающих, место проживания которых удалено от месторасположения учебного заведения; - система оценки знаний (электронные тесты) объективна и независима от преподавателя; 2. Для преподавателей: - Возможность автоматизировать систему оценки знаний; - Использование современных мультимедийных технологий в учебных материалах, что не всегда возможно при аудиторных занятиях; 3. Для учебных заведений: - повышение престижа; - количество студентов может быть во много раз большим, чем при традиционных видах обучения; - экономия средств на проведении учебного процесса с использованием современных дорогостоящих мультимедийных проекторов, камер и другого оборудования. В рамках данного курсового проекта рассматривается деятельность преподавателей в организации проведения турниров для школьников по различным общеобразовательным предметам. Автоматизированные системы проведения соревнований со школьниками помогают организовать участие в них большого количества учащихся. При этом использование интернет – технологий позволяет школьникам участвовать в турнирах дистанционно, не выходя из дома. Да и простая система регистрации и учета, позволяет пользователям быстро и легко просматривать результаты тестирования и анонсы будущих турниров. Существуют большое количество систем, предназначенных для дистанционного тестирования учащихся в учебных заведениях высшего или среднего профессионального образования, к примеру, системы проведения стандартных олимпиад по программированию с подведением итогов, на основе тестирования программ, но они все не подходят нам по формату проведения. Есть и другие формы проведения соревнований, которые более подходят для организации работы со школьниками, например, различные блицтурниры и другие. Как уже говорилось ранее, существует огромное количество различных систем подобного типа, но мы не можем их использовать, поскольку они закрыты (т.е. не предоставляется исходный код и право на размещение), т.е. их попросту нельзя взять и разместить на свой компьютер. Разрешение всех вышеперечисленных проблем обусловило выбор темы моего курсового проекта: «Проектирование программной системы проведения соревнований школьников по различным предметам», и разработку АС «Карусель ikobu». Целью создания АСОИУ является повышение эффективности работы преподавательского состава учебного заведения (среднего образования) в организации проведения соревнований для школьников, в том числе и младших классов, по различным общеобразовательным предметам для развития их познавательной деятельности. Для достижения поставленной цели поставлена задача создания простой и платформо - независимой системы проведения турниров для школьников с нестандартной системой проведения и подсчета очков. Для этого необходимо выполнить следующие задачи: 1) Обследовать объект автоматизации. 2) Произвести детальный анализ аналогов проектируемой системы (дистанционных систем тестирования). 3) Сформировать требования к проектируемой системе. 4) Разработать концепцию автоматизированной системы. 5) Провести детальное проектирование системы. 6) Разработать модель данных. 7) Разработать прототип пользовательского интерфейса. 8) Составить комплект нормативных документов.
Глава 1. Проведение обследования объекта автоматизации Исходные материалы и документы по созданию АСОИУ
Прежде чем приступать к этапу формирования требований к системе необходимо определить и систематизировать нормативные документы, определяющие основные понятия в области автоматизированных систем, устанавливающие термины и определения, основные положения, общие требования, процессы жизненного цикла, стадии создания автоматизированной системы. [2] Ввиду ограниченного объема времени, выделенного на курсовое проектирование, номенклатура разрабатываемой технической документации отличается от документации, предусмотренной действующими нормативными документами, и оговаривается в задании на курсовой проект. Минимальный комплект документации, который необходимо разработать в ходе выполнения курсового проекта включает в свой состав следующие два основных документа: · План управления программным проектом (Software Project Management Plan – SPMP) в соответствии со стандартом IEEE 1058.1-1987 [2]; · Техническое задание (ТЗ) в соответствии со стандартом ГОСТ 34.602-89 [2]; Иерархия нормативных документов, разрабатываемых в ходе проектирования, представлена на диаграмме (см. рисунок 3). Данная диаграмма представляет собой распределение документации по процессам жизненного цикла [2]. В ходе процесса документирования будут использованы следующие государственные стандарты: · ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» [3]; · ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» [4]; · ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» [5]; · ГОСТ Р ИСО/МЭК 12.207-99 «Информационная технология. Процессы жизненного цикла программных средств» [6]; · ГОСТ 24.602-86 «Автоматизированные системы управления. Состав и содержание работ по стадиям создания» [7]; · ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [8]; · ГОСТ 34.602-89 «Автоматизированные системы. Техническое задание на создание автоматизированной системы» [9]. В ходе основного процесса разработки будет составлено техническое задание (ТЗ) в соответствии со стандартом ГОСТ 34.602-89. В ходе процесса управления будет составлен план управления программным проектом (Software Project Management Plan – SPMP) в соответствии со стандартом IEEE 1058.1-1987.
Рисунок 3. Диаграмма распределения документации по процессам жизненного цикла
План управления программным проектом
Управление проектом заключается в управлении производством продукта в рамках отведенных средств и времени. Иными словами, управление проектом – это достижение баланса между стоимостью, возможностями, качеством и сроками. Возможность управления появляется тогда, когда этот баланс оценивается численно. Основное значение в управлении программным проектом имеет проблема управления рисками. [2] Риск – это нечто, что может появиться по ходу проекта, и это нечто в худшем случае может негативно повлиять на проект. Факторы, приводящие проект к срыву, на ранних стадиях проекта проявляются в виде рисков. Таким образом, своевременное выявление того или иного риска, а также принятие соответствующих мер позволяют предотвратить срыв проекта. Существуют два типа рисков: 1. риски, которых можно избежать или которые можно предотвратить (устранимые); 2. риски, которых невозможно избежать. Управление риском состоит из нескольких действий: 1. идентификация; 2. планирование устранения; 3. выбор приоритетов; 4. устранение или уменьшение. Основными факторами риска являются перечисленные ниже: 1. недостаточная вовлеченность в проект высшего руководства; 2. невозможность привлечения пользователей; 3. непонимание требований; 4. привлечение неадекватных пользователей; 5. невозможность управления ожиданиями конечных пользователей; 6. изменение области применения или целей проекта; 7. нехватка знаний или навыков у персонала. План управления программным проектом (SPMP – Software Project Management Plan) приведен в приложении G. 2.3 Техническое задание
Техническое задание (ТЗ) на АСОИУ является основным документом, определяющим требования и порядок создания (развития или модернизации) автоматизированной системы, в соответствии с которым проводится разработка АСОИУ и ее приемка при вводе в эксплуатацию. ТЗ включает в себя системное описание расширенных требований к разрабатываемому изделию и составляется на основе исходного задания по курсовому проекту с учетом всей проведенной выше работы в отношении формулирования и спецификации требований. [2] В техническом задании также приведен перечень и критерии отказов системы - причины, по которым могут возникнуть неполадки или сбои в работе системы. Также в техническом задании указаны требования к форме представления выходной информации и требования к используемой БД. Техническое задание на создание АСОИУ, оформленное в соответствии с ГОСТ 34.602 - 89 «Информационная технология. Комплекс стандартов на автоматизированные системы». [9] Техническое задание на создание автоматизированной системы», помещается в приложение H. Глава 3. Формирование требований к проектируемой АСОИУ Глава 5. Эскизный проект Заключение
В результате курсового проектирования, поставленные перед разработчиком задачи, были выполнены. Для Югорского физико-математического лицея – интерната была спроектирована программная система проведения соревнований школьников по различным общеобразовательным предметам. Система предоставляет возможность хранения информации о ходе соревнования (турнира), базы участников и их рейтинга, а так же: 1. Администратору системы: · Возможность создания ограниченных по времени турниров по различным общеобразовательным предметам (предполагается, что в рамках общего времени проведения карусели на решение каждой задачи будет предоставляться не ограниченное время) и работы над ними, а именно: - Добавление и редактирование (при необходимости) условий задач и ответов к ним (предполагается создание вопросов с любым контентом); - Активация, деактивация или удаление необходимого турнира (с возможностью установления пароля для участия в турнире); · Возможность одновременного проведения нескольких турниров; · Возможность автоматизированной проверки введенных ответов на задачу и подсчета результатов. · Возможность автоматического вычисления статистики по соревнованию (по его завершению соответственно); · Возможность просмотра списка зарегистрированных пользователей в системе и информации о них (с возможностью записи участника на необходимый турнир, либо его удаления); · Возможность изменения прав доступа любого пользователя в системе; · Возможности, предоставляемые любому участнику турнира, описанные ниже; 2. Участнику турнира: · Возможность быстрой и удобной регистрации/авторизации в системе; · Возможность просмотра списка активных или предстоящих турниров, а так же информации о них. · Возможность записи на необходимый турнир и дальнейшее участие в нем; · Возможность просмотра предварительных результатов и конечных (по завершению турнира); · Возможность просмотра архива прошедших турниров и их результатов (список участников и занятых ими мест); · Возможность связи с администратором (отправка сообщения). При обследовании объекта автоматизации с использованием конструктивной модели стоимости COCOMO была вычислена оценка затрат на проектирование системы. Трудозатраты составили примерно 11, 4 (чел-мес), а время, которое понадобится для разработки системы одним человеком, составляет 6 месяцев и 9 дней. На этапе формирования требований к проектируемой АСОИУ были составлены два нормативных документа: 1. План управления программным проектом в соответствии со стандартом IEEE 1058.1-1987. 2. Техническое задание на создание АСОИУ, оформленное в соответствии с ГОСТ 34.602 – 89. Были построены диаграммы IDEF0, DFD, IDEF3 модели «AS-IS» и «TO-BE», а также UML-диаграммы: 1. Диаграмма вариантов использования. 2. Диаграммы последовательности вариантов использования. 3. Диаграмма деятельности для системы в целом. 4. Диаграммы классов по уровням (ER модель, слой представления (интерфейсы), сервисный слой (контроллер)). Был разработан эскиз ГПИ. Создан макет типовой формы и описана диаграмма состояний форм системы. В процессе разработки концепции АСОИУ была аргументировано выбрана клиент-серверная архитектура системы. В перспективе возможно расширение функционала системы, а также доработка графического пользовательского интерфейса.
Список используемой литературы
Приложение A Структурно-функциональная модель системы. IDEF0 «AS - IS»
Рисунок А1. Диаграмма IDEF0. Модель «Чёрный ящик»
Рисунок А2. Декомпозиция контекстной диаграммы «Система проведения турниров» Рисунок А3. Диаграмма декомпозиции функционального блока «Подготовка турнира» Рисунок А4. Диаграмма декомпозиции функционального блока «Подготовка места для проведения турнира» Рисунок А5. Диаграмма декомпозиции функционального блока «Создание списка участников турнира» Рисунок А6. Диаграмма декомпозиции функционального блока «Проведение турнира» Рисунок А7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира» Рисунок А8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов» Приложение B Диаграмма потоков данных системы по методологии DFD («AS - IS») Рисунок B1. Диаграмма DFD. Модель «Чёрный ящик» Рисунок B2. Декомпозиция контекстной диаграммы «Система проведения турниров» Рисунок B3. Диаграмма декомпозиции функционального блока «Подготовка турнира»
Рисунок B4. Диаграмма декомпозиции функционального блока «Подготовка места для проведения турнира»
Рисунок B5. Диаграмма декомпозиции функционального блока «Создание списка участников»
Рисунок B6. Диаграмма декомпозиции функционального блока «Проведение турнира» Рисунок B7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира» Рисунок B8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов» Приложение C Структурно-функциональная модель системы по методологии IDEF0 («TO - BE»)
Рисунок C1. Диаграмма IDEF0. Модель «Чёрный ящик»
Рисунок C2. Декомпозиция контекстной диаграммы «Автоматизированная система проведения турниров» Рисунок C3. Диаграмма декомпозиции функционального блока «Подготовка заданий» Рисунок C4. Диаграмма декомпозиции функционального блока «Конфигурирование турнира» Рисунок C5. Диаграмма декомпозиции функционального блока «Создание списка участников турнира» Рисунок C6. Диаграмма декомпозиции функционального блока «Проведение турнира» Рисунок C7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира» Рисунок C8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов» Приложение D Диаграмма потоков данных системы по методологии DFD («TO - BE») Рисунок D1. Диаграмма DFD. Модель «Чёрный ящик» Рисунок D2. Декомпозиция контекстной диаграммы «Автоматизированная система проведения турниров» Рисунок D3. Диаграмма декомпозиции функционального блока «Подготовка заданий»
Рисунок D4. Диаграмма декомпозиции функционального блока «Конфигурирование турнира»
Рисунок D5. Диаграмма декомпозиции функционального блока «Создание списка участников»
Рисунок D6. Диаграмма декомпозиции функционального блока «Проведение турнира» Рисунок D7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира» Рисунок D8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов» Приложение E Диаграмма последовательности системы. Методология IDEF3 «TO-BE» Рисунок E1. Диаграмма последовательности системы «Система проведения турниров» Приложение G (обязательное)
IEEE 1058.1-1987 ПЛАН УПРАВЛЕНИЯ ПРОГРАММНЫМ ПРОЕКТОМ (SOFTWARE PROJECT MANAGEMENT PLAN – SPMP)
Утверждаю ____________ Дата ____________
01.09.11 Н.А. Аристов: Начало работы над КП 02.09.11 Н.А. Аристов: Получение задания на КП 09.09.11 Н.А. Аристов: Проведение обследования объекта автоматизации 27.09.11 Н.А. Аристов: Формирование требований к АСОИУ 14.10.11 Н.А. Аристов: Разработка концепции АСОИУ 25.10.11 Н.А. Аристов: Эскизный проект 16.12.11 Н.А. Аристов: Создание первой версии 13.02.12 Н.А. Аристов: Доработка первой версии 22.02.12 Н.А. Аристов: Проверка для выпуска 27.02.12 Н.А. Аристов: Окончательное форматирование 09.03.12 Н.А. Аристов: Выпуск
1. Введение 1.1. Обзор проекта Данный проект организован для разработки автоматизированной системы проведения турниров для школьников с нестандартной системой проведения и подсчета очков по различным общеобразовательным предметам. Система будет разработана несколько итераций, после каждой итерации не требуется выпуск промежуточной версии программного продукта. 1.2. Результирующие артефакты проекта Следующие материалы должны быть поставлены в указанные сроки. Версия 1 (прототип) с документацией — третья неделя двенадцатого месяца. Версия 2 с документацией — вторая неделя второго месяца. Документация включает в себя SPMP. Аббревиатуры определены в разделе 1.5. 1.3. Развитие SPMP Данный документ поддерживается лидером проекта. Лидер проекта должен поместить данный документ под управление конфигурациями и обязан поддерживать документ в актуальном состоянии, еженедельно внося необходимые изменения. 1.4. Ссылочные материалы Все необходимые стандарты IEEE опубликованы в сборнике стандартов IEEE. 1.5. Аббревиатуры IEEE (Institute of Electrical and Electronics Engineers) – институт инженеров по электротехнике и радиоэлектронике. QA (Quality Assurance) – контроль качества. SPMP (Software Project Management Plan) – план управления программным проектом (данный документ). USDP (Unified Software Development Process) – унифицированный процесс разработки программного обеспечения. SRS (Software Requirements Specification) – спецификация требований к программному обеспечению. SDD (Software Design Document) – проектная документация программного обеспечения.
2. Организация проекта 2.1. Модель процесса Первые две версии проекта будут выполнены с использованием спирального процесса разработки, по одной итерации на версию. Итерации проводятся в соответствии с USDP. Согласно USDP, итерации классифицируются на начальные итерации, итерации проектирования, конструирования и перехода. Первая итерация будет состоять только из обследования объекта автоматизации и формирования требований к АСОИУ. Количество последующих итераций и состав будут определены после того, как будет готова первая итерация. a. Организационная структура На рисунке G1 изображена типовая структура технологии подготовки и проведения тестирования учащихся.
Рисунок G1. – Структура технологии подготовки и проведения тестирования учащихся
Проект организован как команда равных с назначением ролей. Роли следующие: лидер команды, ответственный за конфигурацию, ответственный за качество, ответственный за требование, ответственный за проектирование. Все роли показаны на рисунке G2.
Рисунок G2. Организация проекта
2.3. Организационные рамки и взаимосвязи Не предусмотрено. 2.4. Ответственность за проект Ответственность участников проекта показана в таблице G1. Ответственность за документ подразумевает следующее: - документ должен быть создан вовремя; - лидер команды определяет, кто пишет документ; - документ поддерживается в актуальном состоянии.
Таблица G1. Ответственность участников проекта
3. Управляющий процесс 3.1. Цели и приоритеты Высший приоритет имеет выполнение проекта в срок. На втором месте по приоритетности – достижение заданного уровня качества. Третий приоритет имеет выполнение максимального количества требований. Четвертый приоритет имеет создание классов, которые можно повторно использовать в других аналогичных проектах. 3.2. Допущения, зависимости и ограничения Нет. 3.3 Управление рисками Информация об идентификации и обработки рисков заносится в таблицу G2. Описание рисков приведено в пояснительной записке по курсовому проекту, раздел 2.2 «План управления программным проектом».
Таблица G2. Идентификация и обработка рисков
3.4. Механизмы мониторинга и контроля Вся команда будет встречаться на совещании в начале каждого этапа (определение требований, проектирование, разработка ТЗ) каждой итерации. Должны проводиться еженедельные совещания по проекту по понедельникам с пяти до семи часов вечера. 3.5. План расстановки кадров Назначение ролей указано в таблице G3. Каждый участник команды имеет дополнительные обязанности по резервированию и инспектированию.
Таблица G3. Назначение ролей участников проекта
4. Технический процесс SRS описывает некоторые аспекты требуемого технологического процесса. Здесь рассматриваются те аспекты, которые не установлены явно в SRS. 4.1. Методы, инструменты и технологии • Реализация ведется на языке C# (С Sharp). Во всех случаях используется объектно-ориентированный подход. • Средство реализации – ASP.NET MVC. • ORM (Object – relational mapping) – Entity Framework 4.1. 4.2. Функции сопровождения проекта Сопровождением проекта будет заниматься лидер проекта.
5. Распределение работ, план-график и бюджет 5.1. Распределение работ Основные работы выполняются совместно всеми участниками команды: проведение обследования объекта автоматизации, формирование требований к проектируемой АСОИУ, разработка концепции АСОИУ, разработка ТЗ. При разработке эскизного проекта работы, связанные с проектированием модели данных, а также работы, связанные с проектированием пользовательского интерфейса, возлагаются на Аристова Н.А. Инспектирование необходимо производить всем участникам команды. 5.2. Зависимости Нет. 5.3. Потребности в ресурсах Аппаратные ресурсы составят один компьютер с процессором Intel Dual-Core 3, 0 ГГц (так же не менее 2 Гбайт RAM и не менее 16 Гбайт свободного пространства на жестком диске) и операционной системой Windows Server 2008 R2 с программным обеспечением: • Сервер IIS 7.5. • СУБД MSSQL 2008. 5.4. Выделение бюджета и ресурсов На проектирование информационной системы выделено четыре месяца. 5.5. План-график План график (диаграмма Ганта) приведен на рисунке G3.
Рисунок G3. Диаграмма Ганта Приложение H (обязательное)
Техническое задание
1. Общие сведения 1.1. Настоящее техническое задание описывает задачу создания автоматизированной системы проведения турниров для школьников с нестандартной системой проведения и подсчета очков по различным общеобразовательным предметам. 1.2. Заказчик проекта: Алексеев А.В., Югорский физико-математический лицей – интернат (до 2007 г. бывший ЮФМШ), г. Ханты – Мансийск. 1.3. Основанием для создания ИС являются результаты экспресс – обследования и задание на курсовой проект. 1.4. Сроки проведения работ: сентябрь 2011 – март 2012.
2. Назначение и цели создания системы 2.1. Назначение автоматизированной системы |
Последнее изменение этой страницы: 2017-05-11; Просмотров: 372; Нарушение авторского права страницы
