Six Priorities Of Traditional Software Development
When designing and developing a traditional software system (i.e. one that will be installed on an end user’s system, rather than running in the cloud), there are several design goals for a successful project. These goals are:
- Availability of the system (Availability)
- The ability to backup and recover the system (Backup/Recovery)
- The ease of use of the system (Ease Of Use)
- The performance of the system (Performance)
- The amount of resources used by the system (Resources)
- The overall security of the system (Security)
As laudable as all of these goals are, they will compete and conflict with each other from time to time as to their relative prominence within the design. For example, while it is possible to create a system with “perfect” security, it would be so impossible to use that no client would ever accept it. Accordingly, here’s where I generally place these six design goals in the following order from most important to least important for traditional software development:
- Ease Of Use. If the system cannot be put to use easily and quickly by the end users, they will abandon it for another system (or collection of systems) that will accomplish their task while making their jobs easier.
- Availability. If the s ystem is not available for use, the end users will not be able to use it, no matter how successful the team has been with priority #1.
- Performance. If the system does not respond to the users’ requests in a reasonable amount of time, they will look for alternate means to accomplish their tasks.
- Security. If the system cannot maintain the confidentiality of the user’s data, they will not use it.
- Resources. If the system requires exorbitant resources, the customer will not buy it.
- Backup/Recovery. If the system is difficult to backup and/or recover, the customer will have to allocate additional resources to address that shortfall.
Obviously, these rules are more oriented for a consumer market where the end user controls the decision making process. For other environments, a corporation can mandate the entirety of the users must use a given product, regardless of whether or not the new product is easier to use than the existing system. Alternatively, other organizations may place much higher priority on design goals which I have placed lower on the list — for example, groups like the US DoD or an intelligence agency may place security as the most important design element and all other elements have to comport with the security restrictions. The individual needs of a customer’s project may cause the list to be reordered as appropriate to the business needs. For example, if developing software for mobile devices, the necessary constraint of the hardware environment will cause Resources to become a higher priority for the development effort.
Related posts (autogenerated):
