Диссертация (1136162), страница 10
Текст из файла (страница 10)
Наиболее часто управляющиеспецификации формализуются с помощью диаграмм переходов состояний (StateTransition Diagram, STD), позволяющих задавать состояния объектов системы,(внешние и внутренние) условия переходов из одного состояния в другое, а такжедействия, совершаемые при таких переходах.ДляинформационногомоделированияБДиИСнаиболеераспространены CASE-средства на основе ERD (см. IDEF1X в таблице 1.5),51которые создают информационные модели БД на логическом и физическомуровнях и генерируют схемы БД с учетом специфики СУБД.CASE-средствапланированияипредварительнойоценкитрудоемкости проектирования ПО позволяют частично автоматизироватьформирование целей и задач корпоративных проектов на основе таких критериев(deliverables), как требования к ресурсам, бюджету, качеству, рискам,взаимодействию сотрудников и безопасности (наиболее эргономичны иэффективны KnowledgePlane и Microsoft Project Central).Таблица 1.4.
Классификация основных CASE-средств по видампроектирования ПОНазваниеПроизводительBPRФункцииДанные СобытияBPWinLogic Works++--CASE.АналитикЭйтэкс-+++CASE/4/0MicroTOOL-+++Database DesignerOracle--+-Design/IDEFMeta Software+++-Designer/DeveloperOracle++++EasyCASEEvergreen CASE Tools-+++ERWinLogic Works--+-I-CASE YordonCAYENNE-+++Prokit*WORKBENCHMDIS-++-S-DesignorSybase/Powersoft-+++SILVERRUNCSA-+++Visible AnalystWorkbenchVisible Systems-+++ARISIDS Sheer AG-++-RationalIBM++++Visual Studio .NETMicrosoft++++52Современные CASE-средства, как правило, объединены со средствамибыстрой реализации приложений (RAD) в «конвейерные» комплексы (OracleDesigner/Developer, Microsoft Visual Studio .NET, IBM Rational, SybaseSDesignor/PowerBuilderидр.)иподдерживаютвысокуюаппаратнуюнезависимость и программную совместимость (Java), а также компонентныеинтероперабельные интернет-ориентированные архитектуры (.NET); стандартомвизуального проектирования ИС является UML.В РФ зачастую (особенно при проектировании мелких и средних ИС)используются устаревающие CASE-средства на основе многопроходнойIDEFметодологии, а также не связанные в комплексы средства CASE и RAD.Результаты детального сравнительного анализа важнейших характеристикосновных CASE-средств приведены в таблицах 1.4-1.6.Таблица 1.5.Сравнение основных CASE-средств по поддерживаемым методологиям++++Silverrun+PRO-IV+ERwin+S-Designor/ PowerBuilder+DataBase Designer+++Rational+Object TeamVisualStudio.NET+ARIS+SmartClassCDMDesigner/DevelopereEPC+UMLBpwinIDEF5+IDEF3IDEF1+IDEF1XIDEF0Design/IDEFIDEF4Модели данныхCASE-средство++53Таблица 1.6.Классификация CASE-средств по сферам примененияТипНазначениеПримерыСредстваанализа(upper CASE)Построение и анализмоделей предметной областиDesign/IDEF, BРwin,Visual Studio.NET,Designer/2000,IBM Rational, ARISСозданиеспецификацийкомпонентов, интерфейсов,Средства анализа и архитектур, алгоритмов и Team Builder,Designer/Developer,проектированияструктур данных на основеSilverrun, PRO-IV, CASE.Аналитик,(middle CASE)наиболее распространенных ARISстандартов проектирования(IDEF и др.).ERwin, S-Designor, ORACLEDataBaseDesigner,TeamBuilder,Designer/Developer, Silverrun, PRO-IVСредствапроектирования БДМоделированиеданных,генерация схем БДСредствареализацииприкладного ПО4GL: Uniface, JAM, PowerBuilder,New Era,Модификация стандартных Developer/2000,SQLWindows, Delphi;компонент прикладного ПОКодогенерация: Vantage TeamBuilder, PRO-IV, частично SilverrunСредствареинжиниринга ИССхемы БД и ERD: Vantage TeamBuilder, PRO-IV, Silverrun,Формированиемоделей Designer/Developer, Erwin,данных и спецификаций ПОS-Designor/наосновеанализаPowerBuilderпрограммных кодов ИС иАнализ кодов: IBM Rational,схем БДObject Team(реинжиниринг на языке С++ )Средствапланирования иуправленияпроектамиСредстваконфигурационногоуправленияСредстватестированияSE Companion,Visual Studio.NET,IBM Rational,KnowledgePlane,ARISВыявление и оценка рисков,бизнес-планирование,PVCS, SCCS,оценка трудоемкости(трудозатраты,стоимость, IBM Rational,Visual Studio.NET,ресурсы, уровень качества)ARISQuality Works,Visual Studio.NET,Developer/2000545 Обзор технологических схем разработки ПОПрактика проектирования ПО свидетельствует, что разработка и развитиесредних и крупных промышленных ИС и БД традиционными методами неприводит к уровню качества, адекватному реальным требованиям [42].Возможны следующие классификации стандартов разработки КПК:1) по предмету стандартизации: функциональные стандарты (на языкипрограммирования, интерфейсы, протоколы) и стандарты на организацию ЖЦсоздания и использования ПО;2) поутверждающейорганизации:официальныемеждународныестандарты, официальные национальные или национальные ведомственные(например ГОСТ, ANSI, IDEF), стандарты международных консорциумов икомитетов по стандартизации (OSF, OMG, CODASYL), стандарты "де-факто"(SQL, SADT), корпорративные стандарты (Microsoft ODBC, IBM SNA);3) пометодическомуисточнику:методическиематериалыфирмразработчиков ПО, фирм-консультантов, научных центров, консорциумовпо стандартизации (Oracle (CASE*)Method, Price Waterhouse SMM, SEI CMM).Важную роль в разработке КПК играют модели на основе процессов;наиболее распространенными являются каскадная [261] и спиральная [150].В основе каскадной (waterfall) модели лежит разбиение процессаразработки ПО на фазы, в которых происходит оценка результата и продолжениепроцесса, в случае, если все составляющие задачи завершены.
Преимуществамимодели (за счет последовательной фиксации фаз) являются прозрачноераспределение обязанностей, формирование отчетной документации и контрольвыполнения графика проектирования. Хотя каскадная модель адекватна припроектированиикрупномасштабныхпрограммныхкомплексов,приневозможности четкой формализации статических требований к ПО до началапроектированияееиспользованиенецелесообразно.Каскадноймоделисоответствуют стандарты и методики ГОСТ, ISO и Oracle CDM.Спиральная (spiral) модель базируется на итеративном совершенствованиипрограммных комплексов в целом.
Преимуществами модели являются55возможность адаптации требований к проектируемому ПО и активноевзаимодействие разработчиков и пользователей ПО (в силу возможностиоперативнойоценкирезультатовразработкинавсемЖЦ).Модельцелесообразно использовать для прототипирования ПО, однако, в силусложности контроля, ее использование при разработки крупномасштабныхгетерогенных КПК требует ряда специальных инструментальных средств инавыков, а также строгойдисциплины. Спиральной модели соответствуютметодики IBM RUP и XP [145].К комплексным подходам к проектированию ПО, объединяющимкаскадную и спиральную модели, можно также отнести Microsoft SolutionFramework (MSF, www.microsoft.com/technet/itsolutions/msf/default.mspx).5.1 Международные стандартыСтандарт ISO/IEC 12207 (www.iso.org) создан в 1995 г.
комитетомISO/IEC и определяет порядок разработки ПО с полным охватом ЖЦ. В отличиеот отраслевых стандартов (Oracle CDM и др.) ISO12207 равно ориентирован наорганизацию поставщиков (разработчиков) и покупателей (пользователей),процессы ЖЦ ПО укрупнены и обобщены, а управление гарантированиемкачества ПО предусмотрено уже на ранней стадии разработки (анализ системныхтребований).Кпреимуществамстандартаследуетотнестивысокуюадаптивность, динамичность и нейтральность по отношению к моделям ЖЦ иметодам разработки ПО на основе вызова процессов по необходимости.
ISO иГОСТ34 хорошо корреспондируются в части обеспечения ЖЦ ПО. Стандарт ISOсодержит минимальную конкретизацию схемы разработки ИС и БД, чтообъясняется его глобальным характером (учитываются требования к разработкене только ПО, но и произвольных автоматизированных систем).Стандарты ГОСТ34 созданы в 80-х гг. как комплекс межотраслевыхпроектных документов для описания произвольных автоматизированных системи рассчитаны на взаимодействие заказчика и разработчика. Комплекс включаетописание этапов создания ИС (ГОСТ 34.601-90), составления техническогозадания (ТЗ) (ГОСТ 34.602-89) и требований к документированию (РД 50-34.698-5690), которые, в отличие от ISO, предусматривают стадии и этапы проектированияПО и БД (без сквозных процессов). Этапы проектирования ПО по ГОСТ34включают формирование требований, разработку концепции, ТЗ, эскизного итехнического проектов, рабочей документации, а также ввод в эксплуатацию исопровождение ПО.
Высокая адаптивность (за счет факультативности эскизногопроектирования и динамических частных ТЗ), выделение на содержательномуровне (компонент) работ (а по сути – процессов) и общая понятийная базапринципиально допускают интеграцию и взаимозаменяемость (элементов)проектов ГОСТ34 и ISO12207.Стандарты групп 12207 и 15288. Несмотря на глубокую трехуровневуюпроработкуэтаповиширокийспектрпокрываемыхпроцессовЖЦ,детализируемость методов и процедур в действующих стандартах программнойи системной инженерии (ISO/IEC 12207:2008 и 15288:2002, ГОСТ/МЭК 122072010 и 15288-2005) на уровне ЖЦ существенно ограничена. При этом посравнению с ГОСТ 34.601-90, регламентирующим процессы разработки ПОлишь в рамках каскадной модели, стандарты нового поколения (группы 12207 и15288) поддерживают более гибкие модели ЖЦ, в т.ч.
итерационную испиральную, и по существу представляют собой расширенные библиотекипроцессов. Для них выбор и последовательность применения этаповконкретизируется по согласованию разработчика с заказчиком и существенноопределяется выбранной совокупностью методологии и модели ЖЦ. В этойсвязи разработан ряд рекомендаций (в т.ч.
ISO/IEC TR 15271 и 19760:2003, атакже ГОСТ Р ИСО/МЭК 15271-2002 и 16326-2002) с разъяснениями поприменению стандартов указанных групп. Тем не менее, ввиду высокойсложностииметодологическоеразнообразиявариантовобобщение процессовиспользованияпроектирования,стандартов,реализацииисопровождения КПК в отрыве от модели ЖЦ и методологии разработки, жесткосогласованной с заказчиком в рамках каждого конкретного проекта, трудноосуществимо. При этом отдельные семантические пробелы присутствуют наверхнем, концептуальном уровне видов деятельности в рамках ЖЦ, а при57продвижении к нижним уровням, детализирующим работы или задачи,семантическая неоднозначность существенно возрастает 1.5.2 Отраслевые и корпоративные стандартыСтандарт проектирования ПО IBM Rational Unified Process (RUP)разработан Г.
Бучем, И. Якобсоном и Дж. Рамбо [151] для семейства продуктовRose, Requisite Pro и др. и предполагает преимущественно итеративнуюразработку корпоративного ПО (хотя пригоден и для каскадного процесса), чтоупрощает планирование, уточняет сроки завершения проекта и ускоряетобратную связь с пользователями. Сценарная (use-case) управляемость RUPспособствует раннему выявлению логических ошибок в спецификациях,формализует разработку интерфейса и тестирование ПО [216].Методология RUP использует потоки для бизнес-анализа требований, ихсбора и трансляции в функциональные спецификации, анализа и моделированиятребований с трансляцией в модели, кодирования, тестирования, управленияконфигурацией, изменениями ПО, управления проектом, создания и поддержкисреды разработки, а также развертывания ПО (для последующего отчуждения).Для ограничения роста сложности КПК используется визуальноеCASEпроектирование на основе унифицированного (для всех стадий ЖЦ) языкаUML (Unified Modeling Language) [151] в среде Rational Rose.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
