Прежде всего определим, что такое ЖЦ и в чем состоят его особенности для систем корпоративного типа. Ведь речь идет о действительно больших системах, которые включают терабайты данных разных степеней структурированности, географически распределены по земному шару и между которыми нужно наладить взаимодействие для получения консолидированной отчетной информации по основным видам корпоративных ресурсов. Будут рассмотрены основные этапы ЖЦ: анализ и спецификация требований, эскизное и детальное проектирование, реализация и тестирование, сопровождение и вывод из эксплуатации – и экономическая специфика этапов ЖЦ ПО. При этом будет упомянуто не только о стоимости затрат, но и об их структуре, на основе анализа большого количества проектов, который был произведен в частности компанией HP и другими компаниями, здесь будут приведены оценки, сделанные Карнеги-Мелонским университетом. И, что очень важно, будет рассмотрена связь этапов ЖЦ с различными моделями.
Модели, методы и инструментальные средства – это, так сказать, три кита, три основных составляющих, на которых стоит все проектирование, разработка корпоративных, в том числе информационных, систем. Эффективная разработка немыслима без использования средств автоматизированного проектирования, или CASE-средств. При описании производства как промышленного процесса необходимо упомянуть о тех метриках, которые позволяют определить и ограничить программный продукт и приходить к определенным выводам на основании анализа этих метрик. Это позволит ответить на вопросы: следует ли уже прекратить сборочное тестирование и начинать тестирование продукта, достаточно ли качественным является этот продукт, не превосходит ли существующее количество ошибок некое пороговое значение.
Как оценить сложность ПО? Достаточно ли, скажем, для этого ограничиться количеством строк кода? Или существуют другие метрики оценки? Например, количество операторов, операндов и т. д. Как пользоваться этими метриками и насколько они эффективны? Ведь процесс производства ПО должен быть конвейерным, таким, чтобы методологии и модели работали для большого количества программных продуктов и проектирование проводилось по единообразной схеме.
Итак, в чем заключается жизненный цикл программного обеспечения, какие имеются у него составляющие, в чем состоит его экономика, инструментарий и метрики.
В разработке ПО существуют определенные сложности и проблемы, которые нужно решать со стороны как разработчика, так и системного архитектора и даже руководителя программного проекта. Необходимо достичь определенного уровня качества, которое связано с теми метриками, о которых уже было сказано: порог ошибок, интерфейс пользователя, эргономичность, масштабируемость, количество одновременных пользователей, количество транзакций, время реакции системы и объем БД. Программный продукт должен удовлетворять этим метрикам при определенном дефиците ресурсов, имеющем место в любом проекте и который в любом случае достаточно жестко контролируется в ходе программных проектов. Это возрастающая сложность программных систем. Корпоративные системы – это десятки взаимодействующих систем, каждая из которых объединяет зачастую сотни первичных сущностей и часто терабайты данных, т. е. это очень сложные программные системы, которые достаточно быстро растут и которым необходимо взаимодействовать друг с другом.
В ходе выполнения программных проектов приходится часто сталкиваться с нехваткой ресурсов: людских, временных, финансовых. Происходит постоянное взаимодействие с заказчиком, который часто изменяет требования, и в ряде случаев, эти изменения могут носить для разработчика достаточно сложный и плохо предсказуемый характер, иногда эволюционный, иногда революционный. При этом необходимо, в зависимости от пути или степени изменения этих сложностей и требований, корректировать модели ЖЦ и, соответствующим образом, очередность стадий ЖЦ программных продуктов.
Еще один важный аспект – это проектная команда, взаимодействие большого количества участников. Под участниками в ряде случаев понимаются представители не только разработчика, но и заказчика, которые входят в состав software quality assurance – группы контроля качества продукта. Если даже исключить их из рассмотрения, а в ряде методологий, в особенности гибких (Agile, X P, Scrum), эти представители присутствуют и играют достаточно активную роль, то в любом случае на стороне разработчика есть целая проектная команда (может быть не одна), работу которой нужно координировать. В больших программных системах это большой объем человеко-часов и большое количество исполнителей с разными мотивациями, целями и задачами. В этом смысле, при большом количестве участников, необходимо управлять процессом, привлекая к этому CASE-средства (автоматизированного проектирования) – это тоже достаточно сложно. При этом важной проблемой является моральное устаревание программного обеспечения.
В следующих главах будет подробнее изложено о понятии Software Engineering (программная инженерия), которое возникло в конце 1960-х гг. на конференции NATO, когда обсуждалась аналогия между любым процессом промышленного производства (в частности, строительством мостов) и строительством программного обеспечения, программной архитектурой. Вообще достаточно часто в литературе, связанной с ПО, возникают аналогии между архитектурным строительством сооружений, зданий, мостов и программными проектами. В отношении Software Engineering – тут не все так просто. Ряд методов, которые работают в первом случае, не подходят для программной инженерии. Программное обеспечение морально устаревает – и это происходит достаточно быстро. Посмотрим, например, на скорость смены ОС Windows – это происходит примерно раз в 5 лет, может и чаще. В то же время многие дома и мосты морально не устаревают гораздо дольше, в течение сотен лет. Таким образом, проблемы разработки ПО во многом более динамичны, чем проблемы целого ряда отраслей реального сектора экономики. Кроме того, разработка ПО растет высокими темпами. Для ряда компаний это направление является единственным, основным, определяющим. Необходимо успеть до того, как выйдут на рынок продукты конкурентов, опередить их и обеспечить высокое качество продукции, совместив его с достаточно быстрым вводом в эксплуатацию. Кроме того, это очень большое количество новых отраслей народного хозяйства. Достаточно сказать о такой новой отрасли, как нанотехнологии – это очень быстрая, конкурентная отрасль, которая затрагивает целый ряд промышленных технологий и направлений, требует оперативного знакомства предметных экспертов и системных аналитиков с совершенно новыми понятиями. Таким образом, получается достаточно большое количество взаимосвязанных и взаимодополняющих проблем, которые существенно осложняют разработку ПО, особенно в корпоративных системах.
Графическое представление ограничений на разработку приложений можно описать следующим образом. Это некоторая модификация традиционного проектного треугольника, который связан с затратами времени, средств и функционала. Приблизительно можно увидеть это как три оси. Где-то внутри этого треугольника находится оптимальное сочетание этих параметров, которое и удается обеспечить при адекватном сочетании моделей, методов и средств проектирования корпоративных информационных систем и программных приложений в целом.
Какие ограничения можно увидеть при разработке приложений, в том числе корпоративных? На процессы разработки воздействует целый ряд факторов. Это, конечно, объем кода, который можно измерить в тысячах строк. Корпоративные продукты – это десятки, сотни тысяч строк и более, в зависимости от характера и масштаба этих систем. Это, конечно, очень большая сложность. Каждый отдельно взятый модуль таких систем, как, например, Oracle Applications, представляет собой несколько сотен первичных сущностей. Для того чтобы охватить их взглядом, требуется очень серьезная фундаментальная предметная подготовка, аналитический взгляд, профессионализм и использование специализированных средств автоматизированного проектирования. Кроме того, существует целый ряд ограничений, которые связаны с людскими ресурсами. Естественно, человеку охватить такое количество сущностей и грамотно строить процессы проектирования, разработки, которые включают и тестирование, постановку задачи, анализ и спецификацию требований, естественно, очень сложно. Эти процессы нужно грамотно координировать, чтобы команда давала отдачу от того, что используется такой большой коллектив, и не появлялись чрезмерные затраты на обучение все новых и новых членов команды по мере того, как проект расширяется и в него вовлекаются новые силы и средства.
Кроме того, обучение тормозит процессы разработки. Нужно понимать, что в разработке новой системы в рамках существующего корпоративного программного комплекса заказчик зачастую не может остановить свои ключевые бизнес-процессы. И пусть ценой дополнительных затрат унаследованные системы, работающие на мейнфреймах или устаревших архитектурах, все же обеспечивают поддержку этих бизнес-процессов. И при интеграции новых систем в существующую программную среду заказчика необходимо обеспечить корректность и адекватность этой интеграции и функционирование расширенного комплекса новой системой. Это нужно сделать для того, чтобы этот новый комплекс позволял извлечь больше информации, консолидировать данные и в итоге давал возможность руководству получить аналог приборной панели, на которой оно сможет видеть результаты, достигнутые компанией по финансам, по кадрам, по материальным и производственным ресурсам. Результаты можно будет представить в виде срезов, проекций с детализацией до отдельных стран, компаний, подразделений и сотрудников, и это позволит плавно масштабировать и анализировать эти результаты, строить тренды, прогнозы перспектив развития.
Целями разработки являются снижение или оптимизация ресурсов – многофакторная оптимизация, которая связана с людскими ресурсами, оптимизацией стоимости и длительности времени графика, плюс функциональные ограничения – ограничения на ту функциональность, которую необходимо и желательно реализовать в рамках программного проекта.
В чем состоит современный подход к решению всех этих проблем? Проблемы, связанные с важностью, высокотехнологичностью и ограничениями, которые диктует рынок: конкурентная среда, время, которое жестко ограничивает регламенты проектирования корпоративных систем, и ряд других проблем, которые усугубляются корпоративным характером информационных систем, сложностью и большим объемом приложений. Конечно, можно прибегнуть к методам анализа и систематизации тех знаний, которые уже существуют, и которые были получены имперически при разработке первых подобных проектов, подобного класса и масштаба. И здесь на помощь приходит программная инженерия, то есть целый ряд дисциплин, которые связаны с процессами управления проектированием программных систем, построением архитектурных основ такого рода информационных систем и, конечно, разработки, проектированию и реализации, включая тестирование и сопровождение, то есть управление ЖЦ такого рода программных систем и их комплексов.
Глава 2
Обзор жизненного цикла корпоративных систем
Программная инженерия, или инженерия программного обеспечения, представляет собой область компьютерной науки, которая занимается построением программных систем, т. е. целого ряда взаимодействующих компонентов программного обеспечения, которые являются настолько большими или сложными, что для построения такого рода систем требуется участие команды или даже взаимодействующих команд разработчиков. Под разработчиками здесь понимаются не только программисты, но и аналитики, постановщики задач, тестировщики, системные архитекторы, документаторы, специалисты по контролю качества ПО и персонал сопровождения. То есть это достаточно большая команда, которая нацелена на производство того или иного программного продукта в уже существующей среде информационных систем заказчика. Поэтому очень важен подход к организации на всех уровнях и во всех перечисленных аспектах разработки программного обеспечения: анализ и спецификация требований, первичное и детальное проектирование, реализация и тестирование, интеграция, передача заказчику, сопровождение.
Программная система – это совокупность взаимодействующих программ под общим управлением, которая предназначена для того, чтобы решать конкретную задачу или ряд взаимосвязанных задач.
Приложение – это программа, которая решает функциональные задачи по обработке информации в рамках той или иной предметной области, например приложения, которые контролируют людские или другие ресурсы.
Процитируем В.А. Липаева – патриарха отечественной программной инженерии. В книге "Программная инженерия" он привел следующее определение: "Под программной инженерией понимается комплекс задач, методов, средств и технологий создания, то есть проектирования и реализации сложных, расширяемых, тиражируемых, высококачественных программных систем, возможно включающих базы данных". Каждое слово в этом определении в полной мере применимо к корпоративным системам.
Согласно определению Липаева эта отрасль науки как раз и направлена на создание корпоративных информационных систем. И ввиду того, что они являются сложными, т. е. содержат большое количество первичных сущностей, большими по объему (тера-, петабайты данных) и расширяемыми, как правило, речь не идет о том, что мы революционным образом сразу заменяем все системы, которые используются в корпоративном программном комплексе. Чаще всего производится доработка какой-то отдельной системы. Они являются высококачественными и часто тиражируемыми.
Некоторые из примеров таких решений – Microsoft Dynamics, Oracle Applications и т. д. Под высоким качеством понимается и масштабируемость – плавное снижение производительности при достаточно резком увеличении интенсивности нагрузки на систему. Кроме того, нужно сказать, что эти системы должны быть надежными, вести себя предсказуемо, быть эргономичными, сопровождаемыми, т. е. должны быть настроены на то, чтобы обеспечивать достаточно гибкое и относительно эволюционное взаимодействие с пользователем на этапе опытной и промышленной эксплуатации. В определении также речь идет о проектировании и реализации, т. е. уже о полном жизненном цикле ПО. Важным дополнением является то, что информационные системы включают в ряде случаев базы данных. Если мы говорим о корпоративных системах, базы данных, как правило, являются неотъемлемой, важной частью этих систем. Другое дело, что эти базы данных могут строиться на различных принципах, являться гетерогенными, включать объектные составляющие, т. е. быть не чисто реляционными. Последние версии СУБД Oracle называются объектно-реляционными. Есть СУБД нового поколения, такие как O2, Orion и др., которые используют не только реляционные, но и другие, более новые объектно-ориентированные модели.
В корпоративных информационных системах необходимо разделять понятия программного проекта и программного продукта. В настоящем издании речь пойдет в основном о программных продуктах, т. е. о взгляде на ЖЦ с точки зрения системного архитектора. А с точки зрения программного проекта – это взгляд менеджера проектов, когда речь идет об управлении проектной командой, проектами, взаимодействием людей в проекте, сроками, стоимостью. С другой стороны, если говорить о программной инженерии, то речь может идти о разработке продукта для конкретного заказчика, но преимущественно и предпочтительно планировать все процессы и технологии, связанные с разработкой таким образом, чтобы по возможности обеспечить производство продукта, нацеленного на более широкую аудиторию потребителей, а в идеале сделать его коробочным или тиражируемым. Целесообразно обеспечить высокий процент повторного многократного использования элементов проекта – это и код, и документация, и структура СУБД, и программная архитектура, с тем чтобы при доработке проекта для "похожего" заказчика было затрачено минимум времени, средств и людских ресурсов.
На начальной стадии разработки продукта, как правило, речь идет о концепции, о том, что существует идея. При этом, конечно, необходимы начальные инвестиции. В то же время, если говорить о разработке проекта, то здесь существует уже некоторый черновой план, который учитывает основные финансовые, функциональные и временные ограничения, есть заказчик и конкретные лица, которые могут обеспечить финансирование проекта. В ряде случаев речь может идти о смешанной разработке, когда разработка частной системы под конкретный заказ может трансформироваться в относительно открытое решение для широкого класса заказчиков.
Чем характеризуется программный продукт? Во-первых, как правило, он имеет определенную коммерческую ценность. Это значит не то, что не существует условно бесплатных программных продуктов, а что этот продукт решает конкретную задачу конкретного класса пользователей, потребителей продукта. Таким образом, продукт может называться рыночным и быть предложен рынку для удовлетворения его определенных потребностей и решения конкретных бизнес-задач. Какие примеры программного продукта можно привести? Часто это физические объекты, скажем, информационные носители (DVD, CD и т. д.), но это могут быть и нематериальные соглашения, такие как лицензия, соглашение о партнерстве и пр. Еще одним примером может выступать услуга по внедрению, сопровождению, консалтингу и т. д.
Программные продукты можно классифицировать по разным основаниям. Один из видов классификации – масштаб использования: это и личное использование, и некоммерческое, и коммерческое как коробочный продукт для широкого класса организаций и предприятий. Другой способ классификации – цель использования. Это может быть специализированное ПО, нацеленное на решение достаточно узкой задачи, например расчетное ПО для решения астрономических задач, лазерной дальнометрии, или ПО более общего назначения, такое как операционная система, офисные продукты и т. п. Еще один вид классификации – степень открытости. При этом можно говорить о компонентной ориентированности, скажем, API, библиотеки, такие как, например, библиотека классов Enterprise Libraries, которая используется для надстройки над. NET для построения Microsoft-продуктов корпоративного типа, библиотека классов для построения офисных приложений и т. д. или готовые продукты.
Любая разработка ПО происходит согласно жизненному циклу и включает последовательное прохождение стадий ЖЦ, о которых мы уже упоминали и которые в широком смысле начинаются с концепции или базовой идеи и заканчиваются выводом из эксплуатации.
Вообще говоря, понятие ЖЦ можно использовать и применительно к другим классам систем, например, к таким системам, как архитектурные сооружения, однако ЖЦ программных систем (ПС) имеет свои особенности. ПС разрабатывается постепенно и развивается от концепции, абстрактной идеи и далее конкретизируется до программного продукта, который включает в себя не только код, но и большое количество документации – это диаграммы, документация к коду, документация для пользователей по работе с программным продуктом, для администраторов по настройке, установке и сопровождению и т. д. Программные системы заканчиваются на этапе вывода из эксплуатации, который завершает сопровождение.