In my previous post on High Level Project Estimates, I talked about 3 points estimates to help provide an up-front estime of effort for a project. Aside from the effort estimate you also need to consider other aspects that the team will spend time on. The following are some aspects I consider with the kind of percentages (above the effort estimate) I have experienced. Note: these percentages are by no means standard or the norm they are essentially a rough guess based on the projects I have worked .

• Planning Meetings @ 10%
• Demos @ 2%
• Code Reviews @ 5%
• Retrospectives @ 5%
• Dark Mater @15%
• Bugs @15%
• New Technical Stories and Spikes @ 25%
• Change Requests (shouldn’t average more than 15%)
• Holidays and Sick Leave @ 5%

You will also need to consider Management Overheads as well as Business Analysts (if included in the team), QA/Functional Testing, Support and Maintenance (if required).

What is the best way to review a backlog? How do you ensure that it is “complete”? How do you ensure that the prioritisation reflects the business vision and goals?

When first faced with a backlog, you are often overwhelmed by the long list of userstories. The most important step is to set a context for these userstories. Are these userstories organised in a hierarchy of “epics”? This hierarchy will help set a context. But first we need to understand what these epics mean at the highest level. Do they represent a user’s high-level goals or are they merely there as a container for some loosely related stories?

When reviewing a backlog for completion it is vitally important that the stories are defined in a context. The context can take different forms depending on the nature of the application. For example if an application has a clear high-level flow that the user journeys along then the epics may be defined as activities in this flow and the userstories can be grouped under each epic representing the functionality required for this activity. This article by Jeff Patton presents such an approach. However, your application my exhibit a more random usage scenario. In this case epics representing high-level user goals may represent the best context for the stories. You can also provide references to other artefacts such as user journeys/wireframes to further enrich the context. This article by Scott Sehlhorst is an interesting discussion of setting a context for user stories.

This grouping of userstories by a context also helps to manage their prioritisation. You can individually prioritise stories within each epic and then also prioritise the epics. Note that just because one epic has a higher priority does not mean that all its child userstories are of a higher priority. You may discover that only the first few userstories can provide enough functionality that further work on that epic is of a lower priority then working on another epic.

Often I see Unit Tests with the test methods that have the same name as the method under test prefixed with the word “test” e.g. testSubmitApplication. This provides no extra information on which “flow” of the mothod is being tested. Other test method names provide a bit more information by suffixing the nature of the test e.g. testSubmitApplicationWithInvalidCriteria. It better but not much better. A number of IDEs actually allow the developer to generate test method names based on the class under test which in my opinion defeats the object.

Unit test methods should be named in such as way that they provide a clear description of the test. In my opinion the prefix “test” is redundent and should never appear in your test method names unless it is part of the domain vocabulary. For example AppicationSubmittedWithInvalidCriteriaMustRaiseException* is more informative then testSubmitApplication. Providing a more descriptive name also serves to keep a clear focus on the flow under test and leads the devloper to create a test method per flow.

*Please Note that the example method name is a simplification. I would consider the term “InvalidCriteria” a bit too high-level for a real unit test. It should be more specific such as AppicationSubmittedWithNoSurnameMustRaiseException.

Performance issues in a application manifest as bottlenecks in one or more of the following 4 layers:

• Application: Application is not designed, developed or configured properly.
• Platform: The platform that the application runs under (e.g. App Servers, Databases etc.) is not setup and configure.
• System: The hardware the platform runs on is not sufficient.
• Network: The network capacity is not sufficient. This is relevant when various parts of the platform are involved in high-bandwidth communication with each other).

The first step in Performance Tuning is to have an environment setup that is a realistic copy of the production. Then we look at what exactly are the performance requirements, these will be expressed in terms of
Round Trip Delay and Throughput (number of concurrent requests).

We can then devise some performance tests that exercise the application through typical usage scenarios and execute these tests to collate data that will provide the baseline for subsequent tests.  The data can be collated in the following areas:

1. Response times and throughput for the over all application
2. Response times and throughput for various parts of the platform
3. Response times and throughput for various layers of the application
4. Resource utilisation both at the platform level (e.g. thread profile, memory profile, socket connections  etc.) and system level (CPU utilisation, Disk IO, Network IO etc.)

Once collated and represented in graphical form you can then start looking at indicators where bottlenecks may be occurring. Please note: that these are simply indicators of performance bottlenecks meant to highlight areas which will most likely require further investigation and tests (in isolation) to pin point the exact problem. Performance tuning is an iterative process with the following steps

1. Perform Load Test
2. Collate and Analyse Test Result Data
3. Compare with Previous Test Result Data (if not the first iteration)
4. Analyse impact of changes (if not first iteration)
5. Check if improvements satisfy the performance requirements
6. Analyse to identify bottlenecks
7. Investigate and isolate the problem
8. Perform remedial action to eliminate bottleneck

