Т ехнологии проектирования ИС

Понятие технологии проектирования Технология (греч.) – искусство, мастерство, умение, совокупность методов изготовления продукции. Метод – способ достижения поставленной цели, решения конкретной задачи. Энциклопедический словарь Технология проектирования определяется как совокупность трех составляющих: – пошаговой процедуры, определяющей последовательность технологических операций проектирования; – критериев и правил, используемых для оценки результатов выполнения технологических операций (соответствие стандартам); – нотаций (графических и текстовых средств), используемых для описания проектируемой системы. 2

Технология канонического проектирования Технология автоматизированного проектирования Основные усилия – на кодирование и тестирование Основные усилия – на анализ и проектирование "Бумажные" спецификации Быстрое итеративное макетирование Ручное кодирование Автоматическая генерация машинного кода Тестирование ПО Автоматический контроль проекта Сопровождение программного кода Сопровождение проекта 6

Оценка трудозатрат по фазам жизненного цикла ИС 7 Каноническое проектирование Автоматизированное проектирование

Компоненты интегрированного CASE- средства 1. Средства централизованного хранения информации о проектируемой ИС в течение всего ЖЦ (репозиторий) 2. Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм. 3. Средства разработки приложений, предназначенные для автоматизированной код генерации и тестирования. 4. Средства документирования, управления проектом и реинжиниринга. 8

Классификация по типам CASE-средств Тип CASE-средства Назначение Средства анализа – Upper CASE (BPWin) Построение и анализ моделей предметной области Средства анализа и проектирования – Middle CASE (Designer/2000) Создание проектных спецификаций компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных Средства проектирования баз данных (ERWin) Моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. Средства разработки приложений (Delphi) Генерация программного кода компонентов системы Средства реинжиниринга (Rational Rose) Анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. 9

Другие виды классификации CASE- средств Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает: – отдельные локальные средства, решающие небольшие автономные задачи (tools); – набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit); – полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Классификация по применяемым методологиям и моделям систем и БД; Классификация по степени интегрированности с СУБД; Классификация по доступным платформам. 10

