Agile software modelling

17

Transcript of Agile software modelling

Page 1: Agile software modelling
Page 2: Agile software modelling

Introduction Warning! Agile Current Status Common Agile Practices Criticisms

Page 3: Agile software modelling

Agile software development is a group of software development methodologies that are based on similar principles. Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages team work, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Page 4: Agile software modelling

Practice Leader Agile Development

Senior Contributing Editor, Dr. Dobb’s Journal

Fellow – International Association of Software Architects

Page 5: Agile software modelling

I’m spectacularly blunt at times Many new ideas will be presented Some may not fit well into your existing

environment Some will challenge your existing notions

about software development Some will confirm your unvoiced

suspicions Don’t make any “career-ending moves” Be skeptical but open minded

Page 6: Agile software modelling

Introduction Warning! Agile Current Status

Agile Adoption Rates Project Success Rates

Common Agile Practices Criticisms

Page 7: Agile software modelling

Yes69%

No31%

85% have run multiple agile projects

24% of “No” respondents hope to do Agile this year

Page 8: Agile software modelling

Introduction Warning! Agile Current Status Common Agile Practices

Agile Development Practices Test-Driven Development (TDD) Database Refactoring Working in Priority Order Agile Planning Agile Model Driven Development (AMDD) Agile Documentation

Criticisms

Page 9: Agile software modelling

Regular Delivery of Working Software Only valid measure of progress Provides visible results to stakeholders True earned value, not documentation-based “earned

value” Daily Stakeholder Interaction

On-Site Customer Active Stakeholder Participation Product Owner

Continuous Integration Automatically compile, test, and style check your code Continuous code integration is nice Continuous system integration is nicer

Page 10: Agile software modelling

Add a test

Run the tests

Make a littlechange

Run the tests

[Fail]

[Fail]

[Pass]

[Developmentstops]

[Developmentcontinues]

With TFD you write a single test and then just enough production code to fulfill that test

Test-Driven Development (TDD) = Refactoring + TFD

TDD is a just-in-time (JIT) specification activity

TDD is a continuous confirmatory validation activity

TDD via Customer/Acceptance Tests Specification of requirements

TDD via Developer Tests Specification of design

TDD is also called Behavior Driven Development (BDD)

Page 11: Agile software modelling

A database refactoring is a simple change to a database schema that improves its design while retaining both its behavioral and informational semantics. Examples: Move Column, Rename Table, and Replace Blob With Table.

A database schema includes both structural aspects such as table and view definitions as well as functional aspects such as stored procedures and triggers.

Important: Database refactorings are a subset of schema transformations, but they do not add functionality.

Page 12: Agile software modelling
Page 13: Agile software modelling

Introduction Warning! Agile Current Status Common Agile Practices

Page 14: Agile software modelling

Introduction Warning! Agile Current Status Common Agile Practices Criticism

Page 15: Agile software modelling

Lack of structure and necessary documentation Only works with senior-level developers Incorporates insufficient software design Requires too much cultural change to adopt Can lead to more difficult contractual negotiations Can be very inefficient — if the requirements for one area of

code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.

Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements

Can increase the risk of scope creep due to the lack of detailed requirements documentation

Agile is feature driven, non-functional quality attributes are hard to be placed as user stories

Page 16: Agile software modelling
Page 17: Agile software modelling