RSS

Tag Archives: SOFTWARE ENGINERING GOALS

Muhammad Umer Haroon | Engrmuh

CHECK MY PORTFOLIO HERE :

 http://engrmuh.wix.com/portfolio

CHECK MY CV HERE :

 http://engrmuh.wordpress.com/

 
Leave a comment

Posted by on May 26, 2013 in Uncategorized

 

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

SOFTWARE ENGINERING GOALS

  • 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.

 

 
1 Comment

Posted by on June 3, 2011 in Uncategorized

 

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