
- •1.12. Лекция: Процесс разработки программного обеспечения
- •1.1.1[Править] Процесс
- •1.1.2[Править] Совершенствование процесса
- •1.1.3[Править] Классические модели процесса
- •1.2[Править] 3. Рабочий продукт, дисциплина обязательств, проект
- •1.2.1[Править] Рабочий продукт
- •1.2.2[Править] Дисциплина обязательств
- •1.2.3[Править] Проект
- •1.3Интегрированная система поддержки жизненного цикла
- •1.4Введение
- •Определение ис
- •Классификация ис
- •Классификация по масштабу
- •Классификация по архитектуре
- •Классификация по характеру использования информации
- •Классификация по системе представления данных
- •Классификация по поддерживаемым стандартам управления и технологиям коммуникации
- •Классификация по степени автоматизации
- •Роль требований в задаче внедрения аис
- •1.5Понятие требования. Классификации требований
- •1.5.1Определение понятия требования
- •1.5.2Классификация требований
- •Требования к продукту и процессу
- •Уровни требований
- •Системные требования и требования к программному обеспечению
- •Функциональные, нефункциональные требования и характеристики продукта
- •Классификация rup
- •1.5.3Методологии и стандарты, регламентирующие работу с требованиями
- •1.6Свойства требований
- •Полнота.
- •Ясность (недвусмысленность, определенность, однозначность спецификаций).
- •Корректность и согласованность (непротиворечивость).
- •Верифицируемость (пригодность к проверке).
- •1.7Процесс анализа требований
- •1.7.1Рабочий поток анализа требований
- •1.7.2Почему нужно анализировать требования?
- •1.7.3Кто создает и использует требования
- •1.7.4Организация работы с требованиями на примере msf
- •1.8Контекст задачи анализа требований
- •1.8.1Анализ требований, бизнес-анализ, анализ проблемной области
- •Роль глоссария при ат.
- •1.8.2Методологии бизнес-анализа
- •1.8.3Требования и архитектура аис
- •1.8.4Анализ требований и другие рабочие потоки программной инженерии
- •1.9Выявление требований
- •1.9.1Источники требований
- •1.9.2Стратегии выявления требований Интервью
- •1. Подготовка
- •2. Проведение опроса
- •Завершение
- •Что нужно помнить при опросе
- •Анкетирование
- •Наблюдение
- •Самостоятельное описание требований
- •Совместные семинары
- •Прототипирование
- •1.10Формирование видения
- •1.10.1Видение продукта и границы проекта
- •1.10.2Концепция в гост рф
- •1.10.3Видение в rup
- •1.10.4Видение / рамки в msf
- •1.11Классификация и специфицирование требований
- •1.11.1Акторы и варианты использования
- •1.11.2Глоссарий
- •1.11.3Спецификация варианта использования
- •Свободный формат
- •Шаблон полного описания варианта использования по а. Коберну
- •Табличные представления варианта использования
- •Шаблон варианта использования rup
- •1.12Расширенный анализ требований. Моделирование
- •1.12.1Какие модели использовать
- •1.12.2Модели uml, поясняющие функциональность системы Диаграмма вариантов использования
- •Диаграмма действий
- •Диаграмма состояний
- •1.12.3Диаграммы uml, поясняющие внутреннее устройство системы
- •Диаграмма классов
- •1.12.4Альтернативные языки моделирования Диаграмма потоков данных
- •Другие виды моделей
- •1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы
- •1.13.1Цели прототипирования
- •1.13.2Классификация прототипов
- •Горизонтальный прототип
- •Вертикальный прототип
- •Одноразовый прототип
- •Эволюционный прототип
- •Бумажный прототип
- •Раскадровка
- •1.13.3Иллюстрированные сценарии прецедентов
- •Ориентиры
- •Средние значения атрибутов и объемы объектов
- •Средняя интенсивность использования
- •1.14Документирование требований
- •1.14.1Документирование требований в соответствие с гост рф
- •Структура тз в соответствие с гост 34.602-89
- •Описание требований к системе в соответствие с гост 34.602-89
- •1.14.2Документирование требований в rup
- •1.14.3Документирование требований на основе ieee Standard 830-1998
- •1.14.44. Требования к внешнему интерфейсу
- •4.1 Интерфейсы пользователя
- •4.2 Интерфейсы оборудования
- •4.3 Интерфейсы по
- •4.4 Интерфейсы передачи информации
- •1.14.55. Другие нефункциональные требования
- •5.1 Требования к производительности
- •1.14.6Документирование требований в msf
- •1.15Проверка требований
- •1.15.1Верификация и валидация
- •1.15.2Некоторые типичные проблемные ситуации процесса формирования и оценки требований Двусмысленность требований
- •"Золочение" продукта
- •Минимальная спецификация
- •Пропуск типов пользователей
- •1.15.3Методы и средства проверки требований
- •Неофициальные просмотры требований
- •Инспекции
- •Разработка тестов
- •Определение критериев приемлемости
- •1.16Введение в управление требованиями.
- •1.16.1Принципы и приемы управления требованиями Базовая версия требований
- •Процедуры управления требованиями
- •Контроль версий
- •Атрибуты требований
- •Контроль статуса требований
- •Измерение трудозатрат, необходимых для управления требованиями
- •1.16.2Управление изменениями Управление незапланированным ростом объема
- •Процесс контроля изменений
- •Анализ влияния изменения
- •Трассируемость требований
- •1.17Совершенствование процессов работы с требованиями
- •1.17.1Модели совершенствования
- •Область процессов "Управление требованиями"
- •Область процессов "Разработка требований"
- •1.17.2Принципы совершенствования
- •1.17.3Процесс совершенствования
- •Оценка текущих приемов
- •Планирование
- •Создание и апробация новых процессов
- •Оценка результатов и принятие решений
- •1.18Требования в управлении проектом
- •1.18.1От рамок проекта к экспресс-планированию
- •1.18.2Планирование проекта на основе требований, путь rup
- •1.18.3Требования в гибких методологиях
- •Артефакты для работы с требованиями в гибких методологиях
- •Планирование на основе требований на примере xp
- •Планирование версий и итераций
- •1.18.4Анализ требований и управление рисками
- •1.18.5Стратегии и работы по управлению риском
- •1.19Заключение
- •1.19.1Современные тенденции в развитии аис и технологий их создания
- •1.19.2Покупное или заказное по - критерии выбора
- •1.19.4Процесс выбора решения
- •1.20Список литературы
- •Белые страницы msf
- •Microsoft Solutions Framework. Модель процессов msf, версия 3.1
- •Гост 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания
- •Гост 19.201-78 "Техническое задание, требования к содержанию и оформлению"
- •Гост 34.602-89 "Техническое задание на создание автоматизированной системы" (тз на ас)
- •1 Аттестации и программного обеспечения
- •1.1 Перечень объектов, подлежащих сертификации, и их характеристики
- •2 Оценка программного обеспечения
- •3 Системы сертификации программного обеспечения и ее стандарты
- •4 Виды испытаний программного обеспечения
- •Стандарты в области промышленного обеспечения.
- •Структура современного рынка программных средств
- •2Введение в программную инженерию
- •2.1Программная инженерия
- •2.2Связь программной инженерии с другими сферами науки
- •3Жизненный цикл пс
- •4Процесс создания пс
- •4.1Стадии разработки пс
- •4.2Понятие метода и технологии проектирования пс
- •4.2.1Определение метода и технологии
- •4.2.2Требования к технологии
- •5Подходы к проектированию по
- •5.1Нисходящий и восходящий подходы к разработке программ
- •5.2Макетирование
- •5.3Структурное программирование
- •5.4Модульное программирование (мп)
- •5.5Формирование структуры модулей программы
- •5.6Подход к разработке программных средств, используемых для автоматизации организационных процессов
- •6Управление требованиями
- •6.1Определение требования и заинтересованного лица
- •6.2Пирамида Требований
- •6.3Трассировка (Связь) между Требованиями
- •6.4Характеристики Хорошего Требования
- •6.5Процесса Управления Требованиями
- •7Модели жизненного цикла пс
- •7.1Каскадный жизненный цикл
- •7.2Спиральная модель
- •7.3Подход rad
- •8Ресурсы для жизненного цикла сложных программных средств
- •9Показатели качества программных средств
- •10Модели качества процессов конструирования
- •10.2Стандарты iso
- •10.3Шесть сигм
- •11Стандартизация пс
- •11.1Стандартизация программных продуктов
- •11.2Виды стандартных программных документов
- •11.3Стандартизация программных документов
- •12Тестирование пс
- •12.1Аттестация пс
- •12.2Испытания пс
- •12.3Оценка пс
- •12.4Виды испытаний по
- •13Сертификация пс
- •13.1Правовые акты по сертификации программных продуктов
- •13.2Сертификация пс
- •13.3Перечень объектов, подлежащих сертификации и их характеристики
- •13.4Сертификационные испытания пс
8Ресурсы для жизненного цикла сложных программных средств
Общее понятие - доступные ресурсы жизненного цикла ПС включает реальные финансовые, временные, кадровые и аппаратурные ограничения, в условиях которых происходит создание и совершенствование комплексов программ. В зависимости от характеристик объекта разработки на ее выполнение выделяются ресурсы различных видов и объема. Эти факторы проявляются как дополнительные характеристики программных продуктов и их рентабельности, которые следует учитывать и оптимизировать, начиная с системного анализа ЖЦ ПС. В результате доступные ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов разработки, на достигаемые качество и эффективность применения ПС. Многие проекты информационных систем терпели и терпят неудачу из-за отсутствия у разработчиков и заказчиков при подготовке контракта четкого представления о реальных финансовых, трудовых, временных иных ресурсах, необходимых для их реализации. Поэтому одной из основных задач при системном проектировании ПС является экономический анализ и определение необходимых ресурсов для создания и всего ЖЦ ПС в соответствии с требованиями контракта и технического задания.
Наиболее общим видом ресурсов, используемых в жизненном цикле ПС, являются допустимые финансово-экономические затраты или эквивалентные им величины трудоемкости соответствующих работ. При разработке, тестировании и анализе качества этот показатель может применяться или как вид ресурсных ограничений, или как оптимизируемый критерий, определяющий целесообразную функциональную пригодность ПС. При этом необходимо также учитывать затраты на разработку, закупку и эксплуатацию системы качества, на технологию и комплекс автоматизации проектирования программ и баз данных, которые могут составлять существенную часть совокупной стоимости и трудоемкости разработки и всего ЖЦ ПС.
Время или допустимая длительность разработки определенных версий ПС является "невосполнимым ограниченным ресурсом реальных проектов. Этот ресурс все больше определяет достижимое качество комплексов программ в процессе их разработки и сопровождения. Высокие требования заказчиков к сжатым срокам реализации проектов, естественно, ограничивают разработчиков и испытателей в продолжительности и объеме возможного системного анализа и проектирования, разработки и, особенно, тестирования программ. Увеличение числа, привлекаемых для этого специалистов, при опытной эксплуатации или тестировании, только в некоторых пределах позволяет ускорять разработку и увеличивать совокупное число тестов при проверках, для повышения качества программ.
Кадры специалистов можно оценивать численностью, а также тематической и технологической квалификацией, которые всегда ограничены. В создании крупномасштабных ПС участвуют системные аналитики и руководители различных рангов, программисты и вспомогательный обслуживающий персонал в некотором, желательно, рациональном сочетании. Определяющими являются совокупная численность и структура коллектива, а также его подготовленность к коллективной разработке конкретного типа ПС и к применению им системы обеспечения качества функционирования.
Доступные разработчикам ПС вычислительные ресурсы объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС. В процессе проектирования целесообразно выделять определенные ресурсы ЭВМ на оперативное обеспечение качества, повышение защищенности и надежности функционирования. Допустимая величина и рациональное распределение ресурсов ЭВМ на отдельные методы улучшения определенных конструктивных характеристик качества ПС, оказывают существенное влияние на достигаемые их значения.
Обобщенными ресурсами проекта ПС являются доступные стоимость или совокупные трудовые, временные и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ. Эти характеристики непосредственно влияют практически на все показатели качества и определяют рентабельность покупки или создания заново конкретного программного продукта. Это означает, что качество является относительным понятием, которое зависит от ресурсов и субъектов, осуществляющих его оценку с позиции эффективности использования, а также от состояния рынка соответствующей продукции, ее производителей и технологий. Ориентация на потребителей подразумевает анализ их нужд и определение возможностей рынка удовлетворить эти потребности. При этом следует учитывать рыночную конкуренцию двух видов: между поставщиками готовых к применению программных средств с фиксированным качеством и между разработчиками, способными обеспечить жизненный цикл ПС или его существенную часть, с характеристиками качества, требующимися конкретному заказчику. В последнем случае на требуемое качество могут оказывать влияние не только заказчик и непосредственные пользователи, но и различные посредники, организационные и торговые структуры, а также исполнители проекта.
В начале проектирования ПС всегда возникает задача оценивания ресурсов, которые необходимы и доступны для создания и обеспечения всего ЖЦ ПС, а также возможной экономической эффективности последующего применения комплекса программ по назначению при условии реализации требуемых характеристик качества. Экономическая эффективность и затраты имеют самостоятельное значение и методологию при анализе ЖЦ ПС. При планировании проектов программных средств, часто инициатором разработки является разработчик-поставщик, который самостоятельно принимает все решения о проектировании за счет собственных ресурсов и предполагает возместить затраты при реализации ПС на рынке. В других случаях имеется определенный заказчик потребитель, который способен задать основные цели, характеристики качества и обеспечить ресурсы для реализации проекта. Таким образом, при экономическом анализе проектов ПС возможны два сценария:
создание и весь жизненный цикл комплекса программ и/или базы данных ориентируется разработчиком на массовое тиражирование и распространение на рынке, для заранее не известных покупателей-пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель-заказчик, который определяет и диктует основные требования, а также финансирует проект;
разработка проекта ПС и/или БД предполагается поставщиком разработчиком для конкретного потребителя-заказчика, который его финансирует, с определенным, необходимым ему тиражом и известной, ограниченной областью применения результатов разработки.