Skandinavisk Data Center |
|
Increase the Productivity of Developers |
|
| NB It is important to note that this Case Study makes reference to CA SCM; references to CA SCM may also apply to instances where the product was known as its previous name, AllFusion Harvest Change Manager. | |
|
Skandinavisk Data Center, or SDC, is an IT organisation based in Copenhagen, Denmark, with over 300 employees
and annual revenues of approximately 1 billion kr (£120m). In April, 2008, Trinem was asked to get involved with SDC by CA Denmark. As an existing customer of CA, SDC were keen to seek improvements and efficiencies from the IT investments they had made with CA. Trinem was engaged to review, recommend and implement suitable changes around their Software Engineering practices, which extended into other areas such as Service Support and Quality Assurance. After the first engagement, conducted throughout 2008, SDC realised a time (and relative cost) saving of 50% within their Release Management team. This was achieved by addressing a number of issues:
Trinem's extensive experience in CA SCM implementations allowed them to quickly identify 'quick wins' by re-engineering the process used for Parallel and Concurrent Development. Trinem implemented an elegant solution that allowed Support & Maintenance development to take place alongside Planned Development - this was achieved through Branched and Trunk Development being conducted within two States, sharing the same View. |
Although this may have seemed like a fairly simple solution, it eradicated a bottleneck in the Application
Development process which restricted the frequencey and accuracy of changes. A large proportion of SDC's development is in Java, using the Eclipse IDE. One of the key benefits to SDC is having productive Developers. This can only be achieved if the Developers are presented with all the necessary information to do their jobs, i.e., from their Eclipse IDE. Figure 1. illustrates how the Development Planning information is displayed through the Eclipse environment. 
By presenting the developer with all the necessary information to perform their job from within their Development Environment, they do not spend time collating information from various sources, or tools. |
|
|
Agile Development: Development Planning & Iterations |
|
|
Organisations dislike change. One thing they hate more than change is expensive consultants coming into their organisation
preaching about the new 'methodologies' they've just picked up from their last "Team Building" meeting. Trinem did not try to
impose new methods or fashionable new terms upon SDC. Trinem masked all the 'method speak' from SDC and simply adopted the latest Agile, SCRUM and Iterative processes that provided the best fit for the customer. Trinem implemented a solution that allows Development Managers, Developers and Users to articulate their requirements as "User Stories". These User Stories can then be allocated to pre-determined Iterations - all achieved by customising the CA SCM Forms. Since the "Agile" functionality was built around the CA SCM Forms, this meant that all "Agile Tasks" were access controlled through CA SCM. This also meant that all Iteration information was accessible to the Developers via their IDE, Eclipse. Figure 2. illustrates how a Package (User Story) is assigned to an Iteration, while the lower section of the customised form displays dynamic data related to the Iteration, such as Iteration Start/End, Number of User Stories, Man Day Effort, Iteration Velocity and an overall Project Velocity. 
|
By presenting the developer with all the necessary information to perform their job from within their Development
Environment, they do not spend time collating information from various sources, or tools. The customised Form used to manage the "Iteration Planning" tasks is completely dynamic and displays data in real time. The Form provides the user with relevant information, such as the length of the Iteration - either 5, 10 or 15 working days. The Form is sensitive to its CA SCM context, for example, once the Package (User Story) has been assigned to an Iteration while in the "Development Planning" state, it cannot then be changed once it has been promoted into another state in the Lifecycle. Figure 2. shows the Package in "Development" and as such, requires a development estimate from the assigned Developer, in this case the assigned Developer has estimated that this User Story will take 2 days to develop. The "Iterative Development Cycle" metric is a count of the number of times a User Story has been presented for "Acceptance Testing" and failed. As we shall see, this metric becomes inmportant when calculating "Re-work" metrics - invaluable for assessing productivity of Developers (spending large amounts of time on "Re-work" would indicate one of two problems; either the requirements are not clearly articulated, or the Developer is not suitably skilled for the piece of work). The technology used to implement the dynamic forms was Trinem's own Trilogy product. The Trilogy product also allows SDC to stream live data from other systems (HP Quality Center and Service Desk) directly to the CA SCM Forms - this is a direct stream of data in real time, not a synchronisation or data copy. |
|
|
|
Continuous Integration Builds |
|
|
Some modern development methods advocate the ideal of producing working software over functionally correct software. The obvious downside
is that although the software may work, it may not be to the users' liking. The obvious benefit is that the software, regardless of its features,
is operational. To remain competitive, organisations need working software all of the time. If an organisation can prevent 'broken' software from leaving their Development department then they should never have 'broken' software deployed to their Production systems. The work that Trinem did with SDC also covered this exact situation. Each time a change is committed to the CA SCM repository, a Continuous Integration Build tool was used to compile the code and ensure that the application had not been broken. The tool responsible for managing the continuous builds was CruiseControl. Figure 3. is an example of the CruiseControl dashboard. 
By using the CruiseControl Dashboard it is easy for anyone in the organisation to see the status of any build. It is also possible for users to view the details of any build, namely:
|
Figure 4. is an example of the "Modifications" tab. This tab tells the user information about the modifications that
were part of that particular build; the Developer who made the changes, any comments by the Developer, the Configuration Item that was modified, and the
version of the Configuration Item. In SDC's case, this data is all supplied from the underlying CA SCM implementation.
Other useful build information is also available on the Build page; users can view the date and time the build took place, how long the build took complete, and the build number - a summary section down the side of the page provides an overview of previous builds and their success status. |
|
|
|
Unit Testing & Panopticode Scans |
|
In addition to producing code that compiles correctly, it is important that a minimum set of tests are carried out on the code to ensure the application
has not regressed. In SDC's case, JUnit is used to automatically test that components have not been broken. Figure 5.
is an example of a series of Unit Tests that have been run over the code, this particular example also displays Test Failures.
By invoking automated unit tests as part of the build, SDC now have checks at component level, conducted each time a change is submitted by a Developer into the CA SCM repository. This goes some way to finding and avoiding defects, however, if the tests do not cover enough of the application then having a 100% pass rate becomes almost meaningless. To ensure that SDC had suitable levels of unit test coverage, Trinem implemented Panopticode Scans to identify where coverage was sufficient and where it was weak. A Panopticode Scan provides SDC with this information in the form of a visualisation. Figure 6. is an example of this; black areas represent areas of the application that have no unit test coverage, through to green where there is sufficient unit test coverage (red represents coverage greater than 0%, yellow represents coverage greater than 50%). |
The same Panopticode tool has also been implemented to identify the commplexity of the code within the application. This is a useful metric to identify areas of the application that may benefit from refactoring thus enabling better reuse of code. Figure 7. is an example of a Code Complexity scan. 
|
|
|
|
Automated Software Deployments |
|
One of the greatest benefits realised by SDC was around their software deployments. In the past, SDC's Release Management team were
responsible for the deployment of all the correct application versions to all environments across the application development Lifecycle.
This was a very manual process that was labour intensive and involved a significant amount of resource. Due to the frequency of changes, and the number
of various applications, this meant that the deployment process was very restrictive and time consuming.
Trinem implemented their Deployment Manager tool which allowed SDC's Developers, Testers and Environment Managers to manage their own deployments. Across the Lifecycle there are various people responsible for numerous environments. The difficulty, as with most organisations, is getting the less technical staff to deploy the application within their own environment - a deployment 'crafted' by Developers in "Development" can be a mammoth task for less technical staff in, say, the "Test" environments. By implementing Trinem's Deployment Manager tool, it is possible for each Environment Manager to configure their own automated, repeatable deployment. As you see from Figure 8., it is a simple task for a user to define their 'Logical Servers' - a label given to a group of physical servers that make up any one environment. 
|
The 'Physical Servers' are the actual machines that make up each environment; the database server, presentation server and application server, for
example. Figure 9. is an example of how each 'Physical Server' is defined. By using Trinem's Deployment Manager tool, it is also possible to configure intuitive settings, such as:
Figure 10. shows how the administrators can define how connections to remote machines will be handled. User credentials can be entered by either; entering them at the deployment runtime, by using an encryted '.dfo' file stored on a file system, by using an encrypted '.dfo' within the CA SCM repository, or by storing them in plain text. |
|
|
|
 |
 |
 |
 |
 |
 |
 |
 |
Case Studies
|
Share |
| © 2003-2010 Trinem Consulting Limited |