Developing software for small-scale embedded applications is different from developing large-scale software applications. Large-scale applications use commercially available ‘one fits all’ software development solutions that are difficult to scale downward and usually miss the desired process goals. In many cases, developing a small-scale software application development process within an existing corporate environment is quicker, less expensive, and results in superior developer productivity and product quality.

Figure 1: A selected group of use-case instances describe an iteration cycle in the implementation and test and verification phases of the development process.

Software pioneer Grady Booch famously commented that, “Building quality software in a repeatable and predictive fashion is hard.” This statement not only describes the difficulty of the software development process, but also describes the primary goal of any software development process — software products should be defect-free, maintainable, and have veracity requirements to guarantee successful operation.

Software development processes can be fully described by four orthogonal views: methodology, process artifacts, process procedures, and quality assurance. This article will focus on the methodology view.

Analysis Phase

The small-scale application development methodology is best described as a use-case-driven “hybrid spiral” (part waterfall, part iterative). The analysis phase is the waterfall portion of the hybrid. The ability to perform this upfront analysis in detail is a unique advantage of small-scale development.

The cornerstone artifact of the analysis phase is a software requirements document (SRD) that details the requirements in textual use-case sequences, top-level state description, and a hardware interface list. This is an artifact that is maintained throughout the product lifecycle. The product SRD largely consists of textual use-case sequences, which drive the rest of the development (i.e. object identification via sequence diagrams, test cases, and schedule).

Figure 2: Iterative development is use-case-driven; they are the information baseline source for all other documents.

Avoid any process of requirements discovery that includes partial design and implementation of the software product; this is very inefficient. Changes in the requirements will occur, prompting updates to the SRD, but an efficient development process means that the designers should make every attempt to unambiguously define the requirements of the customer up front. The process should also accommodate existing processes within the design company, including manufacturing, quality assurance, marketing, and engineering requirements.

Earlier, small-scale application development was defined as following a waterfall and iterative process. An iteration is the software development of one or more use-case scenarios. A schedule, developed as part of the analysis, defines the order of iterations for the implementation and test phases of the process. This order is decided based on customer needs, risk identification, and the importance of each use to the end product. Designers should schedule uses that contain risk items first, using functionality as the variable, and commit to delivering product on time.

For schedule documentation, spreadsheets work fine: one worksheet describes use case delivery, while a second details design, implementation, and verification efforts for each object as they are identified. Once the initial schedule is developed, modifications take less than five minutes per week.

« Start Prev 1 2 3 Next End»

The U.S. Government does not endorse any commercial product, process, or activity identified on this web site.