Ontwikkelaar
8 Mei, 2020
App Dev Manager Darroll Walsh aandelen een introductie CMMI voor ontwikkeling voor ontwikkelaars.
het Capability Maturity Model Integrated (CMMI) is een procesverbeterings-en beoordelingsprogramma dat integreert met andere procesverbeteringsprogramma ‘ s zoals het Project Management Body of Knowledge (PMBOK) en Agile. Het werkt aan het stroomlijnen en standaardiseren van alle processen en bieden een middel om toezicht en bruikbare statistieken voor ontwikkeling hebben, Diensten, leveranciersmanagement, Cyber Maturity, en anderen.
wat ik wil doen is een overzicht geven van CMMI dev vanuit het perspectief van een ontwikkelaar. We zullen het projectmanagement, business analist, Configuratiebeheer en het testen van delen van CMMI dev overslaan om ons te concentreren op de impact van CMMI op een ontwikkelingsteam. Als er interesse is in de andere rollen of mogelijkheden die een goed onderwerp kan zijn voor een latere blog. Merk op dat er veel werk is dat gebeurt voordat ontwikkelaars aan de slag gaan, zelfs in Agile ontwikkeling.
laten we beginnen:
de BRS, of Business Requirements Specificatie is waar het allemaal begint, dit is de enige bron van waarheid. Dit is waar de zakelijke eisen die de eigenaar van het product ondertekent. Hoewel de ontwikkelaars kunnen worden geraadpleegd bij het maken van de BRS, is dit vooral de verantwoordelijkheid van BA ‘ s. echter, dit is waar een ontwikkelaar echt kennis kan maken met de applicatie die ze ontwikkelen; een plek om het grote plaatje te krijgen.
ontwerpen op hoog en laag niveau zijn de architectuurdocumentatie die laat zien hoe de componenten van de toepassing met elkaar verbonden zijn. In het high-level ontwerp, we zouden lay-out externe afhankelijkheden en hoe de gebruikers en/of systemen zullen interageren met t ons systeem. Het low-level ontwerp zou uitleggen hoe interne componenten met elkaar communiceren. Het beoordelen van deze zou een andere Ontwikkelaar een zeer snel begrip van de werking van de applicatie te geven.
de SRS, of Software Requirements Specification, is waar de ontwikkelaar documenteert hoe de applicatie zal worden gebouwd. Dit is waar diensten worden gedocumenteerd, afhankelijkheden worden opgemaakt, en in het algemeen hoe de code moet werken, gebaseerd op de BRS die is gemaakt. Dit wordt meestal gedaan voordat de code wordt geschreven en is een standaard taak. Ik weet dat sommigen vragen waarom we dit zouden moeten doen. Mijn code documenteert zichzelf. En hoewel ik er zeker van Ben, code wordt verspreid door honderden bestanden en duizenden regels code. En soms is de bedoeling niet zo duidelijk als we zouden willen. De SRS geeft ons één document om naar te kijken met een duidelijk overzicht van wat we kunnen verwachten. Het schetst use cases en het verwachte gedrag in een consistente manor.
nadat we definiëren wat we gaan doen, en dan de code schrijven, is het tijd om iemand te laten beoordelen wat we deden. Voer de Code Review in. Dit is niet alleen een goede praktijk om fouten op te vangen en ervoor te zorgen dat we de beste praktijken en richtlijnen volgen, het is een geweldige manier om te delen wat de applicatie doet. De loutere handeling van het herzien van de code door een tweede set ogen geeft ons een tweede persoon die bekend is met hoe de code werkt. Aangezien dit de standaardpraktijk is geworden in de meeste ontwikkelingsteams, zal ik hier niet op ingaan.
het testen van eenheden is een ander belangrijk onderdeel van de meeste ontwikkelingsprogramma ‘ s. Unit testen of gedaan als onderdeel van Test Driven Development of gedaan nadat de code is geschreven, zijn een van de beste manieren om ervoor te zorgen toekomstige veranderingen geen fouten in onze code. In een CI / CD pijplijn kunnen we ervoor zorgen dat alle tests passeren voordat we toestaan dat code in te checken. Dit helpt ons om de code in goede staat te houden.
afzonderlijk is er waarde in elke set documenten hierboven, maar de werkelijke winsten beginnen wanneer u al deze informatie aan elkaar kunt koppelen. In het begin van het requirements gathering-proces starten we een requirements Traceability Matrix waarmee we bedrijfsvereisten, softwarevereisten, code, unit tests, testplannen en cases en gebruikersacceptatie aan elkaar kunnen koppelen. Stel je zes maanden in een groot project voor en een verandering zorgt ervoor dat een testcase mislukt. We kunnen nu teruggaan naar de vereisten, uitzoeken wat het doel van die code is, precies weten waar de code voor die logica is, de unit test aanpassen om de nieuwe zaak te vangen, en een fix implementeren binnen uren, niet dagen.
op korte termijn lijkt CMMI misschien overkill, maar zelfs bij kleine projecten verkort de kennis die verkregen wordt door het proces te volgen de cyclus hoe langer je weg bent van het project. En je hebt nog nooit aan het project gewerkt.
Ondersteuning Voor Ontwikkelaars
App Dev Customer Success Account Manager, Microsoft-Ondersteuning Voor Ontwikkelaars
Volgen