Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
Проект (в теории Управления проектами) – это уникальная (в отличие от процесса) деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата (цели), создание определённого уни- кального продукта или услуги при заданных ограничениях по ресурсам и сро- кам, а также требованиям к качеству и допустимому уровню риска. Таким образом, проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Создание ИС представляет собой программный проект. Типология проектов по созданию ИС Проект создания ИС может быть индивидуальным или типовым. Индивидуальный проект – подразумевает разработку ИС, как правило с помощью специалистов самой организации. 54 Типовое проект ИС предполагает создание системы из готовых типовых проектных решений. Типовое проектное решение (ТПР) – это тиражируемое (пригодное к многократному использованию) проектное решение. Выделяют следующие классы ТПР: • элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному); • подсистемные ТПР – в качестве элементов типизации выступают отдель- ные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; • объектные ТПР – типовые отраслевые решения, которые включают пол- ный набор функциональных и обеспечивающих подсистем ИС. Каждое типовое решение предполагает наличие, кроме собственно функ- циональных элементов (программных или аппаратных), документации с де- тальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы. Для реализации типового проектирования используются два подхода: па- раметрически-ориентированный и модельно-ориентированный. Параметрически-ориентированное проектирование включает следу- ющие основные этапы: 1. декомпозиция проектируемой ИС на множество составляющих компо- нентов (подсистем, программных модулей и т.д.); 2. выбор и приобретение из имеющихся на рынке ТПР, необходимых для реализации выделенных компонентов; 3. настройка (доработка) приобретенного ТПР на особенности конкретного предприятия с помощью обслуживающей организации (либо самостоя- тельно с помощью штатных IT-специалистов). Выбор и приобретение ТПР подразумевает выполнение следующих шагов: 55 1) определение критериев оценки компонентов ИС с точки зрения решения поставленных задач; 2) анализ и оценка доступных ТПР по сформулированным критериям; 3) выбор и закупка наиболее подходящего пакета. Критерии оценки ТПР делятся на следующие группы: • назначение и возможности; • отличительные признаки и свойства; • требования к техническим и программным средствам; • документация; • факторы финансового порядка; • особенности установки; • особенности эксплуатации; • помощь поставщика по внедрению и поддержке; • оценка качества решения и опыт его использования; • перспективы развития. Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП. Достаточно полный перечень показателей можно найти в литературе. Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10- балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем. Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС к модели объекта автоматизации. Техно- логия проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия. Модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специаль- 56 ного программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание ИС на базе типовой модели ИС из репозито- рия, который поставляется вместе с программным продуктом и содержит как базовую (эталонную) модель ИС, так и конфигурации для определенных отрас- лей или типов производства. Подходы к проектированию систем Стихийная («лоскутная») автоматизация (подход «cнизу-вверх») Индустрия разработки ПО начала зарождаться в середине 50-х годов XIX в., однако почти до конца 60-х ей не уделялось серьезного внимания, по- скольку ее доля в компьютерном бизнесе была слишком мала. Серьезный рост начался в 70-х годах XX в., начиная с принятого фирмой IBM в 1969 г. решения о развязывании цен (раздельном назначении цен на аппаратуру, ПО и услуги), и продолжился до появления персонального компьютера. На первом этапе основным подходом к проектированию ИС был метод «снизу-вверх». ИС создавалась в виде набора приложений, наиболее важных в данный момент для поддержки деятельности организации. Основной целью этих проектов было обслуживание текущих потребностей конкретного пред- приятия, а не создание тиражируемых продуктов. Такой подход отчасти сохра- няется и сегодня. Основной недостаток метода:возникновение проблем при объединении существующих систем. Системное проектирование (подход «cверху-вниз») Противоположностью стихийной автоматизации является системное про- ектирование, или автоматизация «cверху-вниз». Смысл системного проектиро- 57 вания – реорганизация управления и перепроектирование всей корпоративной информационной системы, которые наилучшим образом достигают целей управления. Этапы системного проектирования: 1) определение целей и задач управления организацией; 2) создание модели организации, главное требование к которой – системная целостность; каждое изменение элемента модели требует перепроверки и согласования как «cверху-вниз», так и «cнизу-вверх»; 3) создание корпоративной ИС на основе этой модели. Основной недостаток системного подхода к проектированию – трудоем- кость поддержания целостности модели. В настоящий момент большинство организаций уже имеет ИС, в различ- ной степени автоматизирующие процессы в них протекающие. Поэтому типич- ными в настоящее время являются следующие проекты: • по разработке новых ИС и их интеграции с существующими ИС; • по разработке новых ИС с целью замены существующих ИС; • по модернизации (наращиванию функциональности, развитию) суще- ствующих ИС. 1.5. Жизненный цикл проекта по созданию ИС Понятие жизненного цикла информационной системы (ЖЦ ИС) Каждый проект, независимо от сложности и объема работ проходит в своем развитии путь от состояния когда «проекта еще нет» до состояния когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы, стадии и этапы. ЖЦ ИС – это непрерывный процесс, который начинается с момента при- нятия решения о необходимости создания ИС и заканчивается в момент ее пол- ного изъятия из эксплуатации. 58 В определении количества фаз и их содержания имеются некоторые от- личия, поскольку эти характеристики во многом зависят от условвий осуществ- ления конкретного проекта и опыта основных участников. Тем не менее логика и основное содержание процесса разработки ИС почти во всех случаях являют- ся общими. Здесь можно выделить следующие фазы развития ИС: 1) концептуальная фаза. Главным содержанием работ на этой фазе являет- ся определение проекта и разработка его концепции, включающая: • формирование идеи, постановку целей; • формирование ключевой команды проекта; • изучение мотивации и требований заказчика и других участников; • сбор исходных данных и анализ существующего состояния (предпро- ектное обследование объекта автоматизации); • определение основных требований и ограничений, требуемых матери- альных, финансовых и трудовых ресурсов; • сравнительную оценку альтернатив; • представление предложений, их экспертизу и утверждение; 2) разработка технического предложения. Главным содержанием этой фазы является разработка технического предложения и переговоры с за- казчиком о заключении контракта. Общее содержание работ этой фазы: • разработка основного содержания и базовой структуры проекта; • разработка и утверждение технического задания; • планирование и декомпозиция базовой структурной модели проекта; • составление сметы и бюджета проекта, определение потребности в ресур- сах; • разработка календарных планов и укрупненных графиков работ; • подписание контракта с заказчиком; • ввод в действие средств коммуникации участников проекта и средств контроля за ходом работ; 3) проектирование. На этой фазе определяются подсистемы, их взаимосвя- 59 зи, выбираются наиболее эффективные способы выплнения проекта и ис- пользования ресурсов. В основе проектирования ИС лежит моделирова- ние предметной области. Цель моделирования – избежать ошибок, при- водящих к экономическим потерям и затратам на последующее перепро- ектирование системы. Другие работы, характерные для фазы проектиро- вания: • выполнение базовых проектных работ; • разработка частных технических заданий; • выполнение концептуального проектирования; • составление технических спецификаций и инструкций; • представление проектной разработки, экспертиза и утверждение. 4) разработка. На этой фазе производятся координация и оперативный кон- троль работ по проекту, осуществляется изготовление подсистем, их объ- единение и тестирование. Основное содержание фазы: • выполнение работ по разработке программного обеспечения; • выполнение подготовки к внедрению системы; • контроль и регулирование основных показателей проекта; 5) ввод системы в эксплуатацию. На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Ос- новные виды работ: • комплексные испытания; • подготовка кадров для эксплуатации создаваемой системы; • подготовка рабочей документации, сдача системы заказчику и ввод ее в эксплуатацию; • сопровождение, поддержка, сервисное обслуживание; 6) изъятие из эксплуатации или замена: • оценка результатов проекта и подготовка итоговых документов; • разрешение конфликтных ситуаций и закрытие работ по проекту; 60 • накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития. На обнаружение ошибок, допущенных на стадии проектирования, расхо- дуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных стадиях про- екта разработку следует выполнять особенно тщательно. Наиболее частые ошибки, допускаемые на начальных этапах: 1) ошибки в определении интересов заказчика; 2) концентрация на маловажных, сторонних интересах; 3) неправильная интерпретация исходной постановки задачи; 4) неправильное или недостаточное понимание деталей; 5) неполнота функциональных спецификаций (системных требований); 6) ошибки в определении требуемых ресурсов и сроков; 7) редкая проверка на согласованность этапов и отсутствие контроля со сто- роны заказчика (нет привлечения заказчика). Модели жизненного цикла ИС Моделью жизненного цикла ИС будем называть некторую структуру, определяющую последовательность выполнения процессов, действий и задач, выполняемых на протяжении ЖЦ ИС, а также взаимосвязи между этими про- цессами, действиями и задачами. К настоящему времени наибольшее распространение получили следую- щие две модели ЖЦ каскадная (70-85 гг.) и спиральная (86-90 гг.). Каскадная модель ЖЦ Основной характеристикой какскадного способа является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит 61 только после того, как будет полностью завершена работа на текущем (рис. 1.6.). Рис. 1.6. Каскадная схема разработки ПО Создание системы рассматривается как однократная последовательность стадий и этапов. Каждый этап завершается выпуском полного комплекта доку- ментации, достаточной для того, чтобы разработка могла быть продолжена дру- гой командой разработчиков. Достоинства каскадного подхода: 1) на каждом этапе формируется законченный набор проектной документа- ции, отвечающий критериям полноты и согласованности; 2) выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Недостатки каскадного подхода выявились в процессе его использова- ния. Дело в том, что реальный процесс создания ПО почти никогда полностью не укладывается в жесткую схему каскадной модели. В процессе создания ПО может возникнуть потребность возврата к предыдущему этапу и уточнения или пересмотра ранее принятых решений. В результате реальный процесс создания ПО часто принимает следующий вид (рис. 1.7.): 62 Рис. 1.7. Реальный процесс разработки ПО по каскадной схеме Основной недостаток каскадного подхода – существенное запаздывание с получением результатов. Согласование результатов с пользователями произ- водится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода созда- ния ПО, пользователи получают систему, не удовлетворяющую их потребно- стям. Модели (как функциональные, так и информационные) автоматизируемо- го объекта могут устареть одновременно с их утверждением. Область применения каскадного подхода (где каскадный подход хорошо за- рекомендовал себя): 1) однородные ИС, где каждое приложение представляет собой единое це- лое; 2) ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разра- ботчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные системы. 63 Oracle CDM (Custom Development Method, CDM) – методика разработки ИС небольших масштабов на основе Oracle, ориентированная на использование каскадной модели ЖЦ. Методика разработки Oracle CDM (Custom Development Method) Компания Oracle, долгие годы специализирующаяся в области средств автоматизации процессов разработки сложных информационных систем, ори- ентированных на интенсивное использование баз данных, предлагает свою ме- тодику. Программный комплекс разработчика, выпускаемый Oracle, носит название Oracle Designer (раннее Oracle CASE). Основные положения методики Oracle: 1) проектирование имеет структурный нисходящий характер, весь процесс разработки системы представляется в виде последовательности чётко определённых этапов; 2) поддержка осуществляется на всех этапах жизненного цикла системы, начиная от общих предложений и заканчивая сопровождением готового продукта; 3) предпочтение отдаётся архитектуре клиент-сервер, включая сложные структуры распределённых баз данных; 4) во время разработки все спецификации проекта хранятся в специальной базе данных (репозитарии). Данное средство включено в состав ПО De- signer и работает под управлением СУБД Oracle. Репозитарий позволяет подключаться к нему большому числу пользователей с различными уров- нями прав доступа путём стандартных средств СУБД Oracle. В результате все действия разработчиков становятся строго согласованными, невоз- можно независимое действие каждого из них; 5) последовательный переход от одного этапа к другому автоматизирован благодаря использованию специальных утилит. С помощью них по спе- 64 цификациям концептуальной стадии можно получить первоначальный вариант спецификации уровня проектирования. В дальнейшем генерация дополнений значительно упрощается; 6) стандартные действия этапов проектирования и разработки автоматизи- рованы. В любой момент может быть сгенерирован любой объём отчётов по содержимому репозитария, которые обеспечивают документирование текущей версии системы на всех этапах её разработки. Имеются специ- альные процедуры, позволяющие осуществить проверку спецификаций на полноту и непротиворечивость. Методика Oracle предлагает свой вариант структуры жизненного цикла информационной системы: 1) формирование стратегии. Здесь происходит моделирование и анализ процессов, которые описывают деятельность организации, особенности работы. Конечная цель – создание моделей процессов, выявление воз- можностей их усовершенствования. Этап не обязателен, если существу- ющие технологии и организационные структуры чётко определены, хо- рошо изучены и в целом понятны; 2) анализ. На этом этапе происходит разработка детальных концептуальных моделей, которые описывают информационные потребности организа- ции, особенности функционирования. В результате формируются модели двух типов: информационные (они отражают структуру и общие законо- мерности предметной области) и функциональные (описывают особенно- сти решаемых задач); 3) проектирование. Здесь начальные требования к системе преобразуются в детальные спецификации. Специальные утилиты, входящие в состав ПО Oracle , значительно упрощают эту процедуру; 4) реализация. На этом этапе разрабатываются и тестируются приложения, входящие в состав будущей ИС. ПО Oracle содержит специальные гене- раторы приложений, которые предельно автоматизируют этот этап, |