Agile Modelling in Software Engineering

15
Agile Modelling in Agile Modelling in Software Software Engineering Engineering Audrey Nemeth, Audrey Nemeth, Vladimir Vladimir Borisov Borisov

description

Agile Modelling in Software Engineering. Audrey Nemeth, Vladimir Borisov. AM Values. Communication Simplicity Feedback Courage Humility Source: http://www.agilemodeling.com/values.htm. AM Principles. Assume Simplicity Embrace Change Enabling the Next Effort is Your Secondary Goal - PowerPoint PPT Presentation

Transcript of Agile Modelling in Software Engineering

Page 1: Agile Modelling in Software Engineering

Agile Modelling in Agile Modelling in Software Software

EngineeringEngineering

Audrey Nemeth, Audrey Nemeth, Vladimir Vladimir BorisovBorisov

Page 2: Agile Modelling in Software Engineering

AM AM ValuesValues

•CommunicationCommunication•Simplicity Simplicity •FeedbackFeedback•CourageCourage•HumilityHumility

Source: Source: http://www.agilemodeling.com/values.htmhttp://www.agilemodeling.com/values.htm

Page 3: Agile Modelling in Software Engineering

AM AM PrinciplesPrinciples

• Assume SimplicityAssume Simplicity• Embrace Change Embrace Change • Enabling the Next Effort is Your Enabling the Next Effort is Your

Secondary GoalSecondary Goal• Incremental ChangeIncremental Change• Maximize Stakeholder InvestmentMaximize Stakeholder Investment

Source: http://www.agilemodeling.com/principles.htmSource: http://www.agilemodeling.com/principles.htm

Page 4: Agile Modelling in Software Engineering

AM AM PrinciplesPrinciples

• Model With a PurposeModel With a Purpose• Multiple Models Multiple Models • Quality WorkQuality Work• Rapid FeedbackRapid Feedback• Software Is Your Primary GoalSoftware Is Your Primary Goal• Travel LightTravel Light

Page 5: Agile Modelling in Software Engineering

AM AM PrinciplesPrinciples

• Content is More Important Than Content is More Important Than RepresentationRepresentation

• Open and Honest CommunicationOpen and Honest Communication

(Supplementary)

Page 6: Agile Modelling in Software Engineering

AM AM PracticesPractices

• Active Stakeholder ParticipationActive Stakeholder Participation• Apply the Right Artifact(s)Apply the Right Artifact(s)• Collective OwnershipCollective Ownership• Create Several Models in ParallelCreate Several Models in Parallel• Create Simple ContentCreate Simple Content• Depict Models SimplyDepict Models Simply

Source: http://www.agilemodeling.com/practices.htm Source: http://www.agilemodeling.com/practices.htm

Page 7: Agile Modelling in Software Engineering

AM AM PracticesPractices

• Display Models PubliclyDisplay Models Publicly• Iterate to Another ArtifactIterate to Another Artifact• Model in Small IncrementsModel in Small Increments• Model With OthersModel With Others• Prove it With CodeProve it With Code• Single Source InformationSingle Source Information• Use the Simplest Tools Use the Simplest Tools

Page 8: Agile Modelling in Software Engineering

How AM Practices Fit How AM Practices Fit TogetherTogether

Source: http://www.agilemodeling.com/essays/practicesFitTogether.htm

Page 9: Agile Modelling in Software Engineering

What is AM used forWhat is AM used for??

• You are taking an agile approach to You are taking an agile approach to development in generaldevelopment in general

• You plan to work iteratively and incrementallyYou plan to work iteratively and incrementally• The requirements are uncertain or volatileThe requirements are uncertain or volatile• The primary goal is to develop softwareThe primary goal is to develop software• The active stakeholders are supportive and The active stakeholders are supportive and

involvedinvolved• The development team is in control of its destinyThe development team is in control of its destiny• The developers are responsible and motivatedThe developers are responsible and motivated• Adequate resources are available for the projectAdequate resources are available for the project

Page 10: Agile Modelling in Software Engineering

AM in Software AM in Software Development ProjectsDevelopment Projects

AM is meant to be tailored into other, AM is meant to be tailored into other, full-fledged methodologies, enabling full-fledged methodologies, enabling you to develop a software process you to develop a software process which truly meets your needs.which truly meets your needs.

Page 11: Agile Modelling in Software Engineering

Agile Model Driven Agile Model Driven DevelopmentDevelopment

Page 12: Agile Modelling in Software Engineering

AM in eXtreme AM in eXtreme ProgrammingProgramming

The three most common misconceptions are that The three most common misconceptions are that software designers:software designers:

• don’t modeldon’t model• don’t documentdon’t document• if they do model, only use modeling artifacts of if they do model, only use modeling artifacts of

UMLUML

www.extimeprogramming.com

Page 13: Agile Modelling in Software Engineering

AM in Unified ProcessAM in Unified Process

In the RUP there are three disciplines that encompass modeling In the RUP there are three disciplines that encompass modeling activities for a single project – Business Modeling, Requirements, activities for a single project – Business Modeling, Requirements, and Analysis & Designand Analysis & Design – and the EUP adds Enterprise – and the EUP adds Enterprise Business Modeling and Enterprise ArchitectureBusiness Modeling and Enterprise Architecture

Page 14: Agile Modelling in Software Engineering

AM in Feature-Driven AM in Feature-Driven DevelopmentDevelopment

Page 15: Agile Modelling in Software Engineering

How to Save TimeHow to Save Time

• in Modellingin Modelling – Design models that are just barely good enoughDesign models that are just barely good enough – For a given model, use the simplest toolFor a given model, use the simplest tool– Effective developers make use of multiple modelsEffective developers make use of multiple models

• in Documentationin Documentation– Unit tests form much of the detailed design Unit tests form much of the detailed design

documentationdocumentation – When dealing with a part of the software that is When dealing with a part of the software that is

really complicated, either document it thoroughly really complicated, either document it thoroughly or redesign it to make it simpleror redesign it to make it simpler