В предыдущей части мы классифицировали сложившиеся формы коллективной работы: проекты, процессы, кейсы, документооборот, инциденты. Там же было сказано, что разделить их можно лишь умозрительно, в реальности они взаимосвязаны.
Характерно, что свод знаний по проектному управлению PMBOK рассказывает не столько про проекты, столько про процессы управления проектами. В свою очередь, значительная часть свода знаний по процессному управлению CBOK посвящена проектам совершенствования бизнес-процессов.
Взаимозависимость проявляется в следующих формах:
1) Интероперабельность: инициирование коллективной работы одного вида из работы другого вида.
Примеры: кейсы инициируют процессы (лечение больного от поступления в больницу до выписки – кейс, процедура или анализ – процесс), процессы инициируют проекты (управление проектами согласно PMBOK).
7. Процесс разработки программного обеспечения
2) Миграция: пересмотр взглядов на отнесение деятельности к определенному виду коллективной работы со временем.
Зачастую отнесение коллективной работы к проекту, процессу или кейсу – вопрос трактовки. Пример: фармацевтическая компания традиционно рассматривала разработку нового лекарственного препарата как проект. Затем пришла к идее типового шаблона проекта, а от нее – к пониманию того, что эту деятельность целесообразнее рассматривать как процесс.
Другой пример: популярность идей кейс-менеджмента отчасти объясняется тем, что по сравнению с процессами, работа с кейсами требует меньших начальных затрат. Поэтому даже там, где деятельность является предсказуемой, т.е. процессной, рассматривать ее как кейс может быть более прагматичным вариантом. Вместо того, чтобы заранее продумывать все варианты протекания процесса, рисовать и отлаживать схему процесса, исполнителям дают возможность самим выбирать траектории, а уже потом, накопив опыт кейсов и отобрав лучший, реализуют его в виде процесса.
3) Сквозное управление задачами и ресурсами: все формы коллективной работы в итоге порождают атомарные задачи, назначаемые зачастую одним и тем же исполнителям.
Существенной разницы нет и с точки зрения руководителя: вне зависимости от того, по какому каналу поступают задачи, все они требуют ресурсов.
Классы ПО коллективной работы
Рассмотрим типичную функциональность различных классов программного обеспечения:
Электронная почта. Была и остается, пожалуй, самым распространенным средством. Не обеспечивает ни повторяемости, ни предсказуемости, ни структурированности – средство низкоуровневое, но зато универсальное и общедоступное.
Сетевые диски и файлообменники. Взаимодействие обычно по-прежнему обеспечивается электронной почтой, но становится более цивилизованным: по почте больше не пересылаются тяжелые вложения, версии документов как-то контролируются.
ECM-системы. Своему основному назначению поддержки жизненного цикла документа соответствуют идеально. Обладают массой преимуществ по сравнению с файлообменниками: контроль доступа, версионность, индексация и быстрый поиск по контенту, сканирование и преобразование контента, многоуровневая архивация. Поддержка процессов, как правило, на достаточно примитивном по сравнению с BPMS уровне (документо-ориентированные потоки работ), хотя известны программные продукты, сочетающие функциональность ECM и BPMS (EMC Documentum, связка Alfresco и Activiti).
Технологии разработки ПО Лекция 1
Трекеры. Исходно появились как баг-трекеры (работа с дефектами ПО), со временем развились в средства управления и другими аспектами разработки ПО (пожелания по доработке, релизы и т.п.). Контролируют назначение ответственных, сроки и приоритеты. Позволяют вести обсуждение и прикреплять файлы.
Благодаря появившейся таким образом универсальности стало возможным использовать их в качестве средства управления инцидентами, чем и воспользовались многие организации. Иногда используются для управления процессами, но возможности в этой части ограничены: только контроль жизненного цикла через атрибут «состояние».
Кейс-менеджмент (ACM, Adaptive Case Management). Этот класс систем еще формируется, и не всегда легко отделить рекламные обещания от реальной функциональности конкретного продукта. Тем не менее, можно сформулировать общие черты: динамически формируемые самими пользователями списки задач (чек-листы), поддержка структурированного и неструктурированного контента, экранные формы задач, бизнес-правила. К продвинутой функциональности можно отнести возможность сохранять кейс в виде шаблона, который будет помогать работать со следующими экземплярами.
ПО для управления проектами. Перечень задач и зависимости (последовательность выполнения), план-график (прогноз сроков), планирование ресурсов (трудозатрат), формирование сметы. Расширенная функциональность: расчет критического пути, планирование портфеля проектов с учетом конкуренции за общие ресурсы. Возможность работы со структурированными данными ограничена.
ПО для управления бизнес-процессами (BPMS, Business Process Management Suite). Моделирование процессов и данных, быстрая разработка экранных форм и скриптов, исполнение процессов движком, отчетность и аналитика. Расширенная функциональность: поддержка бизнес-правил, интеграция с внешними базами данных и информационными системами.
Итак, что мы видим: все четыре квадранта на рис. 2 из прошлой статьи покрыты:
● Трекер для инцидентов
● Проектное ПО для проектов
● BPMS для процессов
Это новость хорошая.
Плохая же заключается в том, что обойтись одним инструментом не получится. Разве что у вас доминирует какая-то одна форма коллективной работы – например, вы рассматриваете свою организацию как чисто проектную.
Еще вариант – использовать более универсальный, но менее функциональный продукт, мирясь с его недостатками. Например, управлять процессами с помощью трекера или ECM. С помощью почты и файлообменника можно управлять вообще всем, но контролировать работу при этом придется вручную.
Можно поступить и наоборот: например, реализовать управление инцидентами и поручениями средствами BPMS. Это не так уж сложно, но решение получится более дорогим и более громоздким по сравнению со специализированным трекером.
Еще ближе друг к другу задачи кейс-менеджмента и управления инцидентами – покрыть и те, и другие средствами ACM выглядит вполне разумным решением.
Преимущества единой среды коллективной работы
Почему несколько средств поддержки коллективной работы – это плохо? Помимо стандартных доводов – усложнение ИТ-архитектуры, более дорогая ИТ-поддержка и т.п. – можно привести ряд конкретных доводов в пользу интегрированной среды:
Интероперабельность (см. выше).
Поддержка миграции (см. выше).
Единое управление задачами
Как уже отмечалось выше, с точки зрения исполнителя нет особой разницы между задачами, назначаемыми ему в рамках проекта, процесса, кейса или инцидента. Но если всеми этими видами работ управляют разные информационные системы, то разница появляется, и существенная. Ведь у каждой системы свой интерфейс (свой веб-портал), каждый надо освоить.
Кроме того, отличаться будет и функциональность на уровне управления задачами. Скажем, одна система умеет автоматически делегировать задачи на время отпуска, другая – нет, одна умеет автоматически учитывать затраты времени исполнителя, другая – нет. У каждой свой способ уведомления о назначении задач, у каждой свой аудиторский журнал…
Сквозное управление ресурсами
Часто ли сотрудники участвуют только в проектах или только в процессах? И как быть в тех случаях, когда они участвуют и в тех, и в других, а сверх этого им назначаются разовые поручения? Как понять – отлынивает сотрудник от участия в проекте, только ссылаясь на текучку, или действительно перегружен, и рассчитывать на его плотное участие в проекте объективно означает ставить проект под угрозу?
Если проекты и процессы управляются с помощью разного ПО, сделать это будет проблематично. Помимо простого наличия двух сред и механических проблем агрегации данных, здесь есть проблема методическая: проекты и процессы принципиально по-разному подходят к планированию ресурсов.
Для людей, привыкших иметь дело с проектами, первое знакомство с процессной системой может быть шоком. Они задают естественный, на их взгляд, вопрос: «Как здесь узнать, когда процесс завершится?» И получают ответ: «Когда завершится данный экземпляр процесса – неизвестно. В среднем продолжительность процесса составляет столько-то.» То есть в процессах продолжительность и трудозатраты оцениваются в вероятностных терминах. В отличие от проектов, где план-график дает точный ответ на эти вопросы.
Ну как точный… Если присмотреться, точность проектных оценок условна. График проекта может быть пересмотрен, сроки и трудоемкость изменятся. Так что это тоже, в общем-то, оценка вероятностная, просто обычно на этом не акцентируют внимание.
Общая платформа
К любой системе коллективной работы сегодня предъявляются стандартные требования: возможность работы в «облаке», поддержка мобильных устройств (планшетов и смартфонов), поддержка социального взаимодействия (по образцу Фейсбука* и твиттера, но внутри компании). Удовлетворить этим требованиями непросто и объективно дорого. А если эти функции реализовывать для каждой среды коллективной работы по отдельности, то очень дорого.
Кроме того, кому нужны несколько социальных сетей внутри компании? Скорее всего, при таком подходе ни одна не наберет критической массы активных участников, и идея засохнет на корню, как это произошло с идеей интранета.
Требования к среде коллективной работы
На сегодняшний день единую среду, поддерживающую все рассмотренные формы коллективной работы, не может предложить ни один производитель программного обеспечения. Но проблема, судя по всему, назрела, и ряд компаний ведет работы в этом направлении – например, OpenText, IBM, SAP, EleWise. Компания Comindware сделала разработку такой среды своей миссией, что отражено в ее названии.
Попробуем представить себе облик перспективной единой среды, поддерживающей все рассмотренные формы коллективной работы:
1. В кейс-менеджменте есть все необходимое для управления инцидентами и документооборотом.
От документооборота кейс-менеджмент отличается поддержкой структурированных данных. Неструктурированную информацию (контент) поддерживают оба.
От инцидента кейс отличается повторяемостью.
То есть по отношению к обоим кейс-менеджмент обладает избыточностью, но не критичной.
Вывод: отдельные функции для управления поручениями, инцидентами, документами не требуются, все покрывается кейсами.
2. Кейсы и процессы – разные, но органично дополняющие друг друга формы коллективной работы.
Разница между ними в том, что процесс – предсказуемая, кейс – непредсказуемая работа. В случае процесса задача создается, и ее исполнитель назначается в соответствии со схемой процесса, в случае кейса и то, и другое делается по усмотрению пользователя. Можно сказать, что кейс – это динамически формируемый процесс, не требующий предопределенной схемы.
Вывод: поддержка кейсов и процессов должна быть максимально интегрирована. Мониторинг и аналитика могут и должны быть унифицированы.
3. Кейсы отличаются от проектов структурированностью, повторяемостью и непредсказуемостью. Процессы отличаются от проектов структурированностью и повторяемостью.
Как и в случае инцидентов и документов (п.1) структурированность может рассматриваться как избыточная функциональность. Повторяемость – аналогично.
Более интересна ситуация с непредсказуемостью кейсов. Возможность спланировать все задачи проекта от начала до конца (пусть и внося корректировки в этот план в дальнейшем) – обязательная функциональность управления проектами. Теоретически можно добавить к кейсам возможность создавать задачи не только «на сейчас», но и на будущее. Это потребует планирования продолжительности и ресурсов, описания всех вариантов зависимости задач и т.д. Реализовать это можно, но это сделает систему намного более громоздкой, и в результате потеряется главное преимущество управления кейсами – легкость использования.
Поэтому проекты, процессы и кейсы – разные сущности.
Но при этом должны быть обеспечены интероперабельность и миграция.
4. Относительно предсказуемости процессов и проектов.
Как было отмечено выше, предсказуемость эта разная: проект предсказуем на уровне экземпляра (что наглядно отображается диаграммой Гантта), процесс – на уровне статистических характеристик совокупности экземпляров процесса.
Впрочем, при более внимательном рассмотрении обнаруживается, что это различие не принципиальное: никто не мешает отобразить уже завершенные задачи процесса в виде диаграммы Гантта, снизив таким образом барьер между проектами и процессами.
Что касается будущих задач процесса, то спрогнозировать их – задача более сложная, но тоже решаемая. Опираясь на историю выполнения предыдущих экземпляров процессов, статистическими методами можно спрогнозировать наиболее вероятную последовательность задач текущего экземпляра, сроки завершения и т.п. Чтобы прогноз был более точным, можно принять во внимание значения атрибутов данного экземпляра процесса.
Общие функциональные требования:
5. Поддержка как неструктурированных, так и структурированных данных.
Неструктурированные данные поддерживаются в проектах, процессах и кейсах.
Структурированные данные в процессах и кейсах обязательны, в проектах – опциональны.
Система должна предоставлять возможность работы с данными и напрямую, без участия процесса или кейса. Существующие системы BPMS имеют для этого все необходимое – средства моделирования данных, средства разработки экранных форм, но возможность работы с данными напрямую в них, как правило, не предусмотрена. Это выглядит как искусственное ограничение, от которого следует избавиться.
6. Унифицированное управление задачами.
Вне зависимости от того, откуда пришла задача – из проекта, процесса или кейса – она должна отображаться в общем списке задач, на нее должны распространяться общие правила делегирования и т.д.
7. Сквозное управление ресурсами.
Учет трудозатрат и планирование загрузки ресурсов должны осуществляться с учетом задач и проектных, и процессных, и порожденных кейсами.
Для планирования будущей загрузки ресурсов в процессах и кейсах необходимо использовать вероятностные методы, упомянутые выше в п.4.
8. Поддержка социального взаимодействия.
Ленты комментариев к проектам, задачам, бизнес-объектам, людям. Лайки, подписки, инвайты, уведомления и т.п.
Системные требования:
9. База данных.
Если системам управления процессами, с их разделением на среду разработки и среду исполнения, достаточно реляционной базы данных, то кейс-менеджмент требует возможности добавлять атрибуты бизнес-объектов «на лету». Такую гибкость способны обеспечить семантические базы данных.
10. Размещение в облаке или локально.
По усмотрению заказчика, система должна быть доступной в виде облачного сервиса по подписке или в виде традиционного дистрибутива для инсталляции на собственных серверах заказчика.
11. Клиентское ПО.
Все сто процентов функциональности (включая моделирование схем процессов, проектирование структур данных, экранных форм, бизнес-правил и т.п.) должны быть доступны через веб-браузер.
Должны поддерживаться мобильные клиенты для основных платформ (iOS, Android).
Должна поддерживаться работа с задачами из Outlook.
Требования к интеграции с онлайновыми сервисами, унаследованными системами и источниками данных мы оставим за рамками статьи.
* — организация, признанна экстремистской на территории РФ
Источник: ecm-journal.ru
Средства разработки ПО
Инструментальное программное
обеспечение
Инструментальное программное обеспечение —
программное обеспечение, предназначенное для использования в ходе проектирования, разработки
и сопровождения программ.
Инструментальное программное обеспечение используется для создания программных продуктов
в любой области, включая и системные и прикладные
программы. В настоящее время для создания программных продуктов применяются мощные системы
визуального программирования, которые включают
в себя обширные библиотеки стандартных программ,
специальные средства отладки и тестирования.
3.
Инструментальное программное
обеспечение
Системы программирования предназначены для
разработки новых программ на конкретном языке
программирования и включают в себя компиляторы, интерпретаторы, диалоговую среду,
редакторы текстов, библиотеки стандартных
подпрограмм, компоновщики, отладчики, справочные службы, средства автоматизированного тестирования, системы управления версиями
и др.
4.
Инструментальное программное обеспечение
5.
Инструментальное программное обеспечение
6.
Инструментальное программное обеспечение
7.
Инструментальное программное обеспечение
Кроме того, в инструментальное программное
обеспечение входят SDK, ассемблер, генератор
документации.
SDK (Software Development Kit) — комплект
средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определенного пакета программ, программного обеспечения базовых
средств разработки, аппаратной платформы,
компьютерной системы, видеоигровых консолей,
оперативных систем и прочих платформ.
8.
Инструментальное программное обеспечение
Ассемблер — компьютерная программа, компилятор исходного текста программы, написанной
на языке ассемблера, в программу на машинном
коде. Как и сам язык, ассемблеры, как правило,
специфичны для конкретной архитектуры, операционной системы и варианта синтаксиса языка.
Вместе с тем существуют мультиплатформенные
или вовсе универсальные (точнее, ограниченноуниверсальные, потому что на языке низкого
уровня нельзя написать аппаратно-независимые
программы) ассемблеры, которые могут работать
на разных платформах и операционных системах.
9.
Инструментальное программное обеспечение
Генератор документации — программа или пакет
программ, позволяющая получать документацию,
предназначенную для программистов и/или для
конечных пользователей системы, по особым образом комментированному исходному коду и,
в некоторых случаях, по исполняемым модулям
(полученным на выходе компилятора).
10.
Концепция современной интегрированной
среды разработки приложений
Интегрированная среда разработки программного
обеспечения (Integrated Development Environment —
IDE) — система программных средств, используемая
программистами для разработки программного
обеспечения.
11.
Концепция современной интегрированной среды
разработки приложений
Обычно среда разработки включает в себя текстовый
редактор, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Иногда также
содержит систему управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают
браузер классов, инспектор объектов и диаграмму
иерархии классов для использования при объектно-ориентированной разработке программного обеспечения.
Интегрированная среда разработки (ИСР) имеет общую
интерактивную графическую оболочку, поддерживающую выполнение всех основных функций жизненного
цикла разработки.
12.
Концепция современной интегрированной среды
разработки приложений
Для каждой из интегрированных сред разработки программ характерно наличие следующих компонентов:
• единая интерактивная оболочка, обеспечивающая вызов
всех других компонентов, не выходя из среды, с широким использованием функциональных клавиш;
• текстовый редактор для набора и редактирования исходных текстов программ. В недавнем прошлом в отечественной традиции использовался именно термин «исходный
текст», впоследствии стал использоваться термин «исходный
код» (source code);
• система поддержки сборки (build), т. е. компиляции проектов из исходных кодов, включающая компилятор с исходного
реализуемого языка и компоновщик (linker) объектных бинарных кодов в единый исполняемый код (загрузочный модуль);
компоновщик используется либо штатный, входящий в состав
операционной системы, либо специфичный для данной среды;
• отладчик (debugger) для отладки программ в среде с помощью типичного набора команд: точки останова, пошаговое
выполнение процедур (методов), визуализация значений переменных и др.
13.
Концепция современной интегрированной среды
разработки приложений
ИСР обычно предназначены для нескольких языков программирования — такие как IntelliJ IDEA, NetBeans, Eclipse,
Qt Creator, Geany, Embarcadero RAD Studio, Xcode или
Microsoft Visual Studio, но есть и ИСР для одного определенного языка программирования, как, например,
Visual Basic, Delphi, Dev-C++.
Частный случай ИСР — среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.
Современные текстовые редакторы в интегрированных
средах обеспечивают также режим автоматического завершения кода (code completion), который в них включен
по умолчанию и в котором редактор среды подсказывает
разработчику возможные и синтаксически правильные его
продолжения, например, отсутствие закрывающей скобки,
отсутствие точки с запятой; возможные варианты имен
методов при вызове метода от объекта какого-либо определенного класса, и т. д.
14.
Концепция современной интегрированной среды
разработки приложений
15.
Концепция современной интегрированной среды
разработки приложений
В современных версиях интегрированных сред имеются
следующие компоненты.
Профилировщик (profiler) — инструмент для мониторинга
активности пользователей, накопления и анализа статистических данных, полученных в результате выполнения
программы под управлением интегрированной среды:
число вызовов процедур (методов), объем памяти,
используемой при выполнении программ, и т.д.
Рефакторинг (refactoring) — инструментарий для реорганизации кода — изменения внутренней структуры программы, не затрагивающий ее внешнего поведения и имеющий целью облегчить понимание ее работы.
Генератор тестов (unit test generator) — инструмент для
генерации типовых тестов для тестирования модулей, методов или процедур с различными возможными сочетаниями значений аргументов.
16.
Концепция современной интегрированной среды
разработки приложений
Система управления версиями исходных кодов (source code
control system) для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить
несколько версий файлов исходных кодов проектов в среде при
сопровождении программ.
Инструменты поддержки командной разработки программ
(teamwork) — этапов жизненного цикла программы (требования и спецификации, проектирование, реализация, тестирование), распределения заданий по разработке среди участников
команды программистов, контроля выполнения заданий менеджером проекта.
Инструменты анализа кода (code analysis) — специальное
программное обеспечение для статического и динамического
анализа кода проекта. Статический анализ кода (static code
analysis) — анализ программного обеспечения, производимый
в отличие от динамического анализа без реального выполнения
исследуемых программ. Динамический анализ кода (dynamic
program analysis) — анализ программного обеспечения, проводимый при помощи выполнения программ на реальном или
виртуальном процессоре (в отличие от статического анализа).
17.
Концепция современной интегрированной среды
разработки приложений
Инструменты визуализации сгенерированного бинарного кода — методов, переменных, их имен и т.д.
Инструменты «запутывания» кода (obfuscation), выполняющие
именно с этой целью замену имен элементов кода — классов,
методов, полей и т. д. на непонятные, «случайные», «запутанные» имена, в целях затруднения изучения декомпилированного бинарного кода, для защиты от «взлома» кода злоумышленниками, которые хотят несанкционированным образом
присвоить себе новые идеи, содержащиеся в коде, либо изучить его со злонамеренными целями организации атак.
Поддержка создания различных видов программных проектов и решений на основе типовых шаблонов кода; механизм
разработки расширений. При современной разработке программ часто требуется создавать различные приложения — консольные, веб-приложения и веб-сервисы, мобильные приложения, облачные приложения и др. Для каждой из этих разновидностей требуется разработка специфической структуры файлов
исходного кода, а также конфигурационных файлов. Современные интегрированные среды автоматизируют создание различного рода проектов, предоставляя шаблоны исходного кода
и генерируя автоматически необходимые для проекта конфигурационные файлы.
18.
Концепция современной интегрированной среды
разработки приложений
Поддержка моделирования структуры программ
на унифицированном языке моделирования
UML. Современные интегрированные среды поддерживают использование языка UML в двух направлениях: генерация модели и соответствующей
диаграммы по исходному коду и, наоборот, генерация (шаблона) исходного кода по разработанной модели.
19.
Контрольные вопросы и задания
1.
2.
Cформулируйте определение интегрированной среды разработки программ.
Каковы основные компоненты интегрированной среды разработки программного обеспечения?
3. Что такое текстовый редактор?
4. Какие дополнительные функции по синтаксической проверке вводимого исходного кода встроены в современные редакторы в интегрированной среде
разработки?
5. Что такое отладчик и каковы его типовые команды?
6. Какую функциональность обеспечивает поддержка коллективной разработки
программ?
7. Для чего предназначено инструментальное программное обеспечение?
8. Дайте определения понятиям «компилятор», «транслятор», «компоновщик»,
«интерпретатор».
9. Что такое SDK (Software Development Kit)?
10. Наличие каких компонент характерно для интегрированных сред разработки
ПО?
11. Что включает в себя система поддержки сборки?
12. Для чего используются инструменты «запутывания» кода?
20.
Контрольные вопросы и задания
1.
2.
3.
4.
5.
6.
7.
Сформулируйте определение интегрированной среды разработки программ.
Каковы основные компоненты интегрированной среды разработки программного обеспечения?
Что такое текстовый редактор?
Какие дополнительные функции по синтаксической проверке вводимого исходного кода встроены в современные редакторы в интегрированной среде разработки?
Что такое отладчик и каковы его типовые команды?
Какую функциональность обеспечивает поддержка коллективной разработки программ?
Для чего предназначено инструментальное программное
обеспечение?
Источник: ppt-online.org
Методы организации работы в команде разработчиков. Системы контроля версий — презентация
Первый слайд презентации: Методы организации работы в команде разработчиков. Системы контроля версий
Лекция №1 Моделирование и анализ программного обеспечения
Изображение слайда
Слайд 2
Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок.
Изображение слайда
Слайд 3
1. Авторская разработка Авторская разработка — принцип создания программных продуктов, при котором весь жизненный цикл разработки поддерживается одним единственным человеком. 2. Коллективная разработка Одним из основных вопросов коллективной разработки является разделение труда — от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста ). 3. Общинная модель разработки Идеология общинной («базарной») модели разработки сформулирована в программной статье Эрика Раймонда ( Eric Raymond ) «Собор и Базар». Общинная модель характеризуется тремя основными факторами: децентролизованность разработки, разработка ведется на базе открытых исходных текстов, большое количество внешних тестеров (бета-тестеров), позволяющих быстро обнаруживать ошибки и проблемы в программе.
Изображение слайда
Слайд 4
Коллективная разработка Бригада равноправных соисполнителей обычно состоит из специалистов, занимающихся примерно подобными задачами в рамках одного проекта. Естественно, специализаций в рамках одной бригады может быть несколько: инженеры-разработчики (специалисты по инженерии программирования и программисты); технические писатели; инженеры тестирования; инженеры качества; специалисты по сопровождению продукта; специалисты по продажам продукта.
Изображение слайда
Слайд 5: Основные этапы разработки программного обеспечения
Анализ — определение процесса разработки ПО Проектирование — управление проектом разработки Конструирование — описание целевого программного продукта Программирование — проектирование продукта Разработка продукта Тестирование — тестирование частей программного продукта Отладка — интеграция частей и тестирование продукта в целом Развертывание — сопровождение продукта, обучение пользователей Выпуск продукта
Изображение слайда
Слайд 6: Минимальные функции системы коллективной разработки:
это регистрация изменений, вносимых в проект, хранение файлов проекта.
Изображение слайда
Слайд 7: Системы управления версиями ( Version Control Systems, VCS) или Системы управления исходным кодом ( Source Management Systems, SMS) — важный аспект разработки современного ПО. Это программное обеспечение, предназначенное для работы с постоянно изменяющейся информацией. VCS предоставляет следующие возможности: 1) Поддержка хранения файлов в репозитории. 2) Поддержка истории версий файлов в репозитории. 3) Нахождение конфликтов при изменении исходного кода и обеспечение синхронизации при работе в многопользовательской среде разработки. 4) Отслеживание авторов изменений
Система контроля версий
Изображение слайда
Слайд 8: 1) Централизованные/распределённые — в централизованных системах контроля версий вся работа производится с центральным репозиторием, в распределённых — у каждого разработчика есть локальная копия репозитория. 2) Блокирующие/не блокирующие — блокирующие системы контроля версий позволяют наложить запрет на изменение файла, пока один из разработчиков работает над ним, в неблокирующих один файл может одновременно изменяться несколькими разработчиками. 3) Для текстовых данных/для бинарных данных — для VCS для текстовых данных очень важна поддержка слияния изменений, для VCS с бинарными данными важна возможность блокировки
Классификация систем контроля версий
Изображение слайда
Слайд 9: М ониторинг работоспособности некоторых из систем контроля версий
Bazaar, ранее известная как Bazaar -NG, утилита командной строки bzr, — это распределённая система управления версиями, разработка которой спонсируется фирмой Canonical Ltd, в последнюю версию по сравнению с предыдущей было внесено более 50 изменений. Данная система разработана в целях облегчения создания и развития проектов для пользователей.
Mercurial, в переводе с англ. «подвижный», — распределённая система управления версиями, способная функционировать на многих операционных системах и различных аппаратных платформах, разработанная для эффективной работы с очень большими кодами. Git — распределённая система управления версиями файлов.
Код программы был написан на языке «С», проект создан Линусом Торвальдсом в 2005 году для управления разработкой ядра Linux, является общедоступным программным обеспечением. Данная система была введена многими ведущими разработчиками, используется в известных Linux -сообществу проектах. Concurrent Versions System (или CVS, в переводе «Система Одновременных Версий») — представляет собой программный продукт, который относится к разряду систем управления версиями. Программа хранит историю изменений исходного кода программного обеспечения, тем самым облегчая совместную работу программистов над одним проектом. CVS популярна в мире открытого программного обеспечения.
Изображение слайда
Последний слайд презентации: Методы организации работы в команде разработчиков. Системы контроля версий
Bazaar — удобная система контроля версий с приятным интерфейсом, она хорошо подходит для пользователей, которых не привлекает перспектива работы с командной строкой. Имеется множество дополнительных опций и расширений, что позволяет настроить программу под свои нужды.
Говоря о Mercurial следует отметить, что простой и отточенный интерфейс, и набор команд, возможность импортировать репозиториев с других систем контроля версий, — сделают переход на данную программу безболезненным и быстрым, а её надёжность и скорость работы позволяют пользоваться им для контроля версий огромных проектов. Все это позволяет Mercurial стать достойным конкурентом git’а. В свою очередь Git — это гибкая, удобная и мощная система контроля версий, способная удовлетворить абсолютное большинство пользователей. Git — один из лидеров систем контроля версий. Несмотря на то, что программа CVS достаточно устарела и обладает весомыми недостатками, она все ещё является одной из самых популярных систем контроля версий и отлично подходит для управления малыми проектами, не требующих создания нескольких параллельных версий, которые надо периодически соединять. УчётМатериалов
Источник: showslide.ru