Note: You should start with a baseline of results that you can compare the impact of your changes against. You should only tackle one bottleneck at a time making minimum necessary changes before performing another test.  Once you have made enough improvements to satisfy the performance requirements then you should stop the tuning  process.

Selecting the level of results for your baseline is also important since more granular data require more up-front work. One approach is to start at a higher-level, go through the process to see problems can be identified  at that level. If not then create another more granular baseline and repeat the process.
It is obviously very important that your environment and test scenarios remain the same as the baseline throughout the process.

Sun Glassfish server can be run in embeded mode, very useful for automated integration tests. Here’s how:

Maven Dependencies:

<dependency>
  <groupId>org.glassfish.distributions</groupId>
  <artifactId>web-all</artifactId>
  <version>10.0-build-20080430</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.glassfish.embedded</groupId>
  <artifactId>gf-embedded-api</artifactId>
  <version>1.0-alpha-4</version>
  <scope>test</scope>
</dependency>

If you are not using maven then add the above libs to you classpath. Getting the server started in simple

final URI APP_URI= UriBuilder.fromUri("http://localhost/").port(8888).path("myapp").build();
GlassFish server= new GlassFish(BASE_URI.getPort());
ScatteredWar war = new ScatteredWar(APP_URI.getRawPath(),
   new File("src/main/webapp"),
   new File("src/main/webapp/WEB-INF/web.xml"),
   Collections.singleton(new File("target/classes").toURI().toURL()));
server.deploy(war);

You can then use any HTTP Client to send a HTTP Request to the server on a defined port. For automated integration tests use TestNG “dependsOnMethods” feature to ensure that the server was started before executing you integration test group(s). You can then have anther test which depends on your integration test group(s) to ensure that the server is stopped when tests have finished.

You can stop the server with server.stop(). Note: If you are using Maven then using cargo to bring up the server may be more advisable.

The layout of a portlet is handled by a set of JSP in the portal-core web-app which is part of the jboss-portal.sar. In the web-inf direcotry have a look at portal-layouts.xml to see how various layouts are configured. The following is a snippet (self explainatory):

<layouts>
<layout>
  <name>rbs-1column</name>
  <uri>/layouts/mylayout/index.jsp</uri>
  <uri state="maximized">/layouts/mylayout/maximized.jsp</uri>
  <regions>
    <region name="regionBody"/>
  </regions>
</layout>
</layouts>

You can make changes to these JSPs and the portal-layouts.xml. Alternatively (recommended), create you own theme in a separate web app (war file) and change the following config in jboss-portal.sar/META-INF/jboss-service.xml. You need to change the fillowing lines:

• Change layout context path: <attribute name="TargetContextPath">/mylayoutapp</attribute>
• Change path to header jsp: <attribute name="HeaderPath">/WEB-INF/jsp/myheader.jsp</attribute>
• Change path to tabs (navigation) jsp: <attribute name="TabsPath">/WEB-INF/jsp/mynavigation.jsp</attribute>

The new war file will need to have access to the to portal lib tag-libs. These can be found at jboss-portal.sar/portal-core.war/WEB-INF.  Your layout JSP specified as “url” in the portal-layouts.xml will need to include the following directives:

• In the html header: <p:theme themeName=”mytheme”/>, <p:headerContent/>.  See http://java.dzone.com/articles/jboss-portal for a guide on creating custom themes.
• In the body: <p:region regionName=’regionBody’ regionID=’regionBody’ />. This will need to be added for all the regions defined in the portal-layout.xml for this particular layout.

Note: Theme and layouts can be specified in the portal page deployment descriptor (see property theme.id and layout.id)

Jira from Atlassian is a very popular issue tracking software and can be quite effectively used for Agile Project Management. Jira has a plugin (Green Hopper) that allows for creation of a backlog, iterations and tasks. However, with help from the free Mylyn plugin for Eclipse I was able to setup a Product Backlog and Iteration Backlogs.

For the User Stories in the product backlog I created two issue types (Epic & User Story). Story hierarchies can be represented using Jira Links.

For Iteration Backlog I created a version for each iteration and assigned the stories to that version/iteration. Each leaf story can then have Jira Sub-tasks to represent the tasks in a particular iteration. The Resolved state of the story is used to mark it complete and Colsed state is used to mark it as “accepted”. You can use Mylyn to see story hierarchies, also I found Mylyn to be a much more intuitive interface when working on Product and Iteration backlogs.

By Mashooq Badar.

Click here.

How do you make applications portlets available to page authors in CQ5, so page authors can design/author the complete site without requiring application releases?

By Mashooq Badar.

By Mashooq Badar. Click here.

The Portal Server has it’s own means of generating menus and CQ5 has a different mechanism. How do you synchronise the two?

Valtech consultant Mashooq Badar writes on managing CMS and web applications here.

In this blog we look at the challenges for a CMS in managing a site that has embedded web applications – using examples of JBoss Portal and CQ5 CMS from Day.