Weaknesses of RAP Software Process

• Software engineers stuck in a single project
• Project resource hoarding
• Unit and system testing

• Automated testing
• Test discussions
• Test training

• Communication and information sharing within and across projects
• Software estimation in proposal development
• Managing requirements
• Scope creep
• Not always sticking to stated goals
• Integrating software developed by scientific staff into engineered systems
• Training/professional development opportunities
• Code re-use and sharing

• Data formats—need ways of dealing with multiple formats. Conversion problem is difficult and often ad hoc.

• Internal and user documentation

• Design documentation
• Can improve on UML usage
• Lack of design discussions
• Lack of availability of design documentation
• Minimal design documentation often absent for modules. Perhaps a page explaining the thinking behind the design for a module

• Problems separating proprietary code from “open source”
• Inconsistent naming of releases
• Four different framework/environments at RAP. There's a need for more cross-pollination between them

.

Strengths of RAP Software Process

• Non-uniform process
• RAP’s emphasis on being agile and building good software is working well.
• CVS and nightly build

• Re-usable code -- can be used to piece together a complete working system.
• Software engineering internal website

• Successful iteration with users
• Hands-off management

• Open, fairly non-critical environment
• Easy to try new approaches

• Commitment to innovation

o For example, exploration of GIS

• Interesting, cutting edge products
• Creative environment

• Talented staff
• Communities such as Java community and Matlab community

• Flexibility across projects
• Talented, experienced people
• Working on multiple projects-a way to share ideas
• Access to tools such as Purify, Insure, J Builder
• Commitment to meeting deadlines for releases

• Pair programming works in right circumstances
• System integration testing
• Strong project focus

• Good use of status meetings (on some projects)
• Mechanism for external consulting

Evidence of Strengths

• Minimal staff turnover

• Good track record
• Strong growth
• Good working environment

Ways to Improve

• Routine reassessment of priorities and goals is important

• Projects should consciously identify the software process to be used.
• A software process checklist would be helpful to identify the appropriate process

o Initial planning tool

o Post-analysis tool

• The software process for a project should be reviewed at regular time intervals
• Software process needs buy-in from project stakeholders including engineering, management and scientific staff
• Projects should be allowed to pick and choose their process as opposed to having one imposed externally. The project process would adapt to the needs of the project. (Process is non-mandatory and non-uniform.)
• Software process engineering seminar series
• More training opportunities are desirable
• Books
• Video
• Classes
• Further development of RAP’s software engineering web site would be of interest
• Software engineering helpdesk
• Encourage refactoring
• the most important “missing element”

o needs to be included in planning/schedules

• Attention to estimation and requirements management
• Documentation: Recognize that complete documentation is not a practical goal. Therefore, concentrate on important and useful docs:

o Comments in code

o Example usage

o Readme files

o Design docs

o As-built docs

· Testing: As with documentation, recognize that complete formal testing is not a practical or attainable goal at RAP. Therefore, concentrate on the testing which is affordable and effective:

o Individually test code modules as they are written

o Check test suites into CVS

o Simulation/end-to-end tests can be performed in conjunction with nightly builds

o Pre-release testing-code, freeze and test.

• Encourage the use of software patterns or paradigms
• It’s worth taking the time to determine a format or template for documentation, checklists and examples
• Working groups for data formats.
• Cross pollination is effective technique for encouraging reuse

XP

• Pair programming
• Works well in the right circumstances:
• Suitable personalities
• Design phase
• Complex and important infrastructure
• Mentoring new team members
• User stories
• Lots of testing
• Iterative
• UML/design (but not over design)
• Refactoring
• Keep it simple
• Reusable infrastructure
• “They’re Just Rules”

Software Process Spectrum

• Research code – Deliverable System
• Anarchy – Rigor

• Throw Away – Reusable
• Slow – Fast
• Cheap – Expensive
• Bad – Good

Lessons Learned

• Commitment to goals
• Important to find balance between process and organized chaos
• Reliability of software is particularly important for novice users/customers. Unreliable software undermines confidence.
• Cutting edge technology comes at a price