|
Теория
Системный анализ
Проектирование
Реализация
Тестирование
Внедрение
Теория
- Информационная
система -- это система работы с
информацией.
- Система
-- это совокупность взаимосвязанных компонент, работающих
как единое целое.
- Информация
-- это то, что подправляет и корректирует наши знания. (Шкурба)
- Предметная
область -- это часть реального мира, которую затрагивает
информационная система.
Часто термин
"информация" подразумевает понятие "данные".
Это не совсем так. Информация получается из данных, если над ними
произведена некоторая обработка, повышающая их ценность. На основе
информации принимаются управленческие решения. Например, выпуск
продукции за последний год -- это данные, а построенный по этим
данным график, показывающий рост производства, -- это информация.
| Данные |
Информация |
Месяц |
Выпуск
продукции,
млн. руб. |
 |
| Январь |
1200 |
| Февраль |
1252 |
| Март |
1310 |
| Апрель |
1305 |
| Май |
1350 |
| Июнь |
1340 |
| Июль |
1366 |
| Август |
1408 |
| Сентябрь |
1415 |
| Октябрь |
1430 |
| Ноябрь |
1460 |
| Декабрь |
1510 |
Данные бывают
разных уровней. Например, данные по выпуску продукции за месяц складываются
по каждому виду продукции, т.е. это уже агрегированные данные. На
каком-то уровне агрегации за бездушными цифрами данных начинает
проявляться информация, имеющая некоторую познавательную ценность.
Любая информационная
система включает некоторую базу данных, так как,
чтобы работать с информацией, нужно работать с данными. Данные --
это более низкий уровень агрегации и сопоставления, информация --
более высокий.
Информация:
- всегда связана
с какими-либо данными;
- широко распространена,
находится повсюду;
- может зависеть
от контекста, а может и не зависеть;
- может генерироваться
людьми, компьютерами, другими машинами;
- легко воспринимается
и легко передается;
- как правило,
статична;
- может быть
легко взаимосвязана с другой информацией;
- обладает
стоимостью, необходимой на создание и поддержку;
- в принципе
может использоваться кем угодно и когда угодно.
Знания:
- имеют отношения
к данным и информации, но не всегда с ними связаны;
- дефицитны,
их непросто добывать;
- всегда связаны
с каким-то контекстом, существуют в его рамках;
- генерируются
только людьми;
- трудны для
восприятия;
- динамичны;
любые знания обладают своей скоростью передачи и восприятия;
- для успешного
восприятия требуют четких границ их понимания;
- могут быть
очень дороги, цена при этом не фиксирована;
- обладают
сроком и целью использования.
Информационные
системы бывают разных масштабов: индивидуальные, коллективные, масштаба
предприятия, корпорации, отрасли, города, региона, страны, континента,
планеты.
- Формализация
-- это перевод информации с естественного языка в более четкий.
- Языки с разным
уровнем формальности:
- естественный
язык (русский, английский)
- графика,
диаграммы, схемы
- языки программирования
- математика
Существует
разные классификации систем:
по
размеру: малые, большие;
по
сложности: простые, сложные;
Малая
система -- это вовсе не значит, что простая, а большая система --
это не значит, что сложная.
-
Эмерджентность
-- появление новых функций и свойств у системы, которых
не было у ее компонентов.
- Эмерджентность
-- основное свойство любой системы. Отдельный глаз не видит, он
функционирует только в системе "человек"; отдельный
руль "не рулит", кроме как в системе "автомобиль",
хотя отдельное колесо катится. (?)
Системный анализ
- Системный
анализ -- это метод исследования
предметной области с помощью системного подхода.
В начале проектирования
любой информационной системы следует пройти через следующие этапы:
Определение
требований
Начинать обследование
предметной области следует с определения требований. Одновременно
нужно выяснить истинные потребности пользователей, так как не всегда
пользователи требуют то, что им действительно нужно. См. ниже Выяснение проблем заказчика.
При разработке
продукта для рынка требования определяет разработчик. В этом случае
повышается вероятность промахнуться с определением требований.
Самая
страшная ошибка при разработке ПО -- сделать никому не нужную
программу --
не разобраться в требованиях.
Свойства
требований:
- ясность,
однозначность;
- приоритет;
- источник
(пользователь, документ...);
- непротиворечивость
другим требованиям;
- стабильность
(или, наоборот, вероятность изменения);
- проверяемость.
Очень опасно
пропустить какие-либо требования. Некоторые моменты для пользователей
кажутся естественными и поэтому умалчиваются. Аналитики не телепаты
и читать мысли не умеют. Для анализа полноты требований и их скорейшего
уточнения нужно построить логическую
модель предметной области. Также можно
использовать метод прототипа.
Чем
раньше будет найдена ошибка, тем дешевле и легче ее исправить.
Некоторые требования
имеют характер ограничений, т.е. обязательны к выполнению. Ограничения
внутри предприятия называются деловыми правилами. Они
могут вытекать из характера предметной области или складываться
исторически. Включение деловых правил в программу снижает ошибки
пользователей и следовательно повышает надежность системы.
Изменение требований
в процессе разработки и использования ПО -- объективный фактор.
Эти изменения возникают вследствие технического прогресса, социальных
перемен, изменений в людях, предлагаемых улучшений, обнаружения
ошибок. Задача аналитика спрогнозировать изменение требований и
запланировать адекватный ответ на это событие. Поскольку изменения
проекта делаются в более напряженных условиях, то они более подвержены
ошибкам и должны быть особенно тщательно проверены.
Обычно задачи
данной системы определяются задачами системы более высокого уровня.
Что для данной системы является целью, для системы более высокого
уровня является средством достижения более глобальной цели.
Оценка
осуществимости
Осуществимость
проекта можно оценивать по разным критериям:
- экономическая
осуществимость (стоимость, сроки, экономический эффект, спрос...);
- технологическая
осуществимость (ресурсы, технология, инструменты...);
- юридическая
осуществимость (законодательство, обязательства...).
Важнейшим
вопросом является "Быть или не быть" информационной системе.
Стоит ли вообще разрабатывать новую информационную систему, или
можно обойтись тем, что есть? Требуется рассмотреть все возможные
варианты решения текущих проблем, а также заглянуть в будущее в
поисках предстоящих проблем и методов их решения.
Экономический
эффект от информационной системы может включать снижение затрат,
улучшение контроля и управления, увеличение гибкости и скорости
работы, повышение престижа, получение прямой денежной прибыли.
Оценка
риска
До начала разработки
необходимо уберечь проект от его гибели в самом зародыше. Определить
источники неприятностей крайне трудно, так как многие из них сейчас
не видны, но проявятся в будущем. Обычными источниками риска считаются:
нехватка средств, кадровые вопросы (увольнения, болезни), недооценка
трудностей, плохая маркетинговая политика.
Чтобы повысить
надежность проекта обязательно следует пройти следующие этапы:
- анализ
рисков
- определение
источников риска
- группировка
источников риска;
- оценка
вероятности каждого риска;
- оценка
степени влияния каждого риска на проект;
- определение
природы риска, области действия, времени появления, продолжительности
действия, периодичности.
- рассмотрение
комбинации рисков (вероятность и послдствия)
- управление
рисками
- определение
допустимого и предельного уровня каждого риска;
- рассмотрение
вариантов снижения каждого риска (оценка затрат и ограничений);
- принятие
мер для снижения рисков;
- разработка
поведения при наступлении рисковой ситуации;
- разработка
механизма отслеживания рисков;
Правило
Парето:
20%
источников риска вызывают 80% неприятностей.
Полезно помнить
закон Мерфи: "Если неприятность может случиться, то она случается."
и несколько следствий из этого закона: "Случается самая плохая
неприятность в самый неподходящий момент.", ... См. Законы
Мэрфи.
Могут быть приняты
следующие меры по снижению рисков: например, повышение зарплаты
сотрудникам, улучшение условий их работы, нахождение резервных источников
финансирования, найм специалистов по маркетингу и рекламе.
Логическая
модель
- Логическая
модель -- это схема работы предметной области на логическом
уровне без технических подробностей.
Основой для
построения логической модели может служить схема документооборота.
Логическая модель
может представляться на разных уровнях абстракции, что позволяет
охватить проблему в целом и при необходимости рассмотреть более
подробно некоторые ее части. Построение логической модели производится
с помощью функциональной декомпозиции. Начинают
с основной функции системы, затем переходят к более детальным функциям.
На этом этапе
можно наметить границы автоматизации, т.е. определить,
что будет автоматизировано, а что нет. Содержание информации в системе
определяются задачами персонала и решениями управленцев, а не наоборот.
Системный
анализ по методологии Гэйна - Сарсона включает следующие этапы:
- Логическая
модель существующей системы.
- Логическая
модель новой системы.
- Моделирование
данных.
- Проектирование
физической базы данных.
- Физическая
модель новой системы.
Построением
логических моделей занимается структурный системный анализ.
Метод
прототипа
- Прототип
-- это работающая модель будущей системы.
Пользователи
говорят: "Откуда я знаю, что я хочу, если я не знаю, что
я получу?" Для того, чтобы показать пользователям, что
их ждет, можно быстро и дешево разработать прототип будущей системы.
Тогда можно будет уточнить требования пользователей как можно раньше,
чтобы ошибки не появились в окончательной версии, когда ее исправление
будет в 100 раз дороже и в 100 раз тяжелее.
Конечно, многие
функции в прототипе не будут реализованы, но тогда надо создать
имитацию этой функции, видимость работы, заглушку, в конце концов.
Возможно создание
нескольких прототипов, каждый из которых все более полно представляет
будущую систему, и, возможно, последний прототип превратится в первую
версию программы.
Выяснение
проблем заказчика
Построение логической
модели -- это лишь промежуточный шаг в выяснении истинных проблем
и действительных целей заказчика (клиента).
Обычно все начинается
со смутного ощущения, что "что-то не так".
Затем ощущаются какие-то трудности -- проблемы.
Точнее, симптомы проблем, так как истинные причины трудностей могут
заключаться в другом. Например, трудность в сдаче сведений о доходах
в конце года в налоговую инспекцию может быть из-за полного беспорядка
в бухгалтерии предприятия.
Варианты обращения
с проблемой:
- бездействие
в надежде на то, что все разрешится само собой (обычно только
усугубляет положение)
- частично
решить, снять остроту вопроса, смягчить ситуацию (дает некоторую
отсрочку)
- решить оптимально
в данных условиях (не устраняет причин возникновения проблемы)
- растворить
проблему, изменив условия.
Исходная проблема,
заявленная заказчиком, преобразуется в целый комплекс проблем.
У любой явной трудности есть скрытые причины, которые надо выявить.Этим
надо заниматься до начала любой деятельности по
разработке информационной системы. Требуется определить, в каком
именно месте браться за дело, что изучать и автоматизировать. Если
не устранить корни проблемы, а только срезать ее крону (решить оптимально),
то возможно проблема проявится снова уже в несколько другом виде
и в других условиях. Для полного устранения проблемы, требуется
добраться до ее первопричин и изменить условия так, чтобы проблема
растворилась, т.е. исчезла сама возможность ее возникновения.
Высший
уровень управления -- не допускать возникновения проблем, заранее
их предвидя и соответствующим образом изменяя ситуацию.
После того,
как выявлены действительные проблемы заказчика, требуется определить
цели, к которым он стремится, что он хочет от новой
системы. Выясняется конечный результат всей деятельности по разработке
информационной системы. Определение целей -- это постановка задачи
разработчикам. Цели должны быть по возможности измеримыми, чтобы
можно было позже оценить степень выполнения плана. Желательно, чтобы
цели были ясными, явными, измеримыми, реальными.
Когда цели сформулированы,
требуется определить критерии оценки. Критерии
оценки нужны для сравнения альтернативных вариантов решения проблем,
достижения целей. С помощью критериев можно измерить степень достижения
цели.
Например, для
цели успешной сдачи сведений о доходах можно определить следующие
критерии: кол-во сверхурочного человеко-времени, необходимого для
сдачи сведений о доходах, кол-во ошибок в сведениях, сумма штрафов
в связи неверными сведениями или несвоевременной их сдачей. Разработка
критериев -- творческий процесс; главное, чтобы критерии
наиболее полно накрывали цель.
Далее необходимо
определить ограничения, налагаемые на варианты
решения проблемы. Ограничения могут быть разного характера: технологического
(законы природы и т.д.), организационного (деловые правила), юридического
(законодательство) и др. Ограничения бывают разной степени строгости:
некоторые невозможно даже ослабить, некоторые можно полностью устранить.
После того,
как задача четко определена, можно приступать к ее решению
(или устранению). Возможно в процессе решения, некоторые детали
задачи будет уточняться и видоизменяться. К этому надо быть готовым.
Чем раньше будут определены измененные условия, тем легче и дешевле
их учесть. Возможно, что понадобится решить сначала часть задачи,
так как общая задача очень сложна. Выделение подзадач, разбиение
проблемы на более простые части -- это универсальный метод разрешения
проблем. В последнем случае решение может быть проведено в несколько
этапов, даже с возможностью их параллельного исполнения.
Итак, имеем
следующую логическую последовательность:
Проектирование
- Проектирование
-- это планирование информационной
системы.
На данном этапе
разрабатывается общая структура будущей системы, строится каркас
программы, разрабатываются структуры данных (в том числе схема базы данных).
Нисходящее
проектирование
Это пошаговый
процесс проектирования, начиная с основных функций, которые подразделяются
на подфункции до тех пор, пока не станет возможным их реализовать.
Принципы уровней абстракции:
- На каждом
уровне абсолютно ничего не известно о свойствах (и даже о существовании)
более высоких уровней.
- На каждом
уровне ничего не известно о внутреннем строении других уровней.
Связь между уровнями осуществляется через жесткие, заранее определенные
интерфейсы.
- Каждый уровень
должен иметь высокую прочность (связность) и
слабое сцепление с другими уровнями.
- Прочность
объекта -- это мера его внутренних связей.
- Сцепление
объектов -- это мера взаимодействия объектов друг с другом.
Похожие принципы
действуют и на модули внутри каждого уровня:
- Модуль содержит
минимум информации о других модулях данного уровня.
- Каждый модуль
ничего не знает о внутреннем строении других модулей. Связь между
модулями осуществляется через жесткие, заранее определенные интерфейсы.
- Каждый модуль
имеет высокую прочность и слабое сцепление с другими модулями.
Моделирование
данных
Модель
-- это аналог оригинала, который его в чем-то заменяет.
Модель
данных -- это схема данных предметной области, которая создается
с целью правильного отражения действительности в информационной системе.
Данные моделируются
с целью построения базы данных.
Реализация
- Реализация
-- это процесс воплощения проекта в программы и физические системы.
| Современные
CASE-средства позволяют производить автоматическую генерацию
кода, будь то база данных, программа или WEB-сайт. В будущем
эта тенденция будет только усиливаться. |
Реализация (или
программирование, кодирование) должна быть направлена на наиболее
точное воплощение проекта и программных спецификаций в текст программы
на языке программирования. Основные критерии -- точность и надежность.
Не следует усложнять
программу или применять хитрые трюки программирования для обеспечения
чуть большей скорости. Развитие техники идет столь быстрыми темпами,
что основной показатель -- это понятность программы,
ее пригодность к сопровождению и надежность (см.
распределение стоимости). Программа понятна
-- это значит, что другой программист той же квалификации сможет
легко разобраться в том, как работает эта программа. Обычно, чем
выше уровень языка, тем понятнее программа и тем меньше ошибок.
Если требуется повысить скорость работы программы, то надо добиваться
"макроэффективности", а не "микроэффективности".
Тогда скорость возрастет в несколько раз. Самые гениальные
решения -- это самые простые решения.
- Недостаток
комментариев усложняет поиск ошибок,
так как при проверке бывает трудно разобраться в сложной программе
без небольших пояснений.
- Избыток
комментариев также усложняет поиск ошибок.
Комментарии говорят, что делает программа по мнению автора, а
не что она делает на самом деле.
В основном встречается недостаток комментариев.
Один из самых
хороших методов программирования состоит в том, чтобы сначала все
действия процедуры или модуля записать на обычном естественном языке
с помощью комментариев. Затем постепенно детализировать действия,
переводя некоторые из них на язык программирования до тех пор, пока
не получится работающая программа. В этом случае комментарии получатся
сами собой.
Повышение
надежности системы
- Защитное
программирование. В начале каждой процедуры помещается
блок проверки входных данных на правильность и осмысленность.
Каждая компонента должна предполагать, что все другие содержат
ошибки. Все получаемые данные считаются ошибочными, пока не будет
доказано обратное. Самая надежная величина, не требующая никакой
проверки, может быть ошибочна. (см. Законы
Мэрфи)
НО: если выполнять все мыслимые проверки, то проверочная часть
программы может стать слишком сложной и следовательно в ней самой
могут быть ошибки.
- Избыточность
позволяет по части данных проверить остальную часть. Если избыточности
нет, то ее можно ввести.
- Изоляция
ошибок. Ошибка в части системы, не должна повлиять на
другие части. Например, в операционных системах ошибка в одной
программе не должна повлиять на другие программы и саму операционную
систему.
Основная
причина ошибок -- сложность.
Мерой
сложности объекта является количество интеллектуальных
усилий, необходимых для понимания этого объекта. Ясно, что для
каждого человека эта величина разная. Что сложно для одного человека,
может быть просто для другого.
Сложность системы
зависит от количества и качества связей между ее компонентами и
самих компонет.
| Простая
система |
Сложная
система |
| 
|
|
Чтобы уменьшить
сложность объекта, вводятся уровни абстракции,
иерархическая структура
или модульность. В последнем случае проблема (программа)
разбивается на части (модули) до тех пор, пока их не удастся решить
(запрограммировать).
Тестирование
- Тестирование
-- это поиск ошибок в информационной системе.
- Ошибка
-- это несоответствие того, что есть, тому, что должно быть.
- Надежность
-- это вероятность безотказной работы в течение некоторого
периода времени, рассчитанная с учетом стоимости каждого отказа.
Принципы
тестирования
Тестирование
проводится для того, чтобы найти немногие оставшиеся ошибки в хорошо
спроектированной системе и тем самым повысить ее надежность, а следовательно,
ценность. С помощью тестирования нельзя добиться хорошей надежности
в плохо спроектированной системе.
Если мы тестируем
программу, то нам нужно окупить затраты на тестирование, каким-либо
образом повысив стоимость программы. Это можно сделать только повысив
надежность программы, ради чего тестирование и проводится. Повысить
надежность можно только исправлением ошибок, внесенных в процессе
разработки.
Удачным
считается тест, который обнаружил ошибку.
Если ни одна ошибка не была обнаружена, то тест считается неудачным.
- Ошибки имеют
свойство группироваться.
Если в какой-то части программы найдено много ошибок, то там еще
много осталось.
- Никогда не
изменяйте программу, чтобы облегчить ее тестирование.
- Следует избегать
тестирования программы ее автором. Если программист сделал ошибку
при написании программы, то вполне вероятно он сделает ту же самую
ошибку при ее тестировании. Программист подсознательно считает
свою программу продолжением самого себя и не станет особенно тщательно
ее тестировать.
- Разработка
тестов -- творческий процесс, который требует, в некотором роде,
разрушительного склада ума.
- Хорош тот
тест, для которого высока вероятность обнаружить ошибку.
- Необходимо
проверять не только, делает ли программа то, для чего она предназначена,
но и не делает ли она то, что не должна делать.
- Некоторую
часть тестов следует выделить в качестве тестов регрессии,
которые в будущем должны выполняться после каждого исправления
программы, чтобы проверить, не ухудшилась ли система, не произошел
ли регресс.
- Недостаток
комментариев усложняет поиск ошибок, так как при проверке бывает
трудно разобраться в сложной программе без небольших пояснений.
- Избыток комментариев
также усложняет поиск ошибок. Комментарии говорят, что делает
программа по мнению автора, а не что она делает на самом деле.
После
тестирования нельзя гарантировать отсутствие ошибок,
можно лишь говорить о некотором уровне
уверенности
в правильности работы системы.
-
Тест
-- это совокупность входных данных и/или действий пользователя
с указанием ожидаемых результатов и/или ответных действий программы.
Невозможно
провести полное всеохватывающее тестирование даже простой программы,
так как на это не хватит ни времени, ни ресурсов. Поэтому существует
несколько видов тестирования, которые предлагают методики для построения
тестов с наибольшей вероятностью обнаружения ошибок. Каждая методика
дополняет другую и очень хорошо применять сразу несколько видов
тестирования.
Виды
тестирования:
Структурное
тестирование
При данном подходе
считается, что текст программы виден (белый ящик).
Тестируются блоки ветвлений, циклы и т.д.
Существует несколько
типов структурного тестирования:
- покрытие
операторов,
- покрытие
решений,
- покрытие
решений / условий,
- комбинаторное
покрытие условий,
- тестирование
циклов.
Функциональное тестирование
При данном подходе
считается, что текст программы не виден, и программа рассматривается
как черный ящик, т.е. известны входные и выходные условия, а также
общая схема работы. Программа проверятся по ее спецификациям.
Существуют несколько
видов функционального тестирования:
- эквивалентные
классы,
- анализ граничных
значений,
- тестирование
на предельных нагрузках,
- тестирование
на предельных объемах,
- тестирование
защиты,
- эксплуатация
системы самим разработчиком (если возможно),
- опытная эксплуатация.
Отладка
- Отладка
-- это исправление найденных ошибок.
Обычно при тестировании
обнаруживают не сами ошибки, а их последствия -- симптомы. При отладке
настоящую ошибку надо локализовать (т.е. определить место в программе,
где она содержится), затем исправить, проверить правильность исправления
и провести анализ ошибки.
При исправлении
ошибки высока вероятность внесения новой ошибки (примерно 20%).
Если программу исправляет не автор, тогда вероятность еще выше.
- Изучите программу
в окрестности найденной ошибки в поисках новых неприятностей,
так как ошибки имеют свойство появляться группами. Вспомните похожие
места в системе, где возможно была сделана такая же ошибка.
- Если ошибка
была обнаружена при эксплуатации системы, то часто требуется устранить
последствия ошибки. Здесь главное не усугубить положение
поспешными и непродуманными действиями. Рекомендуется по возможности
сделать резервную копию.
- Часто пользователи
сами предлагают способы решения проблемы. Такие пути в будущем
могут привести к еще более сложным проблемам. Все предложения
надо критически проанализировать.
- Не все ошибки
являются ошибками разработчиков, некоторые ошибки происходят из-за
неправильных входных данных или действий пользователей. В таком
случае стоит принять меры для недопущения таких ошибок в будущем.
(см. защитное
программирование)
Каждую
ошибку следует внимательно изучить, чтобы понять, почему она возникла,
что должно было быть сделано, чтобы ее предотвратить или
обнаружить раньше.
Внедрение
- Внедрение
-- это включение информационной системы в предметную область.
Внедрение --
особый этап, так здесь многое зависит от пользователей, разработчиков
и их совместной работы. Внедрение должно быть продумано заранее.
Составляется поэтапный календарный план, затем он претворяется в
жизнь с постоянным контролем за его выполнением.
Первым этапом
внедрения является опытная эксплуатация системы.
Технические
проблемы могут быть таковы:
- требуется
обеспечить преемственность (или совместимость) с прежней системой,
- требуется
обеспечить безболезненный переход к новой системе, возможно без
остановки работы.
Организационные
проблемы:
- внедрение
новой системы возможно потребует новой организации работ,
соединение новой системы и старых методов может привести к краху,
- потребуется
обучение или переквалификация пользователей,
- возможно
потребуются кадровые перестановки или даже увольнения.
Одна из основных
проблем -- человек. Некоторые сотрудники коллектива
препятствуют внедрению новой системы по разным причинам: боятся
новизны, боятся потерять работу или вскрыть свои недостатки, боятся
открыть махинации в работе, не умеют работать по новому и не хотят
научиться этому.
Ради достижения
своей цели некоторые люди начинают врать, критиковать, осмеивать,
саботировать.
Методы борьбы
с сопротивляющимися:
- убеждение
(беседы, доказательство и демонстрация преимуществ новой системы)
- начальная
помощь разработчиков в работе пользователя
(но это не значит, что разработчик возьмет на себя всю
работу пользователя)
- поощрение
или давление со стороны руководства,
- начальный,
постоянный или периодический контроль,
- отстранение
от работы с новой системой
(запрет, перемещение на другую работу или в другой отдел, даже
увольнение)
Подробнее об
этом см. раздел Психология => Конфликтология.
|
