В реальном масштабе времени.

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

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

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

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

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

Программное обеспечение – совокупность программных средств для создания СОД средствами вычислительной техники.

Техническое обеспечение – представляет собой комплекс технических средств применяемых для функционирования системы обработки данных и включает в себя устройство, реализующее типовые операции обработки данных как во вне ЭВМ, так и на ЭВМ различных классов.

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

Правовое обеспечение функционирования СОД включает:

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

• Правило пользования информацией, и порядок разделения сторон по поводу её достоверности.

Лингвистическое обеспечение – представляет собой совокупность языковых средств, используемых на различных стадиях создания и эксплуатации СОД для повышения эффективности обеспечения общения человека и ЭВМ.

Организационные компьютерные ИС

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

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

Понятие жизненного цикла ИС

Понятие жизненного цикла ИС является одним из базовых программ инженерии. Жизненный цикл ИС определяется как период времени, который начинается с момента принятия решений о необходимости создания ИС и заканчивается в момент её полного изъятия из эксплуатации. Основным нормативным документом регламентирующим состав процессов жизненного цикла, является международный стандарт ISO/IEC 12207.

Схема жизненный цикл ИС

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

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

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

Среди моделей ЖЦ можно выделить следующее:

1. Каскадное (до 70г).

2. Интернациональная (70–80 гг.).

3. Спиральная (80–90 гг.).

Принципиальной особенностью каскадного подхода является:

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

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

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

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

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

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

Спиральный метод проектирования

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

• ИС создается не сразу, как в случае каскадного подхода, а по частям, с использованием метода проектирования.

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

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

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

Подход RAD (Rapid Application Development)

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

1. Команды разработчиков от 3–7 человек (должны представлять собой группы профессионалов имеющих опыт программирования и тестирования программного обеспечения).

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

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

Планирование разработки ИС

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

Планирование разработки ИС состоит в определенных трех основных компонентов:

1. Определение цели и разработки.

2. Предварительная экономическая оценка проекта.

1. Построение графика выполнения работ.

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

1. Определение бизнес-планов и целей и целей организации с последующим выделением её потребностей в ИТ.

2. Оценка показателей уже существующих ИС с целью выявления их сильных и слабых сторон.

3. Оценка возможностей использования ИТ для достижения конкурентно способного преимущества.

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

Определение требований к системе

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

1. Предварительное выявление требований к бедующей системе.

2. Определение перечня целевых функций организации.

3. Анализ распределения функций по подразделениям и сотрудникам.

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

5. Анализ существующих средств автоматизации деятельности организации.

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

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

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

Проектирование БД, выбор целевой СУБД и проектирование пользовательского интерфейса

Проектирование БД – это процесс создания проекта базы данных, предназначенной для поддержки функционирования предприятий и способствующий достижению его целей.

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

Логическое проектирование БД – это процесс создания модели используемой на предприятии при проектировании с учетом выбранной модели организации данных. Независимо от типа целевой СУБД и других физических аспектов реализации. Цель логического проектирования состоит в создании модели данных для исследуемой части предприятий. Концептуальная модель данных создается на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Учитывает особенности выбранной модели организации данных целевой СУБД. Однако на этом этапе игнорируются все остальные аспекты выбранной СУБД – например любые особенности физической организации её структур хранения данных и построения индексов.

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

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

• Определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих отрицательную производительность системы с БД.

• Разработки средств защиты создаваемой системой.

• Простейший подход к выбору нужной СУБД функциональной возможности удовлетворяет существующим требованиям.

Разработка приложений – это проектирование интерфейса пользователя и прикладных программ предназначенной для работы с БД. В ЖЦ ИС проектирование БД и приложений выполняются параллельно. В большинстве случаев проектирование приложений нельзя завершить до описания проектирования БД. С другой стороны БД предназначена для поддержки приложений.

Необходимо убедится, что все функциональные возможности, предусмотренные в спецификациях требований пользователей, обеспечиваются интерфейсом пользователя соответствующих приложений. Это относится как проектирование программ доступа к информации баз данных, так и к проектированию транзакций, т.е. проектированию методов доступа к БД. В результате выполнения всех этапов проектирования будет подготовлено все, что необходимо для реализации БД и прикладных программ. Реализация БД осуществляется посредством создания её описания на языке определения данных OLE, DDL. Команды DDL языка компилируются и используются для создания схем и пустых файлов БД, на этом же этапе определяются все специфические пользовательские представления.

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

В настоящее время любая СУБД имеет утилиту загрузки уже существующих файлов в новую БД.

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

