Are You Ready for a Software Development Project?

Twenty questions before you start to develop new software.

 

You want to develop an add-in for your favorite CAD system. That makes sense. Improving the process of creating that thing is a great idea. Or combining CAD with a business database can reduce errors and encourage information flow.

But hang on, are you ready?

Before diving in, or hiring and expert programmer, let’s consider some questions.

Initial Business Questions

Let’s take a few minutes and see if we can make the argument for the new software stronger.

We will start with a handful of business questions before considering technical issues. Trust me, your managers will love this.

1) What is it that you want to do?

Are you trying to improve workflow? Maybe you want to reduce the steps needed to locate, attach, clip, and position a reference map into a title sheet. To be fair, this is a simple example.

The reality is that answering this question can be a very complex and involve process analysis, building of use-cases, and documenting specific requirements. I feel like it is essential though to understand the need(s) before moving forward.

2) Do we already own a software that can accomplish what we want?

Is there a feature of a software application already used in the organization that will accomplish what you want to do? If it does, maybe it makes sense to use it.

3) Is there an “off the shelf” ready software product we can buy?

Do some research to see what’s already out there. Maybe there is a free or open source plug-in that will do what you want.

With scenarios 2 and 3, be careful. Sometimes an existing software isn’t the best choice. If you must train your team to use a complex software and/or an expensive software package to get a couple of features, then it might still be better to develop a new way.

4) What are the real costs?

What will it cost to get from no solution to in production – the up-front cost? You’re going to need an estimate and a work plan to take to your managers. Don’t assume that the vendor’s software estimate is the only cost. There could be a cost associated with analysis plus there could be implementation costs like training and testing.

You might also want to have an understanding of the life-time cost of a software. This can be hard to assess, but it’s a good way to compare different solutions, especially one’s that seem reasonably similar such as Civil 3D versus OpenRoads.

The Minimum Viable (usable) Software | Technical Questions

At this stage, you should have a really strong idea of what you want and how to get it. And, you have done enough analysis to determine that building new software is necessary. Now you can start to develop a backlog of ideas and issues that will define the software’s features and functions.

5) What does the minimum viable software need to do?

This is different than question #1 where we asked what you want. Instead, we are now asking what features do you need to develop in order to build a useful software application? This isn’t necessarily all of the features. It could only be one.

Break the project into manageable chunks. Don’t try to build everything. Build out something that is usable and let your users test it. You may be on track, or you might find out that their practice has changed and the use case you identified during analysis no longer applies. You want to discover issues like this early, not at the end of the project – or what you think is the end.

6) What does this minimum viable software look like?

In this step you want to consider how your user’s will interact with the software. Which of course will lead to more questions…

7) Will there be a user interface?

We typically think of dialog boxes when we say UI. When we are thinking about add-ins for OpenRoads or Civil 3D this is probably a reasonable assumption. We might want to broaden that definition. A text file could be the interface to a program. Or there could be a single command button on a ribbon menu could be all that’s required. Each will have different considerations.

If it is a dialog, decide if it will be sizable, dockable, always above the parent application, will it be a Windows Form style dialog, or a WPF window or user control, and decide if it will be modal or not.

8) Ok. We need a dialog. What controls should it have?

I like to white board what the GUI will look like before thinking about design and implementation.  I want to think like a user might think – what do I need to define, select, do – before I click the command button? Sketching this out helps me think through possible design scenarios and identify new tools that might be needed, and whether or not the dialog will launch a new window.

9) Do the controls change based on the drawing type?

This is interesting question and potentially powerful. Each discipline might need a certain function, but the way users interact with it is different. When I built the title block editor for my client, they had different title blocks for Roadway, Bridge, and Right of Way. Changing the dialog and number of controls to match these – also, do it automatically and based on the file type – reduced the learning curve and support calls.

10) What is the process flow? And how will the user move through the dialog?

