Метод структурного проектирования

2) Описанный подход способствует установлению обратной связи с пользователем в целях выяснения истинных требований к системе.

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

4) Непрерывное итеративное тестирование позволяет объективно оценить состояние проекта.

5) Противоречия в требованиях, проектах и реализациях выявляются раньше.

6) Нагрузка команды (особенно команды тестирования) возрастает по мере развития проекта.

7) Команда может обучаться и вследствие этого непрерывно улучшать процесс.

8) На протяжении всего жизненного цикла проекта его организаторы могут получать реальное представление о текущем состоянии проекта.

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



13. Групповая работа. Характеристика групп программистов. Основные требования к персоналу

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

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

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



14. Причины и подходы модернизации ПО

Необходимость модернизации унаследованных систем может быть вызвана целым рядом причин:

объективным устареванием систем и, как следствие, потерей конкурентного преимущества;

неадекватно большими затратами на поддержку и сопровождение устаревших систем;

необходимостью трансформации ПО в новые, современные формы (например, вывод настольных приложений в веб, присоединение мобильных версий и приложений);

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

недостатком масштабируемости текущих решений в условиях роста бизнеса;

существенным разрывом между имеющейся функциональностью и новыми бизнес-требованиями;

наличием критических архитектурных недостатков, не позволяющих или затрудняющих оперативные изменения и улучшения.

Спектр задач по модернизации систем и приложений, реализуемый специалистами Itransition, включает в себя следующие элементы:

расширение функциональных возможностей;

полная миграция приложений;

миграция данных;

миграция автономных приложений в веб;

оптимизация производительности;

системная интеграция.

15. Динамика развития программ. Законы Лемана

Под динамикой развития программ подразумевается исследование изменений в программной системе. Результатом этих исследований стало появление ряда "законов" Лемана (Lehman), относящихся к модернизации систем.

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

Эти законы (в сущности, не законы, а гипотезы) приведены в табл. 1.

Таблица 1 Законы Лемана

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

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

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

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

Четвертый закон Лемана утверждает, что крупные проекты по разработке программного обеспечения действуют в режиме "насыщения". Это означает, что изменения ресурсов или персонала оказывает незначительное влияние на долгосрочное развитие системы. Это, правда, уже указано в третьем законе, который утверждает, что развитие программы не зависит от решений менеджмента. Этим законом также утверждается, что крупные команды программистов неэффективны, так как время, потраченное на общение и внутрикомандные связи, превышает время непосредственной работы над системой.

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

16. Сопровождение ПО

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

Существует три вида сопровождения системы.

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

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

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

Наиболее существенные изменения при этом претерпевает именно программное обеспечение.

На практике однозначно четкое разграничение между различными видами сопровождения провести достаточно сложно.

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

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

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

17. Понятие, этапы, преимущества реинженеринга ПО

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

С технической точки зрения реинжениринг - это решение "второго сорта" проблемы системной эволюции. Если учесть, что архитектура системы не изменяется, то сделать централизованную систему распределенной представляется делом довольно сложным. Обычно нельзя изменить язык программирования старых систем на объектно-ориентированные языки (например, Java или C++). Эти ограничения вводятся для сохранения архитектуры системы.

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

Код эксплуатируемых в настоящее время программных систем чрезвычайно огромен. В 1990 году Улрич насчитал 120 млрд. строк исходного кода эксплуатируемых в то время программ. При этом большинство программ были написаны на языке COBOL, который лучше всего подходит для обработки данных в деловой сфере, и на языке FORTRAN. У этих языков достаточно ограниченные возможности в плане структуризации программ, aFORTRAN к тому же отличается ограниченной поддержкой структурирования данных.

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

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

По сравнению с более радикальными подходами к совершенствованию систем реинжениринг имеет два преимущества.

1. Снижение рисков. При повторной разработке ПО существуют большие риски - высока вероятность ошибок в системной спецификации и возникновения проблем во время разработки системы. Реинжениринг снижает эти риски.

2. Снижение затрат. Себестоимость реинжениринга значительно ниже, чем разработка нового программного обеспечения.

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

Основное различие между реинженирингом и новой разработкой системы связано со стартовой точкой начала работы над системой. При реинжениринге вместо написания системной спецификации "с нуля" старая система служит основой для разработки спецификации новой системы.

Рис. 1 Традиционная разработка и реинженирингПО

На рис. 1 показан возможный процесс реинжениринга. В начале этого процесса имеем наследуемую систему, а в результате - структурированную и заново скомпонованную версию той же системы. Перечислим основные этапы этого процесса.

1. Перевод исходного кода. Конвертирование программы со старого языка программирования на современную версию того же языка либо на другой язык.

2. Анализ программ. Документирование структуры и функциональных возможностей программ на основе их анализа.

3. Модификация структуры программ. Анализируется и модифицируется управляющая структура программ с целью сделать их более простыми и понятными.

4. Разбиение на модули. Взаимосвязанные части программ группируются в модули; там, где возможно, устраняется избыточность. В некоторых случаях изменяется структура системы.

5. Изменение системных данных. Данные, с которыми работает программа, изменяются с тем, чтобы соответствовать нововведениям.

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

18. Преобразование исходного кода программы. Усовершенствование структуры программы

Самый простой способ реинжениринга программ - это автоматический перевод исходного кода с одного языка программирования на другой, более современный. При этом структура и организация программ остаются неизменными. Программа может переводиться как на обновленную версию исходного языка (например, с языка COBOL-74 на язык COBOL-85), так и на другой "не родственный" язык (например, с языка FORTRAN на С).

Причины перевода на другой язык могут быть следующие.

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

