Once this selection is made, you can dig into Application Lifetime Management (ALM). So, what's the path to follow in order to get to a happy end? Consider that even today, some facts reflected in statistics seem frightening:

With these facts in mind, we need to explore how to properly manage a new project with some confidence and within the schedule and target that we initially foresaw.

On one hand, we count on a complete set of tools and technologies (what we understand by the development platform) that allow any developer to build applications for any type of model, platform, or technology.

This universal offer is even clearer now that it was in the Guide's publication, given the new options around the Universal Windows Platform and .NET Core (which we've already mentioned in this book and will see in more detail in the final chapter).

In addition, ASP.NET Core, and the rest of the initiatives related to Node.js, Apache Cordova, Linux support in Azure, SQL Server support in Linux, Office for Mac OS, and even the recent Visual Studio for Mac, present a vast panorama of opportunities for developers, which extends beyond Windows and its related technologies.

The next diagram was officially published by Microsoft and reviewed in detail by several evangelists, showing the continuous growth in the scope of the Microsoft Development ecosystem:

We saw in this book that .NET has kept evolving since the beginning, and now, it provides a state-of-the-art developing experience no matter what the type of application to be developed is, or whether we are coding for the server or the client:

And, of course, this is just a rough view of the large amount of possibilities now available in the platform, which keeps on growing.

Microsoft Solutions Framework is, as defined by Wikipedia:

So, MSF sits on top of any methodology and recommends what to do in all phases of ALM. It has been around for four versions since its creation, the fourth being the latest revision.

The two models defined by MSF are as follows:

It also defines three disciplines or sets of tasks to be performed and guides to follow in relation to the project's completion. These disciplines are Project Management, Risk Management, and Readiness Management. The official Microsoft documentation on the ALM offers a clear schema of these concepts:

Let's review the most important keys of these models and how they explain and propose well-defined procedures and practices along the ALM.

The Team Model

The Team Model is based on a schema that defines the different roles you can assign to the development team.

Microsoft proposes a new Team Model, as opposed to the classical Hierarchical Model, in order to avoid its typical drawbacks, which summarizes in several aspects: communication overhead, misunderstanding from non-direct contacts, lack of clarity in team roles and responsibilities, detached members, and process overheads.

MSF proposes, in turn, that the Team Model be made up of a team of peers, whose members relate to each other as equals and know clearly which responsibility every member owns and which decisions are based on consensus.

The Team Model gives all members an equally important role in the final success of the project. In this way, many of the unclear responsibilities and vague definitions that are common to other Project Management solutions are suitably addressed.

In the next graphic, you can see how the authors and evangelists of the official Microsoft course on MSF organize these roles around the concept of a Team of Peers:

As you can see in the official schema, there are seven roles—all declared of having equal importance. Note, however, that for small teams, the same person might appear in more than one role.

In summary, the main responsibilities of each role are as follows:

• Product management: Be the contact with the customer, guaranteeing its satisfaction and serving as the voice of the customer for the Program management role.

  The functional areas for this role are:

  • Marketing/corporate communications
  • Business analysis
  • Product planning
• Program management: Be in charge of managing the project's constraints, and be the voice of the team with product management.

  Overall, the functional areas should be:

  • Project management
  • Program management
  • Resource management
  • Process assurance
  • Project quality management
  • Project operations
• Architecture: The goal is to design the solution in a way as per the business goals without forgetting the project's limitations (the budget, schedule, and so on).

  The functional areas of this role are mainly these two:

  • Solution architecture
  • Technical architecture
• Development: Generate code, agreeing with the project specifications, style indications, schedule milestones, and so on.

  The functional areas in this case as follows:

  • Solution development
  • Technology consulting
• Testing: This is to take care of testing when all the issues are correctly addressed.

  In general, four aspects of testing are considered critical (in different scenarios):

  • Regression testing
  • Functional testing
  • Usability testing
  • System testing
• User experience: This is understood as another form of testing and should improve the user experience and performance.

  Here, the goals are closer to the user interaction:

  • Accessibility
  • Internationalization
  • Technical support communications
  • Training
  • Usability
  • User interface design
• Release operations: All operations require satisfactory installation, plus giving hints to the team with respect to future releases.

  In this final phase, the functional tasks are mainly as follows:

  • Accessibility
  • Internationalization
  • Technical support communications
  • Training
  • Usability
  • User interface design

The way the Team Model is established, however, makes some roles incompatible. This depends on the type of responsibilities that a role owns because some of them are considered opposite in nature. The following graphic shows this situation in a table:

This is the case, for instance, with Program Management because the type of relations you carry on is, by nature, incompatible with Product Management (mainly responsible for the team). The most irreconcilable of all roles is the developer, which is—basically—incompatible with any other.

In brief, the authors of MSF define project governance as the set of tools, guides, and techniques, which provide enough oversight, process guidance, and rigor to efficiently and effectively use project resources and deliver a solution. All this happens while handling trade-off patronage decisions and balancing adherence to a set of potentially changing project constraints.

It deals with the process of building the application, and it's traditionally divided into five or six phases depending on the model to be used. In the latest version (4.0), the schema presented by the Microsoft documentation is as follows:

As you see, five phases are considered: Envision, Plan, Build, Stabilize, and Deploy. The transition from one phase to another takes place when you hit a milestone that assumes the existence of a set of deliverables approved by all members of the team.

The main goals of these steps are as follows:

The Risk Model explains how to deal with security along all the previous phases and how to take security into consideration from the very beginning of the application's life cycle. Some theoreticians prefer to include it in the process model itself, as we saw in the diagram at the beginning of this chapter.

We are going to cover security in more depth in Chapter 11, Security, (based on the OAuth 2.0 standard), so it is not the goal to discuss these techniques in depth here, but I would like to review the principles on which the Risk Model is based.

The MSF Risk Management discipline makes a distinction between risks and issues (or problems that already exist or known problems). Thus, it defines a type of risk management that proactively identifies, analyzes, and addresses risks in order to improve the probability of success.

The strategy is to anticipate rather than react to problems, so the team should prepare for problem resolutions before problems occur in order to be able to react proactively and directly to the root causes, not only to symptoms.

The official documentation schematizes risk management in the following graphic:

As you can see, the first step is identifying and stating a given risk. It follows an analysis and prioritization of the problem to be resolved, which goes along with a mitigation plan and schedule.