Agile methods in software development

A Note to The Reader

This section relates to how we have been able to streamline software development work. The requirements that need to be taken into account when developing software to be used in fighter aircraft, where the software is classified as safety critical, are described here.

By using agile working procedures, it is possible to increase performance, quality and delivery precision considerably. This is exemplified in this text in the form of a development project that was conducted in a traditional manner and encountered various difficult problems. Switching to agile methods led to an outstanding improvement.

Development went from 0% delivery precision and quality to 100%! Staffing was largely the same, but the working procedures and attitude to the work had been changed.

Background

Developing software in complex built-in real-time environments with flight safety and quality requirements is no trivial matter. This text describes the considerations that must be dealt with when developing software for advanced systems. Some examples of affected areas are:

  • Systems that form part of the aircraft.
  • Systems for tests.
  • Rigs and maintenance equipment required when producing a flying system.
  • Testing systems.
  • Technical loop with analysis of an aircraft’s technical functionality and maintenance handling.
  • The tactical loop, i.e. planning, execution and analysis of tasks.
  • Operational analysis and training.
  • Technical pilot training.

Recommended reading

The author recommends the following texts that relate to this story: In chapter Creating value for customers under the heading Development of Technology Demonstrators in chapter Having a low life cycle cost under the heading Systems Engineering and in chapter Keeping unique development skills under the heading System integration– unique expertise.

This text concerns the highlighted areas of A Journey of Change in the Aircraft Industry

Summary

Software development is part of the development of an aircraft system. This means that it is part of handling an information flow.

This information flow begins with a customer order, which is based on requirements and expectations and ends with a delivered product.

Handling an information flow in order to develop software means dividing up the information. Using methodology and tools, it is possible to handle the traceability of customers’ product delivery requirements. Developing software therefore means handling a lot of information.

Software development is not a stand-alone activity but rather a part of product development, which means that coordination with other participating processes is required. This coordination requires support between methodology and tools. Information has to be able to flow between the various processes.

In order to handle the problems involved in conducting software development projects, it has become common practice to use agile methods. Examples of such methods are scrum, pair programming and Kanban.

The purpose of these methods is to adapt the software successively to requirements that are not always clear from the start, such as when a customer does not initially know exactly what a product will look like when it is finished.

Description of the contents

  • When developing software, difficulties are not generally caused by problems with handling the function itself.
  • What normally takes a lot of time is handling processes, information flows, methodologies, technologies and development environments.
  • It is not unusual for the work of handling processes, information flows, methodologies, technologies and development environments to be what causes the problems that lead to delays and increased costs.
  • Continuous integration means that the software that is developed is checked via build stages, tested and made available to everyone else that needs it.
  • There is an important difference between developing code for a built-in flying system that is required to handle flight-safety-critical software and handing the development of, for example, a system for dealing with tactical loops or a test system.

Software in Real-Time Environments

Developing software in complex built-in real-time environments with flight safety and quality requirements is no trivial matter. This text describes the considerations that must be dealt with when developing software for advanced systems. Some examples of affected areas are:

  • Systems that form part of the aircraft.
  • Systems for tests.
  • Rigs and maintenance equipment required when producing a flying system.
  • Testing systems.
  • Technical loop with analysis of an aircraft’s technical functionality and maintenance handling.
  • The tactical loop, i.e. planning, execution and analysis of tasks.
  • Operational analysis and training.
  • Technical pilot training.

The focus in software development must be on dealing with customer expectations and developing functionality. The software code itself is not the central factor; the code is a result of the development work.

When developing software, difficulties are not generally caused by problems with handling the function itself. What normally takes a lot of time is handling processes, information flows, methodologies, technologies and development environments. It is not unusual for these areas to be the ones that create the problems that lead to delays, increased costs and a failure to meet customer expectations.

The development process for software

During the 2000s, Saab strove to coordinate the processes of the entire company. This particularly applies to the software development process. This is a part of the company’s development process that interfaces with other processes.

Even if the interfaces have been identified, it is not always understood that the flow of information between them needs to be handled in a development project. It is sometimes necessary to investigate how the information flow needs to be changed.

