Java Development (Coding) Quality Process

This deck highlights key process areas in terms of development quality required for developers.

Transcript

1. Development Quality Process (Generic – Java based Projects)
2. 2 2 2 2 1. Quality Focus Area Architectural Quality Process Requirements Quality Process Project Planning & Estimation Quality Process Design Quality Process 2. Planning for Quality 3. Development Quality Metrics 4. Development Quality Process Coding Build & Release Branch & Merge Release Quality 5. Testing Quality Process 6. Quality Governance Goals & Objectives - Defined
3. 3 3 3 3 Goals & Objectives Align Sapient’s People & Development Process leading to: Drive towards efficient & consistent software development processes Drive improvement in application availability & scalability Increase quality of software releases Leverage tools to increase software engineering discipline Deliver on commitments with quality Establish consistent & uniform process across development projects Establish consistent quality metrics to measure development/delivery quality
4. 4 4 4 4 How each process is structured? Each process need to clearly define: Steps (bases on ETVX – Entry, Task, Verification, Exit model) Each process can be supported by: Templates (for artifacts) Guidelines (for following best practices) Checklist (for verification) Tools (for execution) Governance Periodic checkpoint based model to verify adherence Compare against benchmark established Measure using Quality Metrics identified
5. Planning for Quality Quality Plan
6. 6 6 6 6 Planning for Quality • Before we start into quality metrics & process, it is important to plan for quality along with project delivery plan. • This will ensure we have clearly agreed plan in place. • Quality Plan Life-cycle (Owner: Architect & PM) • Identify Quality Metrics to measure & benchmark for them • Identity Quality Processes to be followed (supported by checklists, guidelines, tools) • Create Quality Plan along with Project Deliver Plan • Execute Quality Plan (use checkpoints to measure) • Quality Governance (external reviews to assess state)
7. Development Quality Quality Metrics
8. 8 8 8 8 How to measure technical quality? Quality Focus Area & Metrics Tool Details Code Review Rules Compliance using Static Code Analyzers Metric: Violations (P1,P2,P3,P3) PMD (Code Analyzer) Finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, etc. It supports Java, JavaScript, XML, XSL FindBugs Look for potential bugs in Java code like identify NPE, using incorrect equality rather than equals, ignored return values IBM Software Analyzer (licensed) Find basic performance problems, and find possible API abuse. Code review can also include deeper forms of analysis, such as data flow, control flow, type state, and so forth. Checkstyle Checks compliance with coding rules
9. 9 9 9 9 How to measure technical quality? Quality Focus Area & Metrics Tool Details Unit Testing Status using manual/automated Code Coverage Tools Metric: Coverage Percentage (80%) & Success (90% & above) Junit Automated unit testing using junit to cover all flows in the code Jtest, Cobertura, Emma Tools based on Junit to analyze code coverage percentage Code Complexity & Dependency Metric: Cyclomatic Complexity • Sonar • Metrics Eclipse Plugin • Google CodePro AnalytiX is a quantitative measure of logical strength of the program. It directly measures the number of linearly independent paths through a program's source code.
10. 10 10 10 10 How to measure delivery quality? Quality Focus Area & Metrics Details DIR (Defect Injection Rate) Measure the rate at which defects are introduced in any new development / change. Measured as number of defects introduced per 100 dev days DSR-T (Defect Seepage Rate to Client Testing team) Measured as % of defects seeped to Client testing team – defects found in Client Test phase/Defects found in Sapient testing DSR-P (Defect Seepage Rate to Production) Defects found in production per 100 dev days Cost to Deliver Cost per story point
11. Development Quality Code Quality Process
12. 12 12 12 12 Code Quality Process Step 1 – Preparedness (Entry) • VM & Development Workspace Setup (install PMD, Checkstyle, FindBugs, Software Analyzer plugins) • FSD Walkthrough • Technical Design Walkthrough • Understand “Development SOD” & Framework-level Guidelines (for Exception Handling, Logging, Auditing, Security & Performance) including PMD Walkthrough • Identify Unit Test Cases Step 2 – Development (Task) • Coding Standards – Automatically gets verified by Checkstyle/PMD • Framework-level Guidelines (for Exception Handling, Logging, Auditing, Security & Performance) • Design Document (considering design rationales & constraints) compliance & update (if required) Step 3 - Verification with “Steps of Doneness” incl. • Unit Testing (prepare UTC beforehand) • Check Code Compliance (Checkstyle, PMD, FindBugs) Report • Code Sanity on the basis of QA Scenarios & execute minimum 25-30% • Code Review (by Track Lead) & Comments Incorporation Step 4 – Integration with Others • Web Analytics • Integration Testing (with real services if needed)
13. 13 13 13 13 Code Quality Process – (continued…) Step 5 – Mark your story complete (Exit Criteria) • Unit Test Results to SVN or Junit Compliance • Check-in SOD to SVN • Update Resultspace/JIRA Important Points • Check-in code on daily basis & ensure build is in working state • Attend daily stand-up morning meetings (on-time) • Update “Developer’s SOD” on regular basis • Discuss any design concerns with TL/Arch on regular basis • Escalate if you are gated in daily team meeting/scrum
14. 14 14 14 14 Code Quality – Supporting Tools & Artifacts Tools • Steps of Doneness (SOD) • Sonar or equivalent dashboard Checklist • Code Review Checklist • Security Checklist • Performance Checklist Guidelines • Planning Guidelines • Code Reviewer Guidelines • Architect’s Guidelines • RACI Matrix Templates • <<Code Template>> • <<Design Document Template>>
15. 15 15 15 15 Code Quality – Developer’s Checklist Have you followed all steps as per SOD? Have you updated SOD document? Have you got code review done with your TL/arch? Have you checked automated code compliance level? Have you informed PM/TL if you are blocked on any issue? Have you informed TL/Arch on any design gaps? Have you identified any performance bottlenecks and communicated the same?
16. 16 16 16 16 Code Quality – Guidelines on Planning Quality Activity Mandatory or Optional Owner Description | approach Who Conduc ts LOE to conduct Peer Review Mandatory Track Lead Basic quality control mechanism—a “finished” product is reviewed by a peer to find defects. Not a review to “gather input”. Reviewers capture defects and assess readiness Team members Preparation: 1-3 hours per participant (varies widely based on the artifacts) Duration: 1-8 hours per participant (varies widely based on the artifacts being reviewed) Iteration Progress Reviews/Weekl y Progress review Mandatory DU Owner Review of the overall project's progress to determine the risk level of the project and adoption to delivery methodology Review Owner Preparation: 30 mins Duration: 2-5 person-hours (dependent on project complexity) Defect Prevention/Les sons Learnt Meetings Optional Project Architect At project start learnings from previous projects must be referred to plan for preventive actions for defects in the projects. However, on an on going basis defects observed in each Iteration\Release would be analyzed. Based on the analysis; preventive action for the rest of Iterations\Releases would be identified and communicated to the team. This will ensure the prevention of similar defects in further Iteration/Release. Project Manager Preparation: None Duration: 2-3 hours (dependency on project ) Group Code Walkthrough Optional Architect At project level, online session with developer walking through their respective code & also functional aspects of their assigned stories. This brings ownership angle to developers. Developer
17. 17 17 17 17 Code Quality – Guidelines on Planning (contd…) Quality Activity Mandatory or Optional Owner Description | approach Who Conducts Quality Checkpoints Mandatory Programme /Release Arch Review progress against defined quality targets, compliance to processes and tools etc Programme Arch Design Reviews Mandatory Project Architect Review of High Level Designs of all the modules of the project Onsite Project Architect QA scenario brainstorming meetings Mandatory Track Lead Dev team to participate in brainstorming sessions to identify all permutations- combinations which should be included as QA test cases QA Track Lead Structured Dev Testing Mandatory Track Lead QA to maintain list of high priority test cases for each story Execution of high priority test cases by the dev team relevant to their story as part of dev testing before handing over the story in the build Developer Bug Find Day Mandatory PM/PA All team members to participate and do testing on all the projects for a particular release. All bugs found need to be assigned and fixed before O2 drop PA Merge Certification Mandatory Release Arch All merges to be certified by the merge certification team Merge Arch
18. 18 18 18 18 Code Quality – Guidelines for Code Reviewer Follow Code Review Checklist Step 1 - Code Compliance Review Check Code Compliance (Checkstyle, PMD, FindBugs) Check Unit Test Proofs & Check Functional Aspects (by running the code, is possible) Step 2 – Performance Review (identify top 3 areas) Check Number of services calls – Take DynaTrace help (if applicable) Optimize Client-side (using YSlow & FireBug) Identify Any Caching needs (for Coherence or others) Step 3 – Security Review (Identify top 3 areas) Check Security Report using Tool (if applicable) Check OWASP Vulnerabilities Verify PII information is not passed in URL or as parameters without encoding Identify Unauthenticated resources
19. 19 19 19 19 Code Quality – Tool - SOD Template Story Name Owner RAG Statu s Status Risk /Dependency VM Setup FS Walkthr ough TSD Walkth rough Identify UT Scenari os HIG Coding Standa rds Follow Develope r's Guideline s Doc Coding Unit Test Cases TSD Updat e Run IDE Plugins (Checkst yle, PMD) UTC Executi on Code Review Review Comme nts Incorpo ration FatWire Integrati on Web Analytic s HTML Integrati on Integr ation Testin g Checkin IDE Executio n Report (Checkst yle, PMD) Checkin UTC Report Checkin SOD << Story Name 1>> <<Dev 1>> 0% << Story Name 2>> <<Dev 2>> 0% Step 5 - Completion Step 1 - Preparedness Step 2 - Development Step 3 - Verification Step 4 – Integration
20. 20 20 20 20 Code Quality – Architect’s Checklist (Performance & Security) Performance Have you planned for Internal Performance testing (PSST team)? Have you identified performance critical areas in application & designed for concurrency etc. using performance tactics? Have you run performance testing before handing over application to client testing team? Have you executed client-side tool like Yslow/Firebug to measure Web Page end response time (Grade B must be t Security Have you planned for security testing using Sapient internal testing team? Have you run security scan using tool (like AppScan) on static code? Have you planned for OWASP security vulnerabilities?
21. 21 21 21 21 Code Quality – Performance Tactics Guidelines Client Tier Caching: Browser Cache Caching: Browser Initiated Pre-Fetch Parallel Execution: Domain Sharding Optimal Web Page Structure Edge Tier Caching: Content Delivery Network Caching: Pre-Fetch Network Optimization : Compression Caching: Content Delivery Network Caching: Pre-Fetch Network Optimization : Compression Web Application Tier Caching: Read Through Caching: Server Pre- Fetch Data/Resource Parallel Execution: Service Calls in Parallel Network Optimization: Content Pre- Compression Network Optimization: Minification Operational Data Store Asynchronous User Experience
22. 22 22 22 22 Code Quality – Logging Guidelines For Architects/TLs: Formualte Standardize logging output by application (follow client-specific Logging Standards, if any) Identify any Auditing needs across the application & configure centralized logging (SYSLOG or similar if required) Sample Log Pattern HOST PORT SCSC %c %d{ISO8601} %t %-5p %m%n For Developers: Ensure that Logging Levels are appropriate Always Put Stack Trace for Errors/Exceptions (using Log4J or others)
23. 23 23 23 23 Code Quality – Exceptions Handling Guidelines • Application Exceptions & System Exceptions need to be cleanly defined and adhered to exception handling strategy & exception hierarchy established for project • Exceptions should leverage print stack trace feature (should not be suppressed while wrapping them – critical for production support team) • Monitor exceptions in server logs & clean-up exceptions, if not environment related
24. Development Quality Build & Release Process
25. 25 25 25 25 Build & Release Process Step 1 – Preparedness (Entry Criteria) • Check development team readiness (FatWire & Java) • Communicate Build Plan to team members • Ensure “Code Freeze” before Build Process Step 2 – Build Task • Trigger Build & Prepare Code Packet for Deployment • Notify Infrastructure/Other Dependent Team (if needed) • Deploy Code Packet • Trigger CMS Publishing (if required) Step 3 – Verification • Check logs (FatWire, WebLogic) for any errors/issues • Smoke Test (by respective development team members) • CMS & Application Integration Testing (if any) Step 4 – Build Handover (Exit Criteria) • Communicate Build Success/Failure Report to Development/QA Team • Build Handover Report with Release Details (e.g. stories released, known issues, defect fixes)
26. Development Quality Release Quality
27. 27 27 27 27 Release Quality Process Step 1 – Preparedness (Entry Criteria) • Publish Release Quality Parameters • Prepare Release Sign-off Checklist Step 2 – Task • Periodic (weekly) Checkpoint on Quality Parameters such as: • Quality Readiness • Configuration Readiness • Merge Readiness • Periodic Checkpoint with Relevant Stakeholders (e.g. Server, DB) • Publish Release Plan Step 3 – Verification • Check logs (FatWire, WebLogic) for any errors/issues • Verify Configuration (for PROD) using Dry Run Step 4 – Sign-off (Exit Criteria) • Communicate Signed-off Release Plan
28. Development Quality Branch & Merge Process
29. 29 29 29 29 Branch & Merge Process Step 1 – Preparedness (Entry Criteria) • Check Branch & Trunk Status (as per maintained sheet for release plan) Step 2 – Creation • Get new branch created from trunk by Build & Release person • Follow Branch Naming Convention (see next slide) Step 3 – Verification • Smoke Test (by respective development team members) • Verify confirm created branch with Sapient arch/Tech Lead • Verify/confirm created branch with Arch/Tech Lead for development Step 4 – Merge • Get Merge done with the help of Build & Release person (always follow automatic merge) • Check basic principles related to Merge (next slide) • Get Merge Conflicts Verified with Tech Lead/Arch
30. 30 30 30 30 Branch & Merge – Sample Template
31. Quality Governance Benchmark & Maturity Model
32. 32 32 32 32 Governance - Guidelines Each Quality Checkpoint should have clearly marked Exit Criteria No P1 & P2 in terms of any violations Code Coverage (Unit Testing) > 90% Development SOD = 100% compliance Code Review Checklist > 90% compliance Each Project should have Objectively tracked Scorecard (baselined): Aligned with client’s objectives in terms of solution quality Assessed based not only on technical debt but also from holistic perspective (defects, testing, delivery SLAs, developer’s awareness of quality process)
33. 33 33 33 33 Governance – Tool - Dashboard A weekly checkpoint by architects help to find health of the project from quality perspective (sample dashboard below) Overall Status Overall Status Overall Status Code Review Unit Testing N/A Total Common Web Billing Web Total# % Executed Status SOD Compliance FatWire HTML Total FindBugs AppScan Total# % Executed Status Java 0 0 0 Total# % Executed Status Comments % 20.30% Overall Status N/A Duplication % N/A Total Defects N/A Cyclomatic Complexity 1.6 Avg. LOC per Method 8 P1 P2 P3 P4 Total LOC 15,271 0 0 0 0 DIR DSR-HIG QA DSR-Prod DTP Delivery SLA Metrics Milestones Status Development Quality Dashboard Process Adherence Rules Compliance Status Testing Status PMD Functional Testing Defects (Not Closed) Code Metrics Others End-to-End Testing Sapient QA Drop HIG QA Drop PROD Readiness Defects Status
34. © 2013 SAPIENT CORPORATION | CONFIDENTIAL Thank You!! Quality is all about mindset
35. Appendix Supplements
36. 36 36 36 36 Quality Plan Across Project Timelines = Success
37. 37 37 37 37 Tool like Sonar Dashboard = Transparency
38. Hartford Tools Context 38
39. Java – Static Code Analysis Tools Top 5 Open Source Tools SonarQube – Complete metrics using multiple behind the scenes analysis tools Google CodeSearchDiggity - Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. Identifies SQL Injection, XSS PMD, FindBugs, Checkstyle OWASP SWAAT Project - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP Squale – A platform to manage software quality (also available for other languages, using commercial analysis tools though). Top 5 Commercial Tools Google CodeSearchDiggity - Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. Identifies SQL Injection, XSS IBM Software Analyzer IBM AppScan
40. References https://www.owasp.org/index.php/Source_Code_Analysis_Tools http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis http://www.ibm.com/developerworks/rational/library/08/0429_gutz1/