
- •Безруков а.И. Экономические и правовые основы разработки программного обеспечения (Тексты лекций)
- •Лекция 1. Знакомство с предметом Введение
- •Программно-информационный продукт – особый вид товара Что такое программный продукт
- •Характеристики качества программного продукта
- •Лекция 2. Маркетинговые исследования Проблема управления производительными силами общества
- •Простое воспроизводство. Закон стоимости
- •Расширенное воспроизводство. Проблема распределения прибавочной стоимости
- •Что такое маркетинг?
- •Проблемы, решению которых может помочь проведение маркетинговых исследований
- •Цели и результаты маркетингового исследования
- •Выбор данных
- •Первичные данные
- •Вторичные данные
- •Сбор первичных данных Определение потребности в данных
- •Подготовка предложения по исследованию
- •Выбор метода
- •Определение выборки
- •Сбор данных
- •Анализ данных
- •Сообщение о результатах
- •Сбор и анализ вторичных данных Внешние данные
- •Внутренние данные
- •Анализ деятельности
- •Отчеты об объемах продаж
- •Выбор метода
- •Определение выборки
- •Сбор данных
- •Анализ данных
- •Сообщение о результатах
- •Сбор и анализ вторичных данных Внешние данные
- •Внутренние данные
- •Анализ деятельности
- •Отчеты об объемах продаж
- •Методы исследования
- •Качественные методы
- •Групповые дискуссии (фокус-группы)
- •Глубинные интервью
- •Проекционные методы
- •Наблюдения
- •Количественные методы
- •Эксперименты
- •Маркетинговая смесь
- •Лекция 3. Экономическая оценка затрат на создание компьютерных программ
- •Классификация видов затрат. Маржинальный анализ
- •Методики расчета различных видов затрат
- •Операционные затраты
- •Пример расчета операционных затрат
- •Операционные затраты
- •Специфические структурные затраты Затраты на оборудование
- •Затраты на оборудование
- •Приведение затрат к одному времени
- •Затраты на нематериальные активы
- •Затраты на лицензии
- •Общефирменные затраты и накладные расходы
- •Использование ms Excel
- •Пример использования электронной таблицы
- •Лекция 4. Оценка эффекта от использования компьютерных программ Классификация программного обеспечения как товара
- •Оценка доли эффекта от собственно разработки программного обеспечения
- •Программное обеспечение массового использования
- •Позиционирование на рынке программных продуктов
- •Пример оценки экономической эффективности программного продукта массового спроса
- •Виды обучающих компьютерных программ на cd
- •Индивидуальные программные продукты
- •Лекция 5. Пример оценки эффекта от внедрения системы управления
- •Описание объекта управления
- •Построение вероятностной модели предприятия
- •Определим условные вероятности последствий
- •Согласование данных
- •Требования к согласованности условных вероятностей
- •Оценка потерь от выбросов
- •Моделирование последствий внедрения системы мониторинга
- •Алгоритм оценки
- •Уровень зрелости фирмы. Стандарт cmm
- •Лекция 6. Управление рисками программного проекта
- •Риски, связанные с реализацией проекта
- •Разделение ответственности
- •Количественная оценка рисков
- •Определение размеров ресурсов, необходимых для снижения рисков
- •Типовые и специфические источники рисков
- •Откуда брать информацию о рисках
- •Лекция 7. Управление персоналом
- •Роль персонала в эффективности проекта
- •Обеспечение условий работы
- •Работа в потоке
- •Организация рабочего места
- •Формирование команды Что такое команда
- •Лидерство
- •Факторы, способствующие формированию команды
- •Факторы, препятствующие формированию команды
- •Инвестиции в человека
- •Лекция 8. Управление качеством Эволюция представлений о качестве Потерянный рай (допромышленное ремесленное производство)
- •Издержки промышленной революции
- •Система Тейлора
- •Главное не наказать, а найти причину (система Шухарта)
- •Новая философия качества (идеи Деминга)
- •Системы управления качеством Роль рынка, ориентация на потребителя
- •Человеческий фактор, роль персонала
- •Международные стандарты серии iso 9000
- •Тотальное управление качеством (tqm)
- •Современные представления об управлении качеством
- •Лекция 9. Система управления качеством программной разработки Требования к системе управления качеством организации Политика в области качества
- •Система менеджмента качества
- •Управленческая деятельность
- •Система требований
- •Информационное обеспечение принятия решений
- •Контроль качества
- •Вовлечение персонала, партнеров, потребителей и общества
- •Требования к развитию
- •Управление качеством при проектировании и разработке
- •Оценка готовности предприятия к выпуску качественного программного продукта
- •Методы управления качеством программных проектов Управление документацией
- •Виды программной документации
- •Управление конфигурацией
- •Элементы конфигурации программного проекта
- •Контроль качества в ходе проектирования
- •Лекция 10. Программный продукт как объект интеллектуальной собственности Что такое интеллектуальная собственность?
- •Авторское право и смежные права
- •Регистрация интеллектуальной собственности
- •Регистрирующие органы
- •Рассмотрение заявки на официальную регистрацию
- •Выдача свидетельства
- •Правовые аспекты использования интеллектуальной собственности
- •Правовое обеспечение создания и использования объектов ис
- •Правовая охрана объектов интеллектуальной собственности
- •Экономические аспекты
Оценка готовности предприятия к выпуску качественного программного продукта
От чего зависит качество разработки? Прежде всего, от каждого разработчика. От его квалификации, умения организовать свой труд и вовлеченности в процесс создания действительно качественного программного продукта. Для оценки готовности разработчика участвовать в серьезном проекте Институтом технологий разработки программного обеспечения (Software Engineering Institute (SEI)) разработан стандарт: «Индивидуальный процесс разработки программного обеспечения» PSP (Personal Software Process) [Э. Брауде]. Стандарт учитывает:
навыки самонаблюдения, сбора и фиксации объективных данных о своей работе (скорости написания кода, количестве ошибок на 1000 строк, время на отладку и т.д.);
способность разработчика к самоанализу и объективной оценке своего труда;
способность оптимизировать реализацию поставленной задачи и процесс разработки;
возможность оценки сложности поставленной задачи и сопоставления ее со своими силами;
навыки планирования работ и взаимодействия с коллегами;
умение тестировать отдельные модули и программный продукт в целом.
мотивация
На основании соответствия PSP принимается решение о готовности разработчика принять участие в проекте и его роли в этом проекте.
Современный программный продукт, как правило, достаточно трудоемкий. Чтобы опередить конкурентов выпустить его на рынок нужно в короткий срок. Поэтому разработкой должна заниматься команда специалистов. Успех разработки, ее трудоемкость и качество программного продукта существенно зависят от организованности команды, умения согласовывать и координировать свои действия для создания качественного продукта в сжатые сроки. Для оценки готовности команды к разработке проекта институт SEI разработал «Командный процесс разработки программного обеспечения» (TSP — Team Software Process).
Отношения, сложившиеся в команде должны способствовать объективности оценок планов и требований. Соглашаться с необоснованными требованиями и нереальными планами, считается признаком непрофессионализма даже в тех случаях, когда требуется так поступать. Управление в команде должно заключаться не только в распределении обязанностей, обеспечении ресурсов и контроле исполнения, но главное, в формировании отношений, обеспечивающих эффективное взаимодействие всех участников команды для лучшего решения поставленных задач.
Даже если собрать вместе высококвалифицированных программистов и организовать их в дружную команду, это не гарантирует успех проекта. Чтобы специалисты успешно работали и были заинтересованы в создании качественного продукта, нужно решить множество организационных проблем. Еще в 80-тые годы было подмечено, что для того чтобы успешно создавать конкурентоспособные программные продукты, фирма-разработчик должна созреть. Должна сформироваться особая культура управления и взаимодействия сотрудников и подразделений, в бизнес-процессах должны использоваться специальные процедуры, обеспечивающие управляемость процессов, их гибкость и ориентацию на достижения высшего качества. В стандарте «Модель зрелости возможностей» (Capability Maturity Model (CMM)), разработанном SEI выделяются 5 уровней зрелости организации (рис.19.1). Предприятие должно дорасти (дозреть) до внедрения более эффективных методов управления. Внедрение сложных и точных методов на незрелом предприятии приведет, скорее всего к напрасной трате средств.
Уровень 1: Начальный (Хаос). Качество ПО и процессов его разработки на данном уровне складывается случайно и напрямую зависит от способностей отдельных сотрудников и их настроения. Личности решают все. Объективные данные о трудозатратах, расписании и качестве не фиксируются. Стоимость разработки ПО высока, а результат непредсказуем.
Уровень 2: Контроль (Обеспечение повторяемости). Предприятие отслеживает свои процессы. Фиксируются данные о трудозатратах и планах. Имеются описания функциональности каждого проекта. Возможно объективное планирование и балансировка основных целей. Как следствие, возможно повторение ранее достигнутых успехов на аналогичных проектах. Качество ПО все еще зависит от способностей отдельных личностей. Основное внимание на данном уровне уделяется управляющим процессам. Результат становится предсказуемым. (В середине 1999 года только 20 % организаций имели уровень СММ 2 или выше).
Уровень 3: Установленный (Начало оптимизации). Процессы и действия задокументированы, стандартизованы и объединены в общий для всех проектов процесс создания ПО. Возможна достаточно точная временная и стоимостная оценка деятельности для проектов, аналогичных реализованным. За счет оптимизации основных бизнес-процессов предприятие снижает свои издержки. Процесс производства и качество ПО не определяется только способностями отдельных личностей. Основное внимание уделяется прикладным процессам и организационной поддержке. «инкубатор лидеров».
Уровень 4: Управляемый. Накоплены подробные данные о процессах работы (их стоимость, трудозатраты, проблемы). Это позволяет количественно оценивать, планировать и контролировать ход процессов. Основное внимание на данном уровне уделяется качеству продукции и процессов работы. Предприятие может адаптировать свои бизнес-процессы к условиям внешней рыночной среды.
Уровень 5: Оптимизированный. Предприятие становится лидером в своем секторе. Вместо того чтобы догонять остальных и пытаться предсказывать новые изменения в технологиях, предприятие обеспечивает непрерывное улучшение своих бизнес-процессов (Business Processes Improvement (BPI)). В настоящее время уровня 5 CMM достигли только несколько организаций в мире [].
Рис 19.1 Уровни зрелости предприятия по CMM