Software house

A software house is a company whose primary products are software, i.e. a company in the software industry.

Types

There are a number of different types of software houses:

All of these may be categorized in one or many of the following:[1]

Common roles in a software house

Organizing a software house is very specialized type of management skill, where experienced persons can turn the organizational problem into a unique benefit. For example, having sub-teams spread in different time zones may allow a 24-hour company working day, if the teams, systems and procedures are well established. A good example is the test team in time zone 8 hours ahead or behind the development team, who fix software bugs found by the testers.

A professional software house normally consists of at least three dedicated sub-teams :

In bigger software houses, greater specialization is employed, and quite often there are also:

Structure

The manager of a software house is usually called the Head Of Development (HOD),[2] and reports to the stakeholders. He or she leads the sub-teams directly or via the managers/leaders depending on the size of the organization. Usually teams of up to 10 person are the most operational. In bigger organizations, there are in general two models of the hierarchy:

Typical structure of a software house

All the teams are fully independent and they work separately on the different projects. The structure is quite simple and all the employees reports to one person, what make the situation quite clear however it is not a good solution in terms of knowledge exchange and optimal usage of human resources.

Matrix structure

In this model there are dedicated managers/leaders for each main specialization, "renting" their people for particular projects led by product/project managers, who formally or informally buy the people and pay for their time. This leads to each private employee having two bosses – the product/project manager and the specialized "resource" manager. On one hand it optimizes the usage of human resources, on the other hand it may give rise to conflicts about which one manager has priority in the structure.

There are also a number of variants of these structures, and a number of organizations have this structure spread and split within various departments and units.

Methodologies

Software house may use a number of various methodologies to produce the code. These can include:

There are also some methodologies which combine both, such as the spiral model, Rational Unified Process (RUP)[7] or MSF.[8]

Product life cycle

Regardless of the methodology used, the product life cycle always consists of at least three stages:

Each stage ideally takes 30% of the total time, with the remaining 10% in reserve.

The UML sequence diagram of interaction between these groups may look like:

The general interaction between the main three groups

At each stage a different group plays a key role, however each type of role must be involved throughout the whole development process:

Systems and procedures

Well-run software houses possess various systems and procedures implemented and working internally across all the sub-teams. These include:

Business Analysts

Programmers

Testers

Project/Product managers

There are also Application Lifecycle Management (ALM), which embed some of these functionalities in one package and are used across the groups. They are delivered from various vendors like Borland, ECM or Compuware.

Efficiency audits

Well-established software houses typically have some way of measuring their own efficiency. This is usually done by defining the set of key performance indicators (KPI), such as

A number of organizations are focused on reaching the optimum level of the Capability Maturity Model (CMM), where "optimum" does not necessarily mean the highest. There are also other systems such as Carnegie-Mellon University's SEMA, or particular ISO standards. Small software houses will sometimes use less formalized approaches, such as the Joel Test : 12 steps to better code. Each organization works out its own style, which lies somewhere between total technocracy (where all is defined by numbers) and total anarchy (where there are no numbers at all). Whichever way the organization goes, they consider the pyramid describing the cost and risk of introducing change to already-begun development processes:

pyramid showing risk and time cost of change

See also

References

  1. ↑ Software Process: Principles, Methodology, and Technology Author: Jean Claude Derniame, Badara Ali Kaba, David Wastell p.166
  2. ↑ Greenlit: Developing Factual/Reality TV Ideas from Concept to Pitch p.12
  3. ↑ Managing successful projects with PRINCE2
  4. ↑ A User's Manual to the PMBOK Guide
  5. ↑ Planning extreme programming
  6. ↑ Agile Project Management with Scrum
  7. ↑ The rational unified process made easy: a practitioner's guide to the RUP
  8. ↑ Microsoft Solutions Framework (MSF): A Pocket Guide
This article is issued from Wikipedia - version of the 12/2/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.