
- •Безруков а.И. Экономические и правовые основы разработки программного обеспечения (Тексты лекций)
- •Лекция 1. Знакомство с предметом Введение
- •Программно-информационный продукт – особый вид товара Что такое программный продукт
- •Характеристики качества программного продукта
- •Лекция 2. Маркетинговые исследования Проблема управления производительными силами общества
- •Простое воспроизводство. Закон стоимости
- •Расширенное воспроизводство. Проблема распределения прибавочной стоимости
- •Что такое маркетинг?
- •Проблемы, решению которых может помочь проведение маркетинговых исследований
- •Цели и результаты маркетингового исследования
- •Выбор данных
- •Первичные данные
- •Вторичные данные
- •Сбор первичных данных Определение потребности в данных
- •Подготовка предложения по исследованию
- •Выбор метода
- •Определение выборки
- •Сбор данных
- •Анализ данных
- •Сообщение о результатах
- •Сбор и анализ вторичных данных Внешние данные
- •Внутренние данные
- •Анализ деятельности
- •Отчеты об объемах продаж
- •Выбор метода
- •Определение выборки
- •Сбор данных
- •Анализ данных
- •Сообщение о результатах
- •Сбор и анализ вторичных данных Внешние данные
- •Внутренние данные
- •Анализ деятельности
- •Отчеты об объемах продаж
- •Методы исследования
- •Качественные методы
- •Групповые дискуссии (фокус-группы)
- •Глубинные интервью
- •Проекционные методы
- •Наблюдения
- •Количественные методы
- •Эксперименты
- •Маркетинговая смесь
- •Лекция 3. Экономическая оценка затрат на создание компьютерных программ
- •Классификация видов затрат. Маржинальный анализ
- •Методики расчета различных видов затрат
- •Операционные затраты
- •Пример расчета операционных затрат
- •Операционные затраты
- •Специфические структурные затраты Затраты на оборудование
- •Затраты на оборудование
- •Приведение затрат к одному времени
- •Затраты на нематериальные активы
- •Затраты на лицензии
- •Общефирменные затраты и накладные расходы
- •Использование ms Excel
- •Пример использования электронной таблицы
- •Лекция 4. Оценка эффекта от использования компьютерных программ Классификация программного обеспечения как товара
- •Оценка доли эффекта от собственно разработки программного обеспечения
- •Программное обеспечение массового использования
- •Позиционирование на рынке программных продуктов
- •Пример оценки экономической эффективности программного продукта массового спроса
- •Виды обучающих компьютерных программ на cd
- •Индивидуальные программные продукты
- •Лекция 5. Пример оценки эффекта от внедрения системы управления
- •Описание объекта управления
- •Построение вероятностной модели предприятия
- •Определим условные вероятности последствий
- •Согласование данных
- •Требования к согласованности условных вероятностей
- •Оценка потерь от выбросов
- •Моделирование последствий внедрения системы мониторинга
- •Алгоритм оценки
- •Уровень зрелости фирмы. Стандарт cmm
- •Лекция 6. Управление рисками программного проекта
- •Риски, связанные с реализацией проекта
- •Разделение ответственности
- •Количественная оценка рисков
- •Определение размеров ресурсов, необходимых для снижения рисков
- •Типовые и специфические источники рисков
- •Откуда брать информацию о рисках
- •Лекция 7. Управление персоналом
- •Роль персонала в эффективности проекта
- •Обеспечение условий работы
- •Работа в потоке
- •Организация рабочего места
- •Формирование команды Что такое команда
- •Лидерство
- •Факторы, способствующие формированию команды
- •Факторы, препятствующие формированию команды
- •Инвестиции в человека
- •Лекция 8. Управление качеством Эволюция представлений о качестве Потерянный рай (допромышленное ремесленное производство)
- •Издержки промышленной революции
- •Система Тейлора
- •Главное не наказать, а найти причину (система Шухарта)
- •Новая философия качества (идеи Деминга)
- •Системы управления качеством Роль рынка, ориентация на потребителя
- •Человеческий фактор, роль персонала
- •Международные стандарты серии iso 9000
- •Тотальное управление качеством (tqm)
- •Современные представления об управлении качеством
- •Лекция 9. Система управления качеством программной разработки Требования к системе управления качеством организации Политика в области качества
- •Система менеджмента качества
- •Управленческая деятельность
- •Система требований
- •Информационное обеспечение принятия решений
- •Контроль качества
- •Вовлечение персонала, партнеров, потребителей и общества
- •Требования к развитию
- •Управление качеством при проектировании и разработке
- •Оценка готовности предприятия к выпуску качественного программного продукта
- •Методы управления качеством программных проектов Управление документацией
- •Виды программной документации
- •Управление конфигурацией
- •Элементы конфигурации программного проекта
- •Контроль качества в ходе проектирования
- •Лекция 10. Программный продукт как объект интеллектуальной собственности Что такое интеллектуальная собственность?
- •Авторское право и смежные права
- •Регистрация интеллектуальной собственности
- •Регистрирующие органы
- •Рассмотрение заявки на официальную регистрацию
- •Выдача свидетельства
- •Правовые аспекты использования интеллектуальной собственности
- •Правовое обеспечение создания и использования объектов ис
- •Правовая охрана объектов интеллектуальной собственности
- •Экономические аспекты
Разделение ответственности
Умение распределять ответственность – одна из важнейших составляющих культуры управления. В идеальном случае отвечать за риск должен тот, кто лучше всего может повлиять на его снижение. При этом, если распределение окажется неравномерным, рискующий вправе требовать от своих коллег компенсацию в виде дополнительных ресурсов, полномочий, авторитета и т.д. Рассмотрим типичное распределение ответственности:
Риск Разработчика (риск не успеть или не суметь разработать обещанное). Реализуемый проект или отдельные его требования могут оказаться значительно более сложными и трудоемкими, чем представлялось в момент заключения договора. Их реализация требует значительно больше времени и средств, чем запланировано, или вообще невозможна. Именно разработчик раньше всех может понять, что с проектом что-то не так и принять необходимые меры для исправления ситуации.
Риск Заказчика (риск сделать не то). Несмотря на то, что проект реализован в срок и соответствует условиям договора, он не может быть использован так, как планировалось. Например, функциональность проекта недостаточна для решения поставленной задачи. В этом случае, Заказчик не в праве обвинять Исполнителя в провале проекта. Ответственность за данный риск заставит Заказчика внимательно продумать условия договора, прежде, чем его подписывать
Риск исполнителя (риск не справиться с порученным делом). Когда руководитель поручал мне эту работу, я был уверен, что справлюсь. Это заставляет исполнителя ответственно браться за предложенную работу, а взявшись, приложить все усилия для ее успешного выполнения.
Риск руководителя (риск потратить имеющиеся ресурсы не на то). Исполнители выполнили всю порученную им работу, однако конечный результат не достигнут.
Форс-мажор (риск стечения обстоятельств). Все выполнили свои условия, однако по независящим от нас условиям проект не может быть использован, как намечено. Этот риск неизбежен, однако ни Разработчик, ни Заказчик не могут повлиять на него. В этом случае им придется разделить ответственность (и потери, в случае их возникновения) между собой.
Недопустимо сваливать ответственность за все риски на одного участника. Это плохо не только потому, что несправедливо, это пагубно для проекта. Дело в том, что вместе с ответственностью за риск, участник проекта снимает с себя мотивацию делать все, чтобы снизить этот риск. А взваливший на себя чужие риски объективно не может управлять ими. В результате вероятность риска и потери с ним связанные растут.
Количественная оценка рисков
Когда мы говорим о риске, мы имеем в виду три связанных вещи:
нежелательное событие
вероятность появления этого события
потери, связанные с появлением этого события.
Для количественной оценки риска введем понятие: ожидание риска - математическое ожидание потерь, связанных с данным риском. В простейшем случае единичного риска это произведение вероятности появления нежелательного события на размеры потерь. Если у нас имеется полная система событий (включая идеальный вариант) то ожидаемые потери от всех рисков есть математическое ожидание потерь.