Just so I don't forget it in the future. In order to get the wsconnector working in the test environment you need the following in your class path:
Labels:
curam
0
comments
These are the things I would like to get from the Business Analyst specifications. I wrote this up for a friend of mine who was a BA and asking me about it. So from the point of view of a dev guy who has done app maintenance, DBA work, testing and performance analysis here are my view points.
The goals are to make sure there is enough detail for:
One thing you should know is business analyst specifications unlike requirements are living documents like source code. Although they should not change too much. The items here are not necessarily Curam specific, but it links to some of the Curam specific requirement gathering documents.
A starting point document would document what someone would need if they want to know what is going on with the project.
It should have the following:
Specific Objectives or goals for the user. The key things are that they are specific and for the user (or the user's client) such as "get a job for the person" or "gather all the information needed for the mainframe rules processing."
A Glossary of Terms so everyone speaks the same language. Every industry has their own lingo, so having that there reduces the confusion.
A References section which lists business documents such as the ones described here or requirements and where to find them.
The Business Analyst Document Template specifications. This would guide people how to read your documents. It would list your document types, their purpose and audience. (Fortunately I kind of written what the types are for you in this blog entry).
Ideally a BA document has the following:
The starting point document already says what the document types are and their purpose, so don't repeat yourself.
End-to-end scenarios should be the basis of any BA specifications. They should be written up as graphical work flow representations with little detail (the little detail is important because if you put in too much detail on this level it will take too much time make make things harder to change).
They are taken from the goals in the Starting point document.
It should talk about how a person would manually do things. Knowing how things are done manually makes it easier to communicate with the stakeholders (users or client) as they must know how things normally work in case the system breaks down.
It should have the following sections
For the stakeholders a visual representation makes it easier for them to understand what is going on.
For the testers the flow gives them an idea how to do their functional testing.
For the developers if they have a workflow engine, they can utilize the workflow engine to do their work or they can implement but have their unit test planned out as well.
For the business analysts they help define the screen flow and the domain specifications.
The domain specifications is where it gets really interesting. I put it before screen flows because this is usually what is missing in most of my Curam projects. However, it is not really much of a problem outside of Curam projects I find though. However, this can be done in parallel with the screen specifications.
When dealing with domain specifications it is best to think what you as a BA are more used to communicating in. I prefer a more object oriented fashion rather than a database oriented fashion because it lets me avoid getting into lower level details which should be done by the developers or the DBA.
For example, I would talk about a Case as a single object that can contain other objects such as Case Members which has a reference to a Person. A Person is a Participant which has a name. And I could go on.
The advantage of dealing with it in an OO fashion allows me to deal with a collection of objects as one object graph.
Although when I write these, I don't expect the BA version to be the final copy. I would expect the developers to give me a cleaned up version of their UML diagram when they finish from their tool (though it should look relatively the same).
The way this is written would be one document per object graph and a high level object graph diagram.
The high level object graph diagram shows how each object graph would link to each other.
Each object graph document would show:
The BAs specifications do not show the following because they are too low level
For the stakeholders the UML representation allows them to see how things are aggregated together. You can explain to them that each box is like a folder which can contain other folders or papers.
For the testers, knowing the domain model allows them to perform data checks directly on the database without the UI.
For the developers it allows them to write a UML class diagram that can be shared with the BAs for review.
For the DBA it allows them to write a logical and physical data model more easily.
For the business analysts they help define what the data you are dealing with and what operations can be performed.
The end-to-end scenarios would provide the detail on what screens should be available. These documents generally come up to look like a site map. It is best to work with a UI person on this one. These would define the following:
For the testers the flow gives them an idea how to do their functional testing in terms of screen flow.
For the developers the screen flow helps them figure out how to link pages together.
For the business analysts they help define what screens they would need.
The template screen specifications talk about the global look and feel of a screen for the application. You may end up with more than one template depending on the complexity of your application, but you should have at least the following:
These should be done with a UI person who would create the layout in HTML for you.
There are two components to the individual screen specifications. The actual business data and how it looks like. How it looks like should be kept as a separate document written by the UI person. The business data which the BA should do specifies the following:
Treat each screen as an individual document, this allows you to update one screen without having the developers read through the entire document to find what has changed.
The template screen specifications already specify some common field information so DO NOT REPEAT YOURSELF. If you are repeating something often then put it in the template specifications.
From the screen specifications and the domain specifications, you should be able to determine what validation rules you would need aside from the obvious mandatory validation, format validation. What you need to describe are business validation such as SIN validation etc. (although I would recommend you just put in links to some web site that describes the algorithm for you... Google is your friend).
The validation rules document should only describe the ones that are global rather than domain or screen specific. Screen specific or domain specific should be put in as part of their respective documents.
Business rules are best written out as decision tables. You can use the same technique I used for Curam rules.
These are not necessarily part of the business flow but is much needed and usually forgotten.
Labels:
business-analysis,
curam
0
comments
Colleague of mine came up to me with a problem. He was getting a ClassNotFoundException being thrown for some class in WebSphere. However, the class curam.foo.util.MyUtil is there, and it works on development. So what's wrong?
Well the default .classpath that comes with Curam just includes everything in custom/source. However, when the build scripts build implementation.jar, it only includes files that are in the impl package. So to fix this you need to move it to curam.foo.util.impl.MyUtil.
To prevent it in the future, you should modify the classpath so the inclusion pattern for custom/source only includes files in these folders. This will cause the developer's local builds to fail early in the game rather than later in deployment.
Labels:
curam
0
comments
To unit test a loader, you first need to extend it so that the load method is exposed. I usually just create a private static final class within the test class that I am using to test the loader.
private static final class ExposedFoodEvidenceLoader extends FoodEvidenceLoader { public void load(final RulesParameters rp) throws AppException, InformationalException { super.load(rp); } }
In the actual test method, I just create the RDO instances and execute the loader.
final FoodEvidenceGroup foodEvidenceGroup = new FoodEvidenceGroup(); final ItemGroupGlobals itemGroupGlobals = new ItemGroupGlobals(); itemGroupGlobals.dateOfCalculation.setValue(Date.getCurrentDate()); final RulesParameters rulesParameters = new RulesParameters(); rulesParameters.addRDO(itemGroupGlobals, false); rulesParameters.addRDO(foodEvidenceGroup, false); new ExposedFoodEvidenceLoader().load(rulesParameters); assertEquals(FOODTYPE.FILIPINO, foodEvidenceGroup.getfoodType().getValueNoLoad());
Labels:
curam,
testing
0
comments
Since Curam 4.5, it comes with a replacement to the Case Evidence Tree API called the Temporal Evidence Framework. This framework is a significant improvement in terms of development and ease of use over the previous framework. Kudos to Curam for providing us a way out of that previous API.
I won't be talking about the UI of the evidence framework, that is fully documented in the Documentation Center. I would be focusing more on how to do analysis of requirements and converting them to evidence forms and structures.
There are some properties of evidence that a BA should be aware of and take advantage of.
There are two inputs that would help you get the analysis done on this task.
By combining the two you can determine which of the actual forms to convert into evidence forms.
The typical approach when creating evidence is to start with an actual form and just build the evidence form from it. This should only be considered as a starting point.
Some things with actual evidence forms:
Following that you may end up with evidence that is not captured on any actual evidence forms. From this avoid the following traps:
The framework has the concept of both effective date and attribution dates. Attribution dates are basically start and end dates for an evidence. Effective dates show when an evidence has actually changed.
Effective dates are used if you want to see how an evidence changes over time. It is a bit more tedious on the end user because he has to enter two evidence records one when the person is eligible and another when he is not. Effective dates are always present, they can be empty, but the field must not be removed.
Attribution dates should be used if you are defining something that can actually begin or end.
The use of effective dates should be used when you are only trying to capture a change in circumstance. Effective dates are used when you need to visually see the history of changes over time.
Effective dates cannot be set unless the evidence has become active.
There is no reason why you couldn't do both. The Sample Sporting Grant does both.
Put validations only for sanity checks on mandatory fields and structural checks. Let the business rules handle business level validations. This keeps the validation logic simple.
Evidence forms ideally should not have any mandatory fields. This gives a user the flexibility to enter in whatever data he has now and fill in the rest later.
Rather than enforcing mandatory fields on save, have an on-save validation which checks if something needs to be mandatory on final it will show warnings to indicate to the user that the evidence form that they have filled in is not complete. Another validation on-activate will ensure that everything must be correct. The developers need only to change one from just a warning to a full error on the two events.
Although format checks should be done on save. If the user enters data, it should be in the correct form.
The following would be an example of validation analysis for an evidence form.
| Field | Format Requirements | Mandatory |
| Actual Cost | x >= 0 | yes |
| Estimated Cost | x >= 0 | no |
| Director | yes |
Once you have finished capturing what you require in evidence. An analyst needs to refactor the evidence screens so it is more beneficial to the user. They can work with a user interface specialist to do this.
There would be times when evidence forms have a common block. Take the following example:
I could refactor it as
Doing that I only have one evidence workspace to deal with which lists all my living expenses. This works well if the screens are very similar in nature except for a type discriminator which can be passed when creating a new evidence. You can do that by having "New Medical Expense" rather than "New" in the evidence workspace screen.
To determine whether an evidence should be in the participant or case level ask the following questions:
What you may notice is most evidence would be associated with the participant. So let's talk about when would it be in the case?
Unfortunately, Curam does not provide us with a facility of associating only with a participant. Everything is still captured within the context of a case.
The following shows some of the analysis work products that would come out.
The following is the top level view of all the evidence types.
| Evidence Form | Approval Requirements | Attribution Dates | IC Types Associated | Person Assoc |
| Income Report | yes | Income Support Rehabilitation | yes | |
| Special Circumstance Benefit | Director or 2 supervisors | no | Rehabilitation | no |
| Medical Incident Report | Medical supervisor | start date only | Income Support Rehabilitation | yes |
You also need to tabulate all the products that would actually need the evidence so have a product evidence link list.
Product Name
Finally you need to specify what fields an evidence form has and what validations if any there are. Just remember validations on save come first before activate. Keep the required fields on save to a minimum as well. So something like this would help out:
Evidence Form
| Field | Type | Validation On Save | Validation On Activate |
| Participant | Case Participant | required | |
| Expense Amount | Money | > 0 | |
| Expense Type | Expense Type | not blank |
Determining where to get the data is pretty simple.
Evidences has approval support built in, you can use it in lieu of putting in a "approved by" field in your evidence.
Labels:
business-analysis,
curam
2
comments
To be honest, Curam provides an excellent document called the Rules Definition Guide in their Documentation Center that would be a good read for any Business Analyst dealing with Rules. This blog will not rehash what is written there, but my knowledge is based on what was written in that document and other business rule specifications I have seen in other projects.
Although the focus is on Curam, this can be applied to any other rules engine analysis work.
That's usually one of the first questions. The answer to this is neither. If you're thinking of rules and evidence you're thinking way too far ahead. That's a good thing.
The starting point for any rules/evidence work is policy. Policy can be in the form of a legislation or an existing manual. This sets up a guideline for you to work with.
Policies tend to be very large documents. It is best that before you try and extract information from the policies you break it up into logical chunks. Usually chapters and subchapters are sufficient.
Most policies will tell you what conditions you have to meet and what are the outcome based on those conditions. This will be the data that gets put into the catalogue.
The catalogue is an interim work product. It should contain a list of conditions and outcome and links to the sub-policies. This is predominantly a copy and paste from a policy document.
The catalogue would have the following sections.
Here is an example of a conditions that may appear in a policy document.
A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years.
A senior citizen with living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 10 years.
The analysis can be broken up into a more formal table format. However, since this is an interim piece of work, you can get away with just creative highlighting. For example:
A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years.
What I have done was underline each individual input data and bolded the outcomes. If you keep things consistent you should be able to get away with that approach with the client. Just remind them that this an interim work product but one of the first step in analysis.
If you need a formal table format, you can use the following:
| Condition ID | Policy ID | Policy Text | Data Elements | Outcomes | Analysis |
| P001-C001 | P001 | A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years. |
| receive $100 times age | |
| P001-C002 | P001 | This benefit cannot be removed by any future government | Statement. Not a rule | ||
| P001-C003 | P001 | Part of a clan |
| Missing outcome. |
There was an emphasis on interim, because this catalogue is useless for development and just a regurgitation of the policy from the client. It is also highly likely that not everything can be covered in policies.
As a BA you have to add value in order for development to be able to use it. So the next step is to convert what you have into a decision table.
The decision table is a table that collects all the information from the catalogue and places them into a tabular format. A group of condition results in a decision table. The following shows a decision table for a condition group.
Conditions satisfied:
| Input Data Name | Input Data Formula | |||||
| senior | CN-PO-1.1-1 | Y | Y | N | N | N |
| citizen | CN-PO-3.1-1 | Y | Y | N | Y | N |
| no living siblings | CD052 | Y | N | Y | Y | N |
| paid CCSIB premiums for at least 5 years | EV042 >= 5 years | Y | - | - | - | Y |
| paid CCSIB premiums for at least 10 years | EV042 >= 10 years | N | Y | Y | Y | N |
| paid MCSB premiums for at least 10 years | EV? < 10 years | - | - | - | Y | Y |
| Outcome | Outcome ID | |||||
| Receive $100 times their age | OC412 | X | X | X | ||
| Receive $200 times their age | OC413 | X | X |
The Input Data Name specifies the input data as per the condition record from the catalogue. The outcome data is information required by the outcome calculation.
The Input Data Formula is a formula that represents the information in the input data name. The formula may consist of an ID to point to some input data with a few simple calculations if needed. This prevents having to create several input data records where the only difference is one parameter.
The formula does not show where to get the data, but it is best the Input Data ID represents the possible source in this example we used CD for core data, CN for other conditions, EV or evidence data. Information on where to get the data is in the I/O catalogue which is described later.
Sometimes we don't have the any input data information defined yet, in which case we indicate it by a "?" on the ID to remind us to get the information.
One word of advice, try to use what is in the core rather than creating new evidences. The information in the core tend to be things that do not really change over time and can be shared with other parts of your application. Evidences are usually not shared outside the integrated case it is associated with.
One other thing to avoid: you may be tempted to just put some of the conditions like this:
| years paid paid CCSIB premiums | EV042 | >=5 | >=10 | >=10 | >=10 | >=5 |
You may have a harder time normalizing the decision table later. So avoid that.
The Outcome specifies the outcome as per the condition record from the catalogue. The Outcome ID is a unique identifier for the outcome. The outcome ID is not a formula, because describing it as a formula in the decision table would make things hard to read. The detailed information for the outcome will be in the I/O catalogue which is described shortly.
Most documentation regarding rules tables call the outcome as Action, but in Curam speak it is probably best to call this an outcome as the rule engine does not actually start up processes.
Once you have captured your decision table, you can optimize it using the techniques shown in http://www.cems.uwe.ac.uk/jharney/table.html
The conditions satisfied section is just there for the interim. It is meant as a way for the BA to keep track as to which conditions have been completed, be the rule catalogue will eventually be discontinued in favour of the decision tables and I/O catalogue. At which point, the section will be reworked as policies satisfied to ensure that any change in policy will trigger a trace back to the proper decision tables.
This catalogue captures the input data and outcomes that were required by the decision tables in the previous section.
For input data, there are three common sources:
The following tables would illustrate how to capture the information for input data:
| Input Data ID | Input Data Name | Calculation |
| CN005 | date of birth | Person.dateOfBirth |
| CN042 | no living siblings | Person.dateOfDeath defined for all ConcernRoleRelationship relations where type is sibling |
| CN006 | age | Current Date - Person.dateOfBirth |
| Input Data ID | Input Data Name | Evidence Form | Evidence Field |
| EV042 | years paid CCSIB premiums | CCSIB | Years Paid |
As you can see there are two different ways of writing the input data specifications. For core data, it tends to be a calculation rather than a direct field because the data tends to be spread out. It is best to communicate with a Curam developer or someone who knows more about the reference model. It is recommended that data elements be of different type to distinguish them from calculation descriptions.
Evidence input data tends to be new and so it should be possible to list the exact form and field rather than a calculation.
The Outcome data shows the following information:
| Outcome Data ID | Outcome Data Name | Objective Type | Objective Value Formula |
| OC412 | $100 x age | Money | CN006 x 100 |
| OC413 | $200 x age | Money | CN006 x 200 |
| OC501 | Food Delivery | Product Delivery | "FOODDELIVERY" |
| OC001 | General Eligibility | Assessment |
Generally an outcome would end up as an objective in Curam terms. The objectives types are usually money, a product or an assessment. The formula column shows the formula with reference to some of the input data as well.
This is as far as the BA would go. The combination of decision tables and the I/O catalogue would be sufficient information to communicate with the development team. It also provides a way of communication with the client team as they can visually see what would happen depending on their choices.
At this point the rule catalogue should be discarded in favour of the decision tables and the I/O catalogue. This is assuming that all the conditions in the rule catalogue are met.
The decision table will be a almost mechanical process to convert to the Curam rules structure. I say almost because the decision table does not name what the data or rulesets are nor do they group things together. That is left with the development team as part of their naming conventions.
The I/O catalogue will drive the creation of evidence and loaders.
Don't get into analysis paralysis. You should never ever do this when you think you completed a previous section. Once you have sufficient information, move onto the next section, if you realize something is missing go back. There is no harm in updating the previous one.
Business rules are very complicated, and policies are just as complicated. Policies tend to be vague and make certain assumptions which cannot be translated into code so you need to ensure those get analyzed.
Most likely the little problems would arise in development, but if you have done your job correctly, they should very little and you can fix it with a relatively quick turnaround.
The process defined here will provide sufficient documentation for both the client what is going on and the developer to understand what needs to be done.
The process defined here is general to most rule engines as well, there is very little Curam specific information so it can be used in other non-Curam projects.
Labels:
business-analysis,
business-rules,
curam
1 comments
Out of the box Curam comes with quite a number of core case types: Integrated Case, Screening Case, Assessment Case, Product Delivery Case. I am not going to re-iterate what the documentation center will discuss, that would be left as an exercise to the reader.
There are two things that you should avoid as a BA.
Screening case as the name implies tries to screen people that are trying to get into your system.
Trying to determine whether to use a screening case is very easy, and usually the answer to the following question is NO.
Are you going to accept and process delivery for every person that gets registered into your system?
If the answer is NO, then you'd have to create a screening case which will determine if
If for some strange reason the answer is YES, you really need to make sure that all data that gets into the Curam application is "trusted". Meaning someone has already verified the participant data outside of Curam and ensure that all required data is present.
When trying to name a screening case, it is best to figure out where it is coming from. So you can have Call Center Screening Case, Web Form Screening Case, or Office Visit Screening Case as examples of screening cases you would be dealing with.
An integrated case simply put is a collection of delivery cases and evidence that is shared across all the delivery cases. The goal of an integrated case is a specific outcome for the primary client which cannot be changed. That's the technical summary, but how would I ask the business? Well fortunately, the answer to those questions can be derived from the very first thing we gathered: the end-to-end scenarios.
The end-to-end scenarios would be able to group together products that you would need to deliver. These groupings turn into an outcome that they would want for a primary client. Chances are unless there are multiple delivery organizations within the customer's organization. An example of something with multiple delivery organizations would be child welfare, which may have something that delivers to foster care and something that delivers to parental support. That would usually involve two separate set of evidence and products. In which case there are two integrated cases.
Most likely when it is the first Curam implementation, there would only be one. However, do not remove that concept and just make product deliveries directly as it would cause you grief later on when you want to share evidences. You may specify a usage scenario where-by the integrated case type is automatically selected rather than getting rid of it.
The best way of naming an integrated case is not Integrated Case, but use something with the organization name and a high level name group name for the outcome group that they want such as Ivalice Employable Citizen Case or Rabanastre Household Support Case. By naming them, you allow your client to create new integrated case groupings and expire old ones more easily.
If your client asks:
What if I do not know what the outcome should be, because I am just trying to get information about a client?
Then your response should be:
That is the definition of a screening case. An integrated case has a target outcome, if you are not sure because you are just capturing information, then that should be a screening case.
You also need to define what kind of members you would have in an integrated case. If you don't define it properly, then you'd end up with evidence capturing memberships (which would look odd to say the least).
Assessment cases run the rules engine to generate a report whether a person is eligible or not.
A product delivery case represents either a benefit or liability for a case member. Like Assessments they run the rules engine against known evidence. However, an active product delivery case will generate financial components or other objectives to a case member.
You can go all out an do one benefit for one product delivery if you desire. Or lump a few together as one cohesive item. The best way to decide on grouping them is to find out from the marketing department what is the actual name of the product they are delivering to the people. Then group them as such.
An example of a good product delivery name would be Rabanastre Self-Employment Support which may give a training courses and some capital in the form of money as two benefits in order to give a person support to start his own business.
Curam provides other case types. These other case types may require a separate license, but it would be good for you to consider them if it will save you time.
One of the better ones I have used is the Service Plans which allow you to manage the delivery of multiple products to achieve a goal.
The others I guess are okay, but I never really used them well enough to make a good judgement call on them.
Labels:
curam
0
comments
In my previous post I talked about end-to-end scenarios. In this post, I am going to talk about what Activity Scenarios are and why they are important.
An Activity Scenario expand on one or more workflow activities from the end-to-end scenario.
By putting this into a separate task, we make sure that we help ensure that we do not get bogged down in the details early on.
The main input to the activity scenario are the end-to-end scenario which shows relatively how things will fit into the entire scheme of things.
In addition, the following inputs will help expand on them. This is relatively the same as the end-to-end scenario inputs, because these would apply throughout the entire requirements gathering process.
The output for each activity scenario is a detailed description of what the activity involves. Generally there are three major parts for each activity scenario.
As I specified earlier there may be more than one workflow activity from the end-to-end scenario involved in an activity scenario. Allowing for it would allow people to work things in a slightly higher level than individual activities, but still lower than the end-to-end activity.
The output is to be given to the developers to implement the workflow.
The Lead Pair would define the activity scenarios and send them to the PM for the planning. The pair would to decide whether group more than one activity in an activity scenario.
The client with the PM prioritizes activity scenarios that they would like to elaborate on. Generally there should be little interdependencies between activity scenarios so these can be done in parallel.
An automatic activity user story is simpler than a manual and it just describes what the system should be doing based on information that it has.
A manual activity is a bit more complicated as it involves determine who should get the task, the deadlines, etc. What a BA needs to do is break down the user story into the components of manual activity. Although you would be tempted to make use of a template that the customer fills out, I would make sure that parts of it are free form text where the customer can write a story as to what should happen when determining the deadlines, who to assign it to, etc.
When defining your first few manual activities (maybe the first 5) try to see if you can create a common manual task pattern that can be extended rather than repeating yourself for the rest of the project.
Having a common manual task pattern would also allow the leads to say:
Anything that we haven't explicitly defined or built we will use the common manual task pattern.
This would allow the requirement gathering team some air by:
As specified earlier, an activity scenario may involve more than one activity. The information obtained here is used primarily in defining loop conditions, event transitions, etc.
As specified earlier, Activity Scenarios expand on one or more workflow activities from the end-to-end scenario. This task separation prevents analysis paralysis.
Since each activity scenario is usually a stand alone unit, it can be prioritized based on importance. In combination with the common manual task pattern, any activities that are unable to be met by the deadline can be postponed. Since the workflow is still present, it just means that some people need to do some work rather than having the system do everything. However, since you can deploy new workflows during the life of the application, there is little risk.
Although this is primarily for Curam, most workflow packages would be able to support the activities specified below as it is technology agnostic.
Labels:
curam
0
comments
This is a continuation of my previous post in which I specified how I would break up the business analysts with the customer. The approach on getting the requirements out uses the same process as User Stories in Extreme Programming. The following is a recap of the user story groups that would be done in Curam:
In this post, I would be talking about the first group which is the end to end scenarios.
An end to end scenario is representative of a full workflow as told by the customer. It is best to get an idea what the end to end scenarios are first, without it there isn't going to be a good understanding of how things would flow through the application. Without that, you'd just end up with chaos in development.
Having end to end scenarios defined makes things a lot easier to develop and test.
There are three possible sources for end to end scenarios:
There are two possible work products from the end to end scenarios:
This gathering information for the end to end scenarios is an iterative process, the output work products feed back into the process as new input.
A high-level workflow would at minimum capture the following:
The workflow is then created and visualized using the Curam workflow activities. The workflow can then be shown to the client to confirm the understanding of the scenario. This task needs the BA to be cognisant of what the Curam workflow can provide. The workflow would also determine who are involved.
Although it would be nice, there are some information are not immediately required to complete a high-level workflow. It is best that the these extra information would be detailed by a different group of BAs. Otherwise you'd get into analysis paralysis of the end to end workflow and won't get anything done. They are:
In the en, the work product would be a document that would have the following sections:
Once the document has been signed off, it is sent down the pipe to the activity bucket. Which will detail off each activity on hopefully a different document, but tied to the original work product. The reason why you'd want it as a different document is to ensure tracibility. That is:
The activity document should have the same content as the original one though, it would just have new detailed information added underneath it.
Determine sub-workflow requirements should not be too difficult. One of best ways of doing this is to define a metric. A good metric would be that the workflow diagram must fit within one legal sized paper in landscape orientation. By limiting the size of the workflow, you'd be forced to write sub-flows in order to handle complexities. The advantage of this would be better focus for the customer and the BAs as they won't get too bogged down in the details.
Imagine having workflow diagrams the size of the Curam reference model poster, you'd probably have difficulty following it. Even worse if you are a new person to the project.
Many of these scenarios be done at the same time, but the customer needs to prioritize them. It takes probably a couple of days to draw a 50 activity workflow by someone that has done it once before.
The cheapest ways of building the workflow are to do it on a shared piece of paper or transparency sheet for larger audiences. Then have someone draw it more professionally afterwards using Curam.
When capturing the detail for an end to end scenario, make sure the customer's focus is going from end to end, rather than expanding every single detail which may take a longer time. Explain to them that the parts they are not 100% sure of or would require a lot of steps can be broken into a sub-scenario (which would be coded as a sub-workflow eventually). Doing this would avoid analysis paralysis.
For non-Curam projects, try and convince your customer and architect to invest time and effort on implementing a workflow solution. There are several out there, some of them free. Others like WebSphere Business Integration/Modeller provide a lot of overkill, but it is good overkill. Just like DB2, it has an overkill of features, but that is what makes it strong and able to deal with many of the things you throw at it.
However, even if you do not have a workflow system, having end to end scenarios defined makes things a lot easier to develop and test.
The output work products for the end to end scenarios will provide a framework for you test team to follow when they are actually testing the application.
These scenarios will help foster and reinforce understanding of the customer's business both to the BA and the customer. Visualization is a very powerful learning tool.
By breaking things into activities, the other BAs can be more narrowly focused, which means that the development team would also be narrowly focused because the flow would be handled by the workflow engine. Also since each activity is more well defined, it is easier for the PM to plan and set dependencies between each activity.
So as you can see having end to end scenarios defined makes things a lot easier. However, not just to develop and test, but planning and fostering customer understanding as well.
Labels:
curam
4
comments
This is a continuation of my previous post. In this entry I talk about working with your customer in hopefully an effective fashion.
One of the toughest part in any project, not just Curam, is getting enough information from your client so that the development team can use it and the client won't come back and say, "that's not what I meant." This may seem like squeezing blood from a stone, but when done right it won't be as bad.
The thing that should help on the get-go is planning and defining who does what. The other important thing a Curam BA has to do is to help your customer adapt to Curam, rather than accepting everything they want.
Unlike non-Curam projects, this is a lot easier for Curam practitioners as they already have a working product that they can use and play with. However, regardless of whether it is Curam or not, it is best that the BA works with the application architect to make sure decisions that they make won't have major consequences to the work.
It is best to determine roles and responsibilities as early on as possible. Customer business reps should be talking with each other, same with your BAs. However, one of each side must lead their own packs.
Here are the pair levels:
If the project is small, which is rare for Curam, some roles may be combined into one person. On the other hand, if you have a big enough project, it may require more than one person to do the role.
Now that you know who your resources are, you should be able to create a project plan with dependencies on each component. This is necessary in case someone misses a deadline. If a deadline has not been met, then the project plan needs to be re-adjusted as a change request. Missing a deadline is a change in scope and should be treated accordingly, otherwise you'd end up with scope creep.
I would recommend that you use a proper planning tool such as Microsoft Project or OpenProj (when it becomes less buggy) to help plan things out.
Also you need only to take the detailed plan on the requirements gathering portion. It is not too bad unlike other areas, because you really have no external dependencies short of the customer.
You do not have to push the client to finish things before they are done. Remind them that if they spend too much time trying to get things perfect at the beginning, then they'd cause more people to be idling. However, they should not leave things to be in an imperfect shape, otherwise they'd still have to pay for any changes to their original requirement once development has started. It is a balancing act.
Fortunately, the approach I am taking uses the User Story method that they do in XP for most of the work products a BA needs to build. This approach gets them to say in their own words what they want to accomplish. These may have already been put into the RFP, but even if it is not then we would have marked the component as high complexity and so more time can be allocated to get the necessary information. The other nice part about User Story method is the BAs don't have to write long wads of documentation, that task is passed onto the customer, who should know how they want things to work more than the BAs.
Because Curam has done a lot of things for us already, a 90/10 target should be strived for rather than 80/20. Of course the best way of doing this is...
Keep in mind, just because the customer wants something, does not mean that it should be how it is supposed to be done. Especially with the usability and case lifecycles.
Using a COTS package like Curam implies that there must be some flexibility with the customer to adapt to Curam. Otherwise, Curam should not have been proposed in the first place and instead a custom solution should be built.
The best layout with regards to meetings with the customer and the BA would be as follows
The reason why it is laid out in that fashion is to give the BAs enough time to prepare for their next meeting with the customer. Consecutive days of gathering customer requirements would not be the best use of their time because there would be too much things to capture and not enough time to think about what they captured.
A colleague at work was also suggesting I try to write up this series as what "I would like for a BA to give me as a developer" rather than being Curam specific, so I have tried to do above by putting in things that are non-Curam specific.
The following points are not Curam specific:
In previous projects, I've worked with BAs that give me 99.9% complete and correct specs and I am amazed by the quality. So at least I had some things to go by.
It is good that they were helpful about it too, if there was something I didn't understand I just came up to them and they pointed me to the right place to look.
Although I do remember one their comments when I do find something wrong: "We don't like Archie as he reminds us that we are not perfect." :-)
However, reality is what development will actually bring out. So if I were a BA, I would have to bite the bullet and tell the client about the error.
Labels:
curam
0
comments
Gathering requirements in Curam does not appear to be an easy thing to do. One can go with a BDUF (big design up front) approach or an iterative development approach. With a COTS package like Curam a combination of the two approaches would be more beneficial.
I've seen a lot of BDUF (big design up front) type documentation in a lot of my projects. Unless you are extremely good at estimating and your customers are very accomodating, these documents tend to take too long to create and is not 80% perfect when they reach their original deadlines.
Iterative development such as RUP/XP try to remedy that. However, unless your sales team is good enough to sell a time and materials contract, then an iterative development approach from requirements gathering to actual development would be a hard sell as well.
Unlike the traditional development approach where you would almost start with scratch, a COTS solution offers a lot of things for you out of the box. However, you would need someone who knows what you can get with minimal changes out of the box. In such cases, you would need more people doing business analysis rather than actual developers. The BA vs Dev mix should be roughly equal, with some of the BAs transitioning to a test team or Curam administrative roles as time progresses.
I am writing this, in case I do switch to a BA lead role with focus on requirements gathering and analysis in a Curam project that may be fixed price.
I say lead, because Curam requirements gathering for any reasonable sized application is not a single or two or three BA job, doing so is asking for a lot of trouble. Conversely, it is not a single or two or three customer representative job, doing so is asking for a lot of trouble as well. It should also be one BA to one customer business rep.
Although my experience in COTS is primarily Curam, I think the concept would apply to most other COTS.
This is the first in a series of blogs regarding requirements gathering. I thought it best to start at the point before you even start working...
Estimating the requirements gathering from an RFP depends highly on the quality of the RFP itself. The following list shows a grid of how I would capture things. The numbers represent some factors I would use in terms of days when calculating things.
| High Complexity | Medium Complexity | Low Complexity | |
|---|---|---|---|
| End to end scenarios | 30 | 20 | 10 |
| Activity scenarios | 15 | 10 | 5 |
| Delivery definitions | 10 | 5 | 3 |
| Rules/Evidence | 30 | 20 | 10 |
| Usage scenarios | 15 | 10 | 5 |
Based on the data, I apply the factors to the counts I would gather from the RFP and just sum things up + add whatever buffer factor I would need.
Complexity is determined by how complete the RFP is in the first place. If there is sufficient detail to generate work products for each component, then I would mark them as low complexity, unless it is really complicated. Remember, I am not building the final application, but rather gathering enough information so the development teams can do their work.
Please note that what I have written above talks about effort. It does not talk about dependencies so things may shift further in duration because of such dependencies.
Labels:
curam
1 comments
Curam uses log4j for logging. By default it only logs stuff that you put in using curam.util.resources.Trace to SystemOut.log. However, since it is using log4j for logging you can tweak it in many different ways by putting your own log4j configuration file.
There is a property that you can change using the web UI or through Application.prx called curam.trace.configfile.location. This specifies the path to a log4j xml configuration file. The following is an example I got from the log4j wiki that you can use to get yourselves started which will dump practically the same data as the standard logger.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> <appender name="console" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%-5p %c{1} - %m%n"/> </layout> </appender> <root> <priority value ="debug" /> <appender-ref ref="console" /> </root> </log4j:configuration>
Of course you'd probably want to tune things in logging like:
This ends up being:
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> <appender name="console" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} - %m%n"/> </layout> </appender> <logger name="Trace"> <level value ="warn" /> <appender-ref ref="console" /> </logger> <logger name="curam.customapp"> <level value ="error" /> <appender-ref ref="console" /> </logger> <root> <priority value="error" /> <appender-ref ref="console" /> </root> </log4j:configuration>
Just don't forget that trace_ultra_verbose messages will not appear with the above configuration so you'd lose some logging. So how do we get around that? Well thanks to log4j, you can create a separate appender to put stuff in there, but since Curam does not include log4j-extras.jar so org.apache.log4j.varia.LevelRangeFilter is not available.
There are two ways of doing application logging in Curam.
The choice generally depends on the logging "control" requirements of the solution.
To perform custom logging, all you have to do is standard log4j. That means
// Define a logger private final Logger log = Logger.getLogger(this.class); // Use the logger log.trace("hello world");
I just define the logger within a private final variable in the class. We don't need it in static usually because most Curam process classes are not meant to be executed in a static fashion. Plus that line can be copied and pasted without having to change anything. If it were static then we need to explicitly specify the class name.
Labels:
curam
0
comments
Curam provides us with a tool called CIARA which allows us to browse around the Curam objects (screens, structs, entities, etc). This tool is available as a standalone tool (which is significantly faster) or as part of DocCenter (which is more familiar).
The tool allows us to actually create our own database containing our the custom objects that are implemented as well. In order to do this, you need to install the standalone tool using InstallCiara.exe. You need to have a valid Curam development installation (with all the environment settings set up).
Another prerequisite is to download and install AspectJ and set the environment variable ASPECTJ_HOME to the appropriate location.
To update DocCenter, a user has to put in the generated CuramApplication.cdb into <doccenter_installation_dir>\ciaradb. The CIARA in the DocCenter can be found in Home -> Business Analysts -> CIARA.
Labels:
curam
0
comments
Like disabling the cache, disabling autocomplete is one of the other things that may be requested for Curam applications. Theoretically this is simple if you control everything in a web application as you only need to put in autocomplete="off" in every form. However, you can't really do that easily in Curam as you don't control the output JSPs nor do they provide you with a facility to do it.
The first inclination would be to modify the generators just like I did when I disabled the cache. Unfortunately, Curam has its own form tag which does not accept the autocomplete attribute. So changing gen-jsp.xsl will not work.
Instead of fixing the output from the generators, we can use JavaScript that gets executed to update all the forms to disable autocomplete. Of course to do that you need to know how to handle the differences between browsers for the onload and the setAttribute functionality.
However, we can get around it by using the standard Curam extension mechanism. If you look at the generated code, then you will notice that there are a few JavaScript files that are always loaded, one of the relatively stable ones that have not really changed is omega3-util.js so we can theoretically use that.
First we make a copy of CuramCDEJ\lib\curam\web\jscript\omega3-util.js to components\custom\WebContent\CDEJ\jscript. That will allow us to separate our customizations from the core files.
Now we write the following script at the end of the file.
function disableautocomplete() {var forms = document.getElementsByTagName('form')
for (var i = 0; i < forms.length; ++i) {
if (forms[i].setAttribute) {forms[i].setAttribute('autocomplete', 'off')
} else { forms[i].autocomplete = 'off'}
}
}
if (window.addEventListener) {window.addEventListener('load', disableautocomplete, true)
} else if (window.attachEvent) {
window.attachEvent('onload', disableautocomplete)} else {window.onload = disableautocomplete
}
Although this change is be done using JavaScript and the scripts can be placed anywhere including gen-page-footer.xsl, this will not be sufficient. The gen-page-footer.xsl file is only used by the standard Curam pages, but pop-ups do not use this file so if the pop-up has a form, the data would be saved.
Labels:
curam,
web-design
0
comments
This is better than disabling the back button, even if it is one of the 10 ten web design mistakes. However, for Curam applications and most web applications, this is something that would really need to be done in order to ensure that the user gets the most current data when they look at a page and to satisfy the requirement of nothing persisted on the client machine.
There are two things that need to be done. The first is to add the following lines to the HTTP header:
Cache-Control: no-store
Pragma: no-cache
Expires: 0
And the following in the <head> block of your web page.
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Pragma" content="no-cache" />
This will make most web browsers not cache the page.
The second thing you need to do is to work around the Internet Explorer bug which disregards the no-cache header information if your page is larger than 64k. To do that add
<head>
<meta http-equiv="Pragma" content="NO-CACHE" />
</head>
Near the end of your file.
Unlike the process of disabling the back button, you cannot simply make the changes on gen-page-header.xsl or gen-page-footer.xsl. The changes need to be directly done on CuramCDEJ\lib\curam\xml\xsl\gen-jsp.xsl.
Note: If there are any upgrades to Curam, the changes need to be redone on the file.
In gen-page-header.xsl, add the following XML after the first instance of <head> in the jsp.xsl
<jsp:scriptlet>
response.setHeader("Cache-Control", "no-store");response.setHeader("Pragma", "no-cache");response.setHeader("Expires", "0");</jsp:scriptlet>
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Pragma" content="no-cache" />
You also need to add the following XML after the scriptlet that outputs </body>:
<head>
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Pragma" content="no-cache" />
</head>
This has only been tested on Firefox and Internet Explorer 6, but it should work with most browsers.
Labels:
curam,
web-design
0
comments