2017-03-12 | ../../

Android Development #4: Better Quality Software

Table of Contents

1 Waterfall Model

  1. There is a widely accepted model, called the waterfall model, of software development that labels four consecutive phases: Requirements, Specs, Design and Implementation.
  2. There are feedback loops among these.

2 Requirements

  1. A Requirements Document describes the software project at its conception. It is written from the perspective of its would-be users.
  2. Unless the project topic/ domain is well known, such as editors, compilers, etc., it should explain where it is coming from.

2.1 User Level Documentation

  1. Initial draft of a Users' Manual. This includes a good description of "what" the software does, but also gives a model and terminology so that the software can be understood.
  2. The user-level documentation is, e.g., what you see on Google Play along with an APK that you are about to download.

2.2 Acceptance Test

3 Specs

  1. A spec describes the software (yet) to be built. From the perspective of the developer.
  2. There are many independent axes. The top two most important ones are (i) Functional Specifications (ii) Resource (CPU, memory, file space, battery, …) specs. Read the article by Hoare (in the refs).

4 Design

  1. A design starts with the "what" described in Specs and develops a plan of "how" to carry it out.
  2. Languages for design exist, but have not become widely known. Design descriptions are often in pseudo code. Frequently use diagrams. E.g., UML.
  3. A practical suggestion is to write the design in a very high level programming language. E.g., if implementation is to be done in Java, do a design in Python or Haskell.

5 Implementation

  1. Implementation is about bringing the design description into a buildable/ executable program/ app. It includes testing and debugging.
  2. A program written in (low level procedural languages such as) Java, C++ are implementations.

6 Refactoring: Eliminate Bad Code Smells

7 Program Comprehension

  1. Enahancing/ Correcting existing code is the daily grind for a software engineer. One should learn to engineer (re-engineer) software so that it is easy to carry this out. A complementary skill is to know when to treat a portion of code as black box, and when to treat it as a transparent box.

7.1 Understanding Clever Algorithms

  1. Understanding large programs is different from understanding tiny programs that are implementations of intricate algorithms.
  2. E.g., if someone gives you the code, with no comments whatsoever, for Heap Sort and you have never before encountered such algorithms, we doubt that you can discover how these algorithms work by reading the code. Abstract descriptions of such algorithms are essential.
  3. {Comprehension PDF Required Reading Assignment}

7.2 Understanding Large Programs

  1. This section is focused on large (> 1000 SLOC) programs, whose source is available.
  2. Build the "big picture". Gradually. Build architectural diagrams, class diagrams, data flow diagrams, who-calls-who diagrams, …
    1. UML is a widely used drawing notation.
    2. UML includes TBD that is focused on math logic based assertions.
    3. TBD is not as well-known but is a highly effective notation.
    4. State Diagrams and State Charts are part of UML. David Harel, Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274, June 1987. PDF
  3. As you understand the code, insert comments. If unsure about the validity of a comment, tag it so, and keep revising.
  4. Unit testing and Refactoring improves your understanding of specific classes and methods.
  5. Who calls who? Build lists of callers of each method.
  6. Build lists of library calls. Build lists of system calls.

7.3 Use Assertions

  1. For every class, discover its class invariant. Write it as a "formal comment" (e.g., Java asserts).
  2. For every method, discover the entry and exit assertions. Write these as "formal comments".
  3. ../Assertions

8 Developer Documentation

  1. The developer documentation is aimed at software developers who may develop the software further in the (near) future. It includes descriptions of Requirements, Specs, Design and Implementation.
  2. Implementation documentation requires more than a few comments sprinkled within source code. It should minimally do a doxygen generated web, based on extensive use of javadoc assertions.
  3. Read the lecture notes on TBD Program Comprehension (i) Include a users manual in the report. (ii) Upload the developer documentation to GitHub.

9 Resources Usage

How to read a file located at a server on the Internet? How to write a file?

9.1 Low Battery Usage

9.2 Speed Improvement/ Lag Reduction

10 References

  1. Sir Charles Anthony Richard Hoare, On Software Quality, Software – Practice and Experience, 103-105, 1972. Turing Award Winner. Required Reading.

11 End

Copyright © 2016 www.wright.edu/~pmateti 2017-03-12