Технология внедрения CASE-средств Технология внедрения CASE-средств базируется на стандартах IEEE (Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Этапы внедрения CASE-средств: Определение потребностей в CASE- средствах Оценка и выбор CASE-средств Выполнение пилотного проекта Полномасштабное внедрение CASE-средств 11

Факторы, влияющие на выбор CASE- средств Относительная простота или сложность средства; степень согласованности с существующими в организации бизнес-процессами; требуемая степень интеграции с другими программными средствами; опыт и квалификация пользователей. 12

I этап – Определение потребностей в CASE-средствах 13

Анализ возможностей организации Анализируются возможности организации в отношении ее технологической базы, персонала и используемого ПО. Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами – ISO 9001: 1994 – ISO : 1991 – ISO :1991 – ГОСТ Р ИСО , гр. Т59 «Рекомендации по улучшению деятельности». Неформальные подходы базируются на использовании анкетирования сотрудников и руководства по вопросам текущей практики использования ПО, технологии и персонала. Для удобства составления анкет эти вопросы могут быть разбиты на 5 групп. 14

Группа 1 - Общие вопросы Используемая модель ЖЦ разработки ИС (каскадная или спиральная); используемые методы (структурные, объектно- ориентированные); квалификация сотрудников; наличие документированных стандартов (формальных или неформальных) по анализу требований, спецификациям и проектированию, кодированию и тестированию; виды документации, выпускаемой в процессе ЖЦ ПО. 15

Группа 2 – проекты, ведущиеся в организации Средняя продолжительность проекта в человеко- месяцах; среднее количество специалистов, участвующих в проектах различных категорий; средний размер проектов различных категорий в терминах кодовых метрик (например, в строках исходных кодов). 16

Группа 3 – технологическая база Перечень вычислительных ресурсов; уровень доступности ресурсов, узкие места, среднее время ожидания ресурсов; перечень ПО, используемое в организации, и его характер (готовые программные продукты, собственные разработки); степень интеграции используемых программных продуктов, механизмы интеграции (существующие и планируемые); уровень использования сетевых возможностей, доступных группе разработчиков; используемые языки программирования; средний процент вновь разрабатываемых, повторно используемых и реально эксплуатируемых приложений. 17

Группа 4 – персонал Реакция сотрудников организации на внедрение новой технологии. Наличие опыта успешных или безуспешных внедрений; наличие лидеров, способных серьезно повлиять на отношение к новым средствам; наличие стремления у рядовых сотрудников к совершенствованию средств и технологии; объем обучения, необходимого для ориентации пользователей в новой технологии; стабильность и уровень текучести кадров. 18

Группа 5 – готовность Поддержка проекта со стороны высшего руководства; готовность организации к долгосрочному финансированию проекта; готовность организации к выделению необходимых специалистов для участия в процессе внедрения и к их обучению; готовность персонала к существенному изменению технологии своей работы; степень понимания персоналом масштаба изменений; готовность технических специалистов и менеджеров к возможному снижению продуктивности своей работы; готовность руководства к долговременному ожиданию отдачи от вложенных средств. 19

Определение потребности организации Потребности организации следуют непосредственно из целей, которые она стремится достичь. Проблемы и цели могут быть связаны с управлением, производством продукции, экономикой, персоналом или технологией. Определение потребностей должно выполняться в сочетании с обзором рынка CASE-средств, поскольку информация о технологиях, доступных на рынке в данный момент, может оказать влияние на потребности. Цель организации: использовать CASE-технологию для достижения определенного уровня CMM или сертификации в соответствии с ISO Потребности, соответствующие цели: – переход от каскадной модели ЖЦ ПО к спиральной; – поддержка технологического процесса разработки ПО; – выпуск нормативной и технологической документации. Матрица соответствия потребностей организации возможностям CASE- средств поможет определиться с выбором конкретного программного продукта. 20

Ожидаемые результаты Реалистичные ожидания Нереалистичные ожидания поддержка реижиниринга бизнес- процессов; поддержка реижиниринга бизнес- процессов; ускорение и повышение согласованности разработки приложений; ускорение и повышение согласованности разработки приложений; снижение доли ручного труда в процессе разработки и эксплуатации; снижение доли ручного труда в процессе разработки и эксплуатации; более точное соответствие приложений требованиям пользователей; более точное соответствие приложений требованиям пользователей; повышение качества документирования; повышение качества документирования; улучшение коммуникации между пользователями и разработчиками; улучшение коммуникации между пользователями и разработчиками; повышение качества проектирования; повышение качества проектирования; повторное использование разработок; повторное использование разработок; кратковременное возрастание затрат, связанное с деятельностью по внедрению CASE-средств кратковременное возрастание затрат, связанное с деятельностью по внедрению CASE-средств отсутствие воздействия на общую культуру и распределение ролей в организации; отсутствие воздействия на общую культуру и распределение ролей в организации; понимание проектных спецификаций неподготовленными пользователями; понимание проектных спецификаций неподготовленными пользователями; сокращение персонала, связанного с ИТ; сокращение персонала, связанного с ИТ; уменьшение степени участия в проектах высшего руководства и менеджеров; уменьшение степени участия в проектах высшего руководства и менеджеров; немедленное повышение продуктивности деятельности организации; немедленное повышение продуктивности деятельности организации; достижение абсолютной полноты и непротиворечивости спецификаций; достижение абсолютной полноты и непротиворечивости спецификаций; автоматическая генерация прикладных систем из проектных спецификаций; автоматическая генерация прикладных систем из проектных спецификаций; немедленное снижение затрат, связанных с информационной технологией; немедленное снижение затрат, связанных с информационной технологией; снижение затрат на обучение. снижение затрат на обучение. 21

Статьи затрат на внедрение CASE- средств Затраты на специалистов по планированию внедрения CASE-средств; технические средства; приобретение, настройка CASE-средств и обучение пользователей; освоение средств разработчиками; интеграция с другими средствами и существующими данными; подготовка документации, стандартов и процедур использования средств; обновление версий. 22

Анализ рынка CASE-средств Анализ рынка CASE-средств выполняется с целью выбора CASE-средства, максимально удовлетворяющего потребностям организации. Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке. При проведении данного анализа необходимо выяснить возможность интеграции конкретного CASE-средства с другими средствами, используемыми (или планируемыми к использованию) организацией. 23

Определение критериев успешного внедрения Критерии должны позволять количественно оценивать степень удовлетворения каждой из потребностей организации, связанных с внедрением. По каждому критерию должно быть определено его конкретное оптимальное значение. Информация о таких метриках приведена в стандартах: IEEE Std (IEEE Standard for Software Productivity Metrics) IEEE Std (IEEE Standard for a Software Quality Metrics Methodology) 24

Примеры критериев успешного внедрения Оценка степени успешности внедрения включает: процент проектов, использующих CASE-средства; рейтинговые оценки уровня квалификации специалистов; результаты опросов персонала по поводу отношения к использованию CASE-средств; соблюдение стандартов организации; степень повторного использования существующих компонентов; объем и виды необходимого обучения. 25

Разработка стратегии внедрения CASE-средств Стратегия включает: организационные потребности; базовые метрики для последующего сравнения результатов; критерии успешного внедрения, связанные с удовлетворением организационных потребностей; подразделения организации, в которых должно выполняться внедрение CASE-средств; влияние, оказываемое на другие подразделения организации; основные факторы риска; ориентировочный уровень расходов и источники финансирования процесса внедрения CASE-средств; ключевой персонал и другие ресурсы. 26

Нисходящий подход Нисходящий подход к разработке стратегии внедрения CASE-средств предполагает общий анализ процесса разработки ИС в организации, что зачастую влечет за собой общую реорганизацию процессов разработки ИС. Результатом такой реорганизации становится крупномасштабная стратегия автоматизации процессов создания и сопровождения ИС. Нисходящий подход рекомендуется для относительно зрелых организаций с устоявшимися процессами разработки ИС. Для повышения вероятности успеха требуется принятие серьезных обязательств со стороны как руководства, так и потенциальных пользователей. 27

Нисходящий подход Преимущества Недостатки Охват всех процессов создания и сопровождения ИС с максимально возможной их автоматизацией; Охват всех процессов создания и сопровождения ИС с максимально возможной их автоматизацией; приобретение интегрированного (или интегрируемого) набора средств, поскольку каждая отдельная поставка подчиняется общей стратегии. приобретение интегрированного (или интегрируемого) набора средств, поскольку каждая отдельная поставка подчиняется общей стратегии. Необходимость в значительных людских и финансовых ресурсах; Необходимость в значительных людских и финансовых ресурсах; не позволяет пользователям быстро приступить к практическому использованию средств; не позволяет пользователям быстро приступить к практическому использованию средств; приводит к серьезным изменениям существующих в организации процессов; приводит к серьезным изменениям существующих в организации процессов; трудности в управлении внедрением. трудности в управлении внедрением. 28

Восходящий подход Восходящий подход начинается с определения некоторого средства или типа средств, которые потенциально могут помочь организации в улучшении выполнения текущей работы. Организация может затем оценить возможное воздействие средств на процесс разработки ИС. Восходящий подход рекомендуется для организаций с узко специфическими потребностями в автоматизации, не нуждающихся в общем совершенствовании процессов разработки ИС. 29

Восходящий подход Преимущества Недостатки минимальные финансовые затраты; минимальные финансовые затраты; минимально короткий срок автоматизации с быстрым устранением известных недостатков в существующих процессах; минимально короткий срок автоматизации с быстрым устранением известных недостатков в существующих процессах; лучшая контролируемость воздействий, оказываемых на существующие процессы. лучшая контролируемость воздействий, оказываемых на существующие процессы. плохая интегрируемость разрозненных средств, что может привести к необходимости выполнения большого объема ручной работы; плохая интегрируемость разрозненных средств, что может привести к необходимости выполнения большого объема ручной работы; фундаментальные проблемы, связанные с широким кругом процессов разработки ПО, обычно не решаются. фундаментальные проблемы, связанные с широким кругом процессов разработки ПО, обычно не решаются. 30

Характеристики пилотного проекта Типичность предметной области Небольшой, но значимый размер Масштабируемость Критичность Авторитетность специалистов Готовность проектной группы 31

Оценка пилотного проекта В процессе оценки пилотного проекта необходимо ответить на следующие вопросы: Целесообразно ли внедрять CASE-средство? Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)? Какие проекты или подразделения в организации могли бы получить выгоду от использования CASE- средства? 32

Результаты пилотного проекта Внедрить CASE-средство. Выполнить дополнительный пилотный проект. Отказаться от данного CASE-средства. Отказаться от использования CASE- средств вообще. 33

Полномасштабное внедрение CASE- средств План перехода включает: информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана; информацию относительно приобретения, установки и настройки CASE-средств; информацию относительно интеграции с существующими средствами, включая как интеграцию средств друг с другом, так и их интеграцию в процессы разработки и эксплуатации ПО, существующие в организации; ожидаемые потребности в обучении; ресурсы, используемые в течение и после завершения процесса перехода; определение стандартных процедур использования CASE- средств. 34

Стандарты, используемые при внедрении CASE-средств стандарты моделирования и проектирования; соглашения по присвоению имен; процедуры контроля качества и процессов приемки, включая расписание экспертиз и используемые методологии; процедуры резервного копирования, конфигурирования и защиты базы данных проекта; процедуры интеграции с существующими средствами и базами данных; процедуры совместного использования данных и контроля целостности БД; стандарты и процедуры обеспечения секретности; стандарт оформления проектной документации; стандарт интерфейса пользователя. 35