RSS

SOFTWARE ENGINERING GOALS

03 Jun

  • All programming projects should begin with functional descriptions which become the highest level pseudocode. Every module and every routine, high or low level, should have a functional description approptiate to its level of abstraction.
  • Functional descriptions determine high level pseudocode should be iteratively refined to low level pseudocode. The pseudocode becomes internal documentation.
  • Pseudocode should be organized into modules, thus ultimately organizing the project into modules.
  • Computer code for all routines and main programs should be generated from low level pseudocode. The pseudocode should become internal documentation.
  • Module interface specifications should be created so that modules may be created independently.
  • Programs should be constructed from modules.
  • All support routines should reside in separately compiled modules.
  • Each module should only contain routines whose functions are related.
  • Inter-module communication should be accomplished solely through passing parameters. No global variables should be used. Parameters should be passed “by value” where required access is read-only.
  • Communication between routines in the same module should also only be accomplished through parameter passing.
  • Low level routines should have simple and explicit functions. For example low level routines should not do any I/O (especially interaction with the user) unless that is the sole function of that routine.
  • Support routines should be evaluated with respect to flexibility and efficiency.
  • Include files should be used where required to effect inter-module independence and consistency. For example data-type definitions should be included to attain consistent definitions global to all modules.
  • Changes (such as changes to underlying data structures) in low level routines should not require source code changes in high level routines. This is accomplished by carefully constructing the calling interface to adhere to data abstraction principles.
  • Changes (such as changes to the driving application) in high level routines should not require source code changes in low level routines. This is accomplished by carefully constructing the calling interface to adhere to data abstraction principles.
  • Changes to high level routines should not require low level routines to be recompiled.
  • Changes to low level routines should not require high level routines to be recompiled. (This is generally very difficult to achieve.)
  • Modules should be constructed so that private support routines are not accessible outside the module. This may be accomplished using submodules or language-dependent protection mechanisms.
  • Modules should be constructed so that internal data structures can be accessed only through authorized routines.
  • All program changes should start with a change to the highest level pseudocode appropriate to that change. This ensures that pseudocode accurately reflects the structure of the underlying code.

 

Advertisements
 
1 Comment

Posted by on June 3, 2011 in Uncategorized

 

Tags: , , , , , , , , , , ,

One response to “SOFTWARE ENGINERING GOALS

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