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

Качество на софтуера

Понастоящем се използват два важни подхода за определяне на качеството:

Управление на дефектите.

Атрибут за качество.

Всичко, което не отговаря на искането на клиента, попада в категорията на дефектите. Екип от разработчици, които не могат напълно да разберат изискванията на клиентите, ще позволи грешки при проектирането.


При управлението на дефектите техните категории се определят въз основа на сериозност. Броят на проблемите се отчита и се вземат мерки в съответствие с установената тежест. Контролните карти могат да бъдат създадени за измерване на възможностите за развитие. Качеството на софтуера се подобри значително през последните две десетилетия. Една от причините за това е, че фирмите използват нови технологии като обектно-ориентирано развитие и CASE инструменти. Освен това можете да гледатенарастващото значение на въвеждането на методи на управление в производството. Управление на качеството ZA се разделя на три основни области:

Гаранция. Разработване на основите на организационните мерки и стандартите за качество на софтуера

Планиране. Избор на подходящи стандарти и адаптиране за конкретен програмен проект.

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

Политическа организация на SQA

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

Съответствие с целите и задачите на организацията.

Ангажимент за общите концепции за осигуряване на качеството.

Ангажираност към стандартите за качество, приети от организацията.

Отговорност за разпределяне на адекватни ресурси.

Желанието за непрекъснато подобряване на качеството и производителността на организацията.

За да отговорят на всички изисквания на стандарта, дружествата номинират отговорността за качеството. Задължения на служителя:

Отговорност за изготвянето на годишната програма от мерки и бюджетната АСП.

Организиране на разработването на планове за развитие на системата за управление на качеството.

Цялостен мониторинг на изпълнението на годишната програма за редовни дейности и планирани проекти за развитие.

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

Представяне и популяризиране на въпросите на SQA за изпълнителното управление.

Подготвени са предложения за проучванияОтделът на SQA за годишната програма за дейности, проверяващ потенциала на предложението за постигане на целите.

Концепции на високо равнище

Качествените характеристики са концепции на високо ниво, които отразяват важни аспекти и не подлежат на пряка оценка на качеството на софтуера. Вместо това планът следва да идентифицира съответните показатели, които могат да бъдат използвани за определяне на една или повече характеристики.
Например, при оценката на XML парсера, можете да използвате набор от тестове за съответствие с XML W3C. Той включва тестове, предназначени за справяне с всички аспекти на контрола, както и препоръки за разширяемия език за маркиране на XML (W3C Extensible Markup Language, XML), със специален акцент върху изискванията за обработка на грешки в точността или автентичността на XML документи. По този начин процентът на преминалите тестови случаи се използва като показател за оценка на такива характеристики на разглеждания XML анализатор:

Потребителска перспектива.

Функционалност.

Надеждност и отказоустойчивост.

От гледна точка на потребителя съществуват няколко важни характеристики, които отговарят на следните въпроси:

Кой осигурява пълния набор от необходими функции за тази цел?

Работи ли е надеждно, за да получите необходимите резултати с правилното използване?

Функционира ли програмата безопасно и надеждно в случай на неправилно въвеждане?

Лесно ли е да се използва софтуерен продукт?

Работи ли бързо или изглежда твърде бавно?

Добре интегрирана програма с друг продукт, коятоизползва потребител?

Ако приемем, че въпросите, свързани с качеството, са важни за потребителя, ИТ екипът, отговорен за разполагането и поддръжката, може да срещне други проблеми:

Защита срещу вредни атаки.

Качеството на използване на компютърните ресурси.

Ресурсите с ниско качество са тези, които изискват повече памет и изчислителна мощност, отколкото е необходимо. ISO осигурява този модел с две нови категории от по-високо ниво, свързани с осигуряване на качеството на технологичния софтуер.

Изисквания към ISO 9126 към продукта

ISO 9126 е международен стандарт за оценка. Той е разделен на четири части, които обхващат следните теми:

Външни показатели.

Вътрешни показатели.

​​

Модел за качество.

Показатели за качество на софтуера.

Първата част на ISO 9126 е разширение на предишния стандарт, изготвен от McCall (1977), Boehm (1978) и FURPS при определяне на набор от качествени характеристики. Документацията по ISO 9126 е предмет на авторско право. Моделът за качество ISO 9126-1 определя 6 основни характеристики:

