Основы информационных технологий

Размещено на http://www.allbest.ru/

1. Основные принципы внедрения и функционирования АИС, которые следует учитывать при проектировании АИС, относят:

Принцип идентичности. Разработка новой, совершенствование существующей или внедрение полученной (приобретённой) извне АИС являются идентичными научно-техническими проблемами, отличающимися друг от друга содержанием ряда этапов и временными параметрами.

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

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

Адаптивность. Компоненты АИС должны обладать свойствами, обеспечивающими быстрое их приспособление к изменениям внешней среды, новым средствам и т.п.

Модульный принцип построения программных и технических средств предполагает, что указанные средства состоят из блоков («модулей»), обеспечивающих возможность их замены или изменения с целью совершенствования АИС или её адаптации к новым условиям.

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

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

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

Экономическая целесообразность. Создание АИС должно предусматривать использование проектных решений, обеспечивающих минимизацию финансовых, материальных затрат и трудовых ресурсов, а также способствующих совершенствованию обслуживания пользователей.

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

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

Принцип корпоративности. При проектировании автоматизированной системы следует предусмотреть её аппаратную, программную, лингвистическую и информационную совместимость с другими АИС. Как правило, разные организации входят в состав различных систем и сетей (республики, края, области, города, района, ведомства и т.п.), участником которых они являются или могут стать. Требования корпоративности могут входить в противоречие с требованиями или решениями, диктуемыми другими принципами, например - преемственности проектных решений.

Ориентация на первых лиц объекта автоматизации. Успешное выполнение работ по созданию АИС, её развитию и эксплуатации возможно при условии их безусловной поддержки первым лицом (директор организации) и закреплении непосредственной ответственности за их выполнение приказом по организации за руководителем на уровне не менее заместителя директора. В подразделениях организации ответственность за выполнение работ должна возлагаться на руководителей этих подразделений.

Рассмотрим некоторые из названных принципов.

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

Непрерывность и поэтапность развития. Это не только принцип проектирования, но и одно из наиболее важных свойств АИС, которая не может длительное время не видоизменяться.

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

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

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

Реализация модульного характера системы имеет свои преимущества и недостатки. Модульная структура программного обеспечения позволяет вести поэтапное внедрение пакетов прикладных программ, что развивает возможности системы, ускоряет её внедрение, а также гарантирует автономное применение каждого пакета в других АИС. К отрицательным моментам относится избыточность и раздробленность пакетов программ. Это усложняет эксплуатацию, требует наличия промежуточных носителей, дополнительных архивов, обеспечивающих надёжность хранения массивов и увеличивает трудоёмкость эксплуатации.

2. Какие же методы используют при проектировании и разработке ИС?

Все эти методы условно можно разделить на четыре больших класса:

структурно-функциональные;

виртуальные (универсальные);

функционально-технологические;

объектные.

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

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

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

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

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

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

Функционально-технологические методы характеризуются:

целостным подходом к анализу и синтезу системной архитектуры ИС и реализуемых в этой архитектуре организационных и управленческих функций;

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

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

учетом физических и информационных связей между элементами ИС;

учетом взаимосвязей создаваемой ИС с внешней средой.

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

3. Жизненный цикл по ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5].

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

4. Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 гг.);

· спиральная модель (86-90 гг.).

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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

Каскадная схема разработки ПО

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

Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10], делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Спиральная модель ЖЦ

Методологии и технологии проектирования ИС

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

Технология проектирования определяется как совокупность трех составляющих:

· пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 6.4);

· критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

· технология должна поддерживать полный ЖЦ ПО;

· технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

· технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

· технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования).

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

· стандарт проектирования;

· стандарт оформления проектной документации;

· стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

· набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации должен устанавливать:

· комплектность, состав и структуру документации на каждой стадии проектирования;

· требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

· правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

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

· требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

· правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

· правила использования клавиатуры и мыши;

· правила оформления текстов помощи;

· перечень стандартных сообщений;

· правила обработки реакции пользователя.

информационный система программный проектирование

Размещено на Allbest.ru