МИНОБРНАУКИ РОССИИ ФГБОУ ВО «Ижевский государственный технический университет имени М.Т. Калашникова» Институт информатики и вычислительной техники Кафедра «Программное обеспечение» Шаталова О.М. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ ПО ДИСЦИПЛИНЕ «ПРОЦЕССЫ И ПРОФЕССИОНАЛЬНАЯ ПРАКТИКА ПРОГРАММНОЙ ИНЖЕНЕРИИ» Ижевск 2023 1. Общие положения Тема курсовой работы: Процессы жизненного цикла программных средств: проектирование и разработка программно-информационной системы (на платформе 1С:Предприятие 8.3) Цель курсовой работы: освоение теоретических положений концепции RUP, практикоориентированных положений моделирования средствами UML и норм технического регулирования процессов проектирования и разработки программных систем, а также углубление знаний и навыков по разработке программно-информационных систем на актуальных инструментальных платформах. Задачи: 1. обзор и аналитическая характеристика теоретических положений концепции рационального унифицированного процесса разработки ПО (Rational Unified Process, RUP); методы моделирования процессов средствами UML; 2. приложение теоретических положений RUP к практике разработки программно-информационных систем с учетом сложившихся норм технического регулирования в сфере программной инженерии, а также специфики программно-информационной системы, разрабатываемой в рамках выполнения курсовой работы. Курсовая работа состоит в изучении теоретических, практических, методических, нормативно-правовых материалов по теме работы на основе самостоятельно разрабатываемой программно-информационной системы. Объект разработки принимается в соответствии с индивидуальным заданием; результат разработки – минимально жизнеспособный продукт. При выполнении курсовой работы принимаются нормативные положения, изложенные в стандартах: ГОСТ 19.102-77 ЕСПД. Стадии разработки ГОСТ 34.601-90 информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания ISO/IEC 19501:2005(en) Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 ISO/IEC/IEEE 12207:2017 Systems and software engineering. Software life cycle processes ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств ISO/IEC/IEEE 15288:2023 Systems and software engineering. System life cycle processes ГОСТР 57193— 2016 Системная и программная инженерия. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА СИСТЕМ Объем курсовой работы должен быть не менее 25 и не более 35 страниц, оформленных в соответствии со следующими требованиями: формат А4; размер шрифта - 14 пт., шрифт - TimesNewRoman; межстрочный интервал – полуторный; абзацный отступ – 1,5; ссылки на литературные источники затекстовые в квадратных скобках, оформление списка литературы - в соответствии с ГОСТ Р 7.0.100–2018. Курсовая работа должна включать в себя следующие разделы: введение, основная часть, заключение, список использованных источников, приложения (при наличии). Во введении необходимо сформулировать актуальность выполняемой работы (положений процессного подхода к проектированию и разработки ПС); цель и задачи работы; степень теоретической, методической, нормативной проработанности темы. Основная часть должна включать два раздела: теоретический, практический. В заключении подводится общий итог работы, формулируются выводы, намечаются перспективы дальнейшего исследования проблемы. 2. Рекомендации к содержанию основной части курсовой работы 2.1. Теоретическая часть Должна содержать результаты обзора и аналитическую характеристику теоретических и методических положений концепции рационального унифицированного процесса разработки ПО (Rational Unified Process, RUP) и актуальных методических и инструментальных средств моделирования процессов разработки. Рекомендуется рассмотреть и представить в отчете по КР следующие вопросы: 1. обзор и аналитическая характеристика теоретических положений концепции RUP ‑ назначение UP как методологической концепции управления процессами разработки программно-информационных систем; ‑ основные характеристики UP (управляемый вариантами использования и требованиями, архитектуроцентричный, итеративный и инкрементный); ‑ фазы жизненного цикла UP; ‑ рабочие процессы UP. 2. Моделирование жизненного цикла разработки программноинформационных систем средствами; ‑ понятие и назначение UML; ‑ языки реализации и платформы; ‑ статический и динамический аспекты модели; ‑ нотация UML, UML-семантика; UML-сущности (структурные, поведенческие, группировки, примечания); UML-отношения; UMLдиаграммы; ‑ описание архитектуры программно-информационных систем посредством UML. 2.2 Практическая часть Практическая часть КР направлена на разработку программного продукта – прикладной конфигурации (по индивидуальному заданию) уровня «минимально жизнеспособный продукт», а также его представления в форме эталонной модели процессов1 в части группы процессов реализации ПС. «Эталонная модель процессов (ЭМП) составляется из формулировки цели и результатов (выходов) каждого из процессов» (ГОСТ …12207-2010 п. В.3) «Эталонная модель процесса <…> базируется на деловых потребностях организации и области приложений» (ГОСТ …12207-2010 п. 5.2.1) . Общий состав процессов жизненного цикла программных средств приведен на рис. 1. В рамках КР рассматривается группа процессов реализации ПС (семь процессов). Для описания процессов реализации ПС могут быть составлены: ‑ модель вариантов использования; ‑ модель анализа, уточняющая детали вариантов использования и определяющая первичное содержание системы по набору объектов, предоставляющих различные варианты поведения; ‑ модель проектирования, определяющая статическую структуру системы (состав подсистем, классов, объектов метаданных, интерфейсов) связи между структурными элементами системы; ‑ модель развертывания (при необходимости); ‑ модель реализации – включает компоненты, представленные исходным кодом; ‑ модель тестирования – варианты тестов для проверки вариантов использования. Эталонная модель процесса предназначается для применения при разработке модели (моделей) оценки для процессов оценки в соответствии с ГОСТ Р ИСО/МЭК 15504-2—2009 Информационная технология. ОЦЕНКА ПРОЦЕССА. Часть 2 Проведение оценки. 1 Рисунок 1 - Группы процессов жизненного цикла Источник: ГОСТ Р ИСО/МЭК 12207-2010 Формулирование цели и результатов каждого процесса проводится исходя из их содержания, нормативно определенного ГОСТ Р ИСО/МЭК 12207-2010 (основные положения приведены ниже) 1. Процессы реализации программных средств используются для создания конкретного элемента системы (составной части), выполненного в виде программного средства. Эти процессы преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий установленным требованиям. 2. Процесс реализации программных средств включает в себя несколько специальных процессов более низкого уровня: а) процесс анализа требований к программным средствам; b) процесс проектирования архитектуры программных средств; c) процесс детального проектирования программных средств; d) процесс конструирования программных средств; e) процесс комплексирования программных средств; f) процесс квалификационного тестирования программных средств. 3. Процесс анализа требований к программным средствам Цель процесса анализа требований к программным средствам заключается в установлении требований к программным элементам системы. Выходы: a) требования к программным элементам системы и их интерфейсам; b) требования к программным средствам анализируются на корректность и тестируемость; c) анализ воздействие требований к программным средствам на среду функционирования; d) оценка совместимости и прослеживаемости между требованиями к программным средствам и требованиями к системе; e) определение приоритетов реализации требований к программным средствам; f) требования к программным средствам принимаются и обновляются по мере необходимости; g) оценка изменений в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям; h) требования к программным средствам воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон. При реализации проекта необходимо выполнять следующие задачи: a) спецификация функциональных характеристик и возможностей; b) внешние интерфейсы к программной составной части; c) квалификационные требования; d) спецификации по безопасности; e) спецификации по защите, включая спецификации, связанные с угрозами для чувствительной информации; f) спецификации эргономических факторов, включая спецификации, связанные с ручными операциями, <…>, ограничениями по персоналу и областям, требующим концентрации внимания и чувствительным к ошибкам человека и уровню его обученности; g) описание данных и требования к базам данных; h) инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения; i) требования к документации пользователя; j) операции пользователя и требования к их выполнению; k) пользовательские требования к сопровождению. 4. Процесс проектирования архитектуры программных средств2 Архитектура [системы]: (1) фундаментальные концепции или свойства системы в ее среде, воплощенные в ее элементах, отношениях, а также в принципах ее проектирования и развития (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.6) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.2) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.5) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.6) (2) набор правил для определения структуры системы и взаимосвязей между ее частями (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -Reference Model: Foundations, 6.6) [иначе: структурное и поведенческое описание устройства программной системы] (3) фундаментальные концепции или свойства объекта в его среде, а также руководящие принципы реализации и развития этого объекта и связанных с ним процессов жизненного цикла (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.3) (4) архитектура (системы) (architecture): Основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития (ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011) архитектурное проектирование. (1) процесс разработки, определения, выражения, документирования, передачи, сертификации правильной реализации, поддержки и улучшения архитектуры на протяжении всего жизненного цикла системы (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.1). Примечание. Архитектура осуществляется в контексте организации или проекта. Объектом проектирования архитектуры может быть, например: система, предприятие, решение, бизнес, данные, приложение, информационные технологии, продукт, услуга, программное обеспечение. архитектурный дизайн. (1) процесс определения набора аппаратных и программных компонентов и их интерфейсов для создания основы для разработки компьютерной системы (2) результат определения набор аппаратных и программных компонентов и их интерфейсов для создания основы для разработки компьютерной системы. Этап архитектурного проектирования. (1) фаза жизненного цикла, на которой разрабатывается общая архитектура системы, тем самым выполняя требования, изложенные в документе с требованиями к программному обеспечению, и детализируя план реализации в ответ на него (ISO/IEC/IEEE 24765:2017 Systems and software engineeringVocabulary) Цель процесса проектирования архитектуры программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований3. [иначе: Цель процесса проектирования архитектуры ПО — создание проекта, определяющего структуру ПО и функциональные отношения между ее 2 Проектирование архитектуры: а) с учетом положений ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 Системная и программная инженерия. ОПИСАНИЕ АРХИТЕКТУРЫ б) в форме «модель архитектуры» 3 по ГОСТ Р ИСО/МЭК 12207-2010 элементами, который может быть реализован и может быть верифицирован относительно исходных требований.] Результаты реализации процесса проектирования архитектуры программных средств (выходы): a) разрабатывается проект архитектуры программных средств программные составные части, которые будут реализовывать требования к программным средствам; b) определяются внутренние и внешние интерфейсы каждой программной составной части; c) устанавливаются согласованность и прослеживаемость между требованиями к программным средствам и программным проектом. 5. Процесс детального проектирования программных средств Цель процесса детального проектирования программных средств: обеспечение проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования. Результаты осуществления процесса детального проектирования программных средств: а) разрабатывается детальный проект каждого программного компонента, описывающий создаваемые программные модули; b) определяются внешние интерфейсы каждого программного модуля и c) устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры. Задачи: 1) разработка детального проекта для каждого программного компонента ПС; 2) детализация программных компонентов на более низком уровне, включающем программные блоки, которые могут быть закодированы, откомпилированы и проверены; 3) должен быть документальное оформление детального проекта; 4) разработка и документальное оформление детального проекта для внешних интерфейсов к программным составным частям, между программными компонентами и между программными блоками; 5) разработка и документальное оформление детального проекта базы данных; 6) определение и документирование требований к тестированию и графики работ по тестированию программных блоков. Необходимо, чтобы требования к тестированию включали в себя проведение проверок программных блоков при граничных значениях параметров, установленных в требованиях; 7) оценка детального проекта для ПС и требований к тестированию по следующим критериям: ‑ прослеживаемость к требованиям программной составной части; ‑ внешняя согласованность с архитектурным проектом; ‑ внутренняя согласованность между программными компонентами и программными блоками; ‑ соответствие методов проектирования и используемых стандартов; ‑ осуществимость тестирования; ‑ осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены. 6. Процесс конструирования программных средств Цель процесса конструирования программных средств заключается в создании исполняемых программных блоков, которые должным образом отражают проектирование программных средств Результаты процесса конструирования программных средств: a) определяются критерии верификации для всех программных блоков относительно требований; b) изготавливаются программные блоки, определенные проектом; c) устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом; d) завершается верификация программных блоков относительно требований и проекта. Задачи процесса: 1) разработка и документальное оформление а) каждого программного блока и базы данных; б) процедуры тестирования и данные для тестирования каждого программного блока и базы данных. 2) тестирование каждого программного блока и базы данных, гарантируя, что они удовлетворяют требованиям. Результаты тестирования должны быть документально оформлены. Критерии оценивания программного кода и результатов испытаний: a) прослеживаемость к требованиям и проекту программных элементов; b) внешняя согласованность с требованиями и проектом для программных составных частей; c) внутренняя согласованность между требованиями к блокам; d) тестовое покрытие блоков; e) соответствие методов кодирования и используемых стандартов; f) осуществимость комплексирования и тестирования программных средств; g) осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены. 7. Процесс комплексирования программных средств Цель процесса комплексирования ПС: объединение программных блоков и программных компонентов, создание интегрированных программных элементов, согласованных с проектом ПС, которые демонстрируют, что функциональные и нефункциональные требования к программным средствам удовлетворяются на полностью укомплектованной или эквивалентной ей операционной платформе. Результаты процесса комплексирования ПС: a) разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и расположенными по приоритетам требованиями к программным средствам; b) разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями; c) программные составные части верифицируются с использованием определенных критериев; d) программные составные части, определенные стратегией комплексирования, изготавливаются; е) регистрируются результаты комплексного тестирования; f) устанавливаются согласованность и прослеживаемость между программным проектом и программными составными частями; g) разрабатывается и применяется стратегия регрессии для повторной верификации программных составных частей при возникновении изменений в программных блоках (в том числе в соответствующих требованиях, проекте и кодах). Задачи: 1) для каждой программной составной части (или составной части конфигурации) а) разработка плана комплексирования для объединения программных блоков и программных компонентов в программную составную часть; план должен включать в себя требования к тестированию, процедуры, данные, обязанности и графики работ; документальное оформление плана комплексирования; б) объединение программных блоков, программных компонентов и тестов (в соответствии с планом комплексирования); документальное оформление результатов комплексирования и тестирования 2) обновление пользовательской документации по мере необходимости; 3) разработка и документальное оформление для каждого квалификационного требования к программной составной части комплекта тестов, тестовых примеров (входов, результатов, критериев тестирования) и процедур тестирования для проведения квалификационного тестирования программных средств. Разработчик должен гарантировать, что после комплексирования программная составная часть будет готова к квалификационному тестированию 4) оценка плана комплексирования, проекта, кода, тестов, результатов тестирования и пользовательской документации по следующим критериям: ‑ прослеживаемость к системным требованиям; ‑ внешняя согласованность с системными требованиями; ‑ внутренняя согласованность; ‑ тестовое покрытие требований к программной составной части; ‑ приспособленность используемых методов и стандартов тестирования; ‑ соответствие ожидаемым результатам; ‑ осуществимость квалификационного тестирования программных средств; ‑ осуществимость функционирования и сопровождения. ‑ документальное оформление результатов оценки. 8. Процесс квалификационного тестирования программных средств Цель процесса квалификационного тестирования ПС заключается в подтверждении того, что комплексированный программный продукт удовлетворяет установленным требованиям. Результаты процесса квалификационного тестирования программных средств: a) определяются критерии для комплексированных программных средств с целью демонстрации соответствия с требованиями к программным средствам; b) комплектованные программные средства верифицируются с использованием определенных критериев; c) записываются результаты тестирования; d) разрабатывается и применяется стратегия регрессии для повторного тестирования комплексированного программного средства при проведении изменений в программных составных частях (должна быть разработана стратегия регрессии для повторного применения тестирования комплексированного программного средства при проведении изменений в программных составных частях). Задачи: (для каждой программной составной части (или составной части конфигурации): а) проведение квалификационного тестирования в соответствии с квалификационными требованиями к программному элементу. Должна обеспечиваться гарантия того, что реализация каждого требования к программным средствам тестируется на соответствие. Результаты квалификационного тестирования должны быть документально оформлены; б) обновление пользовательской документации по мере необходимости; в) оценивание проекта, кода, тестов, результатов тестирования и пользовательской документации, учитывая следующие критерии: ‑ тестовое покрытие требований к программной составной части; ‑ соответствие с ожидаемыми результатами; ‑ осуществимость системного комплексирования и тестирования, если они проводятся; ‑ осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены.
