1. Framework design
   1. App Architecture Guide
   2. A Language for Software Architecture
   3. An Architect Makes It To The Big Show
   4. Cross-Cutting Concerns
   5. Layer
      1. Presentation
      2. Distributed
      3. Domain service
      4. Data access
         1. ORM
            1. NHibernate
            2. Entity Framework
      5. Database
   6. Technical selection
2. Project management
   1. Process
      1. Agile/Scrum/XP
   2. Monitoring
   3. Technical debt
3. Software Design
   1. Functionality
   2. Non functional
      1. Performance
      2. Scalability
      3. Security
         1. Authorization
         2. Authentication
      4. Disaster Recovery
      5. Backout Plan
   3. Identify risk
      1. Are there risks in the project that could be minimized by an early design activity?
      2. 1. It’s someone else’s responsibility to do requirements.
      3. 2. I learn the domain as I write the code; incrementally.
      4. 3. The requirements are already fully understood by the stakeholders.
      5. 4. Domains are irrelevant to architecture choice.
      6. 5. I already know the requirements.
   4. ARCHITECTURAL PATTERNS
      1. Modules
         1. What is the structure of the actual modular units of code?
         2. How are larger modules decomposed into smaller sub modules?
         3. What other modules are using any given module?
         4. Are the modules structured in layers?
         5. What is the class structure of the modules (e.g. class inheritance)?
      2. Components and Connectors
         1. What is the structure of the actual runtime elements and their various interactions?
         2. How are various processes or threads connected?
         3. Where can threads run concurrently?
         4. Where might threads compete for resources?
         5. How is data produced and consumed by runtime elements?
      3. Allocations
         1. How does the system relate to elements like the hardware, file systems, networks and development teams in the environment?
         2. Where is software deployed (e.g. to what hardware are software elements allocated to)?
         3. How is software mapped to the file system(s)?
         4. Which developers or development teams are assigned to work on a given structure?
   5. patterns
      1. anti-patterns
   6. WHAT MAKES A GOOD ARCHITECTURE?
      1. The architecture should be designed to meet a prioritized list of quality attributes.
      2. The architecture should be driven by the non-functional requirements of the system .
      3. The architecture should be well documented and easily communicated.
      4. The architecture should identify any significant conflicts or tradeoffs, and clearly define the resolutions to these issues.
      5. The architecture should maximize the ability to localize changes to any given part of the system without affecting other parts of the system.
      6. The architecture should, whenever possible, lean on established architectural patterns which have proven most effective at solving the problems the software system is faced with.
      7. The architecture should utilize architectural patterns such that, as often as possible, the system does similar things the same way throughout the entire system.
   7. Bad Design
      1. rigidity
         1. it’s hard to change a part of the system without affection too many other parts of the system
      2. fragile
         1. when making a change, unexpected parts of the system break (introducing bugs)
      3. immobile
      4. Viscosity
         1. Easy to do wrong things, hard to do right things
      5. Needless complexity
         1. complicated class design, overly generalized
      6. Opacity
         1. hard to understand
   8. Layer architect
   9. Principles
      1. SOLID
      2. DRY
      3. KISS
      4. You aren't going to need it.
      5. Law of Demeter
      6. The Cooperative Game Principle
      7. The Peter Principle
      8. Once And Only Once
      9. Design By Contract
      10. open-closed-principle design conventions
          1. All member variables should be private
          2. No global variables
          3. avoid multiple if-then-else or switch-case statements
      11. Principles of Package Design
          1. Reuse/Release Equivalency Principle
          2. Common Reuse Principle (CRP)
          3. Common Closure Principle (CCP)
          4. Acyclic Dependencies Principle (ADP)
          5. Stable Dependencies Principle (SDP)
          6. Stable Abstractions Principle (SAP)
      12. Coupling and Cohesion
      13. Proximity Principle
      14. The boy scout rule
      15. Separation of Concerns (SoC) Principle
   10. Object Oriented Concepts
       1. Data and Logic together
       2. Inheritance is the last option
       3. Composition over Inheritance
       4. Focus on smart data-structure
       5. Abstraction as design mechanism
   11. Class design
       1. coupling
          1. Number of class that your class depends on
       2. Cohesion
          1. the object is focused on doing one thing well
       3. high cohesion and low coupling
   12. What does just enough up front design actually mean
       1. too little
          1. No understanding of what and where the system boundary is
          2. No understanding of "the big picture" within the team
          3. No common understanding of "the big picture" across the team
          4. Inability to communicate the overall vision
          5. Team members aren't clear or comfortable with what they need to do
          6. No thought about non-functional
          7. No thought about how the constraints of the (real-world) environment affect the software (e.g. deployment environment)
          8. No thoughts on key areas of risk, such as non-functional requirements, external interfaces, etc
          9. The significant problems and/or their answers haven't been identified.
          10. No thought on separation of concerns, appropriate levels of abstraction, layering, modifiability, flex points, etc
          11. No common understanding of the role that the architect(s) will play
          12. Inconsistent approaches to solving problems
          13. A lack of control and guidance for the team
          14. Significant change to the architecture during the project lifecycle that could have been anticipated
          15. Too many design alternatives and options, often with team members disagreeing on the solution or way forward
          16. Unsure whether the design will work (e.g. no prototyping was performed as a part of the design)
          17. A lack of technology choices
          18. Subtopic 18
          19. Subtopic 19
       2. too much
          1. Too much information (i.e. long documents and/or information overload)
             1. Subtopic 1
          2. A design that is too detailed at too many levels of abstraction
          3. Too many diagrams
          4. Writing code or pseudo-code in documentatiON
          5. n architecture that is too rigid with no flexibility
          6. All decisions at all levels of abstraction have been made
          7. Class level design and sequence diagrams for all interactions
          8. Detailed entity relationship models and database designs (e.g. tables, views, stored procedures and indexes)
          9. Analysis paralysis and a team that is stuck focussing on minor details
          10. Coding becomes a simple transformation of design artefacts to code, which is boring and demotivates the team
          11. An unbounded "design phase" (i.e. time and/or budget)
          12. The deadline has been reached without any coding
       3. enough
          1. Understanding how the significant elements of your architecture fit together (i.e. structure ... components and their interactions)
          2. Ensuring that you identify and mitigate the key risks (e.g. non-functional requirements and the constraints of the environment)
          3. Putting some firm foundations down and ensuring that everybody understands the overall vision (i.e. "the big picture")
       4. question
          1. Will the architecture work? If not, why not?
          2. Have all of the key risks been identified?
          3. Is the architecture too simple? Is it too complex?
          4. Has the architecture been communicated effectively?
          5. What do people like about the diagrams? What can be improved?
          6. Is there too much detail? Is there enough detail?
          7. Could you give this to *your* team as a starting point?
          8. Is there too much control? Is there not enough guidance?
          9. Are you happy with the level of technology decisions that have been made or deferred
