Информациооные системы

Самая страшная ошибка при разработке ПО -- сделать никому не нужную программу --  
не разобраться в требованиях.

Свойства требований:

• ясность, однозначность;
• приоритет;
• источник (пользователь, документ...);
• непротиворечивость другим требованиям;
• стабильность (или, наоборот, вероятность изменения);
• проверяемость.

Очень опасно пропустить какие-либо требования. Некоторые моменты  для пользователей кажутся естественными  и поэтому умалчиваются. Аналитики не телепаты и читать мысли не умеют. Для анализа полноты требований и их скорейшего уточнения нужно построить логическую модель предметной области. Также можно использовать метод прототипа.

Чем раньше будет найдена ошибка, тем дешевле и легче ее исправить.

Некоторые требования имеют характер ограничений, т.е. обязательны к выполнению. Ограничения внутри предприятия называются деловыми правилами. Они могут вытекать из характера предметной области или складываться исторически. Включение деловых правил в программу снижает ошибки пользователей и следовательно повышает надежность системы.

Изменение требований в процессе разработки и использования  ПО -- объективный фактор. Эти изменения  возникают вследствие технического прогресса, социальных перемен, изменений  в людях, предлагаемых улучшений, обнаружения ошибок. Задача аналитика спрогнозировать изменение требований и запланировать адекватный ответ на это событие. Поскольку изменения проекта делаются в более напряженных условиях, то они более подвержены ошибкам и должны быть особенно тщательно проверены.

Обычно задачи данной системы определяются задачами системы  более высокого уровня. Что для  данной системы является целью, для  системы более высокого уровня является средством достижения более глобальной цели.

Оценка осуществимости

Осуществимость проекта можно оценивать по разным критериям:

• экономическая осуществимость (стоимость, сроки, экономический эффект, спрос...);
• технологическая осуществимость (ресурсы, технология, инструменты...);
• юридическая осуществимость (законодательство, обязательства...).

Важнейшим вопросом является "Быть или не быть" информационной системе. Стоит ли вообще разрабатывать  новую информационную систему, или  можно обойтись тем, что есть? Требуется  рассмотреть все возможные варианты решения текущих проблем, а также  заглянуть в будущее в поисках предстоящих проблем и методов их решения.

Экономический эффект от информационной системы может  включать снижение затрат, улучшение  контроля и управления, увеличение гибкости и скорости работы, повышение  престижа, получение прямой денежной прибыли.

Оценка риска

До начала разработки необходимо уберечь проект от его  гибели в самом зародыше. Определить источники неприятностей крайне трудно, так как многие из них  сейчас не видны, но проявятся в будущем. Обычными источниками риска считаются: нехватка средств, кадровые вопросы (увольнения, болезни), недооценка трудностей, плохая маркетинговая политика.

Чтобы повысить надежность проекта обязательно следует  пройти следующие этапы:

• анализ рисков
• определение источников риска
• группировка источников риска;
• оценка вероятности каждого риска;
• оценка степени влияния каждого риска на проект;
• определение природы риска, области действия, времени появления, продолжительности действия, периодичности.
• рассмотрение комбинации рисков (вероятность и послдствия)
• управление рисками
• определение допустимого и предельного уровня каждого риска;
• рассмотрение вариантов снижения каждого риска (оценка затрат и ограничений);
• принятие мер для снижения рисков;
• разработка поведения при наступлении рисковой ситуации;
• разработка механизма отслеживания рисков;

Правило Парето: 
20% источников риска вызывают 80% неприятностей.

Полезно помнить закон  Мерфи: "Если неприятность может  случиться, то она случается." и  несколько следствий из этого  закона: "Случается самая плохая неприятность в самый неподходящий момент.", ... См. Законы Мэрфи.

Могут быть приняты  следующие меры по снижению рисков: например, повышение зарплаты сотрудникам, улучшение условий их работы, нахождение резервных источников финансирования, найм специалистов по маркетингу и рекламе.

Логическая модель

Логическая модель -- это схема работы предметной области на логическом уровне без технических подробностей.

Основой для построения логической модели может служить схема документооборота.

Логическая модель может представляться на разных уровнях  абстракции, что позволяет охватить проблему в целом и при необходимости  рассмотреть более подробно некоторые  ее части. Построение логической модели производится с помощью функциональной декомпозиции. Начинают с основной функции системы, затем переходят к более детальным функциям.

На этом этапе можно  наметить границы автоматизации, т.е. определить, что будет автоматизировано, а что нет. Содержание информации в системе определяются задачами персонала и решениями управленцев, а не наоборот.

Системный анализ по методологии Гэйна - Сарсона включает следующие этапы:

1. Логическая модель существующей системы.
2. Логическая модель новой системы.
3. Моделирование данных.
4. Проектирование физической базы данных.
5. Физическая модель новой системы.

Построением логических моделей занимается структурный системный анализ.

Метод прототипа

Прототип -- это работающая модель будущей системы.

