Five principles of application lifecycle management. The concept of the application lifecycle management methodology - ALM (Application Lifecycle Management)

Control life cycle applications (Application Lifecycle Management, ALM) are developing rapidly. This is a promising approach to improving the software development process. However, the "traditional" ALM process is not able to reach its full profit potential for the organization. Why? Because vendors are aggressively pushing limited end-to-end solutions for ALM that aim to tie customers to closed technology platforms. Customers soon find that these solutions do not integrate with their existing development processes, tools and platforms. Unfortunately, this leaves development teams alone with fragmented processes and a mess of ALM data, which in turn prevents them from fully realizing the capabilities of ALM.

A new approach is needed to solve this problem. An approach that allows customers to create software using a mixed development environment. Borland's Open ALM solutions enable organizations to leverage their existing development resources and tools. This will help achieve transparency, control and discipline throughout the software development cycle. Customers can now benefit from an optimized ALM platform and a single, manageable and measurable software development process.

Predictable Software Development: Mission Impossible?

Software development is essentially a complex undertaking. Creation of a software product with sufficiently clearly defined characteristics, performed with acceptable quality, within the allotted budget and on time, requires constant coordination of a large number of actions between numerous specialists.

The complexity of managing and tracking software projects increases when organizations decide to use distributed development models (for example, offshore programming or the use of temporary employees and subcontractors). As a result, project failure or termination is becoming ubiquitous. Going beyond planned costs, missed schedules, poor quality, and poor reliability have become the norm in the software industry. Accordingly, more and more intelligent approaches are being demanded from software development organizations. They must adopt well-managed, structured and process-oriented approaches that follow the steps of more traditional engineering disciplines. one

With increasing standardization and the use of enterprise development platforms, the challenges facing the industry have become less technical in nature. The ability to generate a stable and predictable profit from software development has become a significant priority for many professionals in the field information technologies (IT). They need to be confident that their teams will be effective in creating software. With these considerations in mind, Borland has developed platforms for ALM. They are designed to solve the problem of stability and predictability of the software development process.

1 Key industry trends such as the accelerated adoption of the CMM / CMMI process improvement framework and the increased use of third-party development models are closely related to this apparent transformation of the software industry.

The emergence of ALM

As the application development industry responds to the need for predictable software development, it has focused its efforts on more than tools for the individual developer. Manufacturers have expanded their offerings and integrated both existing and new capabilities into their products. Their solutions now perform tasks associated with other roles in the software development process. These product suites, often marketed and marketed as collaborative development platforms, ushered in Application Lifecycle Management (ALM) technology. It has become a new category in the market and a separate discipline in software development. ALM platforms are specifically designed to address the challenges of increasing the predictability and integrity of the software development process. They address these challenges by providing integration and automation for each major role that participates in the process and automating a number of functions.

Measurability	Ability to define systems of measures to assess quality, productivity, progress and risk.
	Analyze these metrics and generate reports as the project progresses.

Agreement	Alignment of business specialization and IT priorities.
	Alignment of project results with end-user expectations.

Discipline	Compliance of definition, deployment and tracking with software processes.
	Increasing the severity of the process of changes in management and predicting their consequences.

These capabilities enable IT leaders to balance and prioritize their software project portfolios. They can achieve a higher level of management of their teams and much more transparency in the implementation of projects. ALM can also help executives gain much more control over the software development process. This provides better opportunities for corporate governance and helps the organization to demonstrate compliance with various rules and regulations.

ALM Industry

Initially, one of the few innovators who understood the importance of the ALM trend and changed their product launch strategies towards explicit support for it were Borlandand IBM Rational... In response to clear opportunities, other companies have joined the winning ALM concept: Microsoft, IBM Rational / Telelogic, Mercury and Serena. ALM today is an established trend and growing industry recognized by analysts. ALM vendors provide a variety of tools and technologies to support the software development process. These tools go well beyond traditional productivity tools for an individual developer. They are aimed at providing methodologies and tools focused on teamwork to create software. To create a viable ALM solution, vendors must address the needs of the “extended” software development group and include roles in their products that are involved in the broader process.

For the needs of managers, there are project portfolio-level dashboards that cover important project metrics: risk, progress and quality.

For the needs of project managers, tools are provided for planning and controlling the project, analyzing possible alternatives and allocating resources.

For the needs of analysts, tools are provided for defining requirements, interacting with end users and other stakeholders of the project. This level also provides tools for managing requirements throughout the project life cycle, including subsequent changes.

For the needs of architects, there are tools for visual modeling of various aspects of the application (components, data, process), as well as tools for describing design patterns and corporate architecture.

Various programming environments and code-level quality assurance tools (such as runtime profilers, unit testing and automated code auditing) are provided for developers' needs.

For the needs of quality engineers, there are tools for creating and managing tests, for regression and functional testing, as well as tools for automated performance testing.

A collective infrastructure serves to solve common problems of the whole group. It provides tools for collaboration, process management, change management, and version control.

For the needs of managers of the software development process, there are tools for modeling and applying a set of corporate technology standards.

For the needs of end users and other stakeholders in the organization, tools are provided to automate requirements management. They are also provided with opportunities to exchange information on requirements, report noticed defects and track the status of questions raised.

ALM technology is widely recognized as a major step forward in the development of the application development industry and its customers. Interestingly, the latest "Chaos report" from the Standish Group shows that the number of failed software projects has fallen in half over the past decade. This improvement can be partially attributed to ALM as well. However, a deeper study of customer needs reveals that while ALM has clear benefits, it is still difficult to realize its full potential. To do this, you need to change the fundamental approach that is used to integrate the processes and tools involved in the software life cycle.

ALM's business potential is largely unrealized

To better understand why current solutions are making it difficult to fully unleash ALM's business capabilities, let's take a closer look at typical software development and operating environments. We will examine how the software is produced and deployed in terms of processes, development tools, and work platforms. Ultimately, this discussion explains why software production remains one of the last business processes that fails - let alone automation - consistently and predictably.

The corporate IT environment: the problem of heterogeneity

The rise of the Internet and its proliferation as the primary platform for commerce has brought about significant changes in conventional IT organizations. This was also facilitated by the forced full time job in an environment of scarcity of resources and high demands on flexibility. The problem with these changes has to do with architectural evolution. It aims to improve IT responsiveness and service levels and efficiency by moving from legacy technologies to new, modern application platforms. These are the key areas of this evolution.

Migrate from monolithic mainframe specialized applications to new development tools for enterprise distributed platforms, namely J2EE and .NET.

Migrate from packaged enterprise applications built on legacy architectures to process and composite application runtimes such as SAP NetWeaver and Oracle Fusion.

Use of specialized platforms for specific needs. These are, for example, scripting languages \u200b\u200bfor web applications using databases (PHP, Ruby, etc.), or platforms for developing applications with a variety of Internet and multimedia functions (for example, Adobe® Flash® / Flex ™).

Each of these technologies is associated with specific application development tools (often offered by various vendors). These tools cover analysis, design, coding, quality control, version control, and configuration management.

It is reasonable to assume, especially for midsize and large corporations, that for the foreseeable future, every enterprise IT environment will include at least three of the listed platforms for deployment: mainframe, distributed environment (J2EE or .NET), and business automation system. -processes (SAP or Oracle). It also appears (and is becoming increasingly apparent) that some organizations are deploying software to both the J2EE and .NET platforms. 2

Conflicting programs

It is interesting to note that for obvious reasons, some IT vendors are trying to influence the heterogeneous nature of the enterprise IT environment as much as possible. These vendors seek to take over the entire organization of the IT environment by pushing complete, lifelong solutions to market. They contain software development tools, an application environment, and tools for managing networks and systems. Major manufacturers also include an operating system or even hardware in their solutions. It goes without saying that such solutions also involve a significant component of professional services.

Despite this massive push for all-encompassing solutions from a single source, the reality is that for many clients, this approach just doesn't work. Such organizations increase heterogeneity at all levels. Therefore, they have a set of different priorities that make certain goals important for the customer (not the supplier).

Maximizing competitiveness. Organizations trying to provide the best product or service usually choose the best platform and development tool from a project perspective. This approach helps them achieve the benefits that each platform offers for specific end users. This often happens in separate projects, but it can also happen in the same project. This ultimately leads to "hybrid" applications that span multiple technology domains. Here are some relevant examples.

o Composite applications or services, which include the mainframe, packaged applications, and self-developed distributed applications.

o J2EE / .NET hybrids that leverage the client-side capabilities and user interface of .NET. On the server side, they leverage the scalability, manageability, and security of J2EE technology. This architectural pattern is especially common in the financial vertical. It is used for high-performance trading platforms as Windows is the de facto desktop standard on Wall Street.

o Flash / J2EE hybrids. They combine the power of Adobe Flash as a platform for streaming video and rich Internet applications with the benefits of J2EE technology for servers. This allows for high scalability and a rich multimedia interface.

Reduced development costs. Organizations are trying to reduce software development and deployment costs by combining both open source and proprietary tools and software. In this regard, it is worth mentioning the growing popularity of the LAMP suite (Linux, Apache, MySQL, PHP) and its increasing use in organizations.

Reduced time to market for products. Organizations may prefer certain development tools because of the specific job benefits they offer. This has the potential to significantly reduce time to market for products.

Effective use of the investments already made. Any “destroy and replace” approach faces significant obstacles. This is due to the fact that most organizations do not want to give up significant investments in old programs and tools.

Risk reduction. Several vendors in the IT industry provide custom native support for their platforms. This is seen as a risk in the eyes of their customers. Tying a particular IT vendor to the platform can lead to significant business risk, especially if that vendor is (or will become) a competitor.

2 Key industry trends such as the accelerated adoption of the CMM / CMMI process improvement framework and the increased use of third-party development models are closely related to this apparent transformation of the software industry. IDC Insight's J2EE and .NET Usage Report by Steve McClure states the following. 10.4% of current .NET users expect to use J2EE / J2ME over the next 12 months; 11.9% of J2EE / J2ME users expect to be involved in .NET development within the next 12 months.

IT Heterogeneity: The Biggest Challenge for ALM

In short, many organizations in the IT industry view heterogeneity as the only alternative, as there are many business benefits associated with it. Very often, development teams use a variety of tools that are not designed to work together. There is no single vendor who supplies the tools for all the necessary actions in the context of one software project. Moreover, there is no single vendor that can fully cover the three main domains: legacy system support and modernization, packaged application extension and customization, and new distributed application development. Therefore, it is very likely that organizations will continue to use disparate development tools within the same project and across different technology domains. Because of this, the biggest challenge in implementing ALM is the heterogeneity of development tools. As a reminder, ALM strives to achieve predictability and integrity in the software manufacturing process through automated measurability, alignment, and discipline. However, in a highly heterogeneous environment, these qualities of the software manufacturing process are much more difficult to achieve.

