Пока автоматизация решения задач управления носила локальный, частный характер, а количество таких задач было невелико, схема технологического процесса создания программных средств, при которой каждая функциональная задача рассматривалась отдельно от других задач, могла в большей или меньшей степени удовлетворять разработчиков. Когда возникла потребность создания систем автоматизированной обработки информации, внедрение которых могло обеспечить совершенствование организационно-экономического управления, такая схема оказалась непригодной, так как она не отражала основного принципа разработки - принципа системного подхода, что проявилось особенно ярко в виде массового дублирования данных в информационных массивах.
В качестве альтернативы такому дублированию информации возникла концепция баз данных как единого, централизованного хранилища всей информации, необходимой для решения задач управления. Первоначально в противовес огромному дублированию информации, присущему позадачному подходу, концепция БД подразумевала полное отсутствие такого дублирования. Однако теоретически корректная концепция в реальности оказалась малоэффективной, так как безусловный выигрыш в объемах необходимой памяти оборачивался значительным проигрышем во времени, требуемым на поиск и выборку из БД информации, необходимой для решения той или иной конкретной задачи.
|
|
В связи с этим в настоящее время концепция БД подразумевает разумный компромисс между сокращением до минимума необходимого дублирования информации и эффективностью процесса выборки и обновления требуемых данных. Действительное обеспечение такого решения возможно только при условии системного анализа всего комплекса задач, подлежащих автоматизации, уже на этапе описания системы: ее целей и функций, состава и специфики информационных потоков, информационного состава задач и даже отдельных программных модулей. Системный подход, базирующийся на положениях общей теории систем, наиболее эффективен при решении сложных задач анализа и синтеза, требующих одновременного использования ряда научных дисциплин.
Другим важным фактором, обусловливающим необходимость системного подхода, начиная с этапа формулирования требований и постановки задач, является то, что на этот этап приходится до 70-80% всех затрат, падающих на разработку прикладного программного обеспечения, и он имеет особое значение в обеспечении соответствия результатов разработки потребностям конечных пользователей.
Последнее особенно важно, так как по тяжести последствий ошибок этот этап занимает первое место среди всех остальных этапов.
|
|
Так, по проведенному статистическому анализу большого числа проектов, выполненных ведущими западными компьютерными фирмами (IBM, TRW, GTE Corp., Bell Labs.), в типовом программистском проекте 56% всех обнаруженных ошибок приходится на ошибки в требованиях на программы, а на устранение этих ошибок уходит до 82% всех усилий, затрачиваемых разработчиками на устранение ошибок проекта. Такое положение дел объясняется, с одной стороны, сложностью и трудоемкостью этапа в плане обеспечения адекватности трактовки разработчиками проекта требований пользователей, а с другой стороны, тем, что неизбежные ошибки, допущенные на этом этапе, как правило, обнаруживаются (проявляются) лишь на стадии опытной и даже промышленной эксплуатации, когда стоимость их исправления возрастает в десятки раз.
Объективное требование системного подхода к разработке программных средств решения задач при автоматизации систем управления вызвало необходимость дифференциации специалистов-разработчиков, что проявилось в выделении в их составе системных аналитиков, системотехников, прикладных и системных программистов.
Системный аналитик, исходя из общих целей, назначения, технических характеристик, состава и описания требований пользователей к прикладным задачам и системе в целом, формулирует общие формальные требования к программному обеспечению системы.
Специалист-системотехник преобразует общие формальные требования в детальные спецификации на отдельные программы, участвует в разработке логической структуры базы данных и т.п., т.е. определяет общую информационно-программную структуру проекта.
Прикладной программист преобразует спецификации в логическую структуру программных модулей, а затем и в программный код.
Системный программист обеспечивает сопряжение программных модулей с программной средой, в рамках которой предстоит функционировать прикладным программам (задачам).
В целях сокращения общей длительности разработки системы начало некоторых этапов технологического процесса осуществляется еще до полного завершения работ на предыдущем этапе. Такой частичный параллелизм в работе, кроме того, обусловливается и итерационным характером работ на этих этапах, когда в ходе выполнения отдельных работ 1-го этапа возникает необходимость уточнения или изменения спецификаций, выполненных на предшествующих этапах, либо пользователь по своей инициативе вносит коррективы в исходные требования, что, естественно, отражается на всей последующей технологической цепочке реализации проекта.
Другой отличительной чертой системной разработки проектов прикладных программ является их ориентация на использование интегрированных и распределенных баз данных. В связи с этим в качестве инструментальных средств разработки компонентов программного обеспечения наряду с языками программирования стали применяться языковые средства СУБД.
Микропроцессорная революция резко поменяла приоритеты и актуальность проблем, присущих традиционным технологиям разработки прикладных программ. Быстро растущая вычислительная мощность, расширение других вычислительных возможностей современных ПК в.сочетании с возможностью объединения этих ресурсов с помощью вычислительных сетей - все это позволило нивелировать погрешности Пользователей - непрофессиональных программистов в плане эффективности создаваемых ими программных средств решения прикладных задач.
Возможность исключения из технологической цепочки программистов-профессионалов (посредников) создала предпосылки для ускорения процесса разработки прикладных программных средств, а главное для сокращения количества ошибок, присущих традиционным технологическим схемам, когда основные усилия профессиональных программистов затрачивались на то, чтобы адекватно воспринять требования, предъявляемые конечными пользователями к программам, обеспечить своевременное получение достоверных, исчерпывающих сведений об исходных данных, необходимых для решения задачи, и т.п.
|
|
Но эффект от такого "вытеснения" профессиональных программистов из их сферы деятельности пользователями-непрофессионалами зачастую снижался или не ощущался вообще в связи с тем, что, не владея основами методологии разработки программных средств, типовыми программистскими приемами и умением использовать "подручные" средства из арсенала той или иной инструментальной среды, пользователи зачастую попадают в различные "тупиковые" ситуации, которые не составляют каких-либо трудностей для профессионалов в области программирования.