Проектирование бизнес систем

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

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

Зачастую полезно делить исходную задачу на модули, используя подход «снизу-вверх», а их уже в свою очередь разрабатывать, используя подход «сверху-вниз».

Типы и виды проверок ПО

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

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



Рис. 65 . Виды тестирования

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

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

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

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

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

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

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

· Цель проверки достоверности (валидация) - подтвердить, что выход работы программного обеспечения в обработанном виде годится для заданного использования. «Делаем ли мы корректную программную систему?»

· Цель верификации - подтвердить, что каждый выход процесса или проекта отвечает специфицированным требованиям. «Делаем ли мы программное обеспечение правильно?»

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

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

· Исследование (проверка) кода - в отличие от рассмотренных выше типов тестов, в случае исследования кода код не выполняется, однако инспектируется тестировщиком. Исследование кода предполагает наличие опросных листов, на основе которых оценивают код и ищут в нем ошибки, что в тестах при обычных условиях не делают. Исследователи кода должны быть очень компетентными, например, в части используемого языка. Что ищут? Например, неинициализированные переменные, неподобающе выбранные типы данных переменных, выход переменных или индекса массива за разрешенный предел, порядок действий, совместимость различных типов переменных и т.п.

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

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

· защищенность - свойство продукта ограничивать доступ неавторизованным лицам к бизнес-логике / данным;

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

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

· восстанавливаемость - атрибут продукта, выражающий сложность и необходимый объем работ, и время, необходимое для восстановления основной функциональности системы в случае аварийной ситуации;

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

· применяемость

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

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

o простота использования - атрибут продукта, выражающий гибкость системы и сложность изменения системы конечными пользователями, чтобы сделать систему удобной для себя;

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

· стабильность - атрибут продукта, выражающий величину риска возникновения неожиданного поведения, последующего за внесением изменений продукта;

· повторная используемость - атрибут продукта, выражающий возможность повторного использования компонентов продукта в других программных проектах

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

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



Рис. 66. V-модель тестирования программных продуктов. Модель частично вдохновлена водопадной моделью

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

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

Специальными типами исследований являются:

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

· исследования кода;

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

Самая известная в мире ИТ-аудиторов организация - ISACA (http://www.isaca.org), сертифицированные ее аудиторы носят титул CISA (Certified Information System Auditor - сертифицированный аудитор информационных систем).



Лекция 14-16. Проектирование пользовательского интерфейса

Продукт и дизайн интерфейса, архитектурный дизайн и представление.

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

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

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

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

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

Концептуальный дизайн интерфейса должен базироваться на идее интерфейсной среды. На время работы с?системой пользователь погружается в?среду интерфейса. Слово среда применяется как обозначение типичной для поведения человека в?различных средах связки «сигнал - действие».

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

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

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

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

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

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

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

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

Рекомендации по оформлению

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

Кнопки

Рис. 67 Кнопки бывают нескольких видов:

· кнопки прямого действия (командные кнопки), запускают какое-то действие;

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

· чекбоксы и радиокнопки, позволяют пользователю делать выбор из множества вариантов.

Другие возможные нестандартые решения так или иначе можно отнести к одному из этих трех основных видов кнопок (к примеру, umbrUI -- CSS3 range slider, checkbox + radio button -- нестандартная реализация стандартных кнопок). Кстати говоря, ссылка -- тоже командная кнопка, но ссылки в интерфейсе программ используются гораздо реже, поэтому о них речи не будет.

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

Размер:

· На размер кнопки распространяется закон Фиттса -- чем больше кнопка, тем легче в нее попасть курсором. Из этого следует, что кнопки надо делать большими. Однако это не всегда правильно, в некоторых случаях оправдано использование маленьких кнопок.

· Помимо этого, размеры нескольких кнопок, расположенных в одном окне, должны быть равными или хотя бы пропорциональными.

Положение:

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

· Совершенно неприемлемо удалять из видимости те кнопки, на которые нажать нельзя, взамен этого их необходимо делать неактивными, иначе пользователь будет теряться («клянусь, эта кнопка только что была здесь!»).

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

· Желателен вертикальный порядок чекбоксов и радиокнопок, приемлемо и расположение в две-три колонки, но никак не в разноброс. Пользователь должен сразу видеть, какие кнопки к какой группе относятся.

Текст:

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

· Более внимательно нужно отнестись к использованию к кнопки «ОК» и по возможности заменять «ОК» на соответствующий глагол.

· Желательно совсем отказаться от использования кнопки «Применить», особенно в наборе OK-Применить-Отмена. Такое сочетание кнопок порождает некоторые неопределенности у пользователя, не будем обсуждать какие.

· На кнопке доступа к меню должна быть какая-нибудь индикация о том, что она именно отображает меню (самый лучший вариант -- стрелочка вниз/вбок).

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

· Пользователь скажет вам отдельное спасибо, если подписи к чекбоксам и радиокнопкам так же будут реагировать на нажатие.

Списки

Рис. 68 Кнопки бывают нескольких видов:

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

· Если в списке одиночного выбора присутствует «пустой» элемент, то это не должна быть пустая строка, следует применять мета-элемент «ничего».

· В списке множественного выбора желательно присутствие мета-элемента «все значения».

· По возможности элементы списка должны быть каким-либо образом отсортированы, если не по типу, то хотя бы по алфавиту.

Размер:

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

· Высота списка не должна превышать 7-8 строк. Такое количество элементов легче запоминается.

Поля ввода

Рис. 69 Поля ввода

Размер:

· Ширина поля должна соответствовать объему вводимого текста.

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

Текст:

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

Меню

Текст:

· Название меню должно быть самым эффективным из всех возможных. Идеальный вариант -- название в одно слово.

· Если элемент меню вызывает диалоговое окно, то к названию необходимо приписать троеточие "...".

· Переключающиеся элементы лучше всего отмечать галочкой, нежели менять надпись элемента. Меню не должно меняться с течением времени.

Пиктограммы:

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

Группировка:

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

· Группировать элементы следует максимально логично, причем исходя из логики пользователя, а не программиста.

· Взаимоисключающие элементы желательно помещать в отдельный уровень иерархии.

Контекстное меню:

· Контекстное меню не должно быть единственным способом вызова функций.

· Меню желательно делать не особо длинным, 7-8 элементов.

· В контекстном меню особенно важен порядок -- первыми должны быть более релевантные элементы.

Прочее

· Горизонтальные полосы прокрутки -- это очень плохо. Пользователь их не любит.

· В строке заголовка окна первым должно идти имя документа, а лишь затем -- приложения. Ярким примером служит Microsoft Word 2003: «Microsoft Word -- Document1.doc», и при большом количестве открытых окон в панели задач не будут различимы наименования документов.

· Строку статуса необходимо использовать либо как индикатор состояния системы, либо как панель инструментов для опытных пользователей. Худшим вариантом является использование строки статуса в качестве подсказок при наведении на тот или иной элемент окна.

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

Отклик системы:

· Если системой совершается длительная операция, курсор необходимо сменить на «курсор с часиками». В любом случае, пользователя необходимо уведомить, что система что-то делает, а не простаивает.

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

· Когда система завершила длительную операцию, об этом нужно уведомить пользователя, например «пропищать».

И, главное, не надо бояться копировать успешные и эффективные решения чужих интерфейсов! Интуитивный интерфейс -- это знакомый интерфейс. Единообразие приложений очень важно. Если пользователь, к примеру, привык сохранять документ на сочетание Ctrl+S, то не надо в своем приложении учить его новым сочетаниям клавиш.



Лекция 17. Практическое внедрение систем

Специфика разработки программных средств

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

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

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

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

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



Жизненный цикл программного средства

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

В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС.

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

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

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

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

· Сборочное программирование. Этот подход предполагает, что ПС конструируется, главным образом, из компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми (reusable). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования .

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

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

Рис. 70. Стадии и фазы жизненного цикла ПС

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

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

Кодирование (coding) ПС включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС.

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

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

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

Применение (operation) ПС - это использование ПС для решения практических задач на компьютере путем выполнения ее программ.

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

Понятие качества программного средства

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

Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteria of software quality) принято считать [3.6-3.10]:

· функциональность,

· надежность,

· легкость применения,

· эффективность,

· сопровождаемость,

· мобильность.

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

Надежность подробно обсуждалась в первой лекции.

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

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

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

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

Надежность программного обеспечения

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

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

Рис. 71 .Зависимости стоимости и вероятности обнаружения и исправления ошибок от времени проектирования программного обеспечения

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

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

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

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

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

