Конкретные стандарты построения информационных систем.

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

За достаточно недолгий «информационный» век было разработано и опробовано несколько методологий проектирования информационных систем.

На первом этапе (70-80 гг.) основным подходом в проектировании ИС был метод «снизу-вверх», когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках «кусочной автоматизации» достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.

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

Следующий этап (80-90 гг.) связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться «сверху-вниз», т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей.

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

Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.

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

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

· обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации;

· гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

· поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

· обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).

Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.

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

1. Методологии необходимы для создания больших систем, и АИС в частности.

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