“Eat a live frog first thing in the morning, and nothing worse will happen to you for the rest of the day.”

-Mark Twain

If you have ever been a software project manager, business analyst, developer, or purchaser of software development services, how many times have you encountered a project with the following characteristics:

• All the requirements are done up front, with an emphasis on getting them “perfect.”
• Design follows the same path as requirements – all designs and mockups must be complete before development proceeds.
• In the project plan, coding for the system is broken out into “iterations” – one piece of the code is built at a time.
• Project managers and technical leads schedule developers to implement the easy, simple requirements first in order to show rapid progress and build momentum.
• When clients are shown the product at the end of iterations, they ask for changes that ultimately send shockwaves through the rest of the requirements.

At this point, most large projects are destined either to go significantly over schedule or over budget, or they fail outright – the project is scrapped. The reason for this is two-fold.

1. The Waterfall lifecycle is masquerading as an iterative and incremental lifecycle.
2. Management is pushing key risks to the end of the project.

 The Rational Unified Process (RUP) is a generally-accepted solution to this problem. It provides a framework within which iterative and incremental software development can occur in a way that reduces risk over the lifecycle of a project. RUP is based on several principles:

• Use-case Driven Development:  Use cases guide the development of the system from requirements all the way through test. They also provide system use context far superior to list-based requirements.
• Risk Driven Development:  The most complex, significant, and risk-laden parts of the system are developed first. Over the lifetime of the project, risk decreases since the “harder” parts are done first.
• Architecture Driven Development: Related to risk driven development, the early iterations of development focus on the parts of the system most critical to its structure, providing a framework around which the rest of the system can be developed with relative ease
• Iterative and Incremental: The system is developed one small piece at a time with frequent end-user input. This ensures that the right system is being developed, and that there are no surprises at UAT time

Though RUP is a proven process, it can cause some indigestion for those unfamiliar with it – and especially those most familiar with the waterfall model. Some points of pain for RUP are:

• Requirements are not complete before development begins
• Initial progress can seem slow due to the addressing of high risk items early in the project; it takes longer to establish momentum
• The process wreaks havoc on traditional project schedules – long range estimates for the completion of the project are best given towards the end of the Elaboration phase… after some development is already completed

 On the whole, however, RUP presents far fewer risks that traditional waterfall development. Waterfall projects often veer wildly off schedule due to surprises near the end of the build phase – this is far more risky than RUPs practice of postponing long-range scheduling to the end of Elaboration. Waterfall projects may show lots of early progress as developers pick of low hanging fruit – but the benefits are fleeting; sooner or later the big risks are going to be encountered and, if they’re show-stoppers – all that low-hanging fruit was picked for nothing. Finally, requirements rarely, if ever, remain stable throughout waterfall development. While RUP may seem disquieting in addressing requirements in chunks throughout the process, this is really no different than what happens in waterfall – with the exception that RUP plans for the changes and is structurally built to handle them.

If you’re interested in trying this process, highly suggested reading is The Unified Software Development Process by Jacobson, Booch, and Rumbaugh. It’s dry reading, but full of wonderful and detailed information about how the process works.

NRC and IWMS

NRC intends to implement an intergrated workplace management system (IWMS) with the ARCHIBUS facilities management system. Counterpointe will provide services that include:

• Analyzing an existing and heavily customized ARCHIBUS instance already in place, and determining a procedure for upgrade
• Refitting business processes to use standardized, out-of-box functionality present in ARCHIBUS with respect to space and asset management
• Implementing a new, personalized ARCHIBUS solution that minimizes heavy customizations and promotes an easily maintainable system

Once in place, the system will greatly streamline facilities management, asset management, moves, and much more.

USDA and UPC

The USDA has recruited Counterpointe for an operational support and adaptive maintenance contract with Food and Nutrition Service’s WIC program. Counterpointe will keep an exisiting UPC (Universal Product Code) system up and running as a new team of contractors redesigns and upgrades the organization’s UPC system to a new electronic benefits transfer, which is a key part of the USDA strategic goal to improve service to low income women, infants, and children.

ARCHBUS’ flexibility is a tool, and like any tool it must be used carefully. Changes to an ARCHIBUS implementation generally fall into two categories:

Personalization – This involves minor changes to the system that do not require modifications or additions to system code. Examples of personalizations are:

• Adding, changing, and removing fields in forms
• Implementing custom roles and role based access
• Restricting report results to a certain subset of data
• Creating dashboards

