технология проектирования ИС. Реферат на тему _Технологии проектирования ИС_. Лекция Технологии проектирования ис 1 Основные определения
 Скачать 0.49 Mb.
|
|
Подготовленные требования подлежат обсуждению с заинтересованными сторонами - пользователями и менеджерами и подписываются руководством, если достигнуто согласие. Для обеспечения такого обсуждения часто подготавливается описательный документ “нетехнического” характера. 3.2.5. Подготовка отчета Анализ системы завершается подготовкой отчета, который суммирует и документирует все проделанные шаги и служит источником информации для разработки системы. Решение о продолжении работ принимается по крайней мере три раза: После начального исследования, после исследования возможностей и после завершения всего анализа системы. Разработчики новой системы часто испытывают давление со стороны руководства компании, которое вынуждает их пропускать этап анализа системы и сразу приступать к написанию программ. В больших и сложных организациях это практически всегда приводит к появлению дорогой системы, которая не нужна ее пользователям и поэтому отторгается. 3.3. Концептуальная разработка Фаза концептуальной разработки ИС предназначается для реализации требований пользователей и решения других проблем, обнаруженных на этапе анализа системы. В какой-то момент во время концептуальной разработки должно быть принято решение о выборе между покупкой и разработкой программного обеспечения. 3.3.1. Оценка альтернатив Существует много способов реализации различных компонентов ИС, поэтому ее разработка сопровождается рядом решений по выбору. Примеры приведены в таблице 3.5. Таблица 3.5. Альтернативы для некоторых компонентов ИС
Группа разработчиков должна определить возможные альтернативы и оценить каждую из них по отношению к тому, как хорошо они удовлетворяют целям организации и системы (1), как они удовлетворяют потребности пользователей(2), являются ли они экономически осуществимыми (3), какими достоинствами и недостатками они обладают (4). Окончательное решение по выбору должен принимать руководящий комитет. 3.3.2. Подготовка спецификаций и отчета После выбора альтернатив разработки группа разработчиков определяет концептуальные спецификации для таких элементов как: выходы. Поскольку система разрабатывается для удовлетворения нужд пользователей, работа начинается с определения спецификаций выходов системы, которые для каждого производимого отчета включают: частоту его использования (ежедневно или еженедельно), его содержание, внешнего вида, на каком носителе предоставляться (экранная или твердая копия); хранение данных. Описывается структура данных: последовательный или прямой доступ, файловая организация или база данных, размеры и типы полей; входы. Какие данные должны вводиться, где, когда и как данные должны собираться; процедуры обработки. Как обрабатывать введенные и хранящиеся данные для получения необходимых отчетов. Также определяется частота и последовательность обработки. Предусматриваются процедуры контроля, аудита и обеспечения безопасности. В заключение группа разработчиков готовит отчет о концептуальной разработке, который будет использован: как руководство на этапе физической разработки(1), для оценки, насколько удовлетворены требования пользователей(2), и чтобы помочь руководящему комитету оценить ход работ(3). Главное его содержание - полное описание спецификаций одного или нескольких предлагаемых вариантов. Окончательный выбор варианта ложится на плечи руководящего комитета. 3.4. Физическая разработка На этапе физической разработки широкие, ориентированные на пользователя концептуальные требования к ИС переводятся в детальные спецификации, которые затем используются для программирования и отладки программ. 3.4.1. Разработка выходов Цель этого этапа - определить назначение, формат, содержание, расписание, в соответствии с которыми будут создаваться отчеты, выходные документы и экранные формы. Вот некоторые наиболее важные вопросы разработки выходных документов: использование (кто, почему и для принятия каких решений нуждается в отчетах), носитель (бумага, бланк, экран, голос, файл и т.п.), формат (таблица, текст, график), адресат (место назначения), доступ (кто имеет право знакомиться), детализация (определяет объем объяснений), расписание (в какое время производить). Как правило выходы принадлежат одной из следующих категорий: Регулярные отчеты имеют заранее определенное содержание и формат и готовятся регулярно. Например, ежемесячный отчет о производительности, еженедельный отчет о продажах, ежегодный финансовый отчет. Специальный анализ не имеет заранее определенной структуры и готовится по запросам руководителей. Например, это может быть ответ на вопрос, какой из трех новых продуктов приносит наибольшую прибыль? Отчеты о необычных обстоятельствах имеют заранее определенное содержание, но готовятся только в ответ на необычные условия. Примеры: отсутствие на рабочем месте большого количества служащих, превышение затрат, недостаток материально- производственных запасов. Отчеты по требованию имеют предопределенное содержание и формат, но готовятся только по требованию. Всякий разработанный на этом этапе отчет должен быть подвергнут оценке пользователей, чтобы гарантировать его полноту, актуальность и полезность. 3.4.2. Разработка файлов и базы данных Основные задачи этого этапа - моделирование данных и создание базы данных. При этом окончательно решаются вопросы о носителе данных (жесткий, гибкий, оптический диск или магнитная лента), об организации доступа (прямой, последовательный, индексно-последовательный), о режиме обработки (пакетный или в реальном времени), о процедурах эксплуатации; оцениваются ожидаемые размеры файлов, скорость их обработки, процент ежегодного обновления записей и другая динамика базы данных. Очень важно на этом этапе позаботиться о совместимости форматов данных с уже созданными и работающими ИС компании, а может быть и других организаций. В противном случае в будущем могут возникнуть проблемы интеграции баз данных. 3.4.3. Разработка входов Задача этапа - полностью определить входные данные и оптимальные методы их ввода. Здесь рассмотрению подлежат: способ ввода каждого документа (клавиатура, сканер торгового терминала, OCR - устройство распознавания символов, голос), источник (где данные появляются), формат (первичный или оборотный документ, экранная форма), тип данных, оценка объема, частоты и затрат на ввод данных, требования к подготовке обслуживающего персонала, необходимые меры контроля ошибок и их исправления. Все большее распространение в ИС получает использование автоматизированного ввода, основанного на оборотных документах с последующим их сканированием. Поэтому на этапе разработки входов проектируются формы таких документов. Вот некоторые принципы их разработки: данные, которые могут быть заранее определены, должны встраиваться в документ сразу, а не заполняться (название компании, нумерация, текущий год); выделение линиями, шрифтом, цветом или штриховкой различных частей документа; логичная группировка данных по частям документа; ясные инструкции по заполнению; подбор размера, цветов, толщины и плотности бумаги для облегчения работы с документом и т.д. Если используется ввод с клавиатуры, то большое значение приобретает разработка экранных форм, которая позволяет обеспечить ускорение ввода данных и избежать возникновения ошибок. Приведем некоторые правила: ввод данных осуществляетсяв том же порядке, в котором они появляются на исходном документе; минимизация ввода данных (например, автоматический вывод названия по номеру счета или табельного номера по фамилии работника); заполнение слева направо и сверху вниз; ограничение количества данных в одном кадре; автоматическая проверка правильности ввода (например, сверка почтового индекса и названия города) и т.д. 3.4.4. Разработка программ и процедур Разработка программ - наиболее длительный этап во всем цикле разработки ИС. Этой работой всегда занимаются специалисты по программированию, и здесь существует своя специфика - планирование разработки, выбор инструментальных средств и языка программирования, распределение обязанностей в группе разработчиков, использование различных методик разработки программ, неизбежный этап отладки отдельных программ и программной системы в целом. Процесс разработки программ должен быть тщательно спланирован, разбит на параллельные процессы (обычно это разработка подсистем) и этапы подготовки программной системы в целом (исследовательский и испытательный, прототипы, рабочая версия), когда эксперты группы разработчиков могут оценить ход и направление проводимых работ. Основная цель проектирования программного обеспечения - в определении автономных, независимых модулей. Степень независимости модуля обратно пропорциональна количеству элементов данных (или соединений), образующих поток между модулем и остальной частью системы. Следовательно, акцент этого шага должен быть сориентирован на увеличение независимости модулей, выявляя и реструктуризируя модули с чрезмерными потоками данных. Вторая цель проектирования состоит в том, чтобы определить взаимосвязанные модули, которые исполняют одну законченную функцию. Акцент этого шага состоит в объединении модулей, которые исполняют общую функцию, объединяя функции для уменьшения количества интерфейсов, перемещая модули для увеличения эффективности системы. С использованием результатов предыдущих двух шагов готовится заключительная версия диаграммы структуры программного обеспечения. В завершение этапа проектирования программного обеспечения выполняется анализ преобразования, целью которого является группирование вместе модулей (или процессов), которые обрабатывают определенный набор данных или определенную структуру данных. Например процессы, которые принимают данные по учету движения материально-производственных запасов, изменяют уровень запасов и изменяют данные по общей структуре запасов, вероятно, связаны. Прежде всего, для модулей определяются вход, выход и преобразование (модификация данных) и координация (управление). Группирование модулей для формирования структуры управления может вовлекать обозначение одного модуля как управляющего или создание нового управляющего модуля. Зависимые модули называются подчиненными. Далее выполняняется операционный анализ, цель которого состоит в том, чтобы сгруппировать все модули (или процессы) вызванные одной операцией для формирования операционного центра. Например, все задачи, выполняемые при получении заказа от поставщика, связаны между собой. Часто центр управления представляет собой модуль управления. На основании выполненного проекта программного обеспечения разрабатываются физические модули, сгруппированные для эффективного выполнения на компьютере. Часто выполняется процедурный анализ для определения процедур, которые должны быть сгруппированы в пределах одного модуля, чтобы избежать серьезных ошибок выполнения и/или испытаний. Управлению процессом разработки программ следует уделять самое серьезное внимание. В этой связи для каждой задачи должна быть вычислена оценка длительности разработки следующим образом: оценивается минимальное количество необходимого времени на выполнение задачи – OT. Эта величина подразумевает отсутствие задержек и прерываний в разработке задач, например, таких как болезни; оценивается максимальное количество необходимого времени на выполнение задачи - PT, в предположении, что случается все, что может случиться плохого; устанавливается наиболее вероятное время – MLT- необходимое для выполнения задачи. Тогда ожидаемое продолжительность задачи – ED - можно определить по следующей формуле: ED=(OT+(4xMLT)+PT)/6. Эта формула обеспечивает взвешенное среднее различных оценок. Процедуры - это функциональные режимы по эксплуатации системы. Они должны обеспечивать вопросы подготовки ввода данных, обработки операций, обнаружения и исправления ошибок, выверку балансов, доступ к базе данных, подготовку и предоставление отчетов, инструкции оператора ЭВМ. Процедуры могут принимать форму руководств по системе, инструкций пользователя, обучающих материалов, кадров подсистемы помощи. Они могут готовиться как группой разработчиков, так и пользователями системы. 3.4.5. Разработка методов контроля и подготовка отчета Без обеспечения качественных, точных и корректных данных на входе системы, а также надежной и правильной их обработки получаемый на выходе ИС результат не будет полезным, а может даже оказаться вредным. Методы контроля предназначены для обеспечения целесообразности, эффективности и точности обработки данных, предотвращения ошибки, обнаружения и исправления их в момент появления. В выработке методов контроля большую роль играют специалисты предприятия - менеджеры и особенно бухгалтеры, т.к. именно они до тонкостей представляют себе деятельность фирмы и в состоянии определить мероприятия, обеспечивающие эффективный контроль за данными. Вот наиболее важные аспекты контроля. Законность. Например, как ИС может убедиться, что денежные выплаты вносятся на правильные счета? Авторизация. Действительно ли деятельность по вводу, обработке, сохранению и выводу информации производится не посторонними, а уполномоченными людьми? Точность. Проверяются ли вводимые данные на точность? Какие меры принимаются, чтобы обеспечить обработку данных без потерь? Доступ. Как предотвращается незаконный доступ к данным? Нумерация. Перенумерованы ли документы, чтобы предотвратить ошибочное или намеренное их использование в посторонних целях и чтобы своевременно обнаруживать пропажу или кражу документов? Возможность проверки. Могут ли данные операций быть прослежены от первичных документов до окончательного вывода (и наоборот)? По окончании физической разработки готовится отчет, который служит базовым документом для принятия руководством ответственного решения о начале фазы внедрения. 3.5. Внедрение Внедрение системы - это процесс установки аппаратного и программного обеспечения и начало реальной работы ИС. 3.5.1. Планирование внедрения В плане внедрения указываются мероприятия по внедрению, для каждого из которых определены ожидаемые даты завершения, оценки затрат и ответственные исполнители. Выполнение плана внедрения контролируется руководящим комитетом. Группа, занимающаяся внедрением, должна определить факторы риска, понижающие вероятность успешного внедрения, и план должен содержать меры или стратегию по блокированию каждого такого фактора. Например, один из таких факторов состоит в том, что изменения в ИС могут потребовать и изменений в существующей организационной структуре компании. Может понадобиться создание новых подразделений, а существующие могут ликвидироваться за ненадобностью или сокращаться в размерах. Как правило, изменяются структура и статус отдела, занимающегося обработкой данных. 3.5.2. Безопасность Цель безопасности состоит в том, чтобы защитить аппаратные средства ЭВМ, программное обеспечение, данные и другие ресурсы системы от неавторизованного, некорректного или нежелательного доступа, использования, модификации или воровства. В традиционной информационной системе, построенной на основе централизованной универсальнй ЭВМ компьютер и большинство периферии расположены в помещениях ограниченного доступа. Взаимодействие большого числа пользователей и физически небезопасной периферии, кабелей, линий связи и пунктов доступа делает современные системы соблазнительной целью. Интернет усложняет эту проблему. Угрозы безопасности Предмет безопасности рассматривается, если стоимость нарушения безопасности превышает ценность этого предмета. Совершенная информационная безопасность системы может представлять собой недостижимую цель. Нарушения могут быть получены от людей, аппаратных средств ЭВМ и/или программного обеспечения. |