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