Customization – This involves more substantial changes to the system, generally involving system code and the implementation of custom workflow rules, processes, and complex tasks. Examples include:

• Adding and removing steps in pre-existing ARCHIBUS workflows
• Integrating legacy products into the system
• Performing complex external system integrations

Personalizations are clearly the eaiser of the two to perform, and pose the fewest problems with respect to the system’s maintainability – particularly with respect to upgrades. Customizations, however, can easily pose significant problems if not performed carefully. Since these enhancements can involve changes to system binary code, core view files, internal system configurations and other key items, it is important to design and implement them intelligently.

We offer the following three bits of advice when it comes to ARCHIBUS customizations:

1. Increase your requirements time in your project plan by 25% – 50%.

Requirements will take longer to develop because you will want to review your business processes. In many cases, clients find that changing their own processes to match ARCHIBUS workflows (instead of the other way around) will save time and money not only in the software development process, but in the business processes themselves. ARCHIBUS processes and workflows are built upon industry best practices, and it could do your organization good to take advantage of that collective knowledge base.

2. Increase your design time in your project paln by 25% – 50%

If, after a requirements iteration you determine that customizations will indeed be necessary, allocate a very healthy amount of time to design. A rule of thumb is for project managers and developers is to estimate the time necessary to complete the design, then increase that number by at least 25%. The reason for the increase is that developers must not only perform the standard system design required for any enterprise software system, but they must also design for the remaining bullet points in this article.

3. Keep ARCHIBUS components and custom components seperate

Here lies the onion of why ARCHIBUS customizations can be so risky: Short project timelines lead to insufficient design time, which means that developers must implement customizations as quickly as possible. The quickest (but by no means the best) way to implement many customizations is to modify ARCHIBUS system code and weave customizations directly into the internal fabric of the system. In the short term, this is great: the project doesn’t take very long and the customer’s needs are met… until a year or two later when the client wants to upgrade the software. Now comes the pain.

When a new version of ARCHIBUS is released, its source code obviously isn’t going to contain your specific customizations. It’s going to be up to your developers to literally go line by line through all the customizations they made, and integrate them line-by-line into the new version’s code. Essentially, you’re doing all your customizations over again!

With sufficient design time, however, your developers can organize customizations into self-contained components that can be developed, deployed, and tested seperately from ARCHIBUS. Under this scenario, the upgrade process is much less labor intensive and error prone. Even better, the extra requirements and design time spent up front will actually pay for themselves during your first upgrade, because the upgrade takes so much less time.

So there you have it. Avoid significant customizations when possible – but when you must have them, allow plenty of time for your team to design a solution that will decouple core ARCHIBUS functionality and customizations. If you’d like more specifics, feel free to contact ARCHIBUS senior developer Chris Newman at cnewman@cpointe-inc.com.

If you or anyone you know have experience as software developers, analysts, or managers, please have them forward a resume to trish@cpointe-inc.com. We’d be glad to speak with you!

Learn more about this organization’s incredible work at http://www.projectak47.com.

But for anyone that’s ever tried to backup a document library or email a URL knows just how much of a problem folders can be. Folder structures find themselves inserted into the URL of every document in your library – giving you atrociously long paths that are often too long to be saved on a harddrive.

In additon to the above, use of folders simply fails to leverage the full power of Sharepoint. Far too many people leave behind cool features like views and metadata in favor of the ‘tried and true’ folder system – only to become a.) frustrated by the types of problems mentioned in the last paragraph, or b.) asking themselves “why am I doing this online when I can get the same folder structure in a network folder, with much greater speed?”

Read my lips: “No more folders.”

Remember when Gmail first appeared? People initially found it’s ‘conversational’ model of organizing email to be frustrating and unfamiliar – that is until they realized how great it is. The same can be said of the proper way of organizing Sharepoint content, which is NOT to organize documents in vast, deep nests of folders.

Instead of folders, you should begin to think about two things: Content Types and Views.

Content types allow you to define bits of information that can be associated with documents. Combined with views, which allow you to view cross-sections of your document libraries based on information in the content types, you will be able to access your information more quickly and effectively.

For example, imagine you have the following simple folder structure in a document library:

  Penskey Project
        Meeting Minutes
        Contracts
        SLAs

  Manhattan Project
        Meeting Minutes
        Contracts
        SLAs

