Posts Tagged ‘Derwyn’

1.7 for single users and unlimited read only

Thursday, July 12th, 2007

We just released our 1.7 for single users which comes with a free named license and unlimited read only access. It’s only been one day and already we’re getting a huge response. This option is a great way to get started with no hassles. Just download Contour, install and your off and running.

This release is very exciting for us, most notably for the subtle and indirect changes.

We have a new logo, which I think is a huge improvement. Something about the circle captures our belief, that the whole team is in it together. Can you feel the love? Also, and this isn’t so small, we have a new web site. The site itself is worth perusing, there’s actually a great paper called “Requirements Redefined” that is based on the premise that Requirements Management is valuable but a pain in the @*s#!, I’d be interested in hearing your thoughts on it.

Contour itself has a much improved installation, one button….well almost. There’s a “what’s new” that tracks events in the system and then displays them when you log in, so you can see who did what and when. We also did some color tweaking and UI cleanup.

It’s good to get a release out the door but I’m always looking towards the next release. We have so many cool ideas bouncing around, it’s hard to know what to tackle first. We’ve set up a “backstage” site where the public, as well as current customers, can post support questions, comments or feature requests. We’ll also be posting our ideas looking for feedback. I hope you’ll join us there, the more the merrier.

Our Manifesto

Friday, June 8th, 2007

I thought I’d put together a manifesto of sorts that describes our beliefs and the corresponding features in Contour.

Every Project is unique

By making artifacts completely customizable we’ve enabled companies to define their own process. Therefore Contour can adapt to your process rather than the tool forcing your team to adapt.

The whole team matters

A team is made up of many different roles and personalities. Usability, accessibility and notifications are key to ensuring all members utilize and benefit the tool.

Change happens

Tracking change and knowing the impact of a change is critical throughout the life of a project. Contour utilizes traceability between any or all artifacts and provides multi level deep impact analysis, suspect links, matrix and notifications of change.

Data can be everywhere and anywhere

Your requirements may currently exist in Word, Excel, a database or have yet to be gathered. With Contour you can import data, migrate data, or enter data. From there you can attach images, documents or URLs to an artifact. And lastly you can filter, export or render your data in custom reports that are rich and informative.

We’ll be adding more. Feel free to contact us if you can think of other items that should be listed here.

Cross Project Linking

Wednesday, January 31st, 2007

Contour’s cross project linking allows a project to reference a requirement in a separate project.

Several clients had requested the ability to link requirements (or any items for that matter) across different projects. During analysis we realized that there were several possible implementations.

One option was to completely link an item from one project into another, such that every attribute exists within the original item. This posed a few problems. Namely that attributes on a requirement (status, priority, assigned to, release, custom, etc) differ from project to project. This problem is especially glaring when considering a project release. One projects release is potentially meaningless to another project. All that is really required is the core of the item being linked, like the requirement description, in the case of a traditional requirement.

This lead us to option 2. Say we have ProjectA and ProjectB. We could create within ProjectB its own item that references, or contains within it, a kind of a proxy to the item in ProjectA. This enables two things. One is that we now have a reference in ProjectB to an actual item in ProjectA, such that, the original item is still owned and managed by ProjectA. While ProjectB has it’s own attributes surrounding this reference. ProjectB can now manage this item under it’s own configuration and process. This is the approach we took when we implemented what we call “Cross project linking”. The image below shows an example of an item in ProjectB that has, or references, an item that exists in ProjectA.

Cross Project Link display

There was a third option that is worth mentioning. Utilizing Contours traceability feature, it would be possible to create a trace relationship to an item in a separate project. It’s clean because it allows you to link across projects without having to create new items in each project. However, there are advantages to having an item that can be tracked and managed independently within each project. In the end we have implemented option two but will be looking for solutions around cross project traceability that may coincide.

Ajax to Java Class

Sunday, January 28th, 2007

Learn from our experiences in building Contour!

Early on in the development of Contour two of our key requirements was it had to be web based with a intuitive and usable interface. This lead us down the path of Ajax which has been a challenging, fun and I’ll go so far as to say a revolutionizing experience. I gave a talk at the Ajax Experience in Boston last year about this experience and the lessons learned while building Contour using Java and Ajax. I felt that it was well received, theServerSide even filmed it (although I have as of yet to see it posted). In putting the presentation together I realized that what we’ve learned and accomplished in the last year could not be summed up in a 90 minute presentation. My presentation focused on what I called the phases of adoption, which basically helps development teams migrate to Ajax slowly and with little impact. Big gains, less pains.

The hardest part is ensuring that you don’t sacrifice design and well written code for the sake of ramping up on Ajax knowledge. There will always be the on-the-job learning but knowing the end goal and having a head start will reduce many of the complex problems that can crop up if you begin to implement Ajax haphazardly.

To help with that head start we decided to put together a two day course that introduces you and guides you down several possible end goals in adopting Ajax in a J2EE application. By strengthening your Javascript and working with proven frameworks like dojo and DWR, adopting an Ajax model can be done in a more structured and controlled manner. Check it out and I hope to see you there.

Ajax Course

Day two – the Ajax experience

Wednesday, October 25th, 2006

Day two for me was all about focusing on dojo and DWR seeing as how that is what we’ve been using in Contour. The day started off with an intro to dojo which was a good overview. Alex Russell is a fantastic speaker and represents dojo very well. If anything, the talk at least gave me confidence in the people behind dojo. After that came the advanced dojo topic which was more a promotion of the new things in .4 which was fine with me. Many times that’s really more what these conferences are about, that which is new and exciting. And to be sure the .4 dojo does have some exciting little ditties.

