СибГУТИ, технологии разработки программного обеспечения (контрольная работа)
| 21.05.2026, 11:22 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
СОДЕРЖАНИЕ И ЭТАПЫ ВЫПОЛНЕНИЯ КОНТРОЛЬНОЙ РАБОТЫ Контрольная работа по дисциплине "Технологии разработки программного обеспечения" предполагает решение конкретной практической задачи информатизации и содержит разработку рабочих проектных решений, связанных с созданием программного приложения с микросервисной архитектурой. Задание на КР: В соответствии с согласованной индивидуальной темой реализовать ПС в виде микросервисной архитектуры – логически разделить ПС на выполняемые задачи и для каждой задачи реализовать отдельный контейнер (или группу контейнеров) как законченное приложение. Обмен данными между микросервисами реализовать через WEB-API (запрос/ответ). В качестве средства контейнеризации использовать Docker. Рекомендуемая платформа web-разработки: Django. Рекомендуемая СУБД: PostgreeSQL. Содержание отчета к контрольной работе фактически представляет собой рабочий проект приложения на индивидуально выбранную тему. Наиболее приемлемым вариантом будет реализация программного приложения в контексте выполнения магистерской диссертации. Также возможно выполнение КР по новой теме предложенной студентом и согласованной с руководителем. По согласованию с руководителем возможна разработка и написание комплексных контрольных работ командой из нескольких студентов. Типовая тематика контрольного проектирования по дисциплине "Технологии разработки программного обеспечения" напрямую связана с областью научных исследований кафедры ММиЦРБС и представлена в разделе 3. В процессе выполнения КР студент обязан разработать программное приложение в соответствии с индивидуально поставленной задачей, для чего должен: - сформулировать функциональные требования к ПС и представить их в формальном виде; - осуществить обоснованный выбор средств разработки приложения: СУБД, платформы для web-разработки, языковых средств, средств управления программным процессом, в т.ч. конфигурированием и тестированием, и пр. - построить функциональные модели для решения задач информатизации и реализации отдельных микросервисов; - разработать диаграммы реализации (deployment diagrams UML) программного приложения; - выполнить установку и настройку ОС Linux для дальнейшего развертывания рабочей среды; - выбрать систему контроля версий и на ее базе создать репозиторий для проекта; - развернуть и настроить среду разработки программного приложения коллективным способом; - развернуть Docker Debian и сформировать контейнер для разработки приложения с микросервисной архитектурой; - разработать программные модули и интерфейсную часть приложения; - выполнить тестирование приложения и описать полученные результаты; - представить решения по развертыванию и дальнейшему сопровождению приложения; - оформить отчет и защитить КР в соответствии с действующими стандартами. Выполнение контрольной работы по дисциплине "Технологии разработки программного обеспечения" должно соответствовать утвержденному календарному графику и включает следующие этапы (таблица 2.1). Таблица 2.1. Календарный график выполнения контрольной работы
Более детальное описание структуры отчета к контрольной работе представлено в разделе 4. ТЕМАТИКА ПРОЕКТИРОВАНИЯ В соответствии с квалификационной характеристикой направления подготовки 09.03.01 "Информатика и вычислительная техника" возможны следующие основные направления тематики контрольных работ по дисциплине "Технологии разработки программного обеспечения" (см. табл. 3.1) Таблица 3.1. Тематика разработки ПС
ТРЕБОВАНИЯ К СТРУКТУРЕ КОНТРОЛЬНОЙ РАБОТЫ Результаты выполнения контрольной работы оформляются каждым студентом в виде отчета. Отчет содержит весь проектный материал по созданию ПС, представленный в виде текста, расчетных формул, таблиц, рисунков и др. Типовая структура отчета следующая: - титульный лист типовой формы; - задание на контрольное проектирование на типовом бланке; - реферат; - содержание; - введение; - основная часть, состоящая из нескольких разделов; - заключение; - перечень ссылок; - приложения. Задание на КР размещается сразу после титульного листа и является документом, который определяет объем и порядок выполнения работы, регламентирует исходные данные, функциональные требования к ПС и основные результаты проектирования. Задание утверждается руководителем КР. Реферат предназначен для ознакомления с проектом. Он должен быть коротким, информативным и содержать сведения, которые позволяют представить сущность КР. Реферат должен содержать: - библиографическое описание КР; - текст реферата; - перечень ключевых слов. Библиографическое описание содержит сведения об объеме отчета, количество иллюстраций, таблиц, приложений, а также количество источников в перечне ссылок. Это описание выполняется согласно требованиям действующих стандартов по библиотечному и издательскому делу и имеет такой вид: Контрольная работа: стр., рис., табл., прил., ист. При этом сведения приводятся с учетом всех приложений. Текст реферата должен отображать информацию, представленную в отчете и, как правило, в определенной последовательности: - объект разработки или исследования; - цель работы; - методы и средства разработки; - результаты работы; - основные технико-эксплуатационные, конструктивные и технологические характеристики; - значимость работы и выводы. Части реферата, сведения о которых отсутствуют, не приводят. Объем реферата не более 850 знаков. Реферат располагается на одной странице формата А4. Ключевые слова, существенные для раскрытия сути КР, размещают после текста реферата. Перечень ключевых слов содержит от 5 до 15 слов (словосочетаний), напечатанных прописными буквами в именительном падеже в строку через запятые. Лист реферата выполняется с основной надписью. Содержание располагают после реферата, начиная с новой страницы. Содержание включает: - введение; - последовательно перечисленные названия всех разделов, подразделов; - заключение; - перечень использованных источников; - последовательно перечисленные приложения с заголовками. В содержании указываются номера страниц, на которых расположено начало соответствующего материала. Нумерация страниц в отчете сквозная, начинается с титульного листа, но номера страниц проставляются, начиная с содержания. Перечень условных сокращений и аббревиатур располагают на отдельной странице. В перечне в виде списка пересчитываются обозначения и сокращение, использованные в тексте ПО, а через короткое тире по правую сторону приводится их расшифровка. Введение отчета должно содержать оценку современного состояния и актуальности решаемой задачи, краткое описание используемых методов и средств решения задачи, цель работы и область ее применения. Введение располагается с новой страницы. Основная часть отчета должна включать следующие разделы: 1. Характеристика объекта информатизации. 2. Техническое задание на создание приложения. 3. Функциональная структура приложения. 4. Формирование среды разработки приложения. 5. Программная реализация приложения. 6. Тестирование приложения. 7. Развертывание приложения. Примерный объем отчета 30 – 50 страниц без учета приложений. В разделе 1 приводится дается краткая характеристика предметной области. Приводится подробная информация о структуре объекта информатизации, выполняемых функциях и решаемых задачах. Особо выделяется бизнес-процесс, подлежащий информатизации (процесс информатизации), дается его определение, формулируется цель (процесса, а не информатизации), приводятся правила организации и возможные ограничения. Описание должно давать представление о масштабе деятельности объекта, численности персонала, занятого в бизнес-процессе, характере взаимодействия с другими подразделами и задачами. В данном разделе необходимо разместить иллюстрацию, характеризующую объект и процесс информатизации. Это может быть какая-либо модель, формально представляющая объект, функционально-структурная схема, организационная диаграмма и т.п. В разделе 2 приводится описывается назначение разрабатываемого продукта (ПС) и цели его создания. При описании назначения указывают вид деятельности, которая автоматизируется (расчет, управление, диагностика, планирование, прогнозирование, проектирование и т.п.) и перечень объектов информатизации, на которых предполагается ее использовать. При описании цели создания продукта приводят наименование и необходимые значения технических, технологических, производственно-экономических или других показателей объекта информатизации, которые должными быть достигнуты в результате создания ПС, и указывают критерии оценки достижение указанных целей. Указывается перечень задач и автоматизируемых функций ПС, их назначение, основные характеристики. Приводятся требования к режимам функционирования ПС в целом и по отдельным задачам (функциям), разбивается на несколько пунктов в зависимости от количества задач (функций), например: 1 Требования к задаче (или функции) “...” 2 Требования к задаче (или функции) “...” 3 Требования к задаче (или функции) “...” В каждом пункте указывается полное название задачи, функции или отдельной задачи. Надо помнить, что задача ПС – это функция или часть функции ПС, являющаяся формализованной совокупностью действий, выполнение которых приводит к результату заданного вида. Поэтому в качестве задач надо выбирать такие, для которых можно четко сформулировать результат. Такими задачами, например, могут быть задача введения входных данных, задача формирования статистической отчетности, задача диагностики состояния объекта, задача анализа данных и принятия решений и др. Кроме того, указывают нефункциональные требования к ПС (не менее пяти), отражающие её качественные характеристики согласно ГОСТ Р ИСО/МЭК 9126-93. Также предъявляются требования к обеспечивающим подсистемам ПС: - требования к организации данных, которые должны храниться в ПС, включая основные сущности БД, уместно представить диаграмму классов UML или логическую модель данных; - требования к составу, области применения (ограничение) и средств использования в системе математических методов и моделей, типичных алгоритмов и алгоритмов, которые подлежат разработке; - требованиях к программному обеспечению (ПО), в том числе к операционной среде, к инструментальным средствам разработки ПС и управления её жизненным циклом, к составу и функциям специального ПО, подлежащему разработке; - требованиях к техническому обеспечению, а именно к конструктивным и эксплуатационным характеристикам средств ТО ПС, к конфигурациям компьютеров серверов и клиентских устройств. При формулировании требований к обеспечивающим подсистемам необходимо учитывать, что эти требования обусловленные спецификой задач, которые решаются в ПС, и требованиями к другим частям ПС. В разделе 3 приводятся проектные решения по функциональной структуре ПС согласно требованиям к задачам (функциям) ПС, приведенным в разделе 2. Приводится краткое (не более 100 слов) описание процесса функционирования объекта информатизации в условиях функционирования ПС. Составляется описание процессов выполнения каждой задачи (функции). Выделяются существенные структурные элементы и действия, определяются связи между ними. Уместно построить функционально-структурную схему ПС в виде диаграмм поведения UML. Представить структурную схему микросервисной архитектуры ПС по принципу: «одна задача – один сервис». В разделе 4 отражается обоснованный выбор программного средства для разработки специального ПО. Это должен быть какой-либо фреймворк для создания web-приложения или WEB-сервер с PHP. Отражается установка выбранных СУБД и фреймворка для создания сервисов web-приложения, установка и настройка Docker Debian. Также отражается создание репозитория проекта ПС для осуществления версионного контроля проекта (может быть использована любая система контроля версий: Microsoft Visual SourceSafe, IBM ClearCase, CVS, Subversion, Perforce, Git, Mercurial, Bazaar, Darcs и др.; рекомендуемая система управления версиями – Git), создание инициализирующего коммита, размещение в репозитории созданного проекта приложения. Все шаги документируются иллюстрациями и краткими их комментариями. В разделах 5 и 6 рассмотреть первую половину этапов цикла DevOps – CD: «Написание кода», «Сборка», «Тестирование». В разделе 5 отражается процесс рабочего проектирования (реализации) ПС: создание БД, образа для реализации приложения, разработка и контейнеризация web-приложения посредством Docker с обеспечением логирования http-подключений (время подключения, IP-адрес клиента), размещение текущей версии проекта в удаленном репозитории Git. Примерная структура раздела: - основные файлы приложения (при использовании Django – urls.py, models.py, settings.py); - код, реализующий бизнес-логику приложения; - докер-файл; - средства web-интерфейса (функция index, шаблон старницы); - файл docker-compose.yaml. Код, реализующий бизнес-логику приложения, если он достаточно объемный, может быть вынесен в приложение. Пример реализации простейшего web-приложения с микросервисной архитектурой и его краткого описания представлен в приложении В. Все приведенные компоненты описываются. Целесообразно привести структуру приложения в виде диаграммы компонентов UML, пример которой показан на рис. В.6. Таким образом реализуется первый этап цикла DevOps части CD: «Написание кода». В отдельном подразделе следует представить В разделе 6 реализуется второй и третий этап DevOps части CD: «Сборка» и «Тестирование». Необходимо отразить настройку и работу автоматической сборки приложения на базе выбранной системы контроля версий и последующее тестирование проекта. Описать настроенные триггеры для активации сборки. Представить листинги unit-тестов и результаты их выполнения, текстовые описания и результаты прогона других тестов в соответствии с возможностями используемых средств автоматизированного тестирования. Также необходимо доказательно и лаконично изложить доводы по поводу того, что ПС соответствует функциональным требованиям, которые сформулированы в ТЗ (раздел 2). В разделе 7 необходимо представить и описать процедуру доставки приложения ПС до целевой системы и тестирование его работоспособности, используя CI/CD Pipeline. Рассмотреть вторую половину этапов цикла DevOps – CD: «Развертывание», «Поддержка и мониторинг», «Планирование» в условиях потенциального или реального использования ПС конечными пользователями. Для этапа «Планирование» представить проект нового функционала и план доработок для захода на следующий цикл DevOps CI/CD. В целом текст основной части отчета должен давать полное представление о всех этапах жизненного цикла ПС, а разделы 5–7 должны полностью отражать все этапы цикла DevOps CI/CD. При этом множественные рисунки и копии экрана, не несущие основной информационной нагрузки, целесообразно располагать в приложениях к отчету. Заключение (краткие выводы студента по контрольной работе) должно содержать краткое описание сущности решенной задачи, содержать оценку работоспособности разработанной ПС и правильности полученных результатов, а также перспективы развития ПС. Текст заключения может разделяться на пункты. Перечень использованных источников должен содержать список использованной литературы, оформленный согласно требованиям ГОСТ. Приложения размещают после основной части отчета. В них подаются разные материалы (таблицы, рисунки, схемы, формы документов, листинги программ и др.), которые являются необходимым дополнением основного материала, но не могут быть последовательно размещенные в основной части отчета из-за большого объема или способа изложения. Приложения должны содержать: заполненные макеты входных документов, структуру БД ПС, листинги исходных текстов программного приложения ПС, распечатки сформированных отчетов, материалы, полученные при тестировании, а также по данным контрольного примера. Приложения обозначаются буквами, начиная с А, Б и т.д. Текст отчета выполняется в редакторе MS Word 2003 и выше в печатном виде на стандартных листах формата А4 (210*290 мм) с соблюдением полей: верхнее и нижнее по 20 мм, левое – 25 мм, правое – 15 мм. Шрифт для набора текста – Times New Roman, размер – 14 пт, интервал – полуторный. Страницы отчета должны быть заполнены полностью. Исключение составляет последняя страница раздела. В конце остальных страниц допускается не более 2–3 пустых интервалов, свободное место необходимо дополнять текстом, масштабировать рисунки и таблицы, и т.д. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||