Собирать исходные данные для разработки проектной документации на информационную систему
 Скачать 67.22 Kb.
|
|
СОБИРАТЬ ИСХОДНЫЕ ДАННЫЕ ДЛЯ РАЗРАБОТКИ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ НА ИНФОРМАЦИОННУЮ СИСТЕМУ Сбор исходных данных является важной задачей проектирования, и от полноты ее выполнения зависит качество проектной работы, количество дальнейших изменений проекта и, как следствие, минимизация числа ошибок, которые придется устранить при монтаже и на этапе ввода объекта в эксплуатацию. Информационные системы занимают одно из самых важных мест в инфраструктуре объекта и проектируются с учетом пожеланий заказчика, требований по функционалу, скорости передачи данных и условий эксплуатации. На сегодня информационные системы являются в большинстве случаев необходимым атрибутом каждого офисного, жилого, общественного и производственного здания и обеспечивают работоспособность, связывая в единое целое различное оборудование: сервер, ПК, оргтехнику, IP-телефонию, охранные системы, системы противопожарной защиты и т.д. При проектировании информационных систем требуется руководствоваться следующими исходными данными. 1. Согласованное техническое задание. Это главный документ как для проектирования, так и для охранных систем. Проектируемые системы и их функционал должны быть описаны как можно более подробно. 2. Задания от смежных разделов на подключение к СКС и ЛВС. 3. ТУ на подключение к сетям связи (телефонии, телевидению, Интернету) от провайдеров. 4. ТУ на подключение к проводному вещанию. Собранные материалы обследования должны включать в себя: Цель и задачи функционирования объекта; Сведения об организационной структуре (отделы, цехи, склады, хозяйственные службы и т. п.); Перечень функций, выполняемых в каждом подразделении; Сведения о технологических процессах обработки управленческой и экономической информации (документооборот, методы учета и планирования); Сведения о материальных потоках и процессах их обработки, включая имеющиеся ресурсные ограничения. Анализ собранной информации проводится для решения следующих задач: Определить количественные и качественные характеристики информационных потоков, получить описание их структуры и мест обработки; Уточнить объемы выполняемых операций и трудоемкость каждой из них; Оценить качество функционирования объекта и выявить проблемы, решение которых возможно средствами автоматизации; Исследовать рынок программного обеспечения на предмет наличия предложений информационных систем, решающих выявленные проблемы. На основе проведенного анализа формулируются предварительные требования к ИС (с точки зрения аналитиков и будущих пользователей), устанавливаются ограничения допустимых затрат на ее разработку и внедрение, оценивается ожидаемый экономический эффект. Все это излагается в отчете по проделанной работе и/или заявке на создание ИС (тактико-техническом задании). РАЗРАБАТЫВАТЬ ПРОЕКТНУЮ ДОКУМЕНТАЦИЮ НА РАЗРАБОТКУ ИНФОРМАЦИОННОЙ СИСТЕМЫ В СООТВЕТСТВИИ С ТРЕБОВАНИЯМИ ЗАКАЗЧИКА Техническая документация может включать в себя не только сам документ – основание разработки, но и другие артефакты, создаваемые на разных этапах разработки. На начальном этапе проекта может потребоваться провести обследование объекта автоматизации, в результате которого аналитики проекта должны представить аналитический отчет. Аналитический отчет может быть выполнен согласно требованиям ГОСТ 7.32-2001. Данный вид технической документации может содержать описание бизнес-процессов предприятия, рекомендации по автоматизации отдельных процессов. На стадии обследования объекта автоматизации аналитиками обычно формируется словарь терминов, описывающий предметную область, а также процессы, протекающие на предприятии. Все эти данные должны быть зафиксированы в технической документации для дальнейшего согласования их заказчиком. Описание процессов может быть выполнено с помощью диаграммы IDEF0 или диаграммы вариантов использования UML. Диаграммы, размещенные в аналитическом отчете, следует сопровождать текстовым описанием, где необходимо указать: краткое описание процесса; действующие лица (актеры); предусловие; постусловие; основной сценарий процесса; альтернативные сценарии (альтернативные сценарии на данном этапе могут быть выявлены не все, данное описание может дополняться в процессе уточнения требований). Сценарии варианта использования в технической документации могут быть дополнены диаграммой деятельности UML, это поможет выявить дополнительные процессы и возможно неучтённых действующих лиц. Также в аналитическом отчете можно показать примерные границы проекта, выделив процессы или функции, которые должны быть автоматизированы. Аналитический отчет является частью пакета технической документации и предназначен для описания предварительных целей создания ИС. В конце документа следует дать технико-экономическое обоснование разработки ИС. Данный раздел технической документации, при необходимости, может быть выделен в отдельный документ. Этап обследования объекта автоматизации юридически может быть оформлен отдельным договором или включен в перечень работ по созданию ИС. Следующим этапом создания ИС, является уточнение требований и на основании этого анализа создание документа «Техническое задание». На данном этапе производится детализация процессов, выявленных на этапе обследования, которая способствует формированию списка функциональных требований к Системе. Функциональные требования могут быть описаны в технической документации при помощи все тех же диаграмм UML: use case (варианты использования или диаграммы прецедентов), avtivity (сценарии вариантов использования), state machine (диаграмма конечных автоматов). На данном этапе разработки технической документации можно дополнить описание вариантов использования исключениями, то есть описанием поведения Системы в исключительных случаях (например, сбой или отказ аппаратных средств). Диаграмму конечных автоматов в технической документации лучше использовать для основных объектов, изменение состояния которых в Системе необходимо показать заказчику (например, документ – создан, согласован, утвержден). Также на этапе создания Технического задания системным аналитиком формируется функциональная структура ИС с выделением отдельных подсистем, реализующих определенные функции. РАЗРАБАТЫВАТЬ ПОДСИСТЕМЫ БЕЗОПАСНОСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ В СООТВЕТСТВИИ С ТЕХНИЧЕСКИМ ЗАДАНИЕМ Этап технического проектирования системы обеспечения информационной безопасности заключается в разработке проектных решений по защите автоматизированной системы, технического задания, эскизного и технического проектов, а также рабочей и эксплуатационной документации на проектируемый комплекс защиты. Проектные решения могут базироваться как на основе уже существующих коммерческих средствах защиты, так и на специализированных решениях, разработанных или адаптированных под нужды Заказчика. Технические требования Заказчика к системе защиты, которые, также, могут называться заданием на проектирование, являются тем первичным документом, с которого начинается работа по созданию системы безопасности объекта. Эти требования могут конкретизироваться для каждой стадии проектирования. Технические требования Заказчика достаточно часто оформляются в виде приложения к официальному приглашению для участия в тендере или в торгах на создание системы безопасности. Техническое задание на систему защиты содержит все данные, необходимые для оценки объемов и планирования работ, связанных с последующими стадиями создания системы, и может использоваться Заказчиком в составе конкурсной документации. При разработке технического задания на систему безопасности рекомендуется руководствоваться требованиями и рекомендациями документов ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», ГОСТ 51583-2000 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении», Руководящим документом Гостехкомиссии России «Специальные требования и рекомендации по технической защите конфиденциальной информации». В том случае если Техническое задание разрабатывается на систему или подсистему информационной безопасности, в рамках СУИБ созданной по требованиям ISO 27001 или СТО БР ИББС, то в техническом задании будут учтены требования процессов информационной безопасности и требований и рекомендаций стандартов. При разработке технического задания обязательно учитываются следующие характеристики ИТ систем и работы процессов Заказчика: Критичность защищаемых информационных систем для бизнес-процессов Заказчика; Требования к доступности информационных систем; Количество и квалификация сотрудников Заказчика, осуществляющих эксплуатацию систем Заказчика. ПРОИЗВОДИТЬ РАЗРАБОТКУ МОДУЛЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ В СООТВЕТСТВИИ С ТЕХНИЧЕСКИМ ЗАДАНИЕМ При разработке модуля целесообразно придерживаться следующего порядка: изучение и проверка спецификации модуля, выбор языка программирования; выбор алгоритма и структуры данных; программирование (кодирование) модуля; шлифовка текста модуля; проверка модуля; компиляция модуля. Первый шаг разработки модуля в значительной степени представляет собой смежный контроль структуры программы снизу: изучая спецификацию модуля, разработчик должен убедиться, что она ему понятна и достаточна для разработки этого модуля. В завершении этого шага выбирается язык программирования: хотя язык программирования может быть уже предопределен для всего ПС, все же в ряде случаев (если система программирования это допускает) может быть выбран другой язык, более подходящий для реализации данного модуля (например, язык ассемблера). На втором шаге разработки модуля необходимо выяснить, не известны ли уже какие-либо алгоритмы для решения поставленной и или близкой к ней задачи. И если найдется подходящий алгоритм, то целесообразно им воспользоваться. Выбор подходящих структур данных, которые будут использоваться при выполнении модулем своих функций, в значительной степени предопределяет логику и качественные показатели разрабатываемого модуля, поэтому его следует рассматривать как весьма ответственное решение. На третьем шаге осуществляется построение текста модуля на выбранном способе реализации. Обилие всевозможных деталей, которые должны быть учтены при реализации функций, указанных в спецификации модуля, легко могут привести к созданию весьма запутанного текста, содержащего массу ошибок и неточностей. Искать ошибки в таком модуле и вносить в него требуемые изменения может оказаться весьма трудоемкой задачей. Поэтому весьма важно для построения текста модуля пользоваться технологически обоснованной и практически проверенной дисциплиной программирования. Впервые на это обратил внимание Дейкстра, сформулировав и обосновав основные принципы структурного программирования. На этих принципах базируются многие дисциплины разработки информационных систем, широко применяемые на практике. Наиболее распространенной является дисциплина пошаговой детализации. Следующий шаг разработки модуля связан с приведением текста модуля к завершенному виду в соответствии со спецификацией качества ИС. При программировании модуля разработчик основное внимание уделяет правильности реализации функций модуля, оставляя недоработанными комментарии и допуская некоторые нарушения требований к стилю программы. При шлифовке текста модуля он должен отредактировать имеющиеся в тексте комментарии и, возможно, включить в него дополнительные комментарии с целью обеспечить требуемые примитивы качества. С этой же целью производится редактирование текста программы для выполнения стилистических требований. Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки (использующей выполнение его на компьютере), реализует общий принцип, сформулированный для обсуждаемой технологии программирования, о необходимости контроля принимаемых решений на каждом этапе разработки ИС, наконец, последний шаг разработки модуля означает завершение проверки модуля (с помощью компилятора) и переход к процессу отладки модуля. ОСУЩЕСТВЛЯТЬ ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ НА ЭТАПЕ ОПЫТНОЙ ЭКСПЛУАТАЦИИ С ФИКСАЦИЕЙ ВЫЯВЛЕННЫХ ОШИБОК КОДИРОВАНИЯ В РАЗРАБАТЫВАЕМЫХ МОДУЛЯХ ИНФОРМАЦИОННОЙ СИСТЕМЫТестирование - очень важный и трудоемкий этап процесса разработки информационной системы, так как он позволяет выявить подавляющее большинство ошибок. Процесс разработки предполагает три стадии тестирования: автономное тестирование компонентов; комплексное тестирование разрабатываемой информационной системы; системное или оценочное тестирование на соответствие основным критериям качества. Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы: предполагаемые результаты должны быть известны до тестирования; следует избегать тестирования программы автором; досконально изучать результаты каждого теста; необходимо проверять работу программы на неверных данных; вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания ИС. Существуют два принципиально разных подхода к формированию тестовых наборов – структурный и функциональный. Структурный подход базируется на том, что известны алгоритмы работы системы. В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Для формирования тестов программу представляют в виде графа, вершины которого соответствуют операторам программы, а дуги представляют возможные варианты передачи управления. При структурном тестировании данной части программы необходимо сформировать как минимум пять тестовых наборов таким образом, что бы обойти весь граф. Функциональный подход основывается на том, что алгоритм работы информационной системы не известен. Тесты строят, опираясь на функциональные спецификации. Программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение системы не соответствует требованиям. Для тестирования модулей возможно применение восходящего и нисходящего тестирования. Восходящий подход предполагает, что каждый модуль тестируют отдельно, затем собирают протестированные модули в более крупные модули системы и тестируют их. Так продолжает пока не будет собран весь программный продукт. Данный подход имеет существенные недостатки. Во-первых, при восходящем тестировании серьезные ошибки в функциональности, алгоритмах и интерфейсе могут быть обнаружены только на завершающей стадии работы над проектом. Во-вторых, для того, чтобы тестировать модули нижних уровней, необходимо разработать специальные тестирующие программы, которые обеспечивают вызов интересующих нас модулей с необходимыми параметрами. На этапе тестирования решается задача верификации соответствия реализации требованиям, сформированным на первых двух этапах жизненного цикла ИС. Полную проверку программного продукта гарантирует исчерпывающее тестирование, предполагающее обязательное включение в тесты всех наборов исходных данных, всех вариантов их обработки и большое количество тестовых вариантов. Такая проверка ИС предполагает большое количество тестеров и может занять много времени. Опытные отладчики обнаруживают ошибки путём сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок, шаблонах выходных данных, языке и процессе программирования. Очень важны знания о процессе разработке информационной системы. РАЗРАБАТЫВАТЬ ТЕХНИЧЕСКУЮ ДОКУМЕНТАЦИЮ НА ЭКСПЛУАТАЦИЮ ИНФОРМАЦИОННОЙ СИСТЕМЫ Эксплуатационная документация обычно включает «Руководство системного администратора» и «Руководство пользователя». Если в Системе присутствует несколько основных пользователей, руководство пользователя пишется отдельно для каждого из них. В ГОСТ 2.601 приведено определение эксплуатационного документа: Эксплуатационный документ – конструкторский документ, который в отдельности или в совокупности с другими документами определяет правила эксплуатации (например, руководство по эксплуатации) изделия и/или отражает сведения, удостоверяющие гарантированные изготовителем значения основных параметров и характеристик (свойств) изделия, гарантии и сведения по его эксплуатации в течение установленного срока службы. Где эксплуатация изделия – это стадия жизненного цикла изделия с момента принятия его потребителем от предприятия-изготовителя или ремонтного предприятия до отправки в ремонт или списания. Сведения об изделии, помещаемые в ЭД, должны быть достаточными для обеспечения правильной и безопасной эксплуатации изделий в течение установленного срока службы. При необходимости, в ЭД приводят указания о требуемом уровне подготовке обслуживающего персонала. Виды, комплектность и выполнение (электронное или бумажное) ЭД устанавливает разработчик, опираясь на требования ТЗ и ЕСКД. Состав типового руководства пользователя: Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства; Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется; Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности; Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя; Аварийные ситуации, где описывают действия в нештатных ситуациях сбоях в программе, ошибок в данных и т.д.; Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования. Состав типового руководства системного администратора В системе ЕСПД требования к содержанию и оформлению данного руководства регулируются стандартом ГОСТ 19.503-79. В соответствии с ним, документ должен содержать следующие разделы: Общие сведения о ИС – назначение и функции ИС и сведения о технических и программных средствах, обеспечивающих выполнение данной программы. Структура информационной системы – сведения о структуре ИС, ее составных частях, о связях между составными частями и о связях с другими программами. Настройка системы – описание инструкций по настройке ИС на условия конкретного применения (настройка на состав технических средств, выбор функций и др.). Проверка системы – описание способов проверки, позволяющих дать общее заключение о работоспособности ИС (контрольные примеры, методы прогона, результаты). Дополнительные возможности – описание дополнительных разделов функциональных возможностей ИС и способов их выбора. ПРОИЗВОДИТЬ ОЦЕНКУ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ВЫЯВЛЕНИЯ ВОЗМОЖНОСТИ ЕЁ МОДЕРНИЗАЦИИ Оценка ИС является крайне сложной задачей ввиду многообразия интересов пользователей. Поэтому невозможно предложить одну универсальную меру качества и приходится использовать ряд характеристик, охватывающих весь спектр предъявляемых требований. Наиболее близки к задачам оценки ИС модели качества программного обеспечения, являющегося одной из важных составных частей ИС. В настоящее время используется несколько абстрактных моделей качества программного обеспечения, основанных на определениях характеристики качества, показателя качества, критерия и метрики. Критерий может быть определен как независимый атрибут ИС или процесса ее создания. С помощью такого критерия может быть измерена характеристика качества ИС на основе той или иной метрики. Совокупность нескольких критериев определяет показатель качества, формируемый исходя из требований, предъявляемых к ИС. В настоящее время наибольшее распространение получила иерархическая модель взаимосвязи компонент ИС. Вначале определяется характеристика качества, в числе которых могут быть, например, общая полезность, исходная полезность, удобство эксплуатации. Далее формируются показатели, к числу которых могут быть отнесены: практичность, целостность, корректность, удобство обслуживания, оцениваемость, гибкость, адаптируемость, мобильность, возможность взаимодействия. Каждому показателю ставится в соотвествие группа критериев. Для указанных выше показателей ниже приведены возможные критерии. Надо отметить, что один и тот же критерий может характеризовать несколько показателей. С помощью метрик можно дать количественную или качественную оценку качества ИС. Различают следующие виды метрик и шкал для измерения критериев. Первый тип — метрики, которые используют интервальную шкалу, характеризуемую относительными величинами или реально измеряемыми физическими показателями, например, временем наработки на отказ, вероятностью ошибки, объемом информации и др. Второй тип — метрики, которым соответствует порядковая шкала, позволяющая ранжировать характеристики путем сравнения с опорными значениями. Третий тип — метрики, которым соответствуют номинальная или категорированная шкала, определяющая наличие рассматриваемого свойства или признака у рассматриваемого объекта без учета градаций по этому признаку. Так, например, интерфейс может быть «простым для понимания», «умеренно простым», «сложным для понимания». В случае, когда информационная система имеет довольно высокие качественные оценки, в будущем время ее можно модернизировать. Основное правило модернизирования заключается в том, что при изменении/добавлении в функциях системы не ухудшились ранние показатели. |