4. quality
   1. Software quality factors
      1. Correctness
      2. Efficiency
      3. Expandability
      4. Integrity
      5. Interoperability
      6. Maintainability
      7. Portability
      8. Reusability
      9. Reliability
      10. Testability
      11. Usability
   2. Poor Software Quality
      1. cause by
         1. Lack of domain knowledge
         2. Lack of technology knowledge
         3. Unrealistic Schedules
         4. Badly engineered software
      2. Symptoms
         1. Rigidity
         2. Fragility
         3. immobile
         4. Viscosity
   3. Code Quality
      1. Skill
      2. Technology
      3. Care
      4. Code review
      5. Unit test- TDD
      6. code smell - Code refactoring
   4. Measure the system quality
      1. Metric
         1. 1. Source Lines of Code (SLOC)
         2. 2. Bugs per code_section/module/time_period
         3. 3. Code Coverage - unit test
         4. 4. Design/Development Constraints
            1. Class/method length,
            2. Number of methods/attributes in a class,
            3. Method/constructor parameter counts,
            4. Magical number, string usage in code files,
            5. Comment lines percentage etc.
         5. 5. Cyclomatic Complexity
         6. 6. Code style
            1. stylecop
            2. FxCop
         7. 7. Duplication
            1. PMD
      2. Principle
         1. 1- Software-quality requirements must be established before the design take place.
         2. 2- Software-quality metrics must be identified.
         3. 3- Software-quality metrics must be implemented.
         4. 4- The results of these metrics must be analyzed.
         5. 5- The software-quality metrics must be validated.
         6. Continuous integration
         7. User Story review
         8. root causes analysis
   5. Mistakes
      1. Management
         1. 1.- Believing that productivity is mainly associated with man power and working hours.
         2. 2.- Not managing customer expectations.
         3. 3.- Ignoring feedback from developers.
         4. 4.- Controlling as opposite of empowering.
         5. 5.- Being afraid of making decisions.
      2. Managing crises
      3. Effect on Productivity
   6. Technical Debt
      1. How much is it Really Costing you?
         1. $$-$$$ Error-prone code
         2. $$$ Making a fundamental mistake in architecture or the platform technology
         3. $-$$ The system can’t be easily tested
         4. $-$$ Not taking care of packaging and release and deployment
         5. $-$$ Code that mysteriously works, but nobody is sure how or why
         6. $-$$ Forward and backward compatibility adapters and compromises
         7. $-$$ Out of date libraries and middleware stack
         8. $-$$ Duplicate, copy-and-paste code
         9. $-$$ Known, outstanding bugs in code and unresolved static analysis findings
         10. $-$$ Inefficient design or implementation
         11. $ Inconsistent use of programming idioms and patterns
         12. $ Missing or poor error handling and exception handling.
         13. $0.01 Hard coding, magic numbers, code that isn’t standards compliant, poor element naming, missing comments
         14. $0.01 Out of date documentation
         15. $0.00 Hand-rolled code that could have and should have been done using built-in language features or libraries, or existing framework or common services.
   7. Agile Quality Assurance
      1. goals
         1. changes quickly
            1. what changed
            2. business
            3. technologies
            4. people
            5. to reach
            6. time to market
      2. What’s wrong with traditional
         1. Testing a product takes a lot of time
         2. where do bugs come from?
      3. The dark places in our software are called technical debt
      4. architecture in a way so that these problems are under control
         1. openness
            1. open for new features
         2. flexibility
            1. change local
         3. simple
            1. SOLID
         4. automated test
            1. Unit test
            2. Acceptance test
         5. define initial architecture
            1. It has to be clear enough to get the development team running, but it should not be too specific either
         6. architecture workshop
         7. Gather feedback about architecture
         8. Simulator
         9. Refine architecture
         10. spike
         11. leader
             1. it is still better to decide wrongly (and hopefully correct it later) than not taking a decision at all
   8. Principle
      1. Quality from the start
      2. Early interface validation
      3. Divide and conquer
      4. Safety net for the code
      5. Confidence = Productivity
      6. Light at the end of the tunnel
   9. design quality attribute
