I do. Are you ready?

"First they ignore you, then they laugh at you, then they fight you, then you win."
-Mahatma Gandhi
Applications may not be designed or marketed for real time route guidance; automatic or autonomous control of vehicles, aircraft, or other mechanical devices; dispatch or fleet management; or emergency or life-saving purposes.Doesn't that suck? Just what exactly are we to do with our iPhones* if we can't blow something up?
Planning. This activity isolates requirements and, based on these, develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.I'm not sure if what I'm doing will fit into this personal model of development, but it's thought provoking. Even if I don't collect data about what my problems might be and then analyze the data about what actually went wrong, I can still hold myself to some kind of process. Even though I don't have a deadline or an antsy customer to deliver this to, I can possibly eliminate shortfalls if I just think it out before delving into code.
High-level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are build when uncertainty exists. All issures are recorded and tracked.
High-level design review. Formal verification methods... are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.
Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
Postmortem. Using the measures and metrics collected (a substantial amount of data that shoul be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
Pressman, R.S. (2005). Software engineering: A practitioner's approach. New York: McGraw-Hill.