Prem's views on life, .net and software development (everything contained in one strongly typed weblog).
Monday, March 30, 2009
Improving Process in Software Company
It has been busy period for me trying to setup process in my current company. For those of you interested in knowing things that I have standardized
-> Usage of Cruisecontrol.Net for Continuous Integration
Initially i found configuring this tool really difficult but once I completed setting up couple of projects using it, I am very comfortable with it nowadays. I might not be a continuous integration guru but certainly I could fix any cc.net issue without hiring an external consultant.
We are currently using CruiseControl.Net for migration across to our QA environments as well. This has made the deployment of code a breeze.
-> NDepend for Static analysis
Ndepend is certainly one of the best tools you could purchase to have better control of the quality of code your team is putting out. The parameters I am currently auditing include number of lines in method, cyclometric complexity and comment percentage.
-> Schemaspy for generating automatic Entity Relationship Diagrams
This is a great tool for creating ER diagrams from your database automatically and provides web based output that your team could use as a reference.
I always prefer to automate as much as possible and monitor it periodically to ensure things work as smooth as possible. You would do yourself a great favour by setting up Continuous Integration, One click Code migration and report generation using a tool like nDepend on code quality.
Having worked on improving process in the current company, I want to evaluate where we stand now in "Joel Test"
1. Do you use source control? Yes, we use Borland StarTeam
2. Can you make a build in one step? Yes
3. Do you make daily builds? Yes, we use CruiseControl.Net
4. Do you have a bug database? No
5. Do you fix bugs before writing new code? Yes
6. Do you have an up-to-date schedule? No
7. Do you have a spec? No
8. Do programmers have quiet working conditions? Yes
9. Do you use the best tools money can buy? Yes
10. Do you have testers? Yes
11. Do new candidates write code during their interview? No
12. Do you do hallway usability testing? No
Current score for my team is 7/12 on Joel Test, not good, but I certainly think we have come a long way from where we were... Hope to see this improve...
Sunday, February 04, 2007
Role of Business Analyst, Developer and QA in a project
- Business Analyst
Typically the first person to get to know the change in business requirement, gather them and document it completely and they will be the point of contact of any questions/clarifications in the requirements document. - Developer
This person will take the business requirement and create a high level technical design document and will start coding using his favourite tool (.net) :). They should be responsible for ensuring that all the aspects of the service like scalability/reliability/extensibility of the code has been taken care of. - QA
QA is a person who should create the test cases based on "Requirements Document" and should never interact with the developer for any questions/clarifications. They are in charge of making sure the final code that gets released is error free (typically through black box testing).
Alrite... I hope all of us are in the same page with regards to the functionality of these resources. Now let's take the scenario after this code has been rolled into production. I am sure any code that gets released will have bugs in them who takes the responsibility for the bugs. This is my idea on who should be responsible for the bug.
- Functionality missing
Has this been documented in Business Requirements ? If so, where there test cases created by QA to cover this ? In case the functionality has not been documented the blame should go to the business analyst and in case there were no test case the blame should go to the QA. - Scalability/Reliability Issue
The Developer should be solely responsible for such issues. These things are difficult to test by QA and the design should have addressed these issues. - Functionality not working as per requirements document
When a clearly documented functionality is not working, the blame should go entirely on the QA for not testing it appropriately.
But I don't see this process happening in many places, the developer is the first and only person to be caught for any bugs being reported and he is instructed to fix those issues within the next business day. Being a developer and hearing the same from friends working in startup companies, I am tired of working in such environment. I hope this trend will change in future and the appropriate resources will be pointed for their mistakes.