Agile Model Driven Development (AMDD)

8/6/2019 Agile Model Driven Development (AMDD)

http://slidepdf.com/reader/full/agile-model-driven-development-amdd 1/55

Agile Model DrivenDevelopment(AMDD)



S oftware Development Life Cycle

(S

DLC)It is developing a computer systemIt concerns a process which takes from two months

to two yearsThis is called a system development life cycle

S ystem Development MethodologyS tandard process followed in an organization toconduct all the steps necessary to analyze, design,implement and maintain information systems.

Traditional methodology for developing, maintaining,and replacing information systems



P roject P hases



P otential Deliverables by P hase



R equirements

Inputs:SOW

,P

roposalO utputs:R equirements Document ( R D)

R equirements S pecification Document ( RS D)S oftware R equirements S pecification ( SRS )

1 st P roject Baseline

The ³ W hat´ phaseS oftware P roject Management P lan ( SP MP )R equirements Approval & S ign- O ff

Your most difficult task in this phaseP erhaps most important & difficult phaseS hortchanging it is a µclassic mistake¶ Can begin with a P roject Kickoff MeetingCan end with a S oftware R equirements R eview ( SRR )

For S ponsor and/or customer(s) approval



W hy are R equirements so

Important?



R equirementsCharacteristics & Issues

Conflict of interest: developer vs. customerP otential tug-of-war:

Disagreement on Features & EstimatesEspecially in fixed-price contracts

Frequent requirements changesAchieving sign-off

P roject planning occurs in parallelR equirements are capabilities and conditionto which the system ± more broadly, theproject ± must conform



R equirements

O ther ways of categorizingGo-Ahead vs. Catch-up

R elative to competition

Backward-looking vs. Forward-lookingBackward: address issues with previous versionForward: Anticipating future needs of customers

Must be prioritizedMust-haveS hould-haveCould-have (Nice-to-have: NT H )

Must be approved



Analysis & DesignThe ³ H ow´ P hasesInputs: R equirements DocumentO utputs:

Functional S pecificationDetailed Design DocumentUser Interface S pecificationData ModelP rototype (can also be done with requirements)

Updated P lan (improved estimates; newbaseline)Continues process from R D



Analysis & DesignEnds with Critical Design R eview (CD R )

Formal sign-off Can also include earlier P reliminary Design R eview( P DR ) for high level design

Characteristics & IssuesEnthusiasm via momentumTeam structure and assignments finalizedDelays due to requirements changes, newinformation or late ideasIssues around personnel responsibilitiesUnfeasible requirements (technical complexity)R esource Issues

Including inter-project contention



DevelopmentThe ³Do It´ phaseCoding & Unit testingO ften overlaps Design & Integration phases

To shorten the overall scheduleP M needs to coordinate thisO ther concurrent activities

Design completionIntegration begins

Unit testing of individual componentsTest bed setup (environment and tools)P roject plans updatedS cope and R isk Management conducted



DevelopmentCharacteristics

P ressure increasesS taffing at highest levelsO ften a ³heads-down´ operation

IssuesLast-minute changesTeam coordination (esp. in large projects)Communication overheadManagement of sub-contractors



Integration & TestEvolves from Dev. P haseO ften done as 2 parallel phases

P artial integration & initial testS tarts with integration of modulesAn initial, incomplete version constructedP rogressively add more componentsIntegration primarily a programmer taskTest primarily a QA team taskIntegration:

Top-down: Core functionality first, empty shells forincomplete routines (stubs)Bottom up: gradually bind low-level modulesP refer top-down generally



Integration & TestTests

Integration testingBlack & W hite-box testingLoad & S tress testingAlpha & Beta testing

Acceptance testingO ther activitiesFinal budgeting; risk mgmt.; training; installation preparation; teamreduced

Characteristics & IssuesIncreased pressureO vertimeCustomer conflicts over featuresFrustration over last-minute failuresBudget overrunsMotivation problems (such as burnout)Difficulty in customer acceptance

Esp. true for fixed-price contracts



