Sparx Systems

Requirements are fundamentally important as they are about building the right system.

Yet the failure of requirements is the primary cause of project failure.

How many times do we forget passwords AND user names? This is a clear example of the risk associated with the reliability of the human memory and associated human error. Let's consider the management of the myriad detail accumulated throughout the requirements planning process and the steps of Eliciting, Documenting, Analysing and Communicating. Oh, and let's not forget Tracking, Validating and Verifying!

So spare a thought for the Business Analyst, whose whole focus is on capturing requirements, to ensure successful project outcomes. Or to put it another way, the task of translating the needs, wants and expectations, of all user stakeholders, into technical language for the developers and others, to ensure that they - the users - are are going to get the functionality, that they need, want and expect from a system. This is not a petty task and it can take months. Meanwhile, there is the probability, due to complexity, that not all of the requirements are going to be addressed because of a number of factors, not least, their having been lost or forgotten.

However if effectively managed, requirements identification and supporting traceability improves the overall project outcome, simply because time will be saved, less money will be spent, and most importantly, the customer will be happier.

The Requirements management process has seen much change in the past 20 years and two of the most obvious are the involvement of the customer in all phases of the process and that the requirements process itself is now dynamically linked into an agile culture of continuous integration and delivery. The increase in software defined business, is driving the growth and importance of application delivery within encumbent enterprise and with ever more startups disrupting their industries, enterprise needs greater levels of automation to compete and to deliver quality, quicker than competitors.

In the past Requirements were captured in hand written paper documents, which in time, were augmented with spreadsheets and word documents. The rigour of the process left space for improvement. Today, requirements associated material is held in a central repository and updates are visible to all stakeholders. Enterprise Architect can capture all of the different information that records requirements information, be it from Word, Excel, Visio, handwritten notes, video or audio.

In the past Requirements was an isolated process that had built in “wait” or handover periods before being consumed by the other phases of the project life cycle. Today these gaps are closed with automation and requirements are integrated across the development life cycle, with many other functions. The end result is less time to delivery.

Organisational cultures of resistance to change, identified by a bulwark of divisional and departmental silos and a reluctance to co-operate, increased the risk of failure for the change process. Today, technology based collaborative platforms are increasingly being adopted as they are inclusive, breaking open silos, empowering stakeholders and drawing them together.

The progress of development projects lacked transparency for most key stakeholders, right to the point when business took delivery. Whatever visibility the stakeholders had, was gathered from assumptions, rather than from objective data. Today, key stakeholders form an integral part of the development team and have access to progress charts and dashboard metrics.

In the past, the management of shareholder supported organisations held tightly to the overarching goal of ensuring change was minimised or avoided, so as to maintain the value of their shares. Today the digital imperative, as opposed to the business imperative, says be prepared to change, or risk oblivion.

These examples are a reflection of the changes in the Requirements Management process, which in the development model of today, supports iterative requirements gathering and continuous delivery of software. It has become an Agile practice approach, being adopted to address the challenge of digital transformation. This collaborative, iteration based business lifecycle, between requirements and stakeholders, has given rise to DevOps, a strategy for managing continuous change.

Enterprise Architect is unique in its ability to support Requirements throughout the development lifecycle and to deliver the benefits of the Agile practice approach. Requirements can be defined in the model, or imported from other tools including Visio.

Recently, through agreement with IIBA, Sparx Systems is in the process of developing the Enterprise Architect Guide to BABOK Implementation. Through the power of this collaborative, visual modeling platform, the extension provides the Business Analyst with a fully augmented BABOK user experience.

On March 29, 2017, the public Beta launch of Tools & Techniques for BABOK Guide v3 was announced - please visit the Sparx Systems website for more details.

Veteran Project Manager and user of Enterprise Architect in 100+ projects since 2001, Herminio Lourenço has recently published some illuminating articles regarding toolsets for systems development.

This article was orginally published on Mr. Lourenço's LinkedIn profile on November 22nd, reprinted on the Sparx Systems Community site with permission from the author.

Firstly, tool is something that enables, facilitates, gives bigger productivity to one or more activities. The tool works for us. We dedicate some effort and as a result we have a lot of work done. That said, I will suggest a set of tools to give productivity and quality to systems development.

A concept being introduced is the ALM: Application Lifecycle Management. According to Wikipedia, is the marriage between business management with software engineering, which became viable thanks to tools that facilitate and integrate processes such as requirements analysis, architectural modeling, code development, change management, test management and managing of versions of products accomplished. Each one of these processes is part of a stage of a software life cycle.

This can be achieved through a framework, as the Jazz from IBM or Microsoft TFS, among other options, which integrates specialized tools to manage: requirements; code repository; construction; architecture and coding; tests and quality, versions and components.

In that effort to implement multiple tools, the company may have to invest hundreds of thousands of dollars and dozens of months in software settings and in training.One of the options that brings fastest return in productivity and quality is the Enterprise Architect (EA) from Sparx Systems. With this tool you can manage and analyze requirements, with automatic control of traceability of the requirements until the code and vice versa, besides producing the models of analysis and design and code as much classes as databases.

Support for testing and integration with configuration and release managers practically complete the required skills. Furthermore, EA has tools like KANBAN and task planning that help you plan and control the progress of work.

Other tools like Jira and Subversion can help complete the spectrum.

