The Practical Software Methodology can help any size company – from early start-ups to large enterprise software application companies – with the art of doing software right.

Practical Software Methodology preceded Agile and was improved and matured in parallel with the Agile movement. Practical and Agile share many of the same best practices and concepts, although facets of Practical Software should be incorporated into Agile to make it more effective and, well, practical. Practical Software Management incorporates effective tools and proven processes to deliver high quality software quickly and with agility.

To learn more about how the Practical Software Methodology was developed and the details about how it was applied, Jan’s book, “It Starts with an Idea,”, the book about her start-up, Intelic/Azerity, gives software engineers, managers, and CEOs insight into how to build “Practical Software” – software that is high performance, scalable, reliable, and robust – software that is on-schedule and low cost – using a software development methodology that is more agile than “Agile.” That’s practical software!

Practical Software for the 21st century

Practical Software Practices yield quality software products. Practical Software Practices includes a Practical Software Process for tracking software from inception to production, Practical Software Tools to enhance and enable the process, and the use of Practical Software Design for clean and simple architectures which enable efficient, high-quality products.

Practical Software Process
The Practical Software Process is a lightweight process supported by effective, useful tools.

Practical Software Design

Software architecture projects should always aim for simplicity of design. Over-designed, bulky software is costly to develop and maintain. How can you tell if you truly have a good design or not? Here are the five keys to good software design:

#1 Is there a simpler approach?
#2 Is it customer-focused?
#3 Is it designed for the expected user base?
#4 Was performance considered?
#5 Is it reliable, maintainable, supportable?

Read more in Jan’s Simplicity of Design Blog.

Requirements and/or Fuzzy Ideas Evolve to Final Requirements
Practical Software can start with either a detailed requirements/design spec or a fuzzy idea (similar to an Agile “Story”), available on-line for the developers to easily access and refer to. Unlike “Waterfall” or “phase-gate” methodologies, Practical allows and encourages updates to requirements/stories during design and implementation due to Product Owner (PO) changes or due to better solutions the developers identify during implementation. The final requirements must be on-line, up-to-date and accurate for QA to test against. Because the developers and PO work together, using the on-line requirements as an integral part of the process, requirements management is streamlined and effective. See who the users of on-line specs are in Who Needs Documentation?

Tracking Software Tasks
An easy-to-use, effective task tracker is a core part of the process. The Tracker must be web-based for access anywhere, must display all comments and discussions in an easy to review fashion, and must support key process tracking components (e.g., priority, severity, issue class, release and status).

Any spec changes must link to a task in a Tracker system to make the code change matching the spec change and visa versa. This yields a true iterative approach, very agile, and ensures on-line specs are always accurate and up-to-date. In addition, any other change due to a bug, customer issue, or need to refactor code must be represented by a task in the Tracker system. No change is made to the code without reference to the Tracker task it was made for.

Task requests can be entered by anyone – the Call Center, customers, services, the PO, developers, testers or managers. New requests are reviewed regularly by a cross-functional team and assigned to the appropriate release and organization to resolve them.

Development
Developers only work on tasks assigned to them to fix in the current release, considering task priority. A code reviewer is assigned to review each change. Developers are responsible for unit testing and first pass integration testing as their code is checked into the main branch.

Developers are also responsible for checking in any data schema changes or data migration required for their code changes so that all of the developer’s workstations use the data migration scripts which validates final production data migration for customers.

The PO, other stakeholders and testers are encouraged to review the release incrementally, as soon as a feature is sufficiently ready to evaluate. That way any misunderstandings or changes can be incorporated as early as possible into the cycle.

Final Testing
QA performs final regression test and final verification against completed spec requirements for release to production. Production releases should have no “known bugs”. “Known bugs” are where the code and spec are out of alignment and an issue is known that will cause a user difficulty. The amount and level of QA testing should be decided by the company based on product requirements. For example, products requiring FDA or government inspection sign-off would have more testers and a more stringent/longer test cycle than commercial software. A policy of “no known bugs” does not insure the customer will never encounter a bug because customers may use the software differently than anticipated. “No known bugs” should still be the goal. And using Practical Software Methodology, it can be done!

Iterative, Team-Based
Ensure cross-functional communication and collaboration with team-based, efficient processes and tools.

That’s practical !

Reference Articles

UCSC Practical Software blogs by Anita:
 Practical Requirements Management
 Practical Change Management
 Practical Test Management
 Practical Customer Support