41409

Промышленные технологии проектирования ИС

Лекция

Информатика, кибернетика и программирование

По степени использования типовых проектных решений различают следующие методы проектирования: оригинального индивидуального проектирования когда проектные решения разрабатываются с нуля в соответствии с требованиями к ЭИС; типового проектирования предполагающего конфигурацию ЭИС из готовых типовых проектных решений программных модулей. Итеративному подходу присуща внутренняя гибкость позволяющая включать в бизнесцели новые требования или тактические изменения. Хотя ни один отдельно взятый процесс не способен удовлетворить...

Русский

2013-10-23

152.5 KB

65 чел.

Лекция ПИС

Промышленные технологии проектирования ИС

7/12/01

  1.  Технология RUP (Rational Unified Process). Этапы создания RUP.  Принципы технологии RUP. Инструментальная поддержка процессов RUP. Вспомогательные средства поддержки жизненного цикла программного обеспечения.
  2.  Технология DATARUN.
  3.  Метод Oracle.

1. Понятие технологии проектирования

Технология проектирования ЭИС - это совокупность методологии и средств проектирования ЭИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ЭИС) - рис. 1.

Рис. 1. Технология проектирования

Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего стало бы ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.

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

Методы проектирования ЭИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

Так, по степени автоматизации методы проектирования разделяются на методы:

• ручного проектирования, при котором проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;

• компьютерного проектирования, которое производит генерацию или конфигурацию (настройку) проектных решений на основе использования специальных инструментальных программных средств.

По степени использования типовых проектных решений различают следующие методы проектирования:

• оригинального (индивидуального) проектирования, когда  проектные решения разрабатываются «с нуля» в соответствии с требованиями к ЭИС;

• типового проектирования, предполагающего конфигурацию ЭИС из готовых типовых проектных решений (программных модулей).

Оригинальное (индивидуальное) проектирование ЭИС характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности.

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

По степени адаптивности проектных решений методы проектирования классифицируются на методы:

реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

параметризации, когда проектные решения настраиваются (перегенерируются) в соответствии с изменяемыми параметрами;

реструктуризации модели, когда изменяется модель проблемной области, на основе которой автоматически перегенерируются проектные решения.

Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования ЭИС, среди которых выделяются два основных класса: каноническая и индустриальная технологии (табл. 1). Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий проектирования не исключает использования в отдельных случаях канонической технологии.

Табл. 1 Характеристики классов технологий проектирования

Класс технологии проектирования

Степень автоматизации

Степень типизации

Степень адаптивности

Каноническое проектирование

Ручное проектирование

Оригинальное проектирование

Реконструкция

Индустриальное автоматизированное проектирование

Компьютерное проектирование

Оригинальное проектирование

Реструктуризация модели (генерация ЭИС)

Индустриальное типовое проектирование

Компьютерное проектирование

Типовое сборочное проектирование

Параметризация и реструктуризация модели (конфигурация ЭИС)

Тельнов стр.27- 46

2. Промышленные технологи проектирования

Под промышленной технологией проектирования понимаются электронные технологии, которые обеспечивают поддержку процессов ЖЦ ПО на всех стадиях, которые, как правило, соответствуют  стандарту ISO/I ЕС 12207.

Одной из наиболее распространенных в мире электронных технологий является технология DATARUN. Для создания моделей в рамках этой промышленной технологии используется известное CASE-средство Silverrun.

Другая технология известна как метод Oracle. В состав данного комплекса входит набор средств, разработанных фирмой Oracle. Эти средства поддерживают процесс разработки ИС на всех стадиях жизненного цикла.

Одной из наиболее распространенных и популярных является технология фирмы Rational Software известная,  как RUP – рациональный унифицированный процесс.

3. Рациональный Унифицированный Процесс

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

UML практически не зависит от процесса, то есть его можно использовать в различно организованных процессах изготовления программного продукта.

Но один способ организации, называемый Рациональным Унифицированным Процессом (Rational Unified Process), особенно хорошо приспособлен к UML. Цель Рационального Унифицированного Процесса — обеспечить изготовление программного продукта высочайшего качества, соответствующего потребностям пользователя, в заданные сроки и в пределах заранее составленной сметы.

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

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

Рациональный Унифицированный Процесс итеративен. Если речь идет о простых системах, не представляет особого труда последовательно определить задачу, спроектировать ее целостное решение, написать программу и протестировать конечный продукт. Но, учитывая сложность и разветвленность современных систем, такой линейный подход к разработке оказывается нереалистичным.

Итеративный подход предполагает постепенное проникновение в суть проблемы путем последовательных уточнений и построение все более ёмкого решения на протяжении нескольких циклов. Итеративному подходу присуща внутренняя гибкость, позволяющая включать в бизнес-цели новые требования или тактические изменения. Его использование оставляет возможность выявить и устранить риски, связанные с проектом, на возможно более ранних этапах разработки.