Of course that the biggest suppliers will try to convince IT managers that this solution may not be as good and complete as their offers, but this solution has more than 300,000 users developers across the planet. Theirs might have a few hundred followers. I will not discuss what is the perfect solution because it doesn't exist.

The adoption of a good, solid and tested set of tools is crucial to obtain the desired productivity in systems development.

Application Lifecycle Management (ALM) can move IT and Business to a position of congruency and shift IT from application thinking to process (and service) thinking and in Business, from service to IT. The gulf between Business and IT exists on a relationship from a time past, when there was little contact between the two parties following a commission from Business to IT for services and/or products.

Before the availability of ALM, the window on the progress of development projects lacked transparency for most managers, right to the point when business took delivery. Whatever visibility the managers had, was gathered from assumptions rather than from objective data.

Sparx Systems attended the Gartner Enterprise Architecture Summit in National Harbor during May 2016 where Enterprise Architecture was reviewed as a “catalyst for Digital Tranformation.” and two “big” challenges were identified, as the transformation moves forward. These were, managing the connections within complex ecosystems of communications, partners, platforms, services and technologies and working with New Development methodologies such as Agile, DevOps and Continuous Delivery.

ALM makes IT development visible to upper management and reinforces the requirements of Business to demonstrate Governance, Risk Management and Compliance. On a competitive level it assists in the reduction of development costs, increases innovation and effectively supports change management. As a business process for the management of end to end software development ALM promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales.

Between IT and Business, ALM creates and supports a bridge which embodies a set of processes and methods, including software development, operations, and services, to enhance communication and collaboration between departments. It also aligns the business, development and operations capabilities of the organization, by providing the ability to integrate different tools used and the activities performed within each.

While this establishes a culture of more frequent software builds, tests and releases, the pressure to manage application delivery is growing ,as is the complexity. The need to co-ordinate and automate the process of delivering these projects, with collaborative planning and reporting activities has become critical. Sparx Systems recognises that this requirement makes ALM processes essential to the delivery of worlds best development practices.

"DevOps is a culture that supports improvements
in the software development lifecycle through
automation, best practice and collaboration."

Tight coupling of the stages of the application lifecycle is a key to increasing productivity in application development and establishing traceability and accountability across multiple processes, locations and tool types, in the stages of development and delivery. This completeness of functionality leads to increased quality, reduces time to market and promotes a culture of business agility. By coordinating activity and facilitating communication, ALM provides real time transparency and traceability, proactive change management and error mitigation.

We hear a lot about cultural change in the discussions about DevOps. We also hear a lot about people. Not so much about enabling technology. There is an accepted notion that DevOps is about drawing together people in DEVelopment and people in OPerations with the goal of shortening delivery time through the elimination of constraints that naturally exist between functional silos.

DevOps is a culture that supports improvements in the software development lifecycle through automation, best practice and collaboration. DevOps is about changing culture and the responsibility for this lies with executive management. To realise a cultural change of automation, best practice and collaboration, is to expose the organisation to DevOps benefits,- agility and productivity. As a key enabler of DevOps, Continuous Delivery supports automation of software development, testing and deployment which are in turn supported by agile planning and execution tools.

In an article by Madison Martin, published recently in SD Times, the impact that DevOps and Agile are having on application lifecycle management (ALM). She states that “Those looking to refine their application life cycle are sifting through the marketplace to find the right tool—one that will give their company agile feature functionality and help them move toward a more continuous way of working. A business can no longer look at just the planning and the building of software; they have to monitor every step in between to make sure the software delivered meets the expectations of the user.”

ALM is accepted as the management of end to end software development and as a business process it promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales. Due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

The ALM tools market has seen a continuous evolution over the greater part of the last decade. The change is demonstrated by various benchmarks conducted by Gartner. As recently as July 2016 Gartner has announced their decision to retire “the ADLM MQ and focus on a new MQ for Agile planning and execution tools.” The leading reason cited for this decision is “Shifts in the market due to DevOps.”

Between 2012 and 2013 Gartner blogged that work had begun on the update to the Magic Quadrant for ALM stating “We are subtly shifting our terminology for the market from Application Lifecycle Management to Application Development Lifecycle Management. We feel this is a more accurate depiction of what the tools in this space are focused on.”

In 2008 Gartner published the “Marketscope for Application Lifecycle Management”. This document was described ALM as the practices, processes and tools that aid in the application management lifecycle, specifically the workflow of producing or maintaining an application. This document identified a number of key capabilities that an ALM offering should include. These capabilities have been listed later in this document.

Sparx Systems ALM

In 2015 Sparx Systems was named in the 2015 SD Times 100 for its excellence in the ALM and Development Tools category. When using separate tools in development, there can be a lack of integration between the tools used in each phase of the process and due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

However, when using Enterprise Architect, an integration of all the key features of ALM is provided in an “out of the box” tool set, which uses a single repository as the common data source. Within the integrated Enterprise Architect project workspace, you can view and update artifacts with version control, code review, and continuous integration tools. This is the level of functionality that defines Enterprise Architect as a leading ALM solution.

Key ALM Capabilities

• Requirements definition and management
• Change and configuration management
• Agile project planning
• Work item management
• Quality management, including defect management
• Reporting
• Workflow
• Integration to version management
• Support for wikis and collaboration
• Integration to other ALM tools

This is the first of a series of related articles on DevOps and ALM