Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:55:12Z

Sparnan: /* Scrum */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:54:32Z

Sparnan: /* Responsibility-Driven Design */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:54:20Z

Sparnan: /* Responsibility-Driven Design */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:54:00Z

Sparnan: /* OOD Perspectives and Concepts */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:53:37Z

Sparnan: /* Scrum */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:51:50Z

Sparnan: /* Scrum */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:51:07Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:41:43Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-15T00:34:35Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing. The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:35:03Z

Sparnan: /* Fixtures and Factories(SAAS Video) */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration tests<ref>http://en.wikipedia.org/wiki/Integration_testing</ref>. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:34:34Z

Sparnan: /* References */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:33:28Z

Sparnan: /* Cohesion and Coupling */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to object-oriented programming<ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes"<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:32:56Z

Sparnan: /* Cohesion and Coupling */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

Cohesion<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref> and Coupling<ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref> are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:32:20Z

Sparnan: /* OOD Perspectives and Concepts */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D Protocols]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:30:30Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Fast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Independent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:29:45Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:29:09Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here] is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:28:43Z

Sparnan: /* Introduction */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered (in 2a) and the links to the appropriate topic are available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:27:56Z

Sparnan: /* Responsibility-Driven Design */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:26:07Z

Sparnan: /* Scrum */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models Here] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:25:29Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:25:11Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T10:24:41Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.]

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a topics

2012-12-12T00:49:22Z

Sparnan:

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T19:45:32Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.


More about automated testing is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w10_rc here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T19:05:11Z

Sparnan: /* Fixtures and Factories(SAAS Video) */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==More Controller Specs and Refactoring==

This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.

More about this SAAS video is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w32_mk here]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T19:03:26Z

Sparnan: /* Design Patterns */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Build Management==

'''Build Management ''' is the process of delivering the software in an executable format .The final deliverables are known as '''software builds '''. For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.

Consider the following example

A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable.
The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.

'''Build Automation''' is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.

More about this topic is available [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w12_sv here].

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T12:12:34Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

More about this topic can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w13_sm here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T12:10:25Z

Sparnan: /* OOD Perspectives and Concepts */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Cohesion and Coupling==

<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>.
In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

More about this wiki page can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w20_aa here]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-11T12:08:09Z

Sparnan: /* Enhancing Rotten Potatoes(SAAS Video) */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==Fixtures and Factories(SAAS Video)==

One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

More about this topic is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w33_pv here].

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T15:38:08Z

Sparnan: /* Responsibility-Driven Design */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w9_ms Pair Programming]

More about Agile Software development can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp here].
More about Extreme Programming can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w8_vp here].
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Test_Driven_Development_.28TDD.29 here].More about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here]

Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Behavior_Driven_Development_.28BDD.29 here].

Below are few characteristics of a good unit test:
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testFast]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_testIndependent]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Repeatable]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Self-checking]
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#Characteristics_of_a_good_Unit_test Timely]

[http://en.wikipedia.org/wiki/RSpec RSpec] is a testing tool for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] [http://rspec.info/]. It is based on [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] framework and is inspired by [http://jbehave.org/ JBehave] which is another BDD testing framework [http://en.wikipedia.org/wiki/RSpec]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [http://en.wikipedia.org/wiki/Domain-specific_language].More about RSpec can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec here]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==OOD Perspectives and Concepts==

There are three perspectives of Object Oriented Design:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Language-centric_perspective Language-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Model-centric_perspective.5B3.5D Model-centric perspective]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibility-centric_perspective.5B4.5D Responsibility-centric perspective]

OOD concepts are given below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Roles_.28relation_with_objects.29 Roles]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Responsibilities_.5B8.5D Responsibilities]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Behavior_.5B9.5D Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w15_rr#Protocols_.5B10.5D]

==Responsibility-Driven Design==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming(OOP) language] enables software to be reusable, refinable, testable, maintainable, and extensible by supporting [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) encapsulation]. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.

Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by [http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock Rebecca Wirfs-Brock] and Brian Wilkerson.

Responsibility-Driven Design is defined as follows:

It is inspired by the [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client/server model]. It focuses on the contract by asking:

* What actions is this object responsible for?
* What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>

The basic principles of Responsibility-Driven Design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Maximize Abstraction]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Distribute Behavior]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Responsibility-Driven_Design_principles_and_analysis Preserve Flexibility]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Example Here] is an example of Responsibility-Driven design.

Advantages of Responsibility Driven design are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Increases encapsulation]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Advantages Facilitates Polymorphism]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w23_sr#Comparison_of_Responsibility-Driven_Design_with_Data-Driven_Design Here] is a comparison between Responsibility driven design and Data driven design.

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w17_pt#Proxy_pattern Proxy Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==Enhancing Rotten Potatoes(SAAS Video)==

This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8 </ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref> The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of the wiki page is as follows :

*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Scope The scope of discussion]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#A_Brief_Recap Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#Happy_Path.2C_Sad_Path_and_Bad_path Explanation of Sad path, Happy Path and Bad Path]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Description of the User Story developed in the video lecture]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber]
*[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w26_aj#The_User_Story Explanation of the Background facility in Cucumber]

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T15:31:56Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T15:27:15Z

Sparnan: /* Responsibility-Driven Design */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T13:12:08Z

Sparnan: /* Design Patterns */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T12:14:30Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T12:01:11Z

Sparnan: /* Design Patterns */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T11:39:38Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T11:21:50Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T11:13:03Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T11:06:51Z

Sparnan: /* Design Patterns */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:55:58Z

Sparnan: /* Testing */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:29:16Z

Sparnan: /* Software Process Models */

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:29:04Z

Sparnan: /* Agile */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:28:15Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa V-Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:27:39Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm Spiral Model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:26:43Z

Sparnan: /* Software Process Models */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:26:18Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#The_Waterfall_model: The Waterfall model]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Incremental_or_Iterative_Development Incremental or Iterative Development]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Agile_Methodology Agile Methodology]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Extreme_Programming Extreme Programming]

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:22:02Z

Sparnan: /* Testing */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.

The importance of software testing can be explained in brief in the following points.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Error Free Software]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Variance from the Requirement]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Defect and Prevent their Migration]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Identify Undiscovered Error]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Do Away with Developer Bias]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#Importance_of_Software_Testing Provide Confidence in the Software]

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern

CSC/ECE 517 Fall 2012/ch2a 2w29 st

2012-12-10T10:07:47Z

Sparnan: /* Introduction */

<h2>SaaS - 5.1 - Testing overview</h2>
__TOC__
==Introduction==
This ia a textbook section that covers the online lecture on [https://www.youtube.com/watch?v=Hpg9303P0Ts Testing Overview].
Gone are the days when the developers used to write code and toss it to the QA team for testing. Today’s developers are far more responsible for testing their own code. Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.

==History==
Brian Kernighan famously quoted that “Debugging is twice as hard as writing the code in the first place.” Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
In other words it meant if you’re as clever as you can be when you write your code, how will you ever debug it.

Another famous computer scientist Dijkstra famously remarked that "testing can be used to show the presence of bugs but never to show their absence”.The fact is that NOTHING, not inspection, not formal proof, not testing, can give 100% certainty of no errors. Yet all these techniques, at some cost, can in fact reduce the errors to whatever level you wish.

In the initial stages i.e when the software industry was in a nascent stage, there was no stress upon software testing. In most of the cases there was just a quick check on the software and then the software was handed over to the client.A thorough testing of application was considered to be huge waste of time and resources.This was basically done so that items in the checklist could just be ticked off and software could be developed and handed over to client as soon as possible.However as time passed the importance of software testing was realized. Now software testing is given as much importance as that of developing a software.The change in trend can be easily explained.

A Study conducted in 2002 by NIST reported that software bugs cost the U.S. economy a loss of atleast 59.5 billion dollars annually.It further reports that more than one third of this cost could have been avoided if better software testing was performed. <ref>http://www.abeacha.com/NIST_press_release_bugs_cost.htm</ref>

It is commonly believed that the earlier a defect is found the cheaper it is to fix it. The following table shows the cost of fixing the defect depending on the stage it was found.For example, if a problem in the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had already been found by the requirements review. With the advent of modern continuous deployment practices and cloud-based services, the cost of re-deployment and maintenance may lessen over time.

{|class="wikitable"
|-
!Cost to fix a defect
!
!Time detected
!
!
!
!
|-
!
!
!Requirements
!Architecture
!Construction
!System test
!Post-release
|-
!Time introduced
!Requirements
!1×
!3x
!5-10x
!10x
!10-100x
|-
!
!Architecture
!-
!1x
!10x
!15x
!25-100x
|-
!
!Construction
!-
!-
!1x
!10x
!10-25x
|}

Another survey by Electric Cloud, the leading provider of software production management (SPM) solutions, conducted in partnership with Osterman Research showed that the majority of software bugs are attributed to poor testing procedures or infrastructure limitations rather than design problems. Additionally, the software test process is generally considered an unpleasant process, with software development professionals rating the use of their companies’ test systems more painful than preparing taxes.
Fifty-eight percent of respondents pointed to problems in the testing process or infrastructure as the cause of their last major bug found in delivered or deployed software, not design defects.

Specifically, the survey highlighted the following:
Completely automated software testing environments are still rare, with just 12 percent of software development organizations using fully automated test systems. Almost 10 percent reported that all testing was done manually.
Forty-six percent of software developers said they do not have time to test as much as they should.
More than a third of developers, 36 percent, said they do not believe their companies perform enough pre-release testing.
Fifty-three percent said their testing is limited by compute resources.<ref>http://www.electric-cloud.com/news/2010-0602.php</ref>
==Importance of Software Testing==
Importance of Software Testing:

The importance of software testing can be explained in brief in the following points.

'''Error Free Software''': Software testing needs to be done thoroughly to deliver an error free software to the client. Even a very minute mistake in the the software can have a disastrous effect for the client. For example a small failure in a banking software can result in a wrong balance and millions of dollars worth loss to the client or customers of the client. So it is of prime importance that the software delivered to the client be bug free and accurate.

'''Variance from the Requirement''': One important factor while building a software is to adhere to the client requirements. if a software is not built in accordance to the requirements then the software becomes useless and redundant for the client.This is a lot of trouble and overhead for the software developing firm also as the requirement was not well understood.The budget fixed for the development of th software can easily go overboard.In such scenarios verification and validation process come into picture. The two most important questions that needs to be answered are “Is the product being built right” and “Is the right product being built”.If the answer is negative to any one of these questions it means that the the product developed has a variance from the client requirements and necessary changes needs to be made before going ahead with further development.

'''Identify Defect and Prevent their Migration''': If a defect is detected in the requirement analysis stage ,then rectifying the defect is a lot easier and cheaper. But if the defect is not identified and carried over to the next phases of software development then it become more difficult to fix the defects,So it is highly recommended that software testing process be started right when the software development starts.

'''Identify Undiscovered Error''': If proper importance is not given to software testing i.e it is not done thoroughly and just a superficial testing is done there is high probability that some of the errors will creep through to the next phase. In such case using different software testing methodologies help in identifying the hidden errors.Exploratory testing is one such method. In such case the tester randomly tests the software for bugs and finds out the error.
Use the Software in Real Time Environment: Testing a software in development and running it in production are two completely different scenarios.When a developer develops a software he tests it only in a development environment. There is high probability that the software will fail miserably in real time environment.

'''Do Away with Developer Bias''': When a person is designated a tester role his prime responsibility is to test the software. The element of bias is removed. For example when we have a developer testing a software in majority of the cases he is going to be biased towards the software. This is because he has developed the software and its natural human instinct to think one’s product is the best. In such scenario many problems will remain unearthed.

'''Provide Confidence in the Software''': Software testing is also used for asserting the confidence on a developed product. There is a huge difference between being an usable product to operable product. When a software is tested time and over again with a huge degree of success then one can easily approve of the quality of the software developed.
<ref>http://www.cbwc-ontario.org/importance-of-software-testing.html</ref>

==Testing Today==
There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:

<h4>The Waterfall model:</h4>
It is one of the most common and earliest structured models for software development.Waterfall models stresses that one should only move to a phase after the completing and perfecting the preceding phase.As a result of this the phases of software development in waterfall model are unique and there is no jumping back and forth between the various stages.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* Requirement analysis: In this phase, software requirements are captured in such a fashion that they can be translated into actual use cases for the system. The requirements can be derived from performance goals, use cases, target deployment, etc.
* System design: In this phase,the interacting components that make up the system are identified, The exposed interfaces and the communication between them,key algorithms and sequence of interaction are defined, In the end of this phase an architecture and design review is conducted to ensure that the design conforms to the previously defined requirements.
* Implementation : This phase is also termed as Coding and unit testing. In this phase,coding is done for the modules that build the system.Code can also be reviewed and functionality of each module individually tested.
* Verification: Also termed as Integration and system testing. In this phase,all the modules in the system are integrated together and tested as a single system for all the use cases.The primary emphasis is upon making sure that all the modules meet the requirements.
* Deployment and maintenance. This is the final phase where the software system is deployed into the production environment. Any errors identified in this phase are corrected and functionality is added/modified to the system based on the updated requirements.

Waterfall model has the following advantages:
* The life cycle can be compartmentalized into various phases which helps in planning the resources and the amount of effort required through the development process.
* Testing is enforced in every stage in the form of unit testing and reviews.During various stages of the lifecycle different form of reviews like design and code reviews and various forms of testing like unit and integration testing are performed.
* After each phase of lifecycle expectations for deliverables can be set.

Waterfall model has the following disadvantages:
* There is no working version of software until its late in the life cycle.So problems can’t be detcted until the system testing phase.Problems are always hard to fix in the latter phases of life cycle.
* Also for a phase to get started the previous phase must be complete.A system design principle cannot start until the requirement analysis phase is complete and the requirements are frozen. So waterfall model cannot accommodate uncertainties that that may persist after a phase is over.This can lead to delays and extended project schedules.

Testing approach:
During the requirements phase the project requirements are completely defined.Simultaneously the test team brainstorms the scope of testing,test strategy and drafts a detailed test plan.

<h4>Incremental or Iterative Development</h4>

The fundamental principle behind incremental or iterative development is to break down the project into small parts. When one iteration is complete a new module is completed or an existing module is improved. The module is then integrated into the structure and finally the structure is then tested as a whole. In the iterative development model a project is usually broken down into 12 iterations of one to four week duration each.Finally the system is tested at the end of each duration and the test feedback is immediately incorporated. Time spent on the successive iterations can be modified on the basis of experience gained from past iterations. So the system grows by incorporating new functions during the development portion of each iteration.Each iteration thus involves adding of new functions during the development phase.testing evolves as the system evolves.
 
 
[[File:Iterative_dev.jpg]]
 
 
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* Each iteraton involved giving feedback about the deliverables,timelines,efforts and so on.SO the overhead is considerably higher.
* It is hard to freeze the requirements as requirements may need change based on feedback and increasing customer demands.This can lead to more number of iterations and thus delay in deliverables.
* An efficient control change mechanism is needed to manage the system changes made during each iteration.

Testing approach:
As soon as iteration is complete the entire system is subjected to testing.The feedback from testing is immediately available and further incorporated into the next cycle.Testing time required for the successive iterations can be reduced based on the experience gained from past iterations.

<h4>Agile Methodology</h4>
Previously Majority of the software development life cycle methodologies could be categorised into either iterative or sequential model like waterfall model does.But as software systems evolved and became more complex both of these models couldn’t efficiently adapt to the significant and continuous number of changes.Agile methodology was developed to solve this issue.It was develoepd to respond to changes quicly and smoothly. The drawback with iterative model was that even though it removed the disadvantage of sequential models it was still based on the waterfall model.In Agile methodology , software is developed in incremental, rapid cycles. Interactions amongst customers, developers and client are emphasized rather than processes and tools. Agile methodology focuses on responding to change rather than extensive planning.
 
 
[[File: Agile_dev.gif]]
 
 
The main differences between agile and traditional methodologies are as follows:
* An incremental method of development is followed rather than the traditional sequential method.There are small incremental releases and each release is based on previous functionality.
* Each release is thoroughly tested and that helps to ensure that the defects are addressed in the next iteration.
* There is more emphasis given on people and their interactions rather than processes and tools.The developers,customers and testers continuously interact with each other.This interaction ensures that the tester us aware of the features being developed during a particular iteration and so can easily identify any sort of discrepancy between the system and the requirements.
* More priority is given to working software rather than detailed documentation. Agile methodologies rely on face-to-face communication and collaboration, with people working in pairs. As there is extensive communication between customers and team members, there is no need for comprehensive requirements document. All agile projects have customers as an integral part of the team.When developers have a query regarding program requirements thy can get it immediately clarified from the customers.

The disadvantage is that a constant client interaction leads to and added time pressure on all stakeholders including the client themselves , software development and test teams .

Testing approach:
Incremental testing approach is followed and thus every release of the project is tested thoroughly.This ensures that any bugs in the system are fixed before the next release.

<h4>Extreme Programming</h4>
Extreme programming<ref>http://xprogramming.com/book/whatisxp</ref> is a form of agile methodology that believes in short development cycles.So rather than designing the whole of the system at the start of the project the preliminary design work is shortened down to solve the simple tasks that have already been identified.The developers have to interact frequently with customers and other developers. A simple task is started and as soon as it is developed customer feedback is taken.The system is delivered to the customer as soon as possible and the requirements are then refined on the basis of customer feedback.So the requirements evolve over a period of time and developers are able to respond to changes quickly.Extreme programming emphasizes on pair programming.This means one developer writes the code for a particular feature and the other developer reviews it. In theory, the driver focuses on the code at hand: the syntax, semantics, and algorithm. The navigator focuses less on that, and more on a level of abstraction higher: the test they are trying to get to pass, the technical task to be delivered next, the time elapsed since all the tests were run, the time elapsed since the last repository commit, and the quality of the overall design. The theory is that pairing results in better designs, fewer bugs, and much better spread of knowledge across a development team, and therefore more functionality per unit time, measured over the long term.
[[File:Extreme_prog.jpg]]

 
Extreme Programming is highly useful in the many situations.

* If a customer doesn't have a clear understanding of the system then the developers can interact continuously with the customer ,deliver small pieces and ask the customer for feedback.Corrective action is then taken.
* If a technology used to develop a system is significantly new and its a completely new platform then frequent test cycles in extreme programing mitigate the risk of incompatibility with other existing systems.
* If you want automated unit and functional tests there may be a need to change system design such that each module can be tested in isolation sing automation. XP(Extreme programming) comes handy in such scenario.

The main advantage of following XP is that customers having a vague software design in mind can go ahead to implement their product. The continuous testing and integration ensures that the software code delivered is of the highest standards.

Testing approach:
Extreme programming follows a test driven development.It is explained in brief in the subsequent section.

==Test Driven Development (TDD)==
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.

Test-driven development is totally non conventional in the sense that instead of writing code first and then testing it, you write the tests first and then write code to make the tests pass. This is done iteratively. Only when one test case passes, the developer moves on to the next test case and writes code to make it pass. This process is continued until all tests pass.

With test-driven development we can even start with an unclear set of requirements and then can discuss with the customer later about new requirements or change in existing requirements. Even if the code is not ready for a particular functionality but the tests are written, it will ensure that the functionality is addressing all the requirements given by the customer and unnecessary functionality is not included. It allows you to build your software step-by-step and then as the requirements become more clear it evolves the system. 
Other advantages of TDD:
* Loosely coupled and highly cohesive code is promoted by Test-driven development because the functionality is evolved in small steps.
* The tests that we write can act as documentation for the final system’s specifications.
* Time for retesting is reduced because of automated testing. So we don’t have to waste time in retesting existing functionality.
* You know exactly what you have to do in order to make a test pass. Your effort can be measured in terms of number of tests passed.
Unit testing is also ensured through Test-driven development. We will still need to all other kinds of testing such as acceptance testing, system integration testing etc.

<h4>Steps in Test-Driven Development</h4>
The following figure shows the steps involved in test-driven development process
<ref>http://msdn.microsoft.com/en-us/library/ff649520.aspx</ref>
 
[[File:TDD.gif]]
 
==Behavior Driven Development (BDD)==
Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed.

While TDD makes sure that the technical quality of software is up to the mark, behavior-driven development makes sure that the needs of the customer are fulfilled. TDD takes care of the verification part i.e. building the thing right, BDD takes care of the validation part i.e. building the right thing.

Building the Right Thing :
BDD ensures that the systems is built according to the requirements of the customer and is delivered on time. By having a common language between the stakeholders and the developers we have less chance of going wrong with implementing the requirements. This common language is defining the requirement in terms of user stories.

Reducing Risk :
If we are adhering to Behavior Driven Development and our focus is to make a test pass than it is highly unlikely that a developer will go off the way and develop something unnecessary.And with a suite of acceptance tests developed in partnership with the stakeholder, the customer can monitor the system throughout its lifecycle.

With BDD we create a common language which is shared by all stakeholders. It is perfect for projects where the requirements are changing rapidly or are not specified well. Also, it is easier to estimate the effort needed to complete the project because it can be divided into small chunks of user stories.

One of the disadvantages with BDD is that it can be very expensive to maintain constant contact with the customer. Another disadvantage is that we may be able to satisfy all the customer requirements but end up with bad software architecture which would hurt later while maintaining the code.
<ref>Aramando, Fox (2012). Engineering Long Lasting Software Pg 153-155. San Francisco: Strawberry Canyon</ref>
<ref>http://my.safaribooksonline.com/book/software-engineering-and-development/software-testing/9781449309718</ref>
<ref>http://bubusdaybook.blogspot.com/2011/08/extreme-programming-in-nutshell.html</ref>

==Cucumber and RSpec==
Using cucumber, we can describe, in plain text, how a software should behave. It executes plain-text functional descriptions as automated tests. Cucumber supports Behavior Driven Development. The tests are written before the code is written and is verified by non technical stakeholders. The production code is then written to make the stories pass.
<ref> https://github.com/cucumber/cucumber/wiki</ref>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
Given I am on the posts index page
When I follow “Add new post”
Then I should be on the Create New Post page
When I fill in “Title” with “Fight Club”
And I fill in “Content” with “The things you own, end up owning you”
And I press “Save Changes”
Then I should be on the posts index page
And I should see “Fight Club”
</pre>

There are six steps to behavior driven development using Cucumber and Rspec<ref>http://cukes.info/</ref>
# Describe behavior in plain text using Cucumber
# Write a step definition in ruby using Rspec
# Run the test and it will fail because the code is not been written yet
# Write code to make the step pass
# Run the test again and see the step pass
# Repeat 2-5 until all steps pass in the behavior
 
[[File:Cucumber.jpg|Cucumber and RSpec loop]]
 
The test driven development loop is also known as Red-Green-Refactor.
<ref>Aramando, Fox (2012). Engineering Long Lasting Software Pg 164-165. San Francisco: Strawberry Canyon</ref>
 
Red step: Run the test and verify that it fails because you haven’t yet implemented the code. 
Green step: Write the simplest possible code that causes this test to pass without breaking any existing tests. 
Refactor step: Refactor the code if there is any scope of refactoring. 

==Conclusion==
BDD and TDD may seem strange at first but once you use it you realize you have been using these techniques in conventional development also, while doing unit testing. Rather than coding first and then debugging the code to find the problem, TDD is much better of way of developing a system in that you can isolate the problem really easily because you whole is divided into features and specs.

If we write code first and then debug, we end up using the same techniques as TDD but less efficiently and less productively. Using TDD, bugs can be spotted quickly and regression testing is easy because all the testing is automated.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

2012-12-10T10:02:17Z

Sparnan: /* Software Process Models */

=Introduction=

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

==Software Process Models==

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

* The spiral model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in [http://en.wikipedia.org/wiki/Information_technology information technology (IT)]. This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w3_sm here]

* The V-model also called as Verification and Validation model is a [http://en.wikipedia.org/wiki/Software_development_process software development process] which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the [http://en.wikipedia.org/wiki/Software_testing_life_cycle testing cycle]. More details can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w4_sa here]

==Testing==

==Agile==
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w5_dp#Agile_Software_Development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

==Scrum==
Scrum is an '''agile development framework''' that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

[[File:Scrum_1.png]]

Scrum framework is briefly explained [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_framework here]

[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.

Fundamental Roles in Scrum practice are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Product Owner]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner ScrumMaster]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Product_Owner Team Member]

There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Daily_Standup_meeting Daily Standup meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_of_Scrums Scrum of Scrums]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Planning_Meeting Sprint Planning Meeting]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint_Retrospective Sprint Retrospective]

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Sprint sprint]. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Scrum_Implementation.28Real_World_Example.29 Here] is a real world example of scrum.

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.

