80
(результат!
Третичный
фактор
Первичный фактор
Вторичных
фактор
(Каем
ш ш м
Причинные факторы (характеристики)
Рисунок 26 - Принцип построения диаграммы Исикавы
Над построением диаграммы Исикавы чаще всего работает группа экспер
тов. Наиболее эффективным методом при построении схемы является метод
мозгового штурма. Каждый эксперт выдвигает три наиболее значимых гипотезы
и обозначает их на копиях основной схемы. В дальнейшем каждый эксперт пе
реносит «свои» факторы на общую схему, проставляя баллы на диаграмме Иси
кавы. В результате, когда все эксперты нанесут на схему свои варианты, там вы
явится три наиболее значимых, с точки зрения всех экспертов, фактора.
Не менее интересным для руководителей, принимающих управленческие
решения, является метод построения «деревьев решений», в соответствии с ко
торым ЛПР формирует из «ветвей», «узлов-квадратов» решений и «узлов-
кружков» (соответствующих им исходов) «дерево решений, отражающее струк
турное представление проблемы. В данной модели каждое предлагаемое реше
ние характеризуется вероятными вариантами исходов и вызывает необходи
мость в принятии следующих решений, которые в свою очередь также характе
ризуются вероятностными последствиями.
Метод дерева решений используется при отборе альтернатив, когда мы
сталкиваемся с достаточно сложными решениями, которые можно уточнять и
81
конкретизировать в разных вариантах. Дерево решений позволяет наглядно
представить их многообразие и взаимосвязи. Последовательно «спускаясь» по
дереву и проверяя варианты с точки зрения приемлемости, мы выходим на удо
влетворяющие нас конкретные решения, среди которых и делаем окончательный
выбор.
В данном разделе будет описано практическое использование дерева це
лей для компании, которая работе в сфере предоставления услуг по разработке
сайтов.
Рассмотрим процедуру применения данной технологии на примере реше
ния проблемы поиска специалистов в сфере разработки программ (программи
ста).
Этап 1: Формируем дерево решений, либо путем декомпозиции проблемы
«сверху-вниз», либо группируя известный нам список альтернатив (Рис. 27).
Рисунок 27 - Дерево решений
82
Этап 2: Выделяем в данном дереве семейство («мать-дочки»). В нашем
дереве таких семейств - 8.
1. Б, В1, В2
2. В1, Д1, Д2
3. В2, Д3, Д4
4. Д1, Г1, Г2
5. Д2, Г3, Г4
6. Д3, Г5, Г6
7. Д4, Г7, Г8
Этап 3: В каждом семействе, используя метод оценочных таблиц, прово
дим сравнительный анализ альтернатив. Предварительно необходимо сформиро
вать список всевозможных критериев, которые могут быть использованы для
сравнения той или иной пары конечных альтернатив.
Для примера выделим следующие критерии оценки:
1. денежные расходы на поиск
2. затраты времени на поиск
3. отзывы о работнике
4. качество портфолио
5. опыт работы
Поскольку элементы, находящиеся в разных семействах, имеют каче
ственные отличия, для каждого семейства мы выбираем наиболее характерные
критерии.
Рассмотрим одно из семейств - семейство - В2, Д3, Д4.
Выделим для него наиболее существенные на наш взгляд критерии оценки
и ранжируем их с точки зрения значимости при помощи весовых коэффициен
тов.
1. денежные расходы на поиск - 0,2
2. затраты времени на поиск - 0,2
3. качество портфолио - 0,3
4. опыт работы - 0,3
Затем сравниваем между собой альтернативы по каждому критерию с точ
ки зрения предпочтительности так же при помощи весовых коэффициентов и
83
рассчитываем обобщенную «эффективность» каждой из трех альтернатив данно
го семейства.
84
Таблица №3
Обобщенная «эффективность» альтернатив
Критерии К
Д3
Д4
I
Денежные расходы
0,2
0,06 0,14 1
Затраты времени
0,2
0,09 0,11 1
Качество портфолио
0,3 0,03 0,27 1
Опыт работы 0,3 0,15 0,15 1
I
1 0,33 0,67
Сумма конечных оценок альтернатив в каждом семействе должна рав
няться 1 (0,33+0,67 = 1).
Аналогичные таблицы рассчитываем для каждого семейства, получая для
каждого элемента соответствующую оценку эффективности альтернатив- «до
чек».
Рассчитывая таким образом сумму конечных оценок альтернатив можно
определить наиболее оптимальный вариант, который можно использовать с
наибольшей эффективностью для предприятия.
2.2.2. Формирование команды проекта автоматизации
Для реализации проекта, как со стороны заказчика, так и со стороны раз
работчика созданы проектные команды, которые тесно взаимодействуют друг с
другом. Состав команд будет определяться характером и масштабом проекта
[18]. Структуры команд заказчика и разработчика представлены на рис. 28.
Руководитель проекта нужен во всех проектах. Обязанности руководителя
проекта в организациях заказчика и разработчика отличаются друг от друга, но,
тем не менее, сходство между ними состоит в том, что вся их деятельность
направлена на то, чтобы все члены расширенной команды занимались нужными
делами в нужное время.
Руководитель проекта определяет и распределяет множество задач по
проекту, делится своей концепцией и подходом к реализации проекта с коман
дой. Он тесно сотрудничает с командой, прилагает все усилия к тому, чтобы у
каждого члена команды были ресурсы, необходимые ему для успешной работы.
85
Ведущий представитель пользователей со стороны заказчика выступает в
роли посредника между сообществом пользователей организации и аналитиками
организации разработчика. Задача этого человека - донести нужды пользовате
лей до аналитиков. Он работает в тесном взаимодействии с аналитиком органи
зации разработчика.
т~ ч и и
В свою очередь аналитик отвечает за перевод пожеланий пользователей в
конкретные требования, пригодные для реализации, тестирования и документи
рования в процессе разработки.
Архитектор проекта обычно требуется, когда проект достаточно большой
и возникает необходимость в привлечении нескольких компаний разработчиков,
каждая из которых разрабатывает отдельную часть системы.
Архитектор команды разработчиков отвечает за разработку архитектуры
своей части системы. Эта роль важна, так как архитектор определяет и разраба
тывает основание всей будущей системы и неудачное решение может привести к
провалу проекта. Архитектура - это область повышенного риска и последствия
неудачи здесь очень значительны.
Реализация решений лежит на разработчике. Эта роль требует соблюдения
баланса между творческим подходом к решению задач и соблюдением требова
ний к проекту. Необходимо также приспосабливаться к изменяющимся ситуаци
ям, так как у заказчика могут меняться требования к системе. Современные тех
нологии создания ПО позволяют отслеживать эти изменения за счет итеративно
го характера разработки.
Технический лидер - это самый опытный разработчик в команде. Он
направляет деятельность разработчиков, тестировщиков и аналитиков. Техниче
ский лидер - это правая рука руководителя проекта.
86
Рисунок 28 - Проектные команды [2, С. 60].
Во всех проектах по разработке программного обеспечения команда раз
работчиков использует множество различных инструментов, технологий и про
цессов. Специалист по инструментальным средствам устанавливает и настраива
ет инструментарий среды разработки и подготавливает его для использования.
Руководитель ИТ-подразделения отвечает за поддержку и работу продук
та, разработанного в проекте, при его внедрении у заказчика, за организацию ра
бочей среды, за обеспечение необходимыми аппаратными средствами, за соблю
дение стандартов безопасности.
Специалист по заключению контрактов работает со всеми контрактами по
проекту, в его компетенцию входит управление проектом с точки зрения бизне
са.
87
2.2.3. Средства коллективной работы над проектом автоматизации
Система управления версиями — программное обеспечение для облегче
ния работы с изменяющейся информацией. Система управления версиями поз
воляет хранить несколько версий одного и того же документа. Регистрируя из
менения в одном или нескольких файлах, система управления версиями дает
возможность вернуться к предыдущим версиям этих файлов на произвольный
момент времени.
Такие системы наиболее широко используются при разработке программ
ного обеспечения для хранения исходных кодов разрабатываемой программы.
Применяется несколько типов систем управления версиями.
Многие предпочитают управлять версиями, копируя файлы в новый ката
лог на собственном локальном компьютере. Этот подход прост и поэтому рас
пространен, но не очень надежен. Кроме того, версии доступны только одному
разработчику
Необходимость сотрудничать с разработчиками за другими компьютера
ми, заставила создать и применять централизованные системы контроля версий.
В таких системах, как Subversion (SVN), есть центральный сервер, на котором
хранятся все версии файлов, и ряд клиентов, которые получают копии файлов из
него. На клиента никогда не передается весь проект целиком - только файлы, над
которыми ведется работа. Администрировать централизованные системы намно
го легче, чем локальные, но при таком подходе есть и несколько серьёзных не
достатков: поскольку вся история проекта хранится в одном месте, есть риск по
терять всё.
Распределенные системы управления версиями не полагаются на един
ственный центральный сервер для хранения всех версий проекта.
В таких системах как Git и Mercurial клиенты не просто выгружают по
следние версии файлов, а полностью копируют весь репозиторий. Поэтому в
случае, когда выходит из строя сервер, через который шла работа, любой кли
ентский репозиторий может быть скопирован обратно на сервер, чтобы восста
новить базу данных.
88
Часто, особенно для географически распределенных команд разработчи
ков, требуется иметь единое место для репозиториев всех проектов. В этом слу
чае, репозитории проектов хранятся в облаке. Сегодня для хранения репозитори
ев очень часто используются GitHub или BitBucket, поддерживающие инстру
менты Git или Mercurial.
В качестве средства коллективной работы над текущим проектом выбрана
система Git.
Git является распределённой системой управления версиями, что отличает
её от более старых, централизованных.
Рисунок 29 - Настройка среды разработки для работы с GIT
В Git взаимодействие с пользователем происходит посредством выполне
ния команд из командной строки. Для хранения репозиториев используется
жесткий диск компьютера, для обеспечения доступа других пользователей хра
нить файлы проекта можно в облачных сервисах. Одним из таких является Bit-
89
Bucket. Это один из крупнейших хостингов Git-проектов с удобным веб
интерфейсом. Он используется для коллективной разработки приложений и ко
ординации действий разработчиков. Использовать Git можно и локально, но то
гда другим участникам проекта будет тяжело узнать об актуальных изменениях
в вашей программе. Для работы с BitBucket необходима учетная запись на дан
ном сервисе. После этого там создается проект, и уже посредством командной
строки осуществляется взаимодействие с репозиторием на BitBucket.
Рисунок 30 - Создание репозитория