Informații de inclus
- Referințe pentru controler și software original
- O descriere a comportamentului necesar
- Hardware, interfețe și utilizare prevăzută
- Informații tehnice disponibile și constrângeri ale proiectului
BlagTuning / Software
Când o solicitare de fișier standard nu este suficientă, proiectul începe cu comportamentul software de care aveți nevoie. Cerințele clare transformă o idee complexă într-un domeniu de dezvoltare.
Dezvoltarea personalizată începe prin a descrie ce ar trebui să facă sistemul, în ce condiții și cu ce hardware. O specificație utilă identifică controlerul, software-ul disponibil și intrările sau stările de operare relevante pentru comportamentul solicitat.
Aceasta este diferită de selectarea unei categorii convenționale de calibrare. O conversie, o integrare a componentelor sau o anumită cerință de control poate necesita o etapă de fezabilitate înainte de a putea fi definită livrarea. Primul obiectiv este de a face cerința tehnică suficient de clară pentru a fi evaluată.
Funcționarea software-ului este mai fiabilă atunci când referința originală, modificările anterioare și utilizarea prevăzută sunt cunoscute. Furnizați identificarea disponibilă și explicați comportamentul actual. Dacă sunt implicați mai multe controlere, descrieți rolurile acestora și configurația relevantă.
Cunoașterea strategiilor ECU este valoroasă, deoarece ajută la adresarea întrebărilor potrivite și la identificarea dependențelor. Nu ar trebui prezentat ca o afirmație că fiecare caracteristică este posibilă pe fiecare controler. Sfera de dezvoltare este confirmată pentru software-ul și proiectul actual.
Un proiect personalizat necesită o înțelegere comună a ceea ce va fi livrat și a modului în care va fi evaluat progresul. Acordați comportamentul solicitat, informațiile pe care atelierul le va oferi și punctele în care software-ul va fi revizuit.
Păstrați fiecare revizuire identificabilă. Dacă o modificare hardware sau o cerință suplimentară modifică proiectul, înregistrați-l în mod explicit. Un istoric clar al revizuirilor ajută la distingerea unei ajustări în domeniul de aplicare convenit de o nouă solicitare de dezvoltare. De asemenea, face suportul tehnic mai eficient.
Dezvoltatorul de software și atelierul contribuie cu informații diferite. Fișierul de lucru se adresează software-ului controlerului; atelierul furnizează contextul de instalare și observațiile relevante din aplicație. Calitatea schimbului determină adesea cât de eficient poate progresa o cerere complexă.
Testarea ar trebui să răspundă la întrebările reale ale proiectului. Aceasta poate implica comparații software, date de operare sau alte verificări adecvate, mai degrabă decât o singură măsurare a puterii. Rezultatul este un produs software definit cu contextul necesar pentru a-l utiliza și revizui în mod corespunzător.
Nu se presupune compatibilitate universală. Fezabilitatea depinde de software-ul, controlerul și cerințele identificate.
Nu neapărat. Sfera de dezvoltare și condițiile trebuie convenite înainte de începerea lucrărilor.
O cerință precisă, software original de încredere și o descriere clară a hardware-ului și a comportamentului actual.