Fejlesztő
május 8, 2020
Darroll Walsh alkalmazásfejlesztő menedzser bemutatja a CMMI fejlesztését a fejlesztők számára.
a Capability Maturity Model Integrated (CMMI) egy folyamatfejlesztési és értékelési program, amely integrálódik más folyamatfejlesztési programokkal, mint például a Project Management Body of Knowledge (PMBOK) és az Agile. Úgy működik, hogy racionalizálja és szabványosítja az összes folyamatot, és olyan eszközt biztosít, amely felügyeletet és cselekvőképes mutatókat biztosít a fejlesztés, a szolgáltatások, a beszállítói menedzsment, a számítógépes érettség és mások számára.
amit tenni akarok, az a CMMI Dev áttekintése fejlesztő szemszögéből. Átugorjuk a CMMI dev projektmenedzsmentjét, üzleti elemzőjét, konfigurációkezelését és tesztelési részeit, hogy a CMMI fejlesztői csapatra gyakorolt hatására összpontosítsunk. Ha van érdeklődés a többi szerep vagy képesség iránt, akkor ez jó téma lehet egy későbbi blogbejegyzéshez. Csak vegye figyelembe, hogy sok munka történik a fejlesztők megkezdése előtt, még az agilis fejlesztés során is.
kezdjük:
a BRS vagy az üzleti követelmények specifikációja az, ahol minden kezdődik, ez az igazság egyetlen forrása. Ez az, ahol az üzleti követelmények, hogy a termék tulajdonosa aláírja. Bár a fejlesztőkkel konzultálni lehet a BRS létrehozásáról, ez elsősorban a BA felelőssége. azonban ez az, ahol a fejlesztő valóban megismerheti az általuk fejlesztett alkalmazást; egy hely, ahol a nagy képet kaphatja.
a High-level and low-level designs az architektúra dokumentációja, amely bemutatja az alkalmazás összetevőinek összekapcsolását. A magas szintű tervezés során meghatároztuk a külső függőségeket és azt, hogy a felhasználók és / vagy rendszerek hogyan lépnek kapcsolatba a rendszerünkkel. Az alacsony szintű kialakítás meghatározza, hogy a belső alkatrészek hogyan hatnak egymásra. Ezek áttekintése egy másik fejlesztőnek nagyon gyorsan megértené az alkalmazás működését.
az SRS vagy a szoftverkövetelmények specifikációja az, ahol a fejlesztő dokumentálja az alkalmazás felépítésének módját. Ez az, ahol a szolgáltatásokat dokumentálják, a függőségeket lefektetik, és általában azt, hogy a kódnak hogyan kell működnie, a létrehozott BRS alapján. Ez általában a kód megírása előtt történik, és szabványos feladat. Tudom, hogy néhányan azt kérdezik, miért kellene ezt tennünk. A kódom öndokumentáló. És bár biztos vagyok benne, hogy az, a kód több száz fájlban és több ezer sornyi kódban terjed. Néha a szándék nem olyan egyértelmű, mint szeretnénk. Az SRS ad nekünk egy dokumentumot, hogy nézd meg egy világos vázlatot, hogy mit várhatunk. Felvázolja a felhasználási eseteket és a várható viselkedést egy következetes kastélyban.
miután meghatároztuk, mit fogunk csinálni, majd megírtuk a kódot, itt az ideje, hogy valaki felülvizsgálja, mit tettünk. Írja be a kód felülvizsgálatát. Ez nem csak egy jó gyakorlat a hibák észlelésére és annak biztosítására, hogy kövessük a legjobb gyakorlatokat és iránymutatásokat, hanem nagyszerű módja annak, hogy megosszuk az alkalmazás tevékenységét. A kód második szemével történő felülvizsgálata egy második személyt ad nekünk, aki ismeri a kód működését. Mivel ez a legtöbb fejlesztő csapatban bevett gyakorlattá vált, ezt nem fogom dolgozni.
az egység tesztelése a legtöbb fejlesztési program másik fő tartózkodása. Az egység tesztelése akár a Tesztvezérelt fejlesztés részeként, akár a kód megírása után történik, az egyik legjobb módszer annak biztosítására, hogy a jövőbeni változások ne vezessenek be hibákat a kódunkba. A CI / CD csővezetékben biztosíthatjuk, hogy minden teszt sikeres legyen, mielőtt engedélyezzük a kód ellenőrzését. Ez segít abban, hogy a kódot jó állapotban tartsuk.
külön-külön van értéke az egyes dokumentumok felett, azonban az igazi nyereség kezdődik, ha lehet kötni az összes információt együtt. A követelmények összegyűjtésének kezdetén elindítjuk a követelmények nyomon követhetőségi mátrixát, amely lehetővé teszi számunkra, hogy összekapcsoljuk az üzleti követelményeket, a szoftverkövetelményeket, a kódot, az egységteszteket, a tesztterveket és az eseteket, valamint a felhasználói elfogadást. Képzeljünk el hat hónapot egy nagy projektben, és egy változás egy teszteset kudarcát okozza. Most visszatérhetünk a követelményekhez, megtudhatjuk, mi a kód célja, pontosan tudjuk, hol van a logika kódja, módosíthatjuk az egységtesztet, hogy elkapjuk az új esetet, és órák, nem napok alatt végrehajthatunk egy javítást.
rövid távon a CMMI túlzásnak tűnhet, de még a kis projekteknél is, a folyamat követésével megszerzett tudás lerövidíti a ciklust, minél hosszabb ideig távol van a projekttől. Nem is beszélve arról, ha még soha nem dolgozott a projekten.
Fejlesztői Támogatás
App Dev Ügyfél Siker Account Manager, Microsoft Fejlesztői Támogatás
Kövesse