Primitive views of the Software Design

News Software Engineering Recommended Links Software Prototyping Simplification and KISS Real Insights into Architecture Come Only From Actual Programming Virtual Software Appliances
Software Prototyping Software Life Cycle Models Unix Component Model Primitive views of the Software Design ITIL as cognitive capture Project Management LAMP Stack
Refactoring vs Restructuring Perl-based Bug Tracking Distributed software development Exteme programming as yet another SE fad anti-OO CMM Design patterns
Bad Software  Brooks law Conceptual Integrity Code Reviews and Inspections Conway Law Document Management Systems Featuritis
Cargo cult programming CMDB  CMM (Capability Maturity Model) Agile -- Fake Solution to an Important Problem Slightly Skeptical View on Extreme Programming Compilers Algorithms  
Version Control & Configuration Management Tools Programming style Unix Component Model Software Architecture courses Inhouse vs Outsourced Applications Development Humor Etc

Usually a complex system that works is invariably found to have evolved from a simpler system that works and on which system architecture was refined. That's is the idea of Software Prototyping (which is present in Rapid Prototyping Model and Spiral model)

But there are different more primitive software life cycle model that are reinvented under different names again and again. That means that they represent persistent cognitive approaches to solving this problem. While such approaches are often wrong and typically are far form perfect that also means that  they probably have some narrow areas of applicability.  For example a simple, well defined, easily split into semi-independent modules software can probably be developed using waterfall life cycle model.

The Software Life-Cycle Models

Waterfall Model

Waterfall model

(1) The feedback loops permits modifications to be made to design documents, the software project management plan, and even the specification document, if necessary.

(2) No phase is complete until the documentation for that phase has been completed and the products of that phase has been approved by the SQA group.

(3) Once the client has accepted the product, any changes constitute maintenance.

(4) Inherent in every phase is testing.

Software configuration is the entire set of documents, including specification document, design document, code, user manual, operations manual, etc.

Rapid Prototyping Model

Rapid prototyping model

A rapid prototype is a working model that is functionally equivalent to a subset of the product.

(1) Because the working prototype has been validated through interaction with the client, the resulting specification will be correct. Therefore a major strength of this model is that the development process is essential linear with little or no feedback loops.

(2) In specification, planning and design, verification is needed. In implementation and integration, testing is needed.

(3) An essential aspect of a rapid prototype is in the word rapid.

(4) We can combine waterfall and rapid prototyping, by using rapid prototyping to find out the client's requirements.

Incremental Model

Incremental model

A build consists of code pieces from various modules interacting to provide a specific functionality.

(1) Each build is designed, coded and integrated into the software structure that is tested as a whole.

(2) A typical product will consist of 10 to 50 builds. With the incremental model, something will be working within weeks, with the rest delivered incrementally.

(3) Product can be introduced into the client's organization gradually.

(4) Problems of integration, changes in requirements, "shooting at a moving target".

Spiral Model

Spiral Model

(1) The essential concept is to minimize risks by the repeated use of prototypes and other means.

(2) Unlike other models, at every stage risk analysis is performed. Risk may be cost overruns, schedule delays, etc.

(3) This model, invented by Boehm, is intended primarily for internal development of large-scale software.

Capability Maturity Model

CMM is not a software process model. Instead, it is a strategy for improving the software process.

(1) CMM assists organizations in providing the infrastructure for a disciplined and mature software process. The CMM strategy is to improve the management of the software process, in the belief that this will lead to improvements in techniques.

(2) Maturity Levels:

Maturity Level           Characterization
--------------           ----------------
1. Initial               Ad hoc process
2. Repeatable            Basic project management
3. Defined level         Process definition
4. Managed level         Process measurement
5. Optimizing level      Process control

(3) An organization can assess maturity using a series of questionnaires developed by CMU's SEI (Software Engineering Institute). Thus this approach is good for organization which must access software procurement.

(4) The software maturity model emphasizes measurement, training and retraining of software personnel, and quality control of the software process. But it also increases productivity, as a software development organization moves up to higher level of maturity.

ISO 9000

(1) ISO 9000 is not just a software standard. It can also be used to certify an organization. It emphasizes documentation.

(2) ISO 9000 emphasizes documenting the process in both words and pictures to ensure consistency and comprehensibility.

(3) Like Software Maturity Model, ISO 9000 also emphasizes measurement.

Class Room Discussion

Discuss the sort of product that would be an ideal application for the (a) waterfall, (b) rapid prototyping, (c) incremental, (d) spiral model. For each case one person can present the advantages of a certain model for a certain application, and another person can try to present the disadvantages.

Examples: Payroll, electronic game, airline reservation, AI system to recognize handwriting, total quality management system for managing a very large company, teleconferencing system, etc.

Software Engineering The Software Life Cycle

The goal of software engineering is to develop software that satisfies and possibly exceeds the customer's expectations, is developed in a timely and economical fashion, and is resilient to change and adaptation. Such software

This document provides an overview of the software engineering process and although the process is described in terms of phases, the phases are usually, iterative, incremental and to some extent, concurrent. When the phases are sequential, the life-cycle is called the waterfall model, when the phases are sequential and iterated, the life-cycle is called the spiral model. The spiral model is superior to the waterfall model when resources are limited.

Conceptualization Phase

Conceptualization produces a statement of the problem and the desired solution. The output of the conceptualization phase is a requirements document.

For most programming exercises, there is no conceptualization phase, the requirements document is the problem assigned as a programming exercise.

Analysis Phase

Analysis starts with the requirements and produces a specification of what the system does. The output of the analysis phase is a specification document.

For most programming exercises, the analysis phase

Design Phase

Design begins with the specification and produces a description of how the system will be built from implementation-oriented components. The output of the design phase is a design document.

For most programming exercises, the design phase

Implementation Phase

Implementation begins with the design and produces an encoding of the design in a programming language to produce a working system. The output of the implementation phase is code.

For most programming exercises, the implementation phase should be a straight forward translation of the design into code and the program should be thoroughly tested for compliance with the specifications.

Maintenance Phase

Maintenance begins when the system is put into service and is concerned with managing the evolution of the system in response to changing requirements.

For most programming exercises, there is no maintenance phase.


A program to compute the circumference of a circle given its radius.
Users will invoke the program via the command circle which then prompts the user for input. Upon receiving the input, the program displays the result and terminates. The data objects required by the program are the radius and the circumference which are related through the formula: Circumference = 2 Pi radius. They should be floating point numbers. The value of Pi will be a constant internal to the program. In addition, a prompt for user input and labeling of the program output is required.

In the following sample run of the program, the system prompt is > and user input is in italics.

> circle

Enter the radius: 34.56

The circumference is: 1953.33


Errors: Given a negative value for a radius the program will compute a negative circumference. Given non-numeric input, the program behavior is unpredictable.

Data Structures
The constant Pi of value 3.14, the variable radius of type floating point.
Prompt and read the input, the formula C=2 Pi R, for computing the circumference, implemented as a function, and labeling of the output.
Program Structure
  1. GetInput ( radius )
    1. Display prompt
    2. Read radius
  2. DisplayResult ( Circumference( radius ) )

Code (C++)

Description: A program to compute the circumference of a circle 
Input: The radius of the circle 
Output: Prompt for input, labeled circumference of the circle
Programmer: A. Aaby
Date: January 13, 1993
Revision History:
#include <iostream.h>
The Get Input Function 

Description: Prompts for input, input must be a real number
or an integer.  Other input may cause the program to abort.
Precondition: None
Postcondition: The parameter, r, is a number
void GetInput(float &r)
    cout << "Enter the radius: ";
    cin >> r;
Function implementing the formula C = 2*Pi*R 

Precondition: r is a real number 
Postcondition: Circumference = 2*Pi*r 
void Circumference(float &r, float &C)
    float Pi = 3.14;
    C = 2*Pi*r;
The Display Result Function 

Precondition: parameter C must be a number
Postcondition: C is printed, labeled as the circumference  of a circle
void DisplayResult(float &C)
    cout << endl << "The circumference is: " << C;
The Body of the program  
void main()
    float C = 0,r = 0;
Code (Pascal)
PROGRAM Circle (Input, Output);

Description: A program to compute the circumference of a circle 
Input: The radius of the circle 
Output: Prompt for input, labeled circumference of the circle
Programmer: A. Aaby
Date: January 13, 1993
Revision History:

CONST Pi = 3.14; { an approximation to pi }

VAR radius : REAL; { the radius of the circle} 

The Get Input Procedure  

Description: Prompts for input, input must be a real number
or an integer.  Other input may cause the program to abort.
Precondition: None
Postcondition: The parameter, R, is a number


      Write( 'Enter the radius: ');
      Readln( r )

Function implementing the formula C = 2*Pi*R 

Precondition: R is a real number 
Postcondition: Circumference = 2*Pi*R 

FUNCTION Circumference( r : REAL ) : REAL;

      Circumference := 2*Pi*r

The Display Result Procedure  

Precondition: parameter C must be a number
Postcondition: C is printed, labeled as the circumference  of a circle

PROCEDURE DisplayResult( c : REAL );

      Writeln( 'The circumference is: ', c:5:2 )

The Body of the program  



The program is validated by providing sample runs of the program using positive and negative integers and real numbers which demonstrate the range and precision of the program.

Top Visited
Past week
Past month


Old News ;-)

Recommended Links

Google matched content

Softpanorama Recommended

Top articles




Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: May 15, 2019