This is the third post in a series of posts treating software quality attributes. Unless your only concern is the scalability of your solution I do recommend that you start by reading the first post of this series.
The scalability quality attribute is something we are only concerned with for server based systems. Scalability is the ability to handle more traffic, more concurrent users, more transactions per unit of time and is therefore related to performance. It is important for your business because if the things we are hoping for happens and your business attracts a lot of customers that produces a huge amount of business transactions you would want your system to be able to handle that increased load. Ideally you would like to be able to handle the new load without having to make a big effort. If you need to redesign the system to be able to handle the increased workload you will lose valuable time (not be able to do all the business you otherwise would have the opportunity to do) and the work of improving the software will itself cost money.
This is the second post in a series of posts treating software quality attributes. Unless your only concern is the performance of your software I do recommend that you start by reading the first post of this series.
The performance of a software is quite simply how fast the software does it’s job. It is commonly measured in response time, that is how long time passes between the initiation of a command until the command has been completed. Performance is often measured in seconds or milliseconds in combination with workload, that is how many concurrent requests the system is handeling. That is the simple part of thinking about performance.
This is the first post in a series of blog posts concerning software quality. In this post I will establish some basic terminology, discuss the basics of software quality and provide links to the other posts in this series.
What is software quality?
In these posts I will use the term software quality to refer to how well the non-functional requirements of a software system is implemented. Functional requirements are clearly expressed business needs that define what a system is supposed to do, e.g. the system should be able to calculate the VAT of an invoice. Non-functional requirements instead deals with how a system implements it’s functionality, e.g. the system should be build in a way that makes it easy to test and verify.
The most difficult thing in the software industry Read more…
According to some sales persons you should outsource (or even offshore) as much work as possible. Their rant usually goes something like this:
By offshoring you would be able to save a ton of money by making use of the workforce of low wage countries whose inhabitants are both intelligent and educated – and motivated ta boot! Nobody can ever get fired for doing that!
Well, this post presents a somewhat different attitude towards outsourcing. There are in fact things that you should never ever consider outsourcing…
Today I was in need of arguments to support my personal opinon, so it was kind of an ordinary day. As always I turned to Google. After some fruitless clicking around I finally found something useful over at stackoverflow.
Jack Marchetti neatly formulated his question as “When to rewrite a code base from scratch?” and some of the answers were pretty good.
Massive scalability is a key component of elasticity that in turn is the key advantage of cloud computing. Handling massive amounts of data is far from easy whether you use cloud computing or not. To get the real benefits of the cloud there are a couple of limiting factors that needs to be considered – at least that is the way the official dogma goes.
Agile is gaining more and more popularity compared to plan-driven software development approaches. There is a strong community push in favor of agile, and truth be said agile has quite a few advantages. However, a couple of questions needs to be asked. Should all projects use agile methods? To what degree should a particular project be agile?