Проектирование информационных систем (стр. 4 )

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

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

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

3) Сложность параллельного ведения работ. Отмеченные выше проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последователь­ных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы рас­параллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг от друга группы разработчиков. Поэтому преимущества параллельного ведения ра­бот просто теряются.

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

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

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

Следует также отметить, что, кроме изучения нового материала, не отпадает и не­обходимость в изучении старой информации. Это связано с тем, что вполне веро­ятна ситуация, когда в процессе выполнения разработки изменяется состав груп­пы разработчиков (этот процесс носит название ротации кадров). Новым разра­ботчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчи­ка в курс дела.

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

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

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

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

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

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

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскад­ной схеме, имеют повышенный уровень риска. Этот вывод подтверждается прак­тикой: по сведениям консалтинговой компании The Standish Group, в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчи­вается неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладыва­ется и в срок, и в бюджет.

примечание

Существует еще один серьезный недостаток, присущий каскадной модели разработ­ки, на который также следует обратить внимание. Этот недостаток связан с конфлик­том (не всегда явным) между разработчиками, участвующими в выполнении проекта. Этот конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персони­фицировать ответственного за ошибки далеко не всегда возможно, то попытки поис­ка виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабо­чей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т, п. В результате появляется опасность снижения и квали­фикации, и творческого потенциала всей команды. Соответственно, техническое ру­ководство проектом начинает в большей степени подменяться организационным ру­ководством, все более детальной проработкой должностных инструкций и все более формальным исполнением этих инструкций. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дис­циплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. И такое положение вещей может привести к тому, что наи­более одаренные кадры со временем покинут коллектив.

Лекция 11

Спиральная модель жизненного цикла.

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

Итерации.

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

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

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

Преимущества спиральной модели.

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

·  итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

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

·  итерационный подход упрощает повторное использование компонентов позволяет использовать компонентный подход к программированию — более подробно об этом мы будем говорить в следующей главе). Это обусловлено тем. что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итерации позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;

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

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

Проблемы, возникающие при использовании спиральной модели.

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

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

Лекция 12

Основные особенности методологии RAD

Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений - RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем. RAD - это комплекс специальных инструментальных средств быстрой разработ­ки прикладных информационных систем, позволяющих оперировать с определен­ным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.

Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:

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

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

Основные принципы методологии RAD можно свести к следующему:

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

Объектно-ориентированный подход

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

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

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

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

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

При разработке приложений с помощью инструментов RAD используется множе­ство готовых объектов, сохраняемых в общедоступном хранилище. Однако обес­печивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля». Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формулировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разра­ботке интерфейсов пользователя (при использовании обычных средств разработ­ка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.

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

Визуальное программирование

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

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

Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных— с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разраба­тываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использонанием драйверов ODBC или OLE DB, так и применением специализирован­ных средств (компонентов).

Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определен­ным системам управления балами данных. В качестве примера таких систем мож­но привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft. Поскольку задачи создания прототипов и разработки пользовательского интерфейса, по существу, слились, программист получил непрерывную обратную связь с конеч­ными пользователями, которые могут не только наблюдать за созданием приложе­ния, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психоло­гическим аспектом, который привлекает к RAD все большее число пользователей.

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

Событийное программирование

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

Разработчик реализует логику приложения путем определения обработчика каждого события — процедуры, выполняемой объектом при наступлении соответству­ющий события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помо­щью событий.

Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPD ATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы дан­ных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

Лекция 13

Профили открытых информационных систем

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

Понятие профиля информационной системы

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

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

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

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

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

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

·  регламентирующие архитектуру и структуру информационной системы;

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

В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:

·  профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта;

·  профили информационной системы, предназначенные для решения некоторого класса прикладных задач.

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

Принципы формирования профиля информационной системы

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

·  снижение трудоемкости проектов;

·  повышение качества компонентов информационной системы;

·  обеспечение расширяемости и масштабируемости разрабатываемых систем;

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

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6