JAMK Designs Product Line for Businesses and Communities
Company production lines are usually not public. Now the N4S@JAMK project team of the JAMK University of Applied Sciences has designed and implemented a holistic production line chain for the design of digital services. The production line chain, now known by the working title Corolla, and the different processes essentially related to it offer opportunities for software companies, startups, researchers and students to see for themselves and test in practice how a modern production development line works. A byproduct of this development work is the Contriboard tool used for validating the functionality of the product line, which will be released as an open source product.
The idea about the Corolla production line was born in meetings dealing with N4S work packages, where the N4S@JAMK project team leaders Marko Rintamäki and Jouni Huotari realized they were discussing similar things, but without any concrete common denominator or linking. To practicalize the N4S research challenges between different work packages, a project team of around 10 persons designed a production line that allows any company or community to develop products according to the themes of the N4S program.
Jouni Huotari (left), Paavo Nelimarkka and Marko Rintamäki from the N4S@JAMK project team say that the production line gives software companies, researchers and students an opportunity to see for themselves and test in practice how a modern product development line works.
"A working example of a development environment allows open discussion, exchange of ideas and the testing of new ideas. The aim is to make the mystical adjustment of tools at least slightly more sensible," says Rintamäki.
Rintamäki sees a need for the exchange of ideas, because the production lines of commercial companies arounde rarely public, and some, such as small startup companies, don't necessarily have time to think about processes.
"Companies are used to designing products and services using their own models of operation. However, the present-day need to quickly produce products for the market also forces them to look for outside examples, because they are cost-efficient. Large companies may test parts of our implemented solution in their own internal projects, for example."
Based on cloud services
Video caption
As the project team developed a product development environment together with enthusiastic younger generation developers, combining some old and lots of new, they gave birth to a modern production line that allows software professionals to produce products and services efficiently and holistically.
"The production line was christened 'Corolla', which is a fairly well-known car model in Finland. The analogy here is that services related to the Corolla product development environment are easily available for everyone and relatively well-known," says Rintamäki.
The production line is based on the integration and shared use of product development services. When individual services are flexible, the entire operational environment can be easily scaled, allowing the expansion of the operations of a small team into a larger product line.
"The Corolla product development line responds to today's needs. It allows the agile development of products and services based on the customer's needs. Since the production line is based on cloud services, the service chain may be utilized with rather minimal resources. In practice, all you need is a computer, an Internet connection and a stool," says Rintamäki.
The Corolla production chain designed by the N4S@JAMK project team includes the most modern commercial and open source services. Corolla offers an opportunity to try out new models of operation without an excessive production risk. The experimentation can be done in the form of engineering work, for example.
The product development environment is divided into two parts: the Digital Ocean development cloud and the Amazon production cloud. The current development environment consists of well-known and proven open source tools (e.g. Jenkins, Robot Framework, fMBT) and tools offered by commercial operators. These include the Dropbox file synchronization application, the Flowdock team communication tool and the GitHub project management service. All in all, more than twenty different cloud services and other tool components were needed to implement the development environment. The components chosen may also be replaced, if necessary. The development environment is constantly changing.
Faster distribution of information
According to Rintamäki, operating in the Corolla development environment differs from traditional product development in a few important ways.
"To support quick design, the Corolla production line utilizes mockup techniques. Because the distribution of information within the entire development team must be very fast, aggressive integration is used between different services. Current information from development to production is available in real time, and the development and release of the service follow the principle of continuous development," Rintamäki says.
The production line also includes testing automation, which is an important area when the aim is to speed up product development.
"When the validation of the development environment can also be done using model-based testing, many things are better than good. The aforementioned examples emphasize that the development team must have a good view of every stage of the product. In older production companies, allowing this type of operation can be challenging even culturally," says Rintamäki.
He believes that although there are many handy tools and services available, one basic fact remains the same. Products are created by humans, and they usually do it together.
"Working together may be a challenge, and there must be resources to facilitate it. The Finnish work community without extra hierarchy is competitive in the international market. A good team and good tools give at least a little more flexibility in competition in the global market."
“Companies are used to designing products and services using their own models of operation. However, the present-day need to quickly produce products for the market also forces them to look for outside examples, because they are cost-efficient. Large companies may test parts of our implemented solution in their own internal projects, for example.”
Contriboard — a tool for agile team work
To support collaboration between N4S companies, in the background of the development environment the N4S@JAMK team designed the Contriboard reference product that allows the validation of the Corolla development environment and its processes.
"The goal of the N4S@JAMK team was to develop a product that includes all the essential elements of contemporary cloud services; ease of use, scalability, service monitoring and up-to-date technologies. The purpose of the Contriboard product is to act as an example of how a massively scaling service can be implemented using the Corolla product development environment. Since the service is open source licensed, it can be utilized in things like teaching to create a larger context to support the things being taught," Rintamäki describes.
Contriboard is a tool for developing ideas, where the working platform is a virtual board with idea notes attached to it. A virtual board created in Contriboard can be distributed in real time between the team, for example, after which every user of the board may freely toss up ideas in the form of notes.
"In its current form, the product is not exceptional compared to things like competing solutions, but the service's background systems and running environment enable rather diverse further development. The current implementation is based on the MVP (Minimum Value Product) thinking that is related to the Lean Startup model," Rintamäki says.
Feedback and ideas from companies in the N4S program
Rintamäki believes that N4S partners may collaborate in diverse ways using the Contriboard product reference. At this stage, the aim is to get interested parties to join in and to create a shared effort to make the product viable.
"Different operators may have quite different views of things like what is meant by the concept of service design. In developing the Contriboard reference product, we can show how we do things related to it. This allows us to open a discussion about how models of operation can be developed further. This allows everyone else to learn as well."
According to Rintamäki, another good topic of discussion is how the concept of DevOps is understood in different companies.
"This is being tested in practice in the N4S@JAMK team so that the entire team is made up of different experts. We aim to develop the Contriboard product by using the DevOps thinking as a basis for everything. Developing working practices together has many times led to the realization that using DevOps thinking can't be taken for granted. Perhaps our experiences can help others wrestling with the same problems."
For more information:
Students test Corolla production line - link sharing service Toolbar is born
During the summer of 2014, a group of students of the JAMK University of Applied Sciences used an earlier version of the Corolla production line. This helped them create a new product concept called Toolbar.
JAMK student Janne Heikkinen says that the most important thing about developing the Toolbar product concept was the practical testing of the Corolla production line and working methods.
"Adoption of the production line was slow at first, because the working method associated with it was new in our studies. After we learned to utilize the model, it gave us quick feedback for planning our work. The production line allowed us to automatize the actions related to testing and release. The process of continuous release characteristic of the production line gave us quick feedback about errors, which allowed them to be fixed and rereleased," says Heikkinen. Toolbar as a product concept is a simple link sharing service that can be used within a development team to share web addresses related to different tools, for example. The link collection is sent in the form of a simple tweet link and opens for the user in the form of a small tool kit.
Heikkinen says Toolbar is a useful tool particularly in the early stages of a project, when information and links related to the project are collected from the Internet. With Toolbar, large numbers of links can be easily viewed and shared by the team members. Links can be grouped according to one's preferences and can be password-protected.
For more information:
Model-based testing automation speeds up product development
An important part of the Corolla product development environment is testing automation, which includes Ixonos' model-based testing automation tool Visual Test. The Ixonos Visual Test (current: QAutomate) can be utilized in all fields of business from startups to large corporations. Anssi Pekkarinen of QAutomate says that model-based testing automation helps generate tests mechanically and faster than tests written by humans using traditional methods. Model-based testing means that the behavior of the system being tested is modeled and run against the system by randomly jumping from one state to another.
Pictured here is a model graph from JAMK's Contriboard application and Ixonos' Visual Test Tool product (current: QAutomate). Ixonos' page model-based approach helps create a model graph and the elements needed for testing. A model-based approach alone is not enough; testing automation also requires a totality around the testing. All tools must be in order: the page model, creation of the model graph, running a test from the model, requirements, etc. This requires Ixonos Visual Test, which offers the tools needed for these tasks.
"In Ixonos' approach, state transitions are formed between page models created during model-based testing automation, which create a model graph with its dependencies. Page models, state transitions and dependencies form a model graph. When the methods related to page models are bound to the state transitions of this model graph, the test run will know which methods shall be executed in each state transition. During a test run, these state transitions create executable test flow. Tests can be run either offline or online," says Pekkarinen.
Pekkarinen says that in offline model-based testing automation, a test set is generated based on a model by attempting to cover every state transition. Therefore, a number of n generated tests are created. Online testing means that the tool uses the model as a map, and continuously navigates forward without generated tests. Usually, a target state is set in online testing, so that testing is stopped after reaching sufficient path coverage, a time limit or requirements, or after encountering an error.
"The test is given stoppage conditions, such as requirements (successful login, logout), a time limit of 1h or 100% path coverage. In online testing, the next state transition is always determined randomly according to guards or emphases. In practice, this means that test flow will always be different for each run, which makes it easier to test unpredictable behavior. This is a more efficient way of finding errors than regular regression testing, which always repeats the same test flow."
According to Pekkarinen, creating and running model-based tests is more efficient and diverse than regression testing using traditional methods. The model-based approach allows other areas of testing, such as performance tests and live monitoring, to be combined with the test. Ixonos has conceptualized techniques, which allows the same regression testing model graph to be utilized in performance testing and live monitoring. The model-based approach also makes system administration easier and adds new dimensions to it. In online-based testing, there is no need to maintain so-called tests; the upkeep of models, state transitions and the methods of its model will be sufficient.
Model-based testing is expected to quickly become common in agile production lines based on cloud and web services. The largest American companies have increasingly started using a model-based approach for things like testing phone software, and Spotify, for example, has long been a pioneer in this. Small companies have so far rarely utilized model-based testing automation, and on the Finnish scale, model-based testing is still generally uncommon.
"The reason it is not used yet is generally its complexity and the difficulty of getting started. At Ixonos, we have approached this from the point of view of making its use easy and facilitating its adoption with an appropriate tool," says Pekkarinen.
For more information:
