Методические указания. МУ К ПЗ ТРПО ПКС. Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения
 Скачать 5.82 Mb.
|
|
Тема 1.8. Инструментальные средства интеграции Практическое занятие 19-20. Тема: Внедрение программного обеспечения. Цель работы: разработка сценария внедрения программного продукта. Продолжительность занятия: 4 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Внедрение программного обеспечения в информационных системах Полный спектр работ согласно пожеланиям заказчика, начиная от инсталляции, адаптации и наладки программного обеспечения и до интеграции с устройствами и передачи в эксплуатацию, называется внедрением ПО в систему. Время и стоимость комплекса работ зависят от множества факторов и критериев выполнения, указанных заказчиком или необходимых для стабильности, таких как: готовность персонала компании к переходу на новое ПО или его освоению; наличие необходимых для выполнения аппаратных средств; особенностей выполнения работы; масштаба предполагаемых действий; состояния баз данных на текущий момент, наличия резервных копий на крайний случай; наличия и работоспособности каналов связи. Процесс поэтапного внедрения программного обеспечения Поскольку процедура внедрения ПО может вызвать перебои в работе компании, процесс разделяется на несколько этапов, каждый из которых имеет свои нюансы и осуществляется после строгого согласования с заказчиком. Этап 1. Обследование компании Перед созданием проекта выполняется исследование текущей работы компании профессионалами. По окончании предварительного обследования и аудита заказчик получает рекомендации, связанные с разработкой технического задания на производство работ. В нем уделяется внимание каждой мельчайшей детали, подробно описаны требования по: подготовке и требованиям к техсредствам; формату хранения и передачи данных и резервных архивов; составу и выполнению подготовительных работ для объекта; конфигурированию системы передачи информации; работе общего и прикладного программного обеспечения. Качественно составленное ТЗ гарантирует точность выполнения работ. Этап 2. Составление контракта на производство работ Контракт на производство работ составляется по совместному заключению заказчика и компании после выполнения анализа ТЗ. Этот период — оценочный. Поскольку план работ назначен и сроки определены, компания-исполнитель может оценить всю процедуру в комплексе и определиться с ценой. Чаще всего первичный этап производится бесплатно или становится таковым на основании последующего заказа. Цена на выполнение работ по интеграции программного обеспечения может зависеть от следующих факторов: состава и количества рабочих мест, подсистем и модулей; проведения дополнительных работ по интеграции с другими подсистемами и системами, а также сложности ее исполнения; объема хранимой в БД информации и ее состояния (работоспособности и наличие резервных копий). Этап 3. Создание группы по внедрению ПО Третий период также входит в подготовительные работы. Компанией-исполнителем формируется группа внедрения программного обеспечения и назначаются ответственные. Этап 4. Инсталляция и наладка ПО В этот период производится инсталляция программного обеспечения на серверах и клиентских машинах, подключение связи, а также проверка и наладка рабочего состояния системы и ее тестирование под нагрузкой. В стандартный перечень работ по четвертому этапу входит: установка и подготовка общесистемного ПО сервера; инсталляция и наладка компонентов и функций серверной платформы; создание таблиц баз данных, загрузка информации и интеграция; перенос БД (при необходимости), конвертация в нужный формат, наладка и создание рабочих копий ПО, подготовка программ; установка и подготовка клиентских машин (общеприкладное и прикладное ПО); интеграция и адаптация с уже имеющимися системами и платформами; проверка работоспособности всей системы, тестирование функционирования комплекса программного обеспечения; окончательная настройка по результатам тестирования с целью получения максимальной производительности и оптимизации работы. На этом процесс внедрения программного обеспечения завершен, однако существуют дополнительные процедуры, которые множество компаний называет постустановочными. Завершение внедрения и проведение дополнительных работ Завершение внедрения ПО включает выполнение следующих работ: обучение группы специалистов со стороны заказчика работе с новым ПО — может производится удаленно или на территории заказчика; внесение изменений согласно опыту эксплуатации, заказчиком нового ПО; по окончании внесения условленных изменений и устранения замечаний подписывается акт сдачи работ и приемки проекта согласно ТЗ, после чего система передается заказчику, и операция по внедрению считается завершенной. После интеграции программного обеспечения со стороны заказчика могут возникнуть проблемы. Это может быть человеческий фактор или недостаточная оптимизация и интеграция с незаявленными в ТЗ системами, которые косвенно касаются внедренного ПО. В связи с этим компании оказывают техническую поддержку как своих, так и интегрированных сторонними компаниями систем. Поддержка и сопровождение работы серверов не входит в оплату по основным работам, производимым по техническому заданию. Порядок выполнения работы Согласно индивидуальному заданию из приложения Б, разработать план внедрения системы. Форма отчета: План внедрения, оформленный в Microsoft Word. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.9. Технологии коллективной разработки Практическое занятие 21. Тема: Разработка проекта с использованием команды разрешения конфликтов. Цель работы: разработка стратегии решения конфликтных ситуаций. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Конфликт представляет собой предельное обострение противоречий. В то же время противоречие и конфликт не тождественны. Конфликт вероятен лишь в случае, когда обострение противоречий между Ценами коллектива становится помехой нормальному их взаимодействию в трудовом процессе или делает такое взаимодействие невозможным. Конфликты, как правило, отрицательно сказываются на нервно-психологическом состоянии людей, поэтому необходимо учиться правильному поведению при их разрешении. Конфликт — столкновение противоположных интересов, взглядов, целей, позиций, мнений двух или нескольких людей. В основе любого конфликта лежит конфликтная ситуация, а также противоположные средства достижения цели. Для возникновения разрастания конфликта необходим инцидент (повод), когда одна сторона начинает действовать, ущемляя (пусть неумышленно) интересы другой Типы конфликтов, причины их возникновения Существуют четыре основных типа конфликтов: внутриличностный, межличностный, конфликт между личностью и группой, межгрупповой. Внутриличностный конфликт не соответствует приведенному выше "классическому" определению конфликта. Однако его потенциальные деструктивные последствия аналогичны последствиям других типов конфликта. Он может принимать различные формы. Одна из самых распространенных форм — ролевой конфликт, когда к одному человеку предъявляются противоречивые требования по поводу того, каким должен быть результат его работы. Например, руководителю производственного подразделения его непосредственный начальник дает указание наращивать выпуск продукции, а руководитель по качеству настаивает на повышении качества продукции путем замедления производственного процесса. Внутриличностный конфликт может также возникать в ответ на рабочую перегрузку или недогрузку. Исследования показывают, что такой внутриличностный конфликт связан с низкой степенью удовлетворенности работой, недостаточной уверенностью в себе и организации, а также со стрессом. Межличностный конфликт самый распространенный. В организациях он проявляется по-разному. Чаще всего это борьба руководителей за ограниченные ресурсы, финансы или рабочую силу, время использования оборудования или одобрения проекта. Каждый из руководителей считает, что, поскольку ресурсы ограничены, он должен убедить вышестоящее начальство выделить эти ресурсы именно ему, а не другому. Конфликт между личностью и группой может возникнуть, если эта личность займет позицию, отличную от позиции группы. Например, кто-то хочет выполнять сверхурочную работу или перевыполнять норму, а группа не согласна с этим. Аналогичный конфликт может возникнуть на почве должностных обязанностей руководителя: между необходимостью обеспечивать соответствующую производительность труда и наряду с этим соблюдать правила и процедуры организации. Руководитель может принять дисциплинарные меры, которые окажутся непопулярными в глазах подчиненных. Тогда группа может нанести "ответный удар" — изменить отношение к руководителю и, возможно, снизить производительность труда. Межгрупповой конфликт. Организации состоят из множества групп, как формальных, так и неформальных. Даже в самых лучших организациях между такими группами могут возникнуть конфликты. Неформальные группы, которые считают, что руководитель относится к ним несправедливо, могут крепче сплотиться и попытаться "рассчитаться" с ним снижением производительности труда. Последствия конфликтов Конструктивные последствия конфликта. Их много. Одно из них заключается в том, что проблема может быть решена приемлемым для всех сторон путем. В результате люди будут больше чувствовать свою причастность к решению этой проблемы. Это, в свою очередь, сведет к минимуму или совсем устранит трудности в осуществлении решений — враждебность, несправедливость и необходимость поступать против воли. Другое конструктивное последствие состоит в том, что стороны больше расположены к сотрудничеству, а не к антагонизму в будущих конфликтных ситуациях. Одно из конструктивных последствий разрешения конфликта — улучшение качества принятия решений. В процессе разрешения конфликта члены команды имеют дополнительную возможность проработать даже противоположные идеи и варианты. Могут быть также заранее проанализированы все последствия и возможные трудности до того, как решение начнет выполняться. Деструктивные последствия конфликта. Если не попытаться найти эффективный способ управления конфликтом, то могут возникнуть деструктивные последствия, иначе говоря, условия, препятствующие достижению целей. Управление конфликтной ситуацией Руководитель бизнес - проекта должен начать разрешение конфликта с анализа фактических причин, а затем использовать соответствующую методику. Существует несколько действенных способов управления конфликтной ситуацией, которые можно разделить на две категории: структурные и межличностные. Приведем структурные методы разрешения конфликта: Разъяснение требований к работе. Одним из лучших методов управления, предотвращающих деструктивные конфликты, является разъяснение того, какие результаты ожидаются от каждого сотрудника и подразделения, уровень требуемых результатов, кто предоставляет различную информацию и кто ее получает, какова система полномочий и ответственности, а также принятых процедур и правил. Координационные и интеграционные механизмы. Имеется в виду, что установление иерархии полномочий упорядочивает взаимодействие людей, процедуру принятия решений и информационные потоки внутри организации. Если два или более подчиненных имеют разногласия по какому-то вопросу, то конфликта можно избежать, обратившись к их общему начальнику для принятия решения. Общие организационные цели. Осуществление этих целей требует совместных усилий всех сотрудников, отделов и подразделений. Например, если три смены производственного отдела конфликтуют между собой, то следует сформулировать цели для всего отдела, а не для каждой смены в отдельности. Аналогично установление четко сформулированных целей для всего проекта способствует тому, что руководители отделов будут принимать решения, благоприятствующие всей организации, а не только их собственной функциональной области. Использование системы вознаграждений. За достижение общеорганизационных комплексных целей члены команды могут вознаграждаться благодарностью, премией, признанием или повышением по службе. Не менее важно, чтобы система вознаграждений не поощряла неконструктивное поведение отдельных лиц или групп. Например, если награждать руководителей отдела продаж только на основе увеличения объема проданных товаров, то это может вступить в противоречие с намеченным уровнем получения прибыли. Руководители этого отдела могут увеличить объем сбыта, предлагая без всякой надобности скидки и тем самым снижая уровень средней прибыли компании. Управление конфликтами в MSF Все, что было описано выше, относится к классической теории разрешения и управления конфликтами. Однако, какие же средства для управления конфликтами предоставляет MSF. Если рассмотреть методы разрешения конфликтов, изложенные выше, то можно сделать нижеследующий вывод. Большая часть этих методов реализуется в процессе фазы выработки концепции (Envision). Естественно, обязанность по разрешению конфликтных ситуаций должен взять на себя менеджер проекта. Если говорить подробнее, то разрешение конфликтов входит в такую область управления конфликтами, как управление персоналом (Staff Resource Management), см. таблицу ниже. Алгоритм решения конфликтов в команде Определите, требует ли конфликт решения. Отличайте конструктивный рабочий конфликт, который не стоит решать, от деструктивного перехода на личности или реализации амбиций в ущерб рабочему процессу Определите, какие цели в конфликте преследуют конфликтующие. Зачем им надо конфликтовать? Нуждаются ли они в помощи или могут решить конфликт самостоятельно. Переводите участников конфликта от общих суждений к конкретным фактам. Задавайте уточняющие вопросы. Эти методы помогут им полнее понять ситуацию и уйти от излишних эмоций. Задавайте вопросы для выяснения мотива каждого из конфликтующих. Выяснив мотивы вы выясните пути решения конфликта. Не принимайте ни одну из сторон конфликта и не принимайте решение за конфликтующих. Не критикуйте и не выносите суждений на этом этапе. Выслушайте обе стороны и попросите высказаться, какое решение конфликта они видят, договоритесь о совместном процессе. Каждый участник конфликта должен согласиться сотрудничать в разрешении конфликта. Выработайте пути решений. Достигните соглашения. Определите, что и как должно быть сделано, составьте план и временные рамки. Убедитесь, что ответственность за соглашение и действия лежит на сторонах конфликта и они это признают. Приступите к реализации решения Порядок выполнения работы В соответствии с индивидуальным вариантом из приложения Г, разработать способ разрешения конфликтной ситуации. Форма отчета: Стратегия разрешения конфликтной ситуации, оформленная в документ Word Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.9. Технологии коллективной разработки Практическое занятие 22. Тема: Разработка проекта с использованием ветвей и тэгов. Цель работы: изучить работу с ветвями и тэгами. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Основные понятия: о ветке Git и master Под веткой принято понимать независимую последовательность коммитов в хронологическом порядке. Однако конкретно в Git реализация ветки выполнена как указатель на последний коммит в рассматриваемой ветке. После создания ветки уже новый указатель ссылается на текущий коммит. Имя основной ветки Git-проекта по умолчанию — master (однако зачастую бывает main, например, в GitHub), она появляется сразу при инициализации репозитория. Эта ветка ничем не отличается от остальных и также ее можно переименовать, но по договоренности master принято считать главной веткой в проекте. Что делает git branch Команда git branch — главный инструмент для работы с ветвлением. С ее помощью можно добавлять новые ветки, перечислять и переименовывать существующие и удалять их. Чтобы в Git добавить ветку мы используем: $ git branch После данной операции ветка уже была создана, но вы по-прежнему находитесь в прежней ветке. Если вы планируете переместиться на другую ветку, в том числе только что созданную, необходимо написать checkout: $ git checkout Для того чтобы определить, где сейчас находится разработчик, Git использует специальный указатель HEAD, ссылающийся на текущую локальную ветку. В результате checkout HEAD переместится на иную ветку. Чаще всего при создании новой ветки git пользователю необходимо сразу же переключиться на нее. В таком случае стоит использовать: $ git checkout branch Это будет равносильно: $ git branch $ git checkout И также мы получим тот же результат при использовании git checkout с ключом -b: $ git checkout -b Если пользователю нужно получить список определенного множества веток, то тогда можно воспользоваться ключами. Одними из самых распространенных будут: -r — при использовании этого ключа мы получим список удаленных веток, -a — используя этот параметр, в выводе будут удаленные и локальные ветки. О команде git checkout При выполнении этой команды Git требуется осуществить определенный порядок действий, чтобы переходить на ветку, которую мы указали. Для этого программа выполняет следующий алгоритм: Проверка, что указанная нами ветка существует в проекте Этот этап необходим, так как в ином случае программа не сможет переключиться на ветвь, которая не определена. Для большего понимания нужно вспомнить, что такое ветка в git. Учитываем, что фактически задание ветки — это запись коммита, на который она ссылается. Внутри Git наличие конкретной ветки проверяется наличием одноименного файла в конкретной директории. Переключение указателя HEAD на новую ветку Необходимо сместить указатель, чтобы Git понимал, где сейчас идет работа. Изменение рабочей версии таким образом, чтобы новая ветка ей полностью соответствовала Сама концепция работы ветвления заключается в том, что в разных ветках находятся разные версии кода, над которыми работа ведется отдельно друг от друга. Тогда необходимо изменить рабочую копию. Git берет последний коммит и восстанавливает все изменения. После завершения всех перечисленных выше действий можно считать, что мы полностью переключились. Также с помощью checkout можно извлечь отдельный файл (или папку) из другой ветки и получить его, предварительно перейдя в ту ветку, куда вы собираетесь перенести файл. Для этого выполняем: $ git checkout Основы ветвления и слияния Ветвление позволяет разделять рабочий процесс, оптимизировать тестирование и написание нового кода. Однако после того, как разработчик убедился, что написанный им кусок кода готов и его можно отправить к остальной части итоговой версии, удобно переместить его в основную ветку. Такой подход дает возможность получить к концу разработки проекта целый продукт в одном месте. Для этого в Git предусмотрено слияние — перенос изменений с одной ветки на другую. Однако сливаемая ветка (под этим определением мы подразумеваем ветку, у которой берем изменения для «вливания» их в другую ветвь) никак не меняется и остается в прежнем состоянии. Такие преобразования мы получаем, применив git merge: $ git merge Операция может привести к появлению конфликтов при попытке слить ветки. Это вызвано тем, что изменения удаляют или переписывают информацию в существующих файлах. При попытке некорректного слияния Git останавливает выполнение команды, чтобы вы могли разрешить конфликт. Также стоит упомянуть о существовании ключей, предназначенных специально для работы с конфликтами: —abort — прерывает слияние и возвращает все к началу —continue — продолжает слияние после разрешения конфликта Решить конфликт можно двумя способами: Вручную разрешить файловый конфликт. Для этого нужно самим изменить файлы, с которыми возникли проблемы. Мы получим файлы такими, какими и представляли их при попытке слияния. Выбрать более подходящий файл, а от второго отказаться. Управление ветками с помощью git branch Эта команда может немного больше, чем просто в git создавать ветки из текущей. Если запустить ее без параметров: $ git branch При выполнении этой строки мы получим список существующих веток, где символом * будет отмечена ветка, где вы сейчас находитесь. Это может выглядеть так: first_branch * master second_branch С помощью параметра -v можно получить последний сохраненный коммит в каждой ветке. $ git branch -v first_branch 8fa301b Fix math * master 225cc2d Merge branch 'first_branch' second_branch c56ee12 Refactor code style Так же существуют опции —merged и —no-merged, с помощью которых можно отфильтровать полученную последовательность веток. То есть мы получим список ответвлений, которые уже были слиты, или, наоборот, ветки, которые еще не прошли через слияние с другими. Выведем ветки, которые уже были слиты с текущей: $ git branch --merged first_branch * master Как закоммитить изменения в новую ветку После создания новой ветки, перехода в нее и совершения всех запланированных преобразований, нужно сделать коммит в эту же ветку, чтобы сохранить все изменения. Команды для выполнения этих действий ничем не отличаются от команд для создания коммитов в ветке мастер. $ git add $ git commit -m ' После выполнения последовательности этих команд мы закоммитили изменения в нужной версии программы. Как запушить в новую ветку Если мы хотим запушить нашу ветку, то для этого нужно написать: $ git push origin Теперь ветка запушена. Если до этого мы уже пушили ее, то произойдет отправка новых коммитов. В отличии от команды git checkout, при выполнении пуша нет проверки на существование указанной ветки. Это будет значить, что при написании несуществующей ветки git создаст ее автоматически. Как переименовать ветку В процессе разработки могут возникнуть ситуации, когда человек хочет по-другому называть уже созданную ветку. Это может быть связано с разными причинами (например, разрабатываемый в данной версии функционал не соответствует названию). Чтобы переименовать ветку применяем: $ git branch -m Однако здесь нужно быть аккуратными, чтобы не перегрузить проект ненужными ветками. Если запушить переименованную ветку, то на сервере появится ветка с новым именем, но и ветка со старым названием тоже останется. Чтобы избежать такой проблемы, необходимо удалить ветку локально и на сервере. Как удалить ветку Удаление веток не такой простой процесс, как может показаться. Можно случайно удалить несохраненные изменения в исходном коде, что приведет к нежелательным последствиям. Поэтому здесь нужно действовать осторожно. С операцией удаления над ветками справляется уже привычная команда git branch с параметром -d: $ git branch -d Для корректного удаления нужно помнить несколько правил, чтобы не получить ошибки: Нельзя удалить ветку, в которой вы находитесь. Git выкинет ошибку и не произведет удаление. Следовательно, нужно перейти на другую ветку. Git не позволит удалить ветку, у которой есть несохраненные изменения. Так мы избегаем ситуации, когда часть написанного кода будет безвозвратно утеряна. Если же мы уверены, что изменения в этой версии не нужны и их можно смело удалять, то вместо флага -d используем -D: $ git branch -D Соблюдая все условия, нам удастся удалить указанную ветвь. Порядок выполнения работы 1. Добавьте новую ветку 2. Определите, где сейчас находится разработчик 3. Перейдите в ранее созданную ветку 4. Получить список существующих веток и последний сохраненный коммит в каждой ветке. 5. Оформить отчет о проделанной работе Форма отчета: Отчет, оформленный в документе Word Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.9. Технологии коллективной разработки Практическое занятие 23-24. Тема: Интеграция СКВ в проектную инфраструктуру. Цель работы: знакомство с командной разработкой с помощью СКВ. Продолжительность занятия: 4 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Порядок выполнения работы Создаем свой первый проект и выкладываем на GitHub Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code). Перед началом предлагаю зарегистрироваться на GitHub. Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.  После открываем VS Code. 1. Установите себе дополнительно анализаторы кода для JavaScript и PHP 2. Откройте вашу папку, которую создали ранее После этого у вас появится вот такой интерфейс  1. Здесь будут располагаться все файлы вашего проекта 2. Здесь можно работать с Git-ом 3. Кнопка для создания нового файла 4. Кнопка для создания новой папки Если ваш проект пустой, как у меня, то создайте новый файл и назовите его index.html . После этого откроется окно редактирование этого файла. Напишите в нем ! и нажмите кнопку Tab . Автоматически должен сгенерироваться скелет пустой HTML страницы. Не забудьте нажать ctrl+s чтобы файл сохранился. Давайте теперь перейдем во вкладу для работы с Git-ом.  Откроется вот такое окно: 1. Кнопка для публикации нашего проекта на GitHub 2. После нажатия на кнопку 1 , появится всплывающее окно. Нужно выбрать второй вариант или там где присутствует фраза ...public repository Если вы хотите создать локальный репозиторий и опубликовать код в другой сервис, то необходимо нажать на кнопку Initialize Repository . После этого, вручную выбрать сервис куда публиковать. После того, как выбрали "Опубликовать на GitHub публичный репозиторий" (пункт 2), программа предложит вам выбрать файлы, которые будут входить в первый commit. Проставляем галочки у всех файлов, если не проставлены и жмем ОК . Вас перекинет на сайт GitHub, где нужно будет подтвердить вход в аккаунт. Вы создали и опубликовали репозиторий на GitHub. Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.  Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем: 1. Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки 2. Добавляем наш файл для будущего commit 3. Пишем комментарий 4. Создаем commit 5. Отправляем наш commit в GitHub Индивидуальное задание: Попробуйте в команде подключиться к репозиторию и совместно поработать над проектом через VS Code. Все изменения также отправьте с помощью commit. Желательно изменять разные файлы проекта каждым членом команды. Форма отчета: Отчет, оформленный в документе Word. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.10. Управление проектом Практическое занятие 25-26. Тема: Взаимодействие между участниками проекта, создание IRC, листов рассылок. Цель работы: организация коммуникации в команде разработчиков. Продолжительность занятия: 4 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Лист рассылки представляет собой единый «сборный» email, некую группу, в которую вы включаете нужных вам получателей из адресной книги. Как правило, если для рассылки конкретного письма кого-то из участников вам нужно удалить, править сам лист не нужно: достаточно «раскрыть» его прямо в поле «Получатель» и временно удалить оттуда конкретный адрес. Как минимум функция есть в MS Outlook, mail.yandex, gmail и Lotus’e, насчет других не в курсе, но почти уверена, что она есть везде. При отправке на лист рассылки письмо уходит сразу всем участникам, и вам не нужно думать о том, не забыли ли вы кого-то. Так же вы точно уверены, что информацию все получили, и при необходимости на нее среагируют. Использование листов снимает огромное количество недопониманий, недосказанностей и в значительной мере снижает риски проекта, не говоря уже об удобстве. Особую ценность использование листов рассылки приобретает на кризисных проектах, когда все нужно делать очень быстро, времени детально оценивать риски часто нет, а решения приходится принимать наполовину на интуиции. В таких случаях, команде жестко обозначают, что: Проект переведен в «кризисный» режим, и пока он из этого режима не выйдет, любая коммуникация идет через лист рассылки и только через него. Отвечать на письма, присланные вне листа рассылки, можно только с копией на лист рассылки и с одновременной жалобой руководителя проекта. Если из-за неиспользования лист поедут сроки или еще что-то случится – вина за тем, кто эту цепочку начал и кто не прервал, со всеми возможными применимыми санкциями. Если коммуникация была на встрече, по телефону или еще в какой-то форме – результаты и принятые решения немедленно после ее окончания дублируются на лист рассылки. Иначе считаем, что коммуникации не было. Предназначение полей. Поля – это объекты, предназначенные для автоматической вставки в основной документ данных (дат, текстов, рисунков или других объектов), которые могут принимать значения по определенным правилам, а также для организации вычислений в документах. Поля используют для подготовки типичной документации с постоянной и сменной информацией, например, бланков, анкет, деловых писем многим адресатам, конвертов и т.п. В программе Word различают три типа полей: стандартные поля, поля слияния и поля формы. Поля слияния. Поля слияния – это особый тип полей, используемых для создания копий типичных документов (писем, конвертов, наклеек) методом слияния двух документов: основного и источника данных. Поля данных для слияния называют Merge-Field, а конкретные их имена придумывает пользователь. Основной документ включает неизменную часть текста и вставленные пользователем поля слияния для данных, значения которых будут меняться. Эти значения будут вставляться в основной документ из источника данных, созданного пользователем. Коды полей данных – это имена полей, придуманные пользователем для своих данных, например, Город, Улица, Фамилия и т.п. Количество полей и их коды определяют заранее по условию задачи. Поле данных пользователь вставляет специальной командой Вставить поля слияния, выбирая имя поля из списка предложенных имен. Система автоматически вставляет имя поля в основной документ в точку вставки в двойных угловых скобках. Поля {Date} и {Author} стандартные. Остальные поля являются полями слияния данных. Помните, что имена полей вручную, как в образце письма, вводить нельзя. Этот процесс автоматизирован. Источником данных может быть заранее созданный и записанный на диск файл базы данных или текстовый файл, где данные набраны в приведенном выше виде (подходящем для преобразования в таблицу). Работа упрощается, если база данных с соответствующими именами полей была создана раньше. Тогда источник данных создавать не нужно, остается его только использовать. Суть слияния документов заключается в том, что в результате слияния получим определенное количество однотипных писем, написанных разным людям (приглашение на банкет, встречу, свадьбу и т.п.). Вместо имен полей будут подставлены их конкретные значения, а угловые скобки печататься не будут. Чтобы убедиться, что письма написаны разным людям, нужно щелкать на кнопке-счетчике или щелкнуть на кнопке Слияние в новый документ – все письма можно будет просмотреть с помощью полосы прокрутки. Создание однотипных документов для рассылки. В MS Word эту задачу можно решить посредством диалогового окна команды Слияния и панели инструментов Слияние. В новых версиях программы ее решают с помощью мастера слияния. После выполнения команд Сервис → Письма и рассылки → Слияние… нужно выполнить шесть шагов. 1. Выбрать тип документа (выбираем подчеркнутое): письма, конверты, сообщение, каталоги, наклейки → Выполнить команду Далее. 2. Выбрать документ: текущий, шаблон, существующий → Далее. 3. Выбрать получателей: использование списка, создание списка. Выполнить команду Создать список. В окне новый список адресов нажать на последнюю кнопку Настройка … и, пользуясь другими кнопками, добавить, удалить или переименовать имена полей данных для слияния, а также упорядочить их в порядке использования (с помощью кнопок Вверх, Вниз) → ОК. Ввести адрес и другие данные одной особы. Выполнить команду Создать запись и ввести данные второй особы и т.д. Закрыть окно. Сохранить список как базу данных в формате mdb под именем Список. Просмотреть список в окне Получатели слияния, внести изменения, если нужно → ОК → Далее. 4. Создать главный документ (письмо), набрав неизменяемую часть текста письма и вставив поля базы данных с помощью команды Другие элементы. 5. Просмотреть письма. На этом этапе можно удалить отдельное письмо, скорректировать список адресатов, найти конкретного адресата → Далее. 6. Закончить слияние. На этом этапе можно внести изменения в письма, выполнить команду печати всех или выбранных писем, сохранить созданный файл на диске. Аналогично создают конверты и наклейки. Порядок выполнения работы 1. Запустите текстовый редактор и создайте новый документ. Выполните команду Сервис → Параметры, вкладка Вид. Выключите режим Коды полей. 2. Новый документ объявите документом слияния на бланке. Сервис → Письма и рассылки → Мастер слияния… Этап 1 из 6 - Выбор типа документа. Выбираем документ Письма. → Далее. Открытие документа. Этап 2 из 6 – Выбор документа. Выбираем Текущий документ. → Далее. Выбор получателей. 3. Создайте источник данных для описанного в теоретических сведениях типичного банковского письма с такими полями: Фамилия, Имя, Индекс, Город, Улица, Сумма, Окончание. Этап 3 из 6 - Выбор получателей. Выбираем Создание списка. Кнопка Создать. Кнопка Настройка. Выбираем поля (если нужно переименовываем). Затем создаем список адресатов и сохраняем его в вашей папке с именем Ваша фамилия Получатели. → Далее. Создание письма. 4. Создайте основной документ – текст письма от банка. Этап 4 из 6 – Создание письма. Введите текст письма из теоретической части (рис.1). Поля данных для слияния вставляйте специальной командой Добавить поле слияния на панели инструментов Слияние, выбирая имена полей из предложенного списка. Сохраните шаблон письма в своей папке с именем Ваша фамилия Шаблон письма → Далее. Просмотр писем. 5. Просмотрите созданные письма. Этап 5 из 6 – Просмотр писем. Воспользуйтесь кнопками перехода между письмами. → Далее. Завершение слияния. 6. Выполните слияние документов в новый документ. Этап 6 из 6 – Завершение слияния. На панели инструментов Слияние нажать кнопку Поиск ошибок и выбрать Создать составной документ, сообщая об ошибках по мере их обнаружения. 7. Сохраните документ с письмами в своей папке под именем Ваша фамилия Слияние. Форма отчета: Лист рассылки. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.10. Управление проектом Практическое занятие 27. Тема: Организация хранения кода. Цель работы: Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. На GitHub вы учитесь и участвуете в других проектах, храните код для работы или учебы, берете код других проектов и вникаете во все детали. Для начала необходимо запомнить следующие терминальные команды: git clone git status git add git commit -m “ “ git push Затем к ним добавим еще вот эти: git init git branch git merge git checkout Эти команды вам пригодятся в случае, если вы будете работать с другими людьми или захотите внести какие-то изменения в проект и протестировать их до создания коммита. Не лишней будет и вот такая команда: git help Шаг 1: Регистрация и установка Зайдите на GitHub и создайте свой аккаунт. В принципе, этим можно и ограничиться. При желании можете установить Git. Но для работы с GitHub это вовсе не обязательно. Однако если вы планируете заниматься проектами на локальном компьютере, то установка вам все-таки нужна. Теперь перейдите в терминал, и начнем работу. Если хотите задать одно имя пользователя для всех репозиториев на компьютере, то напишите: git config — global user.name “<ваше_имя>” замените <ваше_имя> на свое имя в кавычках. Можете написать все, что угодно. Если хотите задать имя только для одного репозитория, то удалите из команды слово global. Теперь напишите свой адрес электронной почты. Проследите, чтобы он совпадал с адресом, указанным при регистрации на GitHub. git config — global user.email “<адрес_почты@email.com>” При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.Теперь вы готовы к работе с Git на локальном компьютере. Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта. Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит. Вот как начать работу с Git из терминала. Если у вас есть директория проекта, то просто перейдите в терминал, а в самой директории проекта выполните команду git init Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду git init Допустим, в вашем проекте есть папка new_project. Вы можете перейти в нее из окна терминала и добавить локальный репозиторий. Это делается через следующую команду: cd new_project git init В вашем проекте появилась новая скрытая директория с названием.git. Именно здесь Git хранит все, что ему нужно для отслеживания проекта. Теперь вы можете последовательно добавлять файлы в область подготовки: git add <имя_первого_файла> или добавьте сразу все файлы через: git add. Создать коммит с этими изменениями можно через команду: git commit -m “<сообщение_коммита>” Если изменения вас устраивают, напишите: git push и отправьте эти изменения в репозиторий. Проверить, есть ли изменения для отправки, можно в любое время по команде: git status При внесении изменений следует обновить и сами файлы: git add <имя_файла> или git add — all Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий. Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master. Порядок выполнения работы 1. Разработать программу в соответствии с индивидуальным заданием из приложения А. 2. Опубликовать на GitHub код своего приложения. 3. Загрузить и распаковать код на другом устройстве. Запустить выполнение программы. Форма отчета: Отчет, оформленный в документе Word, корректно работающий программный продукт. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» |