Этапы курсового проектирования
Работа над курсовым проектом может быть разбита на ряд этапов:
1. Исследование предметной области. Анализ поставленной задачи, отработка всех нюансов, уточнение исходных условий. Результатом должно стать ясное и глубокое понимание сущности поставленной задачи. Процесс анализа сопровождается созданием диаграмм Use Case на UML. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй.
2. Проектирование системы в целом, в терминах естественного языка. Именно на этом этапе должна быть продумана структура и функциональные возможности будущего программного продукта. Уже на этом этапе может быть спроектирован интерфейс, определяющий функциональные возможности ПП. Определяются цели и критерии будущего ПП. Выполняется структурирование задачи на подзадачи, моделируется схема управления между подзадачами, осуществляется декомпозиция на модули. На этом этапе необходимо: сформировать диаграмму связей (mind map) - графическую схему взаимодействия объектов (модулей, страниц и т.д.) проектируемого ПО; произвести прототипирование основных экранных форм (например с использованием одного из онлайн сервисов: www.ninjamock.com, www.moqups.com); выбрать архитектуру разрабатываемого ПО (автономные, двух-звенные, многозвенные, CORBA, SOA, REST и т.д.), сформировать графическую схему, описать её структуру и основные элементы; выбрать и обосновать выбор базы данных (исходя из модели данных) и СУБД, описать таблицы данных, структуру хранимых данных; исходя из обрабатываемых и хранимых данных в ПО, рассмотреть методы обеспечения информационной безопасности, особенно при хранении информации содержащей персональные данные пользователей.
3. Разработка ПО... На этом этапе происходит конкретизация определившейся на 2-м этапе структуры. Необходимо выбрать и обосновать выбор инструментальных средств разработки, средств хранения кода и т.д Этот этап требует хороших знаний выбранного инструментария разработки. В процессе программирования (или в условиях объектно-ориентированного инструментарии – при моделировании) должны быть учтены следующие моменты
- определение приоритета целей (удобный пользовательский интерфейс или эффективность программ по времени, или использование памяти и пр.)
- использование идей защитного программирования, блокировка и прогнозирование ошибок;
- соблюдение хорошего стиля программирования (имена, листинги и пр.).
4. Тестирование и отладка ПП. Необходимо выбрать метод проверки качества (ручное/автоматизированное тестирование, интеграционное, нагрузочное, функциональное, A/B тестирование), обосновать выбор. Необходимо спроектировать тестовые варианты, т.е. информационное содержание всех файлов (Б.Д.) , данных интерактивого ввода, значения логических переменных, и т.д. - что обеспечивает прослеживание всех логических цепочек и охватывает все возможные и даже исключительные, экстремальные ситуации. Предусмотреть как структурное тестирование («белого ящика»), так и функциональное тестирование («черного ящика»). Для функционального тестирования использовать диаграммы причин-следствий, позволяющие наиболее полно учесть все возможные функциональные особенности созданного программного продукта. Выявленные ошибки необходимо фиксировать, так как количественная информация об ошибках используется в метриках оценки созданного программного продукта.
5. Комплексная отладка, опытная эксплуатация созданного ПП.
6. Расчет функциональности созданного программного проекта на основе функциональных точек (FP) с учетом коэффициентов регулировки сложности Fi.
7. Расчет метрик программного проекта (производительность, качество) на основе рассчитанного значения FP (пункт 6).
8. Написание пояснительной записки. Пояснительная записка должна в полной мере отражать суть, процесс, средства и результаты решения задачи, должна содержать все описания, таблицы, структуры, исходные тексты программ, выходные документы; должна быть грамотно и четко составлена в соответствии со стандартами оформления текстовой информации..
9. Защита курсовой работы. Демонстрируется созданный программный продукт, проверяется пояснительная записка. Возможна организация публичной защиты курсовых работ.
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
Курсовая работа не только должна быть содержательной и самостоятельной, но и должна быть правильно оформлена.
Примерный план пояснительной записки:
ВВЕДЕНИЕ
1. Анализ и формирование требований к ПО
2. Проектирование программного обеспечения
2.1 Архитектура и структура проектируемого ПО
2.2 Информационная модель
3. Разработка программного обеспечения
3.1 Инструментальные средства разработки ПО
3.2 Описание ПО
3.3 Руководство пользователя
3.4 Тестирование ПО
4. Информационная безопасность
5. Расчет метрик
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЯ
ВВЕДЕНИЕ
Рекомендуется охарактеризовать существующие технологии программирования, дать анализ возможных применений стратегий и моделей конструирования ПП, показать актуальность поставленной задачи.
1.Анализ и формирование требований к ПО содержит суть поставленной задачи, логику получения основных выходных данных, анализ предметной области. Определяются наиболее важные для заказчика требования к:
- функциональности создаваемого программного обеспечения;
- сценариям использования проектируемого ПО;
- дизайну;
- портрету пользователя.
Производится тщательное исследование предметной области. Инструментарием исследования выступает унифицированный язык визуального моделирования UML, с помощью которого строятся диаграммы Use Case. Анализ всех вариантов использования позволит достаточно хорошо исследовать предметную область.(см. пункт 1.2 «Этапы курсового проектирования»).
2. Проектирование программного обеспечения состоит из двух подразделов:
2.1 «Архитектура и структура проектируемого ПО» - необходимо выбрать и описать архитектуру разрабатываемого ПО (автономные, двух-звенные, многозвенные, CORBA, SOA, REST и т.д.), сформировать графическую схему взаимодействия объектов (модулей, страниц и т.д.) проектируемого ПО, описать её структуру и основные элементы. Показать возможности применениия прототипирования основных экранных форм.
2.2 «Информационная модель» для задач обработки информации является ключевым пунктом, позволяющим понять суть задачи, полноту и эффективность ее решения. Информационная модель предполагает полный анализ входной, выходной информации.
Необходимо выбрать и обосновать выбор базы данных (исходя из модели данных) и СУБД, описать таблицы данных, структуру хранимых данных. Привести информационную модель в виде ER-модели. Исходя из обрабатываемых и хранимых данных в ПО, рассмотреть методы обеспечения информационной безопасности, особенно при хранении информации, содержащей персональные данные пользователей.
В зависимости от тематики курсовой работы этот пункт может быть расширен за счет более полного описания входной и выходной информации.
Входная информация. Необходимо представить входную информацию, включая первичные документы; описать, кто, когда и как их заполняет, какая информация из них участвует в решении задачи. Далее необходимо представить структуры созданных файлов или баз данных, а также дать пояснения к созданным структурам
Выходная информация. Необходимо представить перечень выходных документов, их содержание, структуру, порядок выдачи. Листинги выходных документов можно привести в Приложении, на которое можно ссылаться. Надо описать запросы, т.е. информацию, получаемую в результате интерактивного диалога с пользователем. Сюда же можно отнести различную информацию справочного характера, сообщения об ошибках, информацию о ходе выполнения программы и т.п
3. Разработка программного обеспечения должна быть описана подробно. Оформление программного текста, описания программы, описание применения программы должно выполняться в соответствии с соответствующими стандартами
В «Инструментальных средствах разработки ПО» необходимо обосновать выбор инструментальных средств разработки, средств контроля версионности, средств хранения кода и т.д.. Показать, какие средства и приемы использовались для повышения надежности и качества разработки программного продукта.. Дать краткую характеристику и принципы работы используемой системы программирования, системы управления базами данных и т.д. Обосновать выбор данного инструментария.
В пункте «Описание программного продукта» необходимо привести внешнюю структуру программного продукта (структуру интерфейса, показывающую, как выглядит программный продукт с точки зрения пользователя), а также внутреннюю структуру (взаимодействие отдельных модулей, объектов); привести характеристику отдельных составляющих (модулей, процедур, объектов). Необходимо представить внутреннюю структуру пакета, т.е. взаимодействие отдельных модулей, объектов. Целесообразнее всего представить структуру в виде компонентной диаграммы на UML, что покажет наиболее полно все составляющие программного проекта. Учитывая инструментарий разработки, дать характеристику модульной или объектно-ориентированной технологии программирования. Показать, какие средства и приемы использовались для повышения надежности программного продукта, для защиты от несанкционированного доступа, удобства эксплуатации. Необходимо привести характеристику отдельных составляющих (модулей, процедур, объектов). Т.к сами листинги программ приведены в Приложении, этот пункт можно рассматривать как комментарий к листингам, при этом обязательны конкретные ссылки на приложения.
В пункте «Руководство пользователя» необходимо в понятных пользователю терминах представить инструкцию по запуску и эксплуатации программного продукта, отразить необходимые ресурсы (память, требования к технике), отметить исключительные ситуации, пояснить возможные сообщения программы, показать функциональные возможности программного продукта. Вполне вероятно, что изложение материала данного пункта окажется в большой степени связанным с интерфейсом программного продукта, который, возможно, был описан ранее, поэтому ссылки на представленные ранее схемы и рисунки вполне уместны.
В пункте Тестирование ПОнеобходимо охарактеризовать выбранный метод проверки качества (ручное / автоматизированное тестирование, интеграционное, нагрузочное, функциональное, A/B тестирование), обосновать выбор; представить разработанные тест-кейсы проверки качества ПО; представить протокол тестирования (ошибки, исправление, итерационное тестирование). Показать принципы формирования тестовых вариантов для структурного и функционального тестирования. Проектирование тестовых вариантов для функционального тестирования осуществлять с использованием метода диаграмм причинно-следственных связей. Спроектированные диаграммы, таблицы обязательно привести в тексте пояснительной записки. Выявленные ошибки свести в таблицу:
Таблица 1 – Выявленные ошибки
| Ошибки проектирования | Ошибки кодирования | Синтаксические ошибки |
Показать, какие методы отладки использовались (аналитические, экспериментальные). Провести тестирование всех 4-х уровней – от тестирования элементов до тестирования системного. Показать возможности восстановления созданного ПП, результаты стрессового тестирования. Если подобные возможности не реализованы, указать предполагаемые проблемы эксплуатации созданного программного обеспечения. Результаты свести в таблицу произвольного формата.
4.«Информационная безопасность» отражает требования к информационной безопасности, а также средства и способы ее реализации. Описать средства аутентификации, авторизации, хранения паролей, шифрование и пр.
5.Расчет метрик
Целесообразно использовать функционально-ориентированные метрики для оценки процесса конструирования, для чего необходимо рассчитать функциональность созданного ПП с учетом коэффициентов сложности. Для расчета необходимо составить таблицы:
Таблица 2 – Расчет общего количества FP
| Модули | Информационные характеристики проекта | Кол-во методов (алгорит.) | Итого по модулю | ||||
| Вн.вводы | Выводы | Запросы | Внешн. файлы | Интерф. файлы | |||
| Всего: |
Таблица 3 - Исходные данные для расчёта указателя свойств
| № | Характеристика | Количество | Сложность | Итого |
| Вводы | ð | * 4 | = ð | |
| Выводы | ð | * 5 | = ð | |
| Запросы | ð | * 4 | = ð | |
| Логические файлы | ð | * 7 | = ð | |
| Интерфейсные файлы | ð | * 7 | = ð | |
| Количество алгоритмов | ð | * 3 | = ð | |
| Общее количество | = ð |
FP = Общее количество * (0,65 + 0,01 * ∑i=114 Fi),
где Fi – коэффициенты регулировки сложности.
Каждый коэффициент может принимать следующие значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное.
Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (таблица 4).
Таблица 4 - Определение системных параметров приложения
| № | Системный параметр | Описание |
| Передачи данных | Сколько средств связи требуется для передачи или обмена информацией с приложением или системой? | |
| Распределённая обработка данных | Как обрабатываются распределённые данные и функции обработки? | |
| Производительность | Нуждается ли пользователь в фиксации времени ответа или производительности? | |
| Распространённость используемой конфигурации | Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? | |
| Скорость транзакций | Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц) | |
| Оперативный ввод данных | Какой процент информации надо вводить в режиме онлайн? | |
| Эффективность работы конечного пользователя | Приложение проектировалось для обеспечения эффективной работы конечного пользователя? | |
| Оперативное обновление | Как много внутренних файлов обновляется в онлайновой транзакции? | |
| Сложность обработки | Выполняет ли приложение интенсивную математическую или логическую обработку? | |
| Повторная используемость | Приложение разрабатывается для удовлетворения требований одного или многих пользователей? | |
| Лёгкость инсталляции | Насколько трудны преобразование инсталляция приложения? | |
| Лёгкость эксплуатации | Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? | |
| Разнообразные условия размещения | Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? | |
| Простота изменений | Была ли спроектирована, разработана и поддержана в приложении простота изменений? |
Таблица 5 – Коэффициенты регулировки сложности
 Коэф. сложн. Системн. параметр | ||||||
| 1. | ||||||
| 2. | ||||||
| … | ||||||
| 14. | ||||||
| Всего: |
На основе найденного FP определяют производительность и качество проекта, причем трудозатраты (чел-час) тщательно учитываются во все время конструирования по всем этапам.
Производительность = ФункцУказатель / Затраты [FP / чел.-мес.];
Качество = Ошибки / ФункцУказатель [Единиц / FP];
Данные по трудозатратам также необходимо свести в следующую таблицу:
| Этап конструирования | Трудозатраты |
| Всего: |
Окончательные результаты необходимо свести в следующую таблицу:
| Трудозатраты | Кол-во ошибок | FP | Производительность | Качество |
ЗАКЛЮЧЕНИЕ
Дать анализ проделанной работы, отметить результаты и метрики конструирования, достоинства созданного ПП, возможности его развития, практического применения. Отметить приобретенный практический опыт.