Vahvistuskirjaus kattavuuden lisäksi

Yleinen todentamisen suunnittelunäkymä on aloittaa kattavalla todentamissuunnitelmalla, joka kattaa kaikki spesifikaatioissa ja käyttötapauksissa määritellyt vaatimukset, arkkitehtoninen määritelmä ja kaikki muut asiaankuuluvat asiakirjat. Testejä kehitetään sitten kattamaan kaikki todentamissuunnitelman ominaisuudet. Nämä testit suoritetaan ja virheenkorjaus, ja tunnistetut ongelmat käsitellään suunnittelussa. Tämä prosessi toistuu, kunnes sovittu kattavuustaso saavutetaan. Toiminnallinen kattavuus on mittari, jolla tätä prosessia mitataan, ja se toimii hyvin sen puitteissa. Suurilla elektronisen suunnittelun automaation (EDA) toimittajilla on työkaluja simulaatioiden suorittamiseen, kattavuustilastojen keräämiseen ja näiden mittareiden kehittämiseen. Mutta tämä ei ole koko tarina allekirjoituksessa. Kattavuus mittaa varmennussuunnitelman noudattamista, joka on useita vaiheita poistettu asiakkaan vaatimuksista. Mistä suunnittelijat tietävät, ettei tärkeitä tietoja ole pudonnut tai lisätty matkan varrella?

Millä muulla on merkitystä kirjautumisessa?

Kaikella ennen sisäisesti kehitettyjä toiminnallisia spesifikaatioita/vaatimuksia on merkitystä. Ei ole mahdollista sulkea täysin silmukkaa asiakkaan vaatimusten ja toteutuksen/todennuksen välillä, ellei niitä ole sisällytetty analyysiin. Nyt arvoketjut on pakattu, ja järjestelmät sirulle (SoC) ovat tulossa sovelluskohtaisemmiksi. Asiakkaat odottavat suunnitelmia, jotka on viritetty heidän täsmälleen heidän tarpeisiinsa, joten heidän määrittämänsä vaatimukset on sovitettava käyttöönotossa/todentamisessa. Sitä ei oteta hyvin vastaan, jos asiakas huomaa, että hänen odotetaan korjaavan virheitä.

Haasteena tässä on, että määritelmä voi olla melko sekalainen syötepussi: Word, PDF, DITA-pohjaiset asiakirjat, laskentataulukot, Simulink-, SysML- tai virtuaalimallin prototyypit ja ohjelmistolataukset, joiden pitäisi toimia lopullisessa laitteistossa (ehkä joissakin tapauksissa). muutokset). Voi olla myös dokumentoituja vaatimuksia DOORS-, Jama Connect- tai vastaavassa muodossa. Miten todennustiimi, suunnittelutiimi tai arkkitehti ilmoittaa, että toteutus ja todennus vastaavat vaatimuksia? He tekevät tietysti parhaansa, mutta missä on yksityiskohtainen ja tarkastettava prosessi, jolla varmistetaan, että jokainen vaatimus liittyy toteutukseen ja että toteutuksen todentaminen katetaan riittävästi?

Tämän konkretisoimiseksi oletetaan, että on olemassa ominaisuus, jota yksi tärkeä asiakas haluaa, mutta kukaan muu ei vaadi. Ehkä huolimattomuudesta tai väärinymmärryksestä johtuen tämä ominaisuus ei sisälly toiminnallisiin määrityksiin/vaatimuksiin. Sitä tapahtuu aivan liian usein. Jopa 100 %:n kattavuus ei ratkaise tätä ongelmaa, koska kattavuus on vain yhtä hyvä kuin varmistussuunnitelma. On suuri ongelma, jos varmennussuunnitelma ei vastaa tarkasti vaatimuksia.

Tai oletetaan, että suunnittelun aikana tiimi päättää, ettei se voi toteuttaa täsmälleen sitä, mitä spesifikaatio pyytää, vaan vaihtoehto toteutetaan siinä uskossa, että se on yhtä hyvä tai jopa parempi. Tiimi ei tiedä, että tämä muutos vaikuttaa suorituskykyyn joissakin harvinaisissa mutta tärkeissä käyttötapauksissa. Ehkä tämä jää kiinni simulaatioon? Ehkä, mutta on erittäin vaikeaa olla kattava järjestelmätason testauksessa. On olemassa todellinen riski, että tämä ongelmallinen muutos säilyy piin asti.

Vaatimusten jäljitys täydentää vahvistuksen allekirjoittamisen kattavuutta

Word-asiakirjojen, virtuaalimallien ja rekisterinsiirtotason (RTL) välisen vastaavuuden tarkistuksen suorittaminen ei todennäköisesti ole mahdollista elinaikanamme, mutta sen ei tarvitse olla. Järjestelmänrakentajat ja ohjelmistotiimit käyttävät jo aktiivisesti vaatimusten jäljitettävyyttä erittäin vankana menetelmänä huipputason ja toteutustason vaatimusten välisen vastaavuuden seuraamiseen aina toteutukseen, todentamiseen ja testaukseen saakka. Tätä jäljitettävyyttä tuetaan vaatimusten jäljityksellä Requirements Interchange Format (ReqIF) -alustoilla, kuten DOORS- ja Jama Connect -työkaluilla.

Vaikka nämä työkalut on suunniteltu helppokäyttöisiksi ohjelmistomaailmassa, ne eivät ymmärrä laitteiston semantiikkaa. Ne tukevat "vieraiden esineiden" yhteyksiä muodostaakseen yhteyden suunnittelu- ja varmennustietoihin, mutta taakka näiden linkkien tekemisestä oikein on suunnittelu- ja todentamisinsinööreillä. Tämä ei ehkä ole niin paha, jos seurattavia kohteita olisi vain muutama sata. Mutta ajattele muistikartta, keskeytyskartta, IO-sekoituskartta; ne voivat ulottua kymmeniin tuhansiin tai useampiin esineisiin. Kaikkien näiden objektien manuaalinen päivittäminen suunnittelumuutoksilla ja uudelleenosioinnilla tulee erittäin vaikeaksi, ellei mahdottomaksi.

Parempi lähestymistapa on jäljitettävyyden hallinta, joka voi muodostaa yhteyden ReqIF:n kaltaisiin työkaluihin asiakkaan puolella ja suoraan suunnittelu- ja todentamistiimien jäljittämiin artefakteihin. Suunnittelusemantiikan ymmärtäminen mahdollistaa vaatimusten ja toteutuksen välisten yhteyksien päättelemisen ja niiden seuraamisen oikein projektin edetessä. Tämä menetelmä varmistaa tarkastettavat yhteydet asiakkaan spesifikaatioista aina suunnitteluvaatimuksiin ja viime kädessä SoC:n toteuttamiseen.

Tämä on jäljitettävyys, joka voi täydentää todentamisen allekirjoitustavoitteen, jolla on vähäinen vaikutus SoC-suunnittelutiimeihin. Sellainen jäljitettävyystuki, josta löydät Arteris Harmony Trace.