In most sophisticated design applications, what to do next isn’t obvious. Combine that with infrequent (but necessary) usage will lead to excessive support. Consider taking a top to bottom and left to right approach. And, if possible, automatically move the user through each step by hiding and displaying controls as they complete steps. This will make the add-in more intuitive.

11) Does it need to retrieve data? And, where is it located?

Integrating business data, like pay item with CAD is a smart way to reduce errors and improve the flow of information. Whether you attach XRecords in Civil 3D or Item Types in OpenRoads consider associating non-graphic information with your graphic elements.

12) Will any other systems or software need to change with the introduction of your new software?

Changes you make should not impact other parts of the organization negatively, but your software could require changes in the way data is summarized and shared downstream. Or, you might have to get updates from another system, and this could require some changes in order to automate these updates.

Testing and Change Management | Deployment Questions

Don’t assume that because you have created this great new software that everyone will simply start using it. You know, because it’s so great. You will need to deliver it to your users and you will need to teach them how to use it.

13) Who will test your software?

Before you deploy the software, it needs to work. The development team will do enough testing to make sure that something happens when a command is started and will likely have a testing plan. The test plan’s main purpose is to assure the development team that the features still work as designed. You will need a team to test the program to make sure it will work in a production environment under real work loads. Identify key users who will test your program.

14) What do you need to test?

Those requirements and use cases you identified in step #1 for sure. But your test plan should also assess whether or not the functions and features actually helps your users. It should, based on your initial analysis, but business practices change, so what you thought might solve the problem when you started creating the software, might not solve it today.

15) How often will you test?

You will test each time you get a new build from the development team. If you are working in an agile software development project, then this could be once a month. Revisiting question 14, you might decide to only test the changes for the current update, but if this update coincides with a delivery to production, you will have to run through all test plans to make sure everything works.

16) How will you deploy the new software?

Sneaker net is not great]. It’s ok, I suppose, if you have less than 10 users. Automated distribution is better. In larger organizations you will likely have to work with IT on this one. Think too, about how you will deliver the software to consultants (external users). Can they download it from your organization’s website? If this is your approach you will also want to consider creating an installer – even for your workspaces. And, you may then want to think about security, SSL certificates, and digitally signing you software.

17) Do you need documentation? Will it be online, or delivered with the software?

Yes, you do. As a minimum this will be a quick start guide. A video will help too. A YouTube channel is free and easy for your internal and external users to find. And you will need administrative documentation describing set up procedures, required support files, resources and their locations. An install guide or section is also important. Installation is something that is done very infrequently, you and your development team will forget how the software is supposed to get setup. So, document it.

18) Do you need training?

If the new software is interactive and requires some user input, then it is likely to require some kind of training. This could be instructor lead. Self-paced via a learning management system. Or a YouTube video.

Miscellaneous Considerations

19) How do you know if the software you have built has been a success?

This should tie back to your original use cases. I also recommend that you define measurable outcomes that you can test against. These need to be specific and quantifiable. Drawing creation has been reduced by 40%. You can create 100 design concepts in the time it takes to do 1. Or, you might now be able to do something you could not do before – I can draw a sign assembly along an alignment, and have it automatically rotated to the direction of travel.

20) Do you have performance requirements?

When you are building an add-in you don’t always know what these will be until you have had a chance to test initial versions. You also don’t have control over the parent application (the software your applications will run inside). It may be necessary to modify and re-prioritize the backlog in order to address the new issues.

BONUS Question

21) Repeat!

Well, not a question, but definitely a consideration.

Software development is not finished until the software is no longer used in production. So, once you deploy it there will be a need to keep it up to date with the parent software. There will be code enhancements, and yes, bug fixes. These become maintenance releases and should probably coincide with your workspace releases. As a minimum they should be planned yearly.

Ok. This isn’t everything you will need to think about before starting that software development project, but it’s a good start.

There are software teams who are experienced enough to help you fill in the gaps. Whether you can find this team or not, answering these questions can give you a leg up when working on that software project.