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

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

План

Введение

1. Создание и организация автоматизированных информационных систем

2. Об усилиях и пользе

Заключение

Введение

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

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

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

1. Создание и организация автоматизированных информационных систем

Регламентация жизненного цикла программных средств

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

Разнообразие и проблемы жизненных циклов

Слова "жизненный цикл системы" или "жизненный цикл программного средства" часто появляются в статьях и звучат в разговорах разработчиков, по крайней мере - руководителей проектов и подразделений. Всем понятно, что относятся они к тому, что и в какой последовательности должно делаться при создании и эксплуатации систем. Но прежде чем две организации или два специалиста договорятся о том, что конкретно входит или не входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две "стороны") все-таки по-разному понимают, какие работы будут входить в ЖЦ, а какие - нет, какие проверки будут планироваться и когда, и т. д. и т. п. Естественно, общие принципы организации работ описаны давно, но что делать сторонам в конкретном проекте - это каждый раз приходится решать заново.

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

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

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

Многообразие моделей ЖЦ покажем кратким представлением трех самых известных, в каком-то смысле фундаментальных типов моделей ЖЦ: каскадной, инкрементной и эволюционной.

Каскадная модель ЖЦ реализует, по сути, принцип однократного выполнения каждого вида деятельности в виде заранее ограниченных и однозначно упорядоченных во времени стадий, этапов, осуществляемых как бы в их естественных границах: установление потребностей пользователя; определение требований; проектирование (конструирование); изготовление; испытание; корректировка; поставка или использование.

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

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

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

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

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

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

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

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

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

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

Актуальный подход к стандартизации ЖЦ ПС и систем

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

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

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

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

Основные принципы и методы создания профилей стандартов установлены в стандартах серии ГОСТ Р ИСО/МЭК ТО 10000, определяющих основы и таксономию международных функциональных стандартов информационной технологии; в данной лекции мы не будем их детализировать.

Применительно к ПС построение профилей стандартов активно применяется в международной и национальной стандартизации. В России впервые основы построения и использования профилей стандартов ЖЦ ПС заложены принятием в качестве базового стандарта ГОСТ Р ИСО/МЭК 12207. Данный документ введен в действие с 1 июля 2000 года, тесно взаимоувязан с рядом стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения стандартов ИСО.

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

Общее устройство ГОСТ Р ИСО/МЭК 12207

В данном стандарте впервые реализован принцип структурной стандартизации ЖЦ ПС на основе регламентации требований к процессам, работам и задачам, входящим в полную типовую структуру ЖЦ ПС.

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

Группа основных процессов включает в себя процессы: заказа; поставки; разработки; эксплуатации; сопровождения.

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

В условиях выполнения конкретного проекта на основе ГОСТ Р ИСО/МЭК 12207 следует выбирать соответствующую конкретную модель ЖЦ ПС. В данной модели в той или иной мере должны быть описаны те или иные процессы из всего набора процессов стандарта путем включения в модель соответствующих работ и задач из этих процессов.

Соответствие проекта стандарту ГОСТ Р ИСО/МЭК 12207 определяется как реализация в рамках конкретного проекта такой модели ЖЦ ПС, которая построена на основе выбора из данного стандарта соответствующих процессов, работ и задач. Выполнение процесса или работы считается завершенным, если решены все требуемые в них задачи в соответствии с предварительно установленными в договорной документации проекта (договоре или контракте) критериями и требованиями.

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

Стандарт предназначен для всех сторон, участвующих в процессах жизни ПС, он может быть применен при закупке систем, отдельных ПС и оказании соответствующих услуг; а также при поставке, разработке, эксплуатации и сопровождении ПС и программных компонентов программно-аппаратных средств. В стандарте описан также ряд аспектов, необходимых для обеспечения ЖЦ ПС и относящихся к системе в целом.

Отметим, что стандарт описывает архитектуру процессов ЖЦ ПС, но не определяет детали реализации входящих в них работ и задач. В стандарте не определены наименования, форматы, содержание и комплектность документации, выпускаемой в ЖЦ ПС. Данные вопросы должны решаться в рамках конкретного проекта на основе использования соответствующих стандартов и/или методик. Тем самым обеспечивается повышение не только реальной универсальности стандарта (например, за счет возможности применять его в сочетании с самыми разными частными методиками, ориентированными на конкретное, но различное представление документов проекта), но и его живучести, уменьшение вероятности его устаревания в короткие сроки.

Характеристики процессов ЖЦ ПС

Для более конкретной ориентации читателей ниже приведены краткие характеристики процессов ЖЦ ПС, установленных в ГОСТ Р ИСО/МЭК 12207.

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

· Процесс заказа - работы заказчика (субъекта, приобретающего систему, ПС или получающего программную услугу).

· Процесс поставки - работы поставщика (субъекта, поставляющего систему, ПС или программную услугу заказчику).

· Процесс разработки - работы разработчика (субъекта, проектирующего и разрабатывающего ПС).

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

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

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

· Процесс документирования - работы по описанию информации, выдаваемой в конкретном процессе ЖЦ.

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

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

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

· Процесс аттестации - работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по аттестации (сертификации) конечного продукта проекта.

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

· Процесс аудита - работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и договору

· Процесс решения проблемы - работы по анализу и устранению (решению) проблем (включая обнаруженные несоответствия), независимо от их характера и источника, обнаруженных при реализации проекта.

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

· Процесс управления - основные работы по управлению, включая управление проектом, при реализации процессов ЖЦ

· Процесс создания инфраструктуры - основные работы по созданию базовой структуры какого-либо процесса ЖЦ

· Процесс усовершенствования - основные работы, выполняемые субъектом при создании, оценке, контроле и усовершенствовании выбранных процессов ЖЦ.

· Процесс обучения - работы по соответствующему обучению персонала.

Адаптация стандарта к конкретному проекту

Применение требований ГОСТ Р ИСО/МЭК 12207 к конкретному проекту (его адаптация) состоит из работ следующих видов:

· определение условий выполнения проекта;

· запрос исходных данных для адаптации;

· выбор процессов, работ и задач;

· документирование решений по адаптации и их обоснований.

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

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

При выборе процессов, работ и задач должны быть определены необходимые для построения модели ЖЦ ПС процессы, работы и задачи. При этом должны быть охвачены разрабатываемая документация и обязанности исполнителей. Дополнительные процессы, работы и задачи, необходимые для реализации проекта, но не описанные в ГОСТ Р ИСО/МЭК 12207, следует установить в договорной документации проекта.

Все решения по адаптации и их обоснования должны быть документально оформлены.

При проведении работ по адаптации следует руководствоваться также рекомендациями, приведенными в [7] в части классификации ПС и в [8] в части выбора и построения модели ЖЦ ПС.

Так, построение модели ЖЦ ПС должно базироваться на концептуальной идее ПС (системы), охватывать разработку (создание), эксплуатацию и сопровождение и оканчиваться снятием (утилизацией). Модель ЖЦ обычно разбивается на периоды реализации, например стадии или этапы. Каждое такое разбиение должно охватывать отдельные работы и задачи, реализуемые в данном периоде (стадии, этапе), и при их завершении может потребоваться разрешение сторон на переход к следующему периоду модели.

В качестве основы модели ЖЦ могут быть использованы фундаментальные модели ЖЦ: каскадная, инкрементная и эволюционная, которые были описаны ранее.

Адаптация на основе модульности и ответственности

Вопросы адаптации общей структуры ЖЦ ПС, описанной в ГОСТ Р ИСО/МЭК 12207, являются ключевыми при выборе (построении) модели ЖЦ ПС (автономной или входящей в состав общей модели ЖЦ создаваемой системы) в условиях реализации конкретного проекта.

Процессы общей структуры ЖЦ ПС по ГОСТ Р ИСО/МЭК 12207 основаны на двух исходных принципах: модульности и ответственности.

Принцип модульности, в свою очередь, основан на следующих положениях.

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

· Процессы свободно соединены между собой. Количество интерфейсов между процессами сведено к минимуму.

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

· Процесс должен быть своего рода модулем ЖЦ, т. е. каждый процесс должен выполнять только собственную функцию в ЖЦ, а интерфейсы между двумя любыми процессами должны быть минимальны.

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

