A Picture is Worth a Thousand Words: Sketching the System

Introduction

This segment of the series returns to the fundamental instruments of software design; namely, flowchart and pseudocode. Both are presented as a preliminary phase leading to an algorithm for a given system. Once the algorithm has reached a state of stability and more importantly, a practical level of usability, it is anticipated that both design elements will be reapplied in order to refine the system as it enters subsequent phases of development.

Of course, a business is an intricate blend of talented and driven individuals that navigate in tandem through schedules and collaboration. The elements that will be presented are mere starting points for most situations. The flowchart is an invaluable mapping of all the specializations within the organization including its procedural pathways. That same organization can seamlessly communication through a universal dialect provided by pseudocode. As management begins to encompass improvement, the Gantt method is the ideal maneuvering platform for a business committed to achieving that goal.

Flowchart

An effective option for capturing business activity and communicating it among staff and clients is the flowchart. The flowchart will start simple and eventually extend to multiple pages and layers of detail.

Figure 1. Business Flow

(Note: To enlarge the flowchart, point mouse over the image, then right click and select 'Open image in new tab' from the menu for a more legible version.)

The flowchart embeds the most vital elements on a company level as seen above as well as on a product level as seen below. It can embody key objects and relationships from the top looking down or from the bottom looking up in order to maintain cohesion between employees or departments. In a business that relies on employees with extensive backgrounds or that provides a diverse product inventory, the flowchart can streamline the function and method involved with minimal conflict.

Figure 2. Software Development Strategies

Pseudocode

Once the majority of the effort has been organized through visual means such as flowcharting, the next portion is to outline the underlying components using pseudocode.

The main requirement of a business is to sell the product at a competitive price, including the sales tax. A procedure written in pseudocode for computing the final price of a product after computing the sales tax is provided below. The variables necessary in this procedure are: price of item, sales tax rate, sales tax, and final price. This procedure uses three types of actions: input (get), calculate (=) and output (display).

Example A. Computing Sales Tax

1. start
2. get price of item
3. get sales tax rate
4. sales tax = price of time times sales tax rate
5. final price = price of item plus sales tax
6. display final price
7. halt

Each operation is numbered and each operation is unambiguous and effectively computable. Identifying all the variables for keeping track of information is useful when entering the next phase of translating pseudocode into a programming language. As such, extracting and listing all variables is an important outcome of the pseudocode effort.

Another requirement for managing a business with more than one employee is gross pay which depends on the pay rate and the number of hours worked per week. However, working more than 40 hours requires payment of time-and-a-half for all hours worked over 40. A procedure for disbursement of wages is provided below. The variables necessary for this procedure are: hours worked, pay rate, gross pay. The pseudocode computes gross pay for a given pay rate against the total number of hours worked.

Example B. Computing Weekly Wages

1. start
2. get hours worked
3. get pay rate
4. if hours worked ≤ 40 then
   4.1 gross pay = pay rate times hours worked
   4.2 proceed to line 6
5. else
   5.1 gross pay = pay rate times 40 plus 1.5 times pay rate times (hours worked minus 40)
6. display gross pay
7. halt

This example introduces the conditional control structure. On the basis of the True/False question asked in Line 4, we execute Line 4.1 if the answer is True. Otherwise, if the answer is False we execute the lines subordinate to Line 5 (specifically Line 5.1) in order to include extended hours. In both cases, we resume the pseudocode at Line 6.

Event, Role and Scheduling

One of the more common approaches toward the organization and prioritization of task and activity is Gantt analysis which captures and depicts all of the critical events, the staffing roles, and any pivotal accomplishments. A sample chart for the proposed software business is provided below. Each phase of the business operation can be managed by a variety of strategies. The other strategies are illustrated at the end of this section and are provided for further reading and training.

Figure 3. Project Flow

The main design process requires nearly two months to complete (shown in blue starting Oct 4). The design is preceded by a preparatory phase that straddles the design process until just prior to completion (shown in light brown). The planning phase begins before the design process and ends immediately after the design is underway (shown in light blue). The entire product development effort culminates with software refinement nearly three months after the initial point of conception (shown in blue starting Nov 1). Three significant crossroads are indicated by the x, star, and triangle symbol that represent concept, provision, and deployment phases. In 1966, the Critical Path Method was used for the development of a major skyscraper while constructing the former World Trade Center in New York City. Although Critical Path Method is no longer in use, it was successfully applied to project management of resources and workmanship for the completion of an expansive architectural complex within a restrictive metropolitan site.

Figure 4. Applied Flowcharting

(Note: PERT is Project Evaluation and Review Technique. CPM is Critical Path Method.)

Conclusion

The array of techniques available for defining a software product are only part of a larger manufacturing cycle. The practice is more readily referred to as prototyping which typically involves the process of building a less obtrusive model of a system. This prototype converts early specifications into a limited working model of the proposed system. An iterative process which results in an initial set of software requirements, prototyping helps a designer build a product that is intuitive and easy to handle. As one might expect, many businesses use multiple prototyping tools for robustness. One common option is through paper which can be used in the early phases to facilitate feedback on obstacles or features. The flowchart and pseudocode described above are mainly distributed through paper. Secondly, the development of a functional prototype can then be modeled by using computer-aided software engineering or fourth generation languages. In hindsight, the emulation phase can seem tedious or counterintuitive; but, the advantages in time and cost can be significant. A business environment open to simulation can reap invaluable insight into the provisions needed to bolster a product line, in any given business field.

Figure 5. Product Refinement