Software has changed, end points have changed, even the role of the developer has changed. So, it only makes sense that the way developers and organizations manage the application life cycle would have to change too.

In the beginning, the ALM process was very independent, according to Robert Holler, CEO of VersionOne. “You kind of had your application life-cycle-management capabilities that supported requirement-management tools, design tools, coding tools, test tools, build source, deploy tools and project-management tools,” he said. “At first there was a lot of disintegration. Each one of those tools was completely independent.”

With the ever-increasing demand for better quality, better user experience, faster delivery and advanced technologies, the way in which tooling has worked together has evolved.

“Through the years, tool sets have become integrated,” said Holler. “All those tools are no longer independent tool sets; they are actually integrated tool sets that all work together to help manage the project, the product and the process, all at the same time.”

But it hasn’t just been the tool sets going through an evolution; the entire scope of ALM has changed. Where once testing had a definitive role at the end of the life cycle, or requirements took up a large part of the life cycle, the aspects of the life cycle are now linked together. “The life cycle starts with a business idea and doesn’t end with delivery of some value to a customer, but rather cycles around with feedback back to the business again to say did we actually meet the need,” said Kurt Bittner, Forrester analyst.

– See more at: https://sdtimes.com/rethinking-application-life-cycle-management/#sthash.vLvgc49A.dpuf

It’s that time of year again, when the editors of SD Times emerge from their lab to reveal their latest discovery: The 2014 SD Times 100.

A number of elements need to react in precise ways for an organization to attain its place atop the charts, each carrying a certain weight. First is innovation. To earn a seat at the (periodic) table, companies must demonstrate that their work advances the state of the art of software development. Hand in hand with that is leadership. Did the company show it was an industry leader through a lion’s share of its market, or by contributing more to an open-source project than anyone else? Did it establish leadership through the open exchange of its ideas with others? And finally there is the buzz factor. Was the work widely discussed in the industry? Was the technology considered must-have by those in the know? In short, did the organization have the right chemistry?

Displaying each of these elements in just the right proportions can be the difference between a winning formula or a dud. To determine that, the editors carefully consider each nomination in a process that involves debate, research and, ultimately, selection.

In the periodic table, elements are divided by their properties: noble gases are with noble gases, metals are with metals, and so on. In the SD Times 100, those properties are ALM & Development Tools; APIs, Libraries and Frameworks; Big Data and Business Intelligence; the Cloud, Database and Database Management; DevOps & SCM; Mobile; Quality Assurance & Security; User Experience; and Influencers.

What do you think of the 2014 SD Times 100 solution? Did we overlook any organizations that you feel are worthy of inclusion? Did we miss a leader or […]

By Tieren Zhou – September 24, 2013

View original story

Agile is the most widely accepted and practiced development methodology today. Interestingly, agile has gained its popularity not by replacing other methods, but by fusing with them. Real-world agile project success has proven the future of agile is going be a hybrid agile methodology.

SpecDD is a requirement-centric hybrid agile development methodology. It is designed to provide a single framework to manage both agile and traditional projects within a set of principles.

Requirements in SpecDD are represented with requirement epics, MS Word epics, specs, and document attachments. Specs are the normalized requirement items used to quantify requirements. Identical to Scrum, the development project implementation in SpecDD consists of a set of continuous iterations, with each iteration designed to convert a set of committed items to the working software.

Unlike pure agile, however, SpecDD includes models to represent the requirement and QA testing processes. Requirements are used to populate the product backlog and the development sprint workload. QA test cases are created before, during and after the development iterations. To make the QA testing practice scalable, an independent QA team is recommended to work with agile teams to perform testing within development sprints as well as total regression testing.

What is SpecDD?
SpecDD provides a framework for teams to practice agile, but with guidelines to mix agile functions with traditional project-management best practices.
• Requirements are represented as artifacts above the product backlog. Requirements are retained while product backlog items are consumed to generate the working software.
• Requirements are linked with QA test cases that can be created and improved before, during and after development sprints.
• A development sprint in SpecDD generates two deliverables: the improved working software, […]

By Alex Perec – October 19, 2012

View original story

Application development is no longer about one individual working on a project. Today, application development frequently consists of multiple teams, located across the globe, collaborating on a software project. As more and more organizations implement agile development to varying degrees, it is becoming clear that distributed development is not only a fact of life for many teams, but it is a growing segment of the agile community. This is despite the fact that the very idea of physically distributing teams seems to conflict with agile communication practices. Agile practices rely heavily on face-to-face communication as a replacement for lengthy and often tedious documentation; being geographically separated will, of course, interfere with face-to-face communication.

Risks and Rewards of Team Distribution
So if distributed teams are such an impediment to communication, why risk separating teams at all? There are certainly benefits to a distributed team and obviously these need to be weighed against the hindrances to communication. I’ve found that the top three reasons for distributing are:

• Expanding into global markets may require a local presence in the various locations.
• Access to global talent.
• Reducing cost through offshoring or outsourcing.

