Лицензирование услуг по информационному обеспечению потребителей информационных ресурсов — Студопедия.Нет

Согласно ст. 18 Закона “Об участии в международ­ном информационном обмене” одним из видов лицензи­рования в области связи и информатизации в Российской Федерации является лицензирование деятельности по международному информационному обмену.

Деятельность по международному информационно­му обмену включает:

• сбор, обработку, хранение и передачу информа­ции, а также использование документированной информации и информационных ресурсов при международном информационном обмене;

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

• получение документированной информации, ин­формационных ресурсов, информационных про­дуктов;

• оказание информационных услуг.

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

Объектами международного информационного об­мена являются: документированная информация, ин­формационные ресурсы, информационные продукты, информационные услуги и средства международного информационного обмена.

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

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

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

Субъектами международного информационного об­мена могут являться:

• Российская Федерация;

• субъекты Российской Федерации;

• органы государственной власти и органы местно­го самоуправления;

• физические и юридические лица Российской Фе­дерации;

• физические и юридические лица иностранных го­сударств;

• лица без гражданства.

В соответствии с “Положением о лицензировании деятельности по международному информационному обмену”, утвержденному Постановлением Правитель­ства РФ от 03 июля 1998 года № 564, федеральным орга­ном исполнительной власти, уполномоченным на ведение лицензионной деятельности по международному обмену федеральными информационными ресурсами и информаци­онными ресурсами, находящимися в совместном ведении Российской Федерации и субъектов Российской Федера­ции, определен Государственный комитет Российской Федерации по связи и информатизации (как мы уже от­мечали, его правопреемником являлся Государственный комитет Российской Федерации по телекоммуникациям, в настоящее время – Министерство Российской Федера­ции по связи и информатизации), а лицензирование деятелъности по международному информационному обмену информационными ресурсами субъектов Российской Фе­дерации уполномочены осуществлять органы исполни­тельной власти субъектов Российской Федерации.

Методическое обеспечение лицензирования дея­тельности по международному информационному обме­ну осуществляет Минсвязи России.

Порядок взаимодействия Минсвязи России с органа­ми исполнительной власти субъектов Российской Федера­ции включает:

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

• установление структуры записи “Сводного реест­ра выданных, зарегистрированных, приостано­вленных и аннулированных лицензий” и структуры номера лицензии, присваиваемого лицензионными органами субъектов Российской Федерации;

• организацию изготовления бланков лицензий и определение организации – изготовителя этих бланков;

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

• проведение анализа лицензионной деятельности и совместную разработку мер по ее совершенство­ванию.

Минсвязи России разработало общие требования к заявителям и определило лицензионные условия, необ­ходимые для осуществления деятельности по междуна­родному информационному обмену, а также установило форму описания имеющихся у заявителя информацион­ных ресурсов и аппаратно-программных средств, струк­туру записи “Сводного реестра выданных, зарегистри­рованных, приостановленных и аннулированных лицен­зий” и структуру номера лицензии, присваиваемого ли­цензионными органами субъектов Российской Феде­рации.

Лицензионные органы субъектов Российской Феде­рации:

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

– по итогам лицензионной деятельности ежеквар­тально направляют в Минсвязи России информацию о выданных, зарегистрированных, приостановленных и аннулированных лицензиях по международному инфор­мационному обмену в соответствии со структурой запи­си Сводного реестра.

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

В соответствии с Законом “Об участии в междуна­родном информационном обмене” и во исполнение По­становления Правительства Российской Федерации от 03.06.98 № 564 “Об утверждении Положения о лицензи­ровании деятельности по международному информационному обмену” Минсвязи России разработало и внед­рило ряд нормативно-правовых документов, в том числе:

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

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

В соответствии с вышеуказанными Законом и по­становлением Правительства Российской Федерации мэром г. Москвы издано распоряжение “О лицензиро­вании деятельности по международному информацион­ному обмену” от 31 декабря 1998 года № 1331-РМ, в ко­тором ставятся конкретные задачи Московской лицен­зионной палате о проведении необходимых организаци­онных мероприятий по созданию (на уровне субъекта Российской Федерации) органа лицензирования деятель­ности по международному информационному обмену.

В соответствии с Методическими рекомендациями по осуществлению лицензионной деятельности по меж­дународному информационному обмену лицензионными органами субъектов Российской Федерации, утвержден­ными приказом Госкомсвязи России от 10 июля 1998 го­да, заявителями на получение лицензии могут быть уч­реждения и предприятия культуры, науки, образования и иных сфер деятельности, а также коммерческие органи­зации, осуществляющие свою деятельность с использо­ванием информационных ресурсов, находящихся в веде­нии субъектов Российской Федерации, и за счет (с привлечением) средств бюджетов субъектов Россий­ской Федерации.

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

В настоящее время Федеральным унитарным госу­дарственным предприятием Московский научно-исследовательский центр реализуется проект “Разработка организационно-методического и про­граммно-аппаратного обеспечения системы лицензиро­вания в сфере информатизации”.

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

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

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

• разработку Сборника организационно-мето­дических документов по организации и проведению лицензионной деятельности по международному информационному обмену для субъектов Россий­ской Федерации;

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

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

Разработка программно-аппаратных средств веде­ния “Сводного реестра выданных, приостановленных и аннулированных лицензий” предусматривает создание программно-аппаратного комплекса (автоматизированной информационной системы – АИС), обес­печивающей ведение указанного реестра и взаимодействие в телекоммуникационном режиме с лицензионными орга­нами субъектов Российской Федерации.

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

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

Автоматизированная система по ведению Сводного реестра создаст условия для повышения производитель­ности труда специалистов по лицензированию.

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

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

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

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

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

Основная доля трудозатрат при создании ИЭС приходится на прикладное программирование и базы данных. Производство ПО – это крупнейшая отрасль мировой экономики, в которой занято около трех млн. специалистов.

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

В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).

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

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

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

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

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