Суть работы в рамках Рационального Унифицированного Процесса - это создание и сопровождение моделей, а не бумажных документов. Модели, особенно выраженные на языке UML, дают семантически насыщенное представление разрабатываемого программного комплекса. На них можно смотреть с разных точек зрения, а представленную в них информацию допустимо мгновенно извлечь и проконтролировать электронным способом.

Рациональный Унифицированный Процесс обращен прежде всего на модели, а не на бумажные документы; причина состоит в том, чтобы свести к минимуму накладные расходы, связанные с созданием и сопровождением документов, и повысить степень информационного наполнения проектирования.

В центре разработки в рамках Рационального Унифицированного Процесса лежит архитектура. Основное внимание уделяется раннему определению архитектуры программного комплекса и формулированию основных ее особенностей.

Наличие прочной архитектуры позволяет «распараллелить» разработку, сводит к минимуму переделки, увеличивает вероятность того, что компоненты можно будет использовать повторно, и в конечном счете делает систему более удобной для последующего сопровождения. Подобный архитектурный чертеж - это фундамент, на базе которого можно планировать процесс разработки компонентного программного обеспечения и управлять им.

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

Рациональный Унифицированный Процесс поддерживает объектно-ориентированные методики. Каждая модель объектно-ориентирована. Модели, применяемые в рамках Рационального Унифицированного Процесса, основаны на понятиях объектов и классов и отношений между ними, а в качестве общей нотации используют нотацию UML.

Рациональный Унифицированный Процесс поддается конфигурированию.

Хотя ни один отдельно взятый процесс не способен удовлетворить требованиям всех организаций, занимающихся разработкой программного обеспечения, Рациональный Унифицированный Процесс поддается настройке и масштабируется для использования как в совсем небольших коллективах, так и в гигантских компаниях. 

Он базируется на простой и ясной архитектуре, которая обеспечивает концептуальное единство во множестве всех процессов разработки, но при этом адаптируется к различным ситуациям. Составной частью Рационального Унифицированного Процесса являются рекомендации по его конфигурированию для нужд конкретной организации.

Рациональный Унифицированный Процесс поощряет объективный контроль качества и управление рисками на всех стадиях воплощения проекта.

Контроль качества является неотъемлемой частью процесса, охватывает все виды работ и всех участников. При этом применяются объективные критерии и методы оценки. Контроль качества не рассматривается как особый род деятельности, которой можно заняться по завершении разработки. Управление рисками также встроено в процесс, так что возможные препятствия на пути успешного завершения проекта выявляются и устраняются на ранних этапах разработки, когда для реагирования еще остается время.

Рабочие процессы

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

  •  моделирование бизнес-процессов - описывается структура и динамика организации;
  •  разработка требований — описывается основанный на прецедентах метод постановки требований;                                            
  •  анализ и проектирование - описываются различные виды архитектуры системы;
  •  реализация - собственно разработка программ, автономное тестирование и интеграция;                                                     
  •  тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок;
  •  развертывание - охватывает конфигурирование поставляемой системы;
  •  управление конфигурацией - управление изменениями и поддержание целостности артефактов проекта;
  •  управление проектом - описывает разные стратегии работы с итеративным процессом;
  •  анализ среды - рассматриваются вопросы инфраструктуры, необходимой для разработки системы.

Внутри каждого рабочего процесса сосредоточены связанные между собой артефакты и деятельности. Артефакт (Artifact) - это некоторый документ, отчет или исполняемая программа, которые производятся, а впоследствии преобразуются или потребляются.

Термином деятельность (Activity) описываются задачи - обдумывание, выполнение, анализ проекта - которые решаются сотрудниками с целью создания или модификации артефактов, а также способы и рекомендации по решению этих задач. В число таких способов могут входить и инструментальные средства, позволяющие автоматизировать решение части задач.

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

Артефакты

С каждой деятельностью в Рациональном Унифицированном Процессе связаны артефакты, которые либо подаются на вход, либо получаются на выходе. Артефакты используются как исходные данные для последующей деятельности, содержат справочные сведения о проекте или выступают в роли поставляемых по контракту составляющих.

Модели

Модели - это самый важный вид артефактов в Рациональном Унифицированном Процессе. Модель - это упрощение реальности (см. главу 1); она создается для лучшего понимания разрабатываемой системы. В Рациональном Унифицированном Процессе имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы:

  •  модель бизнес-процессов - формализует абстракцию организации;
  •  модель предметной области - формализует контекст системы;
  •  модель прецедентов - формализует функциональные требования к системе;
  •  аналитическая модель (необязательная) - формализует идею проекта;
  •  проектная модель - формализует словарь предметной области и области решения;
  •  модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;
  •  модель развертывания - формализует топологию аппаратных средств, на которых выполняется система;
  •  модель реализации - описывает части, из которых собирается физическая система;
  •  модель тестирования - формализует способы проверки и приемки системы.