Because measurability requires the collection of metric information from various application development tools and repositories, there is no generally accepted standard for such collection of data. Since there is no common information schema for all the tools involved in the process, it also becomes necessary to "normalize" the collected metrics and somehow compare them in the context of certain projects.

Alignment requires tracking actions and outcomes throughout the process, from IT strategies to deployed modules. This degree of control is very difficult to achieve when resources and process activities are scattered across disparate tools and repositories. There are no standard tools that automatically identify, collect, manage, and use audit information.

The discipline requires the deployment, acceptance, and control of various general processes to manage software production. This becomes much more complex when subprocesses flow as "process islands" among a variety of process tools. There is no standard mechanism for ensuring the choreography of such sub-processes (according to a higher-level process) or for deploying process components for these tools. There is also no single terminology for describing processes in an environment of disparate tools. They all use their own languages \u200b\u200bfor "items", "artifacts", "projects", etc. Another aspect of the discipline requires significant changes in management and impact analysis. These capabilities, however, require the correct implementation of end-to-end operational control. As discussed earlier, end-to-end control is much more difficult to achieve in a heterogeneous development environment.

To address these challenges, organizations that practice ALM often stop developing the numerous specialized point-to-point integrations that typically fill the technology gaps between the various development tools in use. Integrations like these are unreliable. They break when upgrading or changing tools, and they are expensive to build and maintain. In addition, they lead to the emergence of software processes that cannot be easily measured and controlled, and which are inconvenient to manage. Obviously, this approach is unacceptable and unprofitable.

Therefore, most IT organizations present major challenges to ALM vendors. These organizations would like to get more value from ALM, namely significant improvements in the software production process that will give them the stability and predictability they need. However, ALM customers also want more than that.

The ability to use a mixture of work platforms in the most optimal way in terms of their business goals.

Free use of a variety of commercial and open source application development tools optimized for their desired deployment goals.

Free use of a variety of commercial or specialized software development processes that are optimized for the culture, project types, and underlying technology of the organization.

A new approach to ALM is needed to meet this complex set of requirements. An approach that enables customers to fully leverage the power of ALM in a heterogeneous IT environment. Borland recently announced its approach and product strategy called Open ALM. This approach is directly intended to address this problem. It is the only ALM solution designed from the ground up to enable IT organizations to deliver software predictably within their own timeline.

Overcoming heterogeneity: ALM's final frontier

The Open ALM approach implements Borland's established vision and product strategy. This approach represents a significant architectural shift unique to the commercial ALM market. In fact, if fully implemented, Borland Open ALM and its associated applications could provide significant benefits even to customers who do not use any Borland application development tools at all. Borland undoubtedly views its tooling business as vital. The company will continue to develop them and deliver best-in-class tools for an expanded software development team. Borland's tools will gradually evolve to support the Open ALM strategy. This would allow them to participate in the orchestration of Open ALM-based software production. However, the Borland tools could be replaced, if customers see the point, with any product that supports their development requirements. It can be a product from a third-party manufacturer or open source. This level of modularity and flexibility sets Borland's product strategy apart from other ALM vendors, many of whom are trying to take over the entire software supply chain.

Benefits of Open ALM

Open ALM delivers the functionality of ALM while providing an unmatched degree of flexibility at the process, tool and platform levels. Specifically, Open ALM users get the following features.

The freedom to choose any combination of platforms and working environments in the context of one software project or for several different projects at once. In this case, the choice is made based on business priorities or suitability for the project.

The freedom to choose the best development tools for your chosen platforms based on economic considerations, performance gains, and technical suitability.

The freedom to choose or design the development processes that best suit their projects and chosen platforms, and also fit

organizational culture and time-to-market requirements.

For the first time, Open ALM and its supporting tools will provide IT organizations that are deploying heterogeneous application development environments with the following capabilities.

An excellent multidimensional and customizable view of the progress, quality, and risk metrics of projects and portfolios to support project management and process improvement initiatives.

"The Holy Grail": full operational control and life cycle tracking. This will allow for real alignment of business goals and activities during the development process, provide a better link between end-user expectations and project outcomes, and provide better opportunities for project management through accurate and comprehensive impact analysis.

A new level of management of the software development process with the help of automated coordination of the actions of specialists and tools involved in the life cycle, based on processes.

These capabilities provide excellent team efficiency, support quality improvement initiatives, and ease the burden of complying with internal and external regulations. They will be delivered as a set of infrastructure grade components and corporate ALM management tools. In addition, customers can also use Borland's best-in-class integrated tooling for application development and project management. This will enable them to gain value in four main process areas.

Project portfolio management (PPM). Tools and automated processes to manage the development of the entire software strategy, as well as manage the execution of a portfolio of software development projects.

Requirements Definition and Management (RDM).A set of tools and best practices that ensure that project requirements are accurate and complete, can be effectively tracked down to business objectives, and are optimally covered by software tests.

Quality management in the life cycle (Lifecycle Quality Management, LQM).The procedure and tools for managing the definition and measurement of quality at all stages of software development. These tools are designed to detect and prevent quality problems early in a project, when the cost of fixing them is relatively low. Also, quality control teams need to ensure that their tests are complete and based on end-user requirements.

Change Management (CM).Infrastructure and tools to help predict the impact of change. They also help manage resources and lifecycle change activities in both multi-node and single-node models.

Borland Open ALM Solution

As stated earlier, ALM's primary goal is to achieve a predictable and manageable software development process through automated measurability, alignment, and discipline. We have seen that each of the three dimensions of ALM in a heterogeneous application development environment becomes much more difficult to implement and therefore presents a number of specific challenges for ALM users. The Borland Open ALM platform architecture is a set of three solution areas, each specifically designed to address the challenges of one of the major ALM domains. Each area of \u200b\u200bthe Open ALM solution is based on a highly modular and extensible infrastructure layer and is a set of specialized applications. The goal of the infrastructure layer is to enable the Open ALM platform to work with any combination of commercial or open source development tools and processes, regardless of vendor or expected environment technology. The diagram on the next page shows a conceptual diagram of the Borland ALM solution.

Borland Open ALM Solution Architecture

Open Business Intelligence for ALM

Open Business Intelligence for ALM (OBI4ALM) is based on standard infrastructure and applications to increase the measurability of progress, improve the quality of work, or any other special metric of software projects in a heterogeneous application development environment. OBI4ALM provides the infrastructure for discreet, distributed data collection and metric mapping and analysis from any application development tool registered to do so. By extracting predefined metrics from data sources, the OBI4ALM framework brings together disparate information scattered throughout the software development cycle. This consolidation offers great opportunities. For example, you can create an aggregated view of project metrics and define new project metrics that combine multiple lower-level metrics. The OBI4ALM infrastructure uses a data warehouse. This repository contains current and historical information collected from those tools that are involved in various stages of the software development process. It uses a structure that is optimized for querying and analyzing data. OBI4ALM applications can convert collected metrics into information useful for making decisions based on it. This provides support for decision making and early notification of problems.

Real-time data dashboards are customizable KPI views that show trends over time.

Metric-based alerts are custom alerts that are triggered when certain conditions occur (for example, when a trend crosses a certain boundary). Alerts help improve management flexibility for a variety of project issues: slow progress, poor quality, underperformance, or any other problem that can be quantified using metrics.

Decision making tools are analytical tools that use historical information about a project (or multiple projects) to facilitate decision making about project management.

Open process control for ALM

In the final analysis, the process becomes the most important concept that permeates the entire software life cycle. A process is more than sharing information structures with tools that are used by different roles, or providing integration of capabilities at the user interface level. The process has real potential for coordinating the actions of people and systems involved in the process of creating software. At the same time, the process ensures compliance with established policies and quality control of implementation.

Open Process Management for ALM (OPM4ALM) provides infrastructure components and a set of applications that are used to model, deploy, and implement various software processes in a heterogeneous application development environment. OPM4ALM goes much further than providing leadership and assigning tasks to stakeholders. This method also uses a level of process automation that serves as the primary glue for integrating client-side, server-side, and methodology according to the rules captured in the process models. From this point of view, the integration between application development tools is actually provided by lower-level processes. This becomes the fundamental basis for effective teamwork.

The OPM4ALM infrastructure is built on a distributed process core. It provides modeling, customization, deployment, orchestration, and choreography of multiple software development processes in a heterogeneous development environment. An important part of the OPM4ALM infrastructure is the management and definition of process events. Open ALM tools can subscribe to and listen to these events, and be notified when they occur. The Process Engine also provides flexible definition and evaluation of rules. It helps to describe and enforce application development policies.

OPM4ALM applications deliver value from the process infrastructure layer. They provide the following capabilities.

Tools for modeling, tuning, fitting and reusing processes. They enable efficient design of commercial or custom software processes using a feature rich software development model.

Enterprise Processes Console that provides a consolidated bird's eye view. This view contains all the software processes that are deployed in various projects with the participation of disparate development tools.

Process conformity assessment toolbar. It shows deviations of processes and their potential consequencesand also provides reporting capabilities useful for implementing compliance initiatives.

Measurement and reporting based on specific metrics for each process.

Open control for ALM

End-to-end process control supports many of the important benefits of ALM. Some of them are: It is an essential tool for implementing business requirements-driven development, requirements-driven development and testing, and accurate analysis of the impact of changes. Open Traceability for ALM (OT4ALM) provides an infrastructure for creating and classifying links between resources created during software development. Also created flexible schedule links of related resources. It does not matter in what tools these resources are located. This technology also provides a means for navigating the diagram of relationships between resources, as well as for creating optimal queries and for extracting the data that this diagram contains.

OT4ALM provides applications that convert collected control data into information for decision making.

Automated planning, analysis of the impact of changes, accurate cost and budget predictions.

Boundary control - early warning of deviations from defined boundaries (for example, resources that do not meet requirements) and unfulfilled requirements.

Reuse Analyzer - Allows you to reuse entire resource trees (from requirements and models to code and tests) instead of simply reusing code modules.

TraceView - Interactive trace viewers for various projects. This helps you find all the resources of the processes and compare them with other resources.

Common platform infrastructure

The Open ALM infrastructure contains two components that are used across all areas of the solution.

ALM metamodel.A common language for describing software processes, relationships between process resources (controllability) and units of measurement (metrics). The ALM metamodel provides a feature rich conceptual model for the software development domain. This is to describe a standard vocabulary that all Open ALM-compatible tools must understand. This understanding will ensure effective communication within the Open ALM platform.

ALM integration layer.Extensible and embeddable integration engine and SDK. It defines the standard way for ALM tools to work, collect ALM metrics, and create charts for monitoring resources. To support and participate in the ALM platform, the tool must provide a platform plugin that satisfies the standard Open ALM API. You can also use a custom adapter that connects the tool to the rest of the application development environments through processes that are orchestrated by the Open ALM platform.

The road to Open ALM

Over the next 24 months, Borland will continue to expand the infrastructure, applications and tools that make up its Open ALM platform. Borland also intends to complement this product with a wide range of professional services programs designed to accelerate deployment and ensure the success of enterprise Open ALM implementations. Customers can take advantage of some of the benefits of Open ALM today. Organizations looking to improve quality and improve their change and project management will find Borland's current solution very attractive. This solution provides highly automated and integrated support for four important areas of application development processes:

Project Portfolio Management (PPM);

Requirements definition and management (RDM);

Application Lifecycle Management (LQM);

Change Management (CM).

These solutions are delivered through tight integration between Borland products and third-party tools. This gives customers the flexibility they need and dramatically increases their software project management capabilities today.

Why Borland?

Throughout its long history, Borland has consistently worked with its customers to ensure that they create software in the most convenient way. Borland is committed to standards-based development and cross-platform support. She offered IT organizations the flexibility and freedom of choice they need. With the advent of Open ALM, Borland is taking its traditional values \u200b\u200bto a whole new level. This clearly sets the company apart from other ALM vendors and non-profit ALM initiatives.

For the largest ALM vendors, IBM Rational and Microsoft, customer service is hardly their top priority. Both of these companies are continually trying to leverage their development tools to tie customers to their middleware and systems management platforms.

In contrast to this approach, Borland has always insisted on supporting the Java and J2EE standards, and has offered strong and integrated support for the platform, languages \u200b\u200band development tools. Microsoft... Borland continues to explicitly expand Microsoft's ALM solution. Borland has invested heavily in supporting the latest Microsoft technologies. For example, CaliberRM, the first fully integrated requirements management solution for Team System, is recommended by Microsoft to extend the core requirements management functionality provided by tool VSTS. Borland will continue to expand joint work Java and .NET platforms. Additional capabilities are planned, such as UML-to-C # code generation and support for Microsoft Domain Specific Languages \u200b\u200b(Microsoft's alternative to UML replacement).

The move towards open source is also linked to the challenges that heterogeneity poses for ALM. The goal of several Eclipse initiatives (Application Lifecycle Framework (ALF), Corona, and Eclipse Process Framework (EPF)) is similar to that of Borland Open ALM. While Borland understands the motivations behind these projects, the company sees their approach as insufficient. Both ALF and Corona attempt to provide only Open ALM infrastructure components. However, Open ALM is a more holistic approach. This approach also enables customers to derive business value from off-the-shelf infrastructures through a suite of complementary applications. Borland goes further than other ALM vendors in its move towards Open ALM. The company recently expanded its horizons and is looking to expand to additional application development domains. Borland is also looking for the best approach to supporting packaged application development projects on SAP NetWeaver and Oracle Fusion platforms.

Conclusion

Borland is unique in helping ALM users create software in their own terms... The Open ALM approach and product strategy clearly sets Borland apart from other ALM vendors and open source initiatives. Borland is the only major ALM vendor to outright recognize the reality of IT heterogeneity. This company is trying to help ALM users leverage existing tools in their processes, environments, and development tools. Borland's approach to process-driven integration further separates the company from its competitors. This allows Borland to provide transparency, control and order throughout the ALM strategy.

Borland begins building infrastructure, applications, and related development tools for Open ALM. Therefore, for the first time, customers will be able to fully utilize the capabilities of ALM. They will be able to take advantage of a completely cohesive, manageable and measurable software development process.

Analyzing the development of the development tools market over the past 10-15 years, we can note the general trend of a shift in emphasis from the technologies of actually writing programs (which since the beginning of the 90s were marked by the emergence RAD tools - "rapid application development") to the need for an integrated management of the entire lifecycle of applications - ALM (Application Lifecycle Management) .

As the complexity of software projects increases, the requirements for the efficiency of their implementation increase sharply. This is all the more important today, when software developers are involved in almost all aspects of enterprise operations and the number of such specialists is growing. At the same time, research data in this area suggests that the results of at least half of "internal" development projects software tools do not live up to the hopes placed on them. In these conditions, the task of optimizing the entire process of creating software becomes especially urgent, covering all its participants - designers, developers, testers, support services and managers. Application Lifecycle Management (ALM) views the software release process as an ever-repeating cycle of interrelated stages:

· Definition of requirements (Requirements);

· Design and analysis (Design & Analysis);

· Development (Development);

· Testing (Testing);

· Deployment and maintenance (Deployment & Operations).

Each of these stages must be carefully monitored and controlled. A properly organized ALM system allows you to:

· To reduce the time of launching products to the market (developers only have to worry about the compliance of their programs with the formulated requirements)

· Improve the quality while ensuring that the application will meet the needs and expectations of users;

· Increase labor productivity (developers get the opportunity to share best practices in development and implementation);

· Speed \u200b\u200bup development by integrating tools;

· Reduce maintenance costs by constantly maintaining consistency between the application and its project documentation;

· Get \u200b\u200bthe most out of your investment in skills, processes and technology.

Strictly speaking, the very concept of ALM, of course, is not something fundamentally new - this understanding of the problems of software development arose forty years ago, at the dawn of the formation of industrial development methods. However, until relatively recently, the main efforts to automate software development tasks were aimed at creating tools directly for programming as the most time-consuming stage. And only in the 80s, due to the complication of software projects, the situation began to change significantly. At the same time, the urgency of expanding the functionality of development tools (in the broad sense of this term) in two main areas has sharply increased: 1) automation of all other stages of the software life cycle and 2) integration of tools with each other.