· Необходимость интеграции существующих и вновь разрабатываемых приложений.

· Функционирование в неоднородной среде на нескольких аппаратных платформах.

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

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

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

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

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

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

Понятие ЖЦ ПО. Международный стандарт ISO/IEC 12207: 1995. Основные и вспомогательные процессы ЖЦ ПО. Организация процессов ЖЦ. Связь между процессами.

Понятие ЖЦ

Жизненный цикл (ЖЦ) программного обеспечения (ПО) определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 “Information Technology – Software Life Cycle Processes” (ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

В России существуют стандарты:

ГОСТ 34601 – 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

ГОСТ 34601 – 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

ГОСТ 34601 – 92. «Информационная технология. Виды испытаний автоматизированных систем».

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

В соответствии с ISO/IEC 12207: 1995 все процессы ЖЦ ПО разделены на три группы:

Основные процессы:

· приобретение;

· поставка;

· разработка;

· эксплуатация;

· сопровождение.

Вспомогательные процессы:

· документирование;

· управление конфигурацией;

· обеспечение качества;

· верификация;

· аттестация;

· совместная оценка;

· аудит;

· разрешение проблем.

Организационные процессы:

· управление;

· усовершенствование;

· создание инфраструктуры;

· обучение.

Основные процессы

Процесс приобретениясостоит из действий и задач заказчика:

Действие – инициирование приобретения – включает задачи:

· определение заказчиком своих потребностей в приобретении;

· анализ требований к системе;

· принятие решения относительно приобретения;

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

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

Действие – подготовка заявочных предложений. Заявочные предложения должны содержать:

· требования к системе;

· перечень программных продуктов;

· условия и соглашения;

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

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

Действие – подготовка и корректировка договора – включает задачи:

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

· выбор конкретного поставщика на основе анализа предложений.;

· подготовку и заключение договора с поставщиком;

· внесение изменений (при необходимости) в договор в процессе его выполнения.

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

 В процессе приемкиподготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.

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

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

Планирование включает задачи:

· принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;

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

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

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

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

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

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

· внешних интерфейсов;

· спецификаций надежности и безопасности;

· эргономических требований;

· требований к используемым данным;

· требований к установке и приемке;

· требований к пользовательской документации;

· требований к эксплуатации и сопровождению.

Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.

Проектирование архитектуры ПО включает задачи (для каждого компонента ПО):

· трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав ее компонентов;

· разработку и документирование программных интерфейсов ПО и баз данных;

· разработку предварительной версии пользовательской документации;

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

Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

Детальное проектирование ПО включает следующие задачи:

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

· разработку и документирование детального проекта базы данных;

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

· разработку и документирование требований к тестам и плана тестирования компонентов ПО;

· обновление плана интеграции ПО.

Кодирование и тестирование ПО охватывает задачи:

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

· тестирование каждого компонента ПО и базы данных на соответствие предъявляемых к ним требованиям. Результаты тестирования компонентов должны быть документированы;

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

· обновление плана интеграции ПО.

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

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

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

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

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

Процесс эксплуатацииохватывает действия и задачи оператора – организации, эксплуатирующей систему и включает действия:

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

· планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;

· определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

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

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

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

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

Процесс сопровождения охватывает следующие действия:

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

· планирование действий и работ, выполняемых в процессе сопровождения;

· определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

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

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

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

· утверждение выбранного варианта модификации.

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

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

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

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

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

Процесс документирования включает действия:

· подготовительную работу;

· проектирование и разработку;

· выпуск документации;

· сопровождение.

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

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC 12207-2: 1995 “Information Technology – Software Life Cycle Processes. Part2. Configuration Management for Software”.

Процесс управления конфигурацией включает действия:

· подготовительную работу (планирование управления конфигурацией);

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

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

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

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

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

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

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

Процесс обеспечения качества включает действия:

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

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

· обеспечение качества процессапредполагает гарантирование соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам;

· обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом ISO 9001.

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

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

Процесс верификации включает следующие действия:

· подготовительную работу;

· верификацию;

В процесс верификации проверяются следующие условия:

– непротиворечивость требований к системе и степень учета потребностей пользователей;

– возможности поставщика выполнять заданные требования;

– соответствие выбранных процессов ЖЦ ПО условиям договора;

– адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

– соответствие проектных спецификаций ПО заданным требованиям;

– корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

– соответствие кода проектным спецификациям и требованиям;

– тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

– корректность интеграции компонентов ПО в систему;

– адекватность, полнота и непротиворечивость документации.

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

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

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

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

Процесс совместной оценки включает действия:

· подготовительную работу;

· оценку управления проектом;

· техническую оценку.

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

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

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

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

Процесс управления включает следующие действия:

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

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

– составление графиков выполнения работ;

– оценку затрат;

– выделение требуемых ресурсов;

– распределение ответственности;

– оценку рисков, связанных с конкретными задачами;

– создание инфраструктуры управления.

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

Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

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

Связь между процессами ЖЦ ПО

Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (рис.1). Такими аспектами являются:

· договорный аспект;

· аспект управления;

· аспект эксплуатации;

· инженерный аспект;

· аспект поддержки.

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

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

Лекция 11. Модели и стадии ЖЦ ПО

Понятие модели ЖЦ ПО (каскадная, спиральная). Стадии: формирование требований к ПО; проектирование; реализация; тестирование; ввод в действие; эксплуатация и сопровождение; снятие с эксплуатации. Подход RAD. Модели качества процессов проектирования.

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

Международный стандарт ISO/IEC 12207: 1995 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать и выполнить действия и задачи, включенные в эти процессы.

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

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

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

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

Планирование работ, предваряющее работы над проектом. Основными задачами являются:

· определение целей разработки;

· предварительная экономическая оценка проекта;

· построение плана – графика выполнения работ;

· создание и обучение совместной рабочей группы.

Проведение обследования деятельности автоматизируемого объекта (организации), в рамках которого осуществляются:

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

· определение структуры организации;

· определение перечня целевых функций организации;

· анализ распределения функций по подразделениям и сотрудникам;

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

· анализ существующих средств автоматизации деятельности организации.

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

· модели “ AS – IS ” («как есть») , отражающей существующее на момент обследования положение дел в организации и позволяющее понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

· модели “ TO – BE ” («как должно быть»), отражающей представление о новых технологиях работы организации.

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

Переход от модели “ AS – IS” кмодели “ TO – BE ” может выполняться двумя способами:

· совершенствованием существующих технологий на основе оценки их эффективности;

· радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

Построенные модели имеют самостоятельное практическое значение. Например, модель “ AS – IS” позволяет выявить узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм (известно, что «одна картинка стоит тысячи слов»).

Стадия проектированиявключает этапы:

Разработка системного проекта. На этом этапе дается ответ на вопрос: «Что должна делать будущая система?», а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели “ TO – BE ”. Документальным результатом является техническое задание.

Разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

К настоящему времени наибольшее распространение получили следующие две модели ЖЦ ПО: каскадная (1970-1985) и спиральная (1986-1990).

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

Рис.1. Каскадная модель

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

Преимущества применения каскадного способа:

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

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

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

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

Рис. 2. Итерационный процесс создания программного обеспечения

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

Основным недостатком каскадной модели является существенное запаздывание с получением результатов и, как следствие, высокий риск создания системы, не удовлетворяющей и изменившимся потребностям пользователей. Это объяснятся двумя причинами:

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

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

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

Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель ЖЦ (рис.3). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков от необходимости точного и полного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

Как показано на рис. 3, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. Планирование — определение целей, вариантов и ограничений.

2. Анализ риска — анализ вариантов и распознавание/выбор риска.

3. Конструирование — разработка продукта следующего уровня.

4. Оценивание — оценка заказчиком текущих результатов конструирования.

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

Планирование Анализ риска

Рис. 3. Спиральная модель: 1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; б – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком.

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

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

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

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

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

Достоинства спиральной модели:

· наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

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

· включает шаг системного подхода в итерационную структуру разработки;

· использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

· новизна (отсутствует достаточная статистика эффективности модели);

· повышенные требования к заказчику;

· трудности контроля и управления временем разработки.

Подход RAD

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

· небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

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

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

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

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

· определение функций, которые должна выполнять система;

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

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

Кроме того, на данной стадии реализуются следующие задачи:

– ограничивается масштаб времени;

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

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

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

· более детально рассматриваются процессы системы;

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

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

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

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

· входной элемент приложения (входной документ или экранная форма);

· выходной элемент приложения (отчет, документ, экранная форма)

· запрос (пара «вопрос/ответ»);

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

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

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

Результатом данной стадии должно быть:

· общая информационная модель системы;

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

· точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранных форм, отчетов, диалогов.

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

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

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

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

· Осуществляется анализ использования данных и определяется необходимость их распределения.

· Производится физическое проектирование базы данных

· Формируются требования к аппаратным ресурсам.

· Устанавливаются способы увеличения производительности.

· Завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

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

· разрабатывается совершенно новая система;

· уже было проведено обследование организации и существует модель ее деятельности.

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

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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

Итак, перечислим основные принципы подхода RAD.

· Разработка приложений итерациями.

· Необязательность полного завершения работ на каждой стадии ЖЦ ПО.

· Обязательность вовлечения пользователей в процесс разработки ЭИС.

· Целесообразность применения CASE – средств, обеспечивающих целостность проекта и генерацию кода приложений.

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

· Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей.

· Тестирование и развитие проекта, осуществляемые одновременно с разработкой.

· Ведение разработки немногочисленной хорошо управляемой командой профессионалов.

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

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO / IЕС 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model – СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IЕС 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IЕС 15504 взята из модели СММ.

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

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

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

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

Рис. 4. Пять уровней зрелости модели СММ

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

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

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

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

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

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

· предотвращения дефектов;

· управления изменениями технологии;

· управления изменениями процесса.

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

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

Определение метода и технологии

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

· Концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход.

· Нотаций, используемых для построения моделей статической структуры и динамики поведения проектируемой системы. В качестве таких нотаций обычно используются графические диаграммы, поскольку они наиболее наглядны и просты в восприятии (диаграммы потоков данных, и диаграммы «сущность – связь» для структурного подхода, диаграммы вариантов использования, диаграммы классов и др. – для объектно-ориентированного подхода.

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

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

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

Требования к технологии

Современная технология проектирования должна обеспечивать:

1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).

2. Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время.

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

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

5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования).

