Практика. Отчет. Вводный инструктаж по технике безопасности. Ознакомление с порядком проведения учебной практики
 Скачать 1.4 Mb.
|
|
Дата выполнения - 27.05.2021; количество часов - 6 часов. Вводный инструктаж по технике безопасности. Ознакомление с порядком проведения учебной практики. Цели и задачи практики. Анализ предметной области. Разработка и оформление технического задания. Распределять технические командные роли. Построение архитектуры программного средства. На вводном инструктаже ознакомился с техникой безопасности и порядком проведения учебной практики. Также изучил цели и задачи практики и что должен освоить такие виды работ как: работа в системе контроля версий; проектирование и реализация программного обеспечения; интегрирование программных модулей; адаптирование программных продуктов и информационных ресурсов к среде функционирования; проектирование архитектуры программного средства; построение диаграмм UML (Последовательности, Кооперации, Развертывания, Деятельности, Состояний, Классов, диаграммы компонентов и диаграмм потоков данных.); разработка и применение тестовых сценариев; оценка необходимого количества тестов; разработка тестовых пакетов; оценка программных средств с помощью метрик; инспектирование программного кода на предмет соответствия стандартам кодирования; использование выбранной системы контроля версии. использование методов для получения кода с заданной функциональностью и степенью качества. Анализ предметной области, в которой непосредственно будет проходить основная работа, позволяет определить основные типы данных, прикладные программы с которыми придется взаимодействовать, определить сильные и слабые стороны проекта, найти основные направления в развитии проекта, и получить полную информацию о конечных пользователях. Техническое задание Техни́ческое зада́ние (ТЗ, техзада́ние) — документ или несколько документов, определяющих цель, структуру, свойства и методы какого-либо проекта, и исключающие двусмысленное толкование различными исполнителями. В России Техническое задание пишется согласно двум ГОСТам: ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»; ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Пример ГОСТ 19.201-78 1. Введение 2. Основания для разработки 3. Назначение разработки 4. Требования к программе или программному изделию 4.1. Требования к функциональным характеристикам 4.2. Требования к надёжности 4.3. Условия эксплуатации 4.4. Требования к составу и параметрам технических средств 4.5. Требования к информационной и программной совместимости 4.6. Требования к маркировке и упаковке 4.7. Требования к транспортированию и хранению 4.8. Специальные требования 5. Требования к программной документации 6. Технико-экономические показатели 7. Стадии и этапы разработки 8. Порядок контроля и приёмки Так же я составил техническое задание из предметной области «Электронная коммерция», а конкретнее «Онлайн-магазин растений». Конкретную реализацию технического задания можно увидеть в таблице 1. Таблица 1 Техническое задание по созданию маркетплейса строительных материалов
Распределение технических командных ролей Нужно качественно распределить технические командные роли, т. к. от этого зависит скорость, эффективность, качество ПП. При изучении данной темы я смог выделить основные роли в создании различных проектов (Таблица №1). Таблица №2
Построение архитектуры программного средства Архитектура программного обеспечения (англ. softwarearchitecture) — совокупность важнейших решений об организации программной системы. Архитектура включает: выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов; соединение выбранных элементов структуры и поведения во всё более крупные системы; архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение Хорошая архитектура должна быть: Эффективной Гибкой Расширяемой Масштабируемой Удобной Критерии плохой архитектуры: Невозможность редактирования или изменения размеров\иконок\символов из-за влияния на другие части системы, вследствии чего ее трудно настроить для различных пользователей, тем самым использование данного интерфейса будет неудобным. (Жесткость) При внесении изменений она может повлиять на другие части системы, из-за чего ее сложно изменить для своих нужд. (Хрупкость) Код тяжело использовать повторно в другом приложении, поскольку его слишком тяжело или же вовсе невозможно «выпутать» из текущего приложения. (Неподвижность) Дата выполнения - 28.05.2021; количество часов - 6 часов. Создание команды разработчиков. Работа в системе контроля версий. Проектирование и реализация программного обеспечения. Создание команды разработчиков. Процесс формирования команды потребует от лидера наличия управленческой компетенции. Недостаточно просто правильно подобрать высококвалифицированных специалистов, необходимо сделать так, чтобы эти люди захотели работать сообща в команде. Сильная команда — это такая команда, в которой слабые стороны одного участника перекрываются сильными сторонами другого. Чтобы научить ребят работать в коллективе и чувствовать себя частью единого целого я ставлю задачу не каждому участнику в отдельности, а едино на всю команду. Человек отвечающий за финальный результат - Feature Owner. Этот тот, кто принимает задачу от бизнеса и формирует решение. Feature owner: декомпозирует общую задачу на подзадачи и распределяет их по всем участникам команды; координирует работу всей команды; имеет финальное слово в различных спорах и принятиях решении; формулирует вопросы к менеджеру проекта в процессе разработки; отвечает за целостность решения; презентует финальный результат. Секрет эффективности нашей модели в том, что все участники команды рано или поздно бывают feature owner: для каждой новой задачи роль feature owner передается от одного участника к другому. Это дает 3 положительных эффекта: Ребята знают обе стороны медали. Они понимают, что и как происходит как на месте разработчика, так и ответственного за результат. Ребята на своем опыте понимают, с какими сложностями сталкиваются тим лиды. Именно поэтому у нас нет болезней, вроде “начальник — дурак” и “подчиненные — бездари”. В один момент времени может быть (практически всегда) несколько feature owners, которые отвечают за разные задачи. Все вопросы по управлению ресурсами и “повисшими” задачами решаются внутри команды. При этом каждая задача находится в чьем-то фокусе внимания. В упрощенной форме и с правом на ошибку ребята получают навыки управления. Это помогает развить в команде автономность и проактивность. Работа в системе контроля версий. Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы гибко управляем некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть, кто что-то поменял. Как правило, системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа. Так самой популярной системой контроля версий является Git, поэтому буду описывать работу на его основе. Для использования системы git вам нужно: 1. Установить программу git на вашей системе. 2. Настроить программу и проверить её работоспособность локально. 3. Зарегистрировать ваш аккаунт на GitHub. 4. Создать локальный репозиторий или копировать репозиторий существующего проекта. 5. Написать файл README.MD. 6. В случае, если вы начинаете проект, создать удаленный репозиторий. 7. Фиксировать изменения локально. 8. Отправлять изменения на GitHub. 9. Зарегистрировать аккаунты разработчиков вашего проекта. 10. Выдать им ссылку на проект. Для наглядности я разместил небольшие рисунки централизованной (Рисунок №1) и распределенной (Рисунок №2) систем.  (Рис.1)  (Рис.2) Для простоты изучения темы, я написал словарь терминов, непосредственно связанных с данной темой (Таблица №3). Таблица №3
Проектирование и реализация программного обеспечения. Реализация программного обеспечения – это процесс перевода системной спецификации в работоспособную систему. Этап реализации всегда включает процессы проектирования и программирования, но если для разработки ПО применяется эволюционный подход, этап реализации также может включать процесс внесения изменений в системную спецификацию. На этапе проектирования ПО определяется его структура, данные, которые являются частью системы, интерфейсы взаимодействия системных компонентов и иногда используемые алгоритмы. Проектировщики сразу никогда не получают законченный результат – процесс проектирования обычно проходит через разработку нескольких промежуточных версий ПО. Проектирование предполагает последовательную формализацию и детализацию создаваемого ПО с возможностью внесения изменений в решения, принятые на более ранних стадиях проектирования. Процесс проектирования может включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование – это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирования, а следовательно, позволяют внести изменения в ранее созданные модели. На рис. 3 показана схема процесса проектирования ПО с указанием результата каждого этапа проектирования. Эта схема построена в предположении, что все этапы процесса проектирования выполняются последовательно. На практике эти этапы перекрываются вследствие неизбежных обратных связей от одного этапа к предыдущему и повторного выполнения некоторых проектных работ. Результатом каждого этапа проектирования является спецификация, необходимая для выполнения следующего этапа. Эта спецификация может быть абстрактной и формальной, т.е. такой, какая необходима для детализации системных требований; но она может быть и частью разрабатываемой системы. Так как процесс проектирования непрерывен, спецификации постепенно становятся все более детализированными. Конечными результатами процесса проектирования являются точные спецификации на алгоритмы и структуры данных, которые будут реализованы на следующем этапе создания ПО. Этапы процесса проектирования: Архитектурное проектирование Обобщенная спецификация Проектирование интерфейсов Компонентное проектирование Проектирование структур данных Проектирование алгоритмов  (Рис. 3) Дата выполнения – 29.05.2021. Количество часов – 6 часов. Интегрирование программных модулей. Адаптирование программных продуктов и информационных ресурсов к среде функционирования. Интегрирование программных модулей. Интеграция программных моделей — это обмен данными между системами с возможной последующей их обработкой. В процессе анализа этой темы я понял о том, что главный смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник. После небольшого освоения в данной теме я могу выделить основные этапы в процессе интеграции: Определение, какой продукт является источником, а какой – приемником. Сопоставление объектов между источником и приемником. Выбор потока для интеграции. Выполнение постобработки данных. Достаточно важно при интеграции различных программных решений в достаточной степени знать и разбираться в их функционале. Так же не мало важной частью после выполнения основных этапов интеграции является естественно тестирование интеграции. Как я понял, это часть внедрения программного обеспечения. И здесь как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, а так же возможно тестирование непосредственно с самими пользователями. Кроме этого, я могу выделить виды интеграций: односторонняя и двусторонняя. На самом деле, принципиальных отличий у односторонней, двусторонней или многосторонней интеграции не существует. Суть процесса остается прежней, просто в разные моменты времени приемник и источник меняются ролями. Единственное важное правило, которое я ввел для себя: при двухстороннем обмене необходимо хранить уникальный идентификатор для всех систем, которые участвуют в интеграции. Адаптирование программных продуктов и информационных ресурсов к среде функционирования. Я рассмотрел существующие методы адаптации к среде функционирования: 1. Параметрическая адаптация – настройка параметров ПО. Параметрическая адаптация является простейшим видом адаптации и предполагает изменение значений переменных (параметров), определяющих поведение и функционирование программы. При таком подходе можно настраивать функции и компоненты ПО, а также выбирать определенные стратегии поведения из допустимого набора стратегий. 2. Функциональная адаптация - изменение функций ПО в допустимых пределах. Функциональная адаптация обеспечивает изменение функций ПО, в пределах имеющейся структуры и организации системы. При этом допустима параметрическая настройка всего ПО, сохраняющая неизменной ее структуру и организацию для выполнения задач, первоначально заложенных в систему. 3. Организационная адаптация - изменение организации (потоков и процессов) в системе. Организационная адаптация предполагает изменение потоков и процессов, протекающих внутри системы, с возможностью изменения функций и параметрической настройки. При данной адаптации происходит перераспределение внутренних ресурсов системы без изменения ее структуры для достижения более высокой производительности и качественного исполнения решаемых задач. 4. Структурная адаптация – изменение структуры системы. Структурная адаптация предполагает модификацию или замену одних структурных компонентов (алгоритмических модулей) системы другими компонентами, позволяющими программе становиться более адекватной решаемым задачам и условиям функционирования. При этом возможно использование организационной, функциональной и параметрической адаптации системы. 5. Размножение – порождение себе подобных потомков. Размножение, как способ адаптации, является невероятно сложным, но и необычайно эффективным методом адаптации. Оно позволяет системе порождать потомки, со свойствами подобными родительским, но обладающими большими возможностями (наличием свободных ресурсов и способностью к изменениям), что позволяет им более эффективно адаптироваться к существенным изменениям внешней среды. 6. Развитие – направленный процесс эволюции систем. Развитие предполагает как направленный процесс эволюции (изменений) конкретной системы, включающий 4 этапа: зарождение системы, становление системы определенного качества, устойчивое функционирование системы, деградацию и гибель системы, так и популяционно-видовой способ существования и эволюции множеств подобных систем. Таким образом, конкретные системы, порождаясь достаточно простыми, в процессе существования (функционирования) накапливают информацию о себе, о внешней среде и о решаемых задачах и становятся более приспособленными для решения задач, изменяющихся во времени. С другой стороны, параллельное существование систем с разным уровнем развития позволяет более совершенным системам осуществлять обучение менее развитых систем, что порождает процесс коэволюции систем и существенно ускоряет прогресс совершенствования и развития всей популяции систем. Кроме этого, при определенных условиях краткосрочно могут возникать новые виды развивающихся систем, которые будут существенно более адекватны внешней среде и решаемым задачам. Проведенный анализ поколений ПО и используемых методов адаптации позволяет сделать вывод о том, что наука программирования вплотную приблизилась к исследованиям и экспериментам в области создания самоорганизующегося ПО. Дата выполнения - 31.05.2021; количество часов - 6 часов. Проектирование архитектуры программного средства. Построение диаграмм UML. Построение диаграммы Последовательности. Построение диаграммы Кооперации и диаграммы Развертывания. Проектирование архитектуры программного средства. Процесс проектирования архитектуры программного обеспечения состоит в проектировании структуры всех его компонент, функционально связанных с решаемой задачей, включая сопряжения между ними и требования к ним. Архитектура программного обеспечения в традиционном смысле включает определение всех модулей программ, их иерархии и сопряжения между ними и данными. Если разрабатывается отдельная программа, исходными данными для этого процесса будут детальные внешние спецификации. Если разрабатывается система программного изделия, исходными данными для этого процесса будут детальные внешние спецификации и функциональная архитектура системы. Во время разработки архитектуры программного обеспечения выполняется его модульно-иерархическое построение. Модуль — это замкнутая программа, которую можно вызвать из любого другого модуля в программе и можно отдельно компилировать. Стремление к созданию модульных программ объясняется следующими факторами: Программные модули, как правило, решают небольшую функциональную задачу, используют на входе и на выходе немного данных. Модульные программы легко читать, сопровождать и модифицировать. Модульные программы обладают повышенной надежностью, так как при их разработке существует возможность распределения работ по созданию модулей различной сложности и важности между программистами различной квалификации; Можно создавать библиотеки наиболее употребительных подпрограмм, которые затем можно использовать в качестве комплектующих частей при разработке других приложений; Построение диаграмм UML. Унифицированный язык моделирования (UML) играет важную роль в разработке программного обеспечения, а также в системах, не связанных с ИТ, во многих отраслях, поскольку он дает возможность визуально показать поведение и структуру системы или процесса. UML помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах. Преимущества UML: Упрощает сложности Сохраняет возможности открытого общения Автоматизирует производство программного обеспечения и процессов Помогает решить постоянные проблемы с архитектурой Улучшает качество работы Сокращает затраты и время выхода на рынок Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей. От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому. Построение диаграммы Последовательности. Для построения диаграммы последовательности используется шаблон UML Sequence из раздела Software and Database программы Visio. Объекты обычно подписываются в формате «объект:класс» и изображаются как в виде обычных прямоугольников, так и с использованием дополнительных обозначений. В представленном примере объектами являются запрос, обозначенный прямоугольником, а также тренер и клиент, обозначенные элементом «Актер». Линия жизни (англ. lifeline) идет вертикально вниз от каждого объекта и упорядочивает сообщения на странице таким образом, чтобы они читались сверху вниз. Каждая линия жизни имеет полосу активности, показывающую интервал активности участника при взаимодействии. Сообщения показывают взаимодействие между объектами в виде горизонтальной стрелки, концы которой лежат на линиях жизни. Направление стрелки указывает на адресата, а положение на линии жизни упорядочивает сообщения по времени. Условия, как и циклы, изображаются с помощью фреймов взаимодействий (англ. interaction frames), позволяющих разметить диаграмму взаимодействия. Каждый фрейм представляет собой разделенную на несколько фрагментов область диаграммы, причем каждый фрейм имеет оператор, а каждый фрагмент может иметь защиту. Для отображения цикла применяется оператор loop с единственным фрагментом, причем тело итерации помещается в защиту. Пример диаграммы последовательности на рисунке 4.  (Рис. 4) Построение диаграммы Кооперации и диаграммы Развертывания. Схема последовательностей UML показывает, как набор объектов взаимодействует с процессом с течением времени. Здесь показаны сообщения, которые передаются между участниками и объектами в системе, и порядок их ветвях.  (Рис. 5) Чтобы создать схему последовательностей, используйте шаблон или начните схему последовательностей UML, которая включает в себя ряд последовательностей UML. Запустите Visio. Если файл уже открыт, щелкните Файл > Создать. В поле поиска введите последовательность UML. Выберите схему последовательностей UML. В диалоговом окне выберите пустой шаблон или одну из трех схем. Нажмите Создать. Откроется схема. Вы увидите окно Фигуры рядом со схемой. Если она не видна, перейдите в > области задач и убедитесь, что выбрана фигура. Если вы по-прежнему не видите его, нажмите кнопку слева на кнопке "Развернуть окно "Фигуры". На вкладке Вид установите флажок Точки соединения. Этот параметр позволяет отображать точки соединения при соединении фигур. Затем перетащите фигуры, которые вы хотите включить в схему, из окна Фигуры на страницу. Чтобы изменить подписи, дважды щелкните их. Используйте фигуру линии жизни субъекта для каждого участника, а фигуру линии жизни объекта для каждого системного компонента в процессе.  (Рис. 6) (Рис. 7)Если одно или несколько взаимодействий образуют цикл или требуется условие для его окончания, заключите эти взаимодействия в фигуру фрагмента: Фрагмент "Цикл" используется для базового повторяютого взаимодействия. Используйте необязательный фрагмент для шагов, которые выполняются только в том случае, если выполняется определенное условие. Используйте фигуру "Альтернативный фрагмент" для обработки или взаимодействия с помощью "если", "если", "если", "иначе". В этом фрагменте есть два раздела, с помощью которых можно показать альтернативное взаимодействие. Чтобы добавить другое условие, перетащите на фигуру операнд взаимодействия.  (Рис. 8)Перетащите фигуру фрагмента к взаимосвязанию. Чтобы все связанные взаимодействия были заключены в фигуру фрагмента, используйте соответствующие дес.висячие дес. Дважды щелкните заголовок фигуры фрагмента, чтобы добавить название или краткое описание процесса, окруженного фрагментом. Под заголовком щелкните запрос [parameters], если вы хотите ввести условия, которые могут закончить этот процесс. Поместите фигуру панели активации на линию жизни, чтобы показать, когда и как долго этот объект или участник активен в процессе. Обычно для демонстрации потока данных используются стрелки в поле активации. Перетащите конечные точки панели активации вверх или вниз, чтобы сделать их нужной длиной.  (Рис. 9)Он указывает на то, что в системе участвует объект или субъект. В конце жизненного горизонта появится большой X. Создание диаграммы Кооперации и диаграммы Развёртывания. Понятие кооперации – одно из фундаментальных в языке UML. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных вариантов использования или наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.  <собственное имя объекта >'/'<Имя роли класса>:<Имя класса >.   Графическое изображение активного объекта (слева) на диаграмме кооперации  Сообщения в языке UML также специфицируют роли, которые играют объекты — отправитель и получатель сообщения. Сообщения на диаграмме кооперации изображаются дополнительными стрелками рядом с соответствующей связью или ролью ассоциации. Направление стрелки указывает на получателя сообщения. Внешний вид стрелки сообщения имеет определенный смысл. На диаграммах кооперации может использоваться один из трех типов стрелок для обозначения сообщений. Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат: <Предшествующие сообщения> <Выражение последовательности> <Возвращаемое значение := имя сообщения> <(Список аргументов)> Построение диаграммы кооперации можно начинать сразу после построения диаграммы классов. При разработке диаграмм кооперации вначале изображаются объекты и связи между ними. Далее на диаграмму кооперации необходимо нанести все сообщения, указав их порядок и другие семантические особенности. Диаграмма кооперации может содержать только те объекты и связи, которые уже определены на построенной ранее диаграмме классов. В противном случае, если возникает необходимость включения в диаграмму кооперации объектов, которые создаются на основе отсутствующих классов, то диаграмма классов должна быть модифицирована посредством включения в нее явного описания этих классов. Диаграмма развертывания – это тип UML-диаграммы, которая показывает архитектуру исполнения системы, включая такие узлы, как аппаратные или программные среды исполнения, а также промежуточное программное обеспечение, соединяющее их. Диаграммы развертывания обычно используются для визуализации физического аппаратного и программного обеспечения системы. Используя его, вы можете понять, как система будет физически развернута на аппаратном обеспечении. Диаграммы развертывания помогают моделировать аппаратную топологию системы по сравнению с другими типами UML-диаграмм, которые в основном описывают логические компоненты системы. Узлы Узел, представленный в виде куба, представляет собой физическую сущность, которая выполняет одну или несколько компонентов, подсистем или исполняемых файлов. Узел может быть аппаратным или программным элементом. Артефакты Артефакты – это конкретные элементы, которые вызваны процессом разработки. Примерами артефактов являются библиотеки, архивы, конфигурационные файлы, исполняемые файлы и т.д. Коммуникационная ассоциация |