Deployment & MaintenanceInstallation depends on system typeW eb-based, CD- RO M, in-house, etc.

Migration strategy

H ow to get customers up on the systemP arallel operation

Deployment typically in your project plan, maintenance not

MaintenanceFix defectsAdd new featuresImprove performance

Configuration control is very important hereDocuments need to be maintained alsoS ometimes a single team maintains multiple products



Deployment & MaintenanceCharacteristics & Issues

Lack of enthusiasmP ressure for quick fixesInsufficient budgetToo many patches

P ersonnel turnoverR egression testing is criticalP referably through automated tools



LifecycleP

lanningLifecycle Management or S DLC

Greatly influences your chance of successNot choosing a lifecycle is a bad optionThree primary lifecycle model components

P hases and their orderIntermediate products of each phaseR eviews used in each phase

Different projects require different approachesYou do not need to know all models by nameYou should know how that if given a certain scenario what sort of S DLC would be appropriateThere are more than covered hereA lifecycle is not a design, modeling or diagramming technique

The same technique (UML, DFD, etc) can be used with multiplelifecycles



Pure

Waterfall

The ³granddaddy´ of modelsLinear sequence of phases

³ P ure´ model: no phases overlap

Document drivenAll planning done up-frontW orks well for projects with

S table product definitionW ell-understood technologies

Quality constraints stronger than cost & scheduleTechnically weak staff P rovides structureGood for overseas projects



W aterfall

Follows the ³classic´ S DLC:R equirements Analysis, Design,Coding, Testing, O perations.Great for managing projects andcontrolling clients, lousy foractually building software.

Assumes you can identify andagree on requirements that won¶tchange.Doesn¶t find problems until late inthe game when they¶re verydifficult and expensive to fix.S ets up a very specific set of expectations around creation of artifacts (and getting paid!).



Disadvantages of W

aterfall

Not flexibleR

igid march from start->finishDifficult to fully define requirements upfrontCan produce excessive documentation

Few visible signs of progress until theend



SpiralEmphasizes risk analysis & mgmt. ineach phaseA S eries of Mini-projectsEach addresses a set of ³risks´

S tart small, explore risks, prototype,plan, repeat

Early iterations are ³cheapest´ Number of spirals is variable

Last set of steps are waterfall-like



Iterative: S piral

Concurrent rather thansequential determination of artifactsR eview of objectives,constraints, alternatives, and

risk with commitment toproceedLevel of effort driven by riskconsiderations

Degree of detail driven byrisk considerations

Use of LC O , LCA, I O C anchorpoint milestonesEmphasis on system andlifecycle activities



SpiralAdvantages

Can be combined with other modelsAs costs increase, risks decreaseR isk orientation provides early warnin

DisadvantagesMore complexR equires more management



P rototyping

Iterative development process:R equirements quickly converted to a working systemSystem is continually revisedClose collaboration between users and analysts



P rototyping Model

Advantages: :Good when input/output requirements and userinterface not clear initially

Good for development of ³visible´ parts of the systemFosters communication with customers and usersH elps identify and refine requirements

D isadvantages:

False expectations: customer sees what appears tobe a working productNot good for ³invisible´ aspects of systemEarly unfinished prototypes may perpetuatethemselves



Iterative Model



A nalysis

Design

Programming

Testing,etc.

CoreProduct

A nalysis

Design

Programming

Testing,etc.

A nalysis

Design

Programming

Testing,etc.

Increment 1

Increment 2

Etc.

Integration +R egressionTesting

Th e IncrementalModel

(Linear S equential)



Incremental ModelAdvantages:

Core functionality can be provided quickly

Increments can be planned to manage technical risks(e.g., increment, evaluate, increment, evaluate, etc.)

D isadvanges:

Takes a long time to finish entire systemLater increments may never get done



V P rocess Model



V P

rocess ModelDesigned for testability

Emphasizes V erification & V alidationV ariation of waterfallS trengths

Encourages V & V at all phasesW eaknesses

Does not handle iterations