6. Поддержка комплексом согласованных CASE – средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.

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

1. Стандарт проектирования.

2. Стандарт оформления проектной документации.

3. Стандарт интерфейса конечного пользователя с системой.

Стандарт проектирования должен устанавливать:

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

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

· Требования к конфигурации рабочих мест разработчиков, включая настройки ОС, настройки CASE – средств и т.д.

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

Стандарт оформления проектной документации. Он должен устанавливать:

· комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов»);

· требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.);

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

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

· требования к настройке CASE – средств для обеспечения подготовки документации в соответствии с установленными правилами.

Стандарт интерфейса конечного пользователя с системой. Он должен регламентировать:

· Правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления.

· Правила использования клавиатуры и мыши.

· Правила оформления текстов помощи.

· Перечень стандартных сообщений.

· Правила обработки реакций пользователя.

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

Сущность структурного подхода. Принципы, на которых базируется структурный подход. Метод SADT . Метод DFD

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

1. Количество связей между отдельными подсистемами должно быть минимальным.

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

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

1. Каждая подсистема должна инкапсулировать свою содержимое (скрывать его от других подсистем).

2. Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

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

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

1. Принцип «разделяй и властвуй»;

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

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

1. Принцип абстрагирования- выделение существенных аспектов системы и отвлечение от несущественных.

