Capability Counts 2016

Capability Counts 2016

The CMMI framework has been around for awhile now, but its use in the industry continues to persist. The framework's focus on quality improvement through the use of best practices makes it of value to almost any organization.

While the framework is still in use, the CMMI Institute has expanded its annual conference beyond a singular focus on the framework itself, to a broader focus on capability. Branding as the "Capability Counts" conference makes sense - all organizations want to build and capitalize on their capability - and this includes more than just the implementation of CMMI. 

We were excited to attend this year's Capability Counts conference in Annapolis, where the wider scope of the conference lent itself to an interesting agenda of speakers on topics from risk management to product quality measurement - and yes, CMMI.

Tom Cagley, our Vice President of Consulting, also spoke at the conference. His presentation, "Budgeting, Estimation, Planning, #NoEstimates, and the Agile Planning Onion - They ALL Make Sense," discussed the many levels of software estimation, including budgeting, high-level estimation, and task planning. He explained why all of these methods are useful, when they make sense, and in what combination.

You can download the presentation below. More information about our CMMI offerings are here - and we're already looking forward to next year's conference!

Download

 

Written by Default at 05:00

5 Trends in Software Security

2015 brought a number of high-profile security breaches, putting company and consumer information at risk. Ashley Madison, VTech, even the Department of Health and Human Services had their data compromised.

It could have been avoided.

You've heard this before, but companies like DCG, and my company, proServices, will continue to bring it up until security is taken more seriously. The first step is staying aware of the latest security threats in order to appropriately ward them off. But, as one risk dies out, another will always take its place.

Risk Management

Download this white paper to learn the top 5 vulnerabilities of 2015 - and what's on the horizon for 2016.

Download

 

Rob Cross
PSC, Vice President

Written by Rob Cross at 05:00

Is Software a Tangible or Intangible Asset?

Tangible Asset

When thinking about software value, most of us immediately think in terms of dollars and cents.  Especially CFOs who talk in terms of where it falls on the organization’s financial statements. Should software that is used within the organization be considered an asset or an expense? This question could be debated over and over depending on who is part of the conversation.

If software is considered to be an asset, it will be found as a line item on the balance sheet. However, it still needs to be broken down further as a tangible or intangible asset. Most would consider software as an intangible asset. It cannot be touched. It is not a physical material or substance. So, it must be intangible, right? Not necessarily. There are exceptions where software is actually deemed to be a tangible asset. 

According to various accounting standards, if software is used to deliver goods and services it can be classified as a tangible asset. An example, would be the software that companies like Snapfish or Shutterfly use for their customers to generate various photo products that result in revenue for their businesses. It would not include a software solution used in their warehouses to keep track of inventory. 

Another criteria to determine if it is a tangible or intangible asset is the cost of the software (to either buy or develop in house). If the cost of one copy of the software is more than $100,000 then it is considered tangible.

So, from the financial perspective, do only tangible software assets add value to the business? Most of us would agree that an inventory management system that streamlines processes and makes the warehouse more efficient adds tremendous value to the organization – it reduces costs, it helps ensure customer satisfaction, etc. 

The Statement of Federal Accounting Standards (SFFAS) No. 10 provides a set of rules about how to treat the transformation of the cost of internal software into value as an asset on the balance sheet. We will not get into these details here in this blog, but it is important to realize that both tangible and intangible software assets can and should be looked at in terms of the value they offer to the bottom line. 

Does your organization have a standard rule it uses in classifying internal software? Is it considered an expense or an asset? Do you have clear guidelines for determining whether to classify your software as a tangible asset or an intangible asset? These questions are important for CIOs and CFOs to discuss to ensure software is allocated as a value to the business.

Written by Michael D. Harris at 05:00
Categories :

Test-Driven Development

James JandebeurTesting has always been a bit of a thorn in the side of software development, necessary as it is. It costs money and time, ties up resources, and does not result in easily tracked returns on investment. In a typical organization, the testing process beings after the development project is complete, in order to ferret out defects or make sure the software is fit for service. If there are problems, development needs to fix them, and then the testing process begins again. Do you see the problem with this cycle?

An alternative to the usual testing process is continuous testing, such as Test-Driven Development (TDD). TDD is not a new concept; it has been around since 2003, but it is still rarely used. The process is straightforward:

  1. Write a test for a single item under development.
  2. Run the test, which will fail.
  3. Write the code to enable the test to pass.
  4. Re-run the test.
  5. Improve the code and retest.

What is the point of this process? At first glance, it may appear that it would make the testing process more complicated, not less. However, it ensures that the testing process is continuous throughout the project. This means that testing is preventing defects rather than finding and repairing them after the fact, thus improving the quality of the final project. TDD provides a suite of tests for the software, almost as a side effect. The tests themselves, when well structured, can effectively provide documentation, as they show what a piece of code is intended to do. Finally, when combined with the user or product owner’s input, the process can be used to perform acceptance testing ahead of the coding, a process known as Acceptance Test-Driven Development, which can help to develop and refine requirements.

Each of these items will ultimately need to be done, regardless of whether they are a part of the traditional testing and re-coding process. TDD allows them to be done in a manner that reduces the number of times steps need to be repeated. Does your organization use TDD? Leave a comment and share your thoughts!

James Jandebeur
CFPS | CTFL

Written by James Jandebeur at 05:00

Agile Testing: Budgeting, Estimation, Planning and #NoEstimates

QUEST

We're a broken record when it comes to software testing. As we've made clear time and time again, testing is undervalued in IT. It is one of the most important steps in the software development process, yet it's often a hurried step, in an effort to produce a final project. As Agile adoption continues to increase (which it will), it's even more important to emphasize the value of testing.

But, testing is routinely overlooked, or organizations don't understand how to prioritize testing within the frameworks in use, like Agile. This is what Tom Cagley, our VP of Consulting and Agile Practice Manager, spoke about at this year's QUEST conference: How to utilize Agile in testing environments. He discussed the difference between budgeting, planning and estimation as applied to testing in an Agile environment - and when they make sense, when they don't and in what combination for testing. He also explained the #NoEstimates movement and its role in Agile testing.

You can download his presentation, "Budgeting, Estimation, Planning and #NoEstimates - They ALL Make Sense for Agile Testing!," here. If you have any thoughts we'd love to here them; just leave a comment below or contact Tom directly.

Download

 

Written by Default at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!