Эксплуатация и сопровождение – это наблюдение за системой и поддержка её нормального функционирования по окончанию развертывания. Этот этап ЖЦ ИС включает выполнение таких действий, как:

• Контроль производительности системы. Если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная настройка или реорганизация БД.

• Сопровождение и модернизация ИС. Новые требования включаются в приложения БД при повторном выполнении предыдущих этапов ЖЦ.

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

В соответствии со стандартом ISO/IEC 12207 все процессы жизненного цикла разделены на 3 группы.

Основные процессы Приобретение Поставка Разработка Эксплуатация Сопровождение	Вспомогательные процессы Документирование Управление конфигурацией Обеспечение качества Верификация Аттестация, совместная оценка Аудит Разрешение проблем
Организационный процесс Управление Создание инфраструктуры Усовершенствование Обучение

Процессы жизненного цикла программного обеспечения

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

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

Основные процессы жизненного цикла

Процесс приобретения – состоит из действий и задач заказчика приобретающего программное обеспечение.

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

1. Инициирование приобретения.

2. Подготовка заявочных приложений.

3. Подготовка к корректировки договора.

4. Надзор за деятельностью поставщика.

5. Приемка и завершение работы.

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

1. Инициирование поставки.

2. Подготовка ответа на заявочные предложения.

3. Подготовка договора.

4. Планирование.

5. Выполнение и контроль.

6. Поставка и завершение работы.

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

1. Подготовка работы.

2. Анализ требований к системе.

3. Проектирование архитектуры системы.

4. Анализ требований к программному обеспечению.

5. Проектирование архитектуры.

6. Детальное проектирование.

7. Подготовка и тестирование ПО.

8. Интеграция ПО.

9. Квалификационное тестирование ПО.

10. Интеграция системы.

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

1. Подготовительную работу.

2. Анализ проблем и запросов на модификацию ПО.

3. Модификация.

4. Проверку и приемку.

5. Перенос ПО в другую среду.

6. Снятие ПО с эксплуатации.

Использование case средств

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

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

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

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

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

3. Использование специальным образом организованного хранилища проектных метаданных.

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

Российский стандарт ГОСТ 34.602–89

ИТ комплекс стандартов на автоматизированной системе, техническое задание на создание автоматизированных систем. ГОСТ 34.601–90 автоматизированные системы, стадии создания.

Все эти стандарты образуют группу ГОСТ 34. Согласно ГОС 34 проект имеет следующие стадии:

1. Формирование требований к автоматизированной системе, стадии формирования системы.

• Обследование объекта и обоснование необходимости проектирования.

• Определение требований заказчика.

• Отчет о работе.

• Заявка на разработку технических заданий.

2. Разработка концепции.

• Изучение объекта.

• Проведение НИР (научно исследовательские работы).

• Разработка вариантов автоматизированных систем и отчет о работе.

3. Разработка и утверждение технического задания

4. Разработка эскизного проекта автоматизированной системы.

• Предварительное решение по всей системе и отдельным компонентам.

• Разработка документации.

5. Разработка технического проекта.

• Тщательная проработка всей системы в целом и отдельных компонентов.

• Разработка и оформление технической документации.

6. Разработка документации.

• Разработка и адаптация ПО.

7. Ввод разработанной системы в действие.

• Подготовка объекта автоматизации.

• Подготовка персонала.

• Комплектация автоматизированной системы программами и техническими средствами.

• Монтажные работы.

• Пуско-наладка.

• Предварительные испытания.

• Опытные эксплуатации.

• Приемочные испытания.

8. Сопровождение.

• Выполнение работ в соответствии с гарантированными обязательствами.

• После гарантийное обслуживание.

Принципы и стандарты документирования ИС

Документацию на программные средства разрабатываются во время разработки самого программного средства (то есть на всех этапах ЖЦ).

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

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

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

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

Технологическая документация

1. Определяет структуру и содержание исходных и отчетных документов по всем этапам ЖЦ ИС.

2. Многочисленную структуру программных и информационных компонентов и БД ИС.

3. Спецификацию на межмодульные интерфейсы, и интерфейсы с внешней средой.

4. Язык и правила программирования, комментирование текста в программах.

5. Методы тестирования испытаний и аттестация.

Эксплуатационная документация

1. Руководства администраторов и операторов для использования и непосредственного управления.

2. Руководство операторов пользователя.

3. Документация сопровождения.

4. Справочное руководство по управлению.

5. Учебные руководства по работе с программами.

Организация документирования

Для создания сложной и качественной документации определяют организационную структуру, в которую входит:

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

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

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

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