UML The UML has emerged as the de facto and de jure standard diagramming notation for object-oriented modeling. It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to combine the diagramming notations from their two popular methods—the Booch and OMT (Object Modeling Technique) methods. They were later joined by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. Many others contributed to the UML, perhaps most notably Cris Kobryn, a leader in its ongoing refinement. Read More |
Project Management In order to complete any task efficiently, and to insure effective use of resources directed toward that endeavor, some method must be devised. Systems development is no different, but the task can be especially difficult due to the complexity of modern computer based information systems. For that reason, the development of information systems in today's business organization absolutely requires that a careful and formalized approach be taken. . Read More |
Organization
Methodologies in and of themselves are meaningless without clear expectations. Expectations can include terminology, process, procedure, etc. It will not matter how a problem is approached, if the expectation was not managed and/or met, the solution is worthless. That said, methodologies are as much a matter of best practice as they are personal style. To make a distinction, a method is a recipe, a series of steps, to build software, while a methodology is a set of recommended practices. Methodologies impose a disciplined process upon project, from building to software development, with the aim of making the project more predictable and more efficient. This is done by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines –these are plan-driven methodologies.
Plan methodologies (or sometimes known as waterfall process) have been around for a long time. They are predictive and sequential. From a user perspective they have not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are very difficult to change, and for the most part require a significant intervention by the whole team. In any type of software project there are so many interwoven files to address to follow the methodology that the whole pace of development slows down.
Agile methodologies, like Iterative Development evolved as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff. Agile methods are adaptive rather than predictive. They try to be processes that adapt and thrive on change, even to the point of changing themselves. Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work.
UML is a visual paradigm that encompasses all the benefits of a Unified process and agile methods. It is iterative and timeboxed, or fixed length of time. The iterations converge towards the most appropriate requirements. This usually means that user feedback and adaptation usually result in an organizational competitive advantage..