<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Lee</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Lee"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Lee"/>
	<updated>2026-05-22T23:33:00Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29854</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29854"/>
		<updated>2009-11-22T22:32:03Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Dynamic Systems Development Method (DSDM) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
Since this is not really a stand alone method in and of itself, it will not be discussed in great detail.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
A simplified agile version of Rational Unified Process (RUP).  &lt;br /&gt;
&lt;br /&gt;
Composed of four phases:&lt;br /&gt;
&lt;br /&gt;
* Inception - identify the scope of the project, a potential architecture, and get the initial resources and acceptance.&lt;br /&gt;
* Elaboration - Prove the architecture. &lt;br /&gt;
* Construction.  Create functional software on an incremental time frame which completes the highest priority features as designated by the stakeholders.  &lt;br /&gt;
* Transition - Deploy the new system to production and validate its effectiveness.&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
Also some of them introduce a daily status meeting while others do not.  Overall it is somewhat difficult to spot too many differences between the methods.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.ambysoft.com/unifiedprocess/agileUP.html The Agile Unified Process]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29853</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29853"/>
		<updated>2009-11-22T22:31:52Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Major Differences */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
Since this is not really a stand alone method in and of itself, it will not be discussed in great detail.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
A simplified agile version of Rational Unified Process (RUP).  &lt;br /&gt;
&lt;br /&gt;
Composed of four phases:&lt;br /&gt;
&lt;br /&gt;
* Inception - identify the scope of the project, a potential architecture, and get the initial resources and acceptance.&lt;br /&gt;
* Elaboration - Prove the architecture. &lt;br /&gt;
* Construction.  Create functional software on an incremental time frame which completes the highest priority features as designated by the stakeholders.  &lt;br /&gt;
* Transition - Deploy the new system to production and validate its effectiveness.&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
Also some of them introduce a daily status meeting while others do not.  Overall it is somewhat difficult to spot too many differences between the methods.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.ambysoft.com/unifiedprocess/agileUP.html The Agile Unified Process]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29852</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29852"/>
		<updated>2009-11-22T22:30:43Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Agile Modeling (AM) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
Since this is not really a stand alone method in and of itself, it will not be discussed in great detail.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
A simplified agile version of Rational Unified Process (RUP).  &lt;br /&gt;
&lt;br /&gt;
Composed of four phases:&lt;br /&gt;
&lt;br /&gt;
* Inception - identify the scope of the project, a potential architecture, and get the initial resources and acceptance.&lt;br /&gt;
* Elaboration - Prove the architecture. &lt;br /&gt;
* Construction.  Create functional software on an incremental time frame which completes the highest priority features as designated by the stakeholders.  &lt;br /&gt;
* Transition - Deploy the new system to production and validate its effectiveness.&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.ambysoft.com/unifiedprocess/agileUP.html The Agile Unified Process]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29851</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29851"/>
		<updated>2009-11-22T22:30:19Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Agile Unified Process (AUP) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
A simplified agile version of Rational Unified Process (RUP).  &lt;br /&gt;
&lt;br /&gt;
Composed of four phases:&lt;br /&gt;
&lt;br /&gt;
* Inception - identify the scope of the project, a potential architecture, and get the initial resources and acceptance.&lt;br /&gt;
* Elaboration - Prove the architecture. &lt;br /&gt;
* Construction.  Create functional software on an incremental time frame which completes the highest priority features as designated by the stakeholders.  &lt;br /&gt;
* Transition - Deploy the new system to production and validate its effectiveness.&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.ambysoft.com/unifiedprocess/agileUP.html The Agile Unified Process]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29850</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29850"/>
		<updated>2009-11-22T22:26:25Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.ambysoft.com/unifiedprocess/agileUP.html The Agile Unified Process]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29849</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29849"/>
		<updated>2009-11-22T22:24:59Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Major Differences */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29848</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29848"/>
		<updated>2009-11-22T22:24:48Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;br /&gt;
* [http://www.agilemodeling.com/practices.htm Agile Modeling Practices]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29847</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29847"/>
		<updated>2009-11-22T22:24:32Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Agile Modeling (AM) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
&lt;br /&gt;
A supplement to other Agile methodologies, it is a collection of values and principles for modeling software specifically designed to be used in agile software development, typically replacing UML.&lt;br /&gt;
&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29846</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29846"/>
		<updated>2009-11-22T22:16:12Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
* Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
* Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
* Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29845</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29845"/>
		<updated>2009-11-22T22:15:25Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Definitions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
* Agile development - A group of software development methodologies that focus on rapid iterative development allowing for development to more quickly respond to changing requirements.  &lt;br /&gt;
* Chicken/Pig philosophy - In software development there are two kinda of roles, chickens and pigs.  Chickens are involved in the project and contribute to it, but pigs require a total sacrifice.  &lt;br /&gt;
* CRC (Class-Responsibility-Collaboration) Cards - A software design methodology where Objects and their interactions are written onto small index cards.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29844</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29844"/>
		<updated>2009-11-22T22:11:36Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Lean Software Development (LSD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
&lt;br /&gt;
This methodology consists of the following principles:&lt;br /&gt;
&lt;br /&gt;
* Eliminate Waste - eliminate everything that is not adding value for the customer&lt;br /&gt;
* Amplify learning - Techniques to increase learning and improve the software&lt;br /&gt;
** Write tests as soon as code (to be tested) is written. &lt;br /&gt;
** Instead of detailed planning, code different techniques and try them out&lt;br /&gt;
* Decide as Last as possible - Decision should be delayed as long as possible&lt;br /&gt;
* Deliver as fast as possible - The shorter the iteration the quicker the delivery to the customer and the more feedback the developer receives.  &lt;br /&gt;
* Empower the team - The managers should be listening to the developers for decision.  If developers are consulted, they feel empowered. &lt;br /&gt;
* Build Integrity In - Refactor often.  This improves the code base and long term maintainability.  Keep the feature set at a minimum.  &lt;br /&gt;
* See The Whole - While tasks are small and compartmentalized, the project needs to be thought of as a whole with all the pieces interacting.&lt;br /&gt;
&lt;br /&gt;
This method also features a morning standing meeting.&lt;br /&gt;
&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29843</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29843"/>
		<updated>2009-11-22T21:51:14Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
* [http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf Aigle Methods]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming]&lt;br /&gt;
* [http://martinfowler.com/articles/newMethodology.html#Crystal The New Methodology]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Methodology] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Adaptive_Software_Development Adaptive Software Development]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29842</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29842"/>
		<updated>2009-11-22T21:49:38Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Adaptive Software Development (ASD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
&lt;br /&gt;
Adaptive Software Development places a strong emphasis on dynamic programming languages.  It features a three phased cycle of:&lt;br /&gt;
&lt;br /&gt;
* Speculate - Instead of 'planning', the term speculate is used due to the nature that planning cannot account of all things and many things may be incorrect. &lt;br /&gt;
* Collaborate - Balancing the certain parts of planning with those that are uncertain.  &lt;br /&gt;
* Learn - The design/build/test cycle.&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29841</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29841"/>
		<updated>2009-11-22T21:27:03Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Crystal */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
* Safety (in project outcome)&lt;br /&gt;
* Efficiency&lt;br /&gt;
* Habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29840</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29840"/>
		<updated>2009-11-22T21:21:39Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
* User story cards&lt;br /&gt;
* Task List&lt;br /&gt;
* CRC Cards&lt;br /&gt;
* Customer Acceptance Tests&lt;br /&gt;
* Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
* Manager - Manages the team and its resources. &lt;br /&gt;
* Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
* Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
* Programmer &lt;br /&gt;
* Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
* Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
* Sitting together - The entire team sits in an open space&lt;br /&gt;
* Whole team - Include everyone necessary to success.  &lt;br /&gt;
* Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
* Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
* Pair programming &lt;br /&gt;
* Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
* Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
* Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
* Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
* Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
* Test-first - Every story should have an acceptance test.&lt;br /&gt;
* Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
* Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
* Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
** What have you done since the last Scrum? &lt;br /&gt;
** What will you do between now and the next Scrum? &lt;br /&gt;
** What got in your way of doing work?  &lt;br /&gt;
* Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
* Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
* Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
 * safety (in project outcome)&lt;br /&gt;
 * efficiency&lt;br /&gt;
 * habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29839</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29839"/>
		<updated>2009-11-22T21:20:38Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Feature Drive Development (FDD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager - Manages the team and its resources. &lt;br /&gt;
 * Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
 * Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
 * Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
 * Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
 * Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
 * Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
 * Test-first - Every story should have an acceptance test.&lt;br /&gt;
 * Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
 * Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
 * Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
 ** What have you done since the last Scrum? &lt;br /&gt;
 ** What will you do between now and the next Scrum? &lt;br /&gt;
 ** What got in your way of doing work?  &lt;br /&gt;
 * Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
 * Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
 * Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
 * safety (in project outcome)&lt;br /&gt;
 * efficiency&lt;br /&gt;
 * habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  Generally each iteration lasts two weeks.&lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Typically each feature is tracked individually and a &amp;quot;Burn Up&amp;quot; chart is kept to keep track of the different features for each iteration.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29838</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29838"/>
		<updated>2009-11-22T21:19:07Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Feature Drive Development (FDD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager - Manages the team and its resources. &lt;br /&gt;
 * Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
 * Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
 * Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
 * Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
 * Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
 * Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
 * Test-first - Every story should have an acceptance test.&lt;br /&gt;
 * Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
 * Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
 * Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
 ** What have you done since the last Scrum? &lt;br /&gt;
 ** What will you do between now and the next Scrum? &lt;br /&gt;
 ** What got in your way of doing work?  &lt;br /&gt;
 * Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
 * Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
 * Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
 * safety (in project outcome)&lt;br /&gt;
 * efficiency&lt;br /&gt;
 * habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
* Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
* Chief Architect - Manages the overall design of the project.&lt;br /&gt;
* Development Manager - Leads normal daily activities.&lt;br /&gt;
* Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
* Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
* Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
* Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
*Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
*Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
*Plan by Feature - development plan from feature list&lt;br /&gt;
*Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
*Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track of.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29837</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29837"/>
		<updated>2009-11-22T21:18:22Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Feature Drive Development (FDD) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager - Manages the team and its resources. &lt;br /&gt;
 * Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
 * Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
 * Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
 * Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
 * Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
 * Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
 * Test-first - Every story should have an acceptance test.&lt;br /&gt;
 * Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
 * Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
 * Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
 ** What have you done since the last Scrum? &lt;br /&gt;
 ** What will you do between now and the next Scrum? &lt;br /&gt;
 ** What got in your way of doing work?  &lt;br /&gt;
 * Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
 * Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
 * Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
 * safety (in project outcome)&lt;br /&gt;
 * efficiency&lt;br /&gt;
 * habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Roles:&lt;br /&gt;
&lt;br /&gt;
 * Project Manager - Administrative lead.  Manages resources.&lt;br /&gt;
 * Chief Architect - Manages the overall design of the project.&lt;br /&gt;
 * Development Manager - Leads normal daily activities.&lt;br /&gt;
 * Chief Programmer - Guides and mentors other programmers. &lt;br /&gt;
 * Class Owner - Responsible for designing and coding certain 'areas' that he or she is responsible for.&lt;br /&gt;
 * Domain Experts - Anyone who has expert knowledge of the market the system is being designed for.&lt;br /&gt;
 * Feature teams - Groups of programmers formed temporarily to work on a particular aspect of the project.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
 Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
 Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is selected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspection a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track of.&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29827</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29827"/>
		<updated>2009-11-22T20:01:15Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager - Manages the team and its resources. &lt;br /&gt;
 * Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
 * Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
 * Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
 * Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
 * Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
 * Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
 * Test-first - Every story should have an acceptance test.&lt;br /&gt;
 * Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
 * Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
&lt;br /&gt;
Scrum utilizes two to four week iterations called 'sprints'.  Within each of these a set of user stores are designed, developed, and tested.  &lt;br /&gt;
&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
  Scrum Master - Runs daily scrum meetings&lt;br /&gt;
  Product Owner - The 'customer' who comes up with user stories.&lt;br /&gt;
  Developer - Tester or programmer who does the work during the sprints.&lt;br /&gt;
&lt;br /&gt;
 * Daily scrum meetings - 15 minutes meeting where developers answer three questions:&lt;br /&gt;
 ** What have you done since the last Scrum? &lt;br /&gt;
 ** What will you do between now and the next Scrum? &lt;br /&gt;
 ** What got in your way of doing work?  &lt;br /&gt;
 * Sprint review (at end of sprint) - Review the stories that were completed during the sprint, usually a demonstration is performed.&lt;br /&gt;
 * Sprint retrospective (at end of sprint) - Discuss how the sprint went, areas for improvement. &lt;br /&gt;
 * Spring planning meeting (at beginning of sprint) - Gather user stories to complete during the sprint.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog - A collection of user stories that make up what can be added to a sprint.&lt;br /&gt;
Sprint Backlog - The user stories that will be done during the sprint.  &lt;br /&gt;
Burndown Chart - A chart displaying the amount of work left in the current sprint. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accommodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
All Crystal methodologies try to ensure three things:&lt;br /&gt;
 * safety (in project outcome)&lt;br /&gt;
 * efficiency&lt;br /&gt;
 * habitability (ensure that developers are happy with the process)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
 Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
 Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track of.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
Chicken/Pig philosophy -&lt;br /&gt;
CRC Cards - &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29826</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29826"/>
		<updated>2009-11-22T19:24:34Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager - Manages the team and its resources. &lt;br /&gt;
 * Coach - Ensures everyone is following the extreme program guidelines, usually a programmer.  &lt;br /&gt;
 * Tracker - One of the programmers, puts together wall charts and progress tracking.&lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester - Assists in writing tests with the customer and running the tests.&lt;br /&gt;
 * Customer - Writes acceptance tests and user stories for the development team.&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - At the beginning of the week the customer picks stories to complete during that week&lt;br /&gt;
 * Quarterly Cycle - Each yearly quarter should focus on a 'theme' or stories.&lt;br /&gt;
 * Slack - Lower priority stories that can be dropped if time is limited.&lt;br /&gt;
 * Ten-minute build - Ensure the project and its tests can be built and run within 10 minutes.&lt;br /&gt;
 * Test-first - Every story should have an acceptance test.&lt;br /&gt;
 * Continuous Integration - Code should be checked in several times a day, with unit tests being run all the time. &lt;br /&gt;
 * Incremental Design - Design daily at each step. &lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
&lt;br /&gt;
Crystal methodologies are a range of methodologies that consist of varying degrees of agile development, for example Crystal Clear is the most agile and Crystal Red is the least.  These different sub-methodologies are designed to accomodate different team sizes as well.  Crystal Clear for example, is to be used with eight developers or less and should have incremental releases of at most every four months.  Crystal Orange is designed to be used with twenty to fourty developers and should have a duration of no longer than two years. &lt;br /&gt;
&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
&lt;br /&gt;
Model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
 Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
 Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track of.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
== Major Differences ==&lt;br /&gt;
All of these methodologies are very similar and you have to look very close to spot the differences aside from nomenclature.  Generally the only differences from any of these methods are the lengths of the iteration.  Each method also generally emphasises some aspect of software development that the others do not.  For example, Extreme Programming places an emphasis on paired programming and CRC cards, while none of the others do so.  This does not mean you cannot use these techniques with the other methods, they simply do not place an emphasis on them.    &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf &lt;br /&gt;
http://en.wikipedia.org/wiki/Extreme_Programming&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29483</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29483"/>
		<updated>2009-11-19T03:19:51Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile development is a relatively new software development method that is becoming increasingly popular in the software industry.  These methods promote smaller development iterations and much quicker stable builds of a product.  Typically iterations can last between one and three weeks, compared with a normal 9 month or longer waterfall model.  &lt;br /&gt;
&lt;br /&gt;
There are many different agile methodologies, the most popular of which Extreme Programing. This page attempts to compare the different agile methods with that of Extreme Programming.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager&lt;br /&gt;
 * Coach &lt;br /&gt;
 * Tracker &lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester &lt;br /&gt;
 * Customer&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - &lt;br /&gt;
 * Quarterly Cycle&lt;br /&gt;
 * Slack &lt;br /&gt;
 * Ten-minute build&lt;br /&gt;
 * Test-first &lt;br /&gt;
 * Continuous Integration&lt;br /&gt;
 * Incremental Design&lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29466</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29466"/>
		<updated>2009-11-19T03:13:24Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Extreme Programming (XP) ==&lt;br /&gt;
&lt;br /&gt;
Extreme Programming is one of the most popular agile methodologies.  This type of development features frequent small releases &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 * Complete iteration every 1 - 3 weeks&lt;br /&gt;
 * Complete release with every iteration&lt;br /&gt;
&lt;br /&gt;
Several types of documentation are used for planning and design purposes:&lt;br /&gt;
&lt;br /&gt;
 * User story cards&lt;br /&gt;
 * Task List&lt;br /&gt;
 * CRC Cards&lt;br /&gt;
 * Customer Acceptance Tests&lt;br /&gt;
 * Visible Wall Graphs&lt;br /&gt;
&lt;br /&gt;
Also there are may different roles that individuals of the team may take, of which someone may take more than one role.&lt;br /&gt;
&lt;br /&gt;
 * Manager&lt;br /&gt;
 * Coach &lt;br /&gt;
 * Tracker &lt;br /&gt;
 * Programmer &lt;br /&gt;
 * Tester &lt;br /&gt;
 * Customer&lt;br /&gt;
&lt;br /&gt;
There are 13 goals and practices of extreme programming:&lt;br /&gt;
 * Sitting together - The entire team sits in an open space&lt;br /&gt;
 * Whole team - Include everyone necessary to success.  &lt;br /&gt;
 * Informative workspace - Include signs around the workspace to indicate progress.&lt;br /&gt;
 * Energized Work - Do not overextend members for a long period of time. &lt;br /&gt;
 * Pair programming &lt;br /&gt;
 * Stories (User stories) - Small statements of functionality ordered in priority by the customer. &lt;br /&gt;
 * Weekly cycle - &lt;br /&gt;
 * Quarterly Cycle&lt;br /&gt;
 * Slack &lt;br /&gt;
 * Ten-minute build&lt;br /&gt;
 * Test-first &lt;br /&gt;
 * Continuous Integration&lt;br /&gt;
 * Incremental Design&lt;br /&gt;
&lt;br /&gt;
There are also 11 secondary practices which are considered somewhat optional.  These will not be discussed here.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29040</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29040"/>
		<updated>2009-11-19T00:50:25Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Agile Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;br /&gt;
&lt;br /&gt;
== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile software development is a collection of processes and development methodologies that emphasize small iterative cycles that allow for a more dynamic evolution of the software.  Unlike the waterfall model, whereby each iteration of development may last nine months or longer, iterations in agile models typically only last a few weeks.  &lt;br /&gt;
&lt;br /&gt;
Some benefits of Agile development include:&lt;br /&gt;
&lt;br /&gt;
 * The ability to change requirements through time.&lt;br /&gt;
 * It is much easier to scope the required resources for a task since the task is much smaller&lt;br /&gt;
 * Having a functional piece of software at the end of each iteration.&lt;br /&gt;
&lt;br /&gt;
While there are many different Agile Development forms, they are all very similar and usually only have a few differences.&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
Frequent small releases (Every week or two)&lt;br /&gt;
Complete iteration (Every 1 - 3 weeks)&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29021</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=29021"/>
		<updated>2009-11-19T00:43:11Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Agile Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;br /&gt;
&lt;br /&gt;
== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
Agile software development is a collection of processes and development methodologies that emphasize small iterative cycles that allow for a more dynamic evolution of the software.  Unlike the waterfall model, whereby each iteration of development may last nine months or longer, iterations in agile models typically only last a few weeks.  &lt;br /&gt;
&lt;br /&gt;
While there are many different Agile Development forms, they are all very similar and usually only have a few differences.&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
Frequent small releases (Every week or two)&lt;br /&gt;
Complete iteration (Every 1 - 3 weeks)&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28173</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28173"/>
		<updated>2009-11-18T05:44:53Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;br /&gt;
&lt;br /&gt;
== Agile Development ==&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
Frequent small releases (Every week or two)&lt;br /&gt;
Complete iteration (Every 1 - 3 weeks)&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28171</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28171"/>
		<updated>2009-11-18T05:44:13Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
Frequent small releases (Every week or two)&lt;br /&gt;
Complete iteration (Every 1 - 3 weeks)&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28163</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28163"/>
		<updated>2009-11-18T05:38:06Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
Frequent small releases (Every week or two)&lt;br /&gt;
Complete iteration (Every 1 - 3 weeks)&lt;br /&gt;
User stories are written&lt;br /&gt;
Code unit tests first&lt;br /&gt;
Pair programming&lt;br /&gt;
Emphasis on CRC crds during designs&lt;br /&gt;
&lt;br /&gt;
http://www.extremeprogramming.org&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
Strong emphasis on Dynamic programming languages &lt;br /&gt;
speculate, collaborate, and learn cycles.&lt;br /&gt;
http://en.wikipedia.org/wiki/Adaptive_Software_Development&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
Places emphasis on different roles (Chicken/Pig)&lt;br /&gt;
   ScrumMaster&lt;br /&gt;
   Product Owner&lt;br /&gt;
   Team&lt;br /&gt;
   Stakeholders&lt;br /&gt;
&lt;br /&gt;
Daily scrum meetings&lt;br /&gt;
Sprint review (at end)&lt;br /&gt;
sprint retrospective (at end)&lt;br /&gt;
Spring planning meeting (at begining)&lt;br /&gt;
frequent stackholder meetings&lt;br /&gt;
&lt;br /&gt;
Items &lt;br /&gt;
Product Backlog&lt;br /&gt;
Sprint Backlog&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
two to four week 'sprints'&lt;br /&gt;
&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
Project lifestyle:&lt;br /&gt;
feasibility study,  &lt;br /&gt;
business study, &lt;br /&gt;
functional model iteration, &lt;br /&gt;
design and build iteration, and &lt;br /&gt;
implementation.&lt;br /&gt;
&lt;br /&gt;
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
3  priorities [ safety (in project outcome), efficiency, habitability (developers can live with crystal)]&lt;br /&gt;
&lt;br /&gt;
http://martinfowler.com/articles/newMethodology.html#Crystal&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
model-driven short-iteration process composed of 5 activities.  &lt;br /&gt;
&lt;br /&gt;
Activities:&lt;br /&gt;
   Develop Overall Model - Walkthroughs of different models are done and presented for peer review.  &lt;br /&gt;
   Build Feature List - The result of the modeling stage is used to gather a list of features.  Domain is split into subject areas which contain business activities.  Max feature time is two weeks.&lt;br /&gt;
 Plan by Feature - development plan from feature list&lt;br /&gt;
 Design by Feature - A set of features that can be done in two weeks is sselected.  The design is done at the class level.&lt;br /&gt;
 Build by features - each of the selected features is built.  Unit tests and code inspecition a must.  &lt;br /&gt;
&lt;br /&gt;
Milestones &lt;br /&gt;
 Six milestones per feature that are completed sequentially.  Percentage of each milestone is kept track o.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28142</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28142"/>
		<updated>2009-11-18T05:22:40Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
== Extreme Programming ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28140</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28140"/>
		<updated>2009-11-18T05:22:18Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Adaptive Software Development (ASD)===&lt;br /&gt;
=== Scrum ===&lt;br /&gt;
=== Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
=== Crystal ===&lt;br /&gt;
=== Feature Drive Development (FDD) ===&lt;br /&gt;
=== Lean Software Development (LSD) ===&lt;br /&gt;
=== Agile Modeling (AM) ===&lt;br /&gt;
=== Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28139</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28139"/>
		<updated>2009-11-18T05:21:56Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== 1) Adaptive Software Development (ASD)===&lt;br /&gt;
=== 2) Scrum ===&lt;br /&gt;
=== 3) Dynamic Systems Development Method (DSDM) ===&lt;br /&gt;
=== 4) Crystal ===&lt;br /&gt;
=== 5) Feature Drive Development (FDD) ===&lt;br /&gt;
=== 6) Lean Software Development (LSD) ===&lt;br /&gt;
=== 7) Agile Modeling (AM) ===&lt;br /&gt;
=== 8) Agile Unified Process (AUP) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28134</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28134"/>
		<updated>2009-11-18T05:21:05Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== 1) Adaptive Software Development (ASD)==&lt;br /&gt;
 2) Scrum&lt;br /&gt;
 3) Dynamic Systems Development Method (DSDM)&lt;br /&gt;
 4) Crystal&lt;br /&gt;
 5) Feature Drive Development (FDD)&lt;br /&gt;
 6) Lean Software Development (LSD)&lt;br /&gt;
 7) Agile Modeling (AM)&lt;br /&gt;
 8) Agile Unified Process (AUP)&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28133</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28133"/>
		<updated>2009-11-18T05:20:50Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 1) Adaptive Software Development (ASD)&lt;br /&gt;
 2) Scrum&lt;br /&gt;
 3) Dynamic Systems Development Method (DSDM)&lt;br /&gt;
 4) Crystal&lt;br /&gt;
 5) Feature Drive Development (FDD)&lt;br /&gt;
 6) Lean Software Development (LSD)&lt;br /&gt;
 7) Agile Modeling (AM)&lt;br /&gt;
 8) Agile Unified Process (AUP)&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28095</id>
		<title>CSC/ECE 517 Fall 2009/wiki3 11 j8</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_11_j8&amp;diff=28095"/>
		<updated>2009-11-18T05:04:38Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The most popular Agile methodology is Extreme Programming (XP). However, there are many other agile process models that have been proposed and used in industry, such as--&lt;br /&gt;