Software development is not a stand-alone activity, but a part of product development. Software development involves coordination with the other participating processes. This coordination requires support through methodology and tools. Information has to be able to flow between the various processes.

The figure below shows the development process illustrated in the form of a development V. Every step described in this development V includes several processes – not just the development process for software, but also processes for developing systems, hardware, verification and validation.

In this development V for the development process, it is possible in principle to follow the route from system requirements, via requirement breakdown, design, test and delivery. This can be seen in the figure by reading from the top left-hand corner down to the bottom of the V and then up again to the top right-hand corner.

 

 

Development of flight-safety-critical software

A development process must promote orderliness, i.e. ensure that it deals with customer requirements and expectations. It must result in a product that satisfies the customer. This is not unique to the aircraft industry; it applies to all companies that develop software.

What makes it more complicated for an aircraft business like Saab is that the process that ensures quality and efficiency also needs to be supplemented with regulations for handling the development of flight-safety-critical software.

An example of flight-safety-critical software is software for an aircraft’s control system. To make it admissible for use, the functions must be traceable, from requirements via implementation and testing through to the product. It is also a requirement that tools, such as compilers, are approved for use.

The rules that need to be complied with for development are described in the regulatory document RTCA/DO 178C, which relates to software-based flight systems. In this document, software is divided into several different classes from A to E, where class A represents the highest safety level.

Classes A to C are primarily considered to be critical to flight safety, while classes D and E relate to software that does not affect flight safety.

These rules describe different types of requirement as follows:

  • How software requirements should be handled in order to be traceable in the developed software.
  • How software development tools need to be qualified.
  • How software should be reviewed and tested.
  • How software should be handled upon and after delivery in order to ensure that it is as secure as possible, so that it can be used in operation in an aircraft.

Even if the flight-safety-critical software only forms a small part of all the software that is developed for the various systems, this means that, if it is not clear what applies to different pieces of software, this creates conditions for increased complexity in development.

Information flow

Software development is therefore only part of the development of an aircraft system. This means that it is part of handling an information flow.

This information flow begins with a customer order, which is based on requirements and expectations and ends with a delivered product.

For software, it is necessary to have precise control of what is delivered in the form of tested code.

Handling an information flow in order to develop software means dividing up the information. Using methodology and tools, it is possible to handle the traceability of customers’ product delivery requirements. There are great demands with regard to information handling for ensuring safety-critical functionality. There are also great demands for ensuring the handling of classified information and information that needs to be handled with regard to export restrictions.

Developing software therefore means handling a lot of information. At the start of a development project, information is provided to the effect that the project has to be delivered at a desired time. The requests are often requirements, where agreed acceptance criteria are applied and must be handled and approved upon delivery.

This means that it is very important from the start to have a well Developed methodology and the necessary tools to support the design of a product.

An example of information handling in a value stream is the development of the training system for pilots, Mission Training System. This is a system where a pilot can train to fly various versions of Gripen. The training system includes various systems, in the form of sensors, weaponry, communications, etc., which make up the various versions of Gripen.

The training system is formed from software that simulates all these elements, in that models of every system are described in the software. This means that, during development, it is necessary to deal with models that are different for different customers.

The system and program developers have access to certain models but not all, given that the various systems – and therefore the models as well – have different levels of national security classification. This requires the software to be divided up into separate parts and the information and models to be handled using tools that provide secure access and protection.

The product itself is designed to provide customers with access to the models that they need and are authorised to deal with, but it also allows customers to add their own models of, for example, sensors that they wish to test during training.

This requires a software system design that allows models of various subsystems to be added and removed, which allows a customer to benefit from producing his or her own models of subsystems to try out without the supplier knowing what they look like.

This increases the benefit for the customer, but also leads to a simplified procedure for development and maintenance in the form of a modular software system with clear boundaries between different parts of the software. If the methodology is described in such a way that the software that is produced has a modular design, this facilitates both development and future maintenance of the product as well as making it possible to differentiate between pieces of software with different levels of national security classification.

Methodology

In order to carry out development work in accordance with the development process, this process must be implemented into the methodology, which then needs to be adapted to different tasks.