· Если процесс А вызван процессом В и только процессом В, тогда А принадлежит к В.

· Если работа или задача вызваны более чем одним процессом, тогда они сами становятся процессом.

· Должна быть возможность для проверки любого процесса, работы и задачи в модели ЖЦ.

· Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что должно выполняться.

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

Ответственность является особенностью структуры ЖЦ применительно к условиям проекта, в который закономерно может быть вовлечено множество субъектов.

2. Об усилиях и пользе

Безусловно, применение ГОСТ Р ИСО/МЭК 12207 требует от соответствующих субъектов определенных усилий по его адаптации к условиям реализации конкретных проектов. Кроме того, требуются усилия по его взаимоувязке с конкретными методиками разработки систем и другими стандартами.

Тем не менее, можно с уверенностью полагать, что внедрение данного стандарта в практическую деятельность должно облегчить упорядочение взаимоотношений между субъектами, вовлеченными в ЖЦ ПС.

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

Методы и организация создания ИС и ИТ

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

Поиск рациональных путей проектирования идет по двум следующим направлениям:

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

2) Разработка автоматизированных систем проектирования.

Рассмотрим первый из путей, т.е. возможности использования типовых проектных решений, включенных в ППП.

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

Наибольшее число ППП создано для бухгалтерского учета. Среди них можно отметить "1С: бухгалтерия", "Турбо-Бухгалтер", "Инфо-Бухгалтер", "Парус", "ABACUS", "Бэмби+" и др.

Справочное и информационное обеспечение управленческой деятельности представлено следующими ППП: "ГАРАНТ" (налоги, бухучет, аудит, предпринимательство, банковское дело, валютное регулирование, таможенный контроль); "КОНСУЛБТАНТ+" (налоги, бухучет, аудит, предпринимательство, банковское дело, валютное регулирование, таможенный контроль).

Экономическая и финансовая деятельность представлена следующими ППП:

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

Многопользовательский сетевой комплекс полной автоматизации корпорации "Галактика" (АО "Новый атлант"), который включает такие важные аспекты управления, как планирование, оперативное управление, учет и контроль, анализ, а для принятия решений - позволяет в рамках СППР обеспечивать решение задач бизнес-планирования с использованием ППП Project-Expert.

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

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

Автоматизированные системы проектирования - второй, быстро-развивающийся путь ведения проектировочных работ.

В области автоматизации проектирования ИС и ИТ за последнее десятилетие сформировалось новое направление - CASE (Computer-Aided Software/System Engineering). Лавинообразное расширение областей применения компьютеров, возрастающая сложность информационных систем, повышающиеся к ним требования привели к необходимости индустриализации технологий их создания. Важное направление в развитии технологий составили разработки интегрированных инструментальных средств, базирующихся на концепциях жизненного цикла и управления качеством ИС и ИТ управления. Они представляют собой комплексные технологии, ориентированные на создание сложных автоматизированных управленческих систем и поддержку их полного жизненного цикла или ряда его основных этапов. Дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-системы или CASE-технологии [11, 12].

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

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

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

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

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

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

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

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

· улучшают качество создаваемых ИС (ИТ) за счет средств автоматического контроля (прежде всего, контроля проекта);

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

· ускоряют процесс проектирования и разработки системы;

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

· поддерживают развитие и сопровождение уже функционирующей ИС (ИТ);

· поддерживают технологии повторного использования компонентов разработки.

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

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

Практически ни один серьезный зарубежный проект ИС и ИТ не осуществляется в настоящее время без использования CASE-средств.

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

Структура жизненного цикла базируется на трех группах процессов:

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

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

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

Под термином CASE (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения автоматизированной системы включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки АС.

Под моделью жизненного цикла разработки программного продукта понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки программного продукта. Наибольшее распространение получили следующие модели жизненного цикла разработки программного продукта: каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модель прототипирования (prototype model); модель быстрой разработки приложений, или RAD-модель (RAD-rapid application development model); многопроходная модель (incremental model); спиральная модель (spiral model).

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