![Agenda ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (17)
Similaire à Care with Source2VALUE
Similaire à Care with Source2VALUE (20)
Care with Source2VALUE
- 1. CARE for software CARE = Computer Aided Redocumentation & Evaluation
- 5. Source2VALUE Market Growing demand for transparency EUROPE USA High Low Low High “ Trust you” “ Tell me” “ Show me” Trust Transparency demand
- 8. Source2VALUE Market Source code analyses benefits Maintenance Cost Impact Analyses Lead Time Risk Document / Design Generation IT Management Insight in Changes Instrument for Impact Analyses Current (design) Documentation Software Development Compliancy Cost of Rebuilding Size estimation (FPA) Cost of Change (Maintenance FPA) Contract Management Risk Compliancy Cost Control Cost Reduction Quality & Control Quality Fraud Prevention Complexity Control Maintainability Control Standard & Guidelines Verification
- 20. Source2VALUE Solution CARE Approach Company Policy Define, determine and improve Development Environment OXML Repository Automated Source code Analyses Reporting Portal Sourceviewer Designviewer Cloneviewer Exceptions to Company Policy Metrics Company Policy Improv. Prescription Metrics Clones Advice Death code Design Report generation Source code Standards & Guidelines Documentation Configuration Quality Audit Reports Case tool export UML Technical Model Case tool export UCE exports
- 22. Source2VALUE demo Demo
Notes de l'éditeur
- Brent Spar Moberg Claim en afreken cultuur uit het Wilde westen 3
- Wanneer je het hebt over systeemdocumentatie dan heb je het over documentatie op verschillende niveaus. In mijn opleiding eind jaren tachtig werd o.a. al gesproken over functionele ontwerpen, technische ontwerpen. Nu zie je meestal een onderverdeling naar business, application/systeem en technologie. Dit model is ook prima toepasbaar bij herdocumentatie van systemen of delen van systemen. Bedrijven hebben vaak al wel een of andere vorm van een business model (procesmodellen, werkinstructies e.d.) Juist in deze tijd zie je dat bedrijven de tijd hebben om weer aan procesverbetering te denken en wordt bijvoorbeeld BPM toegepast om processen te modelleren en te monitoren. Het Technology Model kan met de juiste hulpmiddelen voor een groot deel gegenereerd worden uit broncode (UML). De kunst is nu om het systeemmodel te op orde te brengen waarbij de relatie weer tot stand wordt gebracht tussen bedrijfsprocessen en systeemfuncties. Use Cases vormen wat mij betreft het hart van het systeemmodel, waar nodig aangevvuld met andere modellen. In het kader van outsourcing is het van belang om aspraken te maken over het up-to-date houden van de documentatie.
- Voor inzicht in de functionele en technische werking van een systeem heb je een bepaalde vorm van documentatie nodig. Wat zijn nu kenmerken van goede documentatie? Light but sufficient Zo weinig mogelijk om het systeem toch goed en te kunnen onderhouden Niet alles hoeft gedocumenteerd te worden. Technische documentatie kan vaak gegenereerd worden en is soms voldoende Eenvoudig up-to-date te houden Hoge kwaliteit Het zijn wellicht open deuren, maar wanneer je een assement uitvoert op de systeemdocumentatie, dan blijkt toch vaak dat niet aan deze eisen wordt voldaan. Single point of definition Versiebeheer
- Bedrijven hebben in deze tijd meer ruimte om te verbeteren. Zorg dat je nu orde op zaken stelt, om bij het aantrekken van de markt sneller te kunnen reageren. Ongebruikte code: ongebruikte programma’s, rapporten e.d., maar ook dode code Requirements Management: Hoe is het zover gekomen en wat er aan te doen Herdocumentatie zonder gedegen requirements management proces vaak zinloos Onderdeel van Requirements Management is het bepalen van het Requirements Informatie Model (klantspecifiek) Product versus Procesdocumentatie Het documentatiemodel wat ik net liet zien betreft met name de productdocumentatie die de status van een systeem of deelsysteem op een bepaald moment volledig weergeeft. Tijdens het onderhoud wordt de productdocumentatie als uitgangspunt gebruikt en worden procesdocumenten geproduceerd. In deze procesdocumenten wordt met name aangegeven welke onderdelen men op welke manier wil aanpassen. Zijn de voorgestelde wijzigingen geaccepteerd, dan kan de productdocumentatie weer worden geactualiseerd en kan de procesdocumentatie gearchiveerd. Wie is waarvoor verantwoordelijk? Zeker bij outsourcing Waar te beginnen: Ontwerpers/engineers weten vaak waar de problemen zitten (enquete) Metrieken geven inzicht in volatiliteit omvang, complexiteit en onderhoudbaarheid van systemen en componenten op verschillende niveaus Afh van strategie. Wat ga je outsourcen?
- Teamsamenstelling : Engineers die de code kunnen lezen en vertalen naar een hoger niveau Business Architecten, Eindgebruikers voor validatie, rationales Tooling : Handmatig leidt vaak toch tot maatwerk tooling Verschillende leveranciers die diensten leveren op dit gebied, steeds vaker ook bepaalde metrieken in ontwikkelomgevingen Institutionaliseer : Software Engineering is een vak en documentatie bijhouden is daar een belangrijk onderdeel van Vergelijking met een huisarts Je verwacht van een huisarts ook dat hij een dossier bijhoud met de diagnoses en medicijnen en behandelingen die hij heeft voorgeschreven Om te voorkomen dat er de volgende keer verkeerde medicatie wordt voorgeschreven met alle risico’s van dien Om kennis over te dragen. Het is snel weer verouderd Verandering van processen kost tijd. Automatiseer delen van de documentatie door documentatiegeneratie