When developing software, continuous integration can be used – this means that the various sub-elements of code produced by each developer can be tested continuously against a larger codebase for an entire system and an entire function. In this way, it is possible to obtain quick feedback on functionality and increased quality with regard to the code that has been developed.

Continuous integration has been used for a number of years in a variety of projects, including within the development of support systems and training systems for Gripen. Continuous integration will also be used in the development of software in aircraft.

For designing systems and developing software, Model Based System Engineering (MBSE) is used. MBSE is a model-based working procedure for developing software. It focuses on creating and using abstract representations of knowledge and activities to control a particular function or system.

This type of development uses, for example, models for presenting a system graphically. This makes it easier to understand a system’s function or effect. It is also useful to use models to describe how different systems or parts of a system work together. Models can be used descriptively to show how a planned system would be used, or models can be used to define and generate executable program code.

Agile Development

In order to handle the problems involved in conducting software development projects, it has become common practice in recent years to use agile methods. Examples of these are scrum, pair programming and Kanban.

The purpose of these methods is to adapt the software successively to requirements that are not always clear from the start, such as when a customer does not initially know exactly what a product will look like when it is finished. It is therefore important to be agile, i.e. adaptable and deft during development, in order to develop and change a product gradually during the development work.

The work is thus managed through successive incremental growths in functionality and with an iterative working procedure. This means that smaller, regular deliveries are made and that various issues can be evaluated on an ongoing basis and changed in order to engage with new requirements and requests.

Depending on the task and context, some teams are permitted to choose some of these methods for themselves on the basis of the conditions that have been set. Different teams also have different degrees of maturity, which is another reason for being free to choose a method in order to develop and improve working procedures gradually.

The fact that software development makes it possible to change a product without the need for mechanical redesigns is a strength, but also a weakness that needs to be dealt with. From the customer’s point of view, it often seems that it should be a matter of “just changing a few lines of code”. The answer is that it is usually not that simple.

For example, let us consider a change of code in a flight-safety-critical piece of software. Any change at all will be extensive, as it involves dealing with documentation, reviewing code, testing functionality and handling a new delivery of code.

But even for software that is not flight-safety-critical, a change based on new requests can entail major or minor changes to the software. Introducing a new model in Mission Trainer, which is mentioned above, involves a minor change.

Using an agile working procedure provides greater opportunities for ongoing collaboration with a customer when developing a product that meets their requirements. This is done with controlled requirement management and a controlled cost profile.

Introducing agile methods for managing software projects is therefore one of the most important things that have happened at Saab in recent years. Although Saab is a small company compared to other aircraft manufacturers, the products are complex and become even more complex when they have to be coordinated with each other.

It is easy for an individual software developer to overlook his or her own role in this, and to feel that his or her own contribution is not especially significant.

One example is the work that was done within MSS for Gripen C/D regarding fuel calculation handling, in conjunction with planning a flight mission. There were only a very small number of people involved, who each had an important task to perform in order to introduce the function.

Every developer is highly significant for the development of the products. The correct use of agile methods highlights the responsibility of each and every person, what needs to be done and by when, and where each piece fits in the puzzle.

Agile methods are used today by a great many different teams in a number of different projects at Saab. They began to be introduced around 2008 by taking advantage of experiences that were formed when developing a mission planning system for flights with transport aircraft 84 (TP84) for the Swedish armed forces at Saab’s former office in Örebro.

The use of scrum in the TP84 project produced such positive effects that the development managers at the time drew up instructions for introducing it when working on new products. The use of scrum expanded in 2009, when more and more projects started to use agile development as a methodology. A number of workshops were also arranged, in which project and development teams shared their experiences and, of course, setbacks.

Agile methods have come to focus on the need for a more flexible and agile working procedure for system and software development. The variants of the waterfall model for systems and software development that were used for many years are limited by strict planning, management and sequences for the various phases of a development project. A sequential working procedure often leads to long lead times, less flexibility for exchanging experiences, and a reduced ability to handle required changes.

The figure shows a working procedure based on the waterfall principle.

The strength of agile methods is that they use working procedures that place the customer (whether internal or external) at the centre by regularly delivering value-creating results during a development project.

The figure shows a working procedure based on agile methodology.