Функционалност.

Надеждност.

Ползваемост.

Ефективност.

Срок на годност.

Преносимост.

Функционалност на продукта

Функционалността е основната цел на всеки продукт или услуга. Колкото повече възможности за използване на продукта, толкова по-трудно става да се определи неговата функционалност. Защото може да има списък с това, което му е на разположение. Някои от изброените функции (например удобство) присъстват само вдо известна степен, тоест, не просто "включен" или "изключен". Много хора се бъркат с цялостната функционалност на процеса и софтуерния продукт. Често това се дължи на факта, че диаграмите на потоците от данни (DFD) и други инструменти за симулация могат да отразяват функционалността на процеса, като набор от данни за изведени данни.

ISO 9126-1 и други модели за качество не спомагат за измерване на общите разходи или ползи от процеса, а само изследват софтуерния компонент. Връзката между функционалността в цялостния бизнес процес надхвърля ISO 9126. Тези атрибутни възможности характеризират полезността в тази среда. Всяка от тях може да бъде измерена само ако има съответни програми на системата.

Характеристики на надеждност и използваемост

Веднага след като софтуерната система започне да функционира, характеристиката на надеждността определя способността му да поддържа предоставянето на своите услуги при определени условия през определени периоди от време. Един аспект на тази функция е отказоустойчивостта. Например, ако мрежата е изключена за 20 секунди, системата трябва да може да продължи и да продължи да работи. Способността да се научиш да използваш системата (ученето) е една от основните характеристики на използваемостта. Ефективността е свързана със системните ресурси, които се използват за осигуряване на необходимата функционалност. Обемът на дисковото пространство, паметта и мрежата са добри показатели за ефективност. Както и при редица други критерии, има съвпадение между тях. Например, удобството за използване на систематавлияе върху неговата ефективност.

Преработване и преносимост

Способността за идентифициране и коригиране на грешка в софтуерен компонент е това, за което се отнася характеристиката на изпълнението. Изпълнението му се влияе от четливостта или сложността на кода, както и от неговата модулност. Това е нещо, което помага да се идентифицира причината за неизправността, за да се реши по-късно. Характеристики на поддръжката:

Анализ - идентифицира основната причина за неуспех.

Променливост - Определя усилието, което се добавя за модифициране на кода за отстраняване на грешката.

Стабилност - Демонстрира колко стабилна работи системата, когато се променя.

Тестване - Определя колко усилия е необходимо за тестване на системата.

Толерантност - способността на системата да се адаптира към промените в околната среда.

Адаптивност - колко лесно се адаптира системата към промените, направени в спецификацията.

Скорост на настройка - колко лесно може да се инсталира системата.

Способност за замяна - колко лесно е да се замени компонент на системата.

Разходи за качество. Тя е много важна. Когато предприемачът реши да тества своя продукт, той всъщност ще прекарва време, пари и усилия, за да го тества.

Избираемост - Определя дали функцията отговаря на изискванията.

Точност - установява правилността на изпълнението на функциите.

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

СЪОТВЕТСТВИЕ С НЕОБХОДИМИТЕ ЗАКОНИ И ПРЕПОРЪКИ.

Осигуряване на качеството и сигурността на софтуера и обработката на транзакциите, свързани с данните.

Надеждност - способността да се работи при определени условия през определен период от време.

Зрелостта е честотата на отказите.

Подновяване - представа за способността на системата да се върне към пълноценна работа след неуспех.

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

Разходи за анализни процеси

Разходите за качество се изчисляват чрез анализ на разходите за съответствие и несъответствията. Цената на първия показател е свързана с:

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

Очаквани разходи. Това е размерът на средствата, изразходвани за планиране на всички тестови задачи, а след това и за тяхното изпълнение, например за разработването на тестови случаи.

Разходи за несъответствие. Това са разходи, които произтичат от вътрешни и външни неуспехи.

Вътрешните неуспехи са разходи, които възникват, когато тестовите случаи се изпълняват за първи път на вътрешно ниво, като някои от тях не успяват. Разходите възникват, когато програмистът трябва да фиксира всички открити дефекти в неговия фрагмент по време на модулно или компонентно тестване. външенотказите са разходи, които възникват, когато дефектът е зададен от клиента, а не от проверителя. Тези разходи са много по-високи от тези, които се появяват на вътрешно ниво. Това е особено вярно, ако софтуерът се провали.

Дисциплиниран анализ на процеси

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

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

Оценка на организация на трета страна.

Оценка от трета страна.

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

Стандартен списък на въпросите за падеж.

Индивидуални и групови интервюта.

Прегледи на документи.

Преглед на проекта за оценка от участниците.

Стандартният метод SCAMPI

Определение на IEEE за осигуряване на качеството на софтуера:

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

Набор от действия за оценка на качеството на качеството на софтуера, чрез койтосе разработват или произвеждат продукти.

CMMI (Институт за софтуерно инженерство) за подобряване на процесите (SCAMPI) е разработен, за да отговори на изискванията, базирани на ИПП и паричния съвет. IPI и SCAMPI се състоят от три етапа:

Планиране и подготовка.

Проверка на оценката на място.

Доклад за резултатите.

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

Определяне на зоната за оценка.

Разработване на плана.

Подготовка на екипа за оценка.

Оценка на участниците.

Администриране на въпросника за CMMI.

Проучване на отговорите във въпросници.

Провеждане на първоначален преглед на документи.

Мерките на етапа на докладване включват:

Представяне на окончателните резултати.

Провеждане на изпълнителната сесия.

Приключване на оценката на качеството на софтуера.

Мерките за фазата на оценка на място включват:

Организиране на отварянето на проекта.

Провеждане на интервюта.

Обобщение на информацията.

Подготовка на представянето на резултатите.

Организация за закриване на проекта.

Организационна структура на персонала

Тя включва тези, които са отговорни за качеството на софтуера. Такива хора могат да бъдат:

Мениджъри.

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

Ръководители на отдела за развитие и подкрепа.

Ръководители на отдел за изпитване.

Ръководители на проекти и екипи за разработване и поддръжка на екип по проекта.

Ръководители на екипитестване.

Тестери.

Членове на екипа за тестване:

Специалисти по SQA и заинтересовани практики.

Попечители на SQA.

Членове на комисиите и членове на форума на SQA.

Членове на екипа на подразделението на SQA.

Само ръководители и служители на отдела за изпитване са наети на пълно работно време за задачите на SQA. Други посвещават само част от своето работно време на въпроси, свързани с качеството. Всъщност в организациите за развитие съществуват тристепенни управленски структури:

Висш ръководен състав.

Управление на отдела.

Управление на проекти.

Ръководителят на проекта е лицето, което отговаря за гарантиране, че всички членове на екипа спазват определените процедури и инструкции. Неговата задача включва професионални практически и управленски въпроси. Ръководителите на проекти изпълняват следните функции:

Работата на звеното за разработка и поддръжка на софтуер.

Работа по интегриране и тестване на разработката на софтуер, корекция и изпълнение на регресивни тестове.

Извършване на инспекции и последващи корекции на недостатъци.

Изпълнение на тестове за приемане.

Инсталиране на софтуер на отдалечени клиентски сайтове.

Необходимостта от инсталиране на антивирусни инструменти

При закупуването на нова, потребителят мисли кога да купува антивирусен софтуер. Мнозина все още наричат ​​този тип антивирусни, въпреки че днес този термин е остарял. Най-лошото е, че „най-добрият“ зловреден софтуер, ако може да бъде наречен, тихо прониквана компютъра без знанието на собственика. Може би това ще бъде скрито от очите на потребителя, но това ще донесе вреда. С сериозното обновяване на операционните системи, необходимостта от инсталиране на подобни подозрителни програми за защита на компютъра е изчезнала. Потребителите вече имат Windows 10. Microsoft е изградила два важни инструмента: защитна стена и Windows Defender. Тези две удари са предназначени за защита на вашия компютър. Тъй като те са интегрирани в операционната система, не се изискват допълнителни външни софтуерни ресурси. Microsoft често актуализира комунални услуги, опитвайки се да предотврати появата на нови заплахи. Ако по някаква причина нещо избухне, има подобрена версия на "защита" - защитник на Windows. Работи офлайн. Можете да го стартирате без да се свързвате с интернет от USB устройство за съхранение. Windows Defender е добър инструмент. Няма причина да не го използвате. С него новите собственици не се сблъскват с такива извънредни ситуации, когато купуват антивирусен софтуер.