Ivesia Solutions Inc

Software developers often are faced with a bewildering array of choices while developing software. Oftentimes frameworks, tools and technologies are mandated by client organizations to development teams. It is very possible that the team members are not exposed to at least one of the important technologies, tools or frameworks.

In the rush to shorten the learning curve and to get the development completed, very often basic development guidelines for successful development are ignored. Basic principles of object orientation and modularity of code are ignored and several transversal functions are unstated and are not met. This is discovered half way through the … Continue Reading

Agile works well with small and co-located teams. Does this mean that agile cannot be used for larger enterprises that requires scaling, and in outsourcing engagements? It certainly isn’t the case as distributed teams are deriving value from agile development. Practicing agile in distributed environment is more complex than practicing agile in co-located teams, and it requires a lot of efforts to make this work.

In our experience, when we started making modifications in agile to make it work in distributed environment, we realized that it did offer a lot of benefits.   In fact, we have used agile methods even in our professional services engagements with … Continue Reading

Fixed bid projects are characterized by fixed time, predefined scope and fixed budget. Add to this, predefined quality checks. We will keep quality out of consideration for it can be never be considered a variable. The other three (time, scope and budget) can be considered variables. In most fixed-bid projects, none of them are allowed to be variables, which more often than not, lead to the project not meeting the expectations of stakeholders. Having all three of time, budget and scope fixed is very unrealistic and will most likely result in project failure. However, if we can change one of the … Continue Reading

Whenever we engage with the customer, the most critical aspect will be to align our knowledge with the customer needs. This is especially true and complex, when you are talking about outsourced product development, as we ought to align our knowledge with our customer’s customer needs.

In my mind, product engineering is a domain and expertise by itself as the skills required to build a product are far different from the skills required to build an application. Product is never custom-built for a particular customer; rather it is generic and requires better skills to ensure that the code base is scalable, robust … Continue Reading

I was having a conversation with an enterprise software vendor. He was mentioning that the biggest challenge that he faces is that he is not able to increase the adoption levels of his software and it is costing him dearly.  I just casually mentioned to him that the usabiilty of his software should be as simple as using a desktop productivity tool. I am not sure if this got him thinking, but it certainly got me thinking deep about how we do this at Ivesia. 

I just broke them down into user adoption challenges and the solution that Ivesia offers. I’ve just reproduced them … Continue Reading

Prototyping is one of the most important activities of requirements analysis. Typically when people think of requirements gathering, they think about writing a document. Although writing a formal document is necessary, it is not sufficient to provide non-technical users a good understanding of the product that is being built.

For most web applications, a simple prototype can be easily created using plain old HTML. This will provide the customer with an understanding of the user interface of the application and the workflow of the system. Misunderstandings can be quickly corrected thus putting the requirements on a firmer footing.

Prototypes are usually meant … Continue Reading