Showing posts with label Processes. Show all posts
Showing posts with label Processes. Show all posts

Monday, October 21, 2013

When is Software Development agile?


The following aspects characterise agile software development :
  • Parts of a system are developed at different times. The system is always being enhanced by already accomplished parts. This is called incremental development.
  • Defect analyses and measurements are used as learning opportunity by team members and for improvements of the organization.
  • All involved parties / persons work close together and cooperate directly, e.g. by a high degree of teamwork and a continuous cooperation of the customer or product owner. 
Actually models for agile development exist since the 90s. They follow processes and, due to the mostly short iteration cycles (sprints), they heavily rely on measurements of progress, code quality, test coverage, etc. and a fast feedback of it to the developers.

Monday, October 7, 2013

Software Development with Methods of the industrial Production

Methods of industrial production may be a response to 
  • increasing complexity of requirements,
  • shorter development cycles and
  • growing cost pressure.
This has nothing to do with the series production of the same product. It more concerns the following aspects:
  • Standardization of system and application architecture 
  • Reusability of components
  • Automation  of development and quality assurance processes
  • Measurability of productivity and quality
While today a lot of standards, concepts for reusability and tools for automation are available and established in software development, many companies neglect measurements or use estimations instead. However regular and accurate measurements of productivity and quality are an important basis for the reliable determination of the effort for upcoming development projects (see also Measuring Productivity in Software Development).

Friday, June 21, 2013

The Importance of Processes in commercial Software Development



Processes are part of the constructive quality assurance. Their major benefit is process reliability through defined working procedures. I state that commercial software development cannot be successful without processes.

Even agile methodologies as Scrum follow own processes. They are also based on a schedule planning which is characterized by shorter release cycles (sprints) compared to “heavy weighted” process models. Vice versa most of the (non-agile) process models are also able to deal with short-term changes of the project goals and requirements.

The world of software development is not polarized to agile methodologies versus derivatives of the classical waterfall model. Actually the different models differ primarily by the explicitness of their process definitions, by the flexibility how processes and methods can be tailored to different conditions and by the importance of process compliance towards human interaction or required changes.

My experience is that the definition of quality gates is more important than process compliance. Quality gates assure the quality of an input or output artifact of a process, iteration or project stage. They are defined by checks (test methods or threshold values for metrics) and according success criteria, which a test object (artifact) must fulfill to pass the gate, i.e. that the artifact can be used respectively handed-over to the next development step. An example is the check of requirements for conformity with the project goals, feasibility, completeness, consistency, etc. after the business analysis. The meaningfulness of such a quality gate is not a question of light or heavy weighted or agile process models.

Monday, May 13, 2013

Measuring the Productivity of IT Services



From an enterprise perspective the productivity of IT services is determined by the interplay of the following factors:

  • Efficiency: Regards the economic efficiency concerning a cost/benefit ratio. When looking at a software development process the benefit corresponds with the output of created software and the costs are the development effort (input).
  • Capacity: Depends on the provider’s flexibility in addressing changes in demand and concurrently utilise the capacity of his resources (employees) optimally.
  • Effectiveness: The ratio between an achieved and the targeted result. Depends on external factors as the provider’s market position and image, the opinion on the service quality by the customer, the quality of customer interactions, etc.
According to this model productivity measurement requires the consideration of more areas than only the delivery: marketing, sales, staff planning, etc. The challenge is to find feasible metrics e.g. for rating the opinion of the service quality by the customer.

Factors influencing the productivity of IT services
For controlling of the service productivity it is important to understand how these factors are influencing each other. E.g. standardisation can improve the efficiency, but it can be perceived as negative by customers. Furthermore, the weights must be identified, i.e. how strong each of these factors affects the total productivity. This depends on the type of services, customers, industries, the business and payment model of the provider, the type of contracts, market position, etc. For more information I recommend the PAC Research Report for the project “ProdIT” supported by the German Federal Ministry of Education and Research (http://www.berlecon.de/studien/downloads/121212_ProdIT_Master_Final.pdf).

For measuring the productivity of software development processes usually it is sufficient to focus on the efficiency (see: Measuring Productivity in Software Development). This simplification is possible if influences by the disposition and utilization of employees are negligible and if the process finishes with a defined quality. Otherwise, if the productivity measurement is being used for supporting decisions beyond the delivery, e.g. regarding the market position of a standard software or the cooperation with a (major) customer, external factors as achieving the customer’s objectives, the flexible consideration of new or changed requirements, the quality and reliability of customer provisions, transparency of intermediate results, etc. must be considered.