
- •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Сертификационные испытания пс
1.3Интегрированная система поддержки жизненного цикла
Андрей Алямовский 15.04.2001
Выбор систем автоматизированного проектирования и их конфигураций в условиях дефицита средств — весьма нетривиальная задача. Формальное или, наоборот, слишком личностное отношение на этапе выбора приводит к потерям средств и значительной временной задержке достижения целей. В статье рассматривается возможный подход к построению интегрированной системы на базе одной из САПР среднего уровня.
Как показывает опыт, нет ни одного заказчика, потребности которого — в том числе и подкрепленные финансовыми ресурсами ограничивались бы приобретением только графического редактора. Такую тенденцию проявляют все группы потребителей, независимо от степени использования ими средств автоматизированного проектирования. Распространенной — и благоприятной для бизнеса — является ситуация, когда изменение идеологии в сфере автоматизации совпадает с объективной потребностью перехода от чертежных систем к трехмерным твердотельным и гибридным параметрическим моделировщикам. При этом запросы заказчика к степени «интегрированности» и «полноты» решения даже для средних производств зачастую превосходят необходимые потребности и, несмотря на усилия разработчиков, часто находятся на грани возможностей надежных отчуждаемых продуктов.
Попытка охватить весь жизненный цикл изделия предпринята на сегодняшний день многими отечественными и зарубежными разработчиками. Явно выражены две тенденции: автоматизация «от функции» (на базе собственно инженерных компонентов САПР) и автоматизация от соответствующей системы PDM (product data management). Оба направления зачастую конкурируют, поскольку проблема интеграции самостоятельной PDM с имеющимися или предполагаемыми к внедрению прикладными системами весьма нетривиальна. Такой путь не порождает энтузиазма на уровне исполнителей, да и у руководства среднего звена не всегда находит сторонников. Причина — продолжительный «нулевой» цикл, отвлечение части персонала на решение задач, весьма далеких от текущих и среднесрочных вопросов. Естественным является также опасение, что реализация декларируемых преимуществ касающихся, как правило, весьма далеких перспектив, в конце концов, останется на уровне «внедрения», характерного для систем АСУП 10-15-летней давности. Сегодня оказывается, что только содержание и поддержка таких АСУП требовали штатов, сопоставимых с числом работников основного производства, и, соответственно, вносили весомый вклад в характерные для того времени 500 — 800% накладных расходов. Современная универсальная PDM-система — заведомо недешевый продукт, комплектуемый к тому же соответствующей лицензионной СУБД. Прибавьте затраты на содержание персонала «актуальных» профессий, весьма актуальных в регионах, и аргументы налицо.
Существенно более реалистичным на фоне дефицита финансовых ресурсов является вариант, когда инженерные решения первичны. Эта позиция тем более аргументирована, поскольку проекты уже есть, и менять графическую среду и, тем более «образ жизни», ради неочевидных перспектив весьма рискованно. Поэтому наиболее характерным является внедрение интегрированных систем на фоне имеющейся ситуации, приспосабливаясь к ней, не прерывая производственного процесса. Здесь возможны варианты.
Первый — графическая система с интегрированными модулями для поддержки жизненного цикла, которые разрабатываются тем же производителем, что и базовый продукт, или же поставляются под общей торговой маркой: Dassault Systemes, Unifraphics Solutions, PTC, «Toп Системы», «Аскон», НИЦ АСК. Достоинства импортных продуктов, с точки зрения отечественного потребителя, обычно ассоциируются с немалой ценой, отсутствием локализованных версий и русскоязычной документации, и, в конце концов, фундаментальными различиями в «менталитете». Кроме того, в ходе принятия решения о выборе базы для построения интегрированной системы необходим анализ стабильно работающих у отечественных заказчиков аналогов. Число их в России ограничивается единицами и далеко не все попытки внедрения, указываемые производителем в success story можно назвать удачными. Отечественные продукты свободны от этих проблем, но в них ощущается ориентация на «родную» графическую систему, что особенно проявляется при эксплуатации системы в гетерогенных средах. Кроме этого, по крайней мере сейчас, в этих системах многие аспекты проектирования, изготовления и сопровождения изделий моделируются поверхностно или отсутствуют.
Второй вариант предполагает построение интегрированной среды на базе «системообразующего» графического продукта, обладающего достаточной собственной универсальностью и развитыми интерфейсными возможностями. Одной из таких известных нам САПР является SolidWorks. Даже в базовой поставке — это больше, чем параметрический редактор, а принятая в системе концепция открытости, предполагающая интеграцию с ведущими производителями программного обеспечения из ряда отраслей делает ее устойчивым «скелетом» для построения функционально и организационно-ориентированных сред. Важным элементом такой интеграции является существование и, в некотором смысле, поддержка альтернативных конфигураций, что гарантирует возможность нахождения вполне приемлемых решений в реальных производственных ситуациях.
В таблице 1 приведена принципиальная схема применимости SolidWorks и приложений на всех этапах жизненного цикла изделия (см. терминологический словарь по CALS-технологиям, РД-1-000-99, www.cals.ru).
Заметим, что наличествует программное обеспечение, реализующее библиотеки деталей, менеджеры ведения проекта, расчетные модули.
В каждую группу могут входить приложения, имеющие сходное назначение, но отличающиеся по способу реализации, полноте функциональных возможностей, цене и т.д. Например, в группу «Численные методы анализа» вошли конечно-элементные и разностные модули для решения задач прочности, устойчивости, колебаний, моделирования литьевых процессов, аэрогидродинамики, теплового расчета, электромагнетизма, оптимального проектирования и т.д. К группе «Листовой металл» относятся приложения для получения разверток, решения задачи оптимального раскроя, генерации управляющих программ.
Поскольку номенклатура решений весьма широка, постоянно изменяется и дополняется, то я ограничусь лишь перечислением пакетов, апробированных нашей компанией или знакомым нам по достоверной информации, свидетельствующей о достаточной универсальности и надежности решения.
Следует отметить, что значительная часть приложений — это не «усеченные» модификации популярных программных продуктов, а самостоятельные продукты, использующие преимущества параметрического твердотельного и поверхностного моделирования. В частности, задача оптимального проектирования, ранее считавшаяся весьма экзотической и реализованная в специальных модулях «тяжелых» САПР, в связке с параметрической системой стала атрибутом настольных систем, где она входит в стандартную поставку, или отгружается дополнительно за незначительную доплату. Аналогична ситуация с процедурами построения разверток — благодаря «параметрической» идеологии, данный модуль включен в «стандартный» вариант SolidWorks и его возможности позволяют строить развертки призматических и круговых тонкостенных элементов с учетом параметров материала.
При создании интегрированной системы по описанной технологии, возникает проблема экспорта данных или интеграции с имеющимися графическими и расчетными программами. Задача решается двояко. Некоторые приложения (в частности, большинство «управленческих») имеют развитые интерфейсные возможности. Доступ к другим может осуществляться через SolidWorks, имеющий средства обмена для многих популярных графических форматов.
|
Рис. 1. Пример конструкции, реализованной в SolidWorks |
Описанная технология построения интегрированной системы позволяет подобрать нужную конфигурацию программно-аппаратных средств применительно к разнообразным и меняющимся потребностям, осуществлять процесс построения системы поэтапно, не прерывая производственного процесса, исходя как из функциональных критериев, так и финансовых ресурсов заказчика.
Андрей Алямовский (catia@dol.ru) — сотрудник компании «СиКоP» (Москва)
Таблица 2. Области применения и соответствующие программные продукты |
|
PDM/ERP |
SAP R/3 Integration for SolidWorks, Omega Production*, Босс Корпорация* |
Управление документооборотом |
Search* |
Анимация |
SolidWorks Animator |
Фотореалистические изображения |
PhotoWorks |
Численные методы анализа |
Cosmos/Works, FloWorks, ProCAST |
Трассировка кабелей |
EMbassyWorks |
Моделирование геометрии электронных компонентов |
CircuitWorks |
Трубопроводы |
SolidWorks Piping |
Библиотеки стандартных компонентов |
Технорма*, StandartWorks*, Toolbox/SE |
Трансляторы данных |
SolidWorks, CIMSW-Cat |
Расширенное геометрическое моделирование |
Rhinoceros, SurfaceWorks |
Воспроизведение геометрии |
FeatureWorks |
Детали машин и ТММ |
MechSoft, CamTrax, GearTrax |
Моделирование кинематики и динамики |
Dynamic Designer/Motion, visualNastran Motion |
Производство |
TechCard, MasterCAM, CAMWorks, SURFCAM |
Литье пластмасс и проектирование прессформ |
Moldflow Plastics Advisers, MoldWorks |
Моделирование оптических систем и явлений |
TracePro |
Прототипирование |
3D Lightyear |
Листовой металл |
SolidWorks, Flex3DSW |
Анализ точности |
Sigmund 1D, 3D |