Программное обеспечение как товар. Создание программного обеспечения для персональных компьютеров за какой-то десяток лет превратилось из занятия программистов-одиночек в важную и мощную сферу промышленности.
Только в США более 50 фирм – производителей программного обеспечения имеют объемы продаж более 10 млн. дол., а у десяти из них (в частности, Microsoft, Lotus, Novell, Borland, Autodesk, Symantec и Computer Associates) объемы продаж превышают 100 млн. дол. Поэтому развитие программного обеспечения, предназначенного для широкого круга пользователей, происходит уже не в состязании индивидуальных программистов, а в процессе ожесточенной конкурентной борьбы между фирмами-производителями программного обеспечения.
Доля некоммерческого программного обеспечения постоянно снижается и все более ограничивается программами, создаваемыми в процессе научных исследований или для собственного удовольствия. Важнейшие свойства программ. При разработке коммерческих программ основной задачей фирм-разработчиков является, естественно, обеспечение их успеха на рынке.
Критерии качества на ранних стадиях разработки ПО — Мохамад Кассаб
Для этого необходимо, чтобы программы обладали следующими качествами: функциональность программы, т.е. полнота удовлетворения ею потребностей пользователя; наглядный, удобный, интуитивно понятный и привычный пользователю интерфейс (т.е. способ взаимодействия программы с пользователем); простота освоения программы даже начинающими пользователями, для чего используются информативные подсказки, встроенные справочники и подробная документация; надежность программы, т.е. устойчивость ее к ошибкам пользователя, отказам оборудования и т.д., и разумные ее действия в этих ситуациях. Стандартизация.
Во многих областях совместная работа различных производителей программного обеспечения приводит к стандартизации отдельных элементов интерфейса программ, форматов данных и т.д., что весьма удобно для пользователей. Это происходит прежде всего потому, что разработчики программ перенимают друг у друга удачные находки и приемы и стремятся обеспечить совместимость с другими наиболее популярными программами.
В результате использования ниспадающих (pull-down) меню или вид таблицы табличного процессора будут приблизительно одинаковыми во всех программах, хотя они созданы различными разработчиками, подобно тому, как похожи кнопки в лифтах, изготовленных разными заводами. Удобство пользовательского интерфейса программ является важнейшим фактором, определяющим приемлемость программы для пользователей, а значит, и ее успеха на рынке.
Большинство выпускаемых на рынок программ используют достаточно стандартные методы организации интерфейса: ниспадающее меню, панели для выбора ответа, встроенные диалоговые справочники и т.д. Как правило, пользователь может работать не только с клавиатурой, но и с мышью.
В последнее время все большее количество программ используют графический пользовательский интерфейс (graphical user interface, GUI), в котором, в частности, для упрощения работы пользователя вместо надписей на экране употребляются рисунки (пиктограммы). При этом графический интерфейс используется не только в таких программах, как графические редакторы или издательские системы, но и в табличных процессорах, текстовых редакторах и т.д.
Критерии качества релиза
Многие из программ с графическим интерфейсом работают под управлением системы Windows. Увеличение мощности программ. Важнейшей тенденцией развития программного обеспечения является неуклонное увеличение их мощности – программы могут обрабатывать большие количества данных, делать это быстрее, предоставляют пользователю больше выполняемых функций и т.д.
Таким образом, разработчики программного обеспечения используют возможности, появляющиеся из-за увеличения мощности компьютеров. Весьма заметно и стремление к интеграции функций программного обеспечения. Например, в табличный процессор включаются функции базы данных, в издательскую систему – функции текстового редактора и т.д.
Оборотной стороной увеличения мощности программ является повышение их требований к аппаратуре. Коммерческие разновидности программ. В настоящее время большинство программ распространяется на коммерческой основе. Для приобретения таких программ необходимо вначале заплатить за них определенную сумму денег. Такие программы называются коммерческими.
Существуют и такие программы, которые распространяются бесплатно. Чаще всего эти программы написаны каким-нибудь опытным программистом для себя, затем переданы для общего пользования. Такие программы называются бесплатными (freeware).
Иногда разработчики программы указывают, что их программа является бесплатной для индивидуальных пользователей, но для использования в организациях должна покупаться соответствующая лицензия. Промежуточное положение между бесплатными и коммерческими программами занимают условно-бесплатные программы (shareware).
Эти программы можно получить и опробовать бесплатно, но для систематического их использования необходимо уплатить разработчикам или распространителям программы определенную сумму. Качество произведенного программного продукта, как и для всякого производства, является важным технологическим понятием: достижение приемлемого качества должно планироваться, а в процессе технологического цикла разработки качество должно быть предметом инспекций и контроля.
Классически исходное представление о качестве связано с тем, что разработанный продукт подтверждает свою спецификацию, при этом спецификация должна быть ориентирована на характеристики, которые желает получить клиент [1 P. Crosby. Quality is Free/McGraw-Hill, N.Y., 1979.]. В работе [2 P. Nesi.
Objective Quality, 1995//Objective Software Quality, LNCS № 926, Springer, 1995, p. 1-9.] отмечается, что иная, не менее, широкая трактовка понятия качества может быть выражена утверждением «пригодность для цели». Так или иначе, понятие качества программного обеспечения – это прежде всего внешняя оценка. Степень качества связана с удовлетворением потребностей пользователя.
Современные технологические стандарты и учебники по технологии программирования уточняют понятие качества, вводя совокупность аспектов, в свете которых и должно рассматриваться качество. В работе [3 I. Sommerville. Software Engineering/Addison-Wesley Pub.
Co., 1996], например, в роли таких аспектов выступают: безопасность, защищенность, надежность, устойчивость, понимаемость, тестируемость, адаптируемость, модульность, сложность, переносимость, доступность пользователю, повторная используемость, эффективность, изучаемость и сопровождаемость. Этот список достаточно полон и, по-видимому, включает все интересные для рассмотрения аспекты качества.
Похожий перечень приводится и в монографии российского автора [4 В. Липаев. Качество программного обеспечения//Финансы и статистика, М., 1983.], однако с учетом того, что за десяток лет, разделяющий эти работы, понятие качества программного обеспечения претерпело определенную эволюцию.
С другой стороны, все или по крайней мере большинство из перечисленных аспектов качества определенным образом связано с некоторыми свойствами компонентов программной системы, а также со свойствами структуры программного обеспечения как системы компонентов. Негласно существует программистский «гамбургский счет» оценки качества программной реализации.
Кстати, знакомство с исходными текстами ряда весьма уважаемых и широко используемых программных продуктов показывает, что по этому «гамбургскому счету» они выглядят не очень хорошо. Действительно, разумная организация потока управления и информационных потоков в реализованной программе заведомо улучшает такие аспекты, как устойчивость, понимаемость, тестируемость, адаптируемость, переносимость, повторная используемость, сопровождаемость, да, возможно, и другие.
Для оценки внутренних достоинств реализации программы с технической стороны в работе [5 И. Поттосин. «Хорошая программа»: попытка точного определения понятия//Программирование.-1997. — № 2. — С.3-17.] было предложено понятие добротности программы (в английском переводе [6 .V. Pottosin.
A «Good Program»: An Attempt at an Exact Definition of the Term.//Programming and Computer Software. — v. 23, № 2. — 1997. — p.59-69] приведен соответствующий англоязычный термин «soundness»). В термин «добротность» вкладывается такой аспект хорошей программы, который заключается в том, что программа разумно, рационально реализована, с достаточно продуманной организацией потоков управления и информационных потоков, не слишком переусложнена.
Выбором этого термина подчеркивается чисто техническая сторона оценки – важна отнюдь не красота или изящество программы, которые, как правило, являются следствием оригинальной и интеллектуально сильной идеи, реализованной в программе, а именно качество собственно реализации, ее профессионализм, продуманность, что и соответствует русскому слову «добротность». При такой оценке «за бортом» остаются многие аспекты качества ПО, прежде всего касающиеся функционального соответствия программного продукта запросам клиента.
Однако вместе с тем, как уже и отмечалось, хорошая оценка этой внутренней характеристики программ, составляющих программный продукт, дает определенную уверенность, что другие важные характеристики качества программного обеспечения тоже будут выглядеть неплохо. Достоинством такого технического подхода к оценке качества программ является возможность предложить достаточно точные методы или дисциплины оценки добротности программ при инспекции и контроле качества ПО на этапе кодирования, иначе говоря – на этапе создания собственно программного текста.
Недостаток этого подхода в том, что чаще всего можно говорить о добротности компонентов, но не о добротности всей программной системы в целом. Само понятие добротности нуждается в уточнении, что и будет сделано при описании критериев добротности. Критерии добротности программ.
Определив добротность программ как разумную, рациональную, непереусложненную организацию информационных потоков управления в программе и разумное построение вычислений, мы не избавились от множественности критериев оценки этой добротности. Содержание понятия добротности допускает разные классы оценок.
Пытаясь оценить различные критерии добротности программ, можно свести их к следующим классам. Количественные критерии.
Количественные критерии добротности программ, как правило, в отличие от всех последующих классов критериев, относительны – они не отвечают на вопрос о том, добротна ли данная программа, а позволяют сравнивать близкие программы и на основании сравнения определять, какая программа добротнее. Примерами таких оценок, составляющих основу количественных критериев, являются: мера «совершенства» Холстеда, оценка сложности управляющего графа программы, выражаемая цикломатическим числом; различные оценки сложности программных систем и компонентов в них и т.п.
Достоинство количественных критериев в том, что с их помощью можно оценивать добротность как компонентов, так и самих систем. При модификации программы или системы можно оценивать, не изменилась ли заметно их сложность, не нарушена ли добротность.
Итак, с точки зрения количественных критериев добротная программа – это не переусложненная программа, а программа приемлемой степени сложности. Генетические критерии. Известен следующий практический подход к оценке качества программ: программа признается хорошей, если она произведена по технологии, вызывающей доверие.
Класс критериев, основанный на таком подходе – оценке добротности программ, так сказать, «по происхождению», мы назвали (может быть, не очень удачно) генетическим. Действительно, всякая «хорошая» технология программирования предполагает хорошо продуманную дисциплину разработки, надежно переходящую от спецификации продукта к его реализации.
Поскольку при такой дисциплине гарантируется – в достаточной степени – соответствие реализованной программы ее спецификации, то, привлекая широкое понятие качества ПО, качество продукта должно быть довольно высоким – лишь бы спецификация была полной и адекватной нуждам пользователя. Для добротности интересно то, что продуманная дисциплина перехода от спецификации к программному тексту должна давать хорошую его организованность, разумную реализацию в нем потоков управления и информационных потоков.
Итак, с точки зрения генетических критериев можно быть уверенным в добротности программы или системы, если они произведены по технологии, признаваемой хорошей. Структурные критерии. Разумная организация потока управления предполагает его ясное синтаксическое отображение в программном тексте.
Подход к такому отображению сформулирован давно и выражается понятием структурированной программы. В такой программе управление представлено в виде иерархии регулярных управляющих структур, каждая из которых имеет один вход и один выход.
Помимо такого простого требования, исключающего хаотичное переплетение потоков управления («спагетти»), для добротной программы с регулярностью управления важно иметь хорошо продуманную процедурную основу (или, для объектно-ориентированного случая – систему классов). Все подобные требования к добротности программ мы относим к структурным критериям.
Ясная и четко выраженная структура управления, требуемая структурными критериями, легко сопоставляется с внешними аспектами качества программного обеспечения. Недаром большая часть известной заметки [9 E.Dijkstra. Go to Statement Considerеd Harmful//Commun.
ACM. — 1968. — V. 11, № 3, — p.147-148], положившей основу структурному программированию, посвящена тому, что в структурированных программах текст легко сопоставить с множеством отображенных в нем вычислительных процессов, иначе говоря, структурированные программы резко повышают понимаемость, а значит, и ряд других аспектов качества. Если оценка процедурной основы или системы классов требует нетривиальных умозаключений (частично поддерживаемых некоторыми вычисляемыми мерами сложности), то структурированность программы легко усматривается из программного текста, и ее мы считаем неотъемлемым свойством добротных программ.
Итак, структурные критерии диктуют нам, что добротной признается структурированная программа с разумной организацией процедурной основы и/или системы классов. Прагматические критерии. В работе [5] вводится и определяется специальный класс критериев добротности программ, названный прагматическими критериями.
Давно было замечено, что можно формально обнаружить в программе некоторые несообразности или излишества – в [7] они названы «несовершенствами», в работе [10 V. Kasjanov, I. Pottosin. Application of optimization techniques to correctness problems//Consructing Quality Software. — North-Holland, 1978. — pp.237-248] – «неправдоподобностями». В статье [11 S.Pan, R.G.Dromey. Bejond Structured Programming//Proc.
ICSE-18. -Berlin. -pp.268-278] предложены правила, определяющие так называемую каноническую форму, автоматически исключающую ряд подобных несообразностей. Прагматические критерии добротности связаны с тем, что формально можно выявить некоторые свойства программы, которые содержательно трактуются как цели, достижению которых и служит программа.
Такой целью может быть конечное состояние переменных, порождаемое программой, множество ее истинных (подтверждаемых программным текстом) результатов, подтверждаемые таким текстом потоки управления и информационные потоки и т.п. Развитые методы анализа программ могут обнаруживать подобные цели и находить те фрагменты и объекты данной программы, которые заведомо никак не служат достижению такой формально выявляемой цели.
Наличие данных излишеств и служит основанием для того, чтобы признать программу недобротной в соответствии с прагматическими критериями. Источником таких излишеств может быть невнимание к реальным связям в программе, рудименты при неаккуратной модификации программы и т.п. – в общем, недосмотр и непрофессионализм. Итак, прагматические критерии добротности требуют, чтобы программа соответствовала своей формально выявляемой цели. Заметим, что прагматические критерии относятся скорее к компонентам, чем к системам.
Еще работы по информатике
Реферат по информатике
Критерии и метрики определения качества и сложности разработки ПС. Фунционально и размерно-ориентированные метрики. Метрики ООПС (метрики Чидамбера-Кемерерва).
2 Января 2016
Реферат по информатике
Криптография с открытым ключом
2 Января 2016
Реферат по информатике
Криптографические механизмы конфиденциальности, целостности и аутентичности информации. Электронная цифровая подпись.
Источник: ronl.org
Критерии качества ПС
Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».
Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность — степень логического разбиения кода на ряд управляемых блоков.
Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости
Низкая сложность кода
Низкое использование ресурсов: памяти и процессорного времени
Корректная обработка исключительных ситуаций
Малое число предупреждений при компиляции и линковке
Методы улучшения качества кода: рефакторинг.
Факторы качества
Фактор качества ПО — это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества — таблица 2.1.
Таблица 2.1 — Факторы качества ПС
Назначение ПО должно быть понятным, из самой программы и документации.
Все необходимые части программы должны быть представлены и полностью реализованы.
Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации.
Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.
По всей программе и в документации должны использоваться одни и те же соглашения, форматы и обозначения.
Насколько сложно изменить программу для удовлетворения новых требований. Это требование также указывает, что программа должна быть хорошо документирована, не слишком запутана, и иметь резерв роста по использованию ресурсов (память, процессор).
Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.
Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.
Отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок
Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.
Источник: studentopedia.ru