If the decision is made to distribute a team and sacrifice communication, we must take steps to make up for it in other ways, with one of the most common ways being to improve the management of requirements and specifications.

Good requirements and specification management does not take place in spreadsheets. You need to invest in a system that can offer your team a high degree of traceability and speed. Nothing slows the adoption of a tool faster than a lagging interface. Other nice features for you to look […]

By SD Times Editorial Board – June 1, 2012

View original story

IRely makes a wise choice with TechExcel’s CustomerWise

By Leonard Klie – June 2012

View original story

An enterprise software provider for the management of commodities from farm to fork, iRely serves organizations that handle the origination, trading, manufacturing, and distribution of commodities. Headquartered in Fort Wayne, Ind., it has about 400 customers in the agribusiness, petroleum, trading, risk management, manufacturing, and retail industries. It has five other offices throughout the United States, one in the United Kingdom, two in India, and one in the Philippines.

The company was receiving, on average, about 1,600 technical support cases a month, but customers had no visibility into where their cases were in the queue and when they could expect them to be resolved. IRely’s own visibility wasn’t much better. Any changes or updates had to go through a complicated manual process with multiple phone calls, interfaces, applications, and departments involved.

So in January 2010, the company decided to replace its homegrown customer service and support system.

CustomerWise helps automate and streamline help desk activities with configurable workflows, process approvals, email integration, project management, integrated knowledge management, and the availability of customer self-service through a customer Web portal.

The system provides a single point of contact for customer requests and submitted incidents and the ability to automate reminders and review the approval of incidents and requests. It can be integrated into most CRM, help desk, defect tracking, and test management applications, and brings together Web, wireless, and client/ server technologies.

By switching to CustomerWise, iRely was able to integrate billing into the primary system and move from monthly to weekly billing. Additionally, the company reduced the number of agents from six to four, gained full visibility into the production […]

By Victoria Reitano – March 30, 2012

View original story

The software development life cycle is like a puzzle: Each piece fits into the other in order to create a complete product. When teams decide to adopt new methodologies, such as agile, or revise their current methodologies to be more agile, it is important to make a road map in order to determine what you’re doing and what you want to be doing, according to experts.

Jeff Amfahr, director of product management at Seapine (an agile application life-cycle management solution provider), said that to begin an agile adoption process, teams should assess what metrics will be used to determine if the transition was successful.

“Establish up front how you’re going to know if the adoption was successful. It could be productivity of the team, less software bugs or more customer satisfaction,” he said, adding that it is most likely the business value gained from adopting agile from adopting these new methodologies.

Amfahr said it is important to start with a team that is interested in agile (or the new methodology you’re interesting in adopting). The project should also be one that lends itself to being measured and can be released quickly, he said.

Alex Perec, senior product manager at TechExcel (a maker of application life-cycle management software), said that, based on his experience on a team transitioning to agile, the adoption process can be quite daunting.

He recommended going agile one piece of the process at a time. He said that being partially agile does not mean you are inefficient, it means you are slowly growing toward maximum efficiency.

For some teams and projects, Perec said it is important to realize that Water-Scrum-Fall […]

By Victoria Reitano – January 24, 2011

View original story

TechExcel next week will release its new DevSuite application life-cycle management solution. DevSuite 8.3 allows developers to log in to the programs in the suite, such as DevSpec, DevPlan, DevTrack, DevTime and DevTest, via a Web-based user interface (DevSuite Web), which provides a single sign-on for all programs in the suite.

By Jennifer deJong – January 19, 2011

View original story

It hasn’t exactly advanced on all fronts, but ALM is inching its way forward, albeit by a circuitous route.

SD Times asked analysts and tool makers how Application Life-cycle Management—the tools and processes designed to track software projects from conception to deployment to retirement—has evolved in the last few years and where it is headed. Three major themes emerged.

First, the central promise of ALM 2.0—better integration between point tools for requirements, coding and testing—never really materialized. Second, tool makers are overwhelmingly positioning their offerings as “Agile ALM.” Second, the term is so pervasive, it’s difficult to separate the “agile” marketing message from actual support for agile practices. What’s more, opinions vary on what “Agile ALM” really means. Third, technologies such as application security and virtualized testing, among others, remain largely outside the ALM process today, even though they are widely recognized to play important roles in how applications are developed and managed.

About that ALM 2.0
The plug-in ALM frameworks designed to let application teams stitch together different tool makers’ offerings without having to code the connections between them did not happen, said Forrester principal analyst David West. These frameworks were a key promise of ALM 2.0, a Forrester Research set of principles that outlined ALM’s future and gained wide backing from ALM tool makers in 2008.

West noted that Eclipse projects such as ALF and Corona, aimed at tool and process integration, have failed. Unless application delivery teams are working in the Microsoft Visual Studio, or Eclipse IDEs, “plug-in support is limited today,” he said.

In the ALM 2.0 era, tool makers were talking about a standard way to link together tools for requirements, coding and […]