Web performance in seven steps; step 2: Execute a proof of concept
Posted by Jeroen Borgers at around evening time: June 15th, 2009
Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more...)
Web performance in seven steps; step 1: define performance requirements
Posted by Jeroen Borgers at around evening time: June 10th, 2009
Last week I blogged about how performance problems manifest themselves: frustration, loss of revenue and disruption of development; and how adding hardware is a questionable solution. This week I'll blog about the first step to assure web performance.
It can be a valid choice to run the risk of performance problems in production and deal with them in a re-active manner. However, it is usually wiser to be pro-active and prevent them. This approach brings more certainty, peace of mind and also saves money. It consists of seven steps. Step 1: Define performance requirements.
(more...)
“The Best Requirements Method” survey
Posted by Erwin Bolwidt mid-afternoon: May 8th, 2008
What is the Best Requirements method? That's a mighty big and difficult question to ask, for several reasons. Everyone has a different idea of "best", but also of "requirements method".
While I could try to analyze various methods according to various statistics, it would still only give a one-sided view on the subject. In addition I only know a few methods very well so that would leave out other methods.
A different approach, the one that we take here, is to ask you, the participant in the requirements process.
(more...)
Flex Beyond — eForms
Posted by Balaji D Loganathan at around evening time: March 5th, 2008
Around 6 months back me and Vikas Hazrati gave a XTR on Adobe Flex to my colleagues in Xebia India.
We took some resources from Adobe Dev Net site and eventually found a cool article explaining how Flex Data Services works with Spring using Spring Remoting features and so on.
We were quite amazed with the UI capabilities of Flex with its server side integration. If you look at that article now, its start with a disclaimer saying "Effective with the release of Adobe LiveCycle ES, the Adobe Flex Data Services 2 server product has been rebranded as a Solution Component of LiveCycle ES."
(more...)
Is it a Requirement or is it Design?
Posted by Erwin Bolwidt in the late afternoon: January 18th, 2008
Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more...)
Your SOA product choices should be based on the QUINT model
Posted by Viktor Grgic in the early afternoon: January 16th, 2008
It is always about well-defined requirements stupid. 
Building or choosing out-of-the-box software products like an ESB within the company's SOA strategy can be very well supported by a number of requirements distilled from the QUINT2 ISO model:
Functionality: Suitability, Interoperability, Compliance, Security, Traceability
Usability: Operability, Customisability
Efficiency: Time Behaviour
Maintainability: Testability, Manageability, Reusability
Portability: Adaptability, Replaceability
This is the selection from the complete QUINT2 model. It does not mean that other requirements are not important, but usually less than these. If you fill out these requirements properly, which is still a daunting task, then you will have done pretty good requirements gathering. Besides these aspects, there are also security requirements: availability, integrity and confidentiality which should always be considered.
Agile Up Front Analysis
Posted by Erwin Bolwidt late at night: July 16th, 2007
One of the most visible aspects of agility is making decisions when they are needed, and not making them all up-front, before any development work is done. But some decisions are needed before the rest of the project is executed.
An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.
Reality is not plan based - Plans as a communication device
Posted by Gerard Janssen terribly early in the morning: June 11th, 2007
When it comes to the contents of plan there is a big difference between prescriptive and criterion based approaches. As we stated before the idea behind a plan is to provide guidance to the activities on the project. In that sense it is a sort of communication device. However, the way we use the plan determines its effectiveness.
A plan should describe how to realize the business case on which the project is based. In the criterion based approach to project management this means that the intention of the project is described, but not all activities on how to materialize the business case are specified. The essence of the plan is to explain or to translate the business case into practical guidelines and criteria on how realize the business case. Put differently, it specifies the high level requirements for the project that need to be met for the project to be deemed successful. Tom and Kai Gilb for instance like to state that approximately 10 high level requirements should be enough to give direction to a project. These requirements then are the criteria used to measure the progress and success of the project.
Top 10 recommendations when defining B2B services
Posted by Viktor Grgic in the wee hours: April 5th, 2007
Requirements engineering and design of services that your company need to provide to other companies is quite different from reqs. engineering for an interactive website, or other systems where an actor is a real person. In case of B2B services, the actor is always another system. Mostly you also know who your actors / other companies will be, unless you are Amazon or Google.
These recommendations will give you some tools and ideas how to deal with requirements engineering and design of B2B services.
Archives
Xebia Sites
Categories
- Java (233)
- Agile (100)
- General (50)
- Performance (37)
- Hibernate (35)
- Podcast (31)
- Testing (30)
- Scrum (27)
- Spring (24)
- Project Management (22)
- Architecture (22)
- SOA (19)
- Flex (17)
- Maven (15)
- Eclipse (14)
- JPA (13)
- Quality Assurance (12)
- Groovy (12)
- Articles (11)
- Grails (11)