4 курс (заочка) / Учебное пособие / Tekhnologii_programmirovania

- 63 -

Рассмотрим, каким образом можно обеспечить оставшиеся четыре критерия качества.

12.2. Меры по обеспечению лёгкости применения ПС. Пользовательский интерфейс

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

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

Пользовательский интерфейс (ПИН) – средство взаимодействия пользователя с ПС. Разработка ПИН должна учитывать потребности, опыт, и способности пользователя. При этом очень эффективно прототипирование.

Принципы, которые следует соблюдать при разработке ПИН [1]:

1)ПИН должен базироваться на знакомых пользователю терминах и понятиях;

2)ПИН должен быть единообразным;

3)ПИН должен давать возможность пользователю исправлять свои ошибки;

4)ПИН должен снабжать пользователя справочной информацией. Распространено два вида ПИН: командные и графические.

Командный ПИН позволяет пользователю обращаться к ПС с некоторым запро-

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

Графический ПИН соединяет в себе интерфейс типа «меню» и интерфейс прямого манипулирования. Этот вид интерфейса предоставляет следующие возможности:

-64 -

1)обращение к ПС путём выбора на экране подходящего объекта (графика,

текст);

2)получение от ПС информации на экране в виде графики и текста;

3)возможность прямого манипулирования графическими объектами на экране;

4)использование пиктограмм, иконок для обозначения процессов, объектов, ресурсов;

5)размещение на экране множества окон и вывод в них независимой информа-

ции;

6)использование экранного указателя для выбора объекта.

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

12.3. Меры по обеспечению эффективности ПС

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

тиворечия между временной эффективностью и эффективностью по памяти.

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

Рекомендации с точки зрения обеспечения эффективности ПС [2, 6]:

1)сначала разработать надёжное ПС, а затем доводить его эффективность до требуемого уровня по СК;

2)для повышения эффективности желательно использовать оптимизирующие компиляторы;

3)в случае несоответствия эффективности ПС спецификации качества, надо найти критические модули, влияющие на эффективность, и переделать их вручную;

-65 -

4)действуйте по проверенному принципу: «Лучшее – враг хорошего». То есть

не оптимизируйте модуль, если это не требуется для достижения требуемой эффективности ПС.

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

12.4. Меры по обеспечению сопровождаемости ПС

Реализация данного критерия сводится к обеспечению изучаемости и модифицируемости ПС. Изучаемость ПС (подкритерий) определяется составом и качеством сопроводительной документации ПС и выражается через следующие примитивы: С-документированность (собственно документируемость), информативность, понятность, структурированность и удобочитаемость (последние два примитива определяются внешним видом текстов программ). Окончательное оформление текстов ПМ желательно выполнять с помощью таких рекомендаций [2, 6]:

1)использовать в тексте модуля комментарии, которые объясняют принимаемые решения, начиная с самых ранних стадий;

2)использовать осмысленные и различные имена (оптимальная длина имени от 4 до 12 символов), избегать сходных имён;

3)соблюдать осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в ПМ);

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

5)размещать в строке не больше одного оператора, используя сдвиги операторов при вложенных конструкциях для объяснения структуры ПМ (поддерживать удобочитаемость ПМ);

6)не использовать такие приёмы программирования ПМ, эффект которых не очевиден или скрыт (побочные эффекты функций).

Модифицируемость ПС (подкритерий качества) определяется частично свойствами документации и свойствами, реализуемыми программным путём и выра-

- 66 -

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

12.5. Меры по обеспечению мобильности

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

Мобильность ПС определяется следующими примитивами: независимость от устройств, автономность, структурированность, модульность.

Условия перенесения ПС с одной аппаратной платформы на другую [1]:

–написание программных модулей ПС на машинно-независимом языке программирования;

–независимость от устройств;

–перетрансляция программных модулей в новой среде.

Понятно, что это идеальная ситуация. И к этому нужно стремиться, выделяя в ПС как можно больше модулей с такими свойствами.

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

Обеспечение мобильности ПС требует решения двух задач [1]:

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

-67 -

2)обеспечение сопровождаемости остальных программ ПС.

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

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