Instead of using folders, you could create a content type with two columns: Project and Artifact Type. You can then specify the project (Penskey or Manhattan) and the Artifact Type (Meeting Minutes, Contracts, SLA) at the time you upload the document. Finally, you can create any number of views in that document library so you’ll be just one click away from the documents you need. Create a view to show all Manhattan documents, another to show all Penskey Meeting Minutes, and another to show SLAs from both projects. You can imagine how this could be very useful when you have deeper folder structures.

Of course, creating content types takes a little more time up front and forces you to think carefully about the way you organize information… but that isn’t really a bad thing.

When it comes to Sharepoint folders, just remember: take a deep breath and let it go. Content types and views are the way to go in Sharepoint.

About the author: Chris Newman is a senior software developer at Counterpointe Solutions, Inc.

I recall a quick conversation I had with a friend and former colleague, Paul Duvall, who wrote a book about continuous integration (CI) a couple of years ago. I was not well versed in CI at the time, but these days I’ve been testing out a number of tools to incorporate the concept into our projects at Counterpointe. The open source CI tools available these days enable relatively easy and cost effective implementations. I have been researching two common tools – Hudson CI and Cruise Control – to compare the two to see which would work better in different situations. This is an account of the lessons I’ve learned.

No man is an island

Both Hudson CI and Cruise Control don’t do much on their own. To use the tools for greatest effect, you’ll need to have to understanding and experience with version control software like CVS or Subversion, and management/administration of applications servers(e.g. JBoss or Glassfish) and integration testing frameworks (e.g. JUnit, TestNG, Selenium). It’s a daunting list of things to know, but having that foundational knowledge will help you understand all the configurable items that Hudson provides.

When is CI appropriate?

If you’re working on a one-person project, a CI process is likely overkill. You should only attempt putting one together if you’re interested in learning the concept or putting together a pilot for a larger project. However when you go to projects with two or more developers working on the same set of code, or you have teams working on components with dependencies on one another, CI begins to show its benefits. When someone checks in compile-defective or run-defective code, it can have a negative cascading effect on productivity. The project may not be able to move forward until the author of the buggy component corrects the issue.

The three big issues CI can address

The first issue CI can handle is compilation issues. These can be resolved quickly by a CI process, which will checkout the latest code from version control, run a build, and notify the team of any issues.

The second issue is that of runtime issues at the unit-level. After compiling code from version control, CI processes can execute unit tests and report problems automatically.

Last, but certainly not least, CI can address integration testing by loading data via SQL scripts and executing test scripts against a database and application server that the application is running on – a vital tool for conducting regression tests.

Putting the pieces together

Beyond setting up Hudson CI itself, you will need to have version control set up so that Hudson can draw code from it. You will also require supplimental open source tools to integrate Hudson with your version control, such as Ant and build scripts to automate the compilation, build, and deployment processes. Finally, you will need both data-loading SQL scripts and a tool to control your application server. More details on these issues will be provided in later installments of this series.

That’s all for now. My next entry will step through setting up the environment to integrate Hudson with version control.

About the author
Michael Kim is a Principal Developer at Counterpointe Solutions, whose primary focus is on Java EE development process and system architecture.

This situation is not at all uncommon. MOSS 2007 and its successor Sharepoint 2010 contain a set of out-of-the-box capabilities so large that it can become a liability. This organization’s Sharepoint instance is not the first I’ve seen relegated to the role of a glorified file server – many groups adopt Sharepoint without realizing the true power of content types, site templates, workflows, and other features that make a mature Sharepoint implementation a truly beautiful thing.

If you have a Sharepoint instance that’s looking a little too much like a file server, then take a peek at some of the items discussed below. They could be the keys to transforming your instance into something truly useful.

Content Types

Sharepoint content types allow you to associate data with different types of documents. Your HR department may create a content type for resumes that includes additional information like skill sets, candidate location, rating, etc.  It’s very convenient to have this type of data in addition to the resume itself, because once you’ve created the content type you can search for resumes with a rating of ‘Excellent’ or ‘Project Management’ included in their skill sets. Furthermore, you can restrict the range of data that can be entered into these fields by using custom lists (this will keep one recruiter from listing a candidate’s rating as “Great” while another prefers “Excellent” – governance, discussed later, plays a big role here.)

Site Templates

Most people know that you can create any number of site collections in a Sharepoint implementation, but surprisingly few realize that you can save a “model” site collection as a template. If you’re making subsites for a number of project teams that will have similar structure, lists, navigation, etc., then there’s no need to create them from scratch each time. You can simply create the first site collection to your liking, save it as a named template, then use it as the site template for the next site you create. All the navigation and web parts will be in place, providing your collections with a consistent look and feel.