Changes to requirements and preconditions are the rule rather than the exception in large development projects. It is therefore important to be able to deal with changes so that they create value for the customer.

The agile working procedure is based on the idea that the team that works on a task should itself take responsibility for planning the execution of that task. This usually provides good motivation for achieving the objective and the results specified by the customer, which therefore makes it easier to deliver good project results.

 

In agile methods, close collaboration within the team is a keystone of implementing each task. A built-in working procedure that takes a learning approach is necessary in order to learn lessons that can be used in future development tasks during the execution of a development project. It is particularly important for the team to have a chance to reflect on how to perform and what can be done to improve the working procedure and increase efficiency.

SCRUM

The use of agile methods within Saab began a number of years ago within software development, in conjunction with updates to previous versions of Gripen. The scrum methodology became the backbone of the agile working procedure. The scrum methodology was then refined and adapted.

Scrum is an iterative and incremental framework for handling product development, and is especially suitable for agile software development. The scrum framework defines a flexible, holistic strategy for product development, where a development team works as one unit to achieve a common goal.

The development team works closely together, either through physical proximity or close collaboration via a number of tools for communication between group members. There is also daily cooperation between all group members and technological disciplines involved in the project in question.

The idea behind scrum is to minimise the risks inherent in software development by developing software over short periods, so-called iterations, which are usually between two and six weeks long. The work in each iteration finishes with a deliverable result. This result then forms a part of the final result.

Each iteration involves revising working procedures and results in order to improve both the working procedures and the development that is being worked on. This is called a retrospective.

The methodology covers a number of roles and a number of component parts in the form of mandatory meetings and documents.

The figure shows the fundamental working methodology in SCRUM by means of a sprint cycle. The figure is based on working according to SCRUM with a minor Saab-adaptations.

An important part of the scrum methodology is the close collaboration between the internal customer/ordered of the work and the scrum team.

For it to work, the customer needs to take part. This is done through coordination meetings during the course of the development work; for example, coordination might take place at meetings after one sprint is finished, i.e. after 30 days’ work.

 

Working procedures in scrum

Development using agile methods requires commitment from individual people and development teams. The scrum methodology is based on an agreement between the orderer and the scrum team.

What the development team has agreed to carry out during a sprint must also be dealt with during the sprint, and the team must also be able to deliver the result.

Definitions relating to working procedures in scrum

  • A sprint is a division of work into suitable parts. Planning is managed via stories. A story describes, simply and concisely, what the task to be carried out is and why.
  • After prioritisation and timescale estimation, stories are placed in a backlog, which the development team takes on for implementation during each sprint.
  • A backlog is a place to gather all requests for changes to the product. If for any reason it is not possible to carry out the task, this must be stated in good time and the story must be replanned.

The figure shows the status board that a scrum team uses. The cases that are handled during a sprint are published here.

Work flow

The steps that are handled by a scrum team and published on a status board are described below.

  1. The cases that the team will be working on are retrieved from the project backlog of prioritised cases during the sprint planning. Those cases that the team has undertaken to handle first appear as “Not Checked Out”.
  2. Under “Checked Out” are cases that the team members are working on.
  3. Under “Done” are all completed cases.
  4. The burn-down diagram shows the remaining time in the sprint, the time spent on completed cases and what still remains to be done.
  5. In a perfectly planned and executed sprint, the blue curve in the burn-down diagram should be close to zero when the sprint is finished.
  6. Under “Unplanned Items” are cases that have arisen during the sprint. These must be handled individually. If it is deemed possible to complete them during the sprint, they should be carried out. Otherwise, the sprint must be replanned or these cases must be carried out in a later sprint. The team must handle this on the status board and keep the project manager informed.
  7. Under “Next” are cases that have been discovered during the work and that need to be handled when planning and updating the project’s backlog.

Preconditions

Working with a status board makes it clear to a project manager what a development team is working on. It may not be possible to squeeze in more and more work within a certain amount of time. The project manager must maintain organisation in the backlog of cases to be carried out, and ensure that these cases are scheduled and prioritised. If this is done, a development team can then select the various tasks to be carried out during a sprint.

