Software Development Methodologies

• Agile

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
http://en.wikipedia.org/wiki/Agile_software_development

• Scrum

Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.

Scrum in project management is an agile management process to coordinate teams of approximately six or seven people who can be located anywhere in the world.

The Scrum Methodology is based on the Rugby term for individual groups collaborating together to form a powerful whole.

The scrums (teams) are made up of the Product Owner, the Scrum Master and the team members. The Product Owner is responsible for representing the interest of the client for whom the product is being made. The Scrum Master is the liaison between the team and the Product Owner. The team itself is comprised of a cross-functional mix of personnel, which can include software engineers, programmers, Q/A specialists and the like. While the Scrum Master is responsible for facilitating the team, the team has total control over how they will perform their work.

During the course of the Scrum, a daily meeting will take place to update everyone on each team’s progress

During the meeting, each team member answers three questions:

What have you done since yesterday?
What are you planning to do by tomorrow?
Do you have any problems preventing you from accomplishing your goal?
Advantages of Agile SCRUM

Scrum methodology enables project’s where the business requirements documentation is hard to quantify to be successfully developed.

It is a lightly controlled method which insists on frequent updating of the progress in work through regular meetings. Thus there is clear visibility of the project development.


Like any other agile methodology, this is also iterative in nature. It requires continuous feedback from the user.

Daily meetings make it possible to measure individual productivity. This leads to the improvement in the productivity of each of the team members

It is easier to deliver a quality product in a scheduled time

Agile Scrum can work with any technology/ programming language but is particularly useful for fast moving web 2.0 or new media projects



Disadvantages of Agile SCRUM

It is good for small, fast moving projects as it works well only with small team

http://www.brighthub.com/office/project-management/articles/2042.aspx

• Test-driven development

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standardsTest-driven design (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring
http://www.agiledata.org/essays/tdd.html
http://en.wikipedia.org/wiki/Test-driven_development

TDD vs ATDD
Test-Driven Development is related to, but different from Acceptance Test-Driven Development (ATDD). TDD is primarily a developer’s tool to help create well-written unit of code (function, class, or module) that correctly performs a set of operations. ATDD is a communication tool between the customer, developer, and tester to ensure that the requirements are well-defined. TDD requires test automation. ATDD does not, although automation helps with regression testing. Tests used In TDD can often be derived from ATDD tests, since the code units implement some portion of a requirement. ATDD tests should be readable by the customer. TDD tests do not.
http://en.wikipedia.org/wiki/Test-driven_development

TDD toolbox
-automated testing framework
-mocking framework ;jmock,easymock,mockito
-specialized testing libraries;junit
-acceptance testing framework
-continuous testing;easyb,infinitest
introduction-to-tdd-course-notes.pdf

• Acceptance Test-Driven Development (ATDD)

the practice of expressing functional story requirements as concrete examples or expectations prior to story development. During story development, a collaborative workflow occurs in which: examples written and then automated; granular automated unit tests are developed; and the system code is written and integrated with the rest of the running, tested software. The story is "done"—deemed ready for exploratory and other testing—when these scope-defining automated checks pass
http://janetgregory.blogspot.com/2010/08/atdd-vs-bdd-vs-specification-by-example.html

• Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possibleIn software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.
http://martinfowler.com/articles/continuousIntegration.html
http://en.wikipedia.org/wiki/Continuous_integration

• Pair programming

Pair programming is an agile software development technique in which two programmers work together at one workstation. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator^[1]). The two programmers switch roles frequently.
http://en.wikipedia.org/wiki/Pair_programming

• Behavior Driven Development

Behavior driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project
http://en.wikipedia.org/wiki/Behavior_Driven_Development

Behavior-driven development
In software engineering, behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD)
Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development
http://en.wikipedia.org/wiki/Behavior-driven_development

“BDD's focus is on the discovery of stuff we didn't know about, particularly around the contexts in which scenarios or examples take place. This is where using words like "should" and "behaviour" comes in, rather than "test" - because for most people "test" presupposes that we know what the behaviour ought to be. "Should" lets us ask, "Should it? Really? Is there a context which we're missing in which it behaves differently?"
http://janetgregory.blogspot.com/2010/08/atdd-vs-bdd-vs-specification-by-example.html


Behavior-Driven Development
Test-driven development is rather a paradigm than a process. It describes the cycle of writing a test first, and application code afterwards – followed by an optional refactoring. But it doesn’t make any statements about

    Where do I begin to develop?
    What exactly should I test?
    How should tests be structured and named?

The name test-driven development also caused confusion. How can you test something that’s not there yet?

It was Dan North 1 who noticed all these unsolved questions and came up with a solution: He suggested that instead of writing tests you should think of specifying behavior. Behavior is how the user wants the application to behave.

When your development is Behavior-driven, you always start with the piece of functionality that’s most important to your user. I consider this phase as taking the developer hat off and putting the user hat on. Once you’ve specified the user needs, you put the developer hat back on and implement your specification.

http://blog.codeship.io/2013/04/22/from-tdd-to-bdd.html

• Cucumber

Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.
http://cukes.info/

• JBehave

JBehave is a framework for Behaviour-Driven Development (BDD). BDD is an evolution of test-driven development (TDD) and acceptance-test driven design
jbehave.org

• specflow

Binding Business Requirements to .NET Code
Cucumber for .NET. The open source solution trusted by .NET devs around the world.
https://specflow.org/

• easyb

easyb is a behavior driven development framework for the Java platform. By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation.
Behavior driven development?
Behavior driven development (or BDD) isn't anything new or revolutionary-- it's just an evolutionary offshoot of test driven development, in which the word test is replaced by the word should.
easyb.org

• Feature-driven development

Feature-driven development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance
http://www.nebulon.com/fdd/
http://en.wikipedia.org/wiki/Feature-driven_development

• Object-oriented analysis and design (OOAD)

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

• Kanban

Kanban is a method for developing software products & processes with an emphasis on just-in-time delivery while not overloading the software developers. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see.[1]
Kanban can be divided into two parts:
Kanban - A visual process management system that tells what to produce, when to produce it, and how much to produce.

http://en.wikipedia.org/wiki/Kanban_(development)

• SCRUM vs. Kanban

Now, being such an open methodology, it tends to be adapted depending on the environment. For instance, Toyota defined 6 rules for its process. In fact, you can add all rules of Scrum to Kanban, and still have a sound methodology - with 25 rules!
http://blog.outsystems.com/aboutagility/2010/11/scrum-vs-kanban.html

• Adaptive Software Development 

Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.


ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles
This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.


The word speculate refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it.

Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc.

The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain.[1]

https://en.wikipedia.org/wiki/Adaptive_Software_Development

• Rapid application development (RAD)

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping.
The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.
https://en.wikipedia.org/wiki/Rapid_application_development

• Project Management implies a project manager. This is not the case in terms of Scrum which only recognize three roles: scrum master, developer and product owner.

https://langerman.co.za/agile_pm_harmful/