Качество программных систем.

Каждая программа, входящая в систему, должна отвечать таким требованиям, как правильность, точность, совместимость, надежность, универсальность, защищенность, полезность, эффективность, проверяемость и адаптируемость. Будем говорить, что программа является

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

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

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

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

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

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

- полезной, если задача, которую она решает, представляет практическую ценность;

- эффективной, если объем требуемых для ее работы ресурсов не превышает допустимого предела;

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

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

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

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

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

Среда пользователей.

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

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

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

Среда ЭВМ.

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

Среда заказчика.

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

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

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

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

Среда разработчиков.

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

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

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

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

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

Понятие потока данных.

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

Методология проектирования (неформальная):

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

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

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

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

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

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

Качество программных систем. - student2.ru