Пользователи говорят: "Откуда я знаю, что я хочу, если я не знаю, что я получу?" Для того, чтобы показать пользователям, что их ждет, можно быстро и дешево разработать прототип будущей системы. Тогда можно будет уточнить требования пользователей как можно раньше, чтобы ошибки не появились в окончательной версии, когда ее исправление будет в 100 раз дороже и в 100 раз тяжелее.

Конечно, многие функции  в прототипе не будут реализованы, но тогда надо создать имитацию этой функции, видимость работы, заглушку, в конце концов.

Возможно создание нескольких прототипов, каждый из которых все более полно представляет будущую систему, и, возможно, последний прототип превратится в первую версию программы.

Выяснение проблем заказчика

Построение логической модели -- это лишь промежуточный  шаг в выяснении истинных проблем  и действительных целей заказчика (клиента).

Обычно все начинается со смутного ощущения, что "что-то не так". Затем ощущаются какие-то трудности -- проблемы. Точнее, симптомы проблем, так как истинные причины трудностей могут заключаться в другом. Например, трудность в сдаче сведений о доходах в конце года в налоговую инспекцию может быть из-за полного беспорядка в бухгалтерии предприятия.

Варианты обращения  с проблемой:

• бездействие в надежде на то, что все разрешится само собой (обычно только усугубляет положение)
• частично решить, снять остроту вопроса, смягчить ситуацию (дает некоторую отсрочку)
• решить оптимально в данных условиях (не устраняет причин возникновения проблемы)
• растворить проблему, изменив условия.

Исходная проблема, заявленная заказчиком, преобразуется в целый комплекс проблем. У любой явной трудности есть скрытые причины, которые надо выявить.Этим надо заниматься до начала любой деятельности по разработке информационной системы. Требуется определить, в каком именно месте браться за дело, что изучать и автоматизировать. Если не устранить корни проблемы, а только срезать ее крону (решить оптимально), то возможно проблема проявится снова уже в несколько другом виде и в других условиях. Для полного устранения проблемы, требуется добраться до ее первопричин и изменить условия так, чтобы проблема растворилась, т.е. исчезла сама возможность ее возникновения.

Высший уровень управления -- не допускать возникновения проблем, заранее их предвидя и соответствующим образом изменяя ситуацию.

После того, как выявлены действительные проблемы заказчика, требуется определить цели, к которым он стремится, что он хочет от новой системы. Выясняется конечный результат всей деятельности по разработке информационной системы. Определение целей -- это постановка задачи разработчикам. Цели должны быть по возможности измеримыми, чтобы можно было позже оценить степень выполнения плана. Желательно, чтобы цели были ясными, явными, измеримыми, реальными.

Когда цели сформулированы, требуется определить критерии оценки. Критерии оценки нужны для сравнения альтернативных вариантов решения проблем, достижения целей. С помощью критериев можно измерить степень достижения цели.

Например, для цели успешной сдачи сведений о доходах  можно определить следующие критерии: кол-во сверхурочного человеко-времени, необходимого для сдачи сведений о доходах, кол-во ошибок в сведениях, сумма штрафов в связи неверными сведениями или несвоевременной их сдачей. Разработка критериев -- творческий процесс; главное, чтобы критерии наиболее полно накрывали цель.

Далее необходимо определить ограничения, налагаемые на варианты решения проблемы. Ограничения могут быть разного характера: технологического (законы природы и т.д.), организационного (деловые правила), юридического (законодательство) и др. Ограничения бывают разной степени строгости: некоторые невозможно даже ослабить, некоторые можно полностью устранить.

После того, как задача четко определена, можно приступать к ее решению (или устранению). Возможно в процессе решения, некоторые детали задачи будет уточняться и видоизменяться. К этому надо быть готовым. Чем раньше будут определены измененные условия, тем легче и дешевле их учесть. Возможно, что понадобится решить сначала часть задачи, так как общая задача очень сложна. Выделение подзадач, разбиение проблемы на более простые части -- это универсальный метод разрешения проблем. В последнем случае решение может быть проведено в несколько этапов, даже с возможностью их параллельного исполнения.

Итак, имеем следующую  логическую последовательность:

Проектирование

Проектирование -- это планирование информационной системы.

На данном этапе  разрабатывается общая структура будущей системы, строится каркас программы, разрабатываются структуры данных (в том числе схема базы данных).

Нисходящее проектирование

Это пошаговый процесс  проектирования, начиная с основных функций, которые подразделяются на подфункции до тех пор, пока не станет возможным их реализовать.

Принципы уровней абстракции:

1. На каждом уровне абсолютно ничего не известно о свойствах (и даже о существовании) более высоких уровней.
2. На каждом уровне ничего не известно о внутреннем строении других уровней. Связь между уровнями осуществляется через жесткие, заранее определенные интерфейсы.
3. Каждый уровень должен иметь высокую прочность (связность) и слабое сцепление с другими уровнями.