Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
По функциональным возможностям,отражающим функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и компонентный со- став, выделяют следующие типы CASE-средств: 113 • средства анализа (Upper CASE). Предназначенны для построения и ана- лиза моделей предметной области (Design/IDEF (Meta Software), Bpwin (Logic Works)); • средства анализа и проектирования (Middle CASE). Поддерживают наиболее распространенные методологии проектирования и использую- щиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)); Выходом таких средств являются спецификации компонентов и интер- фейсов системы, архитектуры системы, алгоритмов и структур данных; • средства проектирования баз данных – обеспечивают моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся Erwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирова- ния баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; • средства (быстрой) разработки приложений. На начальном этапе су- ществования ИС их разработка велась на традиционных языках програм- мирования. По мере возрастания сложности разрабатываемых систем по- являлась потребность в новых средствах, обеспечивающих сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области ПО – инструментальных средств для быстрой раз- рабоки приложений (RAD – Rapid Application Development). RAD полу- чила широкое распространение и одобрение в конце XX века. Концепцию RAD также часто связывают с концепцией визуального программирова- ния. Примеры сред разработки, частично использующи принципы RAD: C++ Builder и Delphi (Borland). Развитие этого направления привело к по- явлению на рынке ПО средств автоматизации практически всех этапов ЖЦ ИС и новым подходам к созданию и проектированию ИС. К CASE средствам разработки приложений относятся также: 4GL (Uniface 114 (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично – в Silverrun; • средства реинжиниринга – обеспечивают анализ программных кодов и схем баз данных и формирование на их основе различных моделей и про- ектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, Erwin и S-Designor; • в области анализа программных кодов наибольшее распространение по- лучают объектно-ориентированные CASE-средства, обеспечивающие ре- инжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)); • вспомогательные типы включают: o средства планирования и управления проектом (SE Companion, Microsoft Pr oject и др.); o средства конфигурационного управления (PVCS (Intersolv)); o средства тестирования (Quality Works (Segue Software)); o средства документирования (SoDA (Rational Software)). По степени интегрированности выполняемых функций выделяют сле- дующие типы CASE-средств: • отдельные локальные средства, решающие небольшие автономные задачи (tools); • набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit); • полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Интегрированное CASE-средство (или комплекс средств, поддержива- ющих полный ЖЦ ПО) содержит следующие компоненты: 115 • репозиторий, являющийся основой CASE-средства. Он должен обеспечи- вать хранение версий проекта и его отдельных компонентов, синхрониза- цию поступления информации от различных разработчиков при группо- вой разработке, контроль метаданных на полноту и непротиворечивость; • графические средства анализа и проектирования, обеспечивающие созда- ние и редактирование иерархически связанных диаграмм; • средства разработки приложений, включая языки 4GL и генераторы ко- дов; • средства конфигурационного управления; • средства документирования; • средства тестирования; • средства управления проектом; • средства реинжиниринга. Другие способы классификации CASE-средств: • по применяемым методологиям и моделям систем и БД; • по степени интегрированности с СУБД; • по доступным платформам. На сегодняшний день Российский рынок программного обеспечения рас- полагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; Erwin; Bpwin; S-Designor; CASE.Аналитик. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Arch itect, Visible Analyst Workbench, EasyCASE), так и новые версии и модифи- кации перечисленных систем. Оценка и выбор CASE-средств Входной информацией для процесса оценки является: • определение пользовательских потребностей; 116 • цели и ограничения проекта; • данные о доступных CASE-средствах; • список критериев, используемых в процессе оценки. Элементы процесса оценки включают: • формулировку цели, предположений и ограничений, которые могут уточняться в ходе процесса; • определение потребности пользователей, отражающие количествен- ные и качественные требования пользователей к CASE-средствам; • определение критериев, определяющих набор параметров, в соответ- ствии с которыми производится оценка и принятие решения о выборе; • формализация результатов оценок одного или более средств; • принятие решения (либо дальнейшая оценка). Определение списка критериев основано на пользовательских требовани- ях и включает: • выбор критериев оценки; • определение области использования каждого критерия; • определение одной или более метрик для каждого критерия; • назначение веса каждому критерию. Современные методологии и реализующие их технологии поставляются в электронном виде вместе с CASE-средствами и включают библиотеки процес- сов, шаблонов, методов, моделей и других компонент, предназначенных для построения ПО того класса систем, на который ориентирована методология. Электронные методологии включают также средства, которые должны обеспечивать их адаптацию для конкретных пользователей и возможность раз- вития по результатам выполнения конкретных проектов. Процесс адаптации методологии заключается в следующем: • удаление ненужных процессов и других компонентов методологии; • изменение неподходящих или добавление собственных процессов, также методов, моделей, стандартов и руководств. 117 Настройка методологии может осуществляться по следующим аспектам: • этапы и операции ЖЦ; • участники проекта; • используемые модели ЖЦ; • поддерживаемые концепции и др. Электронные методологии, технологии и поддерживающие их CASE- средства составляют комплекс согласованных инструментальных средств раз- работки ИС. 2.5. Рекомендации по управлению программным проектом Особенности программных проектов Программные проекты относятся к проектам, связанным с созданием программных средств, услуг или выдачей соответствующих результатов. Основные особенности программных проектов заключаются в том, что программные средства: являются наиболее сложными; являются элементами общей системы, увеличивающими ее сложность и создающими предпосылки для последующих ее изменений; наиболее доступны для пользователей и по- этому являются основным объектом их претензий. Программные средства по своей природе отличаются от непрограммных продуктов, услуг и результатов, поэтому управление программными проектами имеет характерные особенности. Процесс управления программным проектом Процесс управления программным проектом зависит от многих факторов, например персонала, организационных и договорных требований и сложности 118 проекта. Администраторы программного проекта определяют методологию и методы (технологию) реализации проекта, необходимые для выполнения задач прогнозирования и соответствующего предотвращения или минимизации рис- ков, решения возникающих проблем. Процесс управления (по ГОСТ Р ИСО/МЭК 12207) состоит из общих работ и задач, которые могут быть использованы любой стороной, управляю- щей соответствующим процессом (ами). Администратор отвечает за управле- ние продуктом, проектом, работами и задачами соответствующего процесса (ов), таких как заказ, поставка, разработка, эксплуатация, сопровождение или вспомогательные процессы. Ниже приведено описание процесса управления программным проектом по ГОСТ Р ИСО/МЭК 12207. 1. Подготовка и определение области управления. Данная работа со- стоит из следующих задач: 1) установление требований к реализуемому процессу; 2) определение возможностей реализации процесса: проверка наличия, со- ответствия и применимости ресурсов, выделенных для выполнения и управления процессом (персонала, материалов, технологии и условий), а также реальности сроков реализации процесса; 3) при необходимости и по согласованию со всеми заинтересованными сто- ронами изменение требований к процессу с точки зрения удовлетворения критериям завершения процесса. 2. Планирование. Данная работа состоит в подготовке планы для выпол- нения процесса. Планы должны содержать описания соответствующих работ и задач, обозначения создаваемых программных продуктов; охватывать следую- щие вопросы: 119 • установление графиков своевременного решения задач; • оценка необходимых трудозатрат; • определение ресурсов, необходимых для выполнения задач; • распределение задач по исполнителям; • определение обязанностей исполнителей; • определение критических ситуаций, связанных с задачами или самим процессом; • установление используемых в процессе критериев управления качеством; • определение затрат, связанных с реализацией процесса; • обеспечение условий и определение инфраструктуры выполнения про- цесса. Планы должны также устанавливать модель ЖЦ программного средства, задачи, распределение задач и соответствующие ресурсы. Оценки проекта, используемые при планировании, должны охватывать: • стоимость реализации соответствующих процессов; • инфраструктуру; • потребности в ресурсах, включая соответствующее управление и кон- троль; оценку и контроль качества; • управление риском; • задания, выполняемые в каждом процессе и (или) работе. Администраторы каждого программного проекта должны стремиться по возможности использовать существующую организационную инфраструктуру. Если существующая инфраструктура не удовлетворяет потребностям проекта, тогда она должна быть соответствующим образом адаптирована или дополнена. Архивные данные следует постоянно использовать для усовершенствова- ния процессов жизненного цикла этой организации. 3. Выполнение и контроль. Данная работа состоит из следующих задач: • начать реализацию плана, чтобы удовлетворить поставленным целям и критериям проекта, выполняя управление процессом; 120 • осуществлять текущий надзор за выполнением процесса, подготавливая как внутренние отчеты о развитии процесса, так и внешние отчеты для заказчика в соответствии с условиями договора; • исследовать, анализировать и решать проблемы, обнаруженные при вы- полнении процесса; Все обнаруженные проблемы и их решения должны быть документально оформлены; • в установленные сроки отчитаться о реализации процесса. Измерения программного средства могут быть использованы для провер- ки соответствия между ожидавшимися функциями программного продукта и его функциями при эксплуатации. 4. Проверка и оценка. Данная работа состоит из следующих задач: • обеспечить оценку программных продуктов и планов на соответствие установленным требованиям; • проверить результаты оценок программных продуктов, работ и задач, реализуемых в ходе процесса, на соответствие поставленным целям и на выполнение утвержденных планов. Вспомогательные процессы по ГОСТ Р ИСО/МЭК 12207 (например, про- цессы совместного анализа и аудита) дополняют работу по проверке и оценке. 5. Завершение. Данная работа состоит из следующих задач: 1) определить степень соответствия конечных результатов критериям, установленным в договоре или организационной процедуре; 2) проконтролировать результаты и полноту документации созданных программных продуктов и выполненных работ. Все представленные окончательные результаты и соответствующая доку- ментация должны быть сохранены в архиве в соответствии с условиями дого- вора. 121 Стандарты в области управления программным проектом: • Руководство РМВОК™ содержит рекомендации по управлению проек- тами в целом; • ГОСТ Р ИСО/МЭК 12207 содержит информацию о программных проек- тах, вспомогательных процессах (5.2 ГОСТ Р ИСО/МЭК 12207) и описа- ние большинства подлежащих реализации работ (видов деятельности) и задач (заданий). • ИСО 10006 содержит информацию, относящуюся к повышению качества управления проектом. 122 3. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ОБЪЕКТА 3.1. Задачи и этапы предпроектного обследования Обследование предприятия является важным и определяющим этапом проектирования ИС и при правильном подходе позволяет сократить эксплуата- ционные расходы и время на исправление ошибок, обнаруживаемых после сда- чи системы. Предпроектное обследование обычно состоит из трех этапов: 1) предварительное обследование (сбор сведений об объекте); 2) анализ сведений (описание и моделирование предметной области); 3) оценка эффективности и целесообразности ИТ-проекта. На каждом этапе применяются различные методы исследования систем управления (ИСУ). Цели ИСУ: улучшение, изменение (реинжиниринг) или автоматизация си- стем управления. Предмет исследования,то есть то, что изучает исследователь с целью решения проблем на объекте, это: система знаний, умений и навыков; методы и способы; факторы внешней и внутренней среды; процессы, происходящие в ор- ганизации. Объектом исследования является организация и ее подсистемы – реаль- ные физические объекты, измеряемые качественными и количественными по- казателями. Научное исследование, как правило, проводится в предметных рамках определенного научного подхода с использованием группы научных методов. Цели исследования системы управления: улучшение, изменение (ре- инжиниринг) или автоматизация систем управления. Метод исследования – это способ получения нового знания, а также ин- струментарий, с помощью которого проводится исследование; совокупность приемов обработки информации, позволяющих достичь целей исследования. 123 Выбор методов исследования, интеграция различных методов при проведении предпроектного обследования определяется знанием, опытом и интуицией спе- циалистов, проводящих исследование. Методы исследования предметной области проектирования ИС можно разбить на следующие группы: • основанные на использовании знаний и интуиции специалистов (экс- пертные методы); • формализованного представления систем, основанные на использовании математических, экономико-математических методов и методов модели- рования, среди которых при проектировании информационных систем особое место занимают графические, включающие различные методы графического представления информации. • комплексированные – сформировались путем интеграции экспертных и формализованных методов (комбинаторика, ситуационное моделирова- ние, топология, графосемиотика и др). 3.2. Сбор сведений об объекте На предварительном этапе обследования решаются следующие задачи: • предварительное выявление требований к будущей системе; • определение структуры организации; • определение перечня целевых функций организации; • анализ распределения функций по подразделениям и сотрудникам; • выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних информационных воздействий; • анализ существующих средств автоматизации организации и др. Длительность предварительного обследования обычно составляет 1-2 не- дели. В течение этого времени системный аналитик должен обследовать не бо- 124 лее 2-3 видов деятельности (учет кадров, бухгалтерия, перевозки, маркетинг и др.). Сбор информации для построения полной бизнес-модели организации ча- сто сводится к изучению документированных информационных потоков и функций подразделений, а также производится путем интервьюирования и ан- кетирования. К началу работ по обследованию организация обычно предоставляет комплект документов, в состав которого обычно входят: 1) сводная информация о деятельности предприятия (оргструктура, инфор- мация об управленческой, финансово-экономической, производственной деятельности предприятия, сведения об учетной политике и отчетности); 2) регулярный документооборот предприятия (реестры входящей, исходя- щей и внутренней информации (табл. 3.1.); 3) сведения об инфраструктуре предприятия; 4) сведения об ответственных лицах и исполнителях. Таблица 3.1. Реестры информации Реестр входящей инфрмации (Наименование пред- приятия) (Наименование подразде- ления) Характеристики обработки документов № Наименование и назначение доку- мента Кто обраба- тывает Откуда по- ступает Трудоемкость Периодичность, регламент Способ полу- чения Реестр внутренней информации (Наименование пред- приятия) (Наименование подразде- ления) Характеристики обработки документов № Наименование и назначение доку- мента Кто обраба- тывает Кому пе- редает Трудоемкость Периодичность, регламент Способ полу- чения Реестр исходящей информации (Наименование пред- приятия) (Наименование подраз- деления) Характеристики обработки документов № Наименование и назначение доку- мента Кто обраба- тывает Куда по- ступает Трудоемкость Периодичность, регламент Способ получе- ния |