Читать онлайн «Основы проектирования корпоративных систем». Страница 7

Еще один важный аспект – это проектная команда, взаимодействие большого количества участников. Под участниками в ряде случаев понимаются представители не только разработчика, но и заказчика, которые входят в состав software quality assurance – группы контроля качества продукта. Если даже исключить их из рассмотрения, а в ряде методологий, в особенности гибких (Agile, X P, Scrum), эти представители присутствуют и играют достаточно активную роль, то в любом случае на стороне разработчика есть целая проектная команда (может быть не одна), работу которой нужно координировать. В больших программных системах это большой объем человеко-часов и большое количество исполнителей с разными мотивациями, целями и задачами. В этом смысле, при большом количестве участников, необходимо управлять процессом, привлекая к этому CASE-средства (автоматизированного проектирования) – это тоже достаточно сложно. При этом важной проблемой является моральное устаревание программного обеспечения.

В следующих главах будет подробнее изложено о понятии Software Engineering (программная инженерия), которое возникло в конце 1960-х гг. на конференции NATO, когда обсуждалась аналогия между любым процессом промышленного производства (в частности, строительством мостов) и строительством программного обеспечения, программной архитектурой. Вообще достаточно часто в литературе, связанной с ПО, возникают аналогии между архитектурным строительством сооружений, зданий, мостов и программными проектами. В отношении Software Engineering – тут не все так просто. Ряд методов, которые работают в первом случае, не подходят для программной инженерии. Программное обеспечение морально устаревает – и это происходит достаточно быстро. Посмотрим, например, на скорость смены ОС Windows – это происходит примерно раз в 5 лет, может и чаще. В то же время многие дома и мосты морально не устаревают гораздо дольше, в течение сотен лет. Таким образом, проблемы разработки ПО во многом более динамичны, чем проблемы целого ряда отраслей реального сектора экономики. Кроме того, разработка ПО растет высокими темпами. Для ряда компаний это направление является единственным, основным, определяющим. Необходимо успеть до того, как выйдут на рынок продукты конкурентов, опередить их и обеспечить высокое качество продукции, совместив его с достаточно быстрым вводом в эксплуатацию. Кроме того, это очень большое количество новых отраслей народного хозяйства. Достаточно сказать о такой новой отрасли, как нанотехнологии – это очень быстрая, конкурентная отрасль, которая затрагивает целый ряд промышленных технологий и направлений, требует оперативного знакомства предметных экспертов и системных аналитиков с совершенно новыми понятиями. Таким образом, получается достаточно большое количество взаимосвязанных и взаимодополняющих проблем, которые существенно осложняют разработку ПО, особенно в корпоративных системах.

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

Какие ограничения можно увидеть при разработке приложений, в том числе корпоративных? На процессы разработки воздействует целый ряд факторов. Это, конечно, объем кода, который можно измерить в тысячах строк. Корпоративные продукты – это десятки, сотни тысяч строк и более, в зависимости от характера и масштаба этих систем. Это, конечно, очень большая сложность. Каждый отдельно взятый модуль таких систем, как, например, Oracle Applications, представляет собой несколько сотен первичных сущностей. Для того чтобы охватить их взглядом, требуется очень серьезная фундаментальная предметная подготовка, аналитический взгляд, профессионализм и использование специализированных средств автоматизированного проектирования. Кроме того, существует целый ряд ограничений, которые связаны с людскими ресурсами. Естественно, человеку охватить такое количество сущностей и грамотно строить процессы проектирования, разработки, которые включают и тестирование, постановку задачи, анализ и спецификацию требований, естественно, очень сложно. Эти процессы нужно грамотно координировать, чтобы команда давала отдачу от того, что используется такой большой коллектив, и не появлялись чрезмерные затраты на обучение все новых и новых членов команды по мере того, как проект расширяется и в него вовлекаются новые силы и средства.

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

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

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