Endava Career Days Jan 2012 Analysis and Architecture in Endava

1,642 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,642
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The developers and testers are focussed on delivering code and verifying quality. However, to build the most effective team, the scrum needs to think outside the dotted box, taking in the perspectives of all those other team roles so that their perspectives enrich every decision made. This is critical to deliver on the promise of Agile.
  • Endava Career Days Jan 2012 Analysis and Architecture in Endava

    1. 1. A&A in Endava.How do we get tosoftware quality? Carmen David Cezar Coca Florin Cardasim - Career Days, Jan 2012 -
    2. 2. Agenda • The A&A discipline in Endava ● Disciplines & Projects • Business Analysis at Endava ● Who, what and how? • Architecture at Endava ● What is architecture? Views, tools, technologies, practices? ● Sonar: one step towards software quality ● Toxicity matrix 2
    3. 3. Endava: disciplines and projects• 2 dimensions: • Vertical one - disciplines • Horizontal one - projects• Each discipline focuses on People Development and Best Practices Projects Management Analysis & Architecture Development Testing Managed ServicesIN YOUR ZONE
    4. 4. The Analysis & Architecture DisciplineClose to the Team and very visible to the Customer Business Analyst System Analyst Architect• Owns requirements • Owns detailed design • Owns the architecture management • Owns technical • tools & technologies• Owns functional specifications • strategic decisions specifications • Helps for requirements • critical components• Helps in testing management • coaching & training • Helps for functional • Does presales work • specifications Does development • Customer workshops & presentations • Proposals IN YOUR ZONE
    5. 5. The Scrum and outside of it 1 2 3 1. Scrum Master 2. Dev Lead 4 5 3. Developer 6 4. Developer 7 8 The Scrum 5. Developer 6. Test Lead 7. Tester 9 8. Tester 10 Business Analyst 9. Product Owner 10. Business Analyst 12 11. Architect 13 12. UAT Coordinator 13. Environments 14 14. Operational Support11 System Analyst/Architect 15. Your Mum Everyone else you need to get the 15 software deliveredIN YOUR ZONE 5
    6. 6. The Project Team Dev Lead Tester Project ManagerBusiness Analyst Product owner Project plan System Analyst Developer IN YOUR ZONE 6
    7. 7. Who’s the BA in the room? I speak Java I speak “Tell me what English “I will you need” tell you what I want” I have to support it … I have to teach “must be user Let me be people to use friendly” your it “…must be interpreter easy to use”IN YOUR ZONE 7
    8. 8. The Business Analyst is…•A liaison among stakeholders to elicit, analyze, communicate and validate requirements for changes to business processes, policies, and information systems – IIBA•The one who ensures that requirements are visible to and understood by all stakeholdersIN YOUR ZONE 8
    9. 9. The Business Analyst does… Analyze and Scope the Identify Document Business Area solutions Requirements Verify Solution Elicit Communicate Meets the requirements Requirements RequirementsIN YOUR ZONE 9
    10. 10. Architecture – is it just a bunch of views/diagrams?What is Architecture?IN YOUR ZONE
    11. 11. Architecture – is it about (the right) tools?IN YOUR ZONE
    12. 12. Architecture – is it about (the right) technologies?IN YOUR ZONE
    13. 13. Architecture - is it about (the best) practices?IN YOUR ZONE
    14. 14. So What is Architecture?•Probably a smart combination of all the above•What we know for sure is that Architecture is a determinant factor for software quality •Sonar: one step towards software qualityIN YOUR ZONE 14
    15. 15. SonarOpen platform to manage code qualityCovers the 7 axes of code qualityIN YOUR ZONE 15
    16. 16. Sonar – the dashboardIN YOUR ZONE 16
    17. 17. Non respect of coding standards and best practicesIN YOUR ZONE 17
    18. 18. Lacking comments in the source code, especially inpublic APIsIN YOUR ZONE 18
    19. 19. Having duplicated lines of codeRecommended best practice is that to qualify for deployment, code duplication levelsshould be kept under 8%IN YOUR ZONE 19
    20. 20. ComplexityIN YOUR ZONE 20
    21. 21. Unit tests70-80% code coverage is a reasonable goalIN YOUR ZONE 21
    22. 22. Architecture and DesignHaving a spaghetti design (cyclic dependencies)IN YOUR ZONE 22
    23. 23. Dependency MatrixIN YOUR ZONE 23
    24. 24. Enforce Architectural rulesBuild Breaker pluginIN YOUR ZONE 24
    25. 25. Toxicity ChartMore details on Erik Doernenburg siteIN YOUR ZONE 25
    26. 26. Toxicity Chart – Open Source ProjectIN YOUR ZONE 26
    27. 27. Toxicity Chart – Reviewed ProjectIN YOUR ZONE 27
    28. 28. Carmen David | Business Analyst Cezar Coca | System Analyst Florin Cardasim | Head of Analysis & Architecture Thank you!IN YOUR ZONE 28

    ×