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

      Общее понятие — доступные ресурсы разработки — включает реальные

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

которых происходит создание и развитие сложного комплекса программ.

Эти факторы  проявляются как дополнительные показатели качества

продуктов и рентабельности процессов, которые следует учитывать

и оптимизировать в ЖЦ ПС. При выборе и определении  требований к

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

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

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

достаточно  выгодное место. Для этого ему  необходимо определить наличие

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

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

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

того, следует  оценить рентабельность затрат на обеспечение  всего ЖЦ

нового ПС и выявить функциональные и конструктивные характеристики

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

и оправдать  затраты на предстоящую разработку. Для этого потенциальные

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

— возможной  экономической эффективности (ценности) применения

и качества программного продукта и способности  удовлетворить

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

— к стоимости (цене), которую готовы заплатить пользователи при

приобретении  и эксплуатации данного комплекса  программ или базы данных.

При выборе продукта и поставщика покупатель стремится  максимизировать

это отношение  как за счет поиска ПС с наилучшими функциями,

эффективностью  и высокими характеристиками качества, так и за счет

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

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

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

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

продукта  на рынок, сроки и график выполнения этапов жизненного

цикла, потребность и достаточность ресурсов для реализации проекта, а

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

версий  программного продукта.

Такие проекты обычно относительно невелики по объему и срокам

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

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

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

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

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

— предварительный  выбор, формализация и обоснование  набора исходных

данных, отражающих общие особенности потребителей и этапы

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

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

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

специализации и профессиональных интересов. Широкая  номенклатура

характеристик, представленная в стандарте ISO 9126:1-4, поддерживает разнообразные требования, из которых следует селектировать и выбирать

те, которые  необходимы с позиции различных потребителей этих данных.

Выбранные значения характеристик качества и  их атрибутов должны

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

учетом  доступных ресурсов конкретного  проекта и при необходимости

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

качества  для конкретных потребителей в ЖЦ ПС. Результаты анализа

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

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

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

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

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

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

      К матрице {x_ij} добавляется столбец в соответствии с представлениями лица, принимающего решение, (ЛПР) о идеальном ПС. Приведен алгоритм, позволяющий из множества всех альтернативных ПС выбирать подмножество ПС, в которых реализованы, по крайней мере, те же функции, что и в идеальном. Если полученное подмножество состоит только из одного элемента, то этот элемент – есть результат выбора, в противном случае ЛПР должен ввести в рассмотрение несколько функций ПС из числа не рассматривавшихся ранее. В этом случает описанная процедура повторяется до тех пор, пока не будут отсеяны все альтернативные ПС кроме одного – результата выбора.

      К достоинствам этой методики выбора программных  продуктов можно отнести ее простоту и минимальные временные затраты на ее проведение. Недостатками методики являются поверхностность суждения о качестве ПС по единственному показателю качества - "функциональная полнота" и о качестве реализации функций ПС только по наличию последних. В предложена методика, рекомендованная авторами для использования разработчиками ПС на этапах его проектирования, создания и отладки. Методика позволяет оценить значения следующих факторов качества: практичность, целостность, эффективность, корректность, безопасность, надежность, удобство обслуживания, оцениваемость, гибкость, возможность использования в других условиях, мобильность, возможность взаимодействия. Этим факторам в соответствие ставится двадцать шесть критериев качества: работоспособность, возможность обучения, коммуникативность, объем ввода/вывода, скорость ввода/вывода, регулирование доступа, контроль доступа, эффективность использования памяти, эффективность функционирования, трассируемость, завершенность, робастность, точность, устойчивость к ошибкам, согласованность, простота, краткость, наличие измерительных средств, распространяемость, общность, информативность, модульность, машинонезависимость, независимость от других программных средств, унифицированность процедур связи, унифицированность данных. Суть методики состоит в том, что ЛПР, выбирает из этих критериев наиболее важные, с его точки зрения, для оцениваемого класса ПС. Таким образом, каждый фактор определяется некоторым числом S_i отобранных критериев. Затем ЛПР располагает критерии в порядке убывания их важности, вводя отношения между двумя соседними критериями: больше или равно, больше и много больше. Основываясь на введенных отношениях, определяются весовые коэффициенты V_j каждого критерия качества. Значение обобщенного показателя качества ПС определяется как среднее арифметическое полученных значений факторов качества.  Достоинством методики является простота ее реализации. Недостатками являются отсутствие разработанного аппарата шкалирования критериев и определения их числовых значений, отсутствие такого критерия качества, который учитывал бы соответствие функций ПС желаниям ЛПР, а так же необоснованность введения среднего значения при подсчете численного значения обобщенного показателя качества. В предложена методика выбора ПС из класса программ для бухгалтерского учета строительных организаций. Она состоит из трех этапов: