РазрПрогрПрилож / Липаев_Программная инженерия

Лекция 4. Системное проектирование программных средств

—цели, задачи и функции предполагаемой новой или модернизиро­ ванной системы, обобщенные в концепции создания соответствующего программного средства;

—проекты планов жизненного цикла, гарантирования требуемого качества ПС, защиты и обеспечения безопасности его функционирования;

—результаты технико-экономического обоснования целесообразности

иосновных направлений продолжения проектирования и всего ЖЦ ПС;

—результаты анализа существующей и возможной инструменталь­ ной среды разработки, а также системы обеспечения качества, перспекти­ вы их развития и совершенствования;

—предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла ПС;

—проект формализованного технического задания и специфика­ ции требований к ПС^ а также предложения по его финансированию и

обеспечению ресурсами;

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

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

Разработка исходных требований для технического задания на проект ПС начинается с анализа результатов обследования объекта ин­ форматизации и оценки доступных ресурсов для реализации проекта. Эта

110

4.2. Процессы системного проектирования программных средств

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

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

Предварительный анализ и моделирование процессов обработки

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

111

Лекция 4. Системное проектирование программных средств

ИСХОДНОМ описании, но и потому, что сложную систему можно описывать, только начиная с основной части ее предметной области, которая затем постепенно расширяется и детализируется.

Моделирование процессов обработки данных при системном проек­ тировании преследует две основные цели:

—моделирование проблемно-ориентированных процессов и конк­ ретных функциональных задач с целью исследования принципов, методов

ихарактеристик обработки информации и принятия решений для последу­ ющего их использования в проектах;

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

При построении формализованного описания системы, выполняемом ее разработчиком, принципиальными являются два организационных мо­ мента: специалисты — заказчики или пользователи создаваемой системы должны активно участвовать в процессе анализа и реализации ее описа­ ния; каждый шаг описания должен обязательно документироваться. На­ глядными и удобными в работе являются графические представления описаний проектных решений, которые позволяют создавать прототипы ПС. Они обеспечивают эффективную визуализацию и обратную связь меж­ ду разработчиком и потенциальным пользователем с целью оценки реали­ зации требований, корректировки функций и качества компонентов, а так­ же форм пользовательского интерфейса. Для этого разработана целая гам­ ма методологий для моделирования, структурного анализа и визуального проектирования. Современные инструментальные CASE-средства обеспе­ чивают широкие возможности выбора процессов моделирования, автома­ тизированного анализа системных предложений и выработки первичных требований к предполагаемому проекту ПС. Схемы потоков данных, пото­ ков управления, сущность-связь и другие — составляют комплекс удоб­ ных и гибких графических методов и средств описания систем, облегчаю­ щих взаимопонимание мелсду разработчиками и заказчиками на раз­ ных уровнях детализации функций, качества и архитектуры ПС.

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

112

Лекция 4. Системное проектирование программных средств

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

Такое постепенное повышение достоверности прогнозов приводит к целесообразности оценки достигаемых значений качества по этапам и к возможности разработки укрупненного, поэтапного плана выполнения всего комплекса работ в ЖЦ ПС. Эти данные позволяют принимать решения по корректировке требований к ПС, по изменению среды разработки или состава коллектива специалистов. Таким образом, последовательное про­ гнозирование, планирование и системное управление проектом обеспечи­ вают рациональное использование ресурсов в процессе создания слож­ ных ПС гарантированного качества.

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

114

4.2. Процессы системного проектирования программных средств

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

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

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

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

115

Лекция 4. Системное проектирование программных средств

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

4.3. Структурное проектирование сложных программных средств

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

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

— стандартизированную структуру целостного построения ПС и/или БД определенного класса;

116

4.3.Структурное проектирование сложных программных средств

—унифицированные правила структурного построения функциональ­ ных программных компонентов и модулей;

—стандартизированную структуру базы данных, обрабатываемых программами;

—унифицированные правила структурного построения информаци­ онных модулей, заполняющих базу данных;

—унифицированные правила организации и структурного построе­ ния межмодульных интерфейсов программных компонентов;

—унифицированные правила внешнего интерфейса и взаимодействия компонентов ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы.

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

Разделение общей задачи системы и программного средства на компоненты — это использование принципа здравого смысла, который должен быть применен в системной разработке крупного ПС для преодо­ ления свойственной ему сложности. Очень часто многие решения прочно взаимосвязаны и взаимозависимы. Когда различные проектные решения прочно взаимосвязаны, то бывает полезно, чтобы всеми ими сразу занима­ лись в одно и то же время одни и те же люди, но на практике это обычно невозможно. Единственный способ справиться со сложностью проекта — разделить задачи. Прежде всего, необходимо пытаться изолировать функ­ ции, которые менее всего связаны с другими. Затем рассматривать раз­ дельно функции, учитывая имеющие отношения ме^кду собой и детали связанных проблем.

117

Лекция 4. Системное проектирование программных средств

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

—эффективные и удобные средства описания свойств и особеннос­ тей структуры создаваемой системы — нотации описания;

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

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

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

—соответствие функций и структуры ПС аппаратной и операцион­ ной среде, их ресурсам и интерфейсам;

—совместимость ПС с другими системами по источникам и пот­ ребителям информации;

—соответствие стандартам структурного построения и интерфейсов комплекса программ, функциональных компонентов и модулей;

—предварительная организация информационного обеспечения и структура базы данных;

—состав, структура и способы обмена данными между функцио­ нальными компонентами и внешней средой ПС;

—временной регламент и предварительные характеристики процес­ сов реализации функций, интенсивность и объемы потоков информации базы данных;

118

4.3.Структурное проектирование сложных программных средств

—контроль, хранение, обновление, защита и восстановление про­ грамм и данных;

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

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

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

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

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

—вертикальная соподчиненность, заключающаяся в последователь­ ном упорядоченном расположении взаимодействующих компонентов, со­ ставляющих ПС;

—право вмешательства и приоритетного воздействия сверху вниз на компоненты нижних уровней;

—взаимозависимость действий компонентов верхних уровней от ре­ акций на воздействия и от функционирования компонентов нижних уров­ ней, информация о которых передается верхним уровням.

119