Thursday, April 25, 2002

 
Brave New World? I just discovered a growing movement that centers on digital presence. What is it? According to a Primer on Digital Presence by Sean Gallagher it's defined as:
[T]he digital existence of a user—that is, a person, device or application—on a network. Being present ranges from simply being registered to actively participating with others.
It's being legitimized by the Internet Engineering Task Force in the form of an Instant Messaging and Presence Protocol work group charter, an independent, nonprofit consortium called the Presence and Availability Management (PAM) Forum, and a growing body of work. More information about the PAM forum can be found in PAM Forum Overview, and additional documents from various sources, including:This is not some obscure movement - at stake is our privacy and this movement may add some sanity to the Liberty/Passport services that are emerging as both competing web services and potential intrusions on privacy.
 
Planning Smarter: Creating Blueprint Quality Software Specifications is a new book that fills that unique niche between the dozens (or more) books on requirements, and the thousands of books about development.

Read this book with an open mind because it is going to expose specification and planning shortcomings in the major methodologies, such as the Microsoft Solutions Framework, Unified Process, Unified Modeling Language. In fact the author states in the preface that he does not expect readers to agree with everything in this book.

What I like about this book is that it's independent of methodologies and development environments. More importantly, it's not another methodology, but a short, focused book that will teach you how to make your existing methodology workable. It's also focused on the planning process and does not stray from it. Among my favorite parts are:

The book is engaging because the author has an active writing style and uses anecdotes from real life to reinforce points. It's also filled with common sense (something that appears to be uncommon during the planning phases of many of the hundreds of projects in which I've been involved). If you take the time to carefully read through this book you'll come away with some solid principles that support effective planning, and a process-oriented approach that will fit within any methodology. Do not expect to find procedures for performing quantitative planning activities - those can be found in most books on project management. Do expect, however, to learn how to approach the planning process the right way. I think every software project manager, requirements analyst and specification developer sho/wwwread this book before taking on their next project or assignment.

Wednesday, April 24, 2002

 
Back to Reliability. Software quality and reliability are two topics that I discuss frequently. I have a collection of new articles on these important subjects for those of you who are actively involved with reliability and/or quality:In addition, you may find IEEE Standard 1220-1998, Application and Management of Systems Engineering Process, useful because it adds process to the techniques in the above papers.

Tuesday, April 23, 2002

 
A new book titled A Practical Guide to Feature-Driven Development proposes a method that I think is on the right track.

What is proposed and described in this book is elegant in that it combines simplicity and power, and effective because it will deliver applications that support business requirements.

Although the approach is based on object-oriented development, and the book is focused on that approach, it can be refactored into function- and procedure-oriented programming environments. Moreover, while the book is written to fit within agile methods, it be fit to any development life cycle approach. This is because the focus is on features, which translate into what the business needs from an application. This is where elegance and simplicity comes in. By focusing on the features needed applications are less apt to be gold-plated with unnecessary features that developers may think is nice, but add little business value. In this respect the time to deliver is shortened and what is delivered is going to reflect genuine business requirements.

The power of FDD comes from the highly structured approach based on the ETVX (entry-task-validation-exit) framework. Entry criteria is typical: requirements, authority to proceed and other quality gates that must be passed before a development project is initiated. The tasks follow a five-step process as follows:

  1. Develop the model, including scope, validation in the form of walkthroughs, and peer reviews. The approach described in the book assumes an object model, but in a non-OO setting this can be realigned to first cut system diagramming in the form of block- and data flow-diagrams,and first-cut design.
  2. Build the features list. The OO approach is domain partitioning based on the model; in a non-OO setting this is where the team maps functional requirements to features.
  3. Plan by feature. This step, in my opinion, shows FDD to be a legitimate software engineering method. Feature prioritization, dependency analysis and effort estimation occur here. Done properly this step will make the difference between success or failure. I do have one issue with the book at this point: the prioritization is done by the technical team - it should be done with the business stakeholders.
  4. Design by feature. This is an iterative step that feeds back into step 1 (build the model) wherein class ownership is determined and the original model is refined based on the design approach. In non-OO environments this would loop back into the first-cut design and trigger trade-off analysis and design refinement.
  5. Build by feature. This is where the application is actually developed on a feature-by-feature basis within the context of the defined architecture (model).
Verification is accomplished using traditional methods. The authors introduce what they call feature-based testing which is no different than product test (also called functional qualification testing, and in some circles, acceptance testing). Verification procedures are thoroughly covered in the book, further adding to the software engineering approach that is incorporated into FDD. Exit criteria is when the sponsors accept the system.

What makes this book important is that is gives a straightforward approach that is based on deliverables (features) within a process context (ETVX). This approach is consistent with best practices in software project management and has the additional benefit of assuring that what gets designed and built is what the customer needs. Bolt FDD onto your favorite methodology and you'll probably see quality increase, and costs and time to deliver decrease.

See the collection of Feature-Driven Development articles for more detail.

 
In Linda's 20 April entry she discussed John Dvorak's encounter with Windows XP in his article titled The Good, The Bad and Microsoft. There is a follow-on to that article dated 22 April titled The Good, the Bad, and Microsoft, Part Two. If you're thinking of moving to Microsoft's XP you may want to take the time to read these articles.

Sunday, April 21, 2002

 
If you frequently read this page or its sister, Postcards from the Revolution, you'll quickly discover that we are strong proponents of requirement management. Get the requirements wrong and your project will either fail or, at best, exceed your budget. There are a number of methods for eliciting, documenting and managing requirements, but the best ones involve workshops where the major stakeholders are involved. There are three methods that amploy workshops and stakeholder involvement:
  1. Participatory Design (PD)
  2. Rapid Development (RD), sometimes called rapid application development (RAD)
  3. Joint Application Development (JAD)
I recently read a groundbreaking book titled Requirements by Collaboration that synthesizes the best of PD, RD and JAD. To this synthesis it adds modern elements such as business rules.

To understand why this book is a ground breaking work a little history is in order:

Each of these approaches have one thing in common: participatory requirements elicitation accomplished in a workshop setting.

Most of the previous documents about these approaches focused on general aspects of workshop management and requirements. Although this book certainly addresses these two aspects, it goes beyond.

This book is structured in three parts and 12 chapters. Part I covers the basics of constructing a workshop and provides a comprehensive list of deliverables. The author's web site that supports this book provides checklists and templates in Word and PDF format, which will save you time. The web site also has links to other resources that will prove extremely useful. Part II provides the workshop framework, covering logistics, managing roles and ground rules and the workshop process itself. Part III addresses the strategies for conducting the workshop. What I particularly like about this book are:

The approach set forth is effective and thoroughly modernizes the approaches that were synthesized. More importantly it provides a structure in which to conduct participatory workshops, and clearly defines the types of goals you should be setting based on the business problem, and clear definitions of the deliverables that the workshop should produce. This book goes into my short list of best books read in 2002, and I suspect it will remain on my short list of recommended books for years to come.

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]