2.1 Требования к информационной системе
Необходимостьl определенияl требованийl к ИС возникаетl в следующихl случаях:
вl моментl выбораl новойl информационнойl системы,
приl подготовкеl тендернойl документации,
при заключенииl договораl на разработкуl или настройку выбраннойlинформационной системы,
приl уточнении (детализации) потребностейl бизнесаl в процессе,
разработкиl илиl настройкиl системы,
приl необходимостиl внесенияl измененийl вl системуl вl ходе эксплуатации.
Всеl существующиеl сегодняl методикиl определенияl требований к ИС являютсяl наследникамиl BSP (Businessl System Planning – планирование бизнес-систем), используютl предложенныеl в нейl методыl сбора информации, подходыl в определенииl приоритетовl требований, обеспечении lполнотыl и непротиворечивостиl требований.
Методикаl BSP определяетсяl как «подход, помогающийl предприятию определитьl планl созданияl информационныхl систем, удовлетворяющих его ближайшиеl и перспективныеl информационныеl потребности».
Потребностьl вl созданииl ИСl можетl обусловливатьсяl либо необходимостьюl автоматизацииl илиl модернизацииl существующих информационныхl процессов, либоl необходимостьюl коренной реорганизацииl вl деятельностиl предприятияl (проведении бизнес-реинжиниринга). Вl зависимостиl от этогоl кl ИСl применяются соответствующиеl требованияl какl поl ихl функциональности, такl и по принципамl проектированияl и внедрения. Требованияl кl проекту определяютсяl характеристикамиl проектируемойl ИС иl условиямиl среды разработки (окружениемl проекта).
Должныl бытьl такжеl определеныl общиеl требованияl к технологии и средствамl разработки, кl структуре и организацииl комплексаl программ;
требованияl кl квалификационнымl испытаниям, кl средствамl и организацииl тестированияl программl на всехl этапахl разработки; требованияl к организации, выполнениюl и документированиюl оценок качества ИС, аl также требованияl кl конфигурационномуl управлению.
Какl иl во всехl проектах, дляl удачногоl завершенияl разработки ИС необходимымl условиемl являетсяl тщательнаяl организацияl и проработка начальныхl этапов (инновационногоl циклаl проекта). Недостаточныйl анализ предметнойl области, обоснованиеl требованийl к проектуl «на скорую руку», нечеткоеl определениеl целейl проекта, ошибкиl в оценкеl трудоемкости, стоимостиl и длительностиl созданияl ИС приводятl кl тому, чтоl результаты проектаl оказываютсяl нижеl намеченных, аl самиl проектыl не укладываются в графикиl и бюджетl разработки. Проектированиеl ИСl вl России регулируетсяl ГОСТl 34.601-90 «Автоматизированныеl системы. Стадии создания».
Системныйl анализ ИСl начинаетсяl с описанияl и анализа функционированияl рассматриваемогоl экономическогоl объекта (системы) в соответствииl с требованиямиl (целями), которыеl предъявляютсяl к нему. В результатеl этого этапаl выявляютсяl основныеl недостатки существующейl ИС, наl основеl которыхl формулируетсяl потребностьl в совершенствованииl системыl управленияl этим объектом, иl ставится задача определенияl экономическиl обоснованнойl необходимостиl автоматизации определенныхl функцийl управления, то естьl создаетсяl технико-экономическоеl обоснованиеl проекта. Послеl определенияl этой потребности возникаетl проблемаl выбораl направленийl совершенствованияl объектаl на основеl выбораl программно-техническихl средств. Результаты оформляютсяl в виде техническогоl задания наl проект, вl котором отражаютсяl техническиеl условияl и требованияl к ИС, аl также ограничения на ресурсыl проектирования. Требованияl к ИС определяютсяl в терминах функций, реализуемыхl системой, иl предоставляемойl еюl информацией.
Системныйl синтез начинаетсяl с этапаl поl составлению функциональнойl архитектуры (ФА), представляющейl собойl совокупность функциональных подсистем и связей между ними, является наиболее ответственным с точки зрения качества всей последующей разработки.
Блок 6 включаетl разработкуl инструкцийl пользователямl и программ, созданиеl информационногоl обеспечения, включаяl наполнениеl баз данных.
Внедрениеl разработанного lпроекта начинаетсяl с опытногоl внедрения, заключающегосяl вl проверке работоспособностиl элементовl и модулейl проекта, устраненииl ошибок на уровне элементовl и связейl между ними.
Этапl сдачиl в промышленнуюl эксплуатацию заключается в организацииl проверкиl проекта наl уровне функций и контроля соответствия его требованиям, сформулированнымl наl стадии системногоl анализа.
Эксплуатацияl и сопровождениеl проекта. Наl этой стадииl выполняютсяl этапы: эксплуатацияl проекта lсистемы и модернизация проекта ИС.
Функциональныеl требования к информационнойl системе, которые описываются, вl томl числе, иl с помощьюl моделейl процессовl и структур данных, являютсяl только lчастьюl общих требований, которыеl содержаться в техническомl задании. Разделl требований кl информационнойl системе техническогоl задания можетl содержатьl следующие подразделы:
требованияl к функциональнымl характеристикам
требованияl кl надежности
настраиваемость
условияl эксплуатации
требования к информационнойl и программнойl совместимости
Требованияl к функциональнымl характеристикам. Вl этомl разделе должны бытьl указаны требованияl к составуl выполняемыхl функций, организацииl входныхl и выходныхl данных. Приl выборе между объектными и структурнымиl методамиl следует использоватьl принципl концептуальной общности, которыйl предполагаетl следованиеl единой философииl на всех этапахl жизненного цикла. Еслиl предполагаетсяl использоватьl структурное программирование, тоl и на этапеl анализаl следует использовать структурныйl подход, а в случаеl использованияl объектно-ориентированных языковl разработки – объектныйl анализ иl объектноеl проектирование. При необходимостиl структурныйl и объектныйl подходы могутl использоваться одновременно.
Требованияl к надежности. Вl разделеl должныl бытьl определены требованияl к обеспечениюl надежного функционирования: контроль входнойl и выходнойl информации, времяl и механизмыl восстановления послеl программныхl и аппаратныхl отказов. Вl этомl разделеl описывается организацияl системыl безопасности, включаяl подсистемы контроля доступа, шифрованияl и т. п.
Настраиваемость. Определяютсяl требованияl кl адаптационным возможностям ПО, тоl естьl указывается, какиеl измененияl в методах управленияl и бизнесl процессах должныl быть предусмотрены.
Условияl эксплуатации. Вl этомl разделе описываетсяl необходимое обслуживание, котороеl требуется дляl работы системы, например, создание резервныхl копий, реиндексерованиеl баз и т. п., а такl же требования к квалификацииl персонала (пользователейl и обслуживающего персонала).
Требованияl к составуl и параметрамl технических средств. Указываетсяl необходимыйl состав техническихl средствl с указанием их основныхl технических характеристик. Могутl указыватьсяl требования к помещениям, в которыхl будетl находитьсяl оборудование. Вl этомl разделе указываютсяl требованияl к переносимости системы.
Требования к информационной и программной совместимости.
Требованияl к информационнымl структурам наl входе иl выходе, методамl решения, исходнымl кодам, языкамl программирования и программнымl средствам, используемымl программой.
Требованияl к программнойl документации. Вl этомl разделе указываетсяl предварительныйl составl программнойl документации, иl при необходимости, специальныеl требования к ней.
Еще разl необходимо подчеркнуть, чтоl состав разделов технического заданияl определяетсяl особенностями проекта, например, вl случае внедренияl существующей ИС требованияlк надежности, информационной и программнойl совместимости, документацииl и т. п. имеютl номинальное значение, посколькуl этиl характеристикиl уже заложеныl в систему и указываютсяl лишь как частьl обязательствl в рамках контракта, не влияя на фактическийl объем работ. В случаеl разработки заказнойl системы эти требованияl необходимо учестьl приl проектировании, ониl определятl состав работl и структуруl проекта.
Динамикаl измененияl требованийl зависит отl выбраннойl модели жизненногоl цикла, в каскаднойl (последовательной) модели требования определяютсяl один раз вl начале проекта, а вl спиральной (итерационной) – уточняются вl ходе выполненияl проекта. Воl второмl случае должнаl быть предусмотренаl процедураl управленияl требованиями. Однимl из возможныхl подходов являетсяl представлениеl совокупностиl требований в видеl набора атомарныхl требований – утверждений, междуl которыми выявляютсяl отношенияl зависимости. Приl использовании каскадной модели все требованияl содержатьсяl в техническомl задании, затем они преобразуютсяl в архитектурное решениеl в техническомl проекте, в этом случае процедураl управленияl требованиямиl упрощается, ведь предполагается, чтоl требованияl не будутl менятьсяl в ходе проекта.
Разработка информационной системы
Разработка интерфейса информационной системы
СПИСОК ЛИТЕРАТУРЫ