Google Search

Sunday, July 26, 2009

Writing Quality Software – Quality Assurance

One must not underestimate the necessity of the QA team.
Quality Assurance (QA), the guys that test the software designed by the engineers and written by the developers. Their mission is to make sure that the software does what it needs to do, and do it well. They are also the first users of the software so they have the best review and criticism about the visual design and usability.
A developer needs to learn to listen to the QA team notes. The QA team, on the other hand, must learn how to note.
In order to really understand this, lets check things more thoroughly:
First of all, the role of the QA team versus the role of the development team in terms of software operability:
No QA team – Bad software; No development team – No software.
That said, we now need understand that the two teams must work together in order to create good software.

Friday, July 10, 2009

Writing Quality Software - Architecture

Designing the architecture of software is very important phase in the software lifecycle.

Rules of thumb:

A good piece of software would follow several rules of thumb:
  • Reusability – The piece of software should be as reusable as possible (unless it is applicative), and reuse other components as much as possible.
  • Extensibility – The piece of software should be as extensible as possible – i.e. have enough places which other developers (or the original developer in a later time) can use to add more functionality.
  • Functionality – The piece of software should make the life of its user easier. The 80-20 rule would fit here (at least 80% of the time…)
  • Order – The piece of software should be organized for easy finding of each piece of code, and easy thinking of a good place for a new piece of code.
  • Traceability – The piece of software should log its actions in details, preferably in different levels of detail. Usage of extensible logging libraries (such as log4net) are welcome.
  • Security – The piece of software should not reveal security leaks, that would allow malicious code to abuse (I am talking about things like code injection, unauthorized privileges modification, system denial of service, etc.)
  • Portability – The piece of software should be as portable as possible. Not necessarily between operating systems, but generally between computers. Zero installation (aka -xcopy deployment) is always welcome.