When it works well, agile development means that project managers know what will be carried out by each development team and when it will be finished. The development team itself has made that commitment. This allows the project manager to prioritise organisation and to remove things that can be done later or do not need to be done at all.

In the scrum methodology, the retrospective is a cornerstone of the working procedure; this is done at the end of each sprint. It is important here to highlight each individual team member’s point of view on what works well and what works less well, so that continuous improvement work can take place.

The difficulties of scrum include putting together functioning development teams with the skills that the development team needs. The development team and each individual developer need to practise assessing what can be achieved and make sure that it is carried out.

In large projects, it can be difficult to coordinate the work efforts of every development team. If everybody makes sure that all development teams use the same amount of time for each sprint, this facilitates coordination.

There must also be an overall plan that manages the project’s backlog of cases and prioritises them. Every developer must be familiar with this plan. It is extremely important for everybody to be involved in selections and decisions regarding what is to be done in each sprint. Everybody is needed and everybody is important. This is the strength of using scrum, but it can become a weakness if there is insufficient knowledge.

Application

Scrum is applied in the majority of projects that work on systems development and software relating to Gripen. For example, it is applied both when developing software in the system computer for Gripen, training systems, and technical and tactical ground support systems.

Many software development projects use scrum with a sprint length of three weeks. This seems to be a sprint length that is well adapted to the need to focus on the task and the need to handle prioritised stories.

It is also important to be able to carry out demonstrations of results from a sprint once it has been completed. Furthermore, it is important to manage the need for replanning and reprioritisation with other development teams.

When development started on Gripen NG, agile methods were introduced at all levels within the disciplines for the development of software, hardware and basic aircraft systems design.

Examples of results that have arisen from projects that have used scrum for a long period of time are:

When developing the planning and evaluation systems for Gripen C/D and now for Gripen E (Mission Support System – MSS C/D and MSS E), the scrum methodology has contributed to the following:

  • A structured working procedure where the product requirements are transferred to top stories, which are then broken down into smaller work packages/stories, prioritised in the backlog and handled by the team. The team’s efficiency is measured via burn-down.
  • Achieving control over deliveries and costs in the MSS-C/D project.
  • Achieving good progress for the production of the software to be delivered in MSS-E. Workers have been able to keep an eye on their work.

Example – success using agile methods

At the start of the 2010s, there were major problems in the Basic Aircraft Systems technology area with completing one of the more central systems, called AIU. Work on developing the software had been carried out for a while using traditional procedures.

The work was characterised at that time by a positive attitude to performing all the tasks set for the development team. The development team contained a few very experienced key members, who made key assessments of the time required for the various tasks on the basis of their personal experience.

There were many requirement owners for the development team’s task. On the other hand, the development team had no specific method for analysing which requirements should be given priority, according to either sequence or urgency. The reason for that is that there was no established delivery sequence plan. All new tasks were taken on in good faith.

The most experienced key members of the development team soon became a scarce resource, which led to limited communication with requirement owners and other development teams involved in the work. Because the key members were overburdened with work, development work became a more individual task.

The workload for the development team became very heavy, so there was no time for systematic work on improving working procedures. The heavy workload forced the team to put in a lot of overtime to complete their task. In spite of that, the work fell further and further behind schedule. The requirement owners who were not getting their deliveries on time became very dissatisfied, and this led to a negative atmosphere. Because of the heavy workload, there had been no time to ascertain the internal requirements that existed and which would have facilitated prioritisation.

Measuring performance

Initially, before any change took place, a measurement of job satisfaction in the development team was carried out. On a scale of 1–5, the result was 2.8. Performance was also measured in terms of time, technique, quality and delivery precision. These values proved to be completely unacceptable at 0%. The results were a consequence of an excessive workload. It was not possible to deliver on time.

Actions

After that, improvement work began. Under these troubling circumstances, a new project manager was assigned, who introduced an agile approach to the task and the development team’s working procedures. It was ensured that the team members would get to know each other and work closely with the system developers.

A review was carried out with all requirement owners, and an order of priority was drawn up for all activities. This made it possible to see the effects on other development teams.

The development team drew up a plan to deal with this commitment. The result of the planning work produced a strong level of commitment, as the team was able to reach an agreement with the requirement owners. A delivery plan was then formally agreed upon with all affected stakeholders, requirement owners and development teams.

This resulted in other development teams being able to plan their work in a way that allowed the entire value stream to be controlled. This applied both to incoming deliveries for the development of AIU and outbound deliveries from this team.

Agile methods such as pair programming and the scrum methodology were also introduced. This working procedure is well suited to developing effective transfer of knowledge between team members.

It was ensured that the work could be visualised at a fine-grained level. This made the work easy to follow. It had become possible to optimise the work at a day-to-day level, and the critical line was clearly visible for the entire project at all times.

An order of priority had been established. Safety-critical software had been classified accordingly. There was a detailed plan for how to deliver new code in order to be finished within 18 months, which was absolutely necessary.

New code would now be delivered at specified times, a total of six times over the course of the project. The fact that the development team was now able to keep to its plan and deliver on time led to positive feedback, which had a positive effect on the atmosphere in the team. A lot of work was also done on communicating with the requirement owners and other development teams in the value stream.

In order to balance the tasks in the team better, the key members had the opportunity to act as coaches in order to support and teach the rest of the team.

Systematic improvement work was introduced in order to streamline many repetitive work tasks. Many effective improvements were made, both in terms of the tools used and the methods used to direct the work. Work was done according to the scrum methodology and there was always a retrospective review at the end of each sprint.

Measuring performance after actions

When job satisfaction in the development team was measured at the end of the project, the result on a scale of 1–5 was 4.7. Performance was also measured in terms of time, technique, quality and delivery precision. The fulfilment rate turned out to be 100%.

The project’s success factors were as follows:

  1. Work was managed with a focus on needs, so that deliveries were made on time and with the right level of quality.
  2. The project was organised so that practical and specific support could be given to participants on an everyday basis.
  3. The project owner took responsibility for ensuring contact and continuous communication with requirement owners and other stakeholders.
  4. Work was done on communication and knowledge transfer throughout the value stream.
  5. The work was divided into smaller tasks that were easier to grasp and manage.

Lessons learned from agile methods

For development work to be effective, it is very important for the development teams themselves to have the opportunity to invest their commitment on the basis of the actions taken by each person. To achieve effective development work, the various development teams must understand not only their own parts in the development work but also the value stream as a whole.

They must understand the prerequisites both up and down the value stream. If the teams understand this, it is significantly easier to communicate and to reach agreements with internal customers with regard to the expected project results. This allows the team to plan the work so that the right functionality is developed, and so that deliveries are made on time and with the right level of quality.

Commitment is needed both at the individual and at the team level – this means commitment to the project, the process and each other within a development team. An important factor in obtaining the right level of commitment and responsibility is that the teams must be included in decisions regarding both techniques and working procedures.

There is naturally a hierarchical structure within the line organisation for reaching technical decisions. However, it is important for the team to understand the technical design and to be involved in order to realise the technical solutions effectively.

A key role for work with agile methods, and specifically with scrum, is the product owner. This is a key role for gathering together all types of requirement and for including those that are derived from top-level customer requirements.

All requirements must be converted into concrete development tasks. The value of the functions to be developed must also be established, and clear planning conditions for those functions must also be provided. A product owner must ensure the realisation of new technical functions, define and minimise risks and plan for upcoming technical development steps.

Developing Gripen NG is a highly complex project. There are more than 1,000 engineers in over 100 development teams within 14 technology areas.

This development work makes use of scrum and agile methods to develop various functions and systems. Integrating many systems into a complex product sets high demands in terms of working procedures and management of work. Using scrum and agile methods makes it possible to continuously maintain a good overview of how the development work is progressing and to handle discrepancies and problems quickly and regularly.

Continuous integration

Continuous integration means that the software that is developed is checked via build stages, tested and made available to everyone else that needs it. If the methodology and development environment are fully developed for continuous integration, then each new piece of software that is added gives a product that is built and tested to a given level of quality.

A functional continuous integration process means that there is always a working product available and that the functions that it has and the requests and requirements that it handles are known.

Integration and growth of functionality take place incrementally, not in large integration stages. Tests can be carried out continuously when there is a growth of functions. Errors are fed back quickly to developers and interfaces are constantly tested. If continuous integration is fully deployed within a project, it leads to effective development, which contributes to a project as a success factor.

 The figure shows the various process steps in continuous integration.

For a larger project with many teams and functions, introducing and following continuous integration is a complex task.

For continuous integration to work, a well thought-through information flow is required, and this must be supported by a carefully considered, functional CM methodology. A well thought-through build environment with the possibility of daily and nightly builds is also needed. Integration and system builds must also be automated to a high degree.

A carefully considered test strategy with automated tests is also required. In addition, it is necessary to support and ensure that the software that is constantly being added to the project works together with the rest of the software.

The figure above shows the steps in continuous integration, but it is a simplified view of the process. For example, it also needs a methodology for ensuring that each software developer has access to the functions required in order to develop his or her own sections. Development tools (software) and a development environment (storage and equipment) are required to support this.

One way of giving every developer access to the completed product is in the form of prebuilts, which are controlled releases of the product that can be used as a basis for developing an individual part of a function, i.e. the code that an individual software developer needs to change. The status of each prebuilt is described with regard to content in the form of functions and the interfaces that apply to it.

Experiences and areas of use

There are many examples of projects where continuous integration has worked to varying degrees, but unfortunately the results and experiences tend not to be passed on between projects and when new projects are initiated.

Getting continuous integration to work without personal experience of the working procedure is not easy. Experiences need to be passed on from project to project.

Examples of successful projects that have used continuous integration include:

  • The development of the Gripen control system was the first project to apply continuous integration.
  • Various projects within the Gripen support system.
  • Mission trainer and MSS for Gripen C/D and MSS for Gripen E.
  • Mission Support System for Gripen C/D.

The development of the Gripen control system was implemented by building and testing the software for the control system in accordance with the flow that is similar to the process for continuous integration.

The mission trainer and MSS for Gripen C/D and the MSS for Gripen E, which are mentioned above, are projects that have used and still use continuous integration in software development. In these projects, a page in the project’s Wiki shows how building and integration works in the various software components that make up the project. Each piece of checked-in code is built and tested automatically.

The result is presented using colours for each software components. If a check-in is unsuccessful for any component, every developer can see this, and the developer that performed the check-in is often notified of the result. It is easy to see how valuable this is in a project with many developers.

Working procedures

For developing a tactical support system for planning and assessing tasks, called the Mission Support System for Gripen C/D, continuous integration is used as follows:

A developer of a functionality is given access to the most recent piece of software in the form of prebuilts, which are controlled releases of MSS C/D. These prebuilts can be used as a basis for developing an individual part of a functionality, i.e. the code that an individual software developer needs to change.

  • Together with a data environment, such as map data, weaponry data etc., this means that everything that is necessary can be accessed.
  • Prebuilts are based on the functional product that is (almost) always available. Prebuilts are packaged on planned occasions and are made available in the project.

When a developer is finished with his or her function, it is tested within the framework (software and hardware) so that the system/product can be built on a daily basis. This is called a daily build.

  • It is then possible to show that it can be used in the project.
  • It is also possible to show when interfaces etc. are working and when one does not understand other developers’ work on the code.

The function is then added to a build environment and run on a nightly basis. When this run is carried out, automatic test stages etc. are also performed – this is called a nightly build.

  • At each stage, the software developer is notified if everything is fine or if there are any errors to be dealt with.
  • This provides quick feedback to a developer and allows the developer to test and deal with detected errors on an incremental basis.

Having a working continuous integration functionality within a project thus provides a high level of efficiency.

Increased automation

It may be possible to go one step further, from continuous integration to continuous deployment, which means that the end result will be a product that is ready for delivery.

This means that each newly added function will result in a product that is tested and ready to be delivered. Reaching the continuous deployment level for a product that will fly, however, requires an analysis of how far it is possible to automate all the formal stages that are needed before a piece of software is approved for flight.

Even if there is still a way to go before this can be implemented, it is worth studying how far it is possible to take the process. Processes other than the software development process are also involved, such as system development, verification and validation.

Managing Existing and Future Requirements

