MS Exsel 2007 как инструмент принятия решения по выявлению наилучшей поисковой системе

Содержание:

Введение

1.Теория

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

1.2 Основные факторы, определяющие качество программных средств

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

2.Практика

2.1 MS Exsel 2007 как инструмент принятия решения по выявлению наилучшей поисковой системе

2.2 Реализация принятия решения на основе расчетов в  Exsel

3. Результативность

Заключение

Список литературы 
 
 
 
 
 
 
 

Введение

    В последние годы программная индустрия  достигла такого уровня развития, при  котором требования к обеспечению качества стали обязательным пунктом заключаемых договоров на разработку программных систем. Постоянное наращивание сложности ПС, как правило, ведет к увеличению числа исходных ошибок в тексте программы, что снижает ее качество, а многообразие ПС, имеющих сходное функциональное назначение, создает жесткую конкуренцию на рынке программной продукции В оценивании качества ПС заинтересованы как его разработчики, так и потребители. Для разработчиков оценивание качества важно уже на этапе проектирования ПС для прогнозирования коммерческого успеха продукта с планируемыми значениями характеристик у пользователей. Оценивание качества ПС на этапе его отладки позволяет разработчику принять решение о завершении этого этапа. Для пользователей же важно уметь оценивать качество готового ПС на этапе его внедрения в эксплуатацию. Основа качественной разработки ПС - рациональная инфраструктура программной инженерии как вида бизнеса. Желание компаний получить наивысшую отдачу от инвестиций в создание ПС побуждает их постоянно возвращаться к вопросу о текущей практике разработки. Разработка ПС как вид бизнеса прошла за последние 30 лет тернистый путь от «закрученных» кодов на Коболе, Фортране и ПЛ/1, создаваемых исключительно в отделах Вычислительно-информационных центров, до приложений, проектируемых, моделируемых и разрабатываемых профессионалами в области информационных систем практически в постоянном взаимодействии с конечными пользователями. К сожалению, разработчики ПС редко завершают программные проекты вовремя, укладываются в рамки бюджета и полностью отражают в программных продуктах требования спецификаций заказчика. Последствия поставки плохо разработанных программных продуктов - это всегда убытки клиентов: не только материальные и финансовые потери, но и падение престижа. Эти проблемы, в свою очередь, негативно отражаются на конкурентоспособности организации-разработчика программных продуктов. И практикующие специалисты в области программных систем, и пользователи сходятся во взглядах на понятие плохого программного продукта как такого, который:

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

    Причины плохого состояния практики разработки ПС заключаются в том, что организация-разработчик страдает синдромом «сапожник без сапог» из-за отсутствия надлежащей инфраструктуры разработки. Разработчики программных продуктов испытывают недостаток в современных автоматизированных инструментальных средствах, методологии разработки, обучении специалистов. Кроме того, из-за неадекватной инфраструктуры, сообществу их потенциальных пользователей не отводится ведущая роль в определении методологий эксплуатации ПС, стандартных процедур обработки деловой информации, планов обеспечения ее безопасности и пр. Поэтому многие пользователи прерывают применение программных продуктов, которые не только плохо разработаны и несовместимы, но и подвергают опасности целостность данных компании. Пользователи сталкиваются с недостатками в программных продуктах из-за того, что те не имеют завершенной технологии поддержки всего жизненного цикла ПС, начиная от ее замысла и кончая списанием. Многие организации-разработчики продолжают использовать тот же ограниченный и не интегрированный набор инструментальных средств и методологий для построения ПС, что и десятилетие тому назад. Эта практика продолжается, несмотря на существенный прогресс в применяемых пользователями основных информационных технологиях и повышение их требований к разрабатываемым по договорам программным продуктам. Руководство организаций-разработчиков по техническим, экономическим и социальным причинам запаздывает с созданием эффективной инфраструктуры, способной обеспечить специалистов инструментальными средствами и методологиями, поддерживающими разработку высококачественных ПС. Оценке качества ПС посвящены государственные и международные стандарты. Согласно ГОСТ 28195-89, оценка качества ПС представляет собой совокупность операций, включающая выбор номенклатуры показателей качества, определение значений этих показателей и сравнение их с базовыми значениями. Оцениванию качества различных материалов и изделий посвящено множество работ. Однако ПС является специфичным объектом: они столь многофункциональны, что даже схематично могут быть описаны только очень большим числом критериев качества (как правило, не менее двухсот). Это не позволяет применять существующие методы оценки качества к ПС в неизменном виде.  
 
 
 

1. Теоретическая часть

 

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

Общее представление о качестве ПС международным  стандартом ISO

9126:1-4:2002 рекомендуется описывать тремя взаимодействующими и

взаимозависимыми  метриками характеристик качества, отражающими:

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

промежуточных этапов жизненного цикла ПС;

— внешнее  качество, заданное требованиями заказчика  в спецификациях

и отражающееся характеристиками конечного продукта;

— качество при использовании в процессе нормальной эксплуатации

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

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

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

значений  или категорий и свойств внутренних характеристик качества,

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

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

Стандарт ISO 9126:1-4 — целесообразно использовать как основу

для формального  регламентирования характеристик качества в жизненном

цикле проектов программных средств. Модель характеристик

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

каждая  из которых детализирована несколькими  нормативными субхарактеристиками. Функциональные возможности детализируются:

— пригодностью для применения по назначению;

— корректностью (правильностью, точностью) реализации требований;

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

— защищенностью  — безопасностью функционирования.

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

— уровнем  завершенности — отсутствием  дефектов и ошибок;

— устойчивостью  при наличии дефектов и ошибок;

— восстанавливаемостью после проявления дефектов;

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

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

— временной  эффективностью реализации комплекса  программ;

— используемостью  вычислительных ресурсов.

Применимость (практичность) предлагается описывать:

— понятностью  функций и документации;

— простотой  использования комплекса программ;

— изучаемостью процессов функционирования и применения.

Сопровождаемость представляется:

— анализируемостью — удобством для анализа предложений  модификаций;

— изменяемостью  компонентов и комплекса программ;

— тестируемостью изменений при сопровождении.

Мобильность (переносимость) предлагается отражать:

— адаптируемостью  к изменениям среды;

— простотой  установки — инсталляции после  переноса;

— замещаемостью  компонентов при корректировках комплекса программ.

Характеристики  и субхарактеристики в стандарте  определены кратко,

без комментариев и подробных рекомендаций по их применению к

конкретным  системам и проектам ПС. Изложение  имеет концептуальный

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

особенностей  объекта, среды разработки, сопровождения  и применения.

Для выбора характеристик качества ПС и достоверного сравнения их

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