ALM is a subset of PLM

In the production industry, software is very often the breaking point in the product lifecycle. Of course, the question raised is how to optimize software development and how to shorten time to market. The amount of software contained in “classic” products is substantial.

A luxury car contains up to 100 million lines of code! Even a simple, computer controlled household appliance can contain up to 1 million lines of code. Medical devices contain up to 3 million lines of code and a jet fighter contains up to 6 million lines of code. Surely you are using a Product Lifecycle Management System (PLM-System) like Dassault Enovia, PTC Windchill or Siemens TeamCenter for controlling the product LifeCycle. But how do you control the development of the software, which is part of your product?

Do you use your PLM-System for managing your product’s software? Maybe you are using an ALM-System (Application Lifecycle Management-System) for managing your software? If yes, this is great! In case your company is part of that 3% of enterprises who have connected the ALM-System to the PLM-System then you can stop reading now.

If you are still reading, this means that there is a very high chance that your enterprise belongs to the remaining 97% of companies who handle Product Lifecycle Management and Application Lifecycle Management isolated from each other – even though both outputs will become part of one product.

To achieve a synchronized effort for both, use the best of breed tools and connect software development with the production processes of your product.

Segments in Product Lifecycle Management

The image above showcases where the production of hardware and software is separated in the PLM process. The processes for producing hardware and software are very different. It begins with the project methodology: Hardware is produced in projects using the waterfall or V-Model as project methodology usually. Producing hardware is highly automatable using CAD/CAM systems and CNC machines, but the software development process contains a lot of manual interactions even though the right tools for automation are available.

Software development in isolated environments with lots of manual interaction not only harms traceability (Important for archiving compliance!), but also the protection of intellectual property and quality of work, and therefore the quality of the entire product. Manual interactions always lead to a high risk of human failure, hence why this automation in the software development processes is duty, not luxury. For archiving this, a co-operation of tools is unavoidable. This starts with requirement management and moves from coding and the build process to automated testing and deployment of the software product back into the chain of the product lifecycle.

ALM is a sub process of PLM

Most important for automation is the connection of point tools used for software development. This is where CollabNet’s TeamForge comes into the picture. TeamForge connects the point tools and creates an automatable and traceable production chain for software. Permission control and role based access control containing single sign on for protecting your intellectual property and an inter project reporting are wanted side effects. This allows the developer to continue working with the tools they are experienced with without affecting their day-to-day tasks. TeamForge’s interfaces allow the connection of most of the point solutions and their integration into the PLM process.

TeamForge becomes the dashboard for the software development process and monitors sub processes and progress. With TeamForge, it doesn’t matter if software is developed following agile or waterfall and if there are one or multiple Git or Subversion repositories.

Following this example, the most important integration is the one from TeamForge into the PLM system. A bidirectional data transfer for transmitting requirements from the PLM system to TeamForge as the ALM system and vice versa is key here. This includes- and is not limited to- the deployment of the produced software, status reporting, amounts of effort, etc.  The information transferred from TeamForge to the PLM system are key for a successful integration of PLM and ALM processes, and therefore optimizing the product lifecycle.

An example process could be

  • A requirement for a new product (part) of type of “Software” is created inside the PLM system.
  • Either a new project will be created in TeamForge for this requirement or information is provided for which project the software part should be assigned to. The specification, a definition of an interface for example, will become a part of a User Story or an Epic in TeamForge and this can be assigned to a Project Manager or a Software Architect.
  • The usual software development process containing coding, build and test, is started in TeamForge .
  • If the created software passes the final tests it will be deployed to a binary repository and a message will be sent to the PLM system that the task is completed with details of where to find the software. The source code will be deployed to a source code repository for protecting the intellectual property.
  • The task will be marked as “completed” in the ALM System. In the PLM system the software can be burnt on to a chip to build into the product and bring the new “part” to production.

The change request was automatically transferred from Enovia to TeamForge

 

Because a PLM system is implemented differently in every Enterprise, the adaptation of TeamForge to the PLM system is always an individual solution. This allows a perfect integration and top level support for the PLM process.

Through the implementation of ALM by TeamForge into the product lifecycle, software development is accelerated and time to market is decreased, saving budget and time are wanted side effects. Automation of processes allows more effective planning and shorter release cycles for software. Project planning becomes more reliable using TeamForge’s reporting and because of tool integrations, each step in the process is much more reasonable.

 

 

Juergen Moors

Juergen has over 20 years of experience in the IT business, working with large enterprise organizations like Compuware, Quest Software and Business Objects developing in Java, C++, Assembler, Basic and some 4GLs. Juergen has expertise in the areas of Development, IT-Security, Business Intelligence and Application Performance Management - sharing his insights via published articles and speaking opportunities at industry events. Juergen lives with his wife and two grown up sons in the west of Germany and in his free time he is constructing and flying radio controlled planes.

Posted in Agile, DevOps/CI, TeamForge

Leave a Reply

Your email address will not be published. Required fields are marked *

*