&lt;br /&gt;
1) Adaptive Software Development (ASD)&lt;br /&gt;
2) Scrum&lt;br /&gt;
3) Dynamic Systems Development Method (DSDM)&lt;br /&gt;
4) Crystal&lt;br /&gt;
5) Feature Drive Development (FDD)&lt;br /&gt;
6) Lean Software Development (LSD)&lt;br /&gt;
7) Agile Modeling (AM)&lt;br /&gt;
8) Agile Unified Process (AUP)&lt;br /&gt;
&lt;br /&gt;
Compare these methodologies, telling how they are different from XP, and assessing their strengths and weaknesses.&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25937</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25937"/>
		<updated>2009-10-14T03:53:37Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Definitions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.   The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  [[#ref_1|[1]]] We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
* Serialization - The process of converting an object into a form more suitable for storage or transmission.  [[#ref_3|[3]]] &lt;br /&gt;
* Deserialization - The process of converting data read from disk or received from a transmission into object form.   [[#ref_3|[3]]]&lt;br /&gt;
* Immutable Object - An object who's attributes cannot be changed after creation.   [[#ref_5|[5]]]&lt;br /&gt;
* Thread Safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization proxy pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25936</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25936"/>
		<updated>2009-10-14T03:52:09Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* The Proxy Object */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.   The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  [[#ref_1|[1]]] We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization proxy pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25934</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25934"/>
		<updated>2009-10-14T03:51:51Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.   The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization proxy pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25932</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25932"/>
		<updated>2009-10-14T03:51:36Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.   The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25931</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25931"/>
		<updated>2009-10-14T03:51:13Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  [[#ref_1|[1]]] The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25929</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25929"/>
		<updated>2009-10-14T03:50:46Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Drawbacks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
[[#ref_7|[7]]]&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25927</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25927"/>
		<updated>2009-10-14T03:50:23Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7]  [http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25925</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25925"/>
		<updated>2009-10-14T03:50:03Z</updated>

		<summary type="html">&lt;p&gt;Lee: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.   [[#ref_3|[3]]]&lt;br /&gt;
&lt;br /&gt;
Immutable objects aid in ensuring thread safety, since they cannot be changed. [[#ref_4|[4]]]&lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.  [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.   [[#ref_6|[6]]]&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.  &lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.     [[#ref_2|[2]]]&lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[5]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_6&amp;quot; /&amp;gt;[6]  [http://java.sun.com/developer/technicalArticles/Programming/serialization/ Discover the Secrets of the Java Serialization API]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_7&amp;quot; /&amp;gt;[7] [ http://books.google.com/books?id=ka2VUBqHiWkC&amp;amp;pg=PA312&amp;amp;lpg=PA312&amp;amp;dq=serialization+proxy&amp;amp;source=bl&amp;amp;ots=yXHkMnp_N1&amp;amp;sig=8sTsZWu1ZOaf-cuozd7eQ60JiP8&amp;amp;hl=en&amp;amp;ei=FErVSpHxGeGJtgeF692pAw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=6&amp;amp;ved=0CBwQ6AEwBQ#v=onepage&amp;amp;q=serialization%20proxy&amp;amp;f=false Effective Java 2nd Edition page 312]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25918</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25918"/>
		<updated>2009-10-14T03:41:02Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_1&amp;quot; /&amp;gt;[1] [http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern What is the serialization pattern ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_2&amp;quot; /&amp;gt;[2]  [http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/ Serializing Immutable Singletons]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_3&amp;quot; /&amp;gt;[3]  [http://en.wikipedia.org/wiki/Serialization Serialization ]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_4&amp;quot; /&amp;gt;[4]  [http://en.wikipedia.org/wiki/Thread_safety Thread Safety]&lt;br /&gt;
&amp;lt;div id=&amp;quot;ref_5&amp;quot; /&amp;gt;[6]  [http://www.javaranch.com/journal/2003/04/immutable.htm Mutable and Immutable Objects]&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25910</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25910"/>
		<updated>2009-10-14T03:37:02Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Drawbacks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25909</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25909"/>
		<updated>2009-10-14T03:36:53Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Drawbacks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
 &lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
 &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25908</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25908"/>
		<updated>2009-10-14T03:35:54Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* The Proxy Object */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
* A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
* An inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25907</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25907"/>
		<updated>2009-10-14T03:35:34Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* The Proxy Object */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We could visually represent it as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To see this in code we would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  &lt;br /&gt;
&lt;br /&gt;
 * A private static class was added that is Serializable and holds all the same information as the Person class.  &lt;br /&gt;
 * An inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25906</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25906"/>
		<updated>2009-10-14T03:33:53Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* The Proxy Object */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:SerialProxy lee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  A private static class was added that is Seriazliable and holds all the same information as the Person class.  Also an inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25903</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25903"/>
		<updated>2009-10-14T03:32:39Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[Image:Serial noproxy ee.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  A private static class was added that is Seriazliable and holds all the same information as the Person class.  Also an inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25902</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25902"/>
		<updated>2009-10-14T03:31:53Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[File:Serial noproxy ee.jpg|caption]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  A private static class was added that is Seriazliable and holds all the same information as the Person class.  Also an inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25901</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 ee</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_ee&amp;diff=25901"/>
		<updated>2009-10-14T03:30:33Z</updated>

		<summary type="html">&lt;p&gt;Lee: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Serialization Proxy Design Pattern=&lt;br /&gt;
&lt;br /&gt;
During system design, immutable classes are preferred to guarantee thread safety and consistent object state. For instance, serialization of immutable classes could cause issues in Java if immutability must be preserved. The Serialization Proxy Pattern aims to make serialization acceptable in that regard. Discuss serialization proxy pattern with regards to the problem, design, implementation details, and idiomatic usage. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
Serialization is the process of converting an object or many objects into a form that can be either written to disk or transmitted across the network.  The idea being that these can be read back and loaded as objects within an environment, called de-serialization.  Imagine having an application with user objects.  When the application is shut down, the objects are written to disk.  When the application is started back, the user objects are read from disk and initialized as objects.  The objects themselves would be in the exact same state as they were before the system was shut down.  &lt;br /&gt;
&lt;br /&gt;
Here is a dipiction of normal serialization.  This shows the Person class being serialized and de-serialized:&lt;br /&gt;
&lt;br /&gt;
[[File:{Serial_noproxy_ee.jpg}]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
When the need to serialize objects in Java arises, the most common tool is the Serializable interface.  This interface is simply used to indicate that the object is serializable.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here is a simple example of serialization in java:&lt;br /&gt;
&lt;br /&gt;
        ObjectOutputStream stream = new ObjectOutputStream(new FileOutputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        stream.writeObject(myObject);&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would serialize the object &amp;quot;myObject&amp;quot; into the file &amp;quot;/tmp/foo&amp;quot;.  Here is a simple example of deserialization:&lt;br /&gt;
&lt;br /&gt;
        ObjectInputStream stream = new ObjectInputStream(new FileInputStream(&amp;quot;/tmp/foo&amp;quot;));&lt;br /&gt;
        Object myObject = stream.readObject();&lt;br /&gt;
        stream.close();&lt;br /&gt;
&lt;br /&gt;
This would take the data in /tmp/foo and deserialize it into the myObject object.&lt;br /&gt;
&lt;br /&gt;
==The Problem==  &lt;br /&gt;
&lt;br /&gt;
One issue with serialization under Java is the need for serialization of immutable classes.  These are classes that after creation, cannot be modified.  Take the following class for example:&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     String name;&lt;br /&gt;
     Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
Once the constructor is called, neither name or age can be changed.  This class is immutable.&lt;br /&gt;
&lt;br /&gt;
The class is easily serializable with no changes, and could be written to disk easily.  A problem arises when the object needs to be de-serialized.  &lt;br /&gt;
&lt;br /&gt;
Normally when Java is de-serializing an object, it would call the default constructor Person() and then call the setter on each object attribute.  With this object there is no default constructor, nor are there setters for the object's attributes.  This was done intentionally to keep the object from changing.  Serialization Proxy pattern comes into play here.&lt;br /&gt;
&lt;br /&gt;
==The Proxy Object==&lt;br /&gt;
&lt;br /&gt;
To work around the fact that we can't deserialize an immutable class, we use a proxy object that is an inner class of the class we want to serialize.  We would change the Person class as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  public class Person {&lt;br /&gt;
     private String name;&lt;br /&gt;
     private Integer age;&lt;br /&gt;
     &lt;br /&gt;
     public Person(String name, Integer age) {&lt;br /&gt;
         this.name = name;&lt;br /&gt;
         this.age = age;&lt;br /&gt;
     }&lt;br /&gt;
     public String name() { return name; }&lt;br /&gt;
     public Integer age() { return age; } &lt;br /&gt;
  &lt;br /&gt;
     private Object writeReplace() {&lt;br /&gt;
        return new Proxy(this);&lt;br /&gt;
    }&lt;br /&gt;
    &lt;br /&gt;
  &lt;br /&gt;
     private static class Proxy implements Serializable {&lt;br /&gt;
        String name;&lt;br /&gt;
        Integer age;&lt;br /&gt;
  &lt;br /&gt;
        public Proxy() { }&lt;br /&gt;
        public Proxy(Person person) {&lt;br /&gt;
            name = person.name();  &lt;br /&gt;
            age = person.age();&lt;br /&gt;
        }&lt;br /&gt;
  &lt;br /&gt;
        Object readResolve() {&lt;br /&gt;
            return new Person(name, age);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
  }&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So what changed?  A private static class was added that is Seriazliable and holds all the same information as the Person class.  Also an inner private method called writeReplace() is added to the Parent class.  &lt;br /&gt;
&lt;br /&gt;
=== Serialization ===&lt;br /&gt;
&lt;br /&gt;
During serialization, the following occurs:&lt;br /&gt;
&lt;br /&gt;
# The object is checked to see if writeReplace() is defined for the Person object.&lt;br /&gt;
# The writeReplace() function is called to retrieve the proxy object.&lt;br /&gt;
# Serialization takes place on the proxy object instead.&lt;br /&gt;
&lt;br /&gt;
=== Deserialization ===&lt;br /&gt;
&lt;br /&gt;
During deserialization, the following occurs:&lt;br /&gt;
  &lt;br /&gt;
# The stored Proxy object is deserialized, resulting in a Proxy object.  Since the member variables of the Proxy object are public, it can be deserialized with no issue.  &lt;br /&gt;
# The Proxy object is examined to determine if it has a readResolve() method.&lt;br /&gt;
# Since it does, readResolve() is called, returning a new Person immutable object.&lt;br /&gt;
&lt;br /&gt;
===Benefits===&lt;br /&gt;
&lt;br /&gt;
* The ability to serialize immutable objects.&lt;br /&gt;
* The interface of the immutable object does not have to be changed&lt;br /&gt;
&lt;br /&gt;
===Drawbacks===&lt;br /&gt;
* Slower than normal serialization&lt;br /&gt;
* Cannot handle some objects with circular object graphs.  The following is an example of a circular object graph:&lt;br /&gt;
&lt;br /&gt;
 public class A {&lt;br /&gt;
    private B classB;&lt;br /&gt;
&lt;br /&gt;
    public A(){}&lt;br /&gt;
    public getClassB() { return classB };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
 public class B {&lt;br /&gt;
    private A classA;&lt;br /&gt;
   &lt;br /&gt;
    public B(){}&lt;br /&gt;
    public getClassA() { return classA };&lt;br /&gt;
&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
In this example, class A holds an instance to class B and class B holds an instance to class A.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
&lt;br /&gt;
 - serialization - The process of converting an object into a form more suitable for storage or transmission.  &lt;br /&gt;
 - deserialization - The process of converting data read from disk or received from a transmission into object form.  &lt;br /&gt;
 - immutable object - An object who's attributes cannot be changed after creation.  &lt;br /&gt;
 - thread safety - the ability of a piece of software to be executed by multiple threads at the same time without malfunctioning.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
 http://stackoverflow.com/questions/702357/what-is-the-serialization-proxy-pattern&lt;br /&gt;
 http://lingpipe-blog.com/2009/08/10/serializing-immutable-singletons-serialization-proxy/&lt;br /&gt;
 http://en.wikipedia.org/wiki/Serialization&lt;br /&gt;
 http://en.wikipedia.org/wiki/Thread_safety&lt;/div&gt;</summary>
		<author><name>Lee</name></author>
	</entry>
</feed>