2. Принцип непротиворечивостиобоснованность и согласованность элементов системы.

3. Принцип структурирования данных- данные должны быть структурированы и иерархически организованы.

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

DFD (Data Flow Diagrams) – диаграммы потоков данных;

SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) – модели и соответствующие функциональные диаграммы;

ERD (Entity – Relationship Diagrams) – диаграммы «сущность-связь».

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

1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями – DFD или SADT (IDEF0).

2. Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT – модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес – процессов организации и взаимодействие между ними (использование SADT – моделей , как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

На стадии проектирования DFD используются для описания структуры проектируемой системы.

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

Разработан Дугласом Россом в 1973г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач.

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

Графическое представление блочного моделирования. Графика блоков и дуг SADT – диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются. Это:

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

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

Состав функциональной модели

Результатом применения метода SADT является модель, состоящая из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно (рис.5). Управляющая информациявходит в блок сверху в то время, как входная информация, которая подвергается обработке, показаны с левой стороны блока, а результаты (выход) – справа. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей снизу.

Рис. 5. Функциональный блок и интерфейсные дуги

Построение иерархии диаграмм

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

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

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

Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков (рис.7). Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.

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

Рис. 6. Общее представление

Ниже (рис.8,9) приведены различные варианты выполнения функций и соединения дуг с блоками.

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

Верхняя диаграмма является родительской для нижней диаграммы

Рис.7. Иерархия диаграмм

Рис.8. Функции блоков А2 и А3 могут выполняться параллельно

Рис. 9. Соответствие интерфейсных дуг родительской (а) и детальной (б) диаграмм

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

Системные требования

Комментарии

Предварительная

Спецификация 

Улучшенный проект

Рис. 10. Пример обратной связи

Механизмы (дуги снизу) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию. Для примера рассмотрим предметную область «Налоговая система РФ» (рис11).

Каждый блок на диаграмме имеет свой номер. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2. Аналогично диаграмма А2 детализирует блок А2 на диаграмме А0, которая является самой верхней диаграммой модели. На рис. 12 показан пример дерева диаграмм.

Законодательство  Внутренние органы

Отчетность                                                       Отчетность

Налогоплательщиков                                     вышестоящим

организациям

Отдел по работе с юридическими лицами

Рис. 11. Выполнение функций осуществляется с помощью механизмов

А0

Работа Государственной налоговой инспекции

А1                                     А2                                 А3

Работа                           Работа                         Работа

с физическими          с юридическими        вспомогательных

лицами                 лицами                      подразделениями

А11                       А12                            А13

Работа                  Работа                         Работа

по подоходному  по налогу                      по налогу

налогу                 на имущество               на землю

Рис. 12. Иерархия диаграмм

Типы связей между функциями

Одним из важнейших моментов при моделировании бизнес-процессов организации с помощью метода SADT является точная согласованность типов связей между функциями. Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):

· случайная;

· логическая;

· временная;

· процедурная;

· коммуникационная;

· последовательная;

· функциональная.

Случайная связь – показывает, что конкретная связь между функциями незначительна или полностью отсутствует (рис.13).

Это относится к ситуации, когда имена данных на SADT – дугах в одной диаграмме имеют слабую связь друг с другом. Крайний вариант этого случая:

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

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

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

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

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

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

В математических терминах необходимое условие для простейшего типа функциональной связи имеет вид:

С=g(B)=g(f(F)).

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

Типы связей

Таблица 1

Лекция 14. Моделирование потоков данных (процессов) . Состав диаграмм потоков данных. Построение иерархии потоков данных. Сравнительный анализ SADT – моделей и диаграмм потоков данных

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе.

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

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

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

Далее при построении будет использоваться нотация Гейна –Сэрсона.

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

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

Основными компонентами диаграмм потоков данных являются:

· внешние сущности (рис.18);

· системы и подсистемы (рис.19);

· процессы (рис. 20);

· накопители данных (рис.21);

· потоки данных (рис.22).

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

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

Рис.18. Графическое изображение внешней сущности

При построении модели сложной ЭИС она может быть представлена в общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем.

Поле номера

Поле имени

Поле физической реализации

Рис.19. Изображение системы (подсистемы)

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

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

Поле номера

Поле имени

Поле физической организации

Рис.20. Графическое изображение процесса

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

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

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

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

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

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

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

Отчетность по

подоходному

налогу

Рис. 22. Поток данных между процессом и внешней сущностью

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

· Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

· Не загромождать диаграммы не существенными на данном уровне деталями.

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

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

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

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

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

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

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

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

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

· Правило нумерации – при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Спецификация является конечной вершиной иерархии DFD . Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

· Наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3).

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

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

· Возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

Спецификации должны удовлетворять следующим требованиям:

·Для каждого процесса нижнего уровня должна существовать одна и только одна спецификация.

·Спецификация должна определять способ преобразования входных потоков в выходные.

·Нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобразования.

·Спецификация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме.

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

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

1. Номер и/или имя процесса.

2. Списки входных и выходных данных.

3. Тело (описание процесса), являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.

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

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

В состав языка входят следующие основные символы:

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

·термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.д.);

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

·общеупотребительные математические, физические и технические термины;

·арифметические уравнения;

·таблицы, диаграммы, графы;

·комментарии.

К управляющим структурам языка относятся последовательная конструкция, конструкция выбора, итерация (цикл).

При использовании структурированного естественного языка приняты следующие соглашения:

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

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

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

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

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

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

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

Потоков данных

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

· диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями – DFD или SADT (IDEF0);

· диаграммы, моделирующие данные и их отношения (ERD).

Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы – использующие DFD (в различных нотациях) и использующие SADT – модели. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE – средствах составляет 90% для DFD и 10% для SADT.

Сравнительный анализ этих двух разновидностей методов структурного анализа проводится по следующим параметрам:

· Адекватность средств решаемым задачам;

· Согласованность с другими средствами структурного анализа;

· Интеграция с последующими стадиями ЖЦ ПО (прежде всего со стадией проектирования).

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

Если же речь идет не о системах вообще, а о ЭИС, то здесь DFD вне конкуренции. SADT – диаграммы оказываются значительно менее выразительными и удобными при моделировании ЭИС.

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

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

DFD могут быть легко преобразованы в модели проектируемой системы.

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

Функциональные модели, используемые на стадии проектирования

Функциональные модели, используемые на стадии проектирования ПО, предназначены для описания функциональной структуры проектируемой системы. Построенные ранее DFD при этом уточняются, расширяются и дополняются новыми конструкциями.

Так, например, для DFD переход от модели бизнес – процессов организации к модели системных процессов может происходить следующим образом:

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

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

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

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

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

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

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

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

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

· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же как в модели процессов, либо другим способом – по функциональным признакам или в зависимости от принадлежности к определенным объектам);

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

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

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

Основные понятия. Метод Баркера. Подход, используемый в CASE – средстве SILVERRUN.

Основные понятия

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), нотация которых впервые была введена Питером Ченом в 1976 г. Базовым понятием ERD являются:

Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.

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

· иметь уникальное имя;

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

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

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

Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, и наоборот.

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

Метод баркера

Одной из наиболее распространенных нотаций ERD является нотация, предложенная Ричардом Баркером, автором методов, используемых в технологии создания ПО фирмы Oracle. Метод Баркера можно пояснить на примере моделирования данных компании по торговле автомобилями. Исходными данными для построения ERD являются результаты интервью, проведенного с персоналом компании:

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

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

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

Первый шаг моделирования – извлечение информации из интервью и выделение сущностей.

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

Исходя из этого, выделяются четыре сущности, которые изображаются на диаграмме:

Второй шаг моделирования – идентификация связей.

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

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

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

·продавец может получить вознаграждение за один контракт или более;

·контракт должен быть инициирован ровно одним продавцом.

Изобразим графически предложения, описывающие связь продавца с контрактом (рис.24).

Рис.24. Отображение связи «продавец – контракт»

Описав также связи остальных сущностей получим полную диаграмму (рис25).

Рис.25. Диаграмма «сущность-связь» без атрибутов

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

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

С учетом имеющейся информации дополним построенную ранее диаграмму (рис.26).

Рис.26. Диаграмма «сущность – связь с атрибутами»

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

Супертипы и подтипы: одна сущность является обобщающим понятием для группы подобных сущностей.

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

В CASE – средстве SILVERRUN для концептуального моделирования данных (на стадии формирования требований) используется один из вариантов нотации Чена (рис. 29). На ERD – диаграмме сущность обозначается прямоугольником, содержащим имя сущности, а связь – овалом, связанным линией с каждой из взаимодействующих сущностей. Числа над линиями означают степень и обязательность связи.

 0,N  1,1

Рис.29. Обозначение сущностей и связей

В данном примере:

· физическое лицо может не иметь банковского счета (необязательная связь) либо иметь много счетов (степень связи N);

· каждый банковский счет может принадлежать одному (обязательная связь) и только одному физическому лицу (степень связи – 1).

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

Существуют следующие виды идентификаторов:

·Первичный/альтернативный: сущность может иметь несколько идентификаторов. Один должен являться основным (первичным), а другие – альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы начинаются с символов <1> для первого альтернативного идентификатора, <2> – для второго и т.д. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы.

·Простой/составной: идентификатор, состоящий из одного атрибута, является простым, из нескольких атрибутов – составным (рис.31);

· Абсолютный / относительный: если все атрибуты, составляющие идентификатор, принадлежат сущности, то идентификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности (рис.32). В примере на рисунке ниже идентификатор сущности Строка-заказа является относительным. Он включает идентификатор сущности ЗАКАЗ, что показано на рисунке подчеркиванием 1,1.

Рис.32. Относительный идентификатор

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

0,N  0,N

Рис. 33. Связь с атрибутами

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

В связи «супертип-подтип» общие атрибуты типа определяются в сущности- супертипе, сущность-подтип наследует все атрибуты супертипа (рис. 34). Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификатора (он импортирует его из супертипа).

Рис. 34. Связь «супертип-подтип»

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

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

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

Лекция 16. Основные понятия качества программных средств

Системы качества. Качество функционирования. Качество в использовании. Основные факторы качества.

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

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

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

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

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

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

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

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

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

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

Разнообразие областей применения компьютеров становится все шире

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

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

Потребителя-заказчика, прежде всего, интересуют функции и качество

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

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

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

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

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

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

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

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

Основой для формирования требований к ПС является анализ свойств,

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

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

и оценки качества характеризуются следующими обобщенными показателями:

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

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

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

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

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

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

· предполагаемым тиражом производства и применения комплекса программ;

· степенью необходимой документированности программ.

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

Качество изменяется в течение жизненного цикла ПС, то есть его требуемое и реальное значение в начале ЖЦ почти всегда отличается от фактически достигнутого при завершении проекта и качества поставляемой пользователям версии продукта. На практике важно оценивать качество программ не только в завершенном виде, но и в процессе их проектирования, разработки и сопровождения. Кроме того, оценки показателей качества могут быть субъективными и отражать различные точки зрения и потребности разных специалистов. Чтобы эффективно управлять качеством на каждом этапе ЖЦ, необходимо уметь определять и примирять эти различные представления требуемого качества и его изменения. Характеристики этого процесса в значительной степени определяются совокупными затратами, необходимыми для достижения заданного качества конечного продукта – версии программного средства.

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

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

· конструктивные характеристики качества, способствующие улучшению и совершенствованию назначения, функций и возможностей применения ПС;

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

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

· цели и особенности потребителей результатов оценивания характеристик качества ПС;

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

· доступные ресурсы, ограничивающие возможные величины реальных характеристик качества ПС;

