Software Process

The software process is the organized process of creating software, from its inception to obsolescence.

Software engineers broke down formally the software process into five stages:

  • Analysis
  • Design
  • Implementation
  • Testing
  • Deployment

Different software methodologies integrate these stages in their own way.

 

Analysis Stage

In the first step, we identify the whys of the software: what it will accomplish. This is done by:

  • Requirements specification
  • Use Cases/Storyboarding

Requirements specification is a document that:

  1. Details the functional (specific actions done) and non-functional (system constraints) requirements of the software.
    1. Functional example: System must authenticate user prior to servicing him/her.
    2. Nonfunctional example: System must authenticate under 1 second.
  2. Translates what the business owners want out of their software product into technical specifications as reference for the project team.
  3. Is a predictor of costs, production schedules, and risks of the software.

We record the steps of hypothetical cases of using the software called use cases. Example:

  Use Case: Eating

  1. Cat opens door.

  2. Cat pushes a dispenser button.

  3. Dispenser gives food.

  4. Cat eats food.

    Variation #1:

  5. Cat cannot open door.

  6. Cat waits for customer service.

  7. Continue with step 2.

Storyboarding is basically use cases but pictorially illustrated. Example (from wiki):

776px-Storyboard_for_The_Radio_Adventures_of_Dr__Floyd

 

Design Stage

Here, we plan what classes of objects will exist in the software and what each class is responsible for. This is done with:

  • CRC cards
  • Class diagrams
  • Sequence diagrams
  • State diagrams
  • Outlines in Javadoc

CRC cards are paper index cards used to identify:

  1. Classes that will exist in your program (usually the nouns found in the analysis stage)
  2. Responsibilities of those classes, ie. the methods (usually the verbs)
  3. Collaborators of each responsibility (which other classes are involved in each method)

crccard

Class diagrams are tables showing classes, their variables and methods, and relationships between them using arrows:

RELATIONSHIP Description Arrow Human Class Example
Aggregation Has as instance/class variable, “has-a” aggregation Has Arm
Dependence Manipulates, “uses” dependence Uses Food
Inheritance Subclasses, “is-a” inheritance Is Animal
Implementation Implements interface implementation Implements Worker

Example:

372px-KP-UML-Generalization-20060325_svg

Sequence diagrams show the timeline of a typical program run, in method calls (and optionally their return values). Example:

sequencediagram

State Diagrams show a program in different states with actions between them. Example:

statediagram

Outlining in Javadoc is writing Javadoc comments before blank classes and methods (“a program skeleton”) that would be filled out in the implementation stage. Example:

/** Cat.
     @author David Hsu
*/
class Cat
{
     /** Say something.
          @param what what to say.
     */
     void say(String what)
     {
     }

     /** Sleep.
          @param minutes number of minutes to sleep.
     */
     void sleep(int minutes)
     {
     }
}

 

Implementation Stage

Here, we give substance to the design of the previous stage by means of programming code.

Implementation may only result in a prototype (“earliest-type”), meaning incomplete software, but may still be runnable and it can be built on later.

 

Testing Stage

Here, we test the implemented product in all its aspects to ensure that each works properly.

Different kinds of testing exist, including:

  • Unit – testing each module of a software separately, to ensure it is working properly.
  • Regression – re-testing a software when a new feature has been added, to ensure it broke nothing that is older.

 

Deployment Stage

Here, the software product is released to the targeted audience.

This may include both installing and configuring the product on target systems.

 

Methodologies

Methodologies have been created to involve the above software stages in different ways to suit different software, most famously:

 

Waterfall Methodology

waterfall

The software process steps are done in sequence, but no step can be returned to after finishing it.

Its disadvantage is risk, because steps are often mistaken for finished when it really isn’t.

Its advantages are simplicity (and thus manageability) and suitable use in small projects where requirements are well understood.

 

Evolutionary Methodology

The software process steps are done in order, and any of those steps can be revisited at any time, as opposed to Waterfall.

 

Spiral Methodology

spiralmodel

The waterfall model but with all the steps repeated some number of times.

The products of the first few cycles are called prototypes (“earliest types”). A user interface prototype is common for this.

 

Extreme Methodology

This is a methodology that simplifies development by removing formal practices and focusing on the “best practices”, including:

  • Minimalizing the software (removing unnecessary things)
  • Refactoring (simplifying) code
  • Conforming to readable coding standards
  • Pairing programmers for tasks
  • Re-testing the whole software whenever a new feature is added
  • Scheduling consistent work hours to stabilize progress
Please like & share: