Файл: Классификация требований к по. 9 Валидация требований 10.docx
Добавлен: 27.10.2023
Просмотров: 105
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Содержание
Классификация требований к ПО. 9
Валидация требований 10
Использование функциональных прототипов 11
Разработка и реализация требований 11
Верификация требований к ПО 12
Copy-paste 14
Локальная система контроля версий 14
Централизованная система контроля версий 15
Распределенная система контроля версий 16
Распределенная система контроля версий 16
Введение
С 18 мая по 21 июня 2023 года я проходил учебную и производственную практику на АО «ФНПЦ «ПО «Старт» им. М.В. Проценко», г. Заречный.
Целью данной практики являлось:
- закрепление теоретических знаний, полученных в ходе изучения профессиональных модулей ПМ.02 «Осуществление интеграции программных модулей», ПМ.03 «Ревьюирование программных продуктов»;
- формирование у обучающихся профессиональных компетенций в условиях реального производства.
Задачи практики:
- закрепление и совершенствование приобретенного в процессе обучения опыта практической деятельности студентов в сфере изучаемой специальности;
- освоение современных производственных процессов, технологий;
- адаптация обучающихся к конкретным условиям деятельности предприятий различных организационно-правовых форм.
В ходе написания отчета были использованы учредительные, регистрационные документы, предоставленная отчетность, учебные и методические пособия.
Введение
С 18 мая по 21 июня 2023 года я проходил учебную и производственную практику на АО «ФНПЦ «ПО «Старт» им. М.В. Проценко», г. Заречный.
Целью данной практики являлось:
- закрепление теоретических знаний, полученных в ходе изучения профессиональных модулей ПМ.02 «Осуществление интеграции программных модулей», ПМ.03 «Ревьюирование программных продуктов»;
- формирование у обучающихся профессиональных компетенций в условиях реального производства.
Задачи практики:
- закрепление и совершенствование приобретенного в процессе обучения опыта практической деятельности студентов в сфере изучаемой специальности;
- освоение современных производственных процессов, технологий;
- адаптация обучающихся к конкретным условиям деятельности предприятий различных организационно-правовых форм.
В ходе написания отчета были использованы учредительные, регистрационные документы, предоставленная отчетность, учебные и методические пособия.
1 Организационная структура предприятия.
Акционерное Общество «Федеральный научно-производственный центр «Производственное объединение «Старт» имени М.В.Проценко» является современным предприятием, обладающим уникальными технологическими возможностями, разрабатывает и выпускает конкурентоспособную наукоемкую высокотехнологичную продукцию, используемую как в сфере обеспечения национальной безопасности страны, так и для нужд атомной энергетики, предприятий топливно-энергетического комплекса, железнодорожного транспорта и прочих промышленных объектов. Как непосредственный участник в деле создания ядерного щита нашей страны, «Старт» более пятидесяти лет работает в сфере ядерно-оружейного комплекса, входящего в состав предприятий Госкорпорации «Росатом», специализируется на выпуске радиотехнических, электромеханических, электронных приборов и систем.
Дата образования предприятия: 20 июля 1954 года Совет Министров СССР принял Постановление о строительстве приборного завода №1134 (ныне ПО «Старт»).
Генеральный директор – Байдаров Сергей Юрьевич.
2 Основные виды деятельности предприятия.
Основными направлениями деятельности АО «ФНПЦ «ПО «Старт» им. M.B.Проценко» являются:
-
изготовление спецтехники в интересах Госкорпорации «Росатом»; -
системы безопасности и технические средства охраны; -
АСУ ТП и различное оборудование для атомной энергетики; -
АСУ ТП и различное оборудование для топливно-энергетического комплекса; -
продукция для железнодорожного транспорта; -
металлообрабатывающее оборудование; -
система обеспечения инструментом; -
твердосплавный режущий инструмент; -
нормализованные изделия.
Ключевыми технологиями производства АО «ФНПЦ «ПО «Старт» им. M.B.Проценко» являются:
-
литье с использованием технологии послойного синтеза; -
литье под давлением порошковых материалов; -
вакуумное литье сталей и цветных сплавов; -
литье под давлением термопластичных пластмасс с давлением впрыска 2500 бар; -
горячая объемная штамповка; -
изготовление корпусов по технологии НТСС; -
технологии литейного производства; -
каркасно-шкафное производство; -
механическая обработка материалов; -
термическая и химико-термическая обработка; -
автоматизация измерений; -
сварочное производство; -
изготовление металлокерамических и металлостеклянных изделий; -
производство печатных плат (в т.ч. рельефных); -
производство чувствительных элементов, волноводных трактов; -
гибридная микроэлектроника (СВЧ и НЧ - микроузлы).
Услугами по проведению испытаний в заводских лабораториях АО «ФНПЦ «ПО «Старт» им. M.B.Проценко» являются:
-
периодические и специальные испытания; -
испытания на электромагнитную совместимость; -
входной контроль; -
метрологические испытания.
3 Порядок ведения технической документации.
Порядок ведения технической документации на предприятии зависит от многих факторов, таких как размер предприятия, виды документов, специфика деятельности и др. Однако, основные этапы ведения технической документации на любом предприятии могут быть следующими:
Разработка и утверждение правил ведения документации. Это включает стандарты наименования и описания документов, сроки их хранения, доступ к документам и т.д.
Разработка и утверждение шаблонов и форм документов. На предприятиях должны быть установлены образцы документов, которые должны быть заполнены при выполнении определенных процессов.
Регистрация документов. Вся документация должна регистрироваться в специальной журнальной книге или в электронном виде. Включает в себя наименование документа, дату, номер, автора, подпись руководителя, ответственного за регистрацию.
Утверждение документов. Документы должны быть утверждены компетентными лицами на предприятии и иметь отметки об утверждении.
Хранение документов. Документы должны храниться в соответствии с определенными правилами и сроками. Для обеспечения сохранности документов должны быть установлены требования к условиям их хранения и ведения электронной базы данных.
Очистка документации. Принятую практику удалять старые документы, которые уже не могут быть актуальными или могут привести к конфликтам.
Обновление документов. В процессе работы документация может устаревать, поэтому необходимы процедуры по перепроверке документов и обновлению их содержания.
В целом, порядок ведения технической документации может быть осуществлен как в бумажном виде, так и в электронном. Это зависит от возможностей предприятия, требований законодательства и решений руководства.
4 Порядок осуществления интеграции программных модулей на предприятии.
Требования к ПО. Классификация требований.
Классификация требований к ПО.
Когда требования собраны, команда, которая будет заниматься проектом, может приступить к их классификации и разбивке на категории.
Благодаря классификации требований можно точнее оценить сроки и определить компоненты решения. В процессе работы у вас также могут появиться идеи, касающиеся реализации проекта.
Требования к ПО могут быть:
1. Функциональными и нефункциональными.
Функциональные требования описывают функции, которые должно выполнять ПО. Например, предоставлять канал коммуникации для пользователя или переводить данные из одного формата в другой. То есть, речь идет о функционале продукта.
Нефункциональные требования касаются таких вещей, как доступность, надежность, способность к восстановлению, поддерживаемость, масштабируемость, производительность, безопасность и прочие «…ость».
2. Производными и навязанными.
3. Ориентированными на продукт или на процесс его разработки.
«Программа должна проверять права пользователя» — это требование к продукту.
«Программа должна разрабатываться инкрементально. В ходе разработки должна использоваться непрерывная интеграция» — это требование к процессу.
4. Разной приоритетности. Для назначения приоритета может использоваться шкала с фиксированными значениями «обязательно», «крайне желательно», «желательно» и «необязательно».
5. Разного масштаба. Одни требования касаются проектирования отдельных компонентов, другие — архитектуры всего ПО. Нефункциональные требования чаще всего касаются всей программы в целом.
6. Изменчивыми или стабильными. Например, изначально может быть ясно, что требования будут меняться в ходе жизненного цикла продукта. В таком случае реализация программы должна быть толерантной к внесению изменений.
Валидация требований
Когда требования выяснены и классифицированы, нужно проверить их, обсудив со стейкхолдерами. Вы должны быть уверены, что поняли и записали все точно и что требования в целом действительно удовлетворяют нужды стейкхолдеров. Требования, которые не прошли валидацию, являются всего лишь «хотелками» тех, кто их высказал.
Если вы практикуете итеративную разработку, валидация требований будет осуществляться регулярно, при этом будут обсуждаться требования, касающиеся отдельных частей решения, т. е., они будут разбиты на логичные группы.
Обычно для проверки требований команда, реализующая решение, воспроизводит свое понимание требований стейкхолдерам. При этом может применяться начальный проект (бизнес-проект или технический, или даже оба), на котором показывается, как будут реализованы нужды стейкхолдеров.
Такие обсуждения для выяснения, все ли правильно всё поняли, устраиваются итеративно на этапах планирования. Обычно в них участвуют кросс-функциональные команды (дизайнеры, бизнес-аналитики, технические эксперты).
В некоторых случаях перед реализацией может потребоваться дополнительная подготовительная работа. Чтобы лучше продемонстрировать, как команда понимает требования, создается функциональный прототип.
В ходе валидации может выясниться, что команда не может полностью удовлетворить все требования каждого стейкхолдера. Ваша задача (как технического эксперта) — продемонстрировать, что можно сделать, и обсудить уступки, на которые можно пойти при существующих ограничениях. Эти компромиссы должны быть приемлемыми для главных стейкхолдеров, а также укладываться в рамки бюджета, технических возможностей и прочих ограничений.
Использование функциональных прототипов
Функциональные прототипы помогают нам:
-
проверить, что требования поняты правильно; -
проверить допущения разработчика; -
получить фидбэк, в котором могут содержаться новые требования.
Вы должны учитывать, что чисто внешние проблемы или проблемы, связанные с качеством, могут отвлечь стейкхолдеров. Следует постоянно подчеркивать, что именно основной функционал является самым важным в этом показе.
То, как создается прототип, определяется командой, которая занимается проектом. Кто-то предпочитает прототипы, в которых вообще не задействовано ПО (аналогичные тем, которые создаются при сборе требований). Другие отдают предпочтение специальным инструментам, с помощью которых можно быстро создать «черновик» будущей программы.
Какой бы вариант вы ни выбрали, следует учитывать, сколько времени уйдет на создание прототипа, и насколько эффективно он продемонстрирует основной функционал.
Разработка и реализация требований
Когда требования прошли валидацию у стейкхолдеров, можно приступать к разработке ПО (т. е., к реализации этих требований).
Основной интерес вашей организации — получить прибыль от программного решения. Ваша задача и ответственность — попытаться использовать методы, снижающие стоимость разработки и поддержки.