· конкурентоспособность, выраженная отношением эффективности применения к стоимости приобретения и эксплуатации ПС.

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

на две принципиально различающихся группы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый сценарий базируется на маркетинговых исследованиях рынка

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

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

Потенциальные покупатели-пользователи перед приобретением ПС обычно оценивают конкурентоспособность новой продукции на рынке по величине отношения:

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

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

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

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

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

Однако для заказчика и разработчика перед заключением контракта необходим достаточно достоверный системный анализ, прогнозированием

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

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

Многие молодые программисты – “художники” лихо утверждают, что

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

Ориентирами для оценивания необходимых ресурсов трудоемкости, длительности и числа специалистов по крупным этапам работ, при создании сложных ПС высокого качества, могут служить данные, опубликованные в [5,6]. В табл. 1 представлен вариант, относительного распределения затрат ресурсов по этапам работ для сложных встроенных ПС реального времени, который можно использовать как базу для приближенных оценок. Соотношение затрат по этапам в процентах достаточно инвариантно для различных по объему и сложности проектов и для ориентировочных оценок может быть пересчитано в реальные значения с учетом размера ПС, доступных ресурсов и средней производительности труда в фирме.

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

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

Табл. 2.

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

Вследствие этого в широких пределах могут изменяться трудоемкость

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

Стандарт ISO 9126:1991 – Оценка программного продукта. Основные факторы, определяющие качество сложных программных средств. Внутренние метрики. Внешние метрики. Метрики качества в использовании

Стандарт ISO 9126:1991 – Оценка программного продукта. Характеристики качества и руководство по их применению – является основой формального регламентирования характеристик качества ПС. Развитие этого международного стандарта проводится в направлении уточнения, детализации и расширения, описаний характеристик качества комплексов программ. Для замены редакции 1991 года завершается разработка и формализован проект стандарта, состоящего из четырех частей ISO 9126:1-4. Стандарт ISO 9126:1991 предполагается заменить, на две взаимосвязанные серии стандартов: ISO 9126:1-4 (проект) – Качество программных средств – и утвержденный стандарт ISO 14598:1-6:1998-2000 – Оценивание программного продукта. Проект нового стандарта ISO 9126 состоит из следующих частей под общим заголовком – Информационная технология – Качество программных средств:

Часть 1: Модель качества.

Часть 2: Внешние метрики качества.

Часть 3: Внутренние метрики качества.

Часть 4: Метрики качества в использовании.

Часть первая стандарта ISO 9126-1 – (пересмотренная и расширенная редакция ISO 9126:1991), сохранила практически ту же номенклатуру нормативных характеристик качества программных средств. В ней приводится схема взаимосвязи частей стандарта ISO 9126 и частей стандарта ISO 14598, а также область применения, нормативные ссылки, термины и определения. Модель характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:

Функциональная пригодность детализируется:

– пригодностью для применения;

– корректностью (правильностью, точностью);

– способностью к взаимодействию;

– защищенностью.

Надежность характеризуется:

– уровнем завершенности (отсутствия ошибок);

– устойчивостью к дефектам;

– восстанавливаемостью;

-доступностью-готовностью.

Эффективность рекомендуется отражать:

– временной эффективностью;

– используемостью ресурсов.

Применимость (практичность) предлагается описывать:

-понятностью;

– простотой использования;

– изучаемостью;

– привлекательностью.

Сопровождаемость представляется:

– удобством для анализа;

– изменяемостью;

– стабильностью;

– тестируемостью.

Переносимость (мобильность) предлагается отражать:

– адаптируемостью;

– простотой установки – инсталляции;

– сосуществованием – соответствием;

– замещаемостью.

Дополнительно каждая характеристика сопровождается субхарактеристикой согласованность, которая должна отражать отсутствие противоречий с иными стандартами и нормативными документами, а также с другими показателями в данном стандарте. Характеристики и субхарактеристики в этой части стандарта определены очень кратко (2-3 строки), без комментариев и подробных рекомендаций по их применению к конкретным системам и проектам. Материалы имеют концептуальный характер и не содержат рекомендаций по выбору и упорядочению приоритетов необходимого минимума критериев в зависимости от особенностей объекта среды разработки и применения. Кроме того, отсутствуют методики измерения характеристик и сопоставления с требованиями спецификаций, а также рекомендации, на каких этапах ЖЦ ПС их целесообразно применять.

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

Основные факторы, определяющие качество сложных программных средств

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

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

·внешнее качество, заданное требованиями заказчика в спецификациях и отражающееся характеристиками конечного продукта;

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

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

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

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

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

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

Метрики качества в использовании отражают, в какой степени продукт удовлетворяет потребности конкретных пользователей в достижения заданных целей. Эта метрика не отражена в числе шести базовых характеристик ПС, регламентируемых стандартом ISO 9126-1 вследствие ее общности, однако рекомендуется для интегральной оценки результатов функционирования и применения комплексов программ в стандарте ISO 9126-4. Качество в использовании – это объединенный эффект функциональных и конструктивных характеристик качества ПС для пользователей. Связь качества в использовании с другими характеристиками ПС зависит от задач и функций их потребителей:

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

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

· для персонала сопровождения ПС качество в использовании определяется преимущественно сопровождаемостью;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение строгих количественных метрик в программирование должно было способствовать решению ряда практических задач:

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

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

· определять корреляцию отдельных характеристик программного кода с качеством готовой системы;

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

· анализировать явные и скрытые дефекты;

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

По мере роста актуальности программных метрик на рынке стали появляться различные “измерительные” программы. Одни из них исследовали характеристики проектов и ПО комплексно, другие ориентировались на вполне конкретные цели: анализ исходного кода, размеров и структуры отдельных модулей.

Функциональные и конструктивные характеристики качества

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

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

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

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

