Let me preface this with saying I am not a Business Intelligence (BI) developer. I’m a .NET developer, and I have only a vague notion of what BI is, and encompasses.
I’ve been an evangelist for a secure development lifecycle in our company, and recently convinced the rest of the development team that we should be doing peer reviews including…
- Requirements Reviews
- Code Reviews
- Architecture/design reviews
- Documentation Reviews
The .NET team does code reviews and we look for various things – general overview:
- Maintainability (clear design, adequately documented, etc.)
- Code clarity (standard .NET coding/naming guidelines)
- Security (scanning for failures to sanitize input, prevent SQL injection, etc)
- Functionality (does it do what it’s supposed to)
- Usability
- Performance
At any rate, our Business Intelligence developers don’t really do the same type of coding/development that we do for websites, windows apps, etc. Our templates/checklists don’t really apply to them. Since I’ve been the one trying to evangelize and get everyone do start doing peer reviews, they asked me for advice on what types of things they should be looking for.
I could probably guide them and help them to develop their own checklists by asking questions about what can go wrong, what is important to them, etc., but I thought I’d ask and see if anyone is aware of established guidelines for doing “code reviews” for BI developers.
I’ll also take, from BI people “What would you look for in evaluating another BI developer’s work?”.
3
I could comment on the ETL side of the BI application development life cycle. The parameters depend on the tool/Language being used, but could largely relate to your above listed ones.
- Maintainability -Adhereence to the defined design could be evaluated
-
Code clarity –
Naming conventions are there in BI ETL development too for different objects used in the code.
*Security –
Not applicable at a code review point of view in BI applications. Security focus is more in the design phase (which users need to see which sub-section of the data) and inthe administration side (reporting tool user log-in configuration) etc. -
Functionality checks-
I think this comes under the unit testing phase or other testing phases – less to do here at the code review time, except for checking if there are unit test plans and test results available as part of the review. -
Usability – NA
- Performance –
Could be evaluated if requirements demand certain measures ( defined time to process the data) and if general guidelines for tuning is followed (simplest example – defining join rank for tables)
Additional: We usually check for impact analysis on existing code and and extent of component re-use . (We work in a multi-member team where multiple BI applications are