2. Недостаток квалифицированного персонала. Бывает, что для сопровождения программ на исходном языке невозможно найти достаточно квалифицированный персонал, особенно это касается программ, написанных на специфических языках, давно вышедших из употребления.

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

4. Недостаточно средств поддержки старого ПО. Поставщик компиляторов для старого языка программирования может уйти с рынка программных продуктов или прекратить поддержку своего продукта.

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



Рис. 1 Процесс преобразования программ

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

19. Управление версиями и выпусками ПО

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

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

Выходная версия (release) системы - это та версия, которая поставляется заказчику. В каждой выходной версии либо обязательно присутствуют новые функциональные возможности, либо она разработана под новую платформу. Количество версий обычно намного превышает количество выходных версий, поскольку версии создаются в основном для внутреннего пользования и не поставляются заказчику.

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

20. Определение и типы требований к ПО

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

Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация - детализированное математическое формальное описание системных функций.

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (userrequirements) для обозначения высокоуровневых обобщенных требований и системные требования (systemrequirements) для детализированного описания выполняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы - проектная системная спецификация (softwaredesignspecification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

Различие между пользовательскими и системными требованиями показаны в примере, представленном в табл. 1. Здесь показано, как пользовательские требования могут быть преобразованы в системные.

Пользовательские требования

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

1.1. Пользователь должен иметь возможность определять тип внешних файлов.

1.2. Для каждого типа внешнего файла должно иметься соответствующее средство, применимое к этому типу файлов.

1.3. Внешний файл каждого типа должен быть представлен соответствующей пиктограммой на дисплее пользователя.

1.4. Пользователю должна быть предоставлена возможность самому определять пиктограмму для каждого типа внешних файлов.

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

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

Рис. 1 Различные типы спецификаций требований и их читатели

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

1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

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

3. Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

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

21. Нефункциональные требования

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

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

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

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

Рис. 1 Типы нефункциональных требований



Все нефункциональные требования, показанные на рис. 1, можно разбить на три большие группы.

1. Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объему необходимой памяти, надежности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации. 2. Организационные требования. Отображают политику и организационные процедуры заказчика и разработчика ПО. Они включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию. 3. Внешние требования. Учитывают факторы, внешние по отношению к разрабатываемой системе и процессу ее разработки. Они включают требования, определяющие взаимодействие данной системы с другими системами, юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в рамках существующего законодательства, а также этические требования. Последние должны гарантировать, что система будет приемлемой для пользователей или заказчика.

22. Схема процесса анализа С-требований



23. Схема процесса анализа D-требований

24. Документирование системных требований

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

Если общее количество требований велико, детализированные системные требования могут быть представлены в виде отдельного документа.

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

На рис. 1 показаны категории читателей спецификации.

Рис. 1 Читатели системной спецификации

Хенингер сформулировал шесть условий, которым должна соответствовать спецификация программной системы.

* Описывать только внешнее поведение системы.

* Указывать ограничения, накладываемые на процесс реализации системы.

* Предусматривать возможность внесения изменений в спецификацию.

* Служить справочным средством в процессе сопровождения системы.

* Отображать весь жизненный цикл системы.

* Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993. Данный стандарт предполагает следующую структуру спецификации.

Хотя стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации - разработчике ПО. В табл. 1 описаны возможные разделы спецификации, построенной на основании стандарта IEEE.

Таблица 1 Структура спецификации требований

Раздел	Описание
Предисловие	Здесь определяется круг лиц, на которых рассчитан данный документ. Описываются предыдущие версии разрабатываемого программного продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта
Введение	Здесь более развернуто обосновывается необходимость создания системы. Кратко перечисляются системные функции и объясняется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы "вписывается" в общую бизнес-стратегию компании, заказывающей программный продукт
Глоссарий	Дается описание технических терминов, используемых в документе. Здесь не делается каких-либо предположений об уровне знаний или практическом опыте читателя документа
Пользовательские требования	Описываются сервисы, предоставляемые пользователям, и нефункциональные системные требования. Это описание может быть сделано на естественном языке с использованием диаграмм, блок-схем и других форм записи, понятных заказчику программной системы. Здесь также должны быть приведены стандарты на программный продукт и процесс его разработки
Системная архитектура	Здесь приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (т.е. уже существующие) компоненты
Системные требования	Подробно описываются функциональные и нефункциональные требования. Если необходимо, нефункциональные требования дополняются описанием интерфейсов других систем
Системные модели	Здесь представлено несколько системных моделей, показывающих взаимоотношения между системными компонентами и между системой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных
Эволюция системы	Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п.

25. Модель процесса создания качественной документации

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

1. Стандарты на процесс создания документации. Определяют способ создания технической документации.

2. Стандарты на документ. Определяют структуру и внешний вид документов.

3. Стандарты на обмен документами. Гарантируют совместимость всех электронных версий документов.

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

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

Рис. 1 Процесс создания документации, включающий проверку качества документов

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

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

Приведем примеры различных стандартов на документацию.

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

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

3. Стандарты внешнего вида документации. Эти стандарты определяют “фирменный” стиль документов: использование шрифтов и стилей, логотипов, названия фирмы, цветовых выделений для элементов структуры документа и т.д.

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

Особая роль отводится стандарту на совместимость документов, так как часто приходится работать с разными электронными версиями документов. Использование стандартов на совместимость позволяет осуществлять передачу документов в электронном виде и при необходимости восстанавливать их в первоначальном виде.

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

26. Способы поддержки пользователей

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

* сообщения, генерируемые системой в ответ на действия пользователя;

* диалоговая справочная система;

* документация, поставляемая с системой.

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

Таблица 1 Факторы проектирования текстовых сообщений

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

Размещено на Allbest.ru

...