Software architect's handbook become a successful software architect by implementing effective architecture concepts
A comprehensive guide to exploring software architecture concepts and implementing best practices Key Features Enhance your skills to grow your career as a software architect Design efficient software architectures using patterns and best practices Learn how software architecture relates to an organ...
| Otros Autores: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
Birmingham ; Mumbai :
Packt Publishing
2018.
|
| Edición: | 1st edition |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009630732306719 |
Tabla de Contenidos:
- Cover
- Title Page
- Copyright and Credits
- Dedication
- Packt Upsell
- Contributors
- Table of Contents
- Preface
- Chapter 1: The Meaning of Software Architecture
- What is software architecture?
- ISO/IEC/IEEE 42010 standard definition
- What makes up a software architecture?
- Software architecture is an abstraction
- Software architecture is about the important stuff
- Why is software architecture important?
- Defining a solution to meet requirements
- Enabling and inhibiting quality attributes
- Giving you the ability to predict software system qualities
- Easing communication among stakeholders
- Managing change
- Providing a reusable model
- Imposing implementation constraints
- Improving cost and effort estimates
- Serves as training for team members
- Software architecture is not a silver bullet
- Who are the consumers of software architectures?
- What is the software architect role?
- Software architects are technical leaders
- Software architects perform a number of duties
- Ivory tower software architects
- What are software architects expected to know?
- Don't be overwhelmed
- Is the software architect role right for you?
- Summary
- Chapter 2: Software Architecture in an Organization
- Types of software architects
- Enterprise architect
- Solution architect
- Application architect
- Data architect/information architect
- Infrastructure architect
- Information security architect
- Cloud architect
- Software development methodologies
- The Waterfall model
- Phases of the Waterfall methodology
- Issues with the Waterfall methodology
- Agile software development methodologies
- Agile values and principles
- An iterative methodology
- Adaptive rather than predictive
- Daily stand-up meetings
- Project management
- The importance of software project estimation.
- Putting effort into the estimates
- Being a realist (or even a pessimist)
- Team and situational factors to consider
- Project schedule changes
- Getting a project back on schedule
- Working overtime
- Reducing scope
- Adding resources
- Reallocating resources
- Identifying problem areas
- Acting as early as possible
- Office politics
- Understanding your organization's goals
- Addressing the concerns of others
- Assisting people with their goals
- Knowing when to compromise
- Being aware of cultural differences
- Software risk management
- Risk avoidance
- Transferring the risk to another party
- Risk mitigation
- Risk acceptance
- Configuration management
- Changing management
- Software product lines
- Benefits of a software product line
- Core assets of an organization
- Risks of product line engineering
- Summary
- Chapter 3: Understanding the Domain
- Developing business acumen
- Familiarity with general business topics
- Understanding your organization's business
- Domain-driven design
- Encourages and improves communication
- What is a ubiquitous language?
- Entities, value objects, and aggregates
- Entities
- Value objects
- Aggregates and root entities
- Separating the domain into subdomains
- What are bounded contexts?
- Requirements engineering
- Types of software requirements
- Business requirements
- Functional requirements
- Non-functional requirements
- Constraints
- The importance of requirements engineering
- Software requirements must be measurable and testable
- Software requirements that affect architecture
- Requirements elicitation
- Techniques to elicit requirements
- Interviews
- Requirements workshops
- Brainstorming
- Observation
- Focus groups
- Surveys
- Document analysis
- Prototyping
- Reverse engineering
- Get access to the proper stakeholders
- Summary.
- Chapter 4: Software Quality Attributes
- Quality attributes
- External or internal
- Quality attributes and the SDLC
- Testing quality attributes
- Maintainability
- Types of software maintenance
- Corrective maintenance
- Perfective maintenance
- Adaptive maintenance
- Preventive maintenance
- Modifiability
- Extensibility and flexibility
- Scope of modifications
- Designing for maintainability
- Reducing size
- Increasing cohesion
- Reducing coupling
- Measuring maintainability
- Lines of code (LOC)
- Cyclomatic complexity
- Depth of inheritance tree (DIT)
- Usability
- Allowing users to complete their tasks efficiently
- Learnability
- Providing useful feedback
- Accessibility
- Usability needs to be considered during requirements
- Usability testing
- Appealing visual design
- Providing a good help system
- Software must be useful, and not just usable
- Availability
- Calculating availability based on time
- Calculating availability based on request success rate
- Faults, errors, and failures
- Detecting faults
- Ping/echo reply
- Heartbeat
- Timestamp
- Voting
- Sanity test/sanity checking
- Condition monitoring
- Self-tests
- Recovering from faults
- Exception handling
- Retry strategy
- Varying levels of redundancy
- Rollback
- Graceful degradation
- Ignoring faulty behavior
- Preventing faults
- Removal from service
- Transactions
- Increasing competence sets
- Exception prevention
- Portability
- Adaptability
- Installability
- Replaceability
- Internationalization and localization
- Maintaining portability
- Interoperability
- Challenges with interoperability
- Locating and exchanging information with another system
- Interoperability standards
- Interoperability testing
- Testability
- Controllability
- Observability
- Isolability
- Automatability.
- Complexity of the software
- Importance of test documentation
- What makes a good tester?
- Summary
- Chapter 5: Designing Software Architectures
- Software architecture design
- Making design decisions
- Software architecture design terms
- Structure
- Element
- System
- Subsystem
- Module
- Component
- The importance of software architecture design
- Making key decisions
- Avoiding design decisions can incur technical debt
- Communicating the architecture to others
- Providing guidance to developers
- Influencing non-technical parts of the project
- Top-down versus bottom-up design approaches
- Top-down approach
- Advantages of the top-down approach
- Disadvantages of the top-down approach
- Bottom-up approach
- Advantages of the bottom-up approach
- Disadvantages of the bottom-up approach
- Which approach should I use?
- Greenfield versus brownfield software systems
- Greenfield systems
- Brownfield systems
- Architectural drivers
- Design objectives
- Primary functional requirements
- Quality attribute scenarios
- Prioritizing quality attribute scenarios
- Constraints
- Architectural concerns
- Leveraging design principles and existing solutions
- Selecting a design concept
- Software architecture patterns
- Reference architectures
- Benefits of reference architectures
- Refactoring a reference architecture for your needs
- Creating your own reference architecture
- Tactics
- Externally developed software
- Buy or build?
- Advantages/disadvantages of building
- Advantages/disadvantages of buying
- Researching external software
- Should I use open source software (OSS)?
- Advantages of using open source software
- Disadvantages of using open source software
- Documenting the software architecture design
- Sketching the architecture design
- Documenting the design rationale.
- Design rationale for design evaluation
- Design rationale for design verification
- Design rationale for design knowledge transfer
- Design rationale for design communication
- Design rationale for design maintenance
- Design rationale for design documentation
- Design rationale for design reuse
- Using a systematic approach to software architecture design
- A general model of software architecture design
- Architectural analysis
- Architectural synthesis
- Architectural evaluation
- Architecture design is an iterative process
- Selecting an architecture design process
- Attribute-driven design (ADD)
- Step 1 - Reviewing inputs
- Step 2 - Establishing the iteration goal and selecting inputs to be considered in the iteration
- Step 3 - Choosing one or more elements of the system to refine
- Step 4 - Choosing one or more design concepts that satisfy the inputs considered in the iteration
- Step 5 - Instantiating architectural elements, allocating responsibilities, and defining interfaces
- Step 6 - Sketching views and recording design decisions
- Step 7 - Performing analysis of current design and reviewing the iteration goal and design objectives
- Step 8 - Iterating if necessary
- Microsoft's technique for architecture and design
- Step 1 - Identifying architecture objectives
- Step 2 - Identifying key scenarios
- Step 3 - Creating application overview
- Determining your application type
- Identifying your deployment constraints
- Identifying important architecture design styles
- Determining relevant technologies
- Step 4 - Identifying key issues
- Step 5 - Defining candidate solutions
- Architecture-centric design method (ACDM)
- Step 1 - Discovering architectural drivers
- Step 2 - Establishing project scope
- Step 3 - Creating notional architecture
- Step 4 - Architectural review
- Step 5 - Production go/no-go.
- Step 6 - Experiment planning.
