Организации информационных процессов

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

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

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

Другим важным фактором, обусловливающим необходимость системного подхода, начиная с этапа формулирования требований и постановки задач, является то, что на этот этап приходится до 70-80% всех затрат, падающих на разработку прикладного программного обеспечения, и он имеет особое значение в обеспечении соответствия результатов разработки потребностям конечных пользователей.Последнее особенно важно, так как по тяжести последствий ошибок этот этап занимает первое место среди всех остальных этапов.

Согласно проведенному статистическому анализу большого числа проектов, выполненных ведущими западными компьютерными фирмами (IBM, TRW, GTE Corp., BellLabs.), в типовом программистском проекте 56% всех обнаруженных ошибок приходится на ошибки в требованиях на программы, а на устранение этих ошибок уходит до 82% всех усилий, затрачиваемых разработчиками на устранение ошибок проекта. Такое положение дел объясняется, с одной стороны, сложностью и трудоемкостью этапа в плане обеспечения адекватности трактовки разработчиками проекта требований пользователей, а с другой стороны, тем, что неизбежные ошибки, допущенные на этом этапе, как правило, обнаруживаются лишь на стадии опытной и даже промышленной эксплуатации, когда стоимость их исправления возрастает в десятки раз.

Объективное требование системного подхода к разработке программных средств решения задач при автоматизации систем управления вызвало необходимость дифференциации специалистов-разработчиков, что проявилось в выделении в их составе системных аналитиков, системотехников, прикладных и системных программистов.

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

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

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

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

Другой отличительной чертой системной разработки проектов прикладных программ является их ориентация на использование интегрированных и распределенных баз данных. В связи с этим в качестве инструментальных средств разработки компонентов программного обеспечения наряду с языками программирования стали применяться языковые средства СУБД.

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

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

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