Defining a Process

Software is designed to perform a process, and thus the skills you learn this month will aid you in communicating your software process to others.

What is a process? A process is defined as a series of actions or steps taken in order to achieve a particular end.

Why is it important to define a process? It’s important to understand the benefits of defining a process in advance and completing up-front design to get approval and consensus before moving forward with development:

• Having peers review your project can lead to a more robust and error proof product
• A good software developer will analyze a project to identify gaps or flaws in the design before beginning coding
• Up-front design is the best way to show your client you are listening to them and getting their approval on the product they want
• Software follows same up-front design because when done incorrectly, it can be costly

How to build/design a process

Every process has a start and an end (a pre- and post- condition).

It’s up to the designer to determine and document the exact conditions for the process to start and end.

Example: Doing laundry could be defined as follows:

Pre-condition: The clothes are in the hamper in laundry room and detergent is on the counter

Post-condition: The clothes are clean, dried, and folded in the hamper.

Pre- and post- conditions should be determined before you start any work on a project so you and your client are in agreement on the scope. These are arbitrary statements and defining them is a key part of the process. These can be as detailed as you like.

Use terminology your audience will understand Never assume people know what you’re thinking. Throughout your career you will be asked to communicate in terms that are understandable to your audience. You will need to differentiate and change your language context communicating with non-technical people versus your software peers.

Determine the detail level

• Based on your audience, can you use more technical terms and take a higher-level approach, or will it require something more detailed, in simpler terms?
• Again, much like pre- and post- conditions the level of detail is arbitrary and design is more about iteration. You can expand on each step to include more details. It’s useful to think of it as “OK, so how exactly do you do that?” once you have defined a step.
• As you design a process you should constantly ask yourself if the details are important. If details are important lock them down in your design for discussion and to create a contract of what needs to happen.

Define the Actions

• Determine all the steps that are needed to complete your process. Think of each Action as a step in a set of directions or instructions. You need every step accounted for in order to complete the process.
• Actions should be short and simple and must begin with an action verb. ie. (Action) Display the final cost. _A program will execute the word immediately following your call out: (Action) then display the final cost _would result in nothing as "then" is not a verb.
• You can have more than (1) Action in a sentence. ie. _(Action) Remove a slice of bread from the package and (Action) place on a plate. (Action) Remove a second slice of bread from the package and (Action) place next to the first slice. _is correct. Make sure you are calling out every verb in your sentence as its own Action.
• When dealing with multiples of an item, each one must be its own step: (Action) Take out 2 pieces of bread and (Action) place on plate would be incorrect as you haven't broken out each step, individually. _The program will only execute the first in the series. Correct: (Action) Remove 1 slice of bread and (Action) place on plate. (Action) Remove a second slice of bread and (Action) place on plate, next to the first slice._
• Remember, if you use the word "and", this indicates that you have more than (1) Action and must call out as such. In the following example: (Action) Open the cabinet, remove a plate and place on the table, a program would only open the cabinet and either error, or skip ahead to the next correctly labeled Action.
• You cannot have negative Actions, ie. (Action) Do not overfill. _You can not execute something that does not happen. To correct you might say, (Action) Pour milk into coffee without overfilling. _If you find yourself compelled to say, then (Action) do nothing, simply delete this Action and continue with the process, as doing nothing is implied by moving on to the next action verb or Decision.

Define the Decisions

• Decisions are always "if statements" ie. (Decision) If you would like creamer in your coffee, (Action) pour creamer into coffee.
• If you have the word "or" this indicates that a Decision needs to be broken up to accommodate. If you're thinking: "Do you want to use milk or creamer?" you would write it as the following: (Decision) If you'd like to use milk, (Action) pour milk into coffee, otherwise, (Action) pour creamer.
• You can use the term "otherwise" for when you have a finite set of results. As above: milk or creamer. Do not use as a way to continue on with the remainder of the process. This is incorrect: _(Decision) If you'd like to use milk, (Action) pour milk, otherwise (Action) pick up the cup. _The Action to pick up the cup is going to be completed regardless of the Decision to use milk or creamer and is unrelated to the Decision.
• If you have a series of choices you must break each of these up into their own Decision followed by an Action. ie. (Decision) If you want yellow paper, (Action) remove a piece of yellow paper. (Decision) If you want blue paper, (Action) remove a piece of blue paper. (Decision) If you want white paper, (Action) remove a piece of white paper. (Action) Place the paper on the table.

Define the order of actions and decisions

• Make sure your process is defined in a logical order to properly execute and satisfy your pre- and post- conditions.
• As the designer it is your job to assess the situation and communicate your ideas in the best manner possible.
• For examples of proper and improper decisions please see the ActionDecisionExample.pdf on FSO.