НИР CASE средства проектирования СУ предприятиями. Отчет по НИР — копия. Исследование по теме case средства проектирования систем управления предприятиями 21 1 Общий анализ рынка caseсредств 21
 Скачать 0.64 Mb.
|
|
Класс 4 объединяет CASE-средства ARIS и Casewise. Они обладают наиболее полным функционалом для моделирования, однако уступают другим системам по характеристикам эффективности (из-за высокой цены) и сопровождаемости (из-за сложности). Эти пакеты могут быть рекомендованы для больших и сложных проектов. Класс 3 объединяет BPWin и Vantage team builder. Причем, BPWin проигрывает Vantage team builder по функциональным возможностям, однако опережает его по трем остальным характеристикам качества, и, в результате, получил более высокую интегральную оценку. Кроме того, BPWin получил лучшую оценку по характеристике сопровождаемость и может быть рекомендован для проектов среднего размера. Средство Vantage team builder подойдет для проектов, разрабатываемых на UNIX-платформах. Класс 2 составили пакеты Business Studio, Rational Rose и ERWin. CASE-средство Business Studio имеет достаточно слабый функционал, однако хорошие значения всех остальных характеристик. Он может быть рекомендован для описания и реинжиниринга бизнес-процессов на средних и малых предприятиях. Пакет Rational Rose получил средние оценки по всем характеристикам, этот пакет можно рекомендовать для проектов, целиком разрабатываемых по объектноориентированной методологии. Пакет ERWin имеет самый слабый функционал (поддерживает только ERD-модели), однако получил, средние и высокие значения по остальным характеристикам качества. Его целесообразно использовать при проектировании структур БД в проектах среднего и малого размера, в том числе совместно с BPWin. Класс 1 объединяет CASE-средства одной фирмы Oracle Data Modeler и Designer/2000. Оба пакета получили достаточно низкие оценки по функциональности и практичности. У Designer/2000 худшее значение по характеристике сопровождаемость из-за сложности при разработке отчетов. Однако, у Oracle Data Modeler — лучшее, а у Designer/2000 — хорошее значение по характеристике эффективность, что обсуловлено низкими ценами на продукты. Оба пакета логично использовать при разработке проектов, реализуемых на СУБД ORACLE.  Рисунок 3.8. Результаты классификации CASE – средств, данные научной статьи «Компьютерные и информационные науки» 3.2 Применимость CASE-средствУтверждается, что сфера применения современных CASE-средств - «большие и сложные системы». В самом деле, сложность и стоимость CASE-средств оправдывается только в больших проектах. Следовательно, не стоит даже пытаться применять их в разработке «средних» программ. С этим утверждением можно полностью согласиться, но применительно только (!) к существующим на сегодняшний день на рынке средствам. По собственному опыту знаю: почти в каждой разработке попадается какая-нибудь «закавыка», справиться с которой «в рукопашную» (то есть, без моделирования) в принципе возможно, но только при крайнем напряжении интеллекта. Да и при разработке обычных объектов чрезвычайно полезны схемы, диаграммы, алгоритмы, и т.д., которые в основном рисуются на бумаге от руки. По сути, это - те же модели, только выполненные вручную. Поэтому, возможно, более справедливым будет утверждение, что современные CASE-системы не удовлетворяют некоторым критериям качества, существенным для сферы «средних» программных средств, в силу чего их применение здесь невозможно. Но что же тогда остается разработчикам «средних» программных средств? Ручка и бумага? Как ни прискорбно будет заметить, но огромнейший класс специалистов оказался, что называется, «за бортом» автоматизации. Это явление представляется ненормальным, что собственно, и стало основным мотивом проделанной работы. Возможны ли CASE-средства массового применения? Считаю, возможны на сто процентов. Более того, меня удивляет их отсутствие. В разделе реализации это мнение получит подтверждение, а сейчас в связи с этим рассмотрим следующий вопрос: почему в свое время языки высокого уровня получили широкое распространение, и, в конце концов, вытеснили низкоуровневые языки типа ассемблеров? Очевидно, потому, что имели ощутимые преимущества: Были основаны на сравнительно простых элементах: достаточно было изучить небольшой набор довольно простых конструкций (операторные скобки, функции, присваивание, ветвление, и т.д.), чтобы начать уверенно программировать. Более качественно отображали алгоритмы, структуру программы, и т.п. Обеспечивали существенно более высокий уровень автоматизации программирования, т.е. множество ранее ручных операций выполнялось теперь компилятором. Со временем перекрыли функциональные возможности языков предыдущего поколения, то есть практически не оставили для них сферы применения. В ассемблерных языках за кажущейся простотой команд (всего-то несколько символов!) кроется неоднородная структура из кода операции (которых в ассемблере как минимум несколько десятков), набора операндов, специфичных для каждой команды, идентификация которых к тому же осложнена разнообразием методов адресации. Это является, пожалуй, наиболее существенной причиной сложности программирования на ассемблере. По сравнению с языками ассемблера, элементы языков высокого уровня были намного проще в понимании и применении. Обеспечение первых двух качеств дает право на существование и практически неограниченное распространение. Два следующих качества обеспечили вытеснение компиляторов предыдущего поколения. Однако обеспечение первого качества - простоты - стало решающим в распространении не только языков и компиляторов высокого уровня, но и самого программирования на более широкий круг специалистов, превращении его из колдовства, дела избранных, в инженерную науку. Этот фактор - фактор простоты - является фундаментальным условием успеха и в других областях массового применения: чтобы получить массовое распространение, инструментальные средства должны быть простыми для пользователя. Применительно к программированию это означает - должны базироваться на простых элементах. Зависимость распространенности инструмента от его простоты характерна не только для программирования: пожалуй, во всех областях деятельности человека количество специалистов, владеющих инструментом, всегда примерно обратно пропорционально его сложности. Значимость фактора простоты в программировании особенно критична в силу итеративности процесса разработки программного обеспечения, то есть необходимости неоднократных повторений, возвратов к предыдущим этапам, присущей в равной степени и большим, и малым проектам. На сегодняшний день необходимость итераций никем не отрицается, более того, настоятельно рекомендуется именно такая схема процесса разработки. Но это означает, что необходимо многократное повторное осмысление ранее разработанных конструкций. Вследствие чего, усложнение элементов представления вызывает экспоненциальный прирост трудоемкости. ЗаключениеТенденции развития информационных технологий сегодня диктуют новый уровень сложности востребованных информационных систем. Крупные проекты ИС сегодня характеризуются аспектами, требующими комплицитных методов моделирования. Такого рода разработка программных систем не возможна в полной мере своей эффективности без использования CASE средств. Современные CASE-инструменты охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Выбор эффективных и адекватных автоматизируемому объекту методов и CASE-средств, применяемых при анализе, проектировании, разработке или внедрении систем управления предприятиями, представляет собой сложную и ответственную задачу. Предложенная классификация методологий и методов проектирования поможет ориентироваться во множестве методов при решении задач выбора оптимального набора моделей, необходимых для анализа и проектирования систем управления конкретной предметной области. Приведенная в работе методика комплексной оценки качества программных средств будет полезна предприятиям и организациям, занимающимся разработкой, внедрением и реинжинирингом систем управления разных классов. Прикладные результаты решения задачи обоснования выбора CASE-средств: структура и масштаб метрики качества, а также результаты проведенного анализа, будут полезны фирмам, занимающимся проектированием и внедрением систем управления предприятиями при выборе CASE-средств для конкретного проекта.ПРИЛОЖЕНИЕ 1Антиплагиат |