BPM Software Development Best Practices Based on My Experience
Development Process
.Choose appropriate development lifecycle process to the project at hand because all other activities are derived from the process
.Use spiral-based methodology, RUP or derivatives (Pega SmartBuild process) over a waterfall process for large projects
.Use Agile, XP over a waterfall process for smaller projects
.Having a process is better than not having one at all
.In many cases, it is less important on what process is used than how well it is executed
Requirements
-Gathering and agreeing on requirements is fundamental to a successful project
-It’s NOT necessary that ALL requirements need to be fixed before any architecture, design, and coding
-It’s more important for the development team to understand what needs to be built
-Core functional requirements of system SHOULD be documented in early iterations
-Core process rules and security matrix SHOULD be documented in early iterations
-Self-service functionalities SHOULD be captured
-Core system prototype SHOULD be prepared and agreed upon before moving to Elaboration phase
Architecture
*Choosing the appropriate architecture for the application is key to project success in long run
*Apply tried and tested industry standard architecture best practices / patterns (Gang of Four patterns, Java patterns, EJB design patterns, Core J2EE Patterns)
*Antipatterns provide useful knowledge of what does not work, and why
*Pega provides domain specific solution frameworks for Insurance, Banking and Healthcare verticals
*For pure-play BPM projects, apply established reference architectures (Doculabs / Pega SmartSuite etc.)
Design
#Even with a good architecture it is still possible to have a bad design
#Many applications are either over-designed or under-designed
#The two basic principles here are “Keep it Simple” and information hiding
#Perform Object-Oriented Analysis and Design using UML
#Reuse, reuse, reuse…..create reusable assets
#Create fine grained components for reuse in early iterations
#Revisit design in each subsequent iteration, refine and aggregate fine grained #components into coarse grained components
#Reach maturity level required to create composite applications
#PegaRULES provides in-built capabilities for reuse at multiple levels
#Ensure equal importance to Non-functional requirements
a)Performance
b)Scalability
c)Security
d)Availability
e)Failover
f)Maintainability
Code construction
%Construction of the code is a fraction of the total project effort, but it is often the most visible
%Follow industry standard coding practices
%For PegaRULES based projects, follow the BPM-COE coding guidelines and guardrails
%A general best practice for constructing code includes the daily build and smoke test
%Use standard frameworks to automate builds and testing, such as Ant and Junit
Peer Reviews
^It IS important to review other people's work
^Reviews are as effective or even more effective than testing
^Any artifact from the development process can be reviewed, including plans, requirements, architecture, design, code, and test cases
^Helpful in producing software quality at top speed
Testing
$Testing is not an afterthought or cutback when the schedule gets tight
$It is an integral part of software development that needs to be planned
$Testing should be proactive; meaning that test cases SHOULD be planned before coding starts
$Test cases SHOULD be developed while the application is being designed and coded
$Every developer SHOULD be accountable for respective unit testing, module testing, $integration and performance testing
Performance Testing
&Testing is usually the last resort to catch application defects
&It is labor intensive and usually only catches coding defects.
&Architecture and design defects may be missed in SIT / UAT
&To catch some architectural defects load testing on the application SHOULD be performed before it is deployed
Configuration Management
+Configuration management involves knowing the state of all artifacts that make up your system or project, managing the state of those artifacts, and releasing distinct versions of a system
+Configuration management than just source control systems, such as Rational Clearcase, CVS etc.
+There are also best practices and patterns for configuration management
Deployment
>Deployment is the final stage of releasing an application for users
>You need to PLAN for deployment
>The Tech Lead SHOULD prepare a deployment checklist before the system is transitioned to the production environment
>Necessary data should be available for the system to kick off in production
>Integrations SHOULD be carefully planned for deployment as they are generally failure prone if not planned properly
Data Migration
~Most applications are not brand new, but are enhancements or rewrites of existing application
~Data migration from the existing data sources is usually a major project by itself
~It is as important as the new application
~Usually the new application has better business processes / rules and expects higher quality data feed
~Some GEE projects faced client escalations due to poor / insufficient data migration
~This is NOT a project for junior programmers. ONLY senior developers / designers along with a functional analyst SHOULD take up this activity
Project Management
.“If you fail to plan, you plan to fail”
.Project management is key to a successful project
.Many of the best practice areas described previously are related to project management
.A good project manager is already aware of the existence of these best practices
.Choose appropriate development lifecycle process to the project at hand because all other activities are derived from the process
.Use spiral-based methodology, RUP or derivatives (Pega SmartBuild process) over a waterfall process for large projects
.Use Agile, XP over a waterfall process for smaller projects
.Having a process is better than not having one at all
.In many cases, it is less important on what process is used than how well it is executed
Requirements
-Gathering and agreeing on requirements is fundamental to a successful project
-It’s NOT necessary that ALL requirements need to be fixed before any architecture, design, and coding
-It’s more important for the development team to understand what needs to be built
-Core functional requirements of system SHOULD be documented in early iterations
-Core process rules and security matrix SHOULD be documented in early iterations
-Self-service functionalities SHOULD be captured
-Core system prototype SHOULD be prepared and agreed upon before moving to Elaboration phase
Architecture
*Choosing the appropriate architecture for the application is key to project success in long run
*Apply tried and tested industry standard architecture best practices / patterns (Gang of Four patterns, Java patterns, EJB design patterns, Core J2EE Patterns)
*Antipatterns provide useful knowledge of what does not work, and why
*Pega provides domain specific solution frameworks for Insurance, Banking and Healthcare verticals
*For pure-play BPM projects, apply established reference architectures (Doculabs / Pega SmartSuite etc.)
Design
#Even with a good architecture it is still possible to have a bad design
#Many applications are either over-designed or under-designed
#The two basic principles here are “Keep it Simple” and information hiding
#Perform Object-Oriented Analysis and Design using UML
#Reuse, reuse, reuse…..create reusable assets
#Create fine grained components for reuse in early iterations
#Revisit design in each subsequent iteration, refine and aggregate fine grained #components into coarse grained components
#Reach maturity level required to create composite applications
#PegaRULES provides in-built capabilities for reuse at multiple levels
#Ensure equal importance to Non-functional requirements
a)Performance
b)Scalability
c)Security
d)Availability
e)Failover
f)Maintainability
Code construction
%Construction of the code is a fraction of the total project effort, but it is often the most visible
%Follow industry standard coding practices
%For PegaRULES based projects, follow the BPM-COE coding guidelines and guardrails
%A general best practice for constructing code includes the daily build and smoke test
%Use standard frameworks to automate builds and testing, such as Ant and Junit
Peer Reviews
^It IS important to review other people's work
^Reviews are as effective or even more effective than testing
^Any artifact from the development process can be reviewed, including plans, requirements, architecture, design, code, and test cases
^Helpful in producing software quality at top speed
Testing
$Testing is not an afterthought or cutback when the schedule gets tight
$It is an integral part of software development that needs to be planned
$Testing should be proactive; meaning that test cases SHOULD be planned before coding starts
$Test cases SHOULD be developed while the application is being designed and coded
$Every developer SHOULD be accountable for respective unit testing, module testing, $integration and performance testing
Performance Testing
&Testing is usually the last resort to catch application defects
&It is labor intensive and usually only catches coding defects.
&Architecture and design defects may be missed in SIT / UAT
&To catch some architectural defects load testing on the application SHOULD be performed before it is deployed
Configuration Management
+Configuration management involves knowing the state of all artifacts that make up your system or project, managing the state of those artifacts, and releasing distinct versions of a system
+Configuration management than just source control systems, such as Rational Clearcase, CVS etc.
+There are also best practices and patterns for configuration management
Deployment
>Deployment is the final stage of releasing an application for users
>You need to PLAN for deployment
>The Tech Lead SHOULD prepare a deployment checklist before the system is transitioned to the production environment
>Necessary data should be available for the system to kick off in production
>Integrations SHOULD be carefully planned for deployment as they are generally failure prone if not planned properly
Data Migration
~Most applications are not brand new, but are enhancements or rewrites of existing application
~Data migration from the existing data sources is usually a major project by itself
~It is as important as the new application
~Usually the new application has better business processes / rules and expects higher quality data feed
~Some GEE projects faced client escalations due to poor / insufficient data migration
~This is NOT a project for junior programmers. ONLY senior developers / designers along with a functional analyst SHOULD take up this activity
Project Management
.“If you fail to plan, you plan to fail”
.Project management is key to a successful project
.Many of the best practice areas described previously are related to project management
.A good project manager is already aware of the existence of these best practices
