Development Strategies

The following is based on a document provided by sonya, lead developer for iPlant. Points 1-5 apply mainly to the engagement teams.

While commercial product development efforts focus upon opportunity, scientific efforts should focus more upon problems, therefore, a modified approach should be adopted. With this in mind, the product development life cycle (PDLC) for iPlant Collaborative should, at a high level, look something like this:

1. Problem Identification

Identify the high level domain problems that must be solved. What problem does the user have that leads them to use the potential product? For example, tree visualization is not the problem that a user has when they make use of a tree visualizer, rather, they have some scientific problem to solve and the visualizer is simply a tool. What are the problems they are trying to solve?

2. Persona Identification

Please see this document for more information about iPlant user personas.

Identify the relevant personas. Who are the people who will be using the system? What background will they bring with them? What kinds of problems will they be attempting to solve?

3. Persona - Problem Mapping

Which personas will use the system to solve which problems?

4. User Story Identification and Development:

We now know the personas and the problems and have mapped them together, next it is time to describe the user experience. For example, persona Doreen wants to solve problem B. What does her interaction with the system toward that end look like?

5. Product Identification:

Once the set of user stories is well understood, they can be grouped logically into products. A product is defined at the level of the user. What functionality makes sense to group together from a user perspective?

Once user stories are developed, a software solution can be designed and developed.

6. Requirements Elicitation and Documentation:

The user stories previously developed should be further enhanced and matured.

7. Design and Development:

Design decisions should consider the user requirements, but the architectural principles and constraints of the system within which the product will be integrated carries equal weight. This phase should produce working software solutions with sufficient accompanying unit test coverage.

8. Quality and Performance Assessment:

All software components must endure rigorous functional testing and performance profiling. Benchmarking is performed at this stage and result are used for
decision-making. Defect reports and test results are the products of this stage.

9. Release Management

Product releases require coordination as multiple software components contribute to a single product. Configuration management, release building, and packaging are all performed as a part of release management.

10. Maintenance

Defect correction, regression testing, and refactoring are all parts of the maintenance effort which is usually managed at the component level and also at the level of products.

This description is only a starting place that focuses mostly upon processes currently in the critical path. These, though numbered sequentially, should not be taken to be serial processes, rather, they should be iterative and parallel.