Software Projects in 9 Steps

Here, in a nutshell, are 9 basic steps I think are essential for any software project. This could describe a traditional waterfall development cycle, or it could be some type of iterative process. Some of the activities, like implementation and testing, can be done in parallel. The important thing to take away here is that without some kind of plan in place the development effort can devolve into little more than a happy hack-fest. Happy, that is, until the customer gets something that doesn’t do what they need it to do, doesn’t work correctly, or just doesn’t work at all.

The reality is that writing good software is hard. Sometimes very, very hard. Anyone who thinks that creating something like OpenOffice, the Linux kernel, or reliable control software for an automated beer bottling system is easy is either (a) incredibly naive, (b) amazingly arrogant, or (c) just plain stupid. Or all of the above.

I have more to say on why the activities outlined here are important (a lot more, actually), but for right now here’s a quick list to consider:

1. Feature/Function Description: What it is and why it’s necessary

Generate a high-level description of what functionality is desired. Can be just a paragraph or so with minimal technical terminology, but it should be detailed enough to allow someone not directly familiar with the underlying software or system to understand what is being described and why it is considered necessary.

2. Functional Requirements: What will it do?

Generate a use case (or multiple uses) describing the functional requirements of the new feature or modification. Use the use case template already defined. Work with the “customer” (sale and marketing, R&D, production, etc.) to collect data for the use case(s) and iterate with the customer to insure that what is being documented is really what they need.

3. Design Documentaion: How will it be built?

With the use cases from Step 2 as a starting point, create a design document that, at the very least, provides a high-level view of the software design in terms of block diagrams, class and module structure, and internal interfaces. In other words, this is the framework upon which the desired functionality will be built.

4. Level of Effort: What will it cost?

Generate a realistic estimate of the level of effort required to implement the functionality described in steps 1, 2 and 3. Be sure to include something for testing and acceptance.

5. Approval: Can we afford it?

Present the materials generated in steps 1 through 4 and get approval to proceed from management.

6. Test and Verification: Prepare a test plan

Once approval is given the next step is to create a test plan. It should address not only the outward functionality visible to the end user (GUI functionality), but also issues such as integration with the existing codebase (if any), integration with external hardware, error handling, data logging and so on.

7. Implementation: Let’s do it.

After steps 1 through 6 are completed coding can commence. Coding styles should be in accordance with accepted stylistic conventions (i.e. Python’s PEP-8 and PEP-256 documents, for example). Code must be subjected to a review process. Unit testing may be conducted during the implementation activities for informal verification purposes.

8. Testing and Verification: Does it work?

Using the test plan from Step 6, create test procedures to verify the functional requirements captured by the use case(s) from Step 2. Test the implemented code in accordance with the test plan, address any defects, and re-test as necessary.

9. Acceptance: Does the customer like it?

Demonstrate to the customer/end user that the code behaves as described in the use cases from Step 2 and passes the testing defining in Step 6. The work isn’t done until the customer says that it is.

Other Topics/Issues

Automated  testing – Unit testing in particular can and should be automated to run every night. Once it is set up it costs nothing to execute and the developers can check in the morning to see what issues have come up that need to be addressed.

Adequate testing – Just poking the GUI and looking at pictures is one way to verify that the GUI behaves as expected, and gives some indication of what is happening under the hood, but it is not a comprehensive test methodology. It may not detect issues with control or data coupling, invalid internal parameters passed between functions or data range/type issues, especially if these occur “silently” in the bowls of the code. Adequate testing involves a sensible combination of low-level techniques such as unit testing with higher level approaches such as functional testing.

Metrics – Collecting metrics is important, if for no other reason than to give some insight as to where resources are being spent and what benefits are being derived from the effort. Metrics include lines-of-code counts (SLOC), cyclomatic complexity, defect resolution performance, and  code coverage (did all the code get executed, or is some if it “dead code”?).

Comments

Some readers may notice that I’ve left a few things out (like allowing for effort to correct defects) and that I’ve specified use cases instead of detailed formal requirements (there is a difference). This isn’t intended as a definitive guide to defining and implemented a software project. It is just a starting point.

Advertisements

0 Responses to “Software Projects in 9 Steps”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: