Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T04:29:02Z

Bluehat: /* Spiral model */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile Methodology==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:agile.gif|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:spiral.png|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Insufficient customer involvement can result in confused and incomplete requirement document and bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequent sync calls and sharing wiki pages.
*Even though some projects are characterized by slow Rate of change making them fall into other software development category, they can be good candidates for agile if other agile development methods can be applied to the project effectively

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==

[1] http://www.buzzle.com/articles/waterfall-model-vs-agile.html

[2] M. A. Awad, "A Comparison between Agile and Traditional Software Development Methodologies"

[3] Boehm B, "A Spiral Model of Software Development and Enhancement"ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986

[4] Rashina H, Philippe K, James N and Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

2010-09-08T14:39:19Z

Bluehat: /* CRC Principle */

==Introduction==

The onset of the object oriented paradigm in the software industry brought about a big change in the basic approach to system design and the software development life cycle.The major task in the development of any application using the object oriented paradigm is to identify ‘classes’, and how these classes interact and collaborate with each other in the system scope.

Whenever a system is designed with classes, each class has a specific role to play in the system.It has certain responsibilities and each class collaborates with other classes to provide the complete system functionality. In such a scenario, identifying classes becomes the key to a good system design.Although it seems to be a simple,intuitive process,identifying classes can be quite complex when it comes to large scale systems.

One such technique for identification of classes that make up the system and its collaborations is the ‘CRC Card’ technique. The concept of CRC cards was first put forth by Kent Beck and Ward Cunningham and it became very popular as it is easy to use and it supports development of any kind of object oriented development regardless of its scale,the method used, the technology or the language used for development

==Definition==
Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.
A typical CRC card layout is shown below.
[[Image:Crccard2.jpg|frame|center|CRC CARD Template]]

Example: Consider a Student class where a student can enroll for a seminar. In this case ‘Student’ will be one class and ‘Seminar’ can be another class that collaborates with the Student class.

[[Image:CrcStudent.jpg|frame|center|Student CRC Card ]]

To know more about CRC cards please refer to http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf

==Principle and Process==

===CRC Principle===

A CRC model includes a collection of cards and each card is divided into three sections.
*Class Name:
**Appears on the top of the CRC card
**Class denotes a set of similar objects that are being modeled in the system

*Responsibilities:
**Appears on the left hand side of the CRC card
**It is a list of the responsibilities of the class i.e. things a class can do with its knowledge

*Collaborators:
**Appear on the right hand side of the CRC card
**They are other classes that the class works with to get information or perform a certain function

===CRC Process===

CRC modeling process includes the users, analysts, and developers in a modeling and design process, bringing together the entire development team to form a common understanding of an OO development project.Example: Consider a software application to implement a game of blackjack. To implement the CRC technique to design this software, the steps of the process are as follows:

*Explanation of the CRC Technique

**The facilitator explains the purpose of the CRC modeling session
**It can include explanation of CRC Cards and creation of sample CRC Cards

*Brainstorming

**A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved.
**Every team member can contribute with innovative ideas
**A list of candidate classes can be drawn up from this activity

Example: considering the above example, we can identify candidate classes by listing down the nouns relating to the game of blackjack. Say, game, blackjack, dealer, players, card, deck, hand, bet, king, queen, jack, ace, suit, winner, game.

*Selecting a scenario and Core classes

**The scenario chosen at the beginning of the session should be simple, clear and well documented
**Related scenarios should be identified and dealt with separately
**Identification of critical classes from the candidate class list is also very important
**This helps to eliminate irrelevant classes and review remaining classes
**This also helps clarify the system scope

Example: We can apply the elimination process to the candidate class list. We can eliminate blackjack as it is the name of the system. ‘House’ can be eliminated as it is another name for the dealer. Also, instead of making ace, king, queen and jack as separate classes, we can represent them as attributes of individual classes.

*Create initial CRC cards

[[Image:Deck1.jpg |frame|center|Deck CRC Card]]

[[Image:Dealer.jpg |frame|center|Dealer CRC Card]]

[[Image:Player.jpg |frame|center|Player CRC Card]]

