flipturn.org - stuff. things. other stuff.
dvorak | pantera | hacks

Iteration3

Phase: Elaboration

See ProcessOverview for a description of the process I'm going to be following as I develop this project.

Management

  • Phase goal: Plan development.
  • Iteration goal: Further refine the vision and architecture. There will probably be at least 3 more iterations in the elaboration phase, because this is going to be a fairly large framework.
  • Artifacts: Business Case | Software Development Plan | Vision | Work Breakdown Structure | Status

OK, I really mean it (since I didn't do it in Iteration2): I'm going to be expanding the Vision, Software Development Plan, and WBS during this iteration, but they aren't going to be baselined until the Architecture Lifecycle Milestone.

The Business Case is the least developed of the documents, since I have the least experience in the business side of software operations and can't find relevant examples.

The Software Development Plan will have some meat on it eventually, because that will describe the development process that I'm going to use. It's currently just an outline.

I suspect that the WBS will not be too detailed because I don't understand its usage that well. Alas, the lack of examples!

Environment

  • Phase goal: Install development environment and change management database.
  • Iteration goal: Install the Trac server.

Again, I really mean it: I want to set up a Trac server to satisfy the change management database, but I have to figure out how to do that in my hosting environment.

Requirements

  • Phase goal: Define architecture objectives.
  • Artifacts: Use Cases | Release Specifications | Vision

The architecture objectives are evolving and are described in the Architecture document.

For this iteration, I want to expand the architecture to:

  • incorporate an abstract data source so that I can have different types of backend storage. Currently, everything uses the STC, but I want to abstract that so that other forms can be used. I still think that the interface will conform to the STC interface defined in the STCInterface class, but the data storage won't actually be an STC
  • look into the menubar/toolbar design, because I don't think that it's scalable as is.
    • related: come up with a better way to link menu items to the view rather than the menu plugins module-level global, or at least tie the pluginkey with the view name. Also, use the class hierarchy to select which menu items to display
  • find a robust configuration system, where I can load and save user preferences

Design

As an example of supporting an abstract data source, I want to integrate PyPE's Python and command shells into peppy.

Implementation

  • Phase goal: Produce architecture baseline.
  • Created a cascading configuration system, where View subclasses will look to their parent classes for configuration items that aren't explicitly specified in the subclass.
  • Borrowed trac's plugin architecture for Views and Protocols

Assessment

  • Phase goal: Assess architecture.
  • Artifacts: Release Specifications | User Manual

This is an example of how the iterative development process works. Initially, I thought this iteration would be focusing on the abstract data source, but out of the blue I ran across Trac's plugin architecture and ended up focusing on that instead.

  • Installed trac.
  • Implemented plugins
    • sample goto line plugin
  • Implemented cascading config system.
    • Somehow I need to integrate plugins and the cascading configs so that I can have plugins be tied to a View subclass. For instance, it would be good to have a search plugin for a Fundamental view, but a different search plugin for a HexEdit view. Or, a better example, having the source code indention be based on a plugin so that the Javascript View and the C++ View could share the same indention code but not be subclasses of each other.
  • Deferred the abstract data source to Iteration4 (or later).
  • Evaluated the scalability of the menu system, and I'm going to defer refactoring for performance until later. The speed of the system is adequate for now, despite the fact that the menubar is rebuilt from scratch every time the view is changed or a new tab is selected.
  • Moved the module-level globals for menus, toolbars, and keyboard actions into the View as cascading attributes named defaultsettings.

Deployment

  • Phase goal: Define user manual.
  • Artifacts: Executables | User Manual | Developer's Guide

Templates of these artifacts now exist, but there's not much detail as I don't want to spend too much time at this point when there may still be major changes as the architecture changes.

Milestone

  • 17 Dec 2006: installed subversion on flipturn.org
  • 19 Dec 2006: installed Trac
  • 23 Dec 2006: completed implementation for this workflow
  • 24 Dec 2006: released 0.3.0