13. Управление процессом разработки ПС

Управление разработкой ПС – это комплекс мероприятий, обеспечивающих необходимые условия для работы коллектива разработчиков. Кроме того, обеспечиваются планирование и контроль деятельности этого коллектива, а также выполнение сроков и бюджета проекта [5]. Другими словами это называют управлением программным проектом. Целью или результатом этой деятельности является обеспечение требуемого качества ПС. Под программным проектом понимается совокупность работ, связанных с разработкой ПС. А ход выполнения этих работ – развитие проекта.

Необходимые условия для работы коллектива разработчиков:

–помещения;

–аппаратно-программные средства;

- 68 -

–документация;

–финансы.

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

Выделяют основные этапы управления разработкой ПС:

1)определение плана разработки ПС;

2)планирование и составление расписания разработки ПС;

3)планирование и управление издержками разработки ПС;

4)текущий контроль, документирование деятельности, связанной с разработкой ПС;

5)подбор и оценка коллектива разработчиков ПС.

Обычно разработка ПС производится в организации, ведущей несколько аналогичных разработок. Управление программными проектами реализуется иерархической или древовидной структурой управления [1, 9]. Во главе иерархии стоит директор, который отвечает за все проекты, разрабатываемые организацией. Ему подчиняются несколько менеджеров-разработчиков, которые курируют отдельные проекты, и менеджер по качеству ПС.

В обязанности менеджера-разработчика входит управление разработками ПС определённого типа (ПС для бизнеса, экспертные системы, офисные приложения и т.д.). Ему непосредственно подчинены менеджеры проектов, относящихся к его области. Менеджеры проектов управляют развитием своих проектов, планируют и составляют расписания работ бригад по разработке соответствующего ПС.

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

- 69 -

(относительно независимых) подпроектов, выполняемых бригадой из 8-10 человек. Архитектура разрабатываемого ПС должна позволять легко «собирать» систему из независимых подсистем через простой и чётко определённый интерфейс.

Ворганизации бригад наиболее часто используют такие подходы [1]:

– обычная бригада;

– неформально-демократическая бригада;

– бригада ведущего программиста.

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

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

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

– ведущий программист (лидер);

– дублёр ведущего программиста;

– администратор базы данных разработки.

Дублёр также является квалифицированным и опытным программистом, способным заменить ведущего программиста. Роль дублёра сводится к следующему – быть в курсе всего, что делает ведущий и быть критиком или оппонентом ведущего при обсуждении его предложений.

- 70 -

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

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

Итог всему процессу разработки ПС подводит аттестация ПС. Аттестация ПС – это авторитетное подтверждение качества ПС [1, 5]. Авторитетность достигается тем, что аттестацию ПС проводит комиссия. Комиссия проводит приёмосдаточные испытания ПС, в результате которых получают информацию по оценке качества ПС. Испытанием является комплекс мероприятий по определению пригодности ПС для успешной эксплуатации в соответствии с требованиями заказчика. Комиссия анализирует информацию, полученную в результате испытаний, и определяет соответствие ПС объявленным примитивам и критериям качества. Результаты работы комиссии фиксируются в специальном документе (акте или сертификате) и подписываются членами комиссии.

14.Компьютеризация разработки и сопровождения ПС

14.1.Инструменты и инструментальные среды разработки ПС

Разработка программных средств невозможна без компьютерной поддержки

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

- 71 -

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

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

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

1)редакторы;

2)анализаторы;

3)преобразователи;

4)инструменты поддержки процессов выполнения программ.

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

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

- 72 -

Второе производят с целью выявления распределения времени работы ПС по программным модулям.

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

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

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

ки и сопровождения ПС.

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

Множество инструментальных сред можно классифицировать по следующим признакам [1]:

1)ориентированность на конкретный язык программирования;

2)специализированность;

3)комплексность;

4)ориентированность на конкретную ТП;

5)ориентированность на коллективную разработку;

6)интегрированность.

Ориентированность на конкретный язык программирования показывает,

моноили полипрограммна инструментальная среда. В первом случае инструментальная среда вместе с инструментами более удобны для использования. Но гра-