**From the information gathered in the step above, CRC cards are written

*Creating a CRC Model

**From the CRC cards written, they are placed appropriately, with collaborating classes closer to each other
**Accordingly, place each card in position till the entire picture of the system is finalized.
**This process may have to be done in several iterations to get a refined view of the system to be modeled

Using CRC Cards: http://alistair.cockburn.us/Using+CRC+cards

==The CRC Team==

*Domain Experts:
**Core team that writes the cards
**Have good business domain knowledge for which the system is being designed
**Usually are 3-5 people

*Object Oriented Design Analyst:
**Analysts and developers those are familiar with object oriented design methodologies
**Usually are 1-2 people

*Facilitator:
**Most important member who conducts the CRC modeling session
**Acts as an intermediary when there is difference of opinion regarding class responsibilities and paths of collaboration
**Usually a single person

*Scribe:
**Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process.
**This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage
**Usually are 1-2 people

==Case study==

To understand the working of CRC card modeling better, here is an example of an ATM system designed using CRC cards. Here, the software system under consideration has to control an automated teller machine. The ATM has a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. Also, the ATM will communicate with the bank's computer over an appropriate communication link.

To perform a transaction, a customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that there are no further transactions, at which point it will be returned. For more on the case study.

http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

==Metrics for CRC Analysis==

CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development.These metrics can be calculated easily and quickly without the need of special tools. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. With the example below an attempt has been made to explain these metrics.In the diagram, black line indicates inheritance while blue line indicates collaboration.

[[Image:Class_hierarchy1.png|frame|center|CRC metrics example]]

===Maximum depth of inheritance===

This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.

===Number of collaborators===

This is the count of all the supporting classes to help a class.In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.

===Number of responsibilities===
This is the count of clearly defined set of duties to each class.For example class Student may have functions like Attending Lectures,
Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.

==Advantages==
* CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems.
* CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML
* CRC cards are a great way to build teamwork and common understanding.
* Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools

==Software for CRC card==

It is difficult to maintain, change, share paper based cards for large projects. Software for CRC cards offer many advantages in such scenarios such as

*Easy Revision: As CRC cards are part of development process, constant changes are made by developers to edit the information .Change to one card might require changes to other cards. It becomes difficult to handle such interdependent changes for various fields such as attribute, responsibility, collaboration on paper based system. Software will reflect one change to every corresponding reference in the design. This saves a lot of time and also avoids the manual errors that may be evident on paper based system.

*Easy sharing: Paper based systems make sharing difficult by necessitating team members to be physically present at one location. Using software, team members can work from different locations.

*Better representation: It is possible to group cards from different perspective such as hierarchy, attributes, parent. This helps better understanding and thinking. Some software also aid graphical display of data.

*Inputs to methodologies: Software for CRC cards can provide the input files for UML class diagram generation software saving lot of time in the development cycle.

*Making additions to existing code: Many projects make addition to existing code or reuse already developed code in their project. Software can produce CRC cards with existing source code as an input. This would help the team to understand the code in efficient manner and less time.

However,it comes with a cost.Based on required features and cost,team may select from various commercially available software products.Below are few links:

*quickCRC:http://www.excelsoftware.com/
*CRC card support is part of Visual Paradigm for UML: http://www.visual-paradigm.com/

==CRC cards Limitations and formal object modeling methodologies(UML)==

CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

http://www.math.gordon.edu/courses/cs211/ATMExample/

==Summary==
CRC cards are very useful to form the base of object oriented methodology.Techniques such as brain storming and role play enhance the understanding of requirements.CRC automation makes card handling and sharing quick and efficient.For large projects more formal technology such as UML is required but CRC cards can provide a very good starting point.

==Reference==
*Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf
*CRC Cards for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html
*UML methodology for ATM :http://www.math.gordon.edu/courses/cs211/ATMExample/
*CRC software:
**quickCRC:http://www.excelsoftware.com/
**Visual Paradigm: http://www.visual-paradigm.com/
*Bellin, D and Simone, S.S ‘The CRC Card Book’, Addison Wesely, 1997