Сергей Зыков - Основы проектирования корпоративных систем Страница 6

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

Остановися подробнее на жизненном цикле ПО (ЖЦ ПО). В начале главы уже были упомянуты его основные этапы. Фазы, которые связаны с разработкой программных систем, включают: анализ и спецификацию требований к программному продукту, проектирование программного продукта – первичное и детальное, уточненное, реализацию и тестирование элементов или модулей отдельного программного продукта, интеграцию или сборку этих модулей в частичный или полный программный продукт вместе с интеграционным тестированием, передачу заказчику после приемочных тестов, промышленную или опытную эксплуатацию, которая называется сопровождением и занимает по времени и средствам основную часть жизненного цикла, и, наконец, вывод из эксплуатации. Для реализации этого жизненного цикла применяются различные модели, методы и инструментальные средства. Подробнее рассмотрим основные этапы ЖЦ.

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

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

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

Итак, в чем заключается жизненный цикл программного обеспечения, какие имеются у него составляющие, в чем состоит его экономика, инструментарий и метрики.

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

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

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