If you’re getting started with Agile, you’ve probably heard a lot of terms and may not know what they all mean.  This post will define the key Agile terms and have you speaking like an Agilista in no time.

I’ve recently completed a white paper that details a methodology employed by CapTech to deliver a SharePoint 2010 collaboration portal for an international client.  Blending Agile and Waterfall practices, CapTech delivered successfully thanks to a variety of benefits afforded to the client and CapTech by the methodology (dubbed CT Hybrid).  The full white paper is attached to this post, but here’s a sneak preview of its Conclusion:

To read the previous entry in this blog series, click here.

So it's time to roll up the sleeves and make things happen: your move/migration is real.  And these boxes/files/images won't move themselves.

 There is a lot of buzz lately around Agile BI and Agile data warehousing.  Typical questions asked include - Does it produce better results?  Is it faster?  How much does it cost?  And of course, most importantly, is the Agile methodology a fit for Data Warehousing and Business Intelligence projects?

What is Agile?

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Design Review, the first security practice in the Verification function.

The Design Review (also called Architecture Review) is a crucial milestone in the software assurance lifecycle, providing an opportunity to spot major high-level issues early in the process when they are still relatively inexpensive to fix. It is typically conducted by security-savvy staff who are either on the project team (for large projects) or in conjunction with the project architect(s) on smaller teams.

First Maturity Level

To read the previous entry in this blog series, click here.

You’ve strategized.  You’ve inventoried.  You’ve cleaned up.  It’s time to answer the pivotal question: how are we going to get this stuff from here to there?  If the move in question is from your college apartment to your parents’ basement, the family minivan might be all you need (and all you can afford).  But if you’re moving from a multi-floor penthouse in Manhattan to a beachfront palace in the Hamptons, the challenge is entirely different.  Similarly, the size, complexity, and available resources associated with a content migration effort will drive the approach definition process, which at its essence involves defining the degree to which the execution of the migration will be automated. 

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Secure Architecture, the third and final security practice in the Construction function. Starting with this post, I am also changing the title naming convention to refer more generally to "software assurance" rather than "secure development." Software assurance is an industry-standard term and encompasses the full spectrum of software security activities across an organization.

To read the previous entry in this blog series, click here.

Of all the moments that make you anxious for the moving process to come to an end, my least favorite might be those that include the following sentiment:  “Why in the world didn’t we just throw/give that away?”  Every occasion in which I opened a box and that thought came to mind corresponded to a case of unnecessary effort, unjustified cost, and unwanted frustration.  Avoiding similar moments for business users should be a goal of content migration.

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Security Requirements, the second security practice in the Construction function. Almost all software development is driven by a set of business requirements, but unfortunately security is often not factored into these requirements at the start of a project. To address this issue, analysts and managers should work to integrate Security Requirements into a development project from the beginning. Security Requirements serve as a "hook" for security: once security has been written into the requirements, it will naturally follow the development lifecycle through design, development, testing, and deployment to production.