*Текстът е предоставен от Luxoft
ASPICE (Automotive Software Process Improvement Capability dEtermination) е стандарт, който има за цел да подобри процесите на разработване на софтуер в автомобилната индустрия. Той е доразвита версия на ISO/IEC 15504 (SPICE) и се използва за оценка на ефективността и качеството на софтуерните разработки от водещите фирми доставчици в тази индустрия.
Мартин Иванов, Тест мениджър и лидер на IVI (инфотейнмънт) технологичната общност на Луксофт ще сподели своите знания и опит за това как ASPICE може да бъде използван за подобряване на процеса на тестване в автомобилната индустрия и как да подготвите своя тест екип за одит.
Авторът на статията е с богат опит в автомобилния бранш. Той е работил с водещи марки като Mercedes-Benz, VW Group, Mazda, Honda и много други. Мартин има бакалавърска степен по Индустриално Инженерство и магистърска степен по Е-мениджмънт в Техническия Университет, София. Той живее в Германия от 6 години. Свободното си време, Мартин се посвещава на колите, кучето си и на любителските занимания по фотография.
Какво представлява ASPICE?
ASPICE е базиран на V-модела за разработване на софтуер/хардуер. Основната идея на тези процеси е да предоставят прозрачност и проследимост между всички артефакти в даден проект.
С развитието на софтуера в автомобилната индустрия, производителите на коли работят с все повече фирми доставчици, което прави задачата за проверка на ефикасността на проектите все по-комплексна и сложна.
С тази идея през 2001 AUTOSIG (English Auto motive Special Interest Group), включваща производители като Audi, BMW, Daimler, Porsche, VW, Fiat, Ford, Jaguar, Land Rover, Volvo, и други, поставя основите на ASPICE. Целта е да има единна система по която всички фирми доставчици могат да работят и да могат да бъдат лесно оценявани от външни лица (било то директно от производителите или от трети лица).
С оглед някои скорошни дискусии на тема автомобилен софтуер, изискванията за спазване на ASPICE процесите се разширяват и вече обхващат не само автомобилния софтуер, но и други софтуерни проекти на автомобилните компании (напр. cloud based функционалности).
Какво представлява ASPICE oдитът?
Loading ...Представители на автомобилния производител или фирма одитор проверяват дали изискванията за прозрачност и проследимост са изпълнени като оценката, която може да бъде получена, е между ниво 0 и ниво 5.
• НИВО 0 | Basic
Екипите на ниво 0 все още разработват процеси или системи. Те могат най-много „частично“ да постигнат изискванията на ASPICE. Тези екипи трябва да съсредоточат по-голямата част от усилията си върху управлението на основни задачи.
• НИВО 1 | Performed
Екипите, постигащи ниво 1, почти или напълно изпълняват стандартните изисквания на ASPICE, но вероятно имат пропуски в своите процеси.
• НИВО 2 | Managed
Екипите от ниво 2 могат надеждно да доставят работни продукти и почти или напълно да постигнат стандартите на ASPICE.
• НИВО 3 | Established
На Ниво 3 екипите са установили и задали стандарти за изпълнение и са ангажирани в непрекъснато подобряване, за да оценяват постоянно и да учат.
• НИВO 4 | Predictable
Екипите от ниво 4 измерват, записват и анализират резултатите; обективно оценяване на резултатите и процесите; и постоянно отговарят на стандартите за ефективност.
• НИВО 5 | Innovating
Екипите от ниво 5 са достигнали етап, в който не само непрекъснато доставят продукти с висока производителност и качество, но и се ангажират и инвестират в непрекъснато подобрение. Тези екипи също анализират стандартите за ефективност за количествена обратна връзка и разрешаване на причинно-следствен анализ.
Как да подготвим тест екипа за ASPICE одит?
Без значение къде спадат отговорностите за тестове спрямо нивата на ASPICE (едно конкретно ниво или всички тест нива – SWE.4, SWE.5, SWE.6, SYS.4, SYS.5) точките които трябва да бъдат покрити, за да се подсигури успех на тест екипа, са еднакви.
Повечето хора, сблъсквайки се с ASPICE за първи път, считат че е достатъчно да се следват BP (best practices) точките и всичко ще бъде наред, но това е сериозна грешка. За да се постигне адекватно ASPICE ниво, количеството документация, която трябва да бъде налична, е доста голямо, въпреки, че в повечето случаи това не е видимо в началото на проекта.
1. Избиране на правилните инструменти
Много е важно да бъдат избрани инструменти, предоставящи:
o Високо ниво на автоматизация – спестява усилия за ръчно и монотонно въвеждане на информация
o Налични интерфейси за свързване с останалите налични инструменти – спестява усилия за “home made” автоматизации за обмен на информация между различни инструменти, нужна за една от най важните точки от ASPICE, а именно проследимостта на артефактите от началото до края на процеса за разработване.
2. Правилно калкулиране на нужните човешки ресурси
Едно от най-честите твърдения, които чувам когато става на въпрос за първа имплементация на ASPICE е – „Не са ни нужни допълнителни ресурси, ще се справим в движение“. Доста често това води до лоши резултати при одита. Дори и точка 1 да бъде изпълнена, допълнителните задължения – повече нива на тестване, документация, ревю процеси т.н. оказва огромно влияние върху количеството работа, което екипът може да поеме и доста често е нужно увеличаване на числеността му.
3. Координиране с отговорни за „лявата част“
Тест процесите са строго свързани с доставяне на правилните документи навреме (Software Detailed Design – SW Unit testing, SW Architecture -–SW Integration testing и т.н.). Поради тази причина е изключително важно тест мениджърът/тест лийд-ът да координира плановете за постигане на повече от ASPICE ниво 0 с отговорните лица за тези дейност, визуализирани в лявата част на V-модела.
Една от най-важните точки за тест екипа е, че трябва да има двупосочна проследимост между тестовете и отговарящите документи с изисквания. Ако има разминаване в процесите, инструментите или идеите как да се работи с ASPICE между лявата и дясната част, постигането на позитивни резултати от одита (както и подсигуряването на адекватно качество на продукта) ще е почти невъзможно.
4. Обучение и следене на тест екипа
Изключително важно е всеки тестер да е запознат детайлно с очакванията за неговата позиция. Това включва не само какво трябва да бъде доставено като свършена работа, но и какво трябва да бъде налично, за да започнат тест дейностите. Решението тук е организиране на основни обучения какво представлява ASPICE. Всички детайли трябва да бъдат описани в тест стратегията.
Проверки на качеството (било то от тест мениджъра или вътрешно фирмени одити) трябва да бъдат извършвани регулярно. Смислени периоди се определят на база продължителността на конкретен проект.
5. Поддържащи процеси (SUP)
Въпреки, че името им е поддържащи процеси, те са в основата на доста дейности от тест екипа. Доста често поради заблуждаващото име тези процеси са оставени с нисък приоритет. Препоръчително е тест мениджърът/лийд-ът да обърне внимание на регулирането на този тип процеси. В зависимост от големината на проекта, може да се наложи и да изработи поне предложение за организация на работата.
Основната цел при подготовка за работа с ASPICE е да се осигури ефикасност при документирането, за да може екипът да има полза от всичките тези процеси и да се избегне генерирането на голям брой документационни задачи по време на целия проект. Ползите от добре имплементирани ASPICE процеси са не само за клиента, но и за всички участници, ангажирани в проекта. Колкото по-рано се започне работа по планирането и гореспоменатите точки, толкова по-лесно и гладко ще върви имплементацията на процесите, както и самата работа.
Ако искате да се присъедините към екипа на Луксофт България разгледайте всички отворени позиции на компанията в Job Board-a на DEV.BG и започнeтe своето ново кариерно пътешествие с най-новите технологии от IT сектора.