1.1 Структура управления разработкой программных средств.
Разработка ПС обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления. Традиционная структура такого рода обсуждена в работе Она представлена на рис.
Во главе этой иерархии находится директор (или вице-президент) программистской организации, отвечающий за управление всеми разработками программных средств. Ему непосредственно подчинены несколько менеджеров сферы разработок и один менеджер по качеству программных средств. В результате общения с потенциальными заказчиками директор принимает решение о начале выполнения какого-либо программного проекта, поручая его одному из менеджеров сферы разработок, а также решение о прекращение того или иного проекта. Он участвует в обсуждении общих организационных требований (ограничений) к программному проекту и возникающих проблем, решение которых требует использование общих ресурсов программистской организации или изменения заказчиком общих требований.
Менеджер сферы разработок отвечает за управление разработками программных средств (систем) определенного типа, например, программные системы в сфере бизнеса, экспертные системы, программные инструменты и инструментальные системы, поддерживающие процессы разработки программных средств, и другие. Ему непосредственно подчинены менеджеры проектов, относящихся к его сфере. Получив поручение директора по выполнению некоторого проекта, он организует формирование коллектива исполнителей по этому проекту (в частности, необходимую вербовку и обучение персонала). Он участвует в обсуждении плана-проспекта программного проекта, относящегося к сфере разработок, за которую он отвечает, а также в обсуждении и решении возникающих проблем в развитии этого проекта. Он организует обобщение опыта разработок программных средств в его сфере и накопление программных средств и документов для повторного использования.
Прежде всего, следует отметить, что оценка качества ПС производится по предъявленной спецификации его качества, т.е. оценивается только декларированное разработчиками качество ПС. При этом оценка качества ПС по каждому из критериев сводится к оценке каждого из примитивов качества, связанному с этим критерием качества ПС, в соответствии с их конкретизацией в спецификации качества этого ПС (см. лекцию 4). Различают следующие группы методов оценки примитивов качества ПС:
непосредственное измерение показателей примитива качества;
тестирование программ ПС;
экспертная оценка на основании изучения программ и документации ПС.
Непосредственное измерение показателей примитива качества производится путем проверки соответствия предъявленной документации (включая тексты программ на языке программирования) стандартам или явным требованиям, указанным в спецификации качества ПС, а также путем измерения времени работы различных устройств и используемых ресурсов при выполнении контрольных (тестовых) задач. Например, некоторым показателем эффективности по памяти может быть число строк программы на языке программирования, а некоторым показателем временнóй эффективности может быть время ответа на запрос пользователя.
Для оценки некоторых примитивов качества ПС используется тестирование [14.5-14.8]. К таким примитивам относятся, прежде всего, завершенность ПС, а также его точность, устойчивость, защищенность и другие примитивы качества. Этот вопрос уже обсуждался в лекции 10. Однако, во время приемо-сдаточных испытаний нет необходимости проведения тестирование ПС в полном объеме (это может слишком дорого стоить). Аттестационная комиссия должна, прежде всего, изучить предъявленную документацию по проведенному разработчиками тестированию ПС и лишь выборочно пропустить предъявленные тесты. Дополнительные тесты составляются, если у комиссии возникают определенные сомнения в полноте тестирования, проведенного разработчиками. Кроме того, обычно работоспособность и некоторые показатели качества ПС демонстрируются на решении контрольных задач, предъявляемых заказчиком.
В некоторых случаях для оценки качества ПС проводятся дополнительные полевые или промышленные испытания [14.8, 14.9]. Полевые испытания ПС – это демонстрация ПС вместе с технической системой, которой управляет эта ПС, с обеспечением тщательного наблюдения за поведением ПС. Заказчикам должна быть предоставлена возможность задания собственных контрольных примеров, в частности, с выходом в критические режимы работы технической системы, а также с вызовом в ней аварийных ситуаций. Промышленные испытания ПС – это процесс передачи ПС в постоянную эксплуатацию пользователям, представляющий собой опытную эксплуатацию ПС (см. лекцию 10) пользователями со сбором информации об особенностях поведения ПС и ее эксплуатационных характеристиках.
Многие примитивы качества ПС трудно уловимы с точки зрения их (объективной) оценки. В этих случаях иногда применяют метод экспертных оценок. Этот метод заключается в следующем. Назначается группа экспертов и каждый из этих экспертов в результате изучения представленной документации составляет свое мнение об обладании ПС требуемым примитивом качества. Затем голосованием членов этой группы устанавливается оценка требуемого примитива качества ПС, т.е. получаемая оценка является некоторым усреднением совокупности субъективных оценок. Эта оценка может производиться как по двухбалльной системе ("обладает" "не обладает"), так и учитывать степень обладания ПС этим примитивом качества (например, производиться по пятибальной системе) в соответствии с требованиями относительно этого примитива, сформулированными в спецификации качества аттестуемого ПС.
- Тема 1 Основные понятия и определения
- Тема 3 Проектирование программных продуктов.
- Основные группы методов
- Эвристические методы
- Метод итераций (последовательного приближения)
- Метод декомпозиции
- Метод контрольных вопросов
- Тема 4 Структура и формат, статические и динамические данные.
- Тема 5 Стандартизация программных продуктов
- Стандартизация программных продуктов
- Система качества пп
- Тема 6 Модульное программирование
- Тема 6 Модульное программирование
- 2. Минимизации количества передаваемых параметров
- Тема 7 Эффективность и оптимизация программ
- 1. Эффективность и технологичность. Способы экономии памяти. Способы уменьшения времени выполнения
- 2. Правила оптимизации программ
- Жертвуем памятью ради скорости
- Жертвуем скоростью ради памяти
- Логические правила
- Составление процедур
- Составление выражений
- Тема 8 Требования и спецификация качества к программных продуктов
- Тема 9 Защита программ
- Тема 10 Инструментальные средства разработки программ
- Тема 11 Коллективная разработка программных средств
- 1.1 Структура управления разработкой программных средств.
- Тема 12 Объектный подход к разработке программных продуктов
- Тема 13 Факторы надежности программных продуктов
- Тема 14 Структурное программирование программных продуктов
- Тема 15 Объектно-ориентированное программирование (ооп)
- Тема 15 Объектно-ориентированное программирование (ооп)
- Тема 16 Стиль программирования
- Тема 16 Стиль программирования
- Тема 17 Отладка, тестирование, сопровождение программ
- 2.Тестирование «белым ящиков»
- 6.Виды сопровождения и отладок пп.
- Тема 18 Экономические аспекты создания и использования программных средств
- Тема 20 Пакеты прикладных программ
- Тема 21 Язык программирования Турбо-Пролог
- Язык Пролог
- Тема 22 Списки и структуры в Прологе.
- Списки в Прологе
- Тема 23 Работа с файлами и динамическими базами данных в Прологе
- Работа с файлами
- Работа с файлами
- 3.6.3. Динамические базы данных