CSC/ECE 517 Fall 2011/ch6 6e zj: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(162 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Introduction==
==Introduction==
===The concept of heavier-weight methodology===
===The concept of heavier-weight methodology===
Heavyweight development methodology(Traditional 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.
Traditional methodology which is also known as Heavyweight development methodology that 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, its typical example is waterfall model.


===The concept of agile methodology===
===The concept of agile methodology===
[http://en.wikipedia.org/wiki/Lightweight_methodology Agile methodology(Lightweight 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.
[http://en.wikipedia.org/wiki/Lightweight_methodology Agile methodology(Lightweight Methodology)] is an iterative and incremental approach to project management, typically used in software development. It helps teams respond to the changes of building software quickly and efficiently . <ref name = "agile1">http://acm.web.auth.gr/2011/03/03/agile-methodology/</ref>
 
===Overview of this article===
 
In section 2 we introduce the comparison between heavier-weight methodologies and agile methodologies, we provide both advantages and disadvantages for both heavier-weight methodologies and agile methodologies. In sections 3, we provide the examples for both heavier-weight and agile methodologies. In sections 4, we discuss how to choose methodologies when developing software. Sections 5 tells under which situation you could avoid using agile methodologies.


==Compare with the heavier-weight methodology and agile methodology==
==Compare with the heavier-weight methodology and agile methodology==
===Heavier-weight methodology===
===Heavier-weight methodology===
Heavyweight methodology:
Heavyweight methodology<ref name = "agile2">http://www.techrepublic.com/article/heavyweight-vs-lightweight-methodologies-key-strategies-for-development/5035285</ref>:
* A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.
* A heavyweight methodology which is composited with rules, practices, and documents makes us discipline and time to follow correctly.
* Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time.
* Heavyweight methodologies focus in the great detail of the project.
* Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail.
* The specifications, reports, plans, schedules and checkpoints is required by the lead managers.
* This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules.
* For the reason that the heavyweight methodology plans about the requirements, design, etc. before the project is actually started, so the project managers who use heavyweight methodologies will resist change.
* But this works well only until things start changing; therefore, project managers who use heavyweight methodologies will resist change.
* Requirements, solution build, testing and deployment are always the basic steps for the heavyweight development methodology.  
* The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment.
* [http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process Rational Unified Process] is one of the widely used example of “heavyweight” methodology.
* An example of a “heavyweight” process is the Rational Unified Process.
*If the project needs multiple teams working at several locations, and you need them to work tighter to develop some core parts of the project, in such condition heavyweight methodologies can be a better choice, because they could adhere to the requirements, design documentation, which will avoid that they work in wrong direction because of inconvenience communication.
* Project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology
* 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.
 
====Advantage of heavier-weight methodology====
====Advantage of heavier-weight methodology====
* It is very easy yet powerful method of software development. The phases are arranged so that it helps even the new developers to understand the “big picture” of how to go about developing the software through the software development life cycle.
* It is a clear and powerful method for software development, many big corporations use this method to develop software. It clearly defines software development life cycle, which help a new developer better know how to develop the software.  
* It calls for a disciplined approach to save on project time and cost as well effort. Otherwise the implementation team may develop a code only to realize later that it was not at all required. This happens much more than one might realize and it cause issues both in development and testing.
*Because we have clear stated what to do before the project actually start, this will save us time to do only those that we actually required. It always happen that a project team do a lot of effort to code and then later found out that it's not required at all. So using this method and adhering closely to documentation, It will avoid of those useless effort.  
* The project management stakeholders are forced to correctly define the business requirements documentation (BRD) and the project management requirements. At the same time the developers are forced to understand these thoroughly before they start writing the software requirements specification (SRS), high level design and code.
*The project stakeholders are forced to clearly and correctly define the business requirements documentations. Also, developers are forced to completely understand the requirements before starting doing the high level design and coding. Without thoroughly understand the requirements, they will fail to meed the corresponding milestone and fail to continue the project.
* It essentially requires documentation at every stage. This gives better understanding of the requirements, the logic of the codes and tests that were conducted on the software.
*Actually, making documentation at every state is an very essential step. It helps better understand the requirements, design the code , write code and design test on the software.


====Disadvantage of heavier-weight methodology====
====Disadvantage of heavier-weight methodology====
The traditional project methodologies that many top corporations use, such as the SDLC approach, are considered to be bureaucratic or “predictive” in nature, and they’ve resulted in many unsuccessful projects. These “heavyweight” methodologies are becoming increasingly unpopular. They can be so laborious that the whole pace of design, development, and deployment actually slows down.
The traditional project methodologies that many top corporations use, such as the [http://www.webopedia.com/TERM/S/SDLC.html SDLC approach], are considered to be bureaucratic or “predictive” in nature, and they’ve resulted in many unsuccessful projects. These “heavyweight” methodologies are becoming increasingly unpopular. They can be so laborious that the whole pace of design, development, and deployment actually slows down.<ref name = "agile2"/>
<br>Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time. Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail. This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules. But this works well only until things start changing; therefore, I believe project managers who use heavyweight methodologies will resist change.
<br>Heavyweight methodologies try to plan majority part of the project in great detail.it assumes that every requirement of the project can be identified before any design or coding occurs Project managers need to predict predict every project milestones because they need those technical details, which result in a large number of documentation, such as plans, report, and schedules. However, we know, when doing a project, there are always a lot of changes, such as that the client may change their requirements, then all the schedules, checkpoints made for the project need to get changed. So making all the details for a project before actually starting the project is not an effective way.  
<br>The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment, whereas lightweight methodologies propose executing the project steps in parallel. For example, the manager of a project that is based on the heavyweight methodology won’t agree to build the IT solution until the full requirements have been determined, and so it continues for each project phase. Still, any project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology. 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.
<br>Heavyweight development methodology is based on a sequential series of steps, such as requirements, solutions, testing and deployment, which means that every step could only be started with the finish of previous step, while the lightweight methodologies propose to execute the project steps in parallel.


===Agile methodology===
===Agile methodology===
In 1970, [http://en.wikipedia.org/wiki/Winston_W._Royce Dr. Winston Royce] presented a paper entitled [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf “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.
"In 1970, [http://en.wikipedia.org/wiki/Winston_W._Royce Dr. Winston Royce] presented a paper entitled [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf “Managing the Development of Large Software Systems”] <ref>http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf</ref>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."<ref name = "agile3">http://agilemethodology.org/</ref>
====Is agile methodology good?====
 
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?
====Advantage of agile methodology====
====Advantage of agile methodology====
* Agile methodology has an adaptive team which is able to respond to the changing requirements.  
* The most important characteristics of Agile methodology is that it is adaptive, making the team is able to respond to the change of requirements. We know that it is a quite common thing for requirements to get changed when developing a software.  
* The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed.  
* The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed.  
* Face to face communication and continuous inputs from customer representative leaves no spaces for guesswork.  
*The close communication from customer and the designer makes all the requirements clear and if somethings changed, the develop team could quickly respond to the change, there is no guesswork here.  
* The documentation is crisp and to the point to save time.  
* No complicated and burdensome documentation, which saves a lot of time when developing software.  
* The end result is the high quality software in least possible time duration and satisfied custormer.  
* The outcome is always the software that best satisfy the customer, as they closely communicate during the developing proecess.  
<br>In a nutshell this means that you can get development started fast, but with the caveat that the project scope statement is “flexible” and not fully defined. Hence this can be one of the major causes of scope creed if not managed properly.
<br>In a nutshell this means that you could quickly start a project, and project scope is flexible which means that you could properly manage the project scope during the developing process.


====Disadvantage of agile methodology====
====Disadvantage of agile methodology====
* In case of some software deliverables, especially the large ones, it is difficult to access the effort required at the beginning of the software development life cycle.  
* In case of some software deliverables, especially the large ones, it is difficult to access the effort required at the beginning of the software development life cycle.  
* There is lack of emphasis on necessary designing and documentation.  
* There is lack of emphasis on necessary designing and documentation. Actually, designing and documentation are important things for software development, they help to different developers to adhere to one "principle policy".
* The project can easily get taken off track if the customer representative is not clear what final outcome that they want.  
*Sometimes when we are asked to develop a software, even the clients themselves don't know what kind of final outcome they want. In such scenario , the project can easily go into a total dilemma.  
* Only senior programmers are capable of taking the kind of decisions required during the development processes. Hence it has no place for newbie programmers, unless combined with experienced recourses.
*The project can easily get taken off track if the customer representative is not clear what final outcome that they want.  
* Such development methodologies have also been criticized for their lack of strong planning and problems with applying them to the creation of larger software systems, especially in comparison to older, heavier weight methods like the spiral model.
*Only those senior programmers have the ability and power to make some decisions required during the develop process. Thus for those newbie programmer, they have no chances and how they have the opportunity to be an experienced senior programmer?
*For developing large scale software systems, such development methodologies are under critical criticize for their lack of strong planning.


===Heavier-weight Methodology VS Agile Methodology===
===Heavier-weight Methodology VS Agile Methodology===
Line 56: Line 57:
! Agile Methodology
! Agile Methodology
! Heavier-weight Methodology
! Heavier-weight Methodology
|-
|
| Customers
| Committed,knowledgeable,collocated,collaborative,representative,empowered
| Access to knowledgeable,collaborative,representative,empowered customers
|-
|-
| Requirements
| Requirements
| Mainly emergent,rapid change.
| has many changes
| Knowable early, largely stable.
| Knowable early, stable
|-
|-
| Architecture
| Architecture
| Designed for current requirements
| Designed for current requirements
| Designed for current and foreseeable requirements
| Designed for current and predicated requirements
|-
|-
| Size
| Size
Line 89: Line 87:
|}
|}


====The Issue of Heavier-weight Methodology and Agile Methodology====
====The Issue of Heavier-weight Methodology and Agile Methodology<ref name = "agile4">http://www.ijcsi.org/papers/IJCSI-8-4-1-441-450.pdf</ref>====
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
Line 97: Line 95:
|-
|-
| Development life cycle
| Development life cycle
| Linear or incremental
| adaptive and incremental
| Incremental
| Incremental
|-
|-
Line 105: Line 103:
|-
|-
| Requirements
| Requirements
| Emergent–Discovered during the project.
| Many changes discovered during the project.
| Clearly defined and documented
| Clearly defined and documented before the project started
|-
|-
| Documentation
| Documentation
| Light(replaced by face to face communication)
| Light(depend on face-to-face communication)
| Heavy/detailed Explicit knowledge
| detailed documentation based on requirements
|-
|-
| Team members
| Team members
| Co-location of generalist senior technical staff
| senior technical staff
| Distributed teams of specialists
| Distributed teams of specialists
|-
|-
| Client Involvement
| Client Involvement
| Onsite and considered as a team member Active/proactive
| considered as a team member Active/proactive for communication
| Low involvement
| Low involvement
|-
|-
Line 125: Line 123:
|-
|-
| Measure of success
| Measure of success
| Business value delivered
| final outcome exactly what the client required
| Conformance to plan
| Conformance to plan


Line 136: Line 134:
====Rational Unified Process====
====Rational Unified Process====
=====Indroduction of RUP=====
=====Indroduction of RUP=====
The [http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process Rational Unified Process (RUP)], originated by Rational Software and later by IBM, is a heavy iterative approach that takes into account the need to accommodate change and adaptability during the development process. In RUP: a software product is designed and built in a succession of incremental iterations. Each iteration includes some, or most, of the development disciplines like requirements, analysis, design, and implementation and testing. It provides a disciplined approach to assign tasks and responsibilities with a software development organization for the successful development of software.
The [http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process Rational Unified Process (RUP)]<ref>http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process</ref>,which comes from Rational Software and later by IBM, is a kind of heavy methodology which can be use to accomodate the change and adaptability during the development process. These are some features of RUP: it use the incremental iterations to build the software. The development disciplines like requirements, analysis, design, and implementation and testing can be parts of the interation. It help successful developing of the software by assign the tasks and responsibilities for the developing teams.


=====The Main Goal of RUP=====
=====The Main Goal of RUP=====
The main goal of RUP is to ensure the production of high-quality software by meeting the needs of its end-users within a predictable schedule and budget. The Rational Unifies Model provides guidelines. templates and tool mentors to software engineering team to take full advantage of among others. Following are the guidelines for best pratices:
RUP can product the high-quality software for its end-users in a predicatable shcedule and budget. RUP needs some guildlines for best pratices<ref name = "agile4" />:
* Develop software iteratively
* Develop software iteratively
* Manage requirements
* Manage requirements
Line 148: Line 146:


=====The Phases of RUP=====
=====The Phases of RUP=====
[[File:Phase.jpg|240px|right|The Phases of RUP]]
[[File:Phase.jpg|280px|right|The Phases of RUP]]
RUP has a series of phases as follows:
RUP has a series of phases as follows:<ref name = "agile4" />
* '''Inception: (Understand what to build)''' In this phase project’s scope, estimated costs, risks, business case, environment and architecture are identified.
* '''Inception: ''' In this phase, we should caculate some risks we may face in the future and the costs, eviroment, eviroment ect.
* '''Elaboration: (Understand how to build it)''' In this phase requirements are specified in detail, architecture is validated, the project environment is further defined and the project team is configured.
* '''Elaboration:''' This phase require us know what needs us to build, and we also should know the detail, make sure the architecture will work in future.
* '''Construction: (Build the Product)''' In this phase software is built and tested and supporting documentation is produced.
* '''Construction:''' In this phase we should build the product according to the documentation required and build the supporting documentation.
* '''Transition: (Transition the Product to its Users)''' In this phase software is system tested, user tested, reworked and deployed.
* '''Transition: ''' In this phase the product will release to the user for user tested, we should correct the bug in this phase for future deploying.  
<br>'''Notes:'''The picture cites from <ref name = "agile4" />
<br style="clear:both;">
<br style="clear:both;">


=====Usage of RUP Model=====
=====Usage of RUP Model=====
Below is some usage of RUP Model:<ref name = "agile4" />
* Distributed systems
* Distributed systems
* Very large or complex systems
* Very large or complex systems
Line 165: Line 165:
====Spiral Model====
====Spiral Model====
=====Indroduction of Spiral Model=====
=====Indroduction of Spiral Model=====
[http://en.wikipedia.org/wiki/Spiral_model Spiral Model] is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.This model is also known as Boehm's model, using his model, process is represented as a spiral rather than as a sequence of activities with backtracking.
[http://en.wikipedia.org/wiki/Spiral_model Spiral Model]<ref>http://en.wikipedia.org/wiki/Spiral_model</ref> is also known as Boehm's model, by use the advantages of the top-down and bottom-up concepts we can represent the process like a spiral, which quite different with sequence we use in the waterfall model.


=====Processes in Spiral Model=====
=====Processes in Spiral Model=====
[[File:Spiral model.jpg|280px|right|Spiral model]]
[[File:Spiral model.jpg|280px|right|Spiral model]]
There are four processes in spiral model:  
*'''Objective setting:''' Specific objectives for the project phase are identified.
There are four processes in spiral model: <ref name = "agile4" />
*'''Risk assessment and reduction:''' Key risks are identified, analyzed and information is obtained to reduce these risks. The aim is that all risks are resolved.
*'''Objective setting:''' We should know what to build and what the goal of project in this process.
*'''Development and Validation:''' Once all possible risks have been identified the development of the software can begin, an appropriate model is chosen for the next phase of development.
*'''Risk assessment and reduction:''' We should calculate the key risks we may face in the future work and try our best to reduce the risks.
*'''Planning:''' The project is reviewed.
*'''Development and Validation:''' After we resolve all risks of the project, we should choose an appropriate model for our future development.
*'''Planning:''' In this phase, we should review the current round of our project and make planning for the spiral next round.
<br style="clear:both;">
<br style="clear:both;">
<br>'''Note:''' The picture cites from <ref>http://en.wikipedia.org/wiki/File:Spiral_model_(Boehm,_1988).png</ref>


=====Usage of Spiral Model=====
=====Usage of Spiral Model=====
Following are the usage of Spiral model:
Spiral model may be a better choose for usage in the situations below: <ref name = "agile4" />
* Large and high budget projects.
*In a large projects that with high budget.  
* When risk assessment is very critical.
*The risk assessment plays an important role in the whole project.
* Requirements are not very clearly defined and
* Requirements are not very clearly defined and complex.
complex.
*The requirements need to change all the procedure.
* When costs and risk evaluation is important
*For projects with high risk.
* For medium to high-risk projects.
* Long-term project commitment unwise because of potential changes to economic priorities.


===Agile methodology===
===Agile methodology===
====Extreme Programming(XP)====
====Extreme Programming(XP)====
=====Indroduction of Extreme Programming(XP)=====
=====Indroduction of Extreme Programming(XP)=====
[http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming(XP)] is a lightweight design method developed by Kent Beck, Ward Cunningham, and others, XP has evolved from the problems caused by the long development cycles of traditional development models. The XP process can be characterized by short development cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design. With all the above qualities, XP programmers respond to changing environment with much more courage.
One of the important agile methodology example is [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming(XP)]. It was created by Kent Beck in his C3 project. The goal for Extreme Programming(XP) is to provide high quality software to the user. It consists the following terms to make sure the software productive by this model. Such like The Planning Process, Small Releases, Metaphor etc. With these terms and practices, the programmer can make change to the environment quickly.


=====XP Terms and Practices=====
=====XP Terms and Practices=====
[[File:Life xp.jpg|400px|right|Life cycle of ]]
[[File:Life xp.jpg|400px|right|Life cycle of ]]
A summary of XP terms and practices is listed below:
A summary of XP terms and practices is listed below:<ref name = "agile5"> http://www.webopedia.com/TERM/E/Extreme_Programming.html </ref>
*'''The Planning Process:'''The desired features of the software, which are communicated by the customer, are combined with cost estimates provided by the programmers to determine what the most important factors of the software are. This stage is sometimes called the Planning Game.
*'''The Planning Process:''' Sometimes we also call this stage as Planning Game. In this stage, the programmer will communicate with the customer and the programmer will determine which the key factor for the project is.
*'''Small Releases:'''The software is developed in small stages that are updated frequently, typically every two weeks.
*'''Small Releases:''' Divide the software into small stages that updated very often mostly like every two weeks.
*'''Metaphor:'''All members on an XP team use common names and descriptions to guide development and communicate on common terms.
*'''Metaphor:''' The guys who in the same XP team should use the common names and description and they will use the common terms in communicating in the development process.
*'''Simple Design:'''The software should include only the code that is necessary to achieve the desired results communicated by the customer at each stage in the process. The emphasis is not on building for future versions of the product.
*'''Simple Design:'''In this stage the software just includes the essential part of the component to fulfill the customer needed. We do not emphasis on building for future versions of the product in this phase.
*'''Testing:'''Testing is done consistently throughout the process. Programmers design the tests first and then write the software to fulfill the requirements of the test. The customer also provides acceptance tests at each stage to ensure the desired results are achieved.
*'''Testing:'''In this stage the programmer should design some test case that can be fulfill the requirement of the customer. And the customer also need to use the acceptance tests to make sure that they get the results they intent to.
*'''Refactoring:'''XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.
*'''Refactoring:'''The programmers improve the software all the time in the developing process instead of correct all the mistakes in the “last minutes”.
*'''Pair Programming:'''All code is written by a pair of programmers working at the same machine.
*'''Pair Programming:'''It needs a pair of the programmers to working in the same code.
*'''Collective Ownership:'''Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to slow the project down. Code is changed when it needs to be changed without delay.
*'''Collective Ownership:'''The code is belongs to all the programmers working on the project, so if everyone can change the code when it needs without delay.
*'''Continuous Integration:'''The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.
*'''Continuous Integration:'''The software system should be integrated multiple times a day to make sure that every programmer at the same stage of the development process.
*'''40-Hour Week:'''The XP team does not work excessive overtime to ensure that the team remains well-rested, alert and effective.
*'''40-Hour Week:'''XP team members work 40-hour a week to make sure that the team could work effectively.
*'''On-Site Customer:'''The XP project is directed by the customer who is available all the time to answer questions, set priorities and determine requirements of the project.
*'''On-Site Customer:'''The customer is available all the time to answer the problem to help the XP team to fulfill the requirement of the customer.
*'''Coding Standard:'''The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.
*'''Coding Standard:'''All the code should be wrote in the same way which will be convenience for the pair working programming to share their code.  
<br style="clear:both;">
<br style="clear:both;">
<br>'''Notes:'''The picture cites from <ref name = "agile4" />


====Crystal====
====Crystal====
=====Indroduction of Crystal=====
=====Indroduction of Crystal=====
[http://en.wikipedia.org/wiki/The_Crystal_Method Crystal Methodologies] is a family of methodologies((Crystal Clear, Crystal Yellow, Crystal Orange, etc.)developed by Alistair Cockburn. The word “Crystal” refers to the degree of hardness and the different colors of the methodology in much the same way that a crystal can have various degrees of hardness and variety of colors.  The degree of hardness pertains to the use of rigor and ceremony i.e. as the hardness increases the amount of required documentation, processes and procedures increases.
[http://alistair.cockburn.us/Crystal+methodologies Crystal Methodologies] is developed by Alistair Cockburn. The Crystal Methodologies means a family of methodologies, such as Crystal Yellow, Crystal Orange, Crystal Clear, etc. “Crystal” means that the degree of hardness and the different colors of the methodology. So crystal can have different degree of hardness and different colors.


=====Features and Restrictions of Crystal=====
=====Features and Restrictions of Crystal=====
[[File:Crystal1.jpg|280px|right|Crystal]]
[[File:Crystal1.jpg|280px|right|Crystal]]
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.
Some key features included in the Crystal, such as teamwork, simplicity, communication and can be adjust to the improving programming process. Crystal has a lot of same features with other agile methodologies, likes high adaptability, customer participating the developing procedure, delivery of current working software frequently, etc.
<br>Crystal methods are denoted by colors. The color of the methods as follows: Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue. Only three of the methods – Crystal Clear, Orange and Orange Web - have been constructed and actually used on projects.
 
<br>One of the restrictions of the Crystal methods is that they only address collocated teams.  Thus, the Crystal methods would not apply to distributed or offshore teams for which Cockburn offers no recommendation other than to locate the team together at one location.
<br>Crystal methods can be presented by colors. Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue are the methods. But we only use the Crystal Clear, Orange and Orange Web on projects since only the three method have been constructed.<ref name = "agile7"/>


=====Rules that are common to all the Crystal Methods=====
<br>One of the restrictions of the Crystal methods is that it is not suitable to work in multiple locations. Thus Cockburn suggest that the team use Crystal methods should work together at one location.
* The project must use incremental development with increments of four months or less with a string preference of one to three months
 
* The team must hold both pre- and post- reflection with a strong preference for mid-project reflection workshops
 
'''Notes:'''The picture cites from <ref name = "agile7">Crystal_Methodologies_summary.doc <br>
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAA&url=http%3A%2F%2Futopia.csis.pace.edu%2Fdps%2F2007%2Famannette-wright%2Fdps%2FDCS801_821%2FCrystal_Methodologies_summary.doc&ei=MAfLTpmnMc2gtweg8oi8DA&usg=AFQjCNHcVdz-ehhu7jtPFiihF99TH8O7iQ</ref>


==How to choose methodology?==
==How to choose methodology?==
What the best model is varies from project to project, but the creation of new models for software development that can strike a balance between extremes is an open question.
What the best model is varies from project to project, there is no fixed answer for which develop methodologies are good, which are bad. The essential points you’ll need to consider when selecting a methodology are<ref name = "agile2" /> <ref name = "agile6">http://rationalizedthoughts.blogspot.com/2006/03/choose-methodology-that-suits-your.html </ref>:
The essential points you’ll need to consider when selecting a methodology are:
* Budget, what's your estimated budget of the project.
* Budget
* Team size, how many developer will get involved in the develop process.
* Team size
* Technology used, what kind of technology will be used in the project.
* Project criticality
* Documentation, will you do a lot of detailed documentation?
* Technology used
* Team members, are your team members all senior developers or are there any newbie programmers?
* Documentation
* project size, is the project a large-scale project or not?
* Training
* Existing processes, is there any existing processes that could be modified to be applied to the project?
* Best practices/lesions learned
* time cost: what's the deliverable time for the project? How much time do you have to develop the project?
* Tools and techniques
* Software, what kind of software you will develop.
* Existing processes
* Software


==Some situations should avoid Agile Methodology==
==When to Avoid the Agile Methodology==
Some situations should avoid Agile Methodology if...
Some situations should avoid Agile Methodology if:
* You have to formally document the requirements, design, code, and testing cases during each phase of the software life cycle.
*The requirements, design, code and testing case need to be formally documented during each phase of the software life cycle.  
This is usually the case when building an infrastructure application, rather than an application that supports a changeable business process. Infrastructure applications support an entire business unit over a long ROI period, with repeated updates and enhancements expected.
From above discuss, we know that for those application with changeable process doesn't need to get detailed documentation during each phase during software life cycle, they rely mostly on face-to-face communication. However, when developing those infrastructure applications <ref name = "agile5"> http://it.toolbox.com/wiki/index.php/Know_when_to_not_use_agile_methodology </ref>, detailed documentation at each phase is important. These applications need to go step by step, and the documentation at each phase inherit from its predecessors.  
These applications are likely to be managed by successive generations of application owners, who will need to inherit documentation from their predecessors, maintain it, and pass it on their successors.
* Every step could be started only when its previous have been successfully finished and approved until deliverable.
* Deliverables must pass through a chain of approvals and tollgates
It means we need to set milestone for each phase, and only when the step has successfully finished and meet the mile store, we could go on to the following. They may slow the project and could ensure that every milestone has been successfully achieved. Thus for those applications requiring phase-end reviews <ref name = "agile5" />may not suitable for agile-method.
Approvals and tollgates are mini-bottlenecks that can slow the momentum of a project, momentum that agile methods are supposed to support. Applications that require phase-end reviews or reviews of major deliverables by senior management, by a PMO, or even an Audit Committee may or may not be candidates for agile methods.
* Your team members has many newbie programmers
Of course, the flip side to this is that agile methods can also help recover momentum lost to approvals and tollgates.
For those applications using agile methodologies, important decisions could only be made by those senior developers. So, if your develop team consists of many newbie programmers, they may make a lot of wrong decisions for lacking of experiences. This may great increase the cost of time on the project and could lead to the bad communication between developer and customer.  
* You have tools to create the software models but not to translate them to the low end software code.
* customer could not involve during the develop process
Model-driven development tools that can generate code are proliferating, but the skills necessary to use them effectively are still relatively scarce. Unless you have both the tools AND the skills available, agile methods that depend on such tools need to be approached with caution.
We know that agile methodologies require the customer act as part of the project team, it greatly rely on face-to-face communication. If the customer could not do like this, we may avoid using agile methodologies or we may have higher risks for getting unexpected results.
* You need to follow traditional Software management processes and Procedures.
"Traditional" usually means "comfortable". If the business sponsor and users are uncomfortable with anything but traditional ways of developing software, and remain unmoved by the value proposition for agile methods, don't bother.
* Application users are NOT always accessible to you.
Agile management depends on an effective, day-to-day working partnership between the development team, the sponsor, and empowered users. If this partnership does not exist, or is likely to be weak, an agile project will face much higher risks than it should.


==Conclusion==
==Conclusion==
Agile methods demand that the customer is involved throughout; the customer is part of the team. It makes sense for the customer to want to be deeply involved in the product you are making them, however, there are a myriad of real world reasons why it might not be possible. With any process you deploy to solve a problem customer buy in is critical… The customer must understand what is required of them and be committed to deliver on that requirement. This cannot be forced and any attempts to make a customer buy into agile will result in difficulty. Sometimes, upfront analysis might just have to do...
Agile methodologies demand that the client is involved as part of the team during the software develop process. This is of course great if the client want to get involved, however it is not the case in real world. A software, especially those large scale software, need a long development life cycle, not all the clients have that much time to take part in the development process. Agile methodologies allow change, and there are sufficient communication between customers and developers such that the developers are delivering software that is definitely what the customer required, and it could essentially reduce the time for developing those functionality not being used.  
<br>It is possible to run an agile project on a fixed priced or time and materials basis. However, in both cases for the project to be agile the scope must be flexible. If the project is fixed scope, there is no benefit from using agile methods. If it’s fixed scope then more than likely the requirements will form part of the contract and thus be well defined (through upfront analysis). The point of agile is to allow change such that the developers are delivering software that will be used by the customer, essentially reduce the scary waste of 45% of functionality not being used!
 
<br>Heavyweight methodologies sometimes could be a better choice. Consider a scenario that you have multiple teams working at different locations, you may want to have a "principle guidelines" that make all the developer adhere to it thus avoiding going to the wrong way.Also, heavyweight methodologies requires detailed documentation at every stage, it helps better understand the requirements of the project.  
 
<br>How to correctly select a methodologies to develop software is to a great degree dependant on having a clear understanding of the particular develop groups and types of development models. This is of great importance and make the develop team choose a methodologies that meet the needs of the customer requirements and their capacity.


==References==
==References==
*[1]: http://www.developer.com/design/article.php/3784576/Why-Agile-Projects-Fail.htm
<references>
*[2]: http://agilemethodology.org/
</references>
*[3]: http://www.versionone.com/Agile101/Methodologies.asp
*[4]: http://www.the-software-experts.de/e_dta-sw-process.htm
*[5]: http://www.agile-methodology.com/
*[6]: http://rationalizedthoughts.blogspot.com/2006/03/choose-methodology-that-suits-your.html
*[7]: http://www.ijcsi.org/papers/IJCSI-8-4-1-441-450.pdf
*[8]: http://www.techrepublic.com/article/heavyweight-vs-lightweight-methodologies-key-strategies-for-development/5035285
*[9]: http://practicalanalyst.com/2009/03/16/agile-and-traditional-methodologies-compared-again/
*[10]: http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
*[11]: http://en.wikipedia.org/wiki/Spiral_model
*[12]: http://en.wikipedia.org/wiki/Extreme_programming
*[13]: http://en.wikipedia.org/wiki/The_Crystal_Method
*[14]: http://en.wikipedia.org/wiki/Lightweight_methodology
*[15]: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Latest revision as of 03:48, 22 November 2011

Introduction

The concept of heavier-weight methodology

Traditional methodology which is also known as Heavyweight development methodology that 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, its typical example is waterfall model.

The concept of agile methodology

Agile methodology(Lightweight Methodology) is an iterative and incremental approach to project management, typically used in software development. It helps teams respond to the changes of building software quickly and efficiently . <ref name = "agile1">http://acm.web.auth.gr/2011/03/03/agile-methodology/</ref>

Overview of this article

In section 2 we introduce the comparison between heavier-weight methodologies and agile methodologies, we provide both advantages and disadvantages for both heavier-weight methodologies and agile methodologies. In sections 3, we provide the examples for both heavier-weight and agile methodologies. In sections 4, we discuss how to choose methodologies when developing software. Sections 5 tells under which situation you could avoid using agile methodologies.

Compare with the heavier-weight methodology and agile methodology

Heavier-weight methodology

Heavyweight methodology<ref name = "agile2">http://www.techrepublic.com/article/heavyweight-vs-lightweight-methodologies-key-strategies-for-development/5035285</ref>:

  • A heavyweight methodology which is composited with rules, practices, and documents makes us discipline and time to follow correctly.
  • Heavyweight methodologies focus in the great detail of the project.
  • The specifications, reports, plans, schedules and checkpoints is required by the lead managers.
  • For the reason that the heavyweight methodology plans about the requirements, design, etc. before the project is actually started, so the project managers who use heavyweight methodologies will resist change.
  • Requirements, solution build, testing and deployment are always the basic steps for the heavyweight development methodology.
  • Rational Unified Process is one of the widely used example of “heavyweight” methodology.
  • If the project needs multiple teams working at several locations, and you need them to work tighter to develop some core parts of the project, in such condition heavyweight methodologies can be a better choice, because they could adhere to the requirements, design documentation, which will avoid that they work in wrong direction because of inconvenience communication.

Advantage of heavier-weight methodology

  • It is a clear and powerful method for software development, many big corporations use this method to develop software. It clearly defines software development life cycle, which help a new developer better know how to develop the software.
  • Because we have clear stated what to do before the project actually start, this will save us time to do only those that we actually required. It always happen that a project team do a lot of effort to code and then later found out that it's not required at all. So using this method and adhering closely to documentation, It will avoid of those useless effort.
  • The project stakeholders are forced to clearly and correctly define the business requirements documentations. Also, developers are forced to completely understand the requirements before starting doing the high level design and coding. Without thoroughly understand the requirements, they will fail to meed the corresponding milestone and fail to continue the project.
  • Actually, making documentation at every state is an very essential step. It helps better understand the requirements, design the code , write code and design test on the software.

Disadvantage of heavier-weight methodology

The traditional project methodologies that many top corporations use, such as the SDLC approach, are considered to be bureaucratic or “predictive” in nature, and they’ve resulted in many unsuccessful projects. These “heavyweight” methodologies are becoming increasingly unpopular. They can be so laborious that the whole pace of design, development, and deployment actually slows down.<ref name = "agile2"/>
Heavyweight methodologies try to plan majority part of the project in great detail.it assumes that every requirement of the project can be identified before any design or coding occurs Project managers need to predict predict every project milestones because they need those technical details, which result in a large number of documentation, such as plans, report, and schedules. However, we know, when doing a project, there are always a lot of changes, such as that the client may change their requirements, then all the schedules, checkpoints made for the project need to get changed. So making all the details for a project before actually starting the project is not an effective way.
Heavyweight development methodology is based on a sequential series of steps, such as requirements, solutions, testing and deployment, which means that every step could only be started with the finish of previous step, while the lightweight methodologies propose to execute the project steps in parallel.

Agile methodology

"In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” <ref>http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf</ref>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."<ref name = "agile3">http://agilemethodology.org/</ref>

Advantage of agile methodology

  • The most important characteristics of Agile methodology is that it is adaptive, making the team is able to respond to the change of requirements. We know that it is a quite common thing for requirements to get changed when developing a software.
  • The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed.
  • The close communication from customer and the designer makes all the requirements clear and if somethings changed, the develop team could quickly respond to the change, there is no guesswork here.
  • No complicated and burdensome documentation, which saves a lot of time when developing software.
  • The outcome is always the software that best satisfy the customer, as they closely communicate during the developing proecess.


In a nutshell this means that you could quickly start a project, and project scope is flexible which means that you could properly manage the project scope during the developing process.

Disadvantage of agile methodology

  • In case of some software deliverables, especially the large ones, it is difficult to access the effort required at the beginning of the software development life cycle.
  • There is lack of emphasis on necessary designing and documentation. Actually, designing and documentation are important things for software development, they help to different developers to adhere to one "principle policy".
  • Sometimes when we are asked to develop a software, even the clients themselves don't know what kind of final outcome they want. In such scenario , the project can easily go into a total dilemma.
  • The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
  • Only those senior programmers have the ability and power to make some decisions required during the develop process. Thus for those newbie programmer, they have no chances and how they have the opportunity to be an experienced senior programmer?
  • For developing large scale software systems, such development methodologies are under critical criticize for their lack of strong planning.

Heavier-weight Methodology VS Agile Methodology

The Difference Between Heavier-weight Methodology and Agile Methodology

Differences Agile Methodology Heavier-weight Methodology
Requirements has many changes Knowable early, stable
Architecture Designed for current requirements Designed for current and predicated requirements
Size Smaller Team and Products Larger Team and Products
Primary objective Rapid value High assurance
Developers Knowledgeable,collocated,collaborative Plan-driven,adequate skills,access to external knowledge.
Release cycle In phases (multiple cycles) Big bang (all functionality at once)

The Issue of Heavier-weight Methodology and Agile Methodology<ref name = "agile4">http://www.ijcsi.org/papers/IJCSI-8-4-1-441-450.pdf</ref>

Issue Agile Methodology Heavier-weight Methodology
Development life cycle adaptive and incremental Incremental
Style of development Adaptive Anticipatory
Requirements Many changes discovered during the project. Clearly defined and documented before the project started
Documentation Light(depend on face-to-face communication) detailed documentation based on requirements
Team members senior technical staff Distributed teams of specialists
Client Involvement considered as a team member Active/proactive for communication Low involvement
Market Dynamic/Early market Mature/Main Street market
Measure of success final outcome exactly what the client required Conformance to plan

Example

Heavier-weight methodology

Rational Unified Process

Indroduction of RUP

The Rational Unified Process (RUP)<ref>http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process</ref>,which comes from Rational Software and later by IBM, is a kind of heavy methodology which can be use to accomodate the change and adaptability during the development process. These are some features of RUP: it use the incremental iterations to build the software. The development disciplines like requirements, analysis, design, and implementation and testing can be parts of the interation. It help successful developing of the software by assign the tasks and responsibilities for the developing teams.

The Main Goal of RUP

RUP can product the high-quality software for its end-users in a predicatable shcedule and budget. RUP needs some guildlines for best pratices<ref name = "agile4" />:

  • Develop software iteratively
  • Manage requirements
  • Use component-based architectures
  • Visual model software
  • Verify software quality
  • Control changes to software
The Phases of RUP
The Phases of RUP
The Phases of RUP

RUP has a series of phases as follows:<ref name = "agile4" />

  • Inception: In this phase, we should caculate some risks we may face in the future and the costs, eviroment, eviroment ect.
  • Elaboration: This phase require us know what needs us to build, and we also should know the detail, make sure the architecture will work in future.
  • Construction: In this phase we should build the product according to the documentation required and build the supporting documentation.
  • Transition: In this phase the product will release to the user for user tested, we should correct the bug in this phase for future deploying.


Notes:The picture cites from <ref name = "agile4" />

Usage of RUP Model

Below is some usage of RUP Model:<ref name = "agile4" />

  • Distributed systems
  • Very large or complex systems
  • Systems combining several business areas
  • Systems reusing other systems
  • Distributed development of a system

Spiral Model

Indroduction of Spiral Model

Spiral Model<ref>http://en.wikipedia.org/wiki/Spiral_model</ref> is also known as Boehm's model, by use the advantages of the top-down and bottom-up concepts we can represent the process like a spiral, which quite different with sequence we use in the waterfall model.

Processes in Spiral Model
Spiral model
Spiral model

There are four processes in spiral model: <ref name = "agile4" />

  • Objective setting: We should know what to build and what the goal of project in this process.
  • Risk assessment and reduction: We should calculate the key risks we may face in the future work and try our best to reduce the risks.
  • Development and Validation: After we resolve all risks of the project, we should choose an appropriate model for our future development.
  • Planning: In this phase, we should review the current round of our project and make planning for the spiral next round.



Note: The picture cites from <ref>http://en.wikipedia.org/wiki/File:Spiral_model_(Boehm,_1988).png</ref>

Usage of Spiral Model

Spiral model may be a better choose for usage in the situations below: <ref name = "agile4" />

  • In a large projects that with high budget.
  • The risk assessment plays an important role in the whole project.
  • Requirements are not very clearly defined and complex.
  • The requirements need to change all the procedure.
  • For projects with high risk.

Agile methodology

Extreme Programming(XP)

Indroduction of Extreme Programming(XP)

One of the important agile methodology example is Extreme Programming(XP). It was created by Kent Beck in his C3 project. The goal for Extreme Programming(XP) is to provide high quality software to the user. It consists the following terms to make sure the software productive by this model. Such like The Planning Process, Small Releases, Metaphor etc. With these terms and practices, the programmer can make change to the environment quickly.

XP Terms and Practices
Life cycle of
Life cycle of

A summary of XP terms and practices is listed below:<ref name = "agile5"> http://www.webopedia.com/TERM/E/Extreme_Programming.html </ref>

  • The Planning Process: Sometimes we also call this stage as Planning Game. In this stage, the programmer will communicate with the customer and the programmer will determine which the key factor for the project is.
  • Small Releases: Divide the software into small stages that updated very often mostly like every two weeks.
  • Metaphor: The guys who in the same XP team should use the common names and description and they will use the common terms in communicating in the development process.
  • Simple Design:In this stage the software just includes the essential part of the component to fulfill the customer needed. We do not emphasis on building for future versions of the product in this phase.
  • Testing:In this stage the programmer should design some test case that can be fulfill the requirement of the customer. And the customer also need to use the acceptance tests to make sure that they get the results they intent to.
  • Refactoring:The programmers improve the software all the time in the developing process instead of correct all the mistakes in the “last minutes”.
  • Pair Programming:It needs a pair of the programmers to working in the same code.
  • Collective Ownership:The code is belongs to all the programmers working on the project, so if everyone can change the code when it needs without delay.
  • Continuous Integration:The software system should be integrated multiple times a day to make sure that every programmer at the same stage of the development process.
  • 40-Hour Week:XP team members work 40-hour a week to make sure that the team could work effectively.
  • On-Site Customer:The customer is available all the time to answer the problem to help the XP team to fulfill the requirement of the customer.
  • Coding Standard:All the code should be wrote in the same way which will be convenience for the pair working programming to share their code.



Notes:The picture cites from <ref name = "agile4" />

Crystal

Indroduction of Crystal

Crystal Methodologies is developed by Alistair Cockburn. The Crystal Methodologies means a family of methodologies, such as Crystal Yellow, Crystal Orange, Crystal Clear, etc. “Crystal” means that the degree of hardness and the different colors of the methodology. So crystal can have different degree of hardness and different colors.

Features and Restrictions of Crystal
Crystal
Crystal

Some key features included in the Crystal, such as teamwork, simplicity, communication and can be adjust to the improving programming process. Crystal has a lot of same features with other agile methodologies, likes high adaptability, customer participating the developing procedure, delivery of current working software frequently, etc.


Crystal methods can be presented by colors. Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue are the methods. But we only use the Crystal Clear, Orange and Orange Web on projects since only the three method have been constructed.<ref name = "agile7"/>


One of the restrictions of the Crystal methods is that it is not suitable to work in multiple locations. Thus Cockburn suggest that the team use Crystal methods should work together at one location.


Notes:The picture cites from <ref name = "agile7">Crystal_Methodologies_summary.doc
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAA&url=http%3A%2F%2Futopia.csis.pace.edu%2Fdps%2F2007%2Famannette-wright%2Fdps%2FDCS801_821%2FCrystal_Methodologies_summary.doc&ei=MAfLTpmnMc2gtweg8oi8DA&usg=AFQjCNHcVdz-ehhu7jtPFiihF99TH8O7iQ</ref>

How to choose methodology?

What the best model is varies from project to project, there is no fixed answer for which develop methodologies are good, which are bad. The essential points you’ll need to consider when selecting a methodology are<ref name = "agile2" /> <ref name = "agile6">http://rationalizedthoughts.blogspot.com/2006/03/choose-methodology-that-suits-your.html </ref>:

  • Budget, what's your estimated budget of the project.
  • Team size, how many developer will get involved in the develop process.
  • Technology used, what kind of technology will be used in the project.
  • Documentation, will you do a lot of detailed documentation?
  • Team members, are your team members all senior developers or are there any newbie programmers?
  • project size, is the project a large-scale project or not?
  • Existing processes, is there any existing processes that could be modified to be applied to the project?
  • time cost: what's the deliverable time for the project? How much time do you have to develop the project?
  • Software, what kind of software you will develop.

When to Avoid the Agile Methodology

Some situations should avoid Agile Methodology if:

  • The requirements, design, code and testing case need to be formally documented during each phase of the software life cycle.

From above discuss, we know that for those application with changeable process doesn't need to get detailed documentation during each phase during software life cycle, they rely mostly on face-to-face communication. However, when developing those infrastructure applications <ref name = "agile5"> http://it.toolbox.com/wiki/index.php/Know_when_to_not_use_agile_methodology </ref>, detailed documentation at each phase is important. These applications need to go step by step, and the documentation at each phase inherit from its predecessors.

  • Every step could be started only when its previous have been successfully finished and approved until deliverable.

It means we need to set milestone for each phase, and only when the step has successfully finished and meet the mile store, we could go on to the following. They may slow the project and could ensure that every milestone has been successfully achieved. Thus for those applications requiring phase-end reviews <ref name = "agile5" />may not suitable for agile-method.

  • Your team members has many newbie programmers

For those applications using agile methodologies, important decisions could only be made by those senior developers. So, if your develop team consists of many newbie programmers, they may make a lot of wrong decisions for lacking of experiences. This may great increase the cost of time on the project and could lead to the bad communication between developer and customer.

  • customer could not involve during the develop process

We know that agile methodologies require the customer act as part of the project team, it greatly rely on face-to-face communication. If the customer could not do like this, we may avoid using agile methodologies or we may have higher risks for getting unexpected results.

Conclusion

Agile methodologies demand that the client is involved as part of the team during the software develop process. This is of course great if the client want to get involved, however it is not the case in real world. A software, especially those large scale software, need a long development life cycle, not all the clients have that much time to take part in the development process. Agile methodologies allow change, and there are sufficient communication between customers and developers such that the developers are delivering software that is definitely what the customer required, and it could essentially reduce the time for developing those functionality not being used.


Heavyweight methodologies sometimes could be a better choice. Consider a scenario that you have multiple teams working at different locations, you may want to have a "principle guidelines" that make all the developer adhere to it thus avoiding going to the wrong way.Also, heavyweight methodologies requires detailed documentation at every stage, it helps better understand the requirements of the project.


How to correctly select a methodologies to develop software is to a great degree dependant on having a clear understanding of the particular develop groups and types of development models. This is of great importance and make the develop team choose a methodologies that meet the needs of the customer requirements and their capacity.

References

<references> </references>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch6_6e_zj&oldid=56158"