Вид - это одна из проекций модели. В Рациональном Унифицированном Процессе существует пять тесно связанных друг с другом видов системной архитектуры: с точки зрения проектирования, процессов, развертывания, реализации и прецедентов.

Другие артефакты

Артефакты в Рациональном Унифицированном Процессе подразделяются на две группы: административные и технические. Технические артефакты, в свою очередь, делятся на четыре большие подгруппы:

  •  группа требований - описывает, что система должна делать;
  •  группа проектирования - описывает, как система должна быть построена;
  •  группа реализации - описывает сборку разработанных программных компонентов;
  •  группа развертывания - содержит все данные, необходимые для конфигурирования предоставленной системы.

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

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

К группе реализации относится вся информация о программных элементах, из которых состоит система, в том числе исходный код на различных языках программирования, конфигурационные файлы, файлы данных, программные компоненты и т.д., а также информация "о том, как собирать систему.

Группа развертывания сообщает о том, как программный комплекс разбит на пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика.

4. ВСПОМОГАТЕЛЬНЫЕ СРЕДСТВА ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4.1. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К СИСТЕМЕ

Одно из первых действии при проектировании ПО — сбор и упорядочение требовании к нему. Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, отчетов существующей системы и массы других материалов.

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

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

Таким образом, без организованных усилий по регистрации и контролю выполнения этих требований велик риск их потерять. Решение проблемы достаточно очевидно: в специально созданном хранилище документов следует вести учет собираемых требований и контролировать их обработку, оценку и реализацию (или отказ от реализации).

Итак, требование это условие или характеристика, которым должна удовлетворять система. Существуют функциональные и нефункциональные требования.

Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Тем самым функциональные требования определяют поведение системы в процессе обработки информации.

Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения. Можно выделить следующие типы нефункциональных требований и их краткую характеристику:

• требования к применению — определяют качество пользовательского интерфейса, документации и учебных курсов;

• требования к производительности — накладывают ограничения на функциональные требования, задавая необходимую эффективность использования ресурсов, пропускную способность и время реакции;

• требования к реализации - предписывают использовать определенные стандарты, языки программирования, операционную среду и др.;

• требования к надежности — обусловливают допустимую частоту и воздействие сбоев, а также возможности восстановления;

• требования к интерфейсу — определяют внешние сущности, с которыми может взаимодействовать система, и регламент этого взаимодействия.

Управление требованиями (requirements management) представляет собой:

• систематический подход к выявлению, организации и документированию требований к системе;

• процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменения требований к системе и обеспечивающий его выполнение.

Управление требованиями преследует определенные цели:

• достичь соглашения с заказчиком и пользователями о том, что система должна делать;

• улучшить понимание требований к системе со стороны разработчиков;

• очертить границы системы;

• определить базис для планирования.

Важность управления требованиями объясняется еще одним обстоятельством: почти во всех проектах, выполняющихся в экстремальных условиях, приходится устанавливать приоритеты, разделяя все требования к системе на три категории: "необходимо выполнить", "следует выполнить" и "можно выполнить". При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем: в первую очередь сконцентрироваться на требованиях, которые необходимо выполнить; затем, если останется время, сосредоточиться на требованиях, которые следует выполнить; и, наконец, если произойдет чудо, заняться требованиями, которые можно выполнить. Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в крайне неприятной кризисной ситуации.

Управление требованиями относится к работам, техническая поддержка которых не требует больших финансовых затрат, но они способны ощутимо повысить качество создаваемой системы.

Наиболее распространенные структурные и объектно-ориентированные методы создания ПО направлены на моделирование требований с помощью различного рода диаграмм. Но в данном случае речь идет именно об управлении требованиями. Эти два понятия - моделирование и управление не являются противоречивыми или несовместимыми.

В реальных проектах пользовательские требования зачастую должным образом не документируются. В свое оправдание разработчики говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе. Это порождает главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования "необходимо выполнить", какие "следует выполнить" и какие "можно выполнить"? Структурные и объектно-ориентированные методы не дают ответа на этот вопрос, поскольку они служат в первую очередь для понимания и объяснения требований, а не для управления ими в динамике (можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого).

Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности, поскольку как сами требования, так и их приоритеты изменяются в течение проекта. Большинство крупных проектов включает сотни требований, а многие — даже тысячи (например, проект самолета Боинг-777, который называли мешком программ с крыльями, включал, по некоторым данным, около 300 тыс. требований). Кроме того, некоторые требования зависят от других требований, а некоторые, в свою очередь, порождают другие требования.

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

