I observed a big difference how small and big companies are making software. Until recently I've only seen how small companies are doing it.
If you're delivering a customized software solution, you prepare it for one customer. That customer - in a lucky situation - has a concrete vision why the need the software and how it should work, based on their existing business processes. The software creation process starts with business analysis. The software company tries to understand what the desired business processes should be and where their software would play any role. The outcome of the analysis than formalized in a document. Based on that document software architect(s) come up with the solution architecture and detailed functional and non functional specifications. The client signs off these documents in an agreement that the software they are going to receive will behave exactly as these documents state. And in most of the cases they want to know the details because their life literally is depending on it. As a result these documents are fine graded and serve a good basis to the development team to start the work. With agile methodology becoming widespread the document development is sliced up to match up the sprints (or however you call them), but the big vision of things is laid down upfront.
As a matter of fact an Agile project require you to define it's scope just like any project...
And this is - I personally think - the main purpose behind while customized software solutions tend to deliver higher quality.
On the other hand big software companies are creating software solutions used by many people and they serve to solve common problems. Big software companies have more resources, and they don't have a client that can hold them responsible really. As a result people honestly think things like agile methodologies mean that there's no process in your development, and there should be no documentation created. And such nonsense. As a result to achieve the same or at least similar quality more cycles are needed and the software creation is more expensive and you can only hope that the quality matches the quality of a custom solution.
And when you point out things like the definition of software means the software code _and_ the documentation, and creating specifications does not necessary mean that you want to do traditional waterfall model based software development, people call you process oriented.
And you end up with the strong belief that you could do anybody's job way better.
Well, it's just the brand new quality engineer growing in me speaking maybe, but there must be a reason while all the quality management standards like ISO, CMM etc. are defining, focusing and auditing processes creating products and not products themselves.
But call me whatever you want to...
No comments:
Post a Comment