5. process
   1. Harveynash High level design process
   2. Harveynash Detail design process
   3. Harveynash development process
   4. Harveynash build process
   5. Agile
      1. principle
         1. breaking projects into Small Releases
            1. to
            2. manage risk and accelerate feedback
         2. time-boxing
            1. to
            2. limit WIP and keep everyone focused
         3. relying only on working software as the measure of progress
         4. simple estimating and using velocity to forecast team performance
         5. working closely and constantly with the customer
         6. Continuous Integration – and Continuous Delivery
            1. to
            2. to ensure that code is always working and stable.
         7. best practices that aren’t important
            1. Test-Driven Development
            2. Pair Programming
            3. Emergent Design and Metaphor
            4. Daily Standups
            5. Collective Code Ownership
            6. Writing All Requirements as Stories
            7. Relying on a Product Owner
      2. Type of Agile teams to avoid
         1. the sinking ship team
         2. the marry go around team
         3. the well oiled team
         4. the roller coaster team
6. TA role
   1. Characteristics of a software architect
   2. Are You a Software Architect?
   3. Software Architecture and Related Concerns
   4. What is a good software architecture in a nutshell?
   5. The Hidden Architectural Driver
   6. Clean Architecture
7. checklist
8. Coding
   1. clean code
   2. code review
   3. principles