При комплексном анализе качества баз данных, не всегда удается четко разделить требования и значения характеристик качества для каждого из этих объектов. При этом одна и та же система управления базой данных (СУБД) может обрабатывать различные по структуре, составу и содержанию данные, а одни и те же данные могут управляться программными средствами различных СУБД. Хотя эти компоненты тесно взаимодействуют при реализации конкретной прикладной БД, первоначально при проектировании они создаются или выбираются практически независимо и могут рассматриваться в их жизненном цикле (ЖЦ) как два объекта, которые различаются:

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

·технологией и средствами автоматизации разработки и обеспечения всего ЖЦ каждого объекта;

·категориями специалистов, обеспечивающих: создание, эксплуатацию или применение компонентов БД;

·комплектами эксплуатационной и технологической документации, поддерживающими жизненный цикл объектов.

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

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

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

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

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

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

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

· идентичностью данных – относительным числом описаний объектов, не содержащих дефекты и ошибки, к общему числу документов об объектах в ИБД;

· актуальностью данных – относительным числом устаревших данных об объектах в ИБД к общему числу накопленных и обрабатываемых данных.

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

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

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

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

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

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

· динамичность – относительное число изменяемых описаний объектов к общему числу записей в БД за некоторый интервал времени, определяемый периодичностью издания версий БД.

Защищенность информации БД реализуется, в основном, программными средствами СУБД, однако в сочетании с поддерживающими их средствами организации и защиты данных. Цели, назначение и функции защиты тесно связаны с особенностями функциональной пригодности каждой ИБД. При проектировании свойства защищать информацию баз данных от негативных воздействий описываются обычно составом и номенклатурой методов и средств, используемых для защиты от внешних и внутренних угроз. Косвенным показателем ее качества может служить относительная доля вычислительных ресурсов, используемых непосредственно средствами защиты информации БД.

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

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

Стандартом ISO 9126 рекомендуется анализировать и учитывать надежность комплексов программ четырьмя субхарактеристиками, которые могут быть применены также для формирования требований к характеристикам качества информации БД. Завершенность – свойство ИБД, состоящее в способности не попадать в состояния отказов вследствие потерь, искажений, ошибок и дефектов в данных. Они могут быть обусловлены не полным тестовым покрытием при испытаниях компонентов и ИБД в целом, а также недостаточной завершенностью их тестирования и защищенностью от искажений.

Устойчивостьк дефектам и ошибкам – свойство ИБД автоматически поддерживать заданный уровень качества данных в случаях проявления дефектов и ошибок или нарушения установленного интерфейса по данным с внешней средой. Для этого в ИБД рекомендуется вводить оперативное обнаружение дефектов и ошибок информации, их идентификацию и автоматическое восстановление (рестарт) нормального функционирования ИБД. Относительная доля вычислительных ресурсов, используемых непосредственно для быстрой ликвидации последствий отказов и оперативного восстановления данных (рестарт) определяет значение устойчивости и снижается на повышении надежности ИБД.

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

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

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

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

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

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

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

Простота использования ИБД – возможность удобно и комфортно ее

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

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

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

Совокупность субхарактеристик сопровождаемости ПС, представленная в стандарте ISO 9126, вполне применима для описания требований к этому показателю качества информации БД, в основном, теми же организационно-технологическими субхарактеристиками. Анализируемость ИБД зависит от стройности архитектуры, унифицированности интерфейса, полноты и корректности технологической и эксплуатационной документации на БД. Изменяемость состоит в приспособленности структуры и содержания данных к реализации специфицированных изменений и к управлению конфигурацией данных. Изменяемость зависит не только от внутренних свойств ИБД, но также от организации и инструментальной оснащенности процессов сопровождения и конфигурационного управления, на которые ориентирована в проекте архитектура, внешние и внутренние интерфейсы данных.Тестируемостьзависит от величины области влияния изменений, которые необходимо тестировать при модификациях структуры и содержания данных в ИБД, от сложности тестов для проверки их характеристик. Ее атрибуты зависят от четкости формализации в системном проекте правил структурного построения компонентов и всего комплекса ИБД, от унификации межмодульных и внешних интерфейсов, от полноты и корректности технологической документации. Субхарактеристики изменяемость и тестируемостьданных доступны количественному определению по величине трудоемкости и длительности реализации этих функций при типовых операциях с данными при применении различных методов и средств автоматизации.

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

· форматная совместимость характеризуется степенью соответствия данных в ИБД анализируемых платформ требованиям стандартов на форматы представления данных для документальных, фактографических, словарных и иных БД;

· лингвистическая совместимость определяется степенью использования в рассматриваемых ИБД единых лингвистических

средств (классификаторов, рубрикаторов, словарей), формализованных соответствующими стандартами этих платформ;

· физическая совместимость заключается в степени соответствия кодировки информации БД одинаковым стандартам на машиночитаемые носители информации.

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

Размерно-ориентированные метрики. Функционально-ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (Lines Of Code). LOC – оценка – это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл.3).

Табл. 3.Исходные данные для расчета LOC- метрик

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 12100 строк программы были разработаны за 24 чел.-мес. И стоили $168 000. Кроме того, по проекту было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:

Производительность = Длина / Затраты (тыс.LOC/чел.-мес.);

Качество = Ошибки / Длина (Единиц/тыс. LOC);

Удельная стоимость = Стоимость /Длина (тыс.$/LOC);

Документированность = Страниц_Документа / Длина (Страниц/тыс.LOC)

Достоинства размерно-ориентированных метрик:

· широко распространены;

· просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

· зависимы от языка программирования;

· требуют исходных данных, которые трудно получить на начальной стадии проекта;

· не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

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

Используется 5 информационных характеристик.

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

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

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

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

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

Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.

Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).

Табл.4. Примеры элементов данных

Табл.5. Правила учета элементов данных из ГИП

Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).

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

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

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

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

Табл.6. Ранг и оценка сложности внешних вводов

Табл.7. Ранг и оценка сложности внешних выводов

