Создание информационной системы Этап обследования и анализа Разработал Дубаков А. А.
Обследование и анализ системы n Основная задача - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня и состоит из: n n Обследование системы - Исследование существующей системы для полного понимания ее работы. Технико-экономическое обоснование - Более полный и точный анализ возможностей, особенно по отношению к затратам и доходам. Определение потребностей в информации и требований к системе - Определение информационных потребностей пользователей и целей новой системы Отчет (сообщение) об анализе системы либо формирование состава задач для реализации
n n Этап предполагает тесное сотрудничество с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, требуемая информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
n n Особое внимание уделяется прежде всего на детальное понимание текущей системы, которая документируется со скрупулезной точностью в различных моделях, таких как DFD, диаграмма последовательностей и др. В рамках обследования системы строится ряд моделей, но только достаточных для улучшения нашего понимания масштаба проекта и определения содержания системы.
n По завершении стадии обследования и анализа появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на n аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения). И перейти к этапу проектированию системы
Выполняется уточнение целей системы: n n n n n Полезность производимой информации, Надежность, Доступность, Своевременность получаемой информации, Наличие достаточного мощности, Экономическая эффективность, Гибкость, Безопасность, Управляемость, Улучшение обслуживания клиентов
Задачи обследование системы n n Наладить рабочие взаимоотношения с пользователями ИС; Получить полное понимание операций, выполняемых компанией, ее политики и процедур, потоков данных и информации, сильных и слабых сторон существующей ИС, характеристику имеющегося персонала, используемое программное и аппаратное обеспечение; Сделать предварительную оценку текущих и будущих информационных потребностей компании и определить природу необходимых изменений. Собрать данные, показывающие потребности пользователей, провести технико-экономическое обоснование, сформировать отчет и дать рекомендации руководству.
Выполняется сбор и обзор информации n Первый документ – структура организации. Затем изучается история возникновения проекта. Для выполнения этого, можно собрать и просмотреть документы, которые описывают проблему. Они включают: n n n Взаимодействия между подразделениями (документооборот), обследования, протоколы, предложения, жалобы клиентов и отчеты, которые документируют проблемную область. Бухгалтерские записи, обзор производительности, обзор измерения работ и других запланированных отчетов. Запросы информационных систем – прошлых и настоящих.
Сбор и обзор информации n Изучаются или проектируются документы, описывающие бизнес-функции. Эти документы могут включать: n n n n Цель организации и стратегический план. Изучаются задачи подразделений. Положения фирмы, которые могут накладывать ограничения на любую предлагаемую систему. Стандартные процедуры, должностные инструкции, маршруты выполнения рутинных процессов. Заполненные бланки, которые представляют действительные операции в различных этапов цикла обработки. Образцы картотек или баз данных. Образцы отчетов или экранов ИС.
Сбор и обзор информации Рассматривается документация предыдущих обследований системы и проектов (выходим далеко за рамки Вашего проекта), выполненных аналитиками и консультантами. Документы могут включать: n n n Различные типы блок-схем и диаграмм. Репозитории проектов. Проектную документацию, включая входы, выходы и структуры баз данных. Программную документацию. Инструкции пользователям и руководства по обучению.
Изучение задач n В отношении каждой задачи выявленной на предыдущем этапе собираются сведения: n n n Наименование задачи; сроки и периодичность ее решения; Степень формализуемости задачи; Источники данных, необходимые для решения задачи; Набор параметров и их предельные значения; Порядок корректировки информации; Описание процедуры вычислений показателей и возможные методы контроля; Действующие средства сбора, передачи и обработки информации; Действующие средства и каналы связи; Необходимая точность решения задачи; Трудоемкость решения задачи; Действующие формы представления исходных данных и результатов их обработки в виде документов и экранных форм; Потребители результатов информации по задаче.
Обследование документооборота n Маршруты движения документов n n n n количество документов; место формирования показателей документа; взаимосвязь документов при их формировании; маршрут и длительность движения документа; место использования и хранения данного документа; внутренние и внешние информационные связи; объем документа в знаках.
Установка приоритетов задач n n n По результатам обследования устанавливается перечень задач управления (транзакций или вариантов использования), решение которых целесообразно автоматизировать, приоритеты и очередность их разработки. На этапе обследования следует еще раз классифицировать планируемые функции системы по степени важности. Вспомним один из возможных форматов представления такой классификации - Mu. SCo. W. Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.
Определение информационных потребностей и требований к системе n n На этапе обследования и анализа подробно определяются информационные потребности и документируются требования к системе. Это весьма сложный процесс из-за огромного количества и разнообразия информации, которая требует определения. Часто пользователи заявляют, что сделано то, что они просили, но не то, что им действительно необходимо. Требование – это характеристика или условие, которому должна удовлетворять ИС, а сам процесс формирования, анализа, документирования и проверки требований – разработка требований
Требование к цвету Мне бы хотелось голубой автомобиль n Мы должны быть осторожны, чтобы недооценить 15
n Мы должны быть осторожны, чтобы не переооценить 16 Belvedere by M. C. Escher. 1958 Overview Хотелось бы голубой автомобиль… с кожаными вставками; контроль сцепления; турбокомпрессор; спутниковую навигацию; холодильник; TV; коктейльбар; Джакузи; скорость 200 км/час и 4 литра на 100 км; Он может летать и … и…
Функциональные требования: n n Перечень сервисов, которые должна выполнять ИС, причём они специфицируются, каким образом система реагирует на предопределенные входные данные, как она ведёт себя в определённых состояниях и т. п. В некоторых случаях указывается, что система не должна делать. Таким образом требования определяют поведение системы в различных ситуациях.
Причины сложности выявления требований n n n n Реально большое количество требований и сложность их идентификации, Заказчики не всегда готовы четко сформулировать требования, отчасти потому, что не представляют всех возможностей современных информационных технологий, Требования исходят не только в функциональной области. Требования должны быть сформулированы так, чтобы они однозначно воспринимались заказчиком и исполнителем, Между функциональными требованиями обычно существуют зависимости, усложняющие управление ими в случае необходимости внесения изменений (Хочу, чтобы руки доставали до земли, …). Могут изменяться в течение разработки и при сопровождении. Для преодоления этих трудностей применяется моделирование требований (модель включает актеров и UC, показывает, как система взаимодействует с актерами и что она делает в каждом UC –ООАП, иерархия DFD - САП)
Примеры функциональных требований n n «Система должна быть способна вычислять стоимость международных поставок для всех продуктов» «Система должна автоматически формировать суммарный отчет всех продаж, выполненных в течение недели. » «Система должна обеспечивать резервирование продукции через Интернет» «Система должна поддерживать графический интерфейс взаимодействия»
Нефункциональные требования n n Не связаны непосредственно с функциями, выполняемыми системой. Они отображают такие интеграционные свойства системы, как надёжность, время ответа или размер системы. Могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемые в системном интерфейсе. Не так много, но они существенны Могут относиться к технологическому процессу создания ПО, другие - содержать перечень стандартов качества, накладываемых на процесс разработки
Делятся на три большие группы n n n Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации. Организационные требования. Отображают политику и организационные процедуры заказчика и разработчика ПО. Они включают стандарты разработки программного продукта, требования к реализации ПО (т. е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию. Внешние требования. Учитывают факторы, внешние по отношению к разрабатываемой системе и процессу её разработки. Они включают требования, определяющие взаимодействие данной системы с другими системами, юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в рамках существующего законодательства, а также этические требования.
Примеры нефункциональных требований Показатель Скорость Единицы измерения количество выполненных транзакций в секунду; время реакции на действия пользователя; время обновления экрана гигабайты; количество внешней памяти Простота время обучения персонала; эксплуатации количество статей в справочной системе средняя продолжительность времени между двумя последовательными проявлениями ошибок в Надёжность системе; вероятность выхода системы из строя; коэффициент готовности системы время восстановления системы после сбоя; Устойчивость к процент событий, приводящих к сбоям; сбоям вероятность порчи данных при сбоях Размер
Разработка требований n Процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований: n n Анализ технической осуществимости создания системы, Формирование и анализ требований, Специфицирование требований Создание соответствующей документации, а также аттестация этих требований
Анализ осуществимости n Основой анализа осуществимости является общее описание системы и её назначения, а результатом анализа - отчёт, в котором должна быть чёткая рекомендация необходимости процесса разработки требований проектируемой системы.
Анализ осуществимости n n n Отвечает ли система общим и бизнес-целям организации-заказчика и организацииразработчика? Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости? Можно ли объединить систему с другими системами, которые уже эксплуатируются? n n Определяются источники информации Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе.
Формирование и анализ требований n На этом этапе команда разработчиков ИС работает с заказчиком и конечными пользователями системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и её характеристик выполнения, аппаратных ограничений и т. д.
Формирование и анализ требований n Процесс формирования и анализа требований циклический с улучшением понимания требований с каждом циклом - цикл начинается с анализа предметной области и заканчивается проверкой требований. n n n n Оцениваются области применения, Описываются сервисы системы, Определяются режимы работы системы и её характеристики выполнения, Аппаратные ограничения и т. д. Не существует универсального подхода Широко применяется прототипирование и методология RAD
Традиционные способы выявления требований и ограничений n Интервьюирование заказчиков и экспертов в проблемной области n n n Анкетирование n n n структурированное (формальное) неструктурированное (неформальное) Многоальтернативные вопросы. Рейтинговые вопросы Вопросы с ранжированием Наблюдение Изучение документов и программных систем
Достоинства и недостатки методов сбора данных о системе Интервью Анкетирование Достоинства Отвечает на вопрос “почему”. Помогает строить позитивные отношения с работниками. Вопросы могут углубляться и проясняться. Может быть анонимным. Не отнимает много времени. Дает время на обдумывание ответов. Недостатки Большие затраты времени. Пристрастность порождает неверную информацию. Не позволяет углублять и прояснять вопросы. Трудно разработать. Часто игнорируется или заполняется формально. Наблюдение Помогает определить, как Требует времени. система работает на самом деле. Трудно интерпретировать Дает большее понимание результаты. системы. Люди под наблюдением меняют поведение. Документация о Описывает, как система Требует времени. системе должна работать Может быть недоступна Письменная форма упрощает или просто не анализ. существовать.
Аттестация требований n n Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик Проверка требований важна, так как ошибка в спецификации требований могут привести к переработке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию.
Критерии для определения требований системы n Согласованность (Consistent) не противоречивы и не двусмысленны n n Полнота (Complete) все возможные входы и отклики системы Осуществимость ( Feasible) могут быть удовлетворены на основе доступных ресурсов и ограничений n Необходимость (Required) действительно необходимы и удовлетворяют целям системы n n Точность (Accurate) установлены верно Пригодность для контроля (Traceable) непосредственно отображаются на функции и возможности системы n Проверяемость (Verifiable) могут быть продемонстрированы во время тестирования 31
Управление требованиями n n n Требования неизбежно будут изменяться в процессе разработки Процесс управления изменениями системных требований и должен начаться сразу после создания черновой версии спецификации требований. После согласования требование включается в соответствующие модели и реализуется в программном обеспечении (UC, последовательностей и т. п. ). Для каждого запроса на изменение необходимо создавать формальный бизнес-прецедент. В идеале, изменения требований должны храниться и отслеживаться с помощью средств конфигурационного управления ПО.
Формируется словарь данных n n Словарь данных - определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и элементов хранилищ в DFD или диаграмме деятельностей. Показывает какие данные преобразуются различными процессами.
Виды описаний словаря n n n Описание значений потоков и хранилищ, изображенных на DFD или диаграмме последовательностей; Описание композиции агрегатов данных, движущихся вдоль потоков, т. е. комплексных данных, которые могут расчленяться на элементарные символы (например, АДРЕС ПОКУПАТЕЛЯ содержит ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ и т. д. ); Описание композиции групповых данных в хранилище; Специфицирование значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах; Описание деталей отношений между хранилищами.
Содержимое словаря данных n n Для каждого потока данных в словаре необходимо хранить имя потока, его тип и атрибуты. По типу потока n простые (элементарные) или групповые (комплексные) потоки; n внутренние (существующие только внутри системы) или внешние (связывающие систему с другими системами) потоки; n потоки данных или потоки управления; n непрерывные (принимающие любые значения в пределах определенного диапазона) или дискретные (принимающие определенные значения) потоки.
Композиции данных
Атрибуты потока данных n n n n Имена-синонимы потока данных в соответствии с узлами изменения имени; Составляющие группового потока; Единицы измерения потока данных; Диапазон значений для непрерывного потока, типичное его значение и информацию по обработке экстремальных значений; Список значений и их смысл для дискретного потока; Список номеров диаграмм различных типов, в которых поток встречается; Список потоков, в которые данный поток входит; Комментарий, включающий дополнительную информацию (например о цели введения данного потока).
БНФ-НОТАЦИЯ n n БНФ-нотация (нотация Бекуса-Наура) позволяет формально описать расщепление/объединение потоков. Поток может расщепляться на собственные отдельные ветви, на компоненты потока-предка или на то и другое одновременно. При расщеплении/объединении потока существенно, чтобы каждый компонент потока-предка являлся именованным. Если поток расщепляется на подпотоки, необходимо, чтобы все подпотоки являлись компонентами потока-предка. Точные определения потоков содержатся в словаре данных, а не на диаграммах.
БНФ-НОТАЦИЯ- синтаксис n n n n @БНФ=<простой оператор>!<БНФ-выражение >, где <простой оператор> есть текстовое описание, заключенное в “/”, а <БНФ-выражение> есть выражение в форме Бэкуса-Наура, допускающее следующие операции отношений: = означает “композиция из”, + означает “И”, [!] означает “ИЛИ” () означает, что компонент в скобках необязателен, {} означает итерацию компонента в скобках, “ “ означает литерал.
БНФ-НОТАЦИЯ- синтаксис n n n Итерационные скобки могут иметь нижний и верхний предел, например: 3{болт}7 от 3 до 7 итераций 1{болт}1 и более итераций {шайба}3 не более 3 итераций Пример описания потока данных с помощью БНФ: @ИМЯ=ВОСЬМЕРИЧНАЯ ЦИФРА @ТИП=дискретный поток @БНФ=[ "0"!"1"!"2"!"3"!"4"!"5"!"6"!"7" ] @ИМЯ= ПРОТОКОЛ ОБСЛУЖИВАНИЯ @ТИП= дискретный поток @БНФ= (ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ)+ (ДЕНЕЖНАЯ СУММА)+ (ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА)
Управляющий поток n n n Управляющий поток (УП) - это объект расширения DFD для реального времени, который представляет собой поток, через который проходит управляющая информация. На диаграммах изображается прерывистой линией. Имя УП представляет существительные и прилагательные, обычно имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции. Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемых ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды. При этом режим выполнения процесса зависит от типа управляющего потока.
типы управляющих потоков n Т-поток (trigger flow). Является потоком управления процессом, который может вызывать выполнение процесса. При этом процесс как бы включается одной короткой операцией. Это - аналог выключателя света, единственным нажатием которого "запускается" процесс горения лампы. n A-поток (activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток "включен" (т. е. течет непрерывно), с "выключением" потока выполнение процесса завершается. Это - аналог переключателя лампы, которая может быть как включена, так и выключена. n E/D-поток (enable/disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по E-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это - аналог выключателя с двумя кнопками: одной - для включения света, другой - для его выключения. Отметим, что можно использовать 3 типа таких потоков: E-поток, D-поток, E/D-поток.
Узел преобразования потоков n Иногда возникает необходимость в представлении одного и того же фрагмента данных потоками различных типов. Например, поток данных Скорость автомобиля в отдельных случаях может использоваться как управляющий для контроля критического значения. Для обеспечения этого используется Узел изменения типа : поток данных является входным для этого узла, а управляющий поток - выходным.
Детализация модели требований n n Выполняется декомпозиция задач и строится диаграмма потока данных Процесс - последовательность шагов (задач), которым необходимо следовать для выполнения бизнес-функции. Для каждого процесса моделируются требуемые входящие данные и все выходящие результаты Что в какой последовательности моделируется, в общем случае, не принципиально (данные или процессы)
Для ООА n n n Разбивается каждый шаг в описании варианта использования на одну или более элементарные активности и моделируется поток процессов каждого варианта диаграммой деятельности (в нормальной последовательности событий) Моделируются все выявленные варианты исключительных ситуаций и возможности ответвления для каждой активности (полный набор событий). Для каждой активности моделируются требуемые входящие объекты и данные, плюс все выходящие результаты (объекты и состояния объектов).
Последовательность операций Нормальные события I С исключит. ситуациями
Последовательность операций Для каждого действия моделируются необходимые входящие объекты и данные плюс полученные результаты (объекты и состояния объектов) Диаграмма деятельности (Activity) трансформируется в диаграмму потока объектов. Когда определяются входящие и выходящие объекты полезно сначала пройти транзакции по порядку и установить в каждом случае какие объекты генерируются или модифицируются.
Цели выполнения процедуры детализации требований n n n выявление из вариантов использования фрагментов, которые могут рассматриваться как отдельные. Примерами таких частей могут быть общие фрагменты, необязательные фрагменты и исключения; обнаружение новых абстрактных актеров, которые играют роли, разделяемые несколькими актерами; реструктуризация модели требований; детальное описание потоков событий для варианта использования; определение приоритетов и трудоемкости вариантов использования.
Проектирование интерфейса n n Выполняется для того, чтобы заказчик смог более точно представить себе работу и возможности будущей ИС, а также представить свои замечания и уточнения требований. Для каждого прецедента описывается вариант интерфейса, т. е. комбинация входных и выходных данных, объектов и событий для создания описания интерфейса. n Наименование интерфейса; n короткое описание 2 -10 строк текста; n степень сложности интерфейса (сложный| стандартный| простой).
n Для любого из способов представления проекта интерфейса следует для каждого прецедента описать вариант интерфейса: n n n комбинация входных и выходных данных, объектов и событий для создания описания интерфейса. Очевидно, что интерфейс не обязательно может быть графический и направлен на взаимодействие с пользователем системы.
Детали интерфейсов (функциональных и данных) Должны быть документированы, если уже известны: n Номенклатура внешних систем (имена программ, имена транзакций, и т. д. ); n Тип интерфейса: синхронный (функциональный интерфейс), асинхронный (изменение данных, например через файлы, таблицы и запросы баз данных); n Направление интерфейса: чтение, запись; n Частота выполнения и, если применимо, распределение по времени в день, например, один раз в день, примерно 100 раз в день и т. п. ; n Максимальный, минимальный и средний объем данных за одно обращение (в байтах); n Важность интерфейса (важный | стандартный| вторичный); n Возможные контакты партнеров, ссылки, документы и т. п. ; n Особенности.
Пользовательский интерфейс n n Пользовательский интерфейс также может являться частью спецификации требований Макет экрана не заменит пользовательских и функциональных требований. Разработчики не смогут сделать вывод о базовой функциональности и взаимосвязи данных по моментальным снимкам экрана. Изучение возможных пользовательских интерфейсов (таких, как рабочий прототип) делает требования более осязаемыми и для пользователей, и для разработчиков. Подсчет элементов графического интерфейса пользователя (graphical user interface, GUI) или числа функциональных точек (function points), связанных с каждым экраном, позволяет оценить размер проекта и, следовательно, затраты на реализацию.
Диалог и вывод системы n n n Кто использует диалог/вывод (количество, квалификация, и т. п. ); Когда и как часто используется диалог/вывод (постоянно, в среднем на пользователя, распределение в течение дня, дней в неделю, месяцев, и т. п. ), например, раз в день, примерно 100 раз в день и т. п. ; Важность интерфейса (важный | стандартный| вторичный); Возможные контакты партнеров, ссылки, документы и т. п. ; Особенности.
Результаты проекта интерфейса n В зависимости от сложности и согласования с заказчиком: n n n программная реализация, воспроизводящая точный вид экранных окон; альбом экранных форм; модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций – кнопок.
Пример: Диалог резервирования n n n n Короткое описание: Этот диалог позволяет зарезервировать автомобиль для клиента Пользователи: Все пользователи офиса, в среднем 25 раз в день на пользователя, в основном с 8 до 10 утра. Сложность: Стандартная Входные поля: Тип автомобиля, место получения, место возврата, период аренды (DD. MM. YYYY HH) Отображаемы поля: Данные резервирования (автомобиль, номер аренды, тип автомобиля, место получения, место возврата, период аренды (DD. MM. YYYY HH)) Возможности переключения : Отказаться, Завершить, Посмотреть данные о клиенте Действия: Проверить доступность автомобиля, Зарезервировать автомобиль, Напечатать квитанцию, Отказаться от резервирования
Возможно приготовить диалог для изучения
Терминология для проектирования GUI n n n n Диалог (Dialog): Определенное окно, с которым пользователь взаимодействует, и которое не является главным окном UI. Элемент управления (Control или Widget): Определенный компонент пользовательского интерфейса. Действие (Affordance): Набор операций, которые пользователь может предпринять в каждый данный момент времени. Состояние (State): Некоторый этап диалога, в котором система показывает определенную информацию в определенных элементах управления и ожидает определенных действий. Режим (Mode): Ситуация, в которой UI ограничивает действия пользователей. Модальный диалог (Modal dialog): Диалог, в котором система находится в исключительно ограниченном режиме. Обратная связь (Feedback): Ответ системы на действия пользователя. Техника кодирования (Encoding techniques): Способ кодирования информации для взаимодействия с пользователем. 57
Размещение и связь по сети n На этапе выполнения анализа следует рассмотреть: n n количество и расположение мест использования системы; требования обработки и доступа к данным и процессам в различных местах; объем и расписание обработки и запросов доступа данных. И принимаются решения: n n n Распределение подсистем ИС и программных приложений. Распределение компонент базы данных. Пропускная способность сети.
n Для получения необходимой информации о размещении элементов системы необходимо идентифицировать места, где должны выполняться автоматизированные бизнес-процессы. Матрица распределения операций с данными
Состав требований 1. 2. 3. 4. 5. Процессы - Описание всех процессов в новой системе, включая что и кем должно делаться Элементы данных- Описание элементов данных, включая имена, форматы, источники и предназначение Структуры данных - Предварительные структуры данных, показывающие, как элементы данных будут организованы в логических записях Выходы - Образцы выходных документов с объяснением их назначения, частоты использования, для кого они делаются Входы - Образцы первичных документов (по возможности с GUI интерфейсом) и объяснение их содержания, источников и ответственных за них лиц
Состав требований (прод. ) 6. 7. 8. 9. Документация - Описание, как новая система и ее подсистемы должны работать Ограничения - Описание таких ограничений, как сроки выполнения работ, меры безопасности, ограничения в кадрах и др. Контроль - Описание мер контроля, позволяющих гарантировать точность и надежность входов, выходов и обработки данных Реорганизация - Требуемые реорганизационные меры - увеличение или сокращение штатов, добавление новых функций, создание подразделений
Завершение этапа анализа n n Системные аналитики используют различные инструментальные средства проектирования (IDEF 0, DFD и ERD, модели ООА) для анализа и спецификации того “что” система должна делать. Это логическая модель системы Логическая модель завершается составлением на основе всех добытых во время анализа сведений в сложный документ под названием Спецификация требований (Requirements Specification). – указываются функции и возможности, которыми должно обладать новое программное обеспечение, а также необходимые ограничения. На этой стадии не имеют значения физические характеристики системы.
Заинтересованные категории n n n n n Клиенты - представление о конечном продукте; Менеджеры проекта - рассчитывают графики, затраты и ресурсы; Команда разработчиков ПО - представление о создаваемом продукте; Группа тестирования составляет планы тестирования, варианты использования и процедуры; Специалисты по обслуживанию и поддержке получают представление о функциональности каждой составной части продукта; Составители документации создают руководства для пользователей и окна справки на основании спецификации требований к ПО и дизайна пользовательского интерфейса; Специалистам, ответственным за обучение персонала, необходима спецификация требований к ПО и документация для пользователей для разработки обучающих материалов; Персонал, занимающийся юридической стороной проекта, проверяет, соответствуют ли требования к продукту существующим законам и постановлениям; Субподрядчики строят свою работу и несут юридическую ответственность также согласно спецификации требований к ПО.
1. Пример 2. Содержим 3. ого Request for proposal 4. 5. 6. 7. Ведение и предыстория A. Описание организации B. Обзор бизнеса Обзор потребностей A. Описание бизнес требований B. Ожидаемый выигрыш C. Обзор системных требований Описание технологических требований A. Среда функционирования B. Требования производительности C. Интеграция, интерфейсы и совместимость D. Спецификация АО E. Расширение и развитие требований F. Поддержка требований Описание функциональных требований A. Спецификация основных функций B. Спецификация выводов информации C. Спецификация пользовательского интерфейса D. Идентификация дополнительных функций и улучшений Описание общих требований A. Сопровождение и поддержка B. Документация и обучение C. Будущее развитие системы Предложение об исполнителях проекта A. Запрос исполнителей Детали представления пропозала A. Временные требования B. Результаты требований C. Критерии и процесс оценки D. Ожидаемый график оценки 64 E. Методы оценки технологических, функциональных и общих требований
Техническое задание n n Результаты обследования представляют объективную основу для формирования т. н. технического задания на информационную систему. Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
Состав задач ТЗ (/ACCESS/tz. doc) n n n n Установить общую цель создания ИС, определить состав подсистем и функциональных задач; Разработать и обосновать требования, предъявляемые к подсистемам; Разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных); Установить общие требования к проектируемой системе; Определить перечень задач создания системы и исполнителей; Определить этапы создания системы и сроки их выполнения; Провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Относительная стоимость исправления ошибок Фаза в которой найдена Коэффициент стоимости Требования 1 Проект 3 -6 Программирование 10 Тестирование разработки 15 -40 Тестирование приемке 30 -70 Функционирование 40 -1000 67
Последствия некорректных требований n n n Стоимость превышает проектную. Система сдается с опозданием. Система не удовлетворяет надежд пользователей, что может быть причиной ее саботажа. После внедрения стоимость поддержки и модернизации системы может быть исключительно высокой. Система может быть ненадежной и подвержена ошибкам и простоям (downtime). Репутация штата ИТ подорвана в результате неудачи. 69
Подготовка отчета n n В отчете суммируются и документируются все проделанные шаги и он служит источником информации для разработки системы. Решение о продолжении работ принимается по крайней мере три раза: n n n после начального исследования, после ТЭО, и после завершения всего анализа системы
Скачать презентацию Создание информационной системы Этап обследования и анализа Разработал
04ebc7096edf8a520e4a4e3c50e55f16.ppt