CSC/ECE 517 Fall 2011/ch6 6f jd

Introduction

The concept of heavier-weight methodology

Heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment. Heavyweight development methodology mainly focuses detailed documentation, inclusive planning, and extroverted design. Following are the most popular Heavyweight development methodologies.

The concept of agile methodology

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints.

Compare with the heavier-weight methodology and agile methodology

Heavier-weight methodology

Heavyweight methodology: (1)A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly. (2)Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time. (3)Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail. (4)This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules. (5)But this works well only until things start changing; therefore, project managers who use heavyweight methodologies will resist change. (6)The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment. (7)An example of a “heavyweight” process is the Rational Unified Process. (8)Project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology (9)Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.

Agile methodology

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work. It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?