Practical Software Engineering

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.
–The New Oxford American Dictionary

The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

When it comes to documenting software designs, there are many practices ranging from a quick whiteboard sketch to fully specified UML models with OCL to tens of pages of written text. Here is what I found that worked best based on most projects that I have been part of:

1. Static Structure Diagram: this is a class, module, or package diagram. This diagram (though often it is more than one), shows the relationship between parts of the system at a given level of abstraction. The relationships shown include: containment, references, parameters, inheritance, and so on. Record on the diagram indirect and implied dependencies with a note.
2. Initialization Sequence Diagram: shows how the system is brought up from being on the disk into the operative memory and “ready to transact business” state. This diagram is part of the dynamic model of the system. It shows the order of messages sent or method invocations. Often also shows resources allocated to get up and running.
3. Shutdown Sequence Diagram: shows how to put back the system or component into the proverbial “bit bucket.” Must complement the initialization sequence diagram and demonstrate that the system is not loosing resources during its operation.
4. Sequence Diagrams, Activity, and/or State Diagrams for the key “business” of the system or software part. All other activities took place just to get ready to do the business of the system. Now it is time to get the business done. The key sequence diagrams show what the system does, how it provides the value that it is expected to deliver.
5. Brief Design Commentary to explain the “why” behind key structural and behavioral elements and decisions. This is usually one Wiki page that ties all other documents together into a coherent whole.

Each of these can be created at “every zoom level” in the system. This means that if you are developing a component-based system, then you would have this set of design documents for the system, subsystems, modules, and components. Within each you represent the unique concerns of each software part.

Read Applying UML and Patterns, 3rd. Ed., by Craig Larman for an in-depth course on how to do object-oriented analysis and design on an iterative software development project. As you do design more, review your results, learn from your mistakes, and over time you’ll get better at it.

Resources:

1. UML basics: An introduction to the Unified Modeling Language, from IBM developerWorks, 2003.
2. Allen Holub’s UML Quick Reference. 2007.
3. Book excerpt from OOAD with Applications, by Grady Booch.
4. UML Modeling in Color, from Wikipedia.

Regardless of the organization you work in, this question probably comes up daily, but at least weekly. To answer the often dreaded status question you need minimum 4 pieces of information.

1. When did the project start? This is the Start Date.
2. When is the project expected to end? This is the Expected, Planned, or Estimated End Date.
3. Where should we be today based on the plan? This is the Expected, Planned, or Estimated % Complete.
4. Where are we today? This is the Actual % Complete.

If you have the above information then you are able to judge how well you are doing relative to what you said you’d be doing. There is a lot more to project management, but this is a good start.

To get started make a plan for the work you intend to do this week. Write down at least 2 tasks for each day: one task for the morning, one task for the afternoon. This gives you a total of 10 tasks for the week. As you check off the completed tasks, you’ll see your progress bar move. Once you are able to plan your work for a week, plan the next month. Collect your data and adjust.

There is no need for you to wait for your entire organization or team to start doing this. You can get started alone. You’ll be surprised how much better your work will go and how much better you’ll be able to help your team.

Writing an individual project plan for your project work can be difficult. The secret of creating a workable task plan is to consider not only the work you will complete, but also the knowledge you expect to learn as you perform each task.

As you complete tasks from your plan, two things happen:

1. you create deliverables, and
2. you learn.

On a short project you may not be able to learn much. If your project is short, only a week long, then to improve the odds of success, you have to make a plan considering only the knowledge you have at the beginning of the project. One week is generally not sufficient to learn something of consequence that will help you get your project done on time. When you make your plan, focus on the deliverables created by each task. When all tasks are done, the output created must add up to a completed project.

If you notice that you have lots of short projects, then you need to take a more systematic view, and find ways to include learning into your work. Teams that fight fires, each fire being a short project, tend to believe that they don’t have time to learn. They feel that there is never time for learning. However, firefighting is really one long project with lots of short iterations. More on this another time.

On a longer project you must learn. If your project is longer, 2 to 4 months or more, then you must factor learning in the work you are planning to do. More so, you may even want to include deliverables that allow you to verify that learning has occurred. Such deliverables are prototypes, proof of concepts, sample code that you create to demonstrate to yourself (sometimes to others) that you indeed understand the work, the requirements, the API, or some other things related to the project.

Outside of explicit learning-oriented deliverables you also must factor learning into the regular project tasks. Let’s look at an example. You make a plan to create component A and component B. B will be using A through A’s public interface. However, at the time of planning you don’t know exactly how that interface will behave. So you plan for learning.

The knowledge you expect to learn is that you will know exactly how A will behave before you start work on B. This knowledge is pre-requisite for doing the correct work on B. Part of the tasks for creating component A include the writing of A’s unit tests. When you perform this task you will learn how to call A through its public interface. By the time you start work on B, you will have acquired the necessary knowledge to perform the work on B. You didn’t have this knowledge when you made the plan, but you planned for the learning to occur by the time you needed it.

After some practice, factoring into your plans the knowledge you expect to learn will enable you to make more detailed plans for longer horizons with higher accuracy. The challenge is that you need to change the way you think about project work. Plan for learning. Make learning an explicit and expected outcome of each task. You’ll surprise yourself, and your team. Your plans will become ever more accurate.

The modern age demands from all of us to deliver more in shorter time. The easy solution to this problem is to multitask. However, as an article by Roger Brown points out: “Multitasking Gets You There Later.” At the bottom of the article he provides a good list of references as well.

Even if you manage to keep yourself and your team focused on one project at a time, you still have to ensure that you keep your day “defragmented.” Let’s suppose that you intend to do 6 hours of work today on your project. You can achieve the 6 hours total if you work:

1. 40 blocks of time, 9 minutes each, or
2. 4 blocks of time, 90 minutes each.

You will get way more done working the 4 blocks of 90 minutes. The simple reason is that you have minimized your context switches. Therefore you could focus on the task and finish it. Don’t take my word for it: try it out yourself today.