Managing problems with software development is largely a matter of being able to apply methodologies, such as agile development and continuous integration.

However, the need for technology and technological development that is also needed within the area of agile development and continuous integration should also be borne in mind. The technological areas that will really benefit from better methodology in development work are software architecture, i.e. how requirements are translated into a design, technology for managing the building of software products, managing tests, test strategy and managing real-time systems, as well as information management and software security.

In this area, we are collaborating with the country’s universities to study, for example, the management of technical liability. This is done by defining what is meant by technical liability and applying technology to measure and manage it. Other examples include technology for developing continuous integration and technology for managing software in multicore processors in flying systems.

The choice of MBSE is as much a choice of methodology as a choice of technology. Successfully introducing MBSE into software development makes it possible to handle the architecture, design and management of complex functions.

However, there are also other areas that are just as important, such as technology for managing built-in real-time systems, safety-critical software in systems with multiprocessors, and testing and environment presentation in real-time simulators.

It is important for the experiences that are formed to be passed on to new or ongoing project teams and for those teams to become familiar with them. The transfer of experiences always seems to be a challenge, regardless of the decade.

Software requirements

There is an important difference between developing code for a built-in flying system that is required to handle flight-safety-critical software and handing the development of, for example, a system for dealing with tactical loops or a test system.

Built-in systems with real-time requirements may mean, for example, access to limited memory, smaller storage media and performance requirements to maintain time requirements. Flight-safety-critical components must not crash – i.e. stop executing – without providing control over how the crash is dealt with. For software that is used at a desktop for a non-critical use, it is irritating if a program stops working, but it can be dealt with by restarting the program or, in many cases, by restarting the computer.

System development environment requirements

It is often easy to end up in a situation where a tool – such as an “awesome” compiler – is chosen with no thought given to the methodology and regulations that need to be followed before the choice is made. Tools are meant to be precisely that: tools that help to develop products quickly and effectively.

It is also important to have control of locked-in effects, i.e. the implications of choosing a particular tool in terms of work and the additional cost of replacing it with another tool.

However, what is important is not the number of tools that need to be managed. There can be many of them. What is important is to have control over whether the tool makes it possible to realise the selected methodology.

Strategy for system development environments

As there are differences in the development of the various products and the number of tools is large and needs to be large, a strategy is required in order to manage the tools.

  • One strategy is to describe the need for tools in the capabilities that are required in order to develop the product.
  • Capabilities might, for example, be the need for tools for agile development, build environments, test environments, managing needs etc.
  • It is important to divide the development up into capability requirements and to look at which tools are needed to realise those capabilities.

The strategy should also ensure that it is possible to develop both built-in real-time systems and desktop systems. These use different operating systems, which means that different tools may be most suitable for developing different products. This means that a capability may include several different tools in order to fulfil it. It may even be a strength for a larger company to have several different choices. For example, it might make it possible to manage customer requests regarding software to be used on a particular platform (Linux, Windows, Android etc.). This also reduces dependence on a particular tool supplier and makes it possible to compare the functionality of different tools.

Systems development and product commitments

It is also important here to understand that a development environment and a methodology are linked to a product rather than to a project. The purpose of the project is to manage the development and delivery of a given version of a product. After that, the project is usually over. The product, on the other hand, lives on in the form of new projects to deal with guarantee commitments, further development etc. The development environment is then needed to handle new projects for the product.

Below are some examples of different tools that are required for the development of a product. Some examples of what tools are needed for:

  • Requirement management.
  • Configuration management (CM).
  • Development (compilers, editors).
  • Building the product.
  • Managing cases.
  • HMI production.
  • Delivering the product.
  • Safety management (e.g. anti-virus tools).

Recommendations

To create an effective system development environment, it is important for a project to be linked to a product’s life cycle rather than to an individual system development project.

Setting up all those tools and their associated adaptations to handle methodology, capabilities and information flow requirements is a project in itself,

which will live on as part of the product’s development project for its entire lifespan – sometimes longer.

The project of managing a development environment consists of at least three phases:

  • Setting up the development environment and putting it into operation.
  • Continuous maintenance of the development environment once the project is complete.
  • Packaging the development environment for the future.

The author´s reflections