SDQ with some of their solutions

Quality Problems

A List of the Usual Problems in a SW Project [Note 1]

  1. Project schedule slips [Note 2];
  2. Too many bugs and no time to correct them until the release;
  3. The customer (or management) asked for a change and there is no time to implement the change and stay on the schedule;
  4. Project's money budget is reduced with a certain percentage with little or no reduction of features or qualities;
  5. Product's release is changed for an earlier date with little if no changes in expected features;
  6. A chosen technology for the project performs worse than expected and it has to be changed during low level design/implementation activity.

Sketchy Analysis of These Usual Problems

  1. Project schedule slips

    Possible causes:

    1. Poor planning – Overly optimistic planning;
      1. Developers not trained to estimate their own work schedules.
      2. (Middle) management reported an exaggeratedly optimistic schedule to be sure to get the project accepted/financed.
    2. Student syndrome – means to delay the start of a task, eventually till delivery is imminent, due to having (initially) more than enough time to accomplish it. (It is also a corollary to Parkinson's law: Work expands to fill the time allowed).
    3. Poor time management
      1. Little focus on the task at hand
        1. Organization poor focus – e.g. lots of meetings, a lot of organizational overhead time, poor communication inside the organization (people focus a lot on understanding each other), etc.
        2. Developers' poor focus – poor personal time management training, poor professional training for the task at hand
      2. Multitasking – making a developer to execute few tasks in parallel will actually lose time not gain time.
    4. Some unexpected event make schedules slip considerably (e.g. The “star” programmer left the team) – meaning poor risk management.
    5. Project began with poorly defined requirements, and after correcting requirements no necessary rescheduling was made (or permitted).

  2. Too many bugs (poor product quality) and no time to correct them until the release. This problem's causes are too many and too vast to analyze here, but mainly this is caused by a improperly designed development process or poorly followed development and/or management procedures;

  3. The customer (or management) asked for a change without rescheduling, and there is no time to implement the change and stay on the track – it is caused by poor customer relationship management (or by poor communication with the manager who took the decision);

  4. Project's money budget is reduced with a certain percentage with little or no reduction of features or qualities – it is caused by poor customer relationship management (or by poor communication with the manager who took the decision) – same cause as in the previous paragraph - §3 ;

  5. Product's release is changed for an earlier date with little if no changes in expected features – it is caused by poor customer relationship management (or by poor communication with the manager who took the decision) – same as in §3;

  6. A chosen technology for the project performs worse than expected and it has to be changed during low level design/implementation activity.
  7. It may be caused by:

    1. Poor understanding of the requirements (or faulty/incomplete requirements);
    2. Poor design decisions, caused by
      1. The choice of incorrect design criteria or of incorrect priorities of the design criteria. For example choosing of a technology because it is better known by the developers over the criteria of fitness of the technology with the architecture of the product.
      2. Insufficient experience of the designer/architect with the product environment or with the technologies to be used.

Notes:

  1. By no means this list is the complete inventory of all the problems that may arise in a SW development project, but I think that the listed problems are the most important and frequent ones.
  2. Delivery time is a quality characteristic of a product in our quality model - and in the real world too.

Quality Problems

Consequences of the quality problems

There are three possible major effects of any serious SW product quality problem:

  1. SW development project fails (is canceled) so there is no product at the end.
  2. The product makes it to its users but they do not use it, or
  3. The users are using the product and are paying the consequences of the poor quality: lost time and poor productivity.

And the final outcome of any poor quality product is that a competitive product of better quality replaces it.

[QUALITY PROBLEMS'SOLUTION]

Quality Principles [Note 3]

  1. Quality is a relative and human concept. It is neither a law of nature, nor a divine datum.
  2. Quality applies to products (objects) and to processes (activities), and it implies a supplier and a receiver (or user, customer, beneficiary). Both supplier and receiver may be single individuals or collectives, organizations, groups of people.
  3. Quality concept, besides being relative it is also a generic concept. In order to define and to measure it, for a specific product or process, we will need to define some specific quality attributes. (As reliability, usability, conformance to needs, harmlessness, users' satisfaction and/or, more specific to a (software) product: maintainability, portability, testability, upgradeability, etc.)
  4. Quality attributes are build into a product or into a process by changes the supplier (or its agents) makes in the environment. But not every change generates or improves quality [Note 4].
  5. Quality improvement is perceived as progress by the receiver of quality. The reciprocal is also true: degradation in quality is perceived as a regressive event.

Quality vs. Delivery Time (or Development Cost)

One of the most spread clichés of the SW development process management is that the quality of a product comes at the price of the time spend to develop this quality, or at the price of development costs, or both. This is a misconception for our model, because we consider delivery time and the price of the SW (related to the development costs) as quality attributes of a SW product. And, as quality attributes they are taken into account explicitly at the time of requirements specification and at the time of SW design – at the same level with other quality attributes.

And how exactly this works? Very simple to explain it. Of course is not always very simple to implement it, meaning not every requirement (including delivery time requirements, or price and development costs requirements) is always feasible. But this is true for every quality attribute – they are not all of them feasible for every project every time. And what are we doing in this case if we want the product developed and we know that we do not have all the needed resources? There are few solutions to this problem:

  1. We look at other design (technical) solution – other processor/computer, other operating system, or other language, other development environment, architectural approach, design model, etc.
  2. We consider other management methods or solutions: project management methods, staffing solutions, time management methods (including personal time management), etc.
  3. We compromise. For example: if we need a reliability of 99.99% (uptime) for our system we will need to implement some intelligent redundancy scheme into it, so we may need some extra time to make requirements, design, implement and test this redundancy scheme. We may also need to train some of our people to do it, or to take an external consultant. All this may overflow our authorized money and time budgets. Or, as an alternative, we may decide that 99% uptime is enough (in agreement with our users, or other relevant stakeholders) and make the system without a redundancy scheme.

Our solutions 1 and 3 have in fact a name. They are called: quality by design method. The only thing I am adding to it, is that I am introducing the delivery time and development cost as quality attributes explicitly.

Notes:

  1. I am using this concept as in the next principles:
    1. Primal cause, origin, source.
    2. Primary law on which other laws are based, fundamental law.
    3. Knowledge, doctrine, precept, tenet, elementary rule, or law of a discipline, art, or thing.
    4. Proposition accepted as a base for a rationale.
    5. Constituting element of a thing (object, idea, article, fact): e.g. active principle.
  2. “If it's not broke, don't fix it” is true if it means: “Don't change if it's not necessary” (for the un-necessary improvement of quality). Meaning – Don't make changes only for the sake of the changes.

careers | contact | dallya