close

Вход

Забыли?

вход по аккаунту

?

Poyasnitelnaya zapiska

код для вставкиСкачать
Министерство образования и науки Российской Федерации
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
"САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
МЕХАНИКИ И ОПТИКИ"
ФАКУЛЬТЕТ СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
На тему: "АИС футбольного клуба"
По дисциплине: "ТРПП"
Выполнил:
Студент группы №363
Рустамов В.В.
Оценка:_______
Проверил(а):
Филиппова О.Ю.
Дата:__________
Подпись:____
Санкт-Петербург
2013г.
СОДЕРЖАНИЕ
РАЗДЕЛ 1. ВЫБОР МОДЕЛИ ..................................................................4
РАЗДЕЛ 2. ТРЕБОВАНИЯ .......................................................................5
РАЗДЕЛ 3. ПРОЕКТИРОВАНИЕ .............................................................. 9
РАЗДЕЛ 4. РАЗРАБОТКА ПРОГРАММНОГО КОДА ................................... 11
РАЗДЕЛ 5. ВЕРИФИКАЦИЯ ПП ...............................................................12
ПРИЛОЖЕНИЕ АНОТАЦИЯ
Пояснительная записка к курсовому проекту по теме: "АИС футбольного клуба"
В первом разделе осуществлён выбор модели ЖЦ ПП.
Второй раздел посвящён описанию требований и способ их выявления
Третий раздел визуального представления понимания о ПП.
Четвёртый раздел посвящён выбору языка программирования.
Пятый раздел посвящён тестированию и верификации. 1 ВЫБОР МОДЕЛИ ЖИЗНЕНОГО ЦИКЛА ПП
Модель ЖЦ разработки ПО схематически объясняет, каким образом будут выполняться действия по разработке ПО, посредствам описания последовательности этих действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за другом, повторяться или происходить одновременно. Для разработки АИС футбольного клуба очевидным выбором модели для автоматизации столь сложной системы будет "каскадная модель ЖЦ".
Каскадная модель предусматривает последовательную организацию работ. При этом основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Выбор модели обусловлен следующими факторами:
- Повышение и гарантии качества: Промежуточные результаты могут быть проверены на ранних стадиях.;
- Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.;
- Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком.
- Простота использования: с данным программным продуктом легко работать не квалифицированному пользователю
- Данные не конфиденциальны : продукту не требуется повышенная надёжность
2 ТРЕБОВАНИЯ
2.1. Выявление требований
Этап 1. Достижение соглашения об определении проблемы.
Процесс выявления требований заключается в достижении соглашения о том, что должен представлять из себя выходной продукт. Методы выявления требований бывают следующими: 1)Интервью, опросы, анкетирование
2)Мозговой штурм, семинар
3)Наблюдение за производственной деятельностью, "фотографирование" рабочего дня
4)Анализ нормативной документации
5)Анализ моделей деятельности
6)Анализ конкурентных продуктов
7) Анализ статистики использования предыдущих версий системы
В данной работе будут использованы все методы , основными же будут методы под пунктами 6 и 7, таким образом, опираясь на все вышесказанное можно с уверенностью заявить , что причины , стоящие в выборе представления готового продукта буду более чем обоснованы
Этап 2 Определение границ системы. Создаваемая система предназначена использования кассирами, соответственно границы системы должны быть, прежде всего, определены их функциональными возможностям и задачами, поставленными перед данной системой.
2.2. Анализ требований
При разработке требований часто возникают проблемы двусмысленности, неполноты, и несогласованности отдельных требований. Устранение этих проблем на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки. Для решения и устранения этих проблем существует процесс разработки требований.
При разработке требований существует технический компромисс между слишком неопределёнными требованиями и требованиями столь детализированными, что они:
* требуют много времени для разработки, иногда даже рискуют устареть к концу разработки;
* ограничивают возможные способы реализации;
* являются слишком дорогостоящими.
3 ПРОЕКТИРОВАНИЕ
Рабочее окружение и связи между ним и системой
3.1Опорные точки зрения
На этапе формирования требования для робота учувствует группа людей состоящая из:
1. Администраторы баз данных - отвечают за поддержку данных в актуальном состоянии. 2. Администраторы сети - отвечают за каналы связи.
Данные и управляющая информация.
РазработчикУправляющие данныеВходные данныеОбъявление новых методов
Поиск последних измененийНазвание метода, описание функционала. Название изменяемого раздела.
ПользовательУправляющие данныеВходные данныеПоиск информацииНеобходимые данные
АдминистраторУправляющие данныеВходные данныеПроверка версий действующего ПО
Время последний действий разработчика и тестировщикаНазвания ПО
Имя разработчика, имя тестировщика.
ТестировщикУправляющие данныеВходные данныеДата дедлайна Версия продукта
Сценарии событий
Регистрация бота
2.3 Спецификация требований см. Приложение 1 "Спецификация требований"
Проектирование программного обеспечения - этап жизненного цикла программного обеспечения, во время которого исследуется структура и взаимосвязи элементов разрабатываемой системы. Результатом этого этапа является прежде всего документ (набор документов), содержащий(е) в себе достаточное количество информации для реализации системы.
На этапе проектирования уточняется функциональная спецификация системы: прорабатывается архитектура системы, определяются требования к аппаратному обеспечению. Также определяется набор организационных мероприятий, необходимых для внедрения системы, и перечень документов, регламентирующих ее использование. В дальнейшем на всех этапах реализации проекта происходит разработка указанных документов и утверждение их Заказчиком.
На основе результатов этапа анализа и сбора требований, специалистами нашей компании осуществляется объектно-ориентированное проектирование системы. Это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической, физической, а также статической и динамической моделей системы.
Этап проектирования осуществляется в тесном взаимодействии с сотрудниками Заказчика. На данном этапе нами широко используется имеющийся опыт создания систем - вырабатываются проектные решения, связанные с выбором платформ и технологий, на основе которых будет функционировать система, языка (или комбинации) языков реализации, определяются требования к пользовательскому интерфейсу, выбирается наиболее подходящая СУБД (если это необходимо) и т.д.
3.1 Проектирование архитектуры 3.2 Проектирование интерфейса
Интерфейс программы будет просто и интуитивно понятен, все кнопки будут иметь стандартный, привычный пользователю вид, что гарантирует простоту и удобство
РАЗДЕЛ 4
4.1. Выбор языка программирования
Выбор языка программирования не занял много времени. На мои взгляд , в реализации данного программного продукта наиболее рациональным было бы использовать C++.
C++ - компилируемый статически типизированный язык программирования общего назначения.
Поддерживает такие парадигмы программирования как процедурное программирование, объектно-ориентированное программирование, обобщённое программирование, обеспечивает модульность, раздельную компиляцию, обработку исключений, абстракцию данных, объявление типов (классов) объектов, виртуальные функции. Стандартная библиотека включает, в том числе, общеупотребительные контейнеры и алгоритмы. C++ сочетает свойства как высокоуровневых, так и низкоуровневых языков. В сравнении с его предшественником - языком C, - наибольшее внимание уделено поддержке объектно-ориентированного и обобщённого
РАЗДЕЛ 5
Верификация и аттестация ПП- это процессы проверки анализов, в ходе которых проверяется соответствие ПП со своей спецификацией требований. Верификация и аттестация использует два вида процессы: инспектирование и тестирование.
5.1. Инспектирование Инспектирование программ - это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованcbcного процесса проверки программ была сформулирована корпорацией IBM в 1970-х годах. В настоящее время данный метод верификации получил широкое распространение. На его базе разработано множество других методов, но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы. Главное отличие инспектирования от других методов оценивания качества программ состоит в том, что его цель - обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в исходном коде, либо несоответствия программы стандартам.
Процесс инспектирования - формализованный. В нем принимает участие небольшая группа людей (обычно не более, чем четыре человека). У каждого в группе есть своя роль. Обязательно должны присутствовать: автор, рецензент, инспектор, координатор. Рецензент "озвучивает" программный код, инспектор проверяет его, координатор отвечает за организацию процесса. По мере накопления опыта инспектирования в организациях могут появляться другие предложения по распределению ролей в группе (например, одно лицо может исполнять несколько ролей, поэтому количество членов в группе инспектирования может варьироваться).
5.2. Тестирование
Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов - это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
1) Надёжность
2) Сопровождаемость
3) Практичность
4) Эффективность
5) Мобильность
6) Функциональность
Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.
Тестирование проводилось при помощи метода "Чёрного ящика"
Метод "черного ящика": приложение (его законченная часть) анализируется как целое. Этот метод используется для проверки того, что приложение (его часть) отвечает предъявляемым требованиям.
Определение координат в зависимости от движения (расположения) основного окна верное. На вход подавалось изображение, на выходе мы получали координаты нужного модуля ПРИЛОЖЕНИЕ 1
СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
1.1 Назначение
Эта спецификация требований к ПО описывает функциональные и нефункциональные требования к системе "Кассир". Этот документ предназначен для команды, которая будет реализовывать и проверять корректность работы системы. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритет..
1.2 Соглашения, принятые в документах
Универсальная общественная лицензия GNU
1.3 Предполагаемая аудитория и рекомендации по чтению
Основная аудитория: фанаты ФК "Зенит", болельщики , любители футбола
Последовательность чтения-любая, компоненты текста независимы
Документ следует читать при ярком освещении.
2 Общее описание
2.1 Общий взгляд на продукт
Происхождение и содержание находиться в документе ЛР № 2. 2.2 Особенности продукта
Продукт не является уникальным и призван оставить конкуренцию уже существующим программам.
2..3 Классы и характеристики пользователей
Класс пользователейописаниеРазработчик Сотрудник постоянно улучшающий алгоритмАдминистраторОтветственен за работоспособность системы и обновление данныхТестировщикТестирует работу разработчика, ведёт анализ статистических данных. 2.4 Операционная среда
Программный продукт может быть на любой ОС
2.5 Ограничения дизайна и реализации
Ограничения-1. Система должна быть проста и интуитивно понятна.
2.6Документация для пользователей
Система должна предоставлять минимальный технический мануал с описанием действий по тестированию ОС, написанный для профессионалов, если такой не представляется возможным, дать ссылки на мануалы описывающие работу под интерфейсов сторонних приложений.
2.7Предположения и зависимости
1. Разработчик и администратор свободно разбираются в предметной области.
2. Система предназначена для массового использования
3. функции системы
3.1 Ведение статистики и тестирование 3.1.1 Описание и приоритет
Разработчик, идентификация которого подтверждена, может выбирать тестируемую машину (находящуюся в ЛС) и набор тестов. Отправлять тесты, получат сформированные ответы по данным тестам.
Приоритет - высокий
3.1.2 Функциональные требования
ВоздействиеРеакцияПросмотр информации о машинах и тестахСистема должна позволять редактировать
информацию о машине и тесте
ТестированиеПрогон по шаблонам уязвимостей
Запись результатов и статистикиЗапись в принятом виде в БД
3.2.1 Описание и приоритет
Разработчик, идентификация которого подтверждена, может выбирать тестируемую машину (находящуюся в ЛС). Вручную с использованием стороннего ПО или эмпирическим путём проверить целевую машину, на наличие уязвимостей.
3.2.2 Функциональные требования
ВоздействиеРеакцияВыбрать тестируемую
машину
Список машин в ЛС
Узнать свойства
тестируемой машины
Выдать программные характеристики и
комментарии
Послать запросРезультат выполнения запроса
4. Требования к внешнему интерфейсу
4.1. Интерфейсы пользователя
1. Внешний вид должен содержать максимум информации, без отвлекающих элементов
2. Интерфейс рассчитан на не профессиональных пользователей
4.2 Интерфейсы оборудования
Протокол взаимодействия описан в лицензии GNU.
4.3Интерфейсы передачи информации
Non-Zero Dispersion Shifted Single Mode Fiber - Одномодовое волокно с ненулевой смещённой дисперсией.
5. Другие нефункциональные требования
5.1 Требования к производительности
Минимальные системные требования
360 двухъядерных Opteron с 2,88 Тб ОЗУ
720 ядер PowerXCell с 2,88 Тб ОЗУ
12 System x3655 с двумя 10 Гбит-Ethernet каждый
288-портовый маршрутизатор Voltaire ISR2012 с 192 Infiniband 4x DDR (180 TriBlade и 12 узлов ввода-вывода)
Система должна иметь возможность атаки мощной машины, рассчитанной на защиту от нагрузочных взломов (Возможно использование дополнительного кластера или удалённых DDOS-клиентов)
5.2 Требования к охране труда
В случае возникновения попыток локального взлома, двухфазные или двухступенчатые взрывные устройства, в которых последовательно развиваются два физических процесса, локализованных в различных областях пространства приведут в действия боеголовку в размере более 18 мегатонн в тротиловом эквиваленте
5.3Требования к безопасности
Доступ к предоставлен только ограниченному кругу пользователей находящихся в одном помещении. Помещение должно быть оформлено и представлено как бомбоубежище II категории
5.4Атрибуты качества ПО
Если при прохождение автоматического тестирования выполнение теста было прервано/отклонено/завершено с ошибкой, то есть возможно записи вышеуказанного теста с перечислением данных параметров: название теста, причина завершения, время завершения и автоматического повтора данного теста (с фиксированным количеством повторов).
2
Документ
Категория
Без категории
Просмотров
110
Размер файла
137 Кб
Теги
poyasnitelnaya, zapiska
1/--страниц
Пожаловаться на содержимое документа