Changes can be more difficult to handleGood choice for systems that require highreliability such as patient control systems



R apid Application Development( R AD)

Methodology to decrease design andimplementation timeInvolves: prototyping, JAD, CA S E tools, and

code generators



Commercial O ff-The- S helf software(C O TS )

Build-vs.-buy decisionAdvantages

Available immediatelyP otentially lower cost

DisadvantagesNot as tailored to your requirements

R emember: custom software rarelymeets its ideal (so compare thatreality to C O TS option)



Agile Modeling (AM)AM is a chaordic, practices-based process formodeling and documentationAM is a collection of practices based on severalvalues and proven software engineering principlesAM is a light-weight approach for enhancingmodeling and documentation efforts for othersoftware processes such as X P and R UP



eXtreme P rogramming



R ational Unified P rocessR UP

From R ational Corporation ³Generic´ version is the Unified P rocessCommercialExtensive tool support (expensive)O bject-orientedIncrementalNewerDevelop IterativelyManage R equirementsUses UML (Unified Modeling Language)P roduces ³artifacts´ Use component-based architectureV isually model softwareComplex processA ³framework´ S uitable for large scale systems



Elaboration

ConstructionInception

Transition

11

22 33

44

R ational Unified Approach - R UP



phases of the EU P



Iterative: R ational Unified P rocess

Use case-driven, architecture-centric, iterative: tackles risk earlyP hases:

Inception: S cope; Go/No-GoElaboration: Test thearchitectureConstruction: Build the rest

Transition: Tune and handoff

50% done = 50% builtDifferent approach to projectmanagement: challenge to controliterative, incremental development

Prob em

So

ut

on



R UP : Key CharacteristicsIterative: Consistent, improvable, insightful, tangible, measurable

Use case-driven: W hat is the context, who are the actors, how dothey interact with the system, and what observable value do theyderive? For each interaction, what¶s the happy path and what are thealternate paths?

Architecture-centric: W hat are the structural elements and how arethey interfaced? W hat behaviors must result from their interactions?H ow do these structural and behavioral elements fit into the overallsystems context?

time

R

D

C

T

R

D

C

T

R

D

C

T

R

D

C

T

R

D

C

T



Agile Model Driven Development(AMDD) P roject Level



W hat Are Agile Models?Agile models:

Fulfill their purposeAre understandableAre sufficiently

accurateAre sufficientlyconsistentAre sufficientlydetailedP rovide positive value

Are as simple aspossibleAgile models are justbarely enough!



Agile DocumentationTravel light ± You need far less documentation than you think Agile documents:

Maximize stakeholder investmentAre conciseFulfill a purposeDescribe information that is less likely to changeDescribe ³good things to know´Have a specific customer and facilitate the work efforts of that customer Are sufficiently accurate, consistent, and detailedAre sufficiently indexed

V alid reasons to document:Your project stakeholders require itTo define a contract modelTo support communication with an external groupTo think something through



Communication Modes

C o m

m u n

i c a

t i o n

E f f e c t i v e n e s s

Richness of Communication ChannelCold Hot

Paper

Audiotape

Videotape

Emailconversation

Phoneconversation

Videoconversation

Face-to-faceconversation

Face-to-faceat whiteboard

DocumentationOptions

ModelingOptions



N

v

r45%

R ¡ r

¢

y19%

Som t £ m ¤

16%

Oft n13%

A¢

w ¡ y ¤

7%

The Cost of Traditional B R UF ³ S uccessful´ P rojects S till H ave S ignificant W aste



AMDD ± S imple Approach



Agile Methods

eXtreme P rogramming (X P )S CR UM

Dynamic S ystems DevelopmentMethod (D S DM)Feature Driven Development (FDD)

AdaptiveS

oftware DevelopmentCrystal« and many more !



Generic Agile P rocess



AMDD ± CA S E Approach



AMDD ± Enterprise Level



Agile S oftware R equirementsManagement

Agile Model Driven Development (AMDD)

Documents

Transcript of Agile Model Driven Development (AMDD)