В настоящее время появились специализированные системы управления требованиями (Requirements Management Systems), обеспечивающие комплексную и сложную поддержку управления требо ваниями. Некоторыми из доступных на сегодняшний день средств о которых упоминалось в главе 4, являются RequisitePro (Rational Software) и DOORS (Quality Systems and Software Inc.).

Средства управления требованиями обладают различными возможностями в зависимости от подхода разработчика. 

Стандартными можно считать две из них:

• выделение требований непосредственно в документах различного формата с сохранением ссылки на исходный текст;

• отслеживание зависимостей между требованиями.

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

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

Еще одна важная задача, которую позволяет решить хранение данных о взаимозависимости требований, — это управление изменениями требований. Зная, какие требования строились на основе измененных, можно корректно отработать внесение изменений.

Каждое требование может быть описано любым удобным набором атрибутов. Обычно помимо источника возникновения указывается обязательность и приоритет, статус. Компоновать требования в разделы можно по любым удобным критериям.

Для внедрения технологии управления требованиями необходимы в первую очередь организационные мероприятия: разработка процедуры сбора, анализа и согласования требовании; определение категорий требований; назначение ответственных за их регистрацию и обработку.

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

По существу, для описания требований уже имеется одно знакомое всем средство. Оно называется "текстовый процессор". В самом деле, начальная версия такого документа обычно исходит от пользователей, например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента. На этой ранней стадии пользователи рассматривают текстовый процессор как свое средство, а записку службы маркетинга — как свои документ. В результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, наблюдается тенденция, ведущая к документоцентричному управлению требованиями, когда средства, используемые специалистами по информационным технологиям (например, RequisitePro или DOORS), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются.

В заключение остановимся на некоторых возможностях и характеристиках системы RequisitePro.

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

Развитые возможности прослеживания требований позволяют визуально определять схожие требования в рамках одного проекта или нескольких и применять готовые апробированные решения в новом проекте.

Возможность задания связей между требованиями позволяет проследить, какие требования следует подвергнуть анализу (и, возможно, изменению) при изменении некоторого конкретного требования или атрибута. Тем самым упрощается процесс внесения изменений.

Для каждого требования хранится его история, помогающая отследить, какие изменения были внесены в требование, кем, когда и почему

Ввод требований осуществляется с помощью Microsoft Ward, с которым интегрировано RequisitePro. Кроме того, возможен импорт существующих требований, документированных средствами Microsoft Word. Средство Import Wizard позволяет собирать требования из разных источников: текстовых файлов, электронных таблиц и баз данных. Сами требования могут храниться в текстовых документах и базах данных MS Access, MS SQL Server или Oracle.

Имеются возможности документирования требований за счет использования стандартных или создаваемых текстовых шаблонов. В частности, предусмотрены шаблоны для выпуска документации в соответствии со стандартами IEEE, ISO, SEI СММ и RUP.

Помимо CASE-средств Rational, перечисленных в главе 4, RequisitePro интегрируется со средствами управления конфигурацией PVCS Xfersion Manager и Microsoft Source Safe, а также со средством управления проектами Microsoft Project. Интеграция RequisitePro версии 4.5 с CASE-средством Rational Rose 2000 позволяет расширять диаграммы вариантов использования нефункциональными требованиями к системе.

6.2. ОЦЕНКА ЗАТРАТ НА РАЗРАБОТКУ ПО

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

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

• оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOC - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Определение функциональной точки приведено в подразд. 1.2.2;

• оценка трудоемкости в человеко-месяцах или человеко-часах;

• оценка продолжительности проекта в календарных месяцах;

• оценка стоимости проекта.

Оценка размера проекта базируется на знании требований к системе, перечисленных в разд. 6.1. Для такой оценки существуют два основных способа:

1. По аналогии. Если в прошлом приходилось иметь дело с подобным проектом и его оценки известны, то можно, отталкиваясь от них, приблизительно оценить свой проект.

2. Путем подсчета размера по определенным алгоритмам на основании исходных данных - требований к системе.

Оценка трудоемкости проекта выводится на основании его размера. Для такой оценки также существуют два основных способа:

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

• в организации аккуратно документируются реальные результаты предыдущих проектов;

• по крайней мере один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

• жизненный цикл, используемые методы и средства разработки, квалификация и опыт проектной команды вашего нового проекта также подобны тем, которые имели место в предыдущих проектах.

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценки (например, модель СОСОМО (Constructive COst MOdel - конструктивная стоимостная модель) Барри Боэма).

Подобным же образом (как на основе исторических данных, так и с использованием формальных методов) оцениваются продолжительность и стоимость проекта.

Согласно Эдварду Иордану, все доступные средства оценки классифицируются следующим образом:

• Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)). Глава фирмы SPR Каперс Джонс, "гуру" в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип "что заложишь, то и получишь"). В лучшем случае с помощью таких продуктов можно получить оценку с точностью ± 10%. Даже если точность будет ±50%, это все равно лучше, чем брать данные "с потолка".

