requirements driven development and delphi draft version 1 daniel polistchuck
TRANSCRIPT
Requirements Driven Development and DelphiDraft version 1
Daniel Polistchuck
Agenda
Background Info/Concepts CMMI People, Process and Technology Requirements Development & Management Feature Driven Development
Delphi CaliberRM Integration Implementation example: Requirements Management +
FDD
Purpose
The purpose of this session is to emphasize that it is possible to combine formal processes (such as CMMI’s Requirements Process Areas) and a full-blown Agile Methodlogy such as Feature Driven Development (FDD)
Especially if you’re using Delphi (Can I hear ECO? Integrated CaliberRM Client? That’s AGILE!)
CMMI
We’re really serious about “process improvement” The Teraquest acquisition was about this To get an official CMMI Appraisal is just the tip of the
iceberg… Real Process Improvement (with capital letters) is the actual goal
We already had the tools like StarTeam, CaliberRM, Together, Delphi…
Now we have it all: people + process + tools
But What’s CMMI?
CMMI stands for Capability Maturity Model Integrated Provides several process areas, with specific and
generic goals that will drive process improvement in your organization.
Two representations: Continuous – Each Process Area is evolved individually by
capability level. More flexible, lets you plan specific areas for improvement, aligned with your organization’s strategic business goals.
Staged – Provides a proven path for improvement of your organization’s processes. Easily lets you compare your organizations maturity level with other players in the market.
CMMI - Staged
CMMI - Continuous
What’s in it for me?
CMMI is a model for improvement than can be used, independent of formal appraisals and reports, to help you organization become: Organized Focused Continuously and systematically growing
It’s not a process, but lets you select a process that complies with the model.
RD & REQM Process Areas in CMMI
Requirements Development – elliciting, developing, analyzing and validating customer and product requirements
Requirements Management – manage the inconsistencies to other work products (tasks, for example), change and traceability of the previously developed requirements
Requirements Good Practices
Categorization of requirement types Business Requirements: Business Opportunity, Business
Objectives, Market Requirements, Major Features, Project Success Factors
Project Constraints: Schedule, Budget, Staffing, Technical, Location
Functional Requirements
Prioritizing Trade-off analysis (using the Requirements Grid)
FDD
What is FDD? It’s an Agile Process that focus on repeatable, measurable
delivery of WORKING software
Why? To enable and enforce the repeatable delivery of working
software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project.
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
FDD Context
Configuration ManagementRequirements Development
Programming Language
Prototyping
Testing
Testing
Project Staffing
Budget Preparation
Project Overall Planning
Resource Testing
Requirements Management
Develop an Overall Model
Build a Features List
Plan By Feature
Design By Feature
Build By Feature
Feature Driven Development
FDD 5 Processes
1.Develop an Overall
Model
2. Build a Features
List
3. Plan by Feature
4. Design By
Feature
5. Build By Feature
An object model(more shape than content)+ informal features list+ notes on alternatives
Shape and coremethods
A categorized list of features
A developmentplan
A design package(sequences)
Completed client-valued function
Detailed how-tocontent
FDD 5 Processes + RDD
1.Develop an Overall
Model
2. Build a Features
List
3. Plan by Feature
4. Design By
Feature
5. Build By Feature
An object model(more shape than content)+ informal features list+ notes on alternatives
Shape and coremethods
A categorized list of features
A developmentplan
A design package(sequences)
Completed client-valued function
Detailed how-tocontent
Requirements Development Requirements Management
FDD Context (again)
Configuration ManagementRequirements Development
Programming Language
Prototyping
Testing
Testing
Project Staffing
Budget Preparation
Project Overall Planning
Resource Testing
Requirements Management
Develop an Overall Model
Build a Features List
Plan By Feature
Design By Feature
Build By Feature
Feature Driven Development
FDD Context + RDD
Requirements Development
Requirements Management
Develop an Overall Model
Build a Features List
Plan By Feature
Design By Feature
Build By Feature
Feature Driven Development
FDD and Functional Requirements
FDD has a specific context: to model, ellicit, plan, design and build functional (working) software.
Actually Feature Areas, Feature Sets and Features could be seen as a hierarchy of Functional Requirements
Remember “Requirements Good Practices?”
Requirements Good Practices (again)
Categorization of requirement types Business Requirements: Business Opportunity, Business
Objectives, Market Requirements, Major Features, Project Success Factors
Project Constraints: Schedule, Budget, Staffing, Technical, Location
Functional Requirements Prioritizing Trade-off analysis (using the Requirements Grid)
CaliberRM
CaliberRM is the tool that will help you as part of the PPT tripod of your company Process – aligned to your business goals Tools – supports your process People- must be trained in the tools and processes
Requirements Types
CaliberRM supports the creation of Requirement Types These are high level groups of requirements that follow a
specific standard. For example Business Requirements – Vision and Scope/Project Charter (WHY) User Requirements – Use Case/user interaction (WHAT) Functional Requirements – Implementation (HOW) Non-Functional Requirements – Performance, Deployment, etc.
CaliberRM in Delphi
The Integration UI is divided in 3 major parts
Requirements Treeview
Contents
Toolbar
CaliberRM Req TreeView
The requirements treeview Has the project itself as the root node In the first level lists the requirement
types set for the current project by the admin
In the other levels (req types children) are the requirements themselves organized hierarchically. (can be dragged/dropped)
You can change/set the name of the currently selected requirement either in the TreeView or in the Details Tab
CaliberRM Toolbar
Available Functionalities Select the current project and baseline Create a new child or sibling requirement Move the requirement up and down Delete the selected requirement Save or cancel changes Refresh Log off Launch Estimate Pro Format the description Manage Code Traceabilities
CaliberRM Content Pane
In BDS 2006 it’s a first-class IDE window
The content pane shows information for the currently selected project/requirement type/requirement
You can edit the any requirement info you want in the content pane.
Let’s take a look at the different tabs
Content Pane Tabs
Details – Shows the “system fields” for the Requirement. They are all required.
Traceability – Lets you create To/From traces between your requirements and Delphi/C# code. Just ALT+Drag code to either the “Traces From” or “Traces To” listboxes
Validation – Validation procedure, so you can help testers with certifying that the requirement was correctly implemented/followed
Content Pane Tabs
Discussion – Lets you collaborate with other team members by creating a “forum-like” discussion for a specific requirement
References – Here you can create references to web sites and external documents
History – Shows the history info (who, what, when, why the requirment changed)
Content Pane Tabs
Responsibilities – The team members that participate in the management, implementation and definition (for example) of the selected requirement. It’s currently read-only.
User-Defined Tabs – Contains any Admin –created Custom Attributes set for the current requirement type.
FDD and CaliberRM
Next slide will show an example implementation of the “Features” Requirement Type in CaliberRM
Build a Feature List Plan By Feature, Build by Feature
All Together Now!
Well, so we’ve taken a look at: CMMI Requirements Management and Requirements
Development PAs Requirements Good Practices Feature Driven Development CaliberRM Integartion in Delphi
Lets wrap it all together in a…
DEMO – Sales Force Automation
The demo will focus on a specific deliverable of a Sales Force Automation Project: Order Entry
Delphi-specific features that will be used: CaliberRM Integration ECO III DUnit Unit Testing Wizards StarTeam Integration
Step 1: Requirements
Let’s gather the requirements Business Requirements Project Constraints
Step 1: Requirements
Step 2: FDD #1 – Develop an Overall Model
Form the modelling team: domain experts, developers and architects
Domain walk-through: the domain expert will provide an overview of the domain
Develop and Refine the Model: got ECO? Write Model Notes: any detailed or complex strutctures
must be clarified using notes Internal and External Assesment
Step 2: FDD #1 – Develop an Overall Model
Step 3: FDD #2 – Build a Features List
Form the Features List Team: Gather your Chief Programmers from FDD Process #1
Organize the Features List in CaliberRM under the CaliberRM “Features” Requirement Type: Subject Areas/Feature Areas Business Activities/Feature Sets Business Activities Steps/Features
The Business Activity Step/Feature format is <action> <result> <object> E.g.: Associate <action> a responsible Salesperson<result> to
an order <object>
Step 3: FDD #2 – Build a Features List
Step 4: FDD #3 – Plan By Feature
Determine the development sequence: Enter the Planned Dates for all Features in your CaliberRM Project.
Assign Business Activities/Features Sets to Chief Programmers: Set the Chief Programmer Responsibility for each Feature Set (2nd level) in your CaliberRM Project.
Step 4: FDD #3 – Plan By Feature
Step 5: FDD #4 – Design By Feature
Form the feature team Develop Sequence Diagram: besides Sequence
Diagrams, you can also define State Machines for the classes involved in the work package/Feature Set.
Refine Object Model: add methods/attributes to the Object Model based on the Sequence Diagram and State Machines.
Write Class and Method Prologues: Add XMLDoc tags to document classes, methods and parameters for the classes
Design Inspection
Step 5: FDD #4 – Design By Feature
Step 6: FDD #5 – Build By Feature
Implement Classes and Methods: Implement specific methods for the feature classes
Code Inspection: Peer review the code Unit Test: Create unit tests to verify if the requirements
related to the features were attended Promote to Build: Add/Check in class to StarTeam using
Delphi’s Integration.
Monitoring and Reporting Progress
Monitoring and Reporting Progress
Monitoring and Reporting Progress
Conclusion
Wheew!! Lot’s of new information, eh? We managed to align seemingly “disparate visions”
CMMI Agile Methodologies Delphi
Questions
