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

CIOs Discuss Prioritizing Projects by Business Value

Mike HarrisLast week I had the pleasure of speaking at The CIO and IT Security Forum in Miami. I also spoke at a CIO Forum this past fall. At these events, my presentations are delivered to small groups of CIOs/CISOs intentionally to allow an interactive and intimate dialogue. That said, I had about 35 people split across two presentations last week. My goal for these presentations is to offer ideas for using software business value to prioritize development projects at the strategic and tactical levels, to provide practical examples, and, above all, to evangelize to try to get more companies doing this stuff – visualizing the business value of their software development efforts.

The attendees were very engaged in this topic. Most of their interest was focused on using cost of delay and weighted shortest job first approaches to prioritize projects. In the first session, the audience requested I go through the calculations in detail, so I incorporated that into the second presentation and again got a positive response. There was something of an “aha” moment in both sessions as they realized that coming up with relative business value for prioritization purposes is actually a practical proposition.

In the first session, we had a substantial group of CISOs, and we talked about where information security investments fit in the business value of software – a particular piece of software development could result in a reduction of risk, but all software development has the potential to add risk of a vulnerability if security is ignored or is simply paid lip service. 

Of the 35 or so participants, just two claimed to attempt to prioritize by business value. They were able to describe their approaches to the other participants. This is one of the great things about CIO Forum events – participants learn as much from their peers as they do from the presenters, and I always try to encourage this interchange during my sessions.

Do you prioritize your software development initiatives by business value? If not, what criteria do you use to prioritize your projects?  If you’d like to learn more about focusing on software business value to prioritize your efforts, click here for white papers, additional blogs, and webinars on the topic.


Mike Harris
CEO

 

Written by Michael D. Harris at 05:00

"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!