• Динамические модели систем — множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днем отдача увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастет количество ошибок, что, очевидно, повлияет на трудоемкость тестирования и отладки.

• Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", также переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.

• Различные руководства и отчеты организаций, подобных Software Engineering Institute (SEI), которые могут помочь при выполнении оценки проектов.

• Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход позволяет привнести немного здравого смысла в проектную команду и в окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала 1 млн строк кода за 12 мес., то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом. Остановимся более подробно на методе функциональных точек. Определение числа функциональных точек является методом количественной оценки ПО, применяемым для измерения функциональных характеристик,процессов его разработки и сопровождения независимо от технологии, использованной для его реализации.

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

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной организацией IFPUG (International Function Point User Group). Существуют специальные программные средства, автоматизирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является KnowledgePLAN — продукт фирмы SPR.

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

KnowledgePLAN имеет следующие возможности:

• формирование близкого к реальному плана работ по проекту;

• определение трудоемкости и стоимости планируемых проектов;

• учет влияния условий разработки, применяемых инструментальных средств и используемых технологий на прогнозируемую трудоемкость, сроки и стоимость разработки;

• проведение анализа "what — if ("что, если") для поиска лучших решений;

• проведение сравнительного анализа качества и производительности разработки разнотипных проектов или однотипных проектов, при выполнении которых использовались различные технологии;

• накопление статистической многомерной информации о проекте и его участниках;

• классификация проектов для принятия решения о структуре управления проектом;

• анализ плановой и реальной оценки сложности и величины разработанного ПО и трудоемкости выполнения проекта.

6.3.СРЕДСТВА УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ПО

Управление конфигурацией ПО является одним из наиболее важных вспомогательных процессов жизненного цикла ПО (см. главу 1). Цель управления конфигурацией - обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонентов в каждый момент времени, а также обо всех предполагаемых и выполненных изменениях. Предполагаемые изменения разделяются на следующие группы:

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

• изменения, которые целесообразно внести в очередную версию с учетом затрат на их реализацию и улучшения эффективности ПО;

• изменения, которые требуют дополнительного анализа целесообразности и эффективности их реализации в последующих версиях и могут не внедряться в очередную версию ПО;

• изменения, которые не оправдывают затрат на разработку и выполнение корректировок или практически не влияют на качество и эффективность ПО и поэтому не подлежат реализации. Все проанализированные изменения регистрируются. Для принятых к внедрению изменений разрабатывается план доработок программ и определяется ответственный за каждую корректировку программы.

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

Аналитические исследования International Data Corporation (IDC) свидетельствуют о быстром росте мирового рынка средств управления конфигурацией (SCM — Software Configuration Management). Если в 1995 г. мировой объем продаж средств SCM составил 239 млн дол., то в 1996 г. - 350, в 1997 г. - 477, в 1998 г. - 595 млн дол. Оценка продаж SCM в 1999 г. составляет 750 млн дол. Лидером по объему продаж является корпорация Rational Software со своим продуктом управления конфигурацией ClearCase.

Rational ClearCase — средство, предназначенное для управления

•конфигурацией ПО сложных информационных систем. ClearCase позволяет хранить в репозитории полные хронологии версий каждого объекта, созданного или измененного в процессе разработки системы. К ним относятся: исходный программный код, библиотеки, исполняемые программы, документация, web-страницы и каталоги.

Rational ClearCase работает с такими инструментальными средствами разработки приложений, как Visual Basic, Visual C++, Visual Java++, PowerBuilder и Oracle Developer.

Семейство продуктов ClearCase включает в себя следующие продукты:

• собственно ClearCase — средство управления версиями и конфигурацией создаваемой системы;

• ClearCase MultiSite — средство поддержки географически удаленных фупп разработчиков;

• ClearQuest — средство контроля изменений в модулях и подсистемах проекта.

Другим распространенным средством управления конфигурацией является средство PVCS фирмы Merant, включающее интегрированный набор продуктов PVCS Professional (PVCS Version Manager, PVCS Tracker и PVCS Configuration Builder) и PVCS Notify

PVCS Version Manager предназначен для управления всеми компонентами проекта и ведения планомерной многоверсионной и многоплатформенной разработки силами команды разработчиков в условиях одной (или нескольких) локальной сети. Понятие "проект" трактуется как совокупность файлов. В процессе работы над проектом промежуточное состояние файлов периодически сохраняется в архиве проекта, ведутся записи о времени сохранения, соответствии друг другу нескольких вариантов разных файлов проекта. Кроме того, фиксируются имена разработчиков, ответственных за тот или иной файл, состав файлов промежуточных версий проекта и др. Это позволяет вернуться при необходимости к какому-либо из предыдущих состояний файла (например, при обнаружении ошибки, которую в данный момент трудно исправить).

Средство PVCS Version Manager может использоваться в рабочих группах. Система блокировок, реализованная в этом средстве, позволяет предотвратить одновременное внесение изменений в один и тот же файл. В то же время PVCS Version Manager дает возможность разработчикам работать с собственными версиями общего файла с полуавтоматическим разрешением конфликтов между ними.

Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств. Сюда входят PowerBuilder, Delphi, JBuilder, ERwin, Visual C++, Visual Basic, Oracle Developer и др.

Результатом работы PVCS Version Manager является созданный средствами файловой системы ОС репозиторий, хранящий в компактной форме все рабочие версии программного продукта вместе с необходимыми комментариями и метками.

PVCS Version Manager функционирует в среде Windows 95/98/NT, Solaris, HP-UX, AIX и SCO UNIX.

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

Коллектив, работающий с PVCS Tracker, делится на пять групп в зависимости от их обязанностей: пользователи, разработчики, группа тестирования и контроля качества, группа технической поддержки и сопровождения, управленческий персонал. Этим пяти группам соответствуют пять предопределенных групп PVCS Tracker:

• пользователи (Submitters) — имеют ограниченные права на внесение замечаний и сообщений об ошибках в базу данных PVCS Tracker;

• разработчики (Development Engineers) — имеют право производить основные операции с требованиями и замечаниями в базе данных PVCS Tracker. Если разработчики делятся на подгруппы, то для каждой подгруппы могут быть заданы отдельные списки прав доступа;

• тестировщики (Quality Engineers) - имеют право производить основные операции с требованиями и замечаниями;

• специалисты службы сопровождения (Support Engineers) — имеют право вносить любые замечания, требования и рекомендации в базу данных, но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения;

• руководители (Managers) — имеют право распределять работы между исполнителями и принимать решение об их надлежащем исполнении. Руководителям разных групп могут быть заданы различные права доступа к базе данных PVCS Tracker. В дополнение к этим пяти предопределенным группам существует группа администратора базы данных и 11 дополнительных групп, которые могут быть настроены в соответствии со специфическими должностными обязанностями сотрудников, использующих PVCS Tracker.

Требование или замечание, поступающее в PVCS Tracker, проходит четыре этапа обработки:

• регистрация — внесение замечания в базу данных;

• распределение - назначение ответственного исполнителя и сроков исполнения;

• исполнение — устранение замечания, которое, в свою очередь, может вызвать дополнительные замечания или требования на дополнительные работы;

• приемка - приемка работ и снятие их с контроля или направление на доработку.

Требования и замечания, поступающие в базу данных PVCS Tracker, оформляются в виде специальной формы, которая може+ содержать до 18 полей выбора стандартных значений и до 12 произвольных текстовых строк. При разработке формы следует определить оптимальный набор информации, характерный для всех записей в базе данных.

Для получения содержательной информации о ходе разработки PVCS Tracker позволяет получать три типа статистических отчетов:

частотные, тренды и диаграммы распределения.

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

Тренды содержат информацию об изменениях того или иного показателя во времени и характеризуют стабильность и непрерывность процесса разработки. Они позволяют ответить на вопросы:

• успевает ли группа разработчиков справляться с поступающими замечаниями;

• улучшается ли качество программного продукта и какова динамика этого процесса;

• как повлияло то или иное решение (увеличение числа разработчиков, введение скользящего графика, внедрение нового метода

тестирования) на работу группы и т.п.

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

PVCS Tracker предназначен для использования в рабочих группах, Объединенных в общую сеть. В этом случае центральная база или проект VyCS Tracker находится на общедоступном сервере сети, доступ к которому реализуется посредством ODBC-драйверов, входящих в состав PVCS Tracker. Главной особенностью PVCS Tracker по сравнению с обычным приложением СУБД является способность автоматически уведомлять пользователя о поступлении интересующей его или относящейся к его компетенции информации и гибкая система распределения полномочий внутри рабочей группы. При необходимости PVCS Tracker может использовать для уведомления удаленных членов группы электронную почту.

PVCS Tracker поддерживает групповую работу в локальных сетях и взаимодействует с СУБД Oracle, MS SQL Server и Sybase посредством ODBC.

PVCS Configuration Builder предназначен для сборки окончательного продукта из компонентов проекта. Он позволяет описывать процесс сборки как на стандартном языке MAKE, так и на собственном внутреннем языке, имеющем существенно большие возможности. PVCS Configuration Builder выполняет сборку программного продукта на основании файлов, хранящихся в репозитории PVCS \fersion Manager.

Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов:

• строится файл зависимостей между исходными модулями;

• в полученный файл вносятся изменения в целях его настройки и оптимизации;

• выполняется сборка программного продукта из исходных модулей.