Here are some of the factors which should be considered before selecting the correct scrum tool:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Primary_Factors Primary Factors]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Secondary_Factors Secondary Factors]

Some of the examples of open-source scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilefant.5B6.5D Agilefant]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IceScrum.5B7.5D Ice Scrum]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Agilo.5B8.5D Agilo]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#eXplainPMT.5B9.5D eXplainPMT]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#XPlanner.5B10.5D XPlanner]

Some of the examples of proprietary scrum project management tools are:

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#IBM_Rational_Team_Concert.5B11.5D IBM Rational Team Concert]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#JIRA.5B12.5D JIRA]

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w7_ma#Mingle.5B14.5D Mingle]

==Design Patterns==

A [http://en.wikipedia.org/wiki/Design_Patterns Design Pattern] in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

''"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"'' - Christopher Alexander.

''"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".''

The different types of design patterns can be categorized and listed as below:

1) [http://en.wikipedia.org/wiki/Creational_pattern Creational Pattern], which help create the objects for the user, instead of having the user to instantiate the object.
Some of the creational patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Abstract_Factory Abstract Factory Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w18_as#Builder Builder Pattern]

2) [http://en.wikipedia.org/wiki/Structural_pattern Structural Pattern], which employ interfaces to achieve inheritance to enable objects to obtain new functionality.
Some of the structural patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w16_dp Adapter Design Pattern]

3) [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#Behavioral_Patterns Behavioral Pattern], which are concerned with communication between objects.
Some of the behavioral design patterns in the wiki 2b are:
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w19_is Template Method Pattern]
* [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w21_ap#State_Pattern State Pattern]

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w14_bb#Pattern_Fragility here]

[http://en.wikipedia.org/wiki/Design_elements_and_principles Software design principles] represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w25_nr Law of Demeter]. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

==References==

<references/>

http://en.wikipedia.org/wiki/Design_pattern