CC BY
3
• Отсутствует понятная юридическая основа для географически распределенных центров хранения и обработки данных. Переход к облачным вычислениям, как в мире, так и в России лишь вопрос времени. Основные препятствия на пути в «облака» связаны с неготовностью многих IT-департаментов компаний к изменениям в своей инфраструктуре. Важным толчком к развитию облачных вычислений в России послужит внимание государства и переход к оказанию госуслуг на основе облачных сервисов.
Использованные источники:
1. Software as a Service (SaaS): An Enterprise Perspective [Электронныйресурс]. Режим доступа: http://msdn.microsoft.com/en-us/library/aa905332. aspx
2. MicrosoftPrivateQoud[Электронный ресурс]. Режим доступа: http://www.microsoft.com/en-us/server-cloud/private-cloud/default.aspx
3. Cloud basics. Platform as a Service [Электронныйресурс]. Режим доступа: http://www.microsoft.com/industry/government/guides/cloud computing/5-PaaS.aspx
4. Об облачных вычислениях [Электронный ресурс]. Режим доступа: http://www.parallels.com/ru/spp/understandingclouds
5. Лицензирование программного обеспечения [Электронный ресурс]. Режим доступа: http://services.softline.ru/license
Акеньшин Д.А. студент
Национальный исследовательский Томский Политехнический
Университет
Институт социально-гуманитарных технологий
Россия, г. Томск
ИСПОЛЬЗОВАНИЕ ПРИКЛАДНОГО СИСТЕМНОГО АНАЛИЗА ДЛЯ
ИССЛЕДОВАНИЯ ВОЗМОЖНОСТИ ВНЕДРЕНИЯ ГИБКОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Аннотация
Цель статьи - рассмотреть проблему внедрения гибкой методологии разработки программного обеспечения с точки зрения системного анализа.
Актуальность проблемы заключается в том, что в нынешних условиях быстрого развития информационных технологий и ориентированности разрабатываемого продукта на конечного потребителя, необходимо иметь возможность максимально быстро подстраиваться под эти условия. Кроме того, проект необходимо завершить как можно быстрее (но безопасно с точки зрения управления рисками), поскольку время реализации становится одним из главных факторов, влияющих на конкурентоспособность компании. Исходя из этого, возникает необходимость адаптировать гибкие методологии для управления проектами.
Проблема внедрения гибких методологий разработки программного обеспечения связана с тем, что люди, при переходе к новой методологии, не могут привыкнуть к измененному процессу работы. Так как до этого они в течение долгого времени работали по той схеме, которая была им удобно, но, не смотря на это, была менее эффективная. Так же, при использовании такой методологии, заказчику или представителю заказчика необходимо ежедневно выделять час своего рабочего времени на обсуждение проекта совместно с командой разработчиков.
В данной работе предпринята попытка рассмотреть проблему внедрения гибкой методологии разработки программного обеспечения с точки зрения прикладного системного анализа (третий этап - составление списка стейкхолдеров; четвёртый этап - выявление и составление проблемного месива; пятый этап - составление конфигуратора; шестой этап - целевыявление; седьмой этап - определение критериев; десятый этап -генерирование альтернатив; одиннадцатый этап - принятие решений.).
Третий этап. Составление списка стейкхолдеров:
1. Топ-менеджмент компании. Основная группа заинтересованных лиц, так как использование выбранной методологии разработки программного решения прямым образом сказывается на направлении развития компании и эффективности предприятия. Данные стейкхолдеры негативно относятся к существованию проблемы и заинтересованы в её решении.
2. Менеджеры проектов. Вторая группа заинтересованных лиц, которую затрагивает внедрение гибкой методологии программного обеспечения, так как именно менеджеры проектов отвечают за процесс производства программного продукта. Данные стейкходеры негативно относятся к существованию проблемы и заинтересованы в её решении.
3. Разработчики. В данную группу стейкхолдеров входят лица, которые занимаются непосредственной разработкой программного продукта (дизайнеры, программисты, верстальщики/интеграторы, тестировщики). Данные стейкхолдеры нейтрально относятся к существованию проблемы.
4. Клиенты. В данную группу стейкхолдеров входят непосредственные заказчики разрабатываемого программного продукта. Клиенты заинтересованы в решении этой проблемы.
Четвёртый этап. Выявление проблемного месива:
1. Топ-менеджмент компании, при внедрении новой методологии разработки программного обеспечения, несёт на себе дополнительные риски, связанные с обучение персонала.
2. Менеджеры проектов, при внедрении новой методологии разработки программного обеспечения,несёт на себе риски, связанные с падением эффективности команды разработчиков.
3. Разработчикине имеют практического опыта разработки программного продукта в условиях использованиях гибкой методологии программного обеспечения.
4. Клиенты, при внедрении гибкой методологии компаний, которая занимается разработкой их программного продукта, не видят перед собой документа, отражающего финальное состояние продукта и бюджет. Так же, клиенту (представителя клиента) необходимо ежедневное присутствие на онлайн собраниях команды разработчиков, так как именно заказчик определяет какая часть из общего набора функциональности будет реализована в ближайшее время.
Пятый этап. Выявление конфигуратора. Для решения данной проблемы необходимо знание следующих областей:
• Разработка программного обеспечения с использованием гибких методологий программного обеспечения:
• Программирование в условиях использования гибкой методологии разработки программного обеспечения.
• Разработка интерфейса в условиях использования гибкой методологии разработки программного обеспечения.
• Интеграция программной части в условиях использования гибкой методологии разработки программного обеспечения.
• Тестирование программного продукта, разрабатываемого с использованием гибкой методологии программного обеспечения.
• Аналитика требований в условиях использования гибкой методологии программного обеспечения.
• Управление командой разработчиков в условиях использования гибкой методологии разработки программного обеспечения.
• Внедрение гибких методологий программного обеспечения.
• Успешный опыт продажи услуг по разработки программного обеспечения с использованием гибкой методологии.
• Успешный опыт участия клиента в разработке программного обеспечения с использованием гибкой методологии.
• Управление проектными командами, занимающимися разработкой программного обеспечения с использованием гибкой методологии.
• Обучение менеджеров проектов разработке программного обеспечения в условиях использования гибкой методологии.
• Обучение разработчиков в условиях использования гибкой методологии разработки программного обеспечения.
В компании, на момент внедрения гибкой методологии разработки программного обеспечения, в большинстве случаев нет специалистов, обладающих знаниями в нужной области. Для решения данной проблемы необходимо пригласить эксперта (тренера) по внедрению гибких методологий программного обеспечения в рабочий процесс компании.
Шестой этап. Целевыявление. В данном этапе были определены те цели стейкхолдеров, к которым должно привести использование гибкой методологии разработки программного обеспечения, и определены их единицы измерения.
• Топ-менеджмент
• Увеличение прибыли, руб.
• Рост профессионального уровня компании, баллы.
• Повышение узнаваемости компании, баллы.
• Менеджеры проектов
• Увеличение эффективности команды разработчиков, баллы
• Сокращение количества неудачных проектов, руб
• Рост заработной платы за счёт увеличения оборота компании, руб
• Разработчики
• Получение опыта разработки сложных/нетипичных проектов, баллы
• Повышение заработной платы, руб
• Клиенты
• Улучшение качества разрабатываемого программного продукта, баллы
• Сокращение сроков разработки, дни
• Сокращение стоимости разработки, руб
Седьмой этап. Определение критериев.
В ходе решения проблемы будет необходимо сравнивать предлагаемые варианты, оценивать степень достижения цели и отклонения от неё, осуществлять контроль над ходом событий. Это достигается путём выделения характеристик рассматриваемых объектов и процессов.
Были определены следующие критерии и подкритерии:
• Доход. Количество полученных средств, руб.
• Расход. Количество затраченных средств, руб.
• Стоимость разработки. Средства, необходимые для разработки программного продукта, руб.
• Неудачные проекты. Количество потерянных/недополученных средств в результате срыва проекта, руб.
• Заработная плата. Средства, необходимые для удовлетворения потребностей, соответствующие уровню персонала.
• Привлекательность компании, баллы. Уровень
заинтересованности клиентов в услугах данной компании, баллы. Эксперты - потенциальные клиенты.
• Профессиональный уровень компании. Уровень компании среди всех компаний, занимающихся разработкой программного обеспечения в России, баллы. Оценивается экспертами. Эксперты - директора компаний, занимающихся разработкой программного обеспечения.
• Узнаваемость компании. Популярность бренда в кругу компаний, занимающихся разработкой программного обеспечения в России, баллы. Эксперты - директора компаний, занимающихся разработкой программного обеспечения.
• Эффективность команды разработчиков. Способность команды разработчиков разрабатывать программный продукт в установленные сроки, баллы. Эксперты -менеджеры проектов.
• Срок разработки. Срок, затрачиваемый на разработку
программного продукта, дни.
• Опыт разработки нетипичных проектов. Опыт получения
опыта разработки проектов, приносящих дополнительное удовлетворение в связи с не типичностью задачи, баллы. Эксперты - команда, занимающаяся разработкой данного проекта.
• Качество программного продукта. Уровень удовлетворения потребностей ЦА программным продуктом, баллы. Эксперты - конечные пользователи программного продукта.
В итоге, мы пришли к трём основным критериям: доход, расход и привлекательность компании.
Таким образом, рассмотрев проблему внедрения гибкой методологии разработки программного обеспечения, мы можем сделать вывод о том, что у источников данной проблемы стоит отсутствие опыта разработки программного обеспечения в условиях использования гибкой методологии. Так же, были выявлены цели стейкхолдеров и определены основные критерии, которые будут необходимы нам для решения поставленной проблемы.
Десятый Этап. Генерирование альтернатив
• Приглашение agile-тренера.
• Обучение персонала за счёт компании:
• платныевебинары;
• платные мастер-классы;
• платные семинары;
• литература.
• Самообучение персонала:
• бесплатныевебинары;
• бесплатные тренинги;
• бесплатная литература. Одиннадцатый этап. Принятие решения:
Принятие решения будет осуществляться для томской веб-студии, состоящей из 5 человек:
• Директор
• Менеджер проектов
• Дизайнер
• Верстальщик
• Программист
Доход компании до начала внедрения agile составляет 1 200 000 руб/месяц. Расход - 1 000 000 руб/месяц. Привлекательность компании - 1 балла из 4.
Для выбора оптимального решения необходимо оценить предложенные варианты решение по следующим критериям:
• Доход, руб. Важность критерия - 10 баллов.
• Расход, руб. Важность критерия - 8 баллов.
• Привлекательность компании, баллы. Важность критерия - 4 балла.
1. Приглашение agile-тренера - 15 баллов.
a. Доход. Рост дохода составит ~30%. (10 баллов)
b. Расход. Стоимость одного месяца работы тренера по внедрению - 200 000 рублей. Для успешного внедрения необходимо ~3 месяца. Итого расход: 600 000 рублей.(1 балл)
c. Привлекательность компании увеличивается в 2 раза. (4 балла)
2. Обучение персонала за счёт компании - 9 баллов.
a. Доход. Рост дохода ~ 10%. (3 балла)
b. Расход. Ежемесячно, в течение 3 месяцев, на обучение персонала выделяется по 10 000 рублей на одного человека. Компания из 5 человек тратит ежемесячно 50 000 рублей. Итого расход: 150 000 рублей. (4 балла)
c. Привлекательность компании увеличивается в 1,2 раза. (2 балла)
3. Самообучение персонала - 10 баллов.
a. Доход. Рост дохода ~ 5%. (1 балла)
b. Расход. 0 рублей. (8 баллов)
c. Привлекательность компании увеличивается в 1,1 раза. (1 балл) Наибольшее количество баллов набрал вариант с приглашением agile-
тренера. Не смотря на то, что это самый дорогой способ, в перспективе он принесёт наибольшую прибыль.
Использованные источники:
1. Тарасенко Ф.П., Прикладной системный анализ (Наука и искусство решения проблем): Учебник / Ф.П. Тарасенко. - Томск: Изд-во Том.ун-та, 2004. - 186с.
2. Расмуссон Дж., Гибкое управление IT-проектами. Руководство для настоящих самураев. - СПб.: Питер, 2012. - 272 с.
3. Поппендик М., Поппендик Т., Бережливое производство программного обеспечения: от идеи до прибыли.: Перевод с англ. - М.: ООО «И.Д. Вильямс», 2010. - 256 с.
4. Майк Кон, Scrum: гибкая разработка ПО.: перевод с англ. - М.: ООО «И.Д. Вильямс», 2011 - 567 с.
5. Лау Д., Google. Прошлое. Настоящее. Будущее / Джанет Лау ; перевод с англ. Е. Лалаян. - М.: Манн, Иванов и Фербер, 2010. - 320 с.
6. Manifesto for Agile Software Development [Электронныйресурс]. Режим доступа: http://agilemanifesto.org/
Акимов Р. А.
студент 2 курса магистратуры бизнеса Сибирский Государственный Аэрокосмический Университет им. М. Ф. Решетнева Россия, г.Красноярск КРИТЕРИИ ВЫБОРА РЫНКА ДЛЯ МЕЖДУНАРОДНОЙ ГАСТРОЛЬНОЙ ДЕЯТЕЛЬНОСТИ РОССИЙСКИХ МУЗЫКАЛЬНЫХ
ИСПОЛНИТЕЛЕЙ Международный музыкальный рынок является одним из главных приоритетов деятельности большинстваисполнителей и организаций культуры, но чтобы на него выйти и занять устойчивую позицию необходимо преодолеть большое количество барьеров.Один из значимых барьеров, требующий основательного изучения - выбор иностранного рынка.
В следствии того, что музыкальный бизнес в России находится на начальном этапе, по сравнению с развитыми странами, необходимоизучить и применять конкретные критерии выхода на иностранные рынкидля реализации международной гастрольной деятельности[3].
Каждая страна в мире имеет свою уникальную музыкальную культуру, менталитет, систему ценностей, политические и социальные взгляды. Любой из этих критериев непосредственно влияет на восприятие жителями разный стран иностранной музыкальной культуры. Из-за этого многие российские
