Методические указания (2). 1 Цели и задачи курсовой работы
 Скачать 141.62 Kb.
|
|
5 Порядок подготовки и защиты курсовой работы В установленный учебным графиком срок каждому студенту выдается для ознакомления с заданием на выполнение методическое руководство по выполнению курсовой работы. Для этого перед непосредственной проверкой руководителем КР на предмет выполнения задания КР и соответствия требованиям, предъявляемым к КР, каждый студент передает преподавателю архив с электронной версией КР, который включает: отчет (файл в формате doc, название файла: год_группа_Фамилия_И_О) и файлы проекта. Если проверка пройдена, то далее студент сдает руководителю КР на проверку бумажную версию КР. Каждая проверенная КР содержит в рецензии результаты проверки преподавателем КР. Если рецензия содержит допуск к защите КР, то далее студент готовиться защищать полученные результаты и теоретические знания по предметной области КР. Иначе доработать КР по представленным замечаниям и сдать повторно на проверку до тех пор, пока не будет получен допуск. Результаты защиты курсовой работы оцениваются по пятибалльной системе оценки («отлично», «хорошо», «удовлетворительно», «неудовлетворительно»). Во время защиты курсовой работы студенту задаются вопросы преподавателем. Студент должен продемонстрировать работоспособность своего программного обеспечения. Итоговая оценка за защиту курсовой работы определяется: «отлично» - если разработанная программа полностью функционирует и включает все заданиям КР, составлен отчет согласно требованиям к оформлению и дан ответ 5 вопросов; «хорошо» - если разработанная программа оценена не ниже «хорошо», составлен отчет согласно требованиям к оформлению и дан ответ на 4 вопроса; «удовлетворительно» - если разработанная программа оценена на «удовлетворительно», в оформление отчета имеются недочеты и дан ответ на 3 вопроса; «неудовлетворительно» - если не выполнены условия получения положительной оценки. 6 Задание и выбор варианта курсовых работ Необходимо разработать программное обеспечение для работы с файлами и устройствами ввода/вывода, а также для мониторинга ресурсов. Задание курсовой работы состоит из следующих основных пунктов: Проектирование программного обеспечения. Разработка графического интерфейса. Разработка программного обеспечения. Обеспечение минимального функционала. Добавление основного функционала. Выбор стратегии тестирования и разработка тестов. Формирование отчета по курсовой работе. Варианты заданий: 1. Способ межпроцессного взаимодействия «Файлового менеджера» и всплывающего окна - Отображение файлов. 2. В разрабатываемом приложение должен присутствовать терминал Linux и иметь следующий набор: сетевые команды и команды для работы с файловой системой - для четных номеров зачетной книжки; команды управления процессами и команды для работы с устройствами ввода/вывода – не четные. 3. Основной функционал для «Файлового менеджера» распределяет по списку группы: имя компьютера; имя пользователя; версию операционной системы; имя процесса; использованное время ЦП; процент используемой физической памяти; процент используемой виртуальной памяти; PID процесса; приоритет процесса; пользователь процесса; текущее местное время; продолжительность текущего сеанса работы; загрузка каждого ядра ЦП в %; общая загрузка процессора в %; размер файла подкачки в байтах; количество свободных байтов файла подкачки; ширину и высоту рамки окна; ширину и высоту экрана; значение загрузки процессора данным процессом; количество модулей, используемых процессом; размер рабочего множества страниц; завершение прикладного процесса, выбранного из списка; счетчик количества созданных описателей (дескрипторов); маска привязки процесса к процессорам; количество страничных ошибок; изменение приоритета выбранного процесса; время старта процесса (час: мин: сек); количество потоков процесса; значение размера используемой оперативной памяти; пиковое значение размера используемой виртуальной памяти; обнаружение фактов создания файлов; обнаружение фактов создания каталогов; обнаружение фактов переименования файлов; обнаружение фактов переименования каталогов; для процесса, выбранного с помощью ввода его PID, вывести список его дочерних процессов (имя процесса, PID, время работы в системе); вывод в текстовый файл списка процессов, завершивших выполнение в период работы монитора; для прикладного процесса, выбранного в списке выполняющихся процессов, вывести список его потоков с указанием свойств каждого потока. Пояснение Задание 1. Проектирование «Файлового менеджера». Включает в себя: выбор средств разработки и среды разработки, сделать сравнительную таблицу по ним. Подключаемые внешние библиотеки, их описание. Задание 2. Разработка графического интерфейса. Сделать эскиз графического интерфейса. Дать описание каждой форме и объектам ПО. Как данные объекты определяются языком программирования. Для создания интерфейса допускается только специализированное ПО или MSVisio. Задание 3. Разработка ПО. Разрабатывается приложение «Файловый менеджер» под любую версию ОС Linux. Можно использовать предпочтительный язык программирования. Создается корневая папка как среда работы «Файлового менеджера» (в менеджере отображаются только вложенные папки). Создать папку «Корзина» аналогичная ОС. Обеспечить удаление в корзину и безвозвратно. Создается папка «System», содержит все необходимые файлы (исполняемые) для работы файлового менеджера (ее удалить, переименовать или переместить нельзя). Так же создаются рабочие папки (произвольные). Защитить папку «System» от удаления/переименования (рис. 1). Сделать основное и контекстное меню (аналогичные вашей операционной системы). В основное меню добавить пункт «О программе» - Операционные системы и оболочки, Язык программирования, ФИО и группа разработчика. Скриншоты из среды разработки обязательны, так же сделать к ним пояснения.  Рис. 1 – Иерархия папок в приложение Задание 4. Обеспечение минимального функционала. Позволить через приложение запуск встроенных системных утилит ОС. Утилиты - программы, служащие для выполнения вспомогательных операций обработки данных или обслуживания компьютеров (диагностики, тестирования аппаратных и программных средств, оптимизации использования дискового пространства, восстановления разрушенной на магнитном диске информации и т.п.). В Linux это Терминал, Управление компьютером, Монитор ресурсов и т.д. Добавить в программу поддержку горячих клавиш, не менее 5. Информацию по горячим клавишам внести в пункт меню «Справка». Добавить функцию поиска файлов и папок во вложенных папках файлового менеджера. Скриншоты из среды разработки обязательны, так же сделать к ним пояснения. Сделать подробное описание всех обработчиков событий. Задание 5.Добавление основного функционала. С помощью приложения обеспечить возможность создания нового процесса (всплывающее окно), которое будет в дальнейшем отображать информацию основного функционала (или части его). Главное окно получает необходимую информацию и передает ее, по средствам межпроцессного взаимодействия всплывающему окну (из п.3. Основной функционал). Всплывающее окно зависит от главного окна. Добавить возможность сохранение полученных данных в файл (лог-файл). Разработать командный интерпретатор Терминал Linux с набором команд согласно варианта, не меньше5 команд. Терминал Linux должен запускаться из основной формы и иметь консольный вид. Добавить справку по командам. Лог-файл – это текстовый файл, в котором хранится информация о посещениях и параметрах посещений Файлового менеджера, которые возникали на нем. Скриншоты из среды разработки обязательны, так же сделать к ним пояснения. Сделать подробное описание всех обработчиков событий. Составить функциональную блок-схему и UML-диаграмму. Для задания алгоритмов можно использовать их графическое представление с помощью схем, которые должны выполняться в соответствии со стандартами. Для увеличения наглядности схема не должна содержать более 50 блоков. Отображение файлов (File Mapping). Механизм отображения файлов позволяет процессу трактовать содержимое файла как блок памяти в адресном пространстве этого процесса. Процесс может использовать обычные операции с указателями для того, чтобы считывать и изменять содержимое файла. Когда два или более процесса получают доступ к одинаковым отображениям файлов, то каждый процесс получает указатель на память в собственном адресном пространстве, которое он может использовать для модифицирования содержимого файла. Отсюда следует, что процессы также должны использовать объект синхронизации, например семафор, чтобы предотвратить разрушение данных в многозадачной среде. Программист может использовать специальный вид отображения файла для обеспечения именованной разделенной памяти между процессами. Если при создании объекта-отображения файла указывается файл подкачки системы (swappingfile), то отображение файла создается как блок совместно используемой памяти. Другие процессы также могут получить доступ к этому блоку, открыв такое же отображение файла. Отображение файлов вполне эффективно, и, кроме того, предоставляет поддерживаемые операционной системой атрибуты безопасности для того, чтобы помочь предотвратить несанкционированный доступ к данным. Механизм отображения файлов может быть использован процессами, работающими только на локальном компьютере; он не используется для передачи данных по сети. Задание 6. Выбор стратегии тестирования и разработка тестов. Стратегия тестирования - это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования. Стратегия тестирования отвечает на вопросы: как, каким образом тестирование даст ответ, что данный функционал работает; что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования; когда определённый функционал будет тестироваться и когда ожидать получения результатов. Тестирование программного обеспечения (ПО) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Для оптимизации набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале времени, отведенном на тестирование) обнаруживать большее число ошибок в ПО, необходимо, во-первых, заранее планировать этот набор и, во-вторых, использовать рациональную стратегию планирования тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПО. Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но ближе к левому краю. Она включает проектирование значительной части тестов по спецификациям, но она требует также проектирования некоторых тестов и по текстам программ. При этом в первом случае эта стратегия базируется на принципах: на каждую используемую функцию или возможность - хотя бы один тест; на каждую область и на каждую границу изменения какой-либо входной величины - хотя бы один тест; на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест. Рассмотрим подробнее методики тестирования «чёрный ящик» и метод тестирования «белый ящик». Метод тестирования «чёрный ящик». Долгое время основным способом тестирования было тестирование методом «черного ящика» - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия. При этом, как именно работает программа, считается несущественным. Отметим, что даже при таком подходе необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать результаты. Этот подход до сих пор является самым распространенным в повседневной практике, но у него есть целый ряд недостатков. Во-первых, таким способом невозможно найти взаимоуничтожающихся ошибок, во-вторых, некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести. Метод тестирования «белый ящик». Метод тестирования, которые изучают не только внешнее поведение программы, но и ее внутреннее устройство (исходные тексты). Такие методики обобщенно называют тестированием «белого ящика». Назовем некоторых представителей этого класса методик: чтение программ, формальные просмотры программ, инспекции и т.п.). Основной трудностью подобных методов является сложность отслеживания вычислений времени выполнения. При тестировании программы методом «белый ящик» происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ числом таких путей может достигать десятков тысяч. Критерии тестирования. Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы целенаправленный подбор тестов. Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения каждого оператора программы. Более сильным критерием является критерий: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Изучение этих методов тестирования показывает, что они дополняют друг друга, то есть различные методы находят разные ошибки. Поэтому наиболее эффективные процессы разработки программного обеспечения используют некоторую комбинацию методик "черного ящика" и "белого ящика". Теперь проведём тестирование созданного программного продукта «Файловый менеджер». Для тестирования приложения была выбрана комбинация методик «черного ящика» и «белого ящика». Протестируем основные функции программы, а это: открытие файлов, копирование файлов, перемежение файлов, удаление файлов, создание новых каталогов. Необходимо для начала создать сами тест-требования, которые будут содержать: требование, ожидаемый результат, конечный результат, описание ошибок (если имеются). Образец для заполнения приведен в табл. 1. Таблица 1 Образец для заполнения тест-требований
Результаты тестирования приложения видим в табл. 2. Ниже приведены критерии тестирования программного продукта: 1. Значения исходных данных (во всех функциях ПС исходные данные-объекты файловой системы компьютера) - исходные данные отображаются в программе «Файловый менеджер» верно. 2. Ожидаемый результат - выполнение соответствующих функций ПС над объектами файловой системы компьютера. 3. Реакция программы - предупреждение об ошибках, совершаемых пользователем при выполнении функции программы. Если ошибок не обнаружено, то приступает к выполнению соответствующих функции приложения. 4. Проверка правильности работы функций приложения с помощью проводника Linux. 5. Возникаемые ошибки и их описание. Таблица 2 Результаты тестирования приложения
Следует отметить, что, тестирование не может доказать правильность работы ПО, в лучшем случае оно может продемонстрировать наличие в нем ошибки. Другими словами, нельзя гарантировать, что тестированием ПО практически выполнимым набором тестов можно установить наличие каждой имеющейся в программе ошибки. По итогам проведённого тестирования приложения комбинацией методик черного и белого ящика все тесты были пройдены успешно. Следовательно, приложение не причиняет вреда объектам файловой системы компьютера и может быть использовано пользователями. В отчете привести составленные тест-требования и ожидаемые результаты. Задание 7. Формирование отчета по курсовой работе. Оформление отчета по требованиям и отправка его на проверку. Назначается дата и время защиты. |