8 - Architetture Software - Architecture centric processes
Upcoming SlideShare
Loading in...5
×
 

8 - Architetture Software - Architecture centric processes

on

  • 3,285 views

 

Statistics

Views

Total Views
3,285
Views on SlideShare
3,285
Embed Views
0

Actions

Likes
1
Downloads
85
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    8 - Architetture Software - Architecture centric processes 8 - Architetture Software - Architecture centric processes Presentation Transcript

    • Architecture-centric processes Paolo Ciancarini
    • Agenda  The role of sw architecture in the development process  What is a software development process and how it is described  Traditional vs iterative process models  Characteristics and benefits of architecture-centric sw development  Agile Processes and Architecture
    • The role of architecture in sw lifecycle
    • Short History of Development Methods AGILE e.g. XP (Kent Beck) RUP (Rational) user Incremental, driven, low process RAD Object oriented, (James Martin)iterative, time-boxed, user driven Prototyping, RUP iterative, time-boxed, SPIRAL MODEL user driven RAD WATERFALL (Royce) (Barry Boehm) V-MODEL (Anon) Requirements, design Iterative Spiral Model implementation, Aligns testing to verification & Waterfall maintenance development V-Model Waterfall1960 1970 1980 85 91 98 99
    • Traditional process  Waterfall Requirements Review Design Review Code Review Test Review Deploy
    • Waterfall characteristics   Delays confirmation of critical risk resolutionWaterfall Process   Measures progress by Requirements assessing work-products analysis that are poor predictors Design of time-to-completion Code and unit test Subsystem integration   Delays and aggregates integration and testing System test   Precludes early deployment   Frequently results in major unplanned iterations
    • V Model Level of Detail Requirements AcceptanceLow Elicitation Testing System Analysis Testing Design Integration Testing Object Design Unit Testing High Project Time
    • The spiral modelDetermine objectives, Evaluate alternatives,alternatives, & constraints identify & resolve risks Risk analysis Risk analysis Risk analysis P1 Prototype3 Prototype2 Prototype1 Requirements Concept of plan operation Software System Requirements Product Detailed Design Design Development Requirements plan validation P2 Code Integration Design Unit Test plan validation Develop & verifyPlan next phase next level product Integration & Test Acceptance Test
    • The spiral model: phases  Determine objectives   Each phase has specific objectives  Evaluate alternatives, reduce risks   Each risk has to be identified and managed  Develop and verify   The process model can be generic   Each phase includes development and verification  Plan next phase   Review the project and plan its future
    • Exercise  Name the pros and cons of each of the following software process models   waterfall model   v-model   spiral model  Specifically focus on their ability to solicit and react to customer requirement approval and changes
    • Iterative Development Requirements Analysis & Design Planning Implementation InitialPlanning Management Environment Test Evaluation Deployment Each iteration results in an executable release
    • Iterative process  Iterative Requirements Requirements Requirements Design Design Design Code Code Code Testing Testing Testing Deploy Deploy Deploy Assess Assess Assess Iteration 1 Iteration 2 Iteration 3
    • Waterfall vs. iterative Requirements Requirements Requirements Design Design Design Code Code CodeRequirements Review Testing Testing Testing Deploy Deploy Deploy Design Review Assess Assess Assess Iteration 1 Iteration 2 Iteration 3 Code Review Test Review Deploy
    • Iterative Development  Phase - the time between two major project milestones, during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not into the next phase. A phase includes one or more iterations.  Iteration – a time period in which a number of predefined tasks are performed and results are evaluated to feedback to the next iteration. An iteration results in a release.  Release (external) – a coherent set of completed functionalities (code and other artifacts) that is useful to the stakeholders of the system  Release (internal) - a coherent set of completed functionalities that is used only by the development organization, as part of a milestone, or for a demonstration to users
    • Risk: waterfall vs iterative Waterfall RiskRisk Risk Reduction Iterative Risk Time
    • Test each iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model andImplementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests
    • Original RUP
    • RUP is iterativehttp://www-306.ibm.com/software/rational/sw-library/
    • DiscussionEvaluate the pros and cons of iterative processes
    • Benefits of Iterative DevelopmentA software project evolves in iterations to:   Mitigate risk   Accommodate change   Learn along the way   Improve the quality of the artifacts   Exploit reuse thus increasing productivity
    • Problems with iterative processes  How iterative? How many rounds?  Agile or rigid?  Heavy weight (many rules, practices and documents) vs. lightweight (few rules and practices)  Disciplined vs ad hoc (or chaotic)
    • A storyA pig and a chicken are walking down a road. 
