Загрузил Эльвира Вахрушева

0. МР КР ППППИ

реклама
МИНОБРНАУКИ РОССИИ
ФГБОУ ВО «Ижевский государственный технический университет
имени М.Т. Калашникова»
Институт информатики и вычислительной техники
Кафедра «Программное обеспечение»
Шаталова О.М.
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ
КУРСОВОЙ РАБОТЫ ПО ДИСЦИПЛИНЕ
«ПРОЦЕССЫ И ПРОФЕССИОНАЛЬНАЯ ПРАКТИКА
ПРОГРАММНОЙ ИНЖЕНЕРИИ»
Ижевск 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) разрабатывается и применяется стратегия регрессии для повторного
тестирования комплексированного программного средства при проведении
изменений в программных составных частях (должна быть разработана
стратегия
регрессии
для
повторного
применения
тестирования
комплексированного программного средства при проведении изменений в
программных составных частях).
Задачи:
(для каждой программной составной части (или составной части
конфигурации):
а) проведение квалификационного тестирования в соответствии с
квалификационными требованиями к программному элементу. Должна
обеспечиваться гарантия того, что реализация каждого требования к
программным средствам тестируется на соответствие. Результаты
квалификационного тестирования должны быть документально оформлены;
б) обновление пользовательской документации по мере необходимости;
в) оценивание проекта, кода, тестов, результатов тестирования и
пользовательской документации, учитывая следующие критерии:
‑ тестовое покрытие требований к программной составной части;
‑ соответствие с ожидаемыми результатами;
‑ осуществимость системного комплексирования и тестирования, если
они проводятся;
‑ осуществимость функционирования и сопровождения.
Результаты оценки должны быть документально оформлены.
Скачать