Обеспечение точности перевода

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

· Поймите задачу;

· Составьте план (включая цели и методы решения);

· Выполните план (проверяя правильность каждого шага);

· Проанализируйте полученное решение.

Преодоление барьера между пользователем и разработчиком

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



Лекция 18. Переход к новой системе

Правила оформления программной документации

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

· техническое задание (назначение, область применения программы, требования, предъявляемые к программе);

· текст программы (запись программы с необходимыми комментариями);

· описание программы (сведения о логической структуре и функционировании программы);

· пояснительная записка (схема алгоритма, общее описание алгоритма и/или функционирования программы, обоснование принятых решений);

· эксплуатационные документы.

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

К эксплуатационным документам относят:

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

· руководство системного программиста (сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения);

· руководство программиста (сведения для эксплуатации программы);

· руководство оператора (сведения для обеспечения общения оператора с вычислительной системой в процессе выполнения программы);

· описание языка (описание синтаксиса и семантики языка);

· руководство по техническому обслуживанию (сведения для применения тестовых и диагностических программ при обслуживании технических средств)

Основная часть программной документации составляется на стадии рабочего проекта. Необходимость того или иного документа определяется на этапе составления технического задания. Допускается объединять отдельные виды документов.

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

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

Техническое задание

В техническое задание включают:

· введение (наименование, краткая характеристика области применения программы);

· основания для разработки (документы, на основании которых ведётся разработка, организация, утвердившая документы, дата утверждения, наименование и обозначение темы разработки);

· назначение разработки (функциональное и эксплуатационное назначение программы);

· требования к программе и программной документации;

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приёмки.

Наиболее существенной частью технического задания является раздел "требования..." В этом разделе приводятся:

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

· требования к надёжности (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа);

· требования к информационной и программной совместимости (требования к информационным структурам на входе и выходе, методам решения, исходным кодам, языкам программирования и программным средствам; требования к защите информации);

· требования к составу и параметрам технических средств;

· требования к программной документации.

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

Кроме явно описанных в техническом задании требований, следует придерживаться общепринятых правил разработки программ с учётом выбранной парадигмы программирования:

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

2. Алгоритм должен быть структурирован: для функционального стиля программирования - адекватное разбиение на функции (процедуры), для объектно-ориентированного - адекватная иерархия классов. Каждая функция (метод класса) должна реализовывать ровно одно действие.

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

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

5. Должны проверятся диапазоны вводимых пользователем значений и параметров, передаваемых между модулями программы.

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

7. Программа должна быть конфигурируема (важные параметры программы следует выделить в единый блок).

Текст программы

Текст программы представляет собой символическую запись на исходном или промежуточном языке или символическое представление машинных кодов. Текст программы оформляется моноширинным шрифтом (Courier, Lucida Console и т. п.) в соответствии с общепринятыми нормами оформления:

1. Количество операторов на строчке должно быть равно 1.

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

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

4. Если синтаксис языка позволяет, желательно отделять знаки операций пробелами от операндов. Как и в обычном тексте, после запятых должен следовать пробел.

5. Определения функций или логические части программы следует отделять друг от друга пустыми строками.

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

7. Текст программы должен содержать комментарии, отражающие функциональное назначение того или иного блока программы, структуру программы.

Описание программы

Документ "Описание программы" содержит:

· общие сведения (обозначение наименование программы, программное обеспечение, необходимое для функционирования программы, языки программирования, на которых написана программа);

· функциональное назначение (классы решаемых задач, сведения о функциональных ограничениях на применение);

· описание логической структуры (алгоритм программы, используемые методы, структура программы с описанием составных частей и связи между ними);

· используемые технические средства (типы ЭВМ и устройств, которые используются при работе программы);

· вызов и загрузка (способ вызова программы с соответствующего носителя данных);

· входные данные (характер, организация и предварительная подготовка входных данных, а также их формат, описание и способ кодирования);

· выходные данные (характер и организация выходных данных, а также их формат, описание и способ кодирования).

Описание логической структуры программы следует сопровождать блок-схемой программы.

Документ "Описание программы" может содержать также схемы данных, схемы взаимодействия программ, схемы ресурсов системы и проч., оформленные в соответствии с ГОСТом..

...