Как уже отмечалось, спецификация качества определяет основные ориентиры (цели), которые на всех этапах разработки программного средства влияют на выбор варианта его реализации. Однако каждый примитив качества имеет свои особенности, а его обеспечение требует своих подходов и методов разработки средства или отдельных его частей. Кроме того противоречивость критериев качества, соответственно и выражающих их примитивов, существенно затрудняет их совместное обеспечение. Поэтому обеспечение качества средства — это процесс поиска приемлемых компромиссов. Частично компромиссы определяются уже в спецификации качества. Модель качества конкретизирует степень присутствия в программном средстве примитивов качества и определяет приоритеты достижения этих степеней.
Обеспечение качества реализуется в каждом технологическом процессе, поскольку примитивы качества связаны со свойствами как программ, так и документации. В силу противоречивости примитивов важно придерживаться выбранных приоритетов в их обеспечении. При этом следуют двум принципам:
· в первую очередь обеспечь функциональность и надежность программного средства, а затем доводи до приемлемого уровня остальные критерии качества;
· не следует добиваться более высокого уровня реализации примитива качества, чем тот, который определен в спецификации качества программного средства.
12.2. Обеспечение легкости применения программного средства.
Легкость применения определяется составом и качеством пользовательской документации и некоторыми свойствами, реализуемыми программным путем.
С пользовательской документацией связаны такие примитивы качества, как П-документированность и информативность. Обеспечением этих свойств занимаются технические писатели. Этот вопрос будет обсуждаться в следующей лекции. Здесь отметим, что речь идет об автономной по отношению к программам документации. Однако в настоящее время широко используется весьма перспективный подход информирования пользователя в интерактивном режиме, т.е. в процессе применения программ. Такое информирование более удобно пользователю, чем работа с автономной документацией, так как позволяет оперативно вызывать нужную информацию посредством контекста вызова.
Программным путем реализуются такие примитивы качества как коммуникабельность, устойчивость и защищенность. Обеспечение устойчивости и защищенности уже было рассмотрено в предыдущей лекции. Коммуникабельность обеспечивается реализацией возможностей обработки исключительных ситуаций и развитым пользовательским интерфейсом.
Инициация исключительной ситуации производится при необходимости информирования пользователя о ходе выполнения программы. При этом выдаваемая информация должна быть проста для понимания. Исключительные ситуации возникают обычно на достаточно низком уровне модульной структуры программы, а создать понятное для пользователя сообщение можно, как правило, на более высоких уровнях этой структуры, где известен контекст, в котором были активизированы действия, приведшие к возникновению исключительной ситуации. Для обработки исключительной ситуации, возникшей в модуле, приходится принимать непростые решения. Применяемый способ передачи информации об исключительной ситуации по цепочке обращений к программным модулям (в обратном направлении) требует дополнительных проверок после возврата из модуля и усложняет само обращение к ним из-за наличия дополнительных параметров. Эффективным решением этой проблемы является включение в операционную среду выполнения программ (в исполнительную поддержку) возможностей прямой передачи информации обработчикам исключительных ситуаций по динамически формируемой их очереди.
Пользовательский интерфейс представляет средство взаимодействия пользователя с программным средством. При разработке интерфейса следует учитывать потребности, опыт и способности пользователя, поэтому они должны быть вовлечены в процесс его разработки. Большой эффект здесь дает прототипирование, при котором пользователи получают доступ к прототипам интерфейса, а их оценка возможностей используемого прототипа учитывается при создании окончательного варианта интерфейса.
В силу большого разнообразия пользователей и видов программных средств существует множество различных стилей пользовательских интерфейсов, при разработке которых используются разные принципы и подходы. Но в любых случаях интерфейс должен:
· базироваться на терминах и понятиях, знакомых пользователю,
· быть единообразным,
· обеспечивать пользователю возможности исправления своих ошибок,
· обеспечивать получение справочной информации по запросу пользователя и генерируемой программным средством.
В настоящее время широкое распространение получили командные и графические пользовательские интерфейсы.
Командный пользовательский интерфейс предоставляет пользователю возможность обращаться к средству с некоторым заданием (запросом), представляемым в текстовом виде (командой) на специальном языке (языке заданий). Достоинствами интерфейса является его реализуемость на дешевых алфавитно-цифровых терминалах и минимальный объем вводимой с клавиатуры пользователем информации. К его недостаткам следует отнести необходимость в изучении командного языка и достаточно большая вероятность ошибки пользователя при задании команды. В связи с этим командный интерфейс обычно выбирают только опытные пользователи, поскольку он реализует быстрое взаимодействие с компьютером и позволяет объединять команды в процедуры и программы (например, язык Shell операционной системы Unix).
Графический пользовательский интерфейс в отличие от командного обеспечивает доступ к средству и получение от него информации посредством графических или текстовых объектов и производит непосредственные манипуляции с ними. Графический интерфейс позволяет размещать на экране монитора множество окон, и с каждым из них работать независимо, использовать управляемый мышью и с клавиатуры экранный указатель для выбора объектов и пиктограммы (т.н. иконки) для смыслового графического выделения объектов. Главным достоинством интерфейса является удобная и понятная пользователю модель взаимодействия с программой (панель управления, рабочий стол и т.п.), не требующая изучения специального языка. Однако его разработка требует больших трудозатрат, сравнимых с трудозатратами по создания самого программного средства. Кроме того, возникает серьезная проблема по переносимости средства из одной операционной среды в другую, так как графический интерфейс существенно зависит от возможностей графических пользовательских платформ, предоставляемых разными операционными системами для его создания. Графический интерфейс обобщает интерфейсы типа меню и прямого манипулирования.
12.3. Обеспечение эффективности программного средства.
Эффективность программного средства обеспечивается принятием соответствующих решений на разных этапах разработки, начиная с создания его архитектуры. На эффективность средства влияют как выбор его структуры и представления данных (проблема памяти), так и подбор алгоритмов и особенности их языковой реализации (проблема времени). При этом постоянно приходится разрешать противоречие между временнόй эффективностью и эффективностью по памяти (ресурсам). Поэтому важно, чтобы в спецификации качества были явно указаны приоритеты или количественное соотношение между показателями этих примитивов. Следует иметь в виду, что программные модули по-разному влияют на эффективность средства в целом. Одни модули полностью забирают временной ресурс и практически не требуют ресурсов памяти, а другие забирают практически весь ресурс памяти, не оказывая заметного влияния на время работы средства. Конкретное воздействие модулей (прежде всего, по временнóй эффективности) заранее далеко не всегда можно правильно оценить.
С учетом этого следует придерживаться принципов:
· сначала разработай надежное средство, а потом доводи его эффективность до уровня, установленного спецификацией качества;
· используй оптимизирующий компилятор;
· если эффективность средства не удовлетворяет спецификации качества, то найди критические по эффективности модули и оптимизируй их посредством ручной доводки;
· не оптимизируй модули, если в этом нет необходимости.
Для отыскания критических по временнóй эффективности модулей необходимо получить карту распределения их времени работы, что можно сделать с помощью динамического анализатора, который определит частоту обращения к каждому модулю и время его работы.
12.4. Обеспечение сопровождаемости программного средства.
Сопровождаемость программного средства обеспечивается его изучаемостью и модифицируемостью.
Изучаемость определяется составом и качеством документации и выражается через ряд примитивов: С-документированность, информативность, понятность, структурированность, удобочитаемость. Последние три примитива качества связаны с текстами программных модулей, по поводу которых и дадим общие рекомендации, определяющие практически оправдавший себя стиль программирования:
· начиная с ранней стадии разработки модуля, используй в его тексте комментарии, поясняющие особенности принимаемых решений;
· используй осмысленные (мнемонические) и различимые имена (размер — 4-12 литер, цифры — в конце) и не используй сходные имена и ключевые слова;
· соблюдай осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля);
· не бойся использовать необязательные скобки — они обходятся дешевле, чем ошибки;
· размещай не более одного оператора в строке, а для прояснения структуры модуля используй отступы в начале каждой строки, этим обеспечишь удобочитаемость текста модуля;
· избегай трюков, т.е. приемов программирования, создающих побочные эффекты, которые скрывают основной эффект модуля.
Структурированность текста модуля уже обсуждалась, а его удобочитаемость обеспечивается автоматически посредством применения специального программного инструмента — форматера.
Модифицируемость средства определяется свойствами документации и свойствами, реализуемыми программным путем. Она выражается через примитивы: расширяемость, модифицируемость, структурированность, модульность.
Загрузка...