The chicken looks at the pig and says, "Hey, why dontwe open a restaurant?" The pig looks back at thechicken and says, "Good idea, what do you want to callit?" The chicken thinks about it and says, "Why dont wecall it Ham and Eggs?" "I dont think so," says the pig,"Id be committed but youd only be involved."#
    • Committed vs involved  The core roles in development teams are those committed to the project in the process - they are the ones producing the product: product owner, team, project manager  The ancillary roles in teams are those with no formal role and infrequent involvement in the process - and must nonetheless be taken into account
    • The Planning SpectrumSource: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002
    • Agile developments methodsSome agile sw development methods  Dynamic System Development Methodology and RAD (www.dsdm.org, 1995)  Scrum (Sutherland and Schwaber, 1995)  XP - eXtreme Programming (Beck, 1999)  Feature Driven Development (DeLuca, 1999)  Adaptive Sw Development (Highsmith, 2000)  Lean Development (Poppendieck, 2003)  Crystal Clear (Cockburn, 2004)  Agile Unified Process (Ambler, 2005)
    • Agile ethics  www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we prefer the items on the left.  Management can tend to prefer the things on the right over the things on the left
    • Traditional vs agile team
    • Agile development  Agile development uses feedback to make constant adjustments in a highly collaborative environment  There are many agile development methods; most minimize risk by developing software in short amounts of time#  Software developed during one unit of time is referred to as an iteration, which typically lasts from hours or few days#  Each iteration passes through a full software development cycle
    • Agile development: architecture-centric
    • The Generic Agile Lifecycle
    • Agile practices
    • Agile Unified Process
    • Architectural Effort During the Lifecycle Inception Elaboration Construction Transition time Majority of architectural design activities
    • Little dedicated architectural effort Inception Construction Transition time Minimal pure Ideal realm of agile Architectural practices Activities
    • Iterations and Phases Inception Elaboration Construction Transition Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration Internal Releases with Releases with main focus on architecture focus on features An architectural iteration focuses on major architectural elements,resulting in a baseline architectural prototype at the end of elaboration
    • SCRUM Daily Scrum Meeting: 15 minutes Team-Level Each teams member answers 3 questions: 1) What did I do since last meeting? Planning Every 24hrs 2) What obstacles are in my way? 3) What will I do before next meeting? Every Iteration 4-6 weeks Working Software Prioritised Delivered Iteration Scope RequirementsRequirements Prioritised Requirements & Requirements Features Backlog Requirements Requirements Applying Agile: Continuous integration; continuously monitored progress
    • Agile: eXtreme ProgrammingThe ethic values of eXtreme Programming  Communication  Simplicity  Feedback  Courage  Respect (added in the latest version)
    • eXtreme Programming (XP)  “Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage” Kent Beck  Proponents of XP and agile methodologies regard ongoing changes to requirements as a natural and desirable aspect of sw projects  They believe that adaptability to changing requirements at any point during the lifecycle is a better approach than attempting to define all requiremenmts at the beginning and then expending effort to control changes to the requirements ! ! !www.extremeprogramming.org!
    • The 12 Practices of XP1.  Metaphor2.  Release Planning3.  Testing4.  Pair Programming5.  Refactoring6.  Simple Design7.  Collective Code Ownership8.  Continuous Integration9.  On-site Customer10.  Small Releases11.  40-Hour Work Week12.  Coding Standards
    • Metaphor  Programmers define a handful of classes and patterns that shape the core business problem and solution, like a primitive architecture  Gives the team a consistent picture of describing the system, where new parts fit, etc.  Example: payroll . . . The paycheck goes down an assembly line and pieces of information are added  Sometimes, you just can’t come up with a metaphor
    • Exercise  Find other useful metaphors
    • Release Planning•  Requirements via User Stories •  Short (index-card length) natural language description of what a customer wants •  A commitment for further conversation •  Prioritized by customer •  Resource and risk estimated by developers•  “The Planning Game” •  Highest priority, highest risk user stories included in early “time boxed” increments•  Play the Planning Game after each increment
    • User stories: examplesGood:  A user can post her cv  A user can search for jobs  A company can post new job openings  A user can limit who can see her resumeBad:  The software will be written in C++  The program will connect to the database through a connection pool
    • User story: example
    • User story testing: example
    • Testing  Test-Driven Development (TDD)   Write tests before code   Tests are automated   Often use xUnit framework   Must run at 100% before proceeding  Acceptance Tests   Written with the customer   Act as “contract”   Measure of progress
    • Pair Programming•  Two software engineers work on one task at one computer•  One engineer, the driver, has control of the keyboard and mouse and creates the implementation•  The other engineer, the navigator, watches the driver’s implementation to identify defects and participates in on-demand brainstorming•  The roles of driver and observer are periodically rotated between the two software engineers
    • Simple Design•  No Big Design Up Front (BDUF)•  “Do The Simplest Thing That Could Possibly Work” •  Including documentation•  “You Aren’t Gonna Need It” (YAGNI)•  CRC cards (optional)
    • Refactoring Refactoring: as you write code, there are times when you need to change its structure - usually to conform to a pattern, to facilitate extensibility, or just because your code got long and messy Improve the design of existing code without changing functionality   Simplify code, remove duplicate code   Search actively all opportunity for abstraction Relies on testing to ensure nothing breaks in the process of refactoring
    • Collective Code Ownership  Code to belongs to the project, not to an individual engineer  As engineers develop required functionality, they may browse into and modify any class
    • Continuous Integration  Each pair writes up its own unit test cases and code for a task (part of a user story)  Pair tests units of code to 100%  Pair integrates  Pair runs ALL integrated unit test cases to 100%  Pair moves on to next task with clean slate and clear mind  Should happen once or twice a day; prevents “Integration Hell”
    • On-Site Customer  Customer available on site to clarify stories and to make critical business decisions  Developers don’t make assumptions  Developers don’t have to wait for decisions  Face to face communication minimizes the chances of misunderstanding
    • Small Releases•  Timeboxed•  As small as possible, but still delivering business value •  No releases to ‘implement the database’•  Get customer feedback early and often Do the planning game after each iteration •  Do they want something different? •  Have their priorities changed?
    • 40h work per week (sustainable pace)•  Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every night”•  Burning the midnight oil kills performance•  Tired programmers write poor code and make more mistakes, which slows you down more in the long run•  If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences
    • Coding standards and conventions  Use Coding Conventions   Considering Pair Programming, Refactor Mercilessly, and Collective Code Ownership . . . need to easily find your way around (other people’s) code  Method Commenting   Priority placed on intention-revealing code   If your code needs a comment to explain it, rewrite it   If you cant explain your code with a comment, rewrite it
    • The 13th Practice: The Stand Up MeetingStart day with 15-minute meeting •  Everyone stands up (so the meeting stays short) in circle •  Going around the room everyone says specifically: •  What they did the day before •  What they plan to do today •  Any obstacles they are experiencing •  Can be the way pairs are formed
    • Research findings on XP  Strong anecdotal evidence from industry   “We can produce near defect-free code in less than half the time.”  Empirical Study   Pairs produced higher quality code   15% more test cases passed (difference statistically significant)   Pairs completed their tasks in about half the time   58% of elapsed time (difference not statistically significant)   Most programmers reluctantly embark on pair programming   Pairs enjoy their work more (92%)   Pairs feel more confident in their work products (96%)
    • Agile Misconceptions  Agile means: “letting the programming team do whatever they need to with no project management, and no architecture, allowing a solution to emerge, the programmers will do all the testing necessary with Unit Tests…”
    • Process control variables  Time – duration of the project  Quality – the requirements for ‘correctness’  Resources – personnel, equipment, etc.  Scope – what is to be done; the features to be implemented  These process control variables are very difficult to control all; the simplest and most effective to control is scope
    • Self-test questions  What are the advantages of an iterative process?  What is an agile process?  Which are the potential problems and risks with user involvement?  What is the planning game?  What is a user story?  What are the major best practices in XP?
    • References  Ambler, Agile Modern Driven Development with UML2 (The Object Primer 3ed.), Cambridge Univ. Press, 2004  Beck and Fowler, Planning Extreme Programming, Addison Wesley, 2000  Cockburn, Agile Software Development, 2000  Larman, Agile and Iterative Development: a managers’ guide, Addison Wesley, 2003  Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004  Shore and Warden, The Art of Agile Development, O’Reilly, 2007
    • Useful sites  www.agilemanifesto.org!  www.agilemodeling.com!  www.agilejournal.com!  www.agilealliance.org!  www.agilekiwi.com!  www.extremeprogramming.org!  www.controlchaos.com!  www.implementingscrum.com!
    • Questions?