Табл.8. Ранг и оценка сложности внешних запросов

Табл.9. Ранг и оценка сложности внутренних логических файлов

Табл.10. Ранг и оценка сложности внешних интерфейсных файлов

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

После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (Function Points). Автором этой метрики является А. Альбрехт (1979).

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

Табл.11. Исходные данные для расчета FP – метрик

Количество функциональных указателей вычисляется по формуле:

FP= Общее количество*(0,65 0,01*SF_i),                         (1)

Где F_i – коэффициент регулировки сложности (I=1..14).

Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.12).

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

Производительность = ФункцУказатель / Затраты (FP/чел.-мес.);

Качество = Ошибки / ФункцУказатель (Единиц/FP);

Удельная Стоимость = Стоимость / ФункцУказатель (Тыс.$/FP);

Документированность=СтраницДокумента/ФункцУказатель (Страниц/FP)

Табл.12. Определение системных параметров приложения

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

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

Табл.13. Исходные данные для расчета указателя свойств

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

Достоинства функционально-ориентированных метрик:

· не зависят от языка программирования;

· Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP – оценки легко пересчитать в LOC – оценки. Как показано в табл.14, результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Табл.14. Пересчет FP – оценок в LOC – оценки

ЗАКЛЮЧЕНИЕ

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

БИБЛИОГРАФИЯ

1. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: «Финансы и статистика». 2000. – 339 с.

2. А.М. Вендров. Практикум по проектированию программного обеспечения экомических информационных систем. М.: «Финансы и статистика». 2002. -190 с.

3. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. -259с.

4. В.В. Липаев. Качество программных средств. Методические рекомендации. М.: «Янус-К». 2002. – 298с.

5. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ./Под ред. А.А. Красилова. М.:Радио и связь, 1985.

6. В.В. Липаев, А.И. Потапов. Оценка затрат на разработку программных средств. М.: Финансы и статистика. 1988.

7. С.А. Орлов. Технологии разработки программного обеспечения. Учебник для вузов. М., Санкт-Петербург: «Питер». 2002.

8. Г. Коллинз, Дж. Блей. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: «Статистика», 1980. 260с.:ил.

9. ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов».

10. ГОСТ 34601 – 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

11. ГОСТ 34601 – 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

12. ГОСТ 34601 – 92. «Информационная технология. Виды испытаний автоматизированных систем».

13. Информационные системы в экономике. Под ред. Проф. В.В. Дика. Учебник для вузов, М., «Финансы и статистика». 1996. – 270 с.

ПРИЛОЖЕНИЕ

Стандарт фирмы IBM. Проектирование пользовательского интерфейса на персональном компьютере.- Вильнюс, 1992

Стандартизация и согласованность интерфейса экономят время пользователя и разработчика.

Пользовательский интерфейс включает в себя три понятия: общение приложения с пользователем, общение пользователя с приложением, язык общения. Язык общение определяется разработчиком программного приложения. Свойствами интерфейса являются наглядность и конкретность. Наиболее распространенный ранее командный интерфейс имел ряд недостатков (многочисленность команд, отсутствие стандарта для приложения), что ограничивало круг его применения. Для преодоления этих недостатков были предприняты попытки его упростить (например, NC). Однако настоящим решением проблемы стало создание графической оболочки для ОС. В настоящее время практически все распространенные ОС используют для своей работы графический интерфейс. Примером здесь может служить интерфейс, разработанный в исследовательском центре Пало Альто фирмы Xerox для компьютеров Macintosh фирмы Apple. Немного позже была разработана графическая оболочка под названием Microsoft Windows, реализующая технологию WIMP и удовлетворяющая стандарту CUA. Новшеством были применение мыши, выбор команд из меню, предоставление программам отдельных окон, использование для обозначения программ образов в виде пиктограмм.

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

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

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

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

Тело панели содержит элементы тела панели: разделители областей, идентификатор и заголовок панели, инструкцию, заголовки столбца, группы, поля; указатель протяжки; область сообщений и команд; поля ввода и выбора (см.прил.2.1.).

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

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

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

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

Путь, по которому движется диалог, называется навигацией. Он может быть изображен в виде графа, где узлы – действия, дуги – переходы. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. Часть запросов на обработку и навигацию является унифицированной. Унифицированные действия диалога – это действия, имеющий одинаковый смысл во всех приложениях. Некоторые унифицированные действия могут быть запрошены из выпадающего меню посредством действия “команда” функциональной клавишей. К унифицированным действиям диалога относятся: “отказ”, “команда”, “ввод”, “выход”, “подсказка”, “регенерация”, “извлечение”, “идентификаторы”, “клавиши”, “справка” (см. прил.3).

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

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

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

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

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

Инструкция сообщает пользователю, что нужно сделать и как продолжить работу.

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

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

Заголовок поля обозначает поле выбора, поле ввода поле переменной информации.

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуемая палитра:

Панель в первичных и вторичных окнах, за исключение панели “Справка”,- белая. Панель в окне справка – синяя. Панель во всплывающих окнах нечетного уровня – голубая, а четного уровня – белая. Ошибки выделяются красным. Предупреждения об ошибках – желтые. Критические сообщения – красные.

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

Действие “ввод” включается, если панель содержит поле ввода или более одного поля выбора (многозначный выбор).

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

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

Унифицированное действие “справка” должно содержать следующие действия в выпадающем меню в порядке расположения:

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

Общая справка. Обеспечивает общую справку о панели, из которой она затребована.

Описание клавиш. Должен быть представлен список используемых функциональных клавиш с их функциями.

Указатель. Содержит перечень имеющихся в приложении справок в алфавитном порядке. Тот же список отображается при выборе клавиши “указатель” в панели “справка”.

Учебная справка. Предусматривается в режиме приложения и должна быть последней в выпадающем меню “Справка”.

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

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

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

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

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

Посредством действия “Идентификатор” пользователь запрашивает включение или выключение идентификатора панели.