Downloaded 15 times
![Types of Requirements FUNCTIONAL REQUIREMENTS Describe what the system is supposed to do “Features”, as succinct as a user story, or as specific as a SBI The system shall do … [give clean/detected, give category, give source] NON-FUNCTIONAL REQUIREMENTS Describe what the system is supposed to be “Qualities” of a system, ex. guarantees SLA of 99.999%, open-source, usable The system shall be … [99.999% SLA, scalable, releasing monthly]](https://image.slidesharecdn.com/agilearchitecture-upload-150430044339-conversion-gate02/75/Agile-architecture-upload-21-2048.jpg)
![[Agile] Design principles Reduce coupling Design for flexibility Anticipate change](https://image.slidesharecdn.com/agilearchitecture-upload-150430044339-conversion-gate02/75/Agile-architecture-upload-27-2048.jpg)
Uploaded byThe Real Dyl
Agile architecture upload
This document provides an outline for an agile software architecture workshop. It begins by defining software architecture and describing key concepts like requirements, design principles, and architectural patterns. It emphasizes that architecture should enable agility by traveling light with just enough design. The document proposes techniques for agile architecture like architectural katas, risk analysis, and evolving the architecture over time with experiments. It concludes by providing an example architectural pitch for a restaurant ordering system that emphasizes high-level design, risks, and timelines.
Agile architecture upload
- 1.
- 2. Outline What is softwarearchitecture? Designing software architectures Communicating architecture Agile software architecture Workshop
- 3. As juniors, pulltogether something new. As seniors, practice new solutions and architectures. As operations, create a deeper understanding and define a common language with our engineers. This is for us devops team.
- 5.
- 6.
- 7.
- 8. Software architecture isbasically the structure of your code. How you define the variables to be used and how you group them in to classes in such a way that your code will be readable to any audience or programmer. Common Conceptions
- 9. It is theoverall design of the System or Product we are developing. This does not only include the System Design, meaning the form of the code of the product, but also all the tools and the processes that will help complete the product or system. Common Conceptions
- 10. Software Architecture As anoun: Structure, interaction of components, foundations, infrastructure, solutions, eagle’s eye view
- 11. Software Architecture As averb: Creating a vision and making design decisions Requirements drive architecture
- 12. Software architecture, besidescode https://leanpub.com/software-architecture-for-developers/read Logging and exception handling Security; non- repudiation, integrity SLO Audit and other regulatory requirements. Sociability with other software systems. Operational requirements Consistency of structure VISION Design choices
- 13. It is notbig design up front A 1k-length book on diagrams and articles is really sad.
- 14. We can havelightweight architecture for agile teams. Good architecture enables agility.
- 15. The software architectis a leader. Leads by building consensus, particularly in the form of competing design requirements. It is up to the architect to make good solid judgement calls. Kartik Ayyar’s answer in Quora.com
- 16. From Simon Brown’sSoftware Architecture for Developers
- 17. Software Architecture as Design FUNCTIONALAND NON-FUNCTIONAL REQUIREMENTS EXPLORING THE DESIGN SPACE
- 18. Big Ball ofMud “… is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle… These systems show unmistakable signs of unregulated growth, and repeated, expedient repair… The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition.” http://www.laputan.org/mud/
- 19. Requirements Engineering Process ofestablishing the services that the customer requires from a system and the constraints under which it operates and is developed.
- 20. Examples of Requirements Userrequirements: The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements: On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. The system shall automatically generate the report for printing after 17.30 on the last working day of the month. A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. Access to all cost reports shall be restricted to authorized users listed on a management access control list
- 21. Types of Requirements FUNCTIONALREQUIREMENTS Describe what the system is supposed to do “Features”, as succinct as a user story, or as specific as a SBI The system shall do … [give clean/detected, give category, give source] NON-FUNCTIONAL REQUIREMENTS Describe what the system is supposed to be “Qualities” of a system, ex. guarantees SLA of 99.999%, open-source, usable The system shall be … [99.999% SLA, scalable, releasing monthly]
- 22. Examples of Non-FunctionalRequirements
- 23. Performance and SpaceRequirements CAN BE SPECIFIED AT THE O-NOTATION (HIGHLY DETAILED) CAN BE SPECIFIED VIA SLO AND GIGABYTES REQUIRED (JUST RIGHT)
- 24. And my personalfavorite… Agility Anticipating future improvements, mitigating risk, creating a feedback loop But more on that later.
- 25. Exploring the designspace The space of possible designs. This is a good design exercise for the team!
- 26. Sample exploration Parallel Messaging SeriesMessaging Distributed Database Data in Message MongoDB MySQL Cluster Other NoSQL DB
- 27. [Agile] Design principles Reducecoupling Design for flexibility Anticipate change
- 28. Some architectural patterns Multilayers Pipeand filters Message oriented Microservices
- 29. Pipe and Filters Littlecomponents “decorating” the output one at a time Swap components and none will be the wiser http://www.site.uottawa.ca/school/research/lloseng/
- 30. Microservices Divide into “small”,reliable interfaces and mash together to produce interesting results “Fail easy, fail fast”
- 31.
- 32. Understanding design is communicatingdesign. Focus on the communication of the solution rather than the solution itself “Sadly, we as an industry has a failure to communicate.” –Simon Brown
- 33. Who uses UML? Sketchesare good enough, right? Right? Due to the nature of our team, we don’t actually need to visualize the design to other people. Hence no need for UML. Although I agree that UML is useful for designing, I think prototyping is a faster design tool.
- 34. Moving fast needsfast communication. (next slides from Simon Brown’s Software Architecture for Developers)
- 35.
- 36.
- 37.
- 38. Choose your ownadventure
- 39. Should have useda whiteboard
- 40.
- 42. Good sketches facilitategood discussions. Titles Short and meaningful Lines Clear relationships, color coded or has notes if necessary Layout You can use sticky notes instead. Color Add in legends if needed. Description Add in a short description if the component is sufficiently complex. Cohesion Things that are alike should be seen together, like databases.
- 43. C4 Diagrams It’s typicallydifficult to show everything in one go. Overview first, zoom in. Diagrams are to help the audience navigate.
- 44. A software systemis made up of containers each of which contains one or more components which in turn are implemented by one or more classes.
- 45. Context What are webuilding? Who is it for? How does it coexist with others in the IT ecosystem?
- 46. Containers What are thehigh level tech decisions? How do the containers communicate with each other? Where do the different workgroups work on?
- 47. Components What are themost important components and how is it done?
- 48. Other ITIL-esque processescan then follow
- 49.
- 50. Agility? Moving fast,embracing change, releasing often, getting feedback. Unfortunately, not all agile teams build software that is agile.
- 51. Observation – Orientation– Decision – Action Loop Faster than the adversary. http://www.dnipogo.org/fcs/pdf/adolph_2006_agile%20lessons_final.pdf
- 52. Good architecture enablesagility. “Base your architecture on requirements, travel light and prove your architecture with concrete experiments.” - Scott Ambler
- 53. Travelling Light –Just enough TOO LITTLE No common understanding where the system boundaries are. Inability to do the elevator pitch. No thoughts on the non-functional requirements. No thoughts on the risks involved. TOO MUCH Unnecessary detail in long documents Writing code or pseudo-code. No flexibility with the design choices. Analysis paralysis.
- 54. Just Enough Architecture FirmFoundations Structure Understand the different elements and their relationships based on the requirements. ------------ Team discussions Vision Create and communicate the “big picture” ----------------- C4 Diagrams, Use Case diagrams, Entity Diagrams Risks Identify and mitigate the biggest risks. --------------- Risk-storming, documentation and experimentation
- 55. Risk Consequences of actionstaken in the face of uncertainty. Time and human resource constraints Technology choice Process workflow Customer satisfaction A risk is a known problem beforehand. Risks should have mitigation plans. If you ignore risks, more likely you’ll encounter lots of problems.
- 56. Architecture is nota relay sport. Architecture evolves. Somebody should own it, and change it as uncertainties are cleared. Do experiments and live feedback throughout the project lifetime. Technical leadership and coaching is needed on all stages of the project.
- 57. Discuss what softwarearchitecture is. Include architecture in retrospectives. Practice.
- 58. Architectural Kata 30-45 minutesof planning, 10 minutes of presentation Prove to the others your solution works Any tech, can make assumptions, no all-star team Constructive criticisms only! I am the sales guy
- 59. Deliverables High level descriptionand architecture – the elevator pitch Non-functional requirements and their solutions Use Case Diagrams and their respective 4C Diagrams (until the components only) ◦ (Include the technology choices!) Soft PBI timelines – dates of feature deliveries
- 60. GRID Food Network APhilippine restaurant food chain wants to enable orders through the Internet. Users: millions+, 99.999% SLA (~8 hours, 45 minutes of downtime a year) Requirements: Users will place their order, then be given a time to pick up their order and directions to the shop which must integrate with Google Maps; If the shop offers a delivery service, dispatch the driver with the order to the user; Mobile-device accessibility; Occasionally offer national promotionals/specials through Facebook, Twitter and Zomato API; Daily offers of local promotionals/specials with Foursquare. Accept payment online or in person/on delivery Integrate with the company’s customer relationship management (loyalty cards) by sending it all customer data with their orders Integrate with the company’s supply chain management system by sending it all orders from all branches
- 61. References Software Architecture forDevelopers - https://leanpub.com/software-architecture-for-developers/read Lecture slides accompanying the book: Object-Oriented Software Engineering: Practical Software Development using UML and Java http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/LlosengCh09E2.ppt Assorted slides from CS 260, Advanced Software Engineering, in UP Diliman Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
Editor's Notes
- #13 Security – important for Facebook, or social networks with connection to third party apps Audit – very important to banks, stock exchanges (jumping from currency to another) Operational, support and maintenance – Flight systems are really strict on this Consistency – ease of new members joiningin
- #28 Reduce coupling, Design for flexibility and anticipate change are the traits for agile teams Coupling – specific and strict dependencies between components, for example, Web App directly dependent on the type of database Flexibility and change– easy to change by layered architectures
- #53 Agility is a quality attribute. It enables teams to experiment, ground themselves in feedback, and properly focus all effort to improve or build the product.
- #61 During middle of session, add requirements: - deliveries must be tracked, users must be able to see the riders in real time. - A Ph.D. teammate has already created a decision support system that recommends to us the promotions. Integrate with it.