This document discusses software quality and architecture practices at Endava. It introduces the Analysis & Architecture discipline, which focuses on business analysis, system analysis, and architecture. Business analysts elicit and document requirements, while system analysts focus on design and specifications. Architects own the architecture including tools, technologies, and strategic decisions. The document discusses how Sonar is used to measure code quality across various axes like coding standards, comments, duplication, complexity, and unit testing. Architecture diagrams and matrices are presented as tools to enforce rules and visualize dependencies. Finally, a toxicity chart is introduced to classify software quality issues.

1. A&A in Endava.
How do we get to
software quality? Carmen David
Cezar Coca
Florin Cardasim
- Career Days, Jan 2012 -

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. 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 Services
IN YOUR ZONE

4. The Analysis & Architecture Discipline
Close 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. 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 Support
11 System Analyst/Architect 15. Your Mum
Everyone else you
need to get the
15 software delivered
IN YOUR ZONE 5

6. The Project Team
Dev Lead Tester
Project Manager
Business Analyst Product owner
Project plan
System Analyst Developer
IN YOUR ZONE 6

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. 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 stakeholders
IN YOUR ZONE 8

9. The Business Analyst does…
Analyze and
Scope the Identify
Document
Business Area solutions
Requirements
Verify Solution
Elicit Communicate Meets the
requirements Requirements Requirements
IN YOUR ZONE 9

10. Architecture – is it just a bunch of views/diagrams?
What is Architecture?
IN YOUR ZONE

11. Architecture – is it about (the right) tools?
IN YOUR ZONE

12. Architecture – is it about (the right) technologies?
IN YOUR ZONE

13. Architecture - is it about (the best) practices?
IN YOUR ZONE

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 quality
IN YOUR ZONE 14

15. Sonar
Open platform to manage code quality
Covers the 7 axes of code quality
IN YOUR ZONE 15

16. Sonar – the dashboard
IN YOUR ZONE 16

17. Non respect of coding standards and best practices
IN YOUR ZONE 17

18. Lacking comments in the source code, especially in
public APIs
IN YOUR ZONE 18

19. Having duplicated lines of code
Recommended best practice is that to qualify for deployment, code duplication levels
should be kept under 8%
IN YOUR ZONE 19

20. Complexity
IN YOUR ZONE 20

21. Unit tests
70-80% code coverage is a reasonable goal
IN YOUR ZONE 21

22. Architecture and Design
Having a spaghetti design (cyclic dependencies)
IN YOUR ZONE 22

23. Dependency Matrix
IN YOUR ZONE 23

24. Enforce Architectural rules
Build Breaker plugin
IN YOUR ZONE 24

25. Toxicity Chart
More details on Erik Doernenburg site
IN YOUR ZONE 25

26. Toxicity Chart – Open Source Project
IN YOUR ZONE 26

27. Toxicity Chart – Reviewed Project
IN YOUR ZONE 27

28. Carmen David | Business Analyst
Cezar Coca | System Analyst
Florin Cardasim | Head of Analysis & Architecture
Thank you!
IN YOUR ZONE 28