I then sat in on the Advanced DWR with Joe Walker who, with the help of Bram Sheets put on a “live” demo of DWR in action building an interactive battleship game. I certainly like the idea and felt that they pulled it off quite well. But it did seem to distract from the “advanced” aspect. Seems there may have been more time spent the 2.0 implementations such as the engine.js having to refresh each time. He mentioned in passing that this will change soon, I’d be curious what this change will be. Over all however, a great demo and also reaffirmed my decision to use DWR in our application.

Day one – the Ajax Experience

Monday, October 23rd, 2006

Arrived late last night and with a solid 4 hours of sleep head into the first day at The Ajax Experience. My presentation is this afternoon at 5:15 when I’ll be sufficiently worn out.

Just finished the keynote with Ben Galbraith and Dion Almaer. In summary they gave a rousing tribute to the reasoning behind having a term for Ajax. The market place seems to thrive on buzzwords and hype to make change happen. Ajax is nothing new and could have been done years ago however since the hype of Ajax many websites are now Ajax enabled. Finally it’s time for the users to benefit from the evolution of technology. As Ben and Dion mentioned years have gone by with many advancements in technology that served to improve the lives of developers but nothing change in the front end leaving users to fend for themselves as they struggled along using applications that where so 90’s. Let the revolution begin.

Derwyn to speak at the Ajax Experience 2006

Friday, October 13th, 2006

Our own Derwyn Harris will be speaking at The Ajax Experience on October 23rd in Boston.  Derwyn will be talking about reengineering Java applications using Ajax.   You can read more about the presentation at the Ajax Experience Website.

This is also the story of building Contour, our requirements management tool as we evolved from a JSP to Ajax model.

What’s in a release?

Saturday, June 24th, 2006

There is a bit of irony in building a tool without a tool. It’s like building a table for a workbench so you can then build a table. So far we have been very efficient in our process of building our Requirements Management tool. We have a small team, with white boards and a wiki. What more could you need.

However, as time goes by, the code base grows along with the feature list. Suddenly we have a beta release and realize that our timeline is running short and people other than ourselves are contributing new ideas, adding features, and changing others. I woke up one morning and realized that my ever increasing anxiety was the fact that as our application grew my ability to keep track of it all shrunk. One answer of course is a tool, but what I found interesting was that, for me, the event that marked this need was not necessarily the requirements themselves but the management of what requirements were where, in other words, releases.

Alan M. Davis mentions in his book Just Enough Requirements Management the importance of being able to see a quick list of the requirements based on a set of specified annotations, such as release, status, priority, owner etc.

The Ying Yang of Process

Wednesday, June 14th, 2006

This article states that “developer misunderstandings of user requirements are the leading cause of defects in software.”  I do believe the developer should be better connected to the actual requirement. However even when using different methodologies, like Agile, there can be a disconnect. Documentation, conversations, phone calls, meetings after meetings all take place before the developer sits down to code. It is essentially up to the developer to translate what needs to be done based on a myriad of communication. And yet everyone is trying to figure out why this disconnect exists and the answer always seems to be either less process or more process! Niether of which truly addresses the problem. In my mind within a project you have different groups, all with very different needs. Analyst may do better with more process while developers prefer less process.

In my humble opinion there is one fundamental need for all parties involved, and that is a simple concise definition of the requirement. If all the meetings, conversations, emails and documentation could center around this simple thing we would have a common ground from which begin and end.

Technology choices

Tuesday, May 30th, 2006

In the early stages of product development a major decision for us was what technology to use. There are many considerations such as distribution, how the product will be used and by whom. In my opinion it tends to come down to two things. Desktop vs web based. Obviously Desktop has many advantages when it comes to building a powerful application whereas Web based is easier to update and distribute. However those lines have become increasingly blurred. I was at a conference just a little over a year ago where I sat in on a presentation about an application implementation using Java Web Start. The argument the presenter was making, was that the browser was too limited and stagnant since the IE dominance, and that Microsoft’s goal was to limit the success of browsers in order to better promote its Web Forms. He went on to describe the glory of developing using Swing and Java Web Start.

I had an opportunity to pursue a solution, like the one above, using either Swing or SWT, but my team was primarily J2EE skilled and the client was interested in a browser based solution. We ended up implementing the application using Struts, but I always felt restricted by the browser. We were as creative as possible using Javascript to do some fun user interface solutions, such as using iframe’s to create a more dynamic feel. But all of this was more eye candy than it was a constant “rich” interface.

Now, faced once again with choosing a technology for our Requirements Management Tool it was clear we wanted the application to be web based for the ease of distribution, but it was equally important for the user interface to behave like a desktop application. We began looking into Ajax. However we were a bit scared of the overhead of implementing such a Javascript reliant application. After all, myself and the rest of the team were used to enterprise applications working with Java, .Net, Web services, Struts etc. We had all used Javascript but never to this extent. And to be honest we did not trust that JavaScript, on such a large scale, would be maintainable.

So we hesitated and dove into coding using Spring, Spring MVC and Hibernate. After all, there was still a lot to think about. We set up the build system to use Xdoclets to generate the Hibernate mapping files. We were much more familiar with Struts but were ready to move on and liked the looks of Spring and it’s MVC implementation. As well we plugged in Acegi as our security framework. All the usuals where there such as JUnit, Eclipse, Tomcat. We found a cool DHTML Tree for our requirements page, Canoo WebTest for our acceptance tests and CruiseControl for our build automation. All that was missing was a slick user interface. We applied some cool css but at the end of the day it was all still click-controller-refresh-view (transient). It wasn’t until we came across DWR that we began to realize the possibilities in accomplishing a sovereign application as described in Ajax in Action.

Next week; DWR and Dojo…

Derwyn

© 2007-2010 Jama Software. All rights reserved.       Contact Us  |  Privacy  |  Sitemap  |  Preferences  |  Enjoy the Journey