Шаблон отчета производственной практики 03.01 ПМ 03 Ревьюирование программных модулей (1)
реклама
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение высшего образования «КУЗБАССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ИМЕНИ Т.Ф.ГОРБАЧЕВА» Филиал КузГТУ в г. Белово ОТЧЕТ ПО ПРОИЗВОДСТВЕНОЙ ПРАКТИКЕ ПМ.05 «Проектирование и разработка информационных систем» Студент гр. ИС-205.2 ___________ / Руководитель от предприятия ___________ / Руководитель практики от филиала КузГТУ в г. Белово М.П. ___________/ Антипов Е.В. Оценка_______________ Дата_________________ Белово 2024 СОДЕРЖАНИЕ ВВЕДЕНИЕ.................................................................................................................................................. 3 1. ОБЩИЕ СВЕДЕНИЯ ОБ ОРГАНИЗАЦИИ ......................................................................................... 7 1.1 Общие сведения об организации и отделе - месте прохождения практики .................................... 7 1.2 Прохождение техники безопасности................................................................................................... 9 1.2.1 Организация рабочего места ...........................................................................................................11 1.2.2 Перерывы в работе за компьютером ..............................................................................................11 1.3 Виды обеспечения ИС ........................................................................................................................12 1.3.1 Комплекс технических средств.......................................................................................................12 1.3.2 Комплекс программных средств.....................................................................................................12 2. ПРОВЕДЕНИЕ АНАЛИТИЧЕСКОГО ОБСЛЕДОВАНИЯ. .............................................................13 3. РАЗРАБОТКА ТРЕБОВАНИЙ. ...........................................................................................................15 3.1. Разработка функциональных требований. ........................................................................................15 3.1.1 Построение диаграмм UML ............................................................................................................15 3.1.2 Построение диаграмм DFD .............................................................................................................18 3.1.3 Построение диаграммы IDEF0 ........................................................................................................20 3.2. Разработка требований к программному обеспечению. ...................................................................22 3.3. Разработка требований к оборудованию. ..........................................................................................23 4. РЕВЬЮИРОВАНИЕ ПРОТОТИПА ИНТЕРФЕЙСА ПОДСИСТЕМЫ БЕЛОВСКОЙ ГРЭС НА БАЗЕ СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ GIT .......................................................................................25 4.1 Проектирование и разработка прототипа интерфейса подсистемы, реализующей бизнеспроцессы отдела кадров. ...........................................................................................................................25 4.2 Разработка и заполнение базы данных отдела кадров .......................................................................28 4.3 Установка и настройка локального и глобального репозиториев информационной системы отдела кадров .................................................................................... Ошибка! Закладка не определена. 4.4 Ревьюирование информационной системы на этапе опытной эксплуатации и устранение замечаний .......................................................................................... Ошибка! Закладка не определена. ЗАКЛЮЧЕНИЕ .........................................................................................................................................30 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ .....................................................................................32 2 ВВЕДЕНИЕ Производственная практика по профессиональному модулю ПМ.03 «Ревьюирование программных модулей» предусматривает закрепление и углубление знаний, полученных обучающимися в процессе теоретического обучения, приобретение ими необходимых умений практической работы по избранной специальности, овладение навыками профессиональной деятельности, приобретение практического опыта. Программа производственной практики является составной частью профессионального модуля ПМ.03 «Ревьюирование программных модулей», основной профессиональной образовательной программы по специальности СПО 09.02.07 «Информационные системы и программирование». Прохождение практики направлено на формирование соответствующих компетенций: ПК - 3.1 - Осуществлять ревьюирование программного кода в соответствии с технической документацией. Знать: задачи и технологии планирования и контроля развития проекта; используемые нотации в графических языках моделирования; правила построения моделей; типовые функциональные роли в коллективе разработчиков, правила совмещения ролей; методы организации работы в команде разработчиков. Уметь: работать с проектной документацией, разработанной с использованием графических языков спецификаций; выполнять оптимизацию программного специализированных программных средств. Иметь практический опыт: 3 кода с помощью разработки моделей программного средства с помощью графических языков моделирования оптимизации программного кода с использованием специализированных программных средств. ПК - 3.2 - Выполнять процесс измерения характеристик компонент программного продукта для определения соответствия заданным критериям. Знать: современные стандарты качества программного проекта и процессов его обеспечения; методы организации работы в команде разработчиков. Уметь: применять стандартные метрики по прогнозированию затрат, сроков и качества. Иметь практический опыт: определения характеристики программного продукта и автоматизированных средств. ПК - 3.3 - Производить исследование созданного программного кода с использованием специализированных программных средств с целью выявления ошибок и отклонения от алгоритма. Знать: характеристики программного продукта; задачи, решаемые при исследовании программных продуктов, используемые методы и средства. Уметь: выбирать необходимые программные средства для исследования программного продукта и выявления требуемых характеристик. Иметь практический опыт: измерения характеристик программного продукт с помощью специальных средств. 4 ПК - 3.4 - Проводить сравнительный анализ программных продуктов и средств разработки, с целью выявления наилучшего решения согласно критериям, определенным техническим заданием. Знать: основные методы сравнительного анализа программных продуктов и средств разработки; основные подходы к менеджменту программных продуктов; основные методы оценки бюджета, сроков и рисков разработки программ. Уметь: проводить сравнительный анализ программных продуктов; проводить сравнительный анализ средств разработки программных продуктов; разграничивать подходы к менеджменту программных проектов. Иметь практический опыт: обоснования выбора методологии и средств разработки программного обеспечения. Цель: производственная практика по специальности направлена на формирование у обучающихся умений, приобретение первоначального практического опыта и реализуется в рамках профессиональных модулей ОП СПО по основным видам профессиональной деятельности для последующего освоения ими общих и профессиональных компетенций по избранной специальности. Задачи: по результатам практики составляется отчет, который утверждается организацией. В качестве приложения к дневнику практики оформляется графические, аудио-, фото-, видео-, материалы, наглядные образцы изделий, подтверждающие практический опыт, полученный на практике. 5 Основной целью производственной практики является закрепление знаний, приобретенных в процессе лекционных, лабораторных занятий и самостоятельной работы студента, и получение фундаментальных компетенций. Успешно пройденная производственная практика способствует более легкому усвоению материала по специальным дисциплинам, составляющим фундаментальную часть профессионального цикла. Программа производственной практики (далее программа) является частью программы подготовки специалистов среднего звена в соответствии с ФГОС по специальности СПО 09.02.07 «Информационные системы и программирование» в части освоения основного вида профессиональной деятельности (ВПД): «Ревьюирование программных модулей». Количество часов на освоение рабочей программы производственной практики - 72 часа. База прохождения практики: Период прохождения: 13 декабря – 26 декабря 2023 г. 6 1. ОБЩИЕ СВЕДЕНИЯ ОБ ОРГАНИЗАЦИИ 1.1 Общие сведения об организации и отделе - месте прохождения практики Беловская ГРЭС - предприятие энергетики пгт. Инской, Кемеровская область. АО «Кузбассэнерго», входит в Группу «Сибирская генерирующая компания» (СГК). Награждена Орденом «Знак Почёта» (1974). Беловская ГРЭС находится по адресу: 652644, Кемеровская область – Кузбасс, г. Белово, пгт. Инской, микрорайон Технологический, д. 5. Директором Беловской ГРЭС является Данейко Петр Иванович. Беловская ГРЭС сооружена между жилыми кварталами посёлка городского типа Инской и деревней Коротково, в центральной части Кузбасса, на реке Иня (рис. 1). Для нужд станции на реке создано Беловское водохранилище. Рисунок 1 – Беловская ГРЭС Начало строительства станции - июль 1956 года. Первый энергоблок ГРЭС мощностью 200 МВт был запущен 29 июня 1964 года. В 1968 году, с вводом шестого блока, станция достигла своей проектной мощности 1200 МВт. Установленная тепловая мощность ГРЭС - 123 Гкал/ч. 7 Сегодня на станции установлено 6 энергоблоков мощностью 200 и 230 МВт, 6 прямоточных симметричных двухкорпусных котлов ПК-40-1 паропроизводительностью 640 тонн в час, 6 турбогенераторов, подстанция 500 кВ, ОРУ 110 и 220 кВ. Сегодня на долю ГРЭС приходится около трети всей вырабатываемой в области электроэнергии. Через высоковольтные линии электроэнергия поступает в Кемерово, Новокузнецк, Белово и другие города, а также в соседние регионы. Электростанция обеспечивает основное потребление электрической энергии промышленными предприятиями Кемеровской области. В 2021 году от Беловской ГРЭС в центральную часть города Белово была построена тепловая магистраль протяжённостью 12,4 км. Благодаря чему в Белово удалось заместить 3 неэффективных котельных. Предприятие представлено следующей оргструктурой, представленной ниже (рис. 2). Рисунок 2 – Организационная структура Беловской ГРЭС 8 Производственная практика проходила в отделе «Группа поддержки рабочих мест». Руководителем отдела является Куницын Виктор Михайлович. Рабочее место представлено ниже (рис. 3). Рисунок 3 – Рабочее место Данный пользователей отдел занимается (обслуживание сопровождением ПК, поддержка рабочих АРМов, мест поддержка корпоративных программных комплексов, систем печати и т. д.). 1.2 Прохождение техники безопасности Под техникой безопасности подразумевается комплекс мероприятий технического и организационного характера, направленных на создание безопасных условий труда и предотвращение несчастных случаев на производстве. 9 На Беловской ГРЭС был проведен вводный, первичный инструктаж, обозначены маршруты безопасного движения по территории станции. Рассмотрели правила безопасности по каждому этапу работы с компьютером: 1) До начала работы: проверить исправность электропроводки, розеток и вилок компьютера, заземление ПК. 2) Во время работы: необходимо аккуратно обращаться с проводами; запрещается работать с неисправным компьютером; нельзя заниматься очисткой компьютера, когда он находится под напряжением; недопустимо самостоятельно проводить ремонт оборудования при отсутствии специальных навыков; нельзя располагать рядом с компьютером жидкости, а также работать с мокрыми руками; нельзя в процессе работы с ПК прикасаться к другим металлическим конструкциям (например, батареям); не допускается курение и употребление пищи в непосредственной близости с ПК и др. 3) В аварийных ситуациях: при любых неполадках необходимо сразу отсоединить ПК от сети; в случае обнаружения оголенного провода незамедлительно оповестить всех работников и исключить контакт с проводом; в случае возникновения пожара принять меры по его тушению с использованием огнетушителей (работники должны знать, где они находятся); в случае поражения человека током оказать первую помощь и вызвать скорую медицинскую помощь. 4) По окончании работы: выключить компьютер; желательно провести влажную уборку рабочего места; 10 отключить электропитание. 1.2.1 Организация рабочего места Постоянная работа за компьютером вызывает отклонения в здоровье работника, в частности: нагрузка на зрение приводит к его ухудшению, покраснениям глаз, возникновению «синдрома сухого глаза»; несоблюдение нормативов организации рабочего места может привести к искривлению позвоночника, заболеваниям суставов и болям различного характера; длительная концентрация внимания на экране вызывает переутомление. Приведем некоторые требования, предъявляемые СанПиН к рабочему месту пользователя ПК: расстояние от монитора до глаз должно составлять от 600 до 700 мм, но не меньше 500; стул работника должен быть регулируемым по высоте и обеспечивать возможность поворота и изменения позы во время работы; высота стола – от 680 до 800 мм; поверхность стола должна позволять оптимально разместить на ней все необходимое для работы и др. 1.2.2 Перерывы в работе за компьютером С целью избежать переутомления работника СанПиН рекомендуют делать перерывы длительностью от 10 до 15 минут после 45 — 60 минут работы. Во время перерыва работнику следует выполнять гимнастику для глаз и физические упражнения, предусмотренные приложениями 8 – 10 к СанПиН. При работе за компьютером обязательно нужно пользоваться правилами работы за компьютером, это поможет избежать некоторых болезней, связанных с работой за компьютером. Однако чаще всего именно работники пренебрегают данными правилами, и задача работодателя в данном случае – постоянно доводить до сведения своих сотрудников информацию о последствиях 11 несоблюдения вышеизложенных требований и своими распоряжениями организовывать обязательные перерывы в работе. 1.3 Виды обеспечения ИС 1.3.1 Комплекс технических средств Состав технического обеспечения автоматизированного рабочего места формируется исходя из выполняемых должностных обязанностей работника. В отделе установлено 6 компьютеров. Средние характеристики устройства: 1. Имя устройства: DESKTOP-H8J63G2 2. Процессор: Intel(R) Core(TM) i5-10500T CPU @ 2.30GHz 2.30 GHz 3. Оперативная память: 8,00 ГБ 4. Тип системы: 64-разрядная операционная система, процессор x64 5. Монитор: HP, модель - HP 2311x 6. Блок питания: tp-link, модель - T480125-2-DE Характеристики Windows: Выпуск: Windows 10 Pro Версия: 20H2 Дата установки: 25.08.2021 1.3.2 Комплекс программных средств Программный комплекс - набор технических и программных средств, работающих совместно для выполнения одной или нескольких сходных задач, можно понимать под ним систему из разных приложений, которые работают в единой среде и направлены на выполнения конкретной цели. На ПК установлен офисный пакет Microsoft Office, браузер Google. В данном разделе описали предприятие – место прохождения практики, составили организационную структуру предприятия, описали технические и программные средства. 12 2. ПРОВЕДЕНИЕ АНАЛИТИЧЕСКОГО ОБСЛЕДОВАНИЯ. Аналитическое обследование — это процесс изучения и анализа данных с целью выявления закономерностей, тенденций и значимых взаимосвязей. Целью аналитического обследования является получение информации, которая может быть использована для принятия решений, прогнозирования тенденций и улучшения процессов или систем. Результаты аналитического обследования могут быть использованы для разработки стратегий, рекомендаций и планов действий, направленных на повышение эффективности и результативности деятельности организации. В данной организации планируется предоставлять электричество и снабжением отопления в дома, расположенные в посёлке Инской и городе Белово. Анализ предметной области — это процесс исследования и понимания конкретной области, которая будет использоваться в проекте. В ходе анализа предметной области определяются цели и задачи, выявляются требования к системе, определяется ее функциональность и производится оценка рисков и возможностей. Анализ предметной области позволяет создать проект, который соответствует требованиям и ожиданиям заказчика. Результаты анализа могут быть использованы для разработки стратегии и тактики работы в данной области, а также для принятия решений о дальнейших действиях. Анализ включает в себя сбор информации, а также определение целей и задач, которые необходимо решить в данной области. Предметной областью в данном случае является отдел кадров, занимающийся способствованию достижению целей предприятия (организации) путем обеспечения предприятия необходимыми кадрами и эффективного использования потенциала работников. В общем виде, отдел кадров на предприятии обеспечивает следующие потребности: 13 организация отбора, набора и найма персонала необходимой квалификации и в требуемом объеме; создание эффективной системы штатных сотрудников; разработка карьерных планов сотрудников; разработка кадровых технологий. Также отдел кадров имеет следующие функции: определение потребности организации в кадрах и подбор персонала совместно с руководителями подразделений; анализ текучести кадров, поиск методов борьбы с высоким уровнем текучести; внедрение систем мотивации труда; подготовка штатного расписания предприятия; оформление личных дел сотрудников, выдача по требованию работников справок и копий документов; проведение операций с трудовыми книжками (прием, выдача, заполнение и хранение документов); ведение учета отпусков, составление графиков и оформление отпусков в соответствии с действующим трудовым законодательством; организация аттестаций сотрудников; подготовка планов повышения квалификации сотрудников. Отдел кадров является не только функциональной единицей, это еще и лицом компании, так как именно в отделе кадров любой соискатель начинает знакомиться с организацией. Структура отдела кадров предприятия и его численность определяется директором каждой компании в зависимости от общего количества персонала и особенностей деятельности. 14 3. РАЗРАБОТКА ТРЕБОВАНИЙ. 3.1. Разработка функциональных требований. Разработка функциональных требований — это процесс определения и документирования ожидаемого поведения системы или компонента. Функциональные требования описывают, что именно система должна делать, какие функции выполнять, чтобы удовлетворить потребности пользователей или заказчика. Этот процесс помогает определить границы и основные возможности системы, а также проверить их на полноту и непротиворечивость. Функциональные требования могут включать в себя различные сценарии использования, входные и выходные данные, ограничения и допущения. Функциональные требования представлены в диаграммах (рис.4 - 8) 3.1.1 Построение диаграмм UML StarUML - программный инструмент моделирования, который поддерживает UML (Унифицированный язык моделирования). StarUML ориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0. Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя концепцию профилей UML. Доступные типы диаграмм: 1. Диаграмма классов (Сlass diagram) - визуальное отображение различных статических отношений между класс-подобными элементами. Диаграмма классов может содержать не только классы, но также и интерфейсы, перечислимые типы, пакеты, различные отношения, инстанции и их связи. 2. Диаграмма прецедентов (Use case diagram) - отображение отношений между вариантами использования (прецедентами) определенной системы или объекта и внешними акторами. Вариант использования 15 отображает функции системы и то, как эти функции взаимодействуют с внешними акторами. 3. Диаграмма последовательности (Sequence Diagram) отображает взаимодействие инстанций. Она является прямым отображением множества взаимных воздействий (InteractionInstanceSet) между элементами множества инстанций (CollaborationInstanceSet). В то время как Диаграмма сообщений роли ориентирована на классификаторы-роли, обычная Диаграмма сообщений - на инстанции. 4. Диаграмма сообщений (Sequence Role Diagram) роли отображает взаимодействия в концепции ролей. Она является прямым отображением Interaction (множества взаимных сообщений между классификаторамиролями) в пределах Collaboration. В то время как Диаграмма сообщений отображение инстанций, Диаграмма сообщений роли - отображение классификаторовролей. 5. Диаграмма коллаборации (Collaboration Diagram) отображает взаимодействие между инстанциями. Она является прямым отображением модели взаимодействия инстанций, входящих в 6. Диаграмма вариантов использования (use case diagram) описывает функциональное назначение системы или то, что система будет делать в процессе своего функционирования. 7. Диаграммы деятельности описываем последовательность действий для каждого прецедента, необходимая для достижения поставленной цели. 8. Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования, показывая ее структуру. Диаграмма классов не отображает динамическое поведение объектов, изображенных на ней классов. Технология выполнения: 1. Создали диаграмму вариантов использования в программе StarUML (рис. 4). 16 Рисунок 4 – Диаграмма вариантов использования UML Диаграмма вариантов использования – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей. Диаграммы использования применяются для того чтобы описать различные группы пользователей и их возможности в будущей программе, создаётся так называемая диаграмма вариантов использования. 2. Создали диаграмму последовательностей (рис. 5). Рисунок 5 – Диаграмма последовательностей UML 17 Диаграмма последовательности используются: для изображения поведение нескольких объектов в рамках одного прецедента; для удобства представления взаимодействия объектов, но не для точного определения их поведения; для отображения экземпляров объектов и сообщения, которыми обмениваются экземпляры в рамках одного прецедента. 3.1.2 Построение диаграмм DFD Data Flow Diagrams – представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Изображается прямоугольником с двумя полями. Первое поле служит для указания номера или идентификатора накопителя, который начинается с буквы «D». Второе поле служит для указания имени. Функциональное моделирование (IDEF0), описание бизнес-процессов (IDEF3), диаграммы потоков данных (DFD). Основными компонентами диаграмм потоков данных являются: внешние сущности; системы и подсистемы; процессы; накопители данных; 18 потоки данных. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Рисунок 6 – Диаграмма DFD Диаграммы типа DFD используются для визуального отображения всех процессов с точки зрения данных. Это может быть полезно: при разработке информационной системы; при интеграции системы; при миграции данных и функционала с одной системы на другую; 19 в проектах, связанных с Data Management; в процессе построения аналитического хранилища, BI-решения. 3.1.3 Построение диаграммы IDEF0 Функциональные модели IDEF0 — это всегда графические схемы и у них есть свои особенности и правила составления. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся: диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые; метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы; последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем происходит их детализация и уточнение; древовидные схемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом и входящих в нее деталей. Построение диаграммы IDEF0 выполняется по следующей технологии выполнения: 1. Запуск BPwin. 2. Установка тип (нотацию IDEF0) модели, задали имя модели, щелкнув по кнопке. Появится диалоговое окно. Внесли в текстовое поле Name имя модели «Деятельность компании» и выбрали Туре – Business Process (IDEF0). 3. Установка области, цели, точку зрения и временной охват в модели: Перешли в меню Model/Model Properties; 20 Во вкладке General диалогового окна Model Properties в текстовое поле Model name внесли имя модели «Обработка информации» (рис. 7); Рисунок 7 – Функциональная диаграмма IDEF0 IDEF0 используется для создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции. Провели декомпозицию функциональной диаграммы (рис. 8); Рисунок 8 - Диаграмма декомпозиции 21 Диаграммы декомпозиции предназначены для детализации функций и получаются при разбиении контекстной диаграммы на крупные подсистемы (функциональная декомпозиция) и описывающие каждый подсистему и их взаимодействие. Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В данном разделе выполнили проектирование ИС с помощью диаграмм UML, DFD и IDEF0. 3.2. Разработка обеспечению. требований к программному Разработка требований к программному обеспечению — это процесс определения задач и функций, которые должно выполнять программное обеспечение. Требования могут быть функциональными (описывают, что должно делать ПО), нефункциональными (ограничения или особенности, такие как производительность, безопасность, совместимость) и бизнестребования (определяют цели и задачи в контексте бизнеса). Разработка требований помогает создать понятное и эффективное ПО, отвечающее потребностям пользователей и бизнеса. Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация — детализированное математическое формальное описание системных функций. Для различения требований разных уровней используется термин пользовательских требований, высокоуровневые обобщенные требования и системные требования, детализированные описания выполняемых системой функций. Существует более детализированное описание — проектная системная спецификация. 22 Пользовательские требования: Возможность выбора компонентов из каталога. Наличие фильтров для поиска компонентов по характеристикам (производитель, модель, цена, наличие на складе и т.д.). История сборок и возможность просмотра информации о ранее купленных комплектующих. Возможность регистрации и авторизации пользователей. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО. Проектная системная спецификация — обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и се последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований. Пользовательские требования пишутся для заказчика ПО и для лица, заключающего контракт на разработку программной системы, причем они могут не иметь детальных технических знаний по разрабатываемой системе. Спецификация руководящего системных технического состава требований предназначена компании-разработчика и для для менеджеров проекта. Она также необходима заказчику ПО и субподрядчикам по разработке. Эти оба документа также предназначены для конечных пользователей программной системы. Проектная системная спецификация является документом, который ориентирован на разработчиков ПО. 3.3. Разработка требований к оборудованию. Для удобства работы с приложениями компьютер пользователя должен соответствовать следующим требованиям: 23 двухъядерный процессор с тактовой частотой не ниже 2500 МГц. Рекомендуем от 3100 МГц; оперативная память не менее 4096 Мб; свободное место на жестком диске не менее 5 Гб; монитор с диагональю не менее 19" и разрешением экрана не меньше 1280*1024. Рекомендуемые параметры: 21-24", широкоформатный, 1920х1080; локальная сеть с пропускной способностью не ниже 50 мбит\с; в случае использования печатных форм в формате *.doc, необходим установленный Microsoft Office Word не ниже 2003; операционная система Microsoft Windows 7, 8, 10. периферийные устройства: клавиатура, мышь, аудиосистема. Разработка требований к оборудованию — это процесс определения характеристик и функций оборудования, программного обеспечения. Разработка необходимого требований к для работы оборудованию помогает создать систему, которая будет эффективно работать вместе с программным обеспечением и удовлетворять потребности пользователей. 24 4. Проектирование и разработка информационной системы отдела кадров БЕЛОВСКОЙ ГРЭС 4.1 Проектирование и разработка программных модулей подсистемы, реализующей бизнес-процессы отдела кадров. Разработаем форму для внесения данных: Рисунок 9 – Код стилей 25 Рисунок 10 – Код формы 26 Рисунок 11 – Код формы Рисунок 12 – Готовая форма 27 4.2 Разработка и заполнение базы данных кадров Создадим базу данных для внесения новой информации: Рисунок 13 – Создание базы данных Рисунок 14 – Добавление строк в таблицу 28 отдела Рисунок 15 – Структура таблицы Рисунок 16 – Обзор таблицы 29 Рисунок 17 – Форма с таблицей ЗАКЛЮЧЕНИЕ В ходе прохождения производственной практики по проектированию и разработке информационных систем выполнили следующие виды работ: 1. Рассмотрели теоретический материал по темам производственной практики, 2. Выполнили индивидуальные практические задания: 1.Уточнение предметной области указанной в задании практики. Построение моделей процессов. Выявление заинтересованных лиц, их интересов, связанных с предполагаемой разработкой системы. Разработка кандидатов в требования. 30 2. Формирование предварительной спецификации требований. Анализ и ранжирование требований. Выявление и детализация архитектурных требований. Разработка состава тестовых примеров и сценариев выполнения. Предварительное определение состава функциональных модулей. 3. Уточнение используемой операционной системы. СУБД. Среды разработки. Базовых нефункциональных требований, связанных с производительностью и масштабируемостью системы. Определение возможного типа архитектуры. 4. Определение состава подсистемы. Разработка архитектурного представления модели классов и компонентов. Определение базовой стабильной архитектуры. 5. Построение полной модели проектирования. Разработка сценариев детального выполнения требований в виде взаимодействий объектов классов. Определение последовательности реализации классов проектирования. 6. Разработка программных модулей системы. Модульное тестирование. 7. Интегрирование модулей в систему. Системное тестирование. При прохождении практики освоили профессиональные компетенции и приобрели практический опыт решения профессиональных задач. 31 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ Основные источники: 1. Старолетов, С. М. Основы тестирования и верификации программного обеспечения: учебное пособие / С.М. Старолетов.— 2е изд., стер.— Санкт-Петербург: Лань, 2020.— 344с.:ил.— (Учебники для вузов. Специальная литература).— Текст: непосредственный. 2. Романов, Е.Л. Программная инженерия: учебное пособие / Е.Л. Романов. – Новосибирск: Изд-во НГТУ, 2017. – 395 с.; илл. – (Серия «Учебники НГТУ»). 3. Заботина, Н. Н. Проектирование информационных систем: учебное пособие / Н. Н. Заботина. — Москва: ИНФРА-М, 2020. — 331 с. — (Высшее образование: Бакалавриат). - ISBN 978-5-16-004509-2. - Текст: электронный. - URL: https://znanium.com/catalog/product/1036508 (дата обращения: 14.12.2023). – Режим доступа: по подписке. 4. Федорова, Г. Н. Разработка, внедрение и адаптация программного обеспечения отраслевой направленности : учеб. пособие / Г.Н. Федорова. — М. :КУРС : ИНФРА-М, 2019. — 336 с. (Среднее Профессиональное Образование). - ISBN 978-5-906818-41-6. - Текст: электронный. - URL: https://znanium.com/catalog/product/989682 (дата обращения: 15.12.2023). – Режим доступа: по подписке. 5. Гагарина, Л. Г. Технология разработки программного обеспечения: учебное пособие / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. СидороваВиснадул; под ред. Л.Г. Гагариной. — Москва: ФОРУМ: ИНФРА-М, 2021. — 400 с. — (Среднее профессиональное образование). - ISBN 978-5-8199-08129. - Текст: электронный. - URL: https://znanium.com/catalog/product/1189951 (дата обращения: 17.12.2023). – Режим доступа: по подписке. 32