Результатом работы PVCS Configuration Builder является специальный файл, описывающий оптимальный алгоритм сборки программного продукта, построенный на основе анализа дерева зависимостей между исходными модулями.

6.4. СРЕДСТВА ДОКУМЕНТИРОВАНИЯ

Для создания документов в процессе разработки ПО используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASB-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation - автоматизированное документирование ПО).

Система SoDA предназначена для автоматизации разработка проектной документации на всех стадиях ЖЦ ПО. Она позволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и включать ее в выходные документы. При этом контролируются соответствие документации проекту, взаимосвязь документов, обеспечивается их своевременное обновление. Результирующая документация автоматически формируется из множества источников, число которых не ограничено.

SoDA не зависит от применяемых инструментальных средств. Связь с приложениями осуществляется через стандартный программный интерфейс API. Переход на новые инструментальные средства не влечет за собой дополнительных затрат по документированию проекта.

SoDA содержит набор стандартных шаблонов документов, на основе которых можно без специального программирования создавать новые формы документов, определяемые пользователями.

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

SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по редактированию и верстке выпускаемой документации. Разные версии документации могут быть для наглядности отмечены своими отличительными признаками. В системе создаются таблицы требований к проекту, по которым можно проследить, как реализуются эти требования. Разные виды документации, сопровождающие различные этапы ЖЦ, связаны между собой, и можно проследить состояние проекта от первоначальных требований до анализа, проектирования, кодирования и тестирования программного продукта.

Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (FrameBuilder), который получается в результате генерации документа. Вывод на печать этого документа (или его части) возможен из системы SoDA.

Среда функционирования SoDA — ОС UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000.

6.5. СРЕДСТВА ТЕСТИРОВАНИЯ

Под тестированием понимается процесс исполнения программы в целях обнаружения ошибки. Наиболее удачными считаются тесты, которые обнаруживают еще не выявленные ошибки. Регрессионное тестирование — это тестирование, проводимое после усовершенствования функций программы или внесения в нее изменений.

Одно из наиболее развитых средств автоматизированного тестирования приложений архитектуры "клиент-сервер" Rational TeamTest обеспечивает следующие возможности:

• полное функциональное тестирование приложений, включающее запись тестов и их воспроизведение, отслеживание ошибок и контроль за изменениями;

• создание многократно используемых тестовых скриптов для тестирования свойств всех объектов приложений;

• поддержка различных средств разработки приложений и языков программирования, в том числе Microsoft Visual Basic и Visual C++, Java, Oracle Developer, PowerBuilder;

• поддержка командной работы над проектом за счет контролируемого доступа ко всем аспектам тестов, отслеживания ошибок, внесения изменений через Интернет, оповещения по электронной почте.

Основой Rational TeamTest является средство функционального тестирования Rational Robot. Скрипты, создаваемые в Rational Robot, обеспечивают поиск ошибок в приложении, оставаясь виртуально независимыми от внесенных изменений и среды функционирования приложения. Без дополнительных изменений скрипты могут использоваться в среде Windows 95, Windows 98 и Windows

NT. Объектное тестирование обеспечивает быстрое создание скриптов, которые в дальнейшем можно легко изменить, создав заново и воспроизвести.                                  |

Rational TeamTest поддерживает весь процесс тестирования, начиная с формулирования требований и необходимых условий. Средство Rational TestManager может быть использовано для планирования тестов напрямую или путем экспорта требований из Rational RequisitePro. При этом различные части плана могут быть немедленно назначены к реализации конкретным разработчикам, и как только закончены все тесты конкретного аспекта приложения, статус этого аспекта и соответствующего требования автоматически обновляется. Такое тесное взаимодействие между управлением и выполнением тестов позволяет менеджеру проекта получить точное и ясное представление о текущем состоянии разработки и тестирования. В любой момент менеджер может видеть, какие требования к системе уже реализованы и протестированы и каковы результаты этих тестов. Поскольку часто требования меняются по мере развития проекта, TestManager активно управляет тестами по мере добавления новых требований.

TeamTest также включает в себя средство Rational ClearQuest/TT Edition для управления запросами на изменения, позволяя команде разработчиков регистрировать ошибки по мере их возникновения, устанавливать статус исправления, внедрять изменения в приложение и отсылать сообщение об успешном внедрении изменений обратно команде разработчиков и менеджеров. ClearQuest/TT Edition полностью совместимо с ClearQuest.

Все аспекты тестов, созданных и использующихся в TeamTest, хранятся в централизованном репозитории. TestManager предоставляет прямой доступ к этому репозиторию, а также позволяет создавать краткие сводки о текущем состоянии процесса тестирования. Поскольку TeamTest взаимодействует с электронной почтой, сообщения об ошибках, исправлениях и распределении задач могут быть автоматически разосланы членам команды.

