Saturday, April 27, 2002
Friday, April 26, 2002
Thursday, April 25, 2002
[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:
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:
- Pathology of bad plans and how to recognize them.
- A best practices comparison of the CMM, Microsoft Solution Framework, UML and Rational Unified Process. Note that I disagree (as predicted by the author in his preface) that the CMM belongs in the discussion since it's not a methodology but an indicator of process maturity based on key practices.
- The emphasis on communications during the planning process. This is a common failure point and the fact that an entire chapter is devoted makes this book all the more valuable.
Wednesday, April 24, 2002
- Holistic Engineering for Software Reliability (46 pages)
- Software Reliability Growth Model (10 pages)
- Software Reliability
- Module Size Distribution and Defect Density
Tuesday, April 23, 2002
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:
- 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.
- 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.
- 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.
- 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.
- 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).
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.
Sunday, April 21, 2002
- Participatory Design (PD)
- Rapid Development (RD), sometimes called rapid application development (RAD)
- Joint Application Development (JAD)
To understand why this book is a ground breaking work a little history is in order:
- Participatory design (PD) began in England by Enid Mumford and was refined in Scandinavia by Pelle Ehn and Morten Kyng in the late 1970s.
- RD (Rapid Development) was first formalized by DuPont in mid 1980s and was then known as Rapid Iterative Production Prototyping (RIPP).
- JAD was first developed by Toby Crawford and Chuck Morris at IBM in 1977.
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:
- It defines a process with inputs, tasks and defined outputs (deliverables).
- Adds structure by aligning business problems to model views, and by defining the deliverables that need to be produced to develop the model. The models views are: behavior, structural, dynamic and control. These cover the four basic business problem domains.
- Does not lock you into any single model (you can use multiple model types), and provides criteria for selecting the best model(s) to employ for capturing requirements.
- Introduces business rules, which is (in my opinion) one of the most powerful and effective means of capturing requirements.
Subscribe to Posts [Atom]