Workflows

Sharepoint is capable of routing documents through approval workflows that can be customized as you see fit, and it can generally be done without writing a single line of code. If you require processing for your documents, make sure you check out the basic out-of-the-box Sharepoint workflows before you go looking for a custom solution. You may be surprised by the flexibility offered by the standard workflows.

Other Cool Things

• You can create timer jobs to execute according to a schedule. This is useful for a number of things, especially synchronizing Sharepoint document libraries with external systems
• You can configure document libraries to receive emails.  You can associate a document library with an email address and automatically populate that library with emails sent to its pre-configured address
• You can create custom web-based forms using InfoPath. InfoPath allows you to create forms without using code that can be deployed to Sharepoint and made available to users through the browser. Form information can be saved into document libraries or manipulated in practically any way you see fit, all without writing code

Governance

Governance is, in short, the creation and maintenance of principles that guide the use and implementation of Sharepoint to that it becomes a reliable, consistent, and useful system for the people it’s supposed to benefit. Governance is to Sharepoint what laws are to a nation. Sadly, this most important part of the business of running Sharepoint is also the most overlooked. The result is Sharepoint implementations suffering from one or more of the following:

• A patchwork of loosely related and often redundant site collections
• Inconsistent look, feel, and navigation throughout the site collections
• Non-existent or poorly defined content types that make locating documents nearly impossible, resulting in deep folder structures within document libraries that effectively turn Sharepoint into a file server
• No guidance as to how to implement and deploy custom features and other upgrades
• Lack of SLAs that cause Sharepoint maintenance windows to clash with project deadlines, among other serious problems
• A Sharepoint implementation that people hate to use

If any of the above looks familiar to you, then you probably have a governance problem.

I could go on all day about the robust features of Sharepoint, but we’ll leave it at this for now.  If you have any Sharepoint issues you’d like to discuss, feel free to email cnewman@cpointe-inc.com.

However, leveraging the full power of Java EE generally necessitates use of container-managed or other external objects with complex dependencies (e.g. EJBContext or JPA), making unit testing a difficult practice to follow. “Microcontainer” options are available and include products such as GlassFish and JBoss, but setting these up can be prohibitively cumbersome and platform dependent – GlassFish and JBoss microcontainers require  Oracle and JBoss target environments, respectively.

After numerous frustrating attempts at performing EJB unit tests with TentNG and JUnit, there appear to be new developments on the horizon that will make this task much more simple. Arquillian is a new testing framework (currently in Alpha) designed to make the testing of EJB/JPA objects as straightforward and flexible as testing options for POJOs. Here’s to hoping this new framework makes life a little easier for us all.

http://community.jboss.org/en/arquillian/blog/2010/10/04/the-perfect-recipe-for-testing-jpa-2-revisited

Much of the work is coming from the Internal Revenue Service, which has awarded:

• A 2-year contract to provide administrative services support for the Graphic Database Interface (GDI) system, which includes preparing investment portfolio strategies and initiative proposals, developing business requirements for system support, developing sustainable training program materials and obtaining support for project initiatives.
• A 5-year contract from the Internal Revenue Service to provide Computer Aided Facilities Management (CAFM) Support Services. The support for this contract includes CAFM Database Management, AutoCAD Drawing Management and Electronic Document Management.
• A 2-year purchase order from the Internal Revenue Service for technical services to retire the Web-based Electronic Project Investment Process (ePIP) system and incorporate its functional capabilities into the GDI System. Our objective is to examine existing work product to determine the status of software functionality, perform system testing, facilitate user acceptance testing, and provide implementation and production cutover support.
• A 1-year purchase order from the Internal Revenue Service to provide technical services to complete work to retire the web-based Foundation Information for Real Property Management (FIRMWeb) system and incorporate its functionality into the GDI System. Our objective is to analyze existing work products, determine the status of software functionality, and provide implementation and production cutover support.
• A 2-year purchase order from the Internal Revenue Service to continue deployment of the GDI System.  Our objectives are to expand the use of the system to include other space related processes and data supporting non-space related processes, increasing access by making the system available to Shared Services partners, the CFO, and select Business Unit customers; and retiring existing REFM single purpose legacy systems and tools.

The company has also received an award from the U.S. Department of Agriculture – a 4-year contract from Food and Nutrition Services to continue Operations and Maintenance for the ME Tool. The primary objectives for this contract are to provide quarterly releases for updates to the system, help desk support and incorporation of new programs into the system.