Many companies were engaged in these tasks, but the undisputed leader here was the Rational company, which for more than twenty years, since its inception, has specialized in the automation of development processes. software products... At one time, it was she who became one of the pioneers of widespread use visual techniques software design (and practically the author of the UML, which is de facto accepted as the standard in this area), has created a general ALM methodology and a corresponding set of tools. We can say that by the beginning of this century, Rational was the only company that had in its arsenal the full range of products to support ALM (from business design to maintenance), except, however, one class of tools - conventional coding tools. However, in February 2003, it ceased to exist as an independent organization and became a division of the IBM corporation, called IBM Rational.

More recently, Rational was practically the only manufacturer of complex development tools of the ALM class, although there were and are competing tools from other vendors for certain stages of software development. However, a couple of years ago, Borland Corporation publicly announced its intention to compete with it, which has always had a strong position just in the field of traditional application development tools (Delphi, JBuilder, etc.), which are actually the basis of the corporation's ALM complex, the expansion of which went through the acquisition other companies making similar products. This is the fundamental difference between the business models of the two companies, which opens up potential opportunities for real competition. After Rational became part of IBM, Borland positions itself as the only independent provider of an integrated ALM platform today (that is, it does not promote its own operating systems, languages, etc.). In turn, competitors note that Borland has not yet formulated a clear ALM methodology that provides a basis for combining its existing tools.

Another major player in the development tools field is Microsoft. So far, she does not aim to create her own ALM platform; promotion to this direction is only in the framework of cooperation with other suppliers, the same Rational and Borland (both of them became the first participants in the Visual Studio Industry Partner program). At the same time, Microsoft's core development tool, Visual Studio .NET, continually expands its functionality through the use of high-level modeling and project management tools, including integration with Microsoft Visio and Microsoft Project.

It should be noted that today almost all leading companies - developers of technologies and software products (except for those listed above, one can name Oracle, Computer Associates, etc.) have developed technologies for creating software, which were created both on their own and through the purchase of products and technologies created by small, specialized companies. And although, like Microsoft, they have not yet planned to create their own ALM platform, the CASE tools produced by these companies are widely used at certain stages of the software lifecycle.

ALM systems allow you to provide transparency, a clear understanding of the application development process and present it as one of the business processes. However, ALM should not be viewed only as a tool for monitoring and enforcing compliance, analysts warn. These systems are designed not so much for control as for automating the development process and integrating various tools.

The biggest challenge in implementing ALM tools is people's misunderstanding of the development process. Oftentimes, management thinks that ALM can be used to get things done in a well-defined way. However, it's impossible to plan everything in advance. In application development, you often have to go through several iterations at each step, release intermediate versions, and gradually increase the functionality of the application. ALM system should not limit the actions of developers, but facilitate the process.

The IT industry loves to talk about the barriers between IT and the business, but within the IT structure itself, there are many less visible barriers that can stand in the way of an unwary system integrator.

Consider, for example, one of the most controversial and hotly debated topics in IT today - DevOps methodology and everything related to it. As a brief description of all the actions associated with the transfer of the developed application to the IT service for real operation, these words sound harmless enough. But by and large, there is a wall of confusion between the developers of enterprise applications and the specialists who manage the IT infrastructure of the enterprise. Programmers often blame IT for lack of flexibility, and those who manage day-to-day IT operations often blame IT for ignoring the constraints and requirements of the production infrastructure in which the applications they create must run.

This tension is driving a growing interest in Application Lifecycle Management (ALM) technology, which is a set of management tools designed to provide programmers and IT staff with a clearer understanding of the application being developed and the infrastructure in which the application must run. ... The main idea is that facilitating collaboration between developers and IT professionals will lead to more efficient functioning of the entire corporate information environment. The problem is that the implementation of ALM has little chance in a situation where two parties, the cooperation between which is necessary to ensure the success of the project, begin to shift responsibility for the difficulties that arise.

To successfully implement ALM methodology, the system integrator must rise above the level of mutual accusations in the IT department. According to Gina Poole, vice president of marketing for IBM Rational Software, this means finding and hiring a CIO or CFO who can understand how much money a customer is losing due to a lack of coordination across the IT department. Fixing bugs in an application late in the development project means extremely high costs. If the need for such a fix is \u200b\u200bcaused by the developer's earlier assumptions about the environment in which the application will function, and these assumptions ultimately turn out to be incorrect, then the cost of the entire project increases significantly, or the customer will be forced to modernize his infrastructure accordingly.

Of course, it can take a significant amount of money to resolve such conflicts in an organization's IT infrastructure. However, the only ultimate goal of this work should be to create and implement a set of management technologies that would allow programmers and IT operations to stop interfering with each other's work. The more time programmers spend discussing collaboration with IT professionals, the less time they have directly on development. The more applications are created, the more developed infrastructure will be needed and this is of course good news for resellers.

Overall, the DevOps debate is definitely beneficial for resellers and integrators. The problem is not to get caught up in internal conflicts associated with the desire to carry out too many IT projects in parallel. If the customer does not accept the very concept of ALM, this is actually a very good indicator of his lack of maturity and weak competence in IT management. This in itself suggests that the reseller is better off staying away from such a customer, since the chances are high that such a customer will bring much more problems than profit.

It is known that many users (and, to be honest, some IT specialists), when talking about software development, mean first of all the creation and debugging of application code. There was a time when such ideas turned out to be close enough to the truth. But modern application development consists not only and not so much of writing code as of other processes, both immediately preceding programming and following it. Actually, we will talk about them further.

Application Development Life Cycle: Dreams and Reality

it’s not a secret that many commercially successful products both in Russia and abroad were implemented using only application development tools, and even the data were often designed on paper. It will not be an exaggeration to say that of all the possible tools for creating software in Russia (and in many European countries), application development tools are now popular, and to a somewhat lesser extent - data design tools (first of all, this concerns projects with a small budget and tight terms of implementation). All project documentation, from the technical assignment to the user's manual, is created using text editors, and the fact that some part of it is the source information for the programmer only means that he simply reads it. And this despite the fact that, on the one hand, requirements management tools, business process modeling, application testing tools, project management tools, and even generation tools project documentation have existed for a long time, but on the other hand, any project manager, naturally, wants to make life easier for himself and for the rest of the performers.

What is the reason for the distrust of many project managers in the tools that allow automating many stages of the work of the teams they lead? In my opinion, there are several reasons for this. The first one is that the tools used by the company very often do not integrate well with each other. Let's consider a typical example: Rational Rose is used for modeling, Delphi Professional is used for coding, CA AllFusion Modeling Suite is used for data design; integration tools for these products are either completely absent for a given combination of their versions, or do not work correctly with the Russian language, or are simply not purchased. As a result, use-case diagrams and other models created with Rose become nothing more than pictures in the design documentation, and the data model mainly serves as a source of answers to questions like: "Why is this field in that table at all?" And even such simple parts of the application as the Russian equivalents of the names of the database fields are written by project participants at least three times: once when documenting the data model or application, the second time when writing the user interface code, and the third time when creating a help file. and user manuals.

The second, no less serious reason for mistrust of software lifecycle support tools is that, again, due to the absence or poor functionality of the integration tools for such products, in many cases it may not be possible to continuously synchronize all parts of the project with each other: process models , data models, application code, database structure. It is clear that a project that implements the classic scheme of a waterfall (Fig. 1), in which requirements are first formulated, then modeling and design is carried out, then development and, finally, implementation (about this scheme and other methodologies for project implementation can be read in the series of reviews by Lilia Hough, published in our magazine) is more a dream than a reality - while the code is being written, the customer will have time to change some of the processes or wish for additional functionality. As a result of project execution, an application is often obtained that is very far from what was described in the terms of reference, and a database that has little in common with the original model, and the synchronization of all this with each other for the purpose of documentation and transfer to the customer turns into a rather laborious task.

The third reason why software lifecycle support is not used everywhere where it could be useful is that it is extremely limited in choice. Mainly two product lines are actively promoted in the Russian market: IBM / Rational tools and Computer Associates tools (mainly the AllFusion Modeling Suite product line), which are largely focused at the moment on certain types of modeling, and not on the constant process of code synchronization, databases and models.

There is one more reason that can be attributed to the category of psychological factors: there are developers who do not at all strive to fully formalize and document their applications - after all, in this case, they become irreplaceable and valuable employees, and a person who is forced to understand after the dismissal of such a developer in his code, or just the accompanying product, will feel like a complete idiot for a very long time. Such developers, of course, are by no means in the majority, nevertheless, I know at least five company executives, whom such ex-employees have spoiled a lot of blood.

Of course, many project managers, especially projects with a small budget and limited deadlines, would like to have a tool with which they could formulate requirements for the software product being developed ... and as a result, get a ready-made distribution of a working application. This, of course, is only an ideal, which so far one can only dream of. But if you descend from heaven to earth, then you can formulate more specific wishes, namely:

1. Requirements management tools should simplify the creation of the application model and data model.

2. Based on these models, a significant part of the code should be generated (preferably not only client, but also server code).

3. A significant part of the documentation should be generated automatically, and in the language of the country for which this application is intended.

4. When you create the application code in the models, automatic changes should occur, and when the model is changed, the code should be automatically generated.

5. Code written by hand should not disappear when the model changes.

6. The emergence of a new customer requirement should not cause serious problems associated with changes in models, code, database and documentation; however, all changes must be made synchronously.

7. Version control tools for all of the above should be convenient in terms of finding and tracking changes.

8. Finally, all this data (requirements, code, models, documentation) should be available to project participants to the extent that they need them to fulfill their responsibilities - no more and no less.

In other words, the application development cycle should allow for iterative collaborative development without the added cost of changing customer requirements or how they are implemented.

I will not assure you that all these wishes are absolutely impossible to fulfill with the help of IBM / Rational or CA tools - technologies develop, new products appear, and what was impossible today will become available tomorrow. But, as practice shows, the integration of these tools with the most popular development tools, unfortunately, is still far from being as ideal as it might seem at first glance.

Borland products from a project manager's perspective

borland is one of the most popular vendors of development tools, with a well-deserved love of developers for twenty years. Until recently, this company offered mainly a wide range of tools intended directly for developers of application code - Delphi, JBuilder, C ++ Builder, Kylix (we have written about all of these products in our magazine several times). However, a company's success in the market is largely determined by how well it follows trends in its development and how much it understands the needs of those who are consumers of its products (in this case, companies and departments that specialize in application development).

This is why Borland's development strategy for development tools now includes support for the full Application Lifecycle Management (ALM), which includes requirements definition, design, development, testing, implementation and maintenance of applications. This is evidenced by last year's acquisition by Borland of a number of companies - BoldSoft MDE Aktiebolag (a leading provider of the latest application development technology Model Driven Architecture), Starbase (a provider of software configuration management tools), TogetherSoft Corporation (a provider of software design solutions). Since the acquisition of these companies, a lot of work has been done in terms of integrating these products with each other. As a result, these products are already meeting the needs of project managers for the ability to organize iterative collaborative development. Below we will discuss what Borland is currently offering to executives and other contributors to software development projects (many of the products and integration technologies described below were presented by the company at the developer conferences held in November in San Jose, Amsterdam and Moscow) ...

Requirements management

Requirements management is one of the most important parts of the development process. Without formulated requirements, as a rule, it is practically impossible either to organize work on a project normally, or to understand whether the customer really wanted to get exactly what was implemented.

According to analysts, at least 30% of the project budget is spent on what is called reworking the application (and I personally think that this figure is greatly underestimated). Moreover, more than 80% of this work is associated with incorrectly or inaccurately formulated requirements, and fixing such defects is usually quite expensive. And the extent to which customers love to change requirements when the application is almost ready is probably known to all project managers ... It is for this reason that requirements management should be given the utmost attention.

For requirements management, Borland's arsenal includes Borland CaliberRM, which is essentially a platform for automating the requirements management process and providing change tracking (Figure 2).

CaliberRM integrates with many development tools from Borland and other manufacturers (for example, Microsoft), up to embedding a list of requirements in the development environment and generating code snippets when you drag a requirement icon into the code editor. In addition, you can create your own solutions based on it - for this there is a special set of CaliberRM SDK tools.

Note that this product is used to manage requirements not only for software, but also for other products. For example, there are cases of its successful application in the automotive industry to manage the requirements for various vehicle components (including Jaguar vehicles). In addition, according to Jon Harrison, product line manager for JBuilder, the use of CaliberRM to create Borland JBuilderX has greatly simplified the product development process.

And finally, the presence of a convenient requirements management tool greatly simplifies the creation of project documentation, and not only in early stages of the project, but also on all subsequent ones.

Application and data design

Design is an equally important part of creating an application and should be based on the stated requirements. The design result is the model used by programmers at the stage of code creation.

For application and data design, Borland offers Borland Together (Figure 3), an application analysis and design platform that integrates with a variety of Borland and non-Borland development tools (Microsoft in particular). The specified product enables modeling and design of applications and data; at the same time, the degree of its integration with development tools at the moment is such that changes in the data model lead to an automatic change in the application code, just as changes in the code lead to a change in the models ( this technology integration of modeling tools and development tools is called LiveSource).

Borland Together can be used as a tool for integrating requirements management and modeling tasks with development and testing tasks, and allows you to understand what the product requirements should be.

Generating application code

Application code writing is an area that Borland has specialized in for over 20 years. Borland today produces development tools for Windows, Linux, Solaris, Microsoft .NET, and a range of mobile platforms. We have already written about the development tools of this company many times, and we will not repeat ourselves in this article. We only note that the latest versions of the development tools of this company (Borland C # Builder, Borland C ++ BuilderX, Borland JBuilderX), as well as the soon-expected new version of one of the most popular development tools in our country, Borland Delphi 8 for Microsoft .NET Framework allow for tight integration of Together modeling tools and CaliberRM requirements management tools with their development environments. We will definitely talk about Delphi 8 in a separate article in the next issue of our magazine.

Testing and optimization

Testing is an absolutely essential part of building quality software. It is at this stage that it is checked whether the application meets the formulated requirements for it, and the corresponding changes are made to the application code (and often to the model and the databases). The testing phase typically requires application performance analytics and optimization tools, and Borland Optimizeit Profiler is used for this purpose. Today, this product, along with this, is integrated into the development environment of the latest versions of Borland development tools, as well as the Microsoft Visual Studio .NET environment (Fig. 4).

Implementation

Software implementation is one of the most important components of a project's success. It should be carried out in such a way that at the stage of trial operation of the product, changes can be made to it without serious costs and losses, it is easy to increase the number of users without sacrificing reliability. Because applications are currently deployed with companies using different technologies and platforms and using a certain number of existing applications, the ability to integrate a new application with legacy systems can be important during implementation. For this purpose, Borland offers a number of cross-platform integration technologies (such as Borland Janeva, which allow .NET applications to be integrated with CORBA and J2EE-based applications).

Change management

Change management is performed at all stages of application creation. From Borland's perspective, this is the most important part of the project - after all, changes can occur in requirements, and in code, and in models. It is difficult to manage a project without tracking changes - the project manager must be aware of what exactly is happening at this stage and what has already been implemented in the project, otherwise he risks not completing the project on time.

To solve this problem, you can use Borland StarTeam (Figure 5) - a scalable software configuration management tool that stores all the necessary data in a centralized repository and optimizes the interaction of employees responsible for various tasks. This product provides the project team with a variety of tools for publishing requirements, managing tasks, scheduling, working, discussing changes, version control, and organizing workflow.

The features of this product are tight integration with other Borland products, support for distributed development teams interacting over the Internet, the presence of several types of client interfaces (including the Web interface and the Windows interface), support for many platforms and operating systems, the presence of the StarTeam Software Development Kit (SDK), which is application programming interfaces for creating solutions based on StarTeam, data protection tools on the client and server side, tools for accessing the Merant PVCS Version Manager and Microsoft Visual SourceSafe repositories, tools for integrating with Microsoft Project, tools for visual presentation of data, creation reports and decision support.

Instead of a conclusion

What does the appearance on the Russian market of the above set of products from a well-known manufacturer, whose development tools are widely used in a wide variety of projects, mean? At a minimum, the fact that today we will be able to get not just a set of tools for various project participants, but also an integrated platform for implementing the entire development life cycle - from the definition of requirements to implementation and maintenance (Fig. 6). At the same time, this platform, in contrast to competing product sets, will guarantee support for all the most popular development tools and will allow integrating its components into them at the level of complete code synchronization with models, requirements, and changes. And hopefully, project managers will breathe a sigh of relief, relieving themselves and their employees of many tedious and routine tasks ...

It might be useful to read: