practice-guides
Getting Started with PSIP
Why Practice PSIP?As you already know, PSIP framework is an iterative, incremental, repeatable, cyclic process for improvement planning. The cyclic nature of PSIP enables you and your team to improve overall project quality and achieve science goals by encouraging frequent iteration and reflection.
PSIP consists of seven simple steps, as described below and on the next pages. You and your team can work through these steps on your own, or with the assistance of a PSIP facilitator. The process described below assumes that you and/or your team will be practicing PSIP on your own by following the guides.
The key to PSIP is understanding where you are starting from, setting goals, and tracking your progress. The way you implement PSIP is by creating and using progress tracking cards (PTC).
Step 1: Summarize Current Project Practices
The first step to PSIP is to have a good idea of your current state of practice and to document it. You’ll want to have a record of the original state of your project to create a baseline for measuring progress and to help identify areas that are ready for improvement.
To do this, imagine that you are telling a stranger or your best friend about your project using the bulleted lists below as a guide. How do you describe your project? Write a short paragraph summarizing your project practices.
Use plain language and define your terms. That way, you’ll be able to reduce any misunderstandings that might arise from a vague term or one that may have several meanings to different people. Your goal in this step is to be as accurate as possible about your project. The details below are excerpts from the BSSw PSIP Overview:
Describe the overall software development process used by the project, emphasizing what is most important for productivity and sustainability.
- How software requirements are determined and transformed into implemented code, tested and deployed (the software lifecycle)
- How integration of new and revised capabilities into the existing software will preserve existing capabilities (regression testing)
- How users will learn about utilizing the code in their scientific efforts (documentation and training)
Describe your tools and processes.
- Source management tools and processes (how source code will be developed and managed)
- Issue tracking tools and processes (how feature requests and software faults or “bugs” will be recorded and managed)
- Testing tools and processes (how tests will be invoked and reported)
- Software distribution tools and processes (how will users and collaborators access software products)
Describe training.
- How new software developers will be trained
- How the value of the work of departing developers will be retained
Describe improvement strategies.
- How you presently improve software productivity and sustainability
- How improvement efforts will be rewarded
Any software used but not developed (a.k.a, third-party software)?
Use of third-party software typically reduces the cost (time and effort) compared to developing the same capability independently. At the same time, it also increases risk and complexity. If your project makes significant use of scientific software developed by others, the following topics should be addressed:
- Describe how the third-party software is tested for correct behavior, initially and when upgrading to a new version (verification and validation)
- Describe how loss of functionality via faults and missing features is handled by the third-party software
- Describe how complete loss of the third-party capability would be addressed by the application (risk mitigation)
Ready to move to the next step?
Step 2: Set Goals