Kehittäjä
Toukokuun 8., 2020
App Dev Manager Darroll Walsh jakaa johdannon CMMI development for developers.
Capability Maturity Model Integrated (CMMI) on prosessinkehitys-ja arviointiohjelma, joka integroituu muihin prosessinkehitysohjelmiin, kuten Project Management Body of Knowledge (PMBOK) ja Agile. Se pyrkii virtaviivaistamaan ja standardoimaan kaikkia prosesseja ja tarjoamaan keinon valvoa ja toimia mittareita kehittämiseen, palveluihin, toimittajien hallintaan, Cyber Maturity, ja muut.
haluan tarjota yleiskuvan CMMI Dev: stä kehittäjän näkökulmasta. Sivuutamme CMMI DEV: n projektinhallinnan, liiketoiminta-analyytikon, konfiguraationhallinnan ja testausosuudet keskittyäksemme CMMI: n vaikutuksiin kehitystiimissä. Jos on kiinnostusta muita rooleja tai valmiuksia, jotka voivat olla hyvä aihe myöhemmin blogimerkintä. Huomaa, että ketterässäkin kehityksessä on paljon työtä, joka tapahtuu ennen kuin kehittäjät pääsevät alkuun.
let us get started:
the BRS eli Business Requirements Specification is where it all begins, this is the single source of truth. Tässä kohtaa liiketoiminnan vaatimukset, jotka tuotteen omistaja allekirjoittaa. Vaikka kehittäjiä voidaan kuulla BRS: n luomisessa, tämä on pääasiassa BA: n vastuulla. tämä on kuitenkin paikka, jossa kehittäjä voi todella tutustua kehittämäänsä sovellukseen; paikka saada kokonaiskuva.
korkean ja matalan tason mallit on arkkitehtuurin dokumentaatio, joka osoittaa, miten sovelluksen komponentit on kytketty toisiinsa. Korkean tason suunnittelussa asetamme ulkoiset riippuvuudet ja sen, miten käyttäjät ja/tai järjestelmät ovat vuorovaikutuksessa järjestelmämme kanssa. Matalan tason suunnittelu määrittelisi, miten sisäiset komponentit ovat vuorovaikutuksessa keskenään. Näiden tarkistaminen antaisi toiselle kehittäjälle hyvin nopean käsityksen sovelluksen toiminnasta.
SRS eli Software Requirements Specification on, jossa kehittäjä dokumentoi, miten sovellus aiotaan rakentaa. Tässä dokumentoidaan palvelut, luodaan riippuvuudet ja yleensä se, miten koodin oletetaan toimivan, perustuen luotuun BRS: ään. Tämä tehdään tyypillisesti ennen koodin kirjoittamista, ja se on vakiotehtävä. Tiedän, että jotkut kysyvät, Miksi meidän pitäisi tehdä tämä. Koodini dokumentoi itse itseään. Ja vaikka olen varma, että se on, koodi leviää satoja tiedostoja ja tuhansia rivejä koodia. Joskus tarkoitus ei ole niin selvä kuin haluaisimme. SRS antaa meille yhden asiakirjan tarkastella selkeä pääpiirteittäin, mitä voimme odottaa. Se hahmottelee käyttöjuttuja ja odotettavissa olevaa käyttäytymistä johdonmukaisessa kartanossa.
kun olemme määritelleet, mitä aiomme tehdä, ja sitten kirjoittaneet koodin, on aika pyytää joku tarkistamaan tekemämme. Anna koodin tarkistus. Tämä ei ole vain hyvä käytäntö havaita virheitä ja varmistaa, että noudatamme parhaita käytäntöjä ja ohjeita, se on loistava tapa jakaa, mitä sovellus tekee. Jo pelkästään se, että tarkistamme koodin toisella silmäparilla, antaa meille toisen henkilön, joka tuntee koodin toiminnan. Koska tämä on tullut standardi käytäntö useimmissa kehitys joukkueet, En belabor tämä yksi.
yksikkötestaus on toinen pääjäähy useimmille kehitysohjelmille. Testattiinko yksikkö osana Testivetoista kehitystä vai sen jälkeen, kun koodi on kirjoitettu, on yksi parhaista tavoista varmistaa, että tulevat muutokset eivät tuo virheitä koodiimme. CI / CD-putkistossa voimme varmistaa, että kaikki testit läpäisevät ennen kuin sallimme koodin kirjautumisen. Tämä auttaa meitä pitämään koodin hyvässä toimintakunnossa.
yksittäin jokaisella edellä mainitulla asiakirjakokonaisuudella on arvoa, mutta todellinen hyöty alkaa, kun voit sitoa kaikki nämä tiedot yhteen. Vaatimusten keruuprosessin alussa käynnistämme vaatimusten Jäljitettävyysmatriisin, jonka avulla voimme yhdistää liiketoiminnan vaatimukset, ohjelmistovaatimukset, koodin, yksikkötestit, testaussuunnitelmat ja-tapaukset sekä käyttäjän hyväksynnän yhteen. Kuvitellaan, että puoli vuotta on iso projekti ja muutos saa testitapauksen epäonnistumaan. Voimme nyt palata vaatimuksiin, selvittää koodin tarkoituksen, tietää tarkalleen, missä koodi on logiikalle, muokata yksikkötestiä uuden tapauksen havaitsemiseksi ja korjata tilanteen muutamassa tunnissa, Ei päivässä.
lyhyellä tähtäimellä CMMI voi tuntua ylilyönniltä, mutta pienissäkin projekteissa prosessia seuraamalla saatu tieto lyhentää kierrettä mitä pidempään on poissa projektista. Puhumattakaan siitä, ettet ole työskennellyt projektin parissa aiemmin.
Kehittäjätuki
App Dev Customer Success Account Manager, Microsoft Developer Support
Follow