The hybrid process – general design

The first post in the series on hybrid software development talked about general problems many software development companies have during their customer relationship. Contracts are very often based on a linear process as shown below:
Hybrid Contract flow

In addition, user departments responsible for the requirements and the software may have the need to change the requirements even after they have been finalized or contractually agreed due to several reasons. Some of them are:

  • A change in another process requires a change of the requirement
  • Some requirements have been forgotten
  • A change due to e.g. legal reasons need to be included

Based on the number of required changes projects need to be shifted, deployment dates need to be moved or projects already started need to be cancelled.

In the last decade agile development tried to get rid of some of the challenges mentioned above. Based on the “Agile Manifest” a lot of development processes have been designed that try to solve the problems mentioned above. As a result, requirements are created at a rougher level at the beginning and later on detailed during development at the time when they are really developed. In recent years several of these process models have been designed, namely Scrum, FDD and others.

In recent years it has been seen that even those approaches have raised questions and concerns. Some of them are:

  • They do not follow enterprise processes (as enterprises are very often stick to linear processes where there’s a contract required with a fixed price offer based on a detailed specification)
  • Very rough requirements at the beginning might cause legal intervention in case of later delays not non-wanted results
  • Customers (and requirement engineers) need to be more involved during the complete development process.
  • Processes like scrum or other agile methods tend to deliver software in more frequent deployments (to reduce time to market). A software delivery with intermediate (and therefore changing) features need a high amount of change management. This becomes heavy if you use a complex software on a high user base.
  • Team building is a more complex process as agile teams with a given velocity tend to react negative to changes in stuffing.

We have designed a hybrid process which tries to overcome (most of) the concerns described above and create a model combining the best out of the two worlds (classic and agile).

The hybrid process will change each of the process steps above in a way to achieve a possibility to create flexibility during development for a fixed price project:

  • Requirements: Allow fuzzy requirements that remain estimatable
  • Contract: Enhance the contract process to recognize fuzzyness and allow reserves
  • Develop: Agile (e.g. Scrum) and allow refinements
  • Deployment: (Usually) only one deployment towards the customer
  • Acceptance: Acceptance based on requirements and refinements

This process has been established now for medium to large projects for at least three years with increasing success.

Further posts will discuss details on every process step and will provide more in-depth guidance.

Creating bootstrapper installers with dotNetInstaller

Currently we are using WIX integrated into our TFS build process to create our installation packages. This has been proved to be a fast and cheap way to create professional setup packages.Actually there was the need to create combined setup packages consisting of several MSI packages generated by WIX.After looking at several packages (including WIX 3.6 burn, and others) we decided to start over with dotNetInstaller. Using a XML file you are able to generate .EXE bootstrappers. After playing around with this tool we decided to incorporate this directly into our build process which wasn’t that easy as the integration needed to support the following “features”:

  • MSBuild (the integration is done in the .wixproj file)
  • Support for dynamic filenames (including the automatically generated version number)
  • Support for multiple languages

The following sections describe the steps to include this into our software: Continue reading “Creating bootstrapper installers with dotNetInstaller”

Creating NetworkService services with wix

One of our products had the need to create a windows service running as “NetworkService” user.

So we did it the simple way and created the following (wrong) script:

<Component Id="cmpVipeService" Guid="PUT-GUID-HERE">
  <!-- CreateFolder is necessary for components without files -->
  <File Id="filServiceExecutable" Source="$(var.VipeService.TargetPath)" KeyPath="yes"/>
  <ServiceInstall Id="srvVipeService" Name="VIPE [INSTANCE_NUMBER] Service" Start="auto" Type="ownProcess"
  <ServiceControl Id="StartsrvVipeService" Name="VIPE [INSTANCE_NUMBER] Service" Start="install" Wait="no" />
  <ServiceControl Id="StopsrvVipeService" Name="VIPE [INSTANCE_NUMBER] Service" Stop="both" Wait="yes" Remove="uninstall" />

Testing on a local PC and a test server worked fine, as WIX_ACCOUNT_NETWORKSERVICE has been translated to “NT
AUTHORITY\NETWORK SERVICE” or “NT AUTORITÄT\NETZWERKDIENST” (in German) and the service has been installed successfully. The only difference between existing (NetworkService) users and our service has been the written username “NT AUTORITÄT\NETZWERKDIENST”.

Result: Test completed inside our domain.

Yesterday we started to deploy the software to the production environment on a dedicated internet server hosted externally (and therefore not included in our domain). And (as expected) we failed. The following error has been reported in the event log with the id NETLOGON – 3095 (Sorry, in German):

Dieser Computer ist als Mitglied einer Arbeitsgruppe konfiguriert, nicht als Mitglied einer Domäne. Der Anmeldedienst braucht bei dieser Konfiguration nicht gestartet zu sein.

In english: The computer is a member of a workgroup, not a domain. The NETLOGON service doesn’t need to be run.

As a result the installation failed.

On day with unsuccessful research I finally analized an existing 3rd party tool that installs a service with a NetworkService login as well. The solution was simply not to put WIX_ACCOUNT_NETWORKSERVICE but “NT AUTHORITY\NetworkService” for the Account parameter.

Windows MSI API translates this value automatically into the local representation (i.e. NetworkService or Netzwerkdienst, …). After changing the parameter and running the installation again the software package has been installed successfully.

TFS checkin policy for Jira

We are currently in the phase to migrate all projects to Visual Studio 2010, C#, TFS, SQL Server. Additionally we are planning to use Jira for bug/feature tracking.

One nice enhancement we are using additionally is the Atlassian Connector for Visual Studio. With the connector we are able to search for issues, change issue statem …

What was missing is the integration of Jira for TFS.

We have a development policy that requires a issue number to be provided to the checkin comment which allowes later on to see which checkin was related to which comment.

Continue reading “TFS checkin policy for Jira”