Другое средство - PerformanceStudio предназначено для нагрузочного тестирования приложений архитектуры "клиент-сервер" (тестирования производительности, тестирования при подключении большого числа пользователей, стрессового тестирования и тестирования на больших объемах данных). PerformanceStudio тестирует работу системы, в точности имитируя работу реальных Пользователей, оценивает и предсказывает поведение клиент-сер-церных систем в реальных условиях.

Дополнительную информацию по данным средствам можно получить на сайте Rational Software Corporation.


 

А также другие работы, которые могут Вас заинтересовать

66412. АНТИКООПЕРАТИВНІСТЬ ПРИ КОМПЛЕКСОУТВОРЕННІ АРОМАТИЧНИХ СПОЛУК І ДНК У ВОДНОМУ РОЗЧИНІ 473 KB
  Енгельгардта РАН старший науковий співробітник відділу ДНКбілкових взаємодій м. Низькомолекулярні біологічно активні сполуки БАС що виявляють свою медикобіологічну дію шляхом зв’язування з ДНК є однією з найбільш перспективних груп лікарських препаратів які застосовуються...
66413. СУФІЗМ ТА ІСЛАМІЗМ: ГЛОБАЛЬНИЙ ТА ЛОКАЛЬНИЙ КОНТЕКСТ 175 KB
  Вивчення суфізму що репрезентує традиційні ісламські цінності й водночас є впливовою течією ісламу та ісламізму який є яскравим політичним феноменом сучасності дозволить спрогнозувати тенденції розвитку української умми та попередити або мінімізувати можливі проблеми...
66414. Формування технологічних маршрутів у аерокосмічному виробництві на основі інформаційного аналізу функціональних взаємозв’язків у виробничій системі 6.02 MB
  Серед першочергових заходів технологічного характеру відзначимо необхідність удосконалення процесів технологічної підготовки виробництва ТПВ як основного етапу що забезпечує успішний випуск нової продукції. Незважаючи на широке розроблення методів ТПВ у тому числі й автоматизованих до цього часу...
66415. ПІДГОТОВКА МАЙБУТНІХ ВИХОВАТЕЛІВ ДОШКІЛЬНИХ НАВЧАЛЬНИХ ЗАКЛАДІВ ДО ПРОФЕСІЙНОЇ ДІЯЛЬНОСТІ В ПОЛІКУЛЬТУРНОМУ СЕРЕДОВИЩІ КРИМУ 168.5 KB
  Проте питання підготовки майбутніх вихователів дітей дошкільного віку до професійної діяльності в полікультурному просторі і зокрема у полікультурному середовищі Криму не знайшли свого висвітлення в науковопедагогічних дослідженнях.
66416. СУДОВЕ ПРАВОЗАСТОСУВАННЯ В УКРАЇНІ: ПРОБЛЕМИ ТЕОРІЇ І ПРАКТИКИ 136.5 KB
  На сучасному етапі дослідження питань правозастосування та правозастосовчого процесу знаходять розвиток у працях таких вітчизняних дослідників як О. Проблематика судового правозастосування в вітчизняній юридичній літературі на превеликий жаль майже не досліджена.
66417. МАЛІ КОЛИВАННЯ ЗЧЛЕНОВАНИХ ГІРОСТАТІВ 407 KB
  У цьому випадку дуже характерні і задачі про малі коливання зчленованих гіростатів. Розроблено підхід який оснований на використанні теорії операторних матриць що діють у гільбертовому просторі і який дозволяє перейти від вихідної початково крайової задачі для гідромеханічної системи...
66418. Удосконалення методів передачі розміру одиниці електричного опору нерівнономінальним мірам 1.65 MB
  Питання удосконалення методів передачі розміру одиниці електричного опору нерівнономінальним мірам виникло у зв'язку зі збільшенням обсягів прецизійних вимірювань у яких здійснюється порівняння нерівнономінальних некратнодесятинних мір.
66419. Виховання патріотизму в учнів середніх шкіл США 169 KB
  Тому ставлення до виховання патріотизму в молодого покоління у сучасній українській школі повинно докорінно змінитися. Вдосконаленню і збагаченню вітчизняних традицій патріотичного виховання в школі може слугувати аналогічний зарубіжний досвід зокрема Сполучених Штатів Америки країни де цьому питанню завжди приділялася належна увага.
66420. РОЗВИТОК ПІДПРИЄМСТВ ОРГАНІЧНОГО СЕКТОРУ АГРОБІЗНЕСУ В КОНТЕКСТІ ВИКЛИКІВ ГЛОБАЛІЗАЦІЇ ТА ЄВРОІНТЕГРАЦІЇ 211.5 KB
  В контексті викликів глобалізації та євроінтеграції не повинна стати винятком і Україна тим більше що є всі передумови для ефективного функціонування підприємств органічного сектору. Теоретичні основи й узагальнення практичного досвіду розвитку...