4.Методология разработки

На разных этапах разработки ИС приходится решать общие в методическом отношении задачи:

• Управление сложностью разработки - невозможно сразу создать (и описать) все детали информационной системы – приходится выделять и разрабатывать более или менее самостоятельные блоки.

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

• Задача выработки и соблюдения требований к качеству и готового изделия, и процесса его разработки.

Известны и широко применяются следующие подходы к управлению сложностью:

1. Декомпозиция «сверху-вниз». Исходное целое разбивается на некоторые части, каждое из которых в дальнейшем подвергается аналогичному делению до получения некоторых простейших единиц.

2. Синтез «снизу-вверх» противоположен предыдущему подходу – из простых частей пытаются скомбинировать более сложные блоки, и так далее до получения требуемого результата.

3. Подход «от центра к границам» (Centre-out) комбинирует два первых подхода. Изучение начинается с некоторого среднего по уровню детализации объекта. Исследуется его структура (декомпозиция) и связь с другими объектами (синтез). Подход применяется при изучении различных структур управления.

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

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

1. Структурное программирование – ограничение управляющих конструкций следованием, выбором и циклом (отказ от Go To) с возможностью их вложения друг в друга. Эти ограничения в сочетании с определением процедур и функций является стройной концепцией пошаговой декомпозиции в программировании.

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

3. Моделирование данных – описание системы данных в виде совокупности единиц информации. При этом выделяют элементарные единицы, такие как числа, строки, логические данные и другие, и составные единицы, такие как массивы (наборы пронумерованных единиц одного типа) и структуры (наборы единиц разных типов).

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

Приведенный список отражает только некоторые распространенные структурные методы.

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

• внешние границы, определяющие описываемую часть реального мира,

• внутренние границы, задающие уровень детализации.

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

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

Отдельно рассматривают качество конструкции и качество изготовления (см. табл.3).

Для каждого вида работ важны следующие характеристики качества:

1. Соответствие ожиданиям/требованиям пользователя. Качество соответствия обеспечивается:

   1. участием пользователя в планировании и конструировании ИС,

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

   3. использованием специальных приемов и технологий общения.

2. Гибкость ИС. Гибкости добиваются посредством независимости систем и частей ИС.

3. Универсальность (portable). Способами достижения универсальности являются разработка более сложных процедур чем требуется в данном проекте с учетом прогноза изменения ИС и тщательное документирование разработки.

Рис. 8. Наиболее вероятные моменты обнаружения ошибок

Таблица 3