Software Engineering and Architecture

Had in every business aspect a big positive impact. Development Process (86%), Managing changing priorities (92%) and time to market (77%) were stated to have the most positive impact (percentages for improved and significantly improved).

Also big positive impact over all aspects. Team morale/motivation (84%), people development (81%) and team productivity (81%) stand out the most!

Here the impact is smaller but still positive.

• Agile companies are much more satisfied with their methodology than non-agile companies
• Hybrid development is an issu, but shows miced results
• Agile companies show more improvements
• Only slight improvements with stress and overtime

It leads to ability to manage changing prior and this influences the development process directly!

Collaboriation!

The more experience the more collaboration happens!

• Tech practices precede collaborative practices:
  • Why? Initial misunderstanding of importance?
• Organization culture linked to agile experience
  • What does it mean for your organization
• Barriers are cultural first, complexity later:
  • How should agile handle complex software development?
• Agile is stressful?
  • Why? What can be done?

Definition

• A software system's architecture is the set of principal design decisions about the system.
• Software architecture is the blueprint for a software system's construction and evolution
• Design decisions encompass the following aspects of the system under development
  • Structure
  • Behavior
  • Interaction
  • Non-functional properties
• Can be understood like a Blueprint (plan)
  • provides overview
  • eases understanding
  • promotes communication
  • increases flexibility

• process: design a solution
• product: models, documentation, prototypes
• means: eases implementation of larger system

• Structural
  • The architectural elements should be organized and composed ecactly like this...
• Behavioral
  • Data processing, storage, and visualization will be performed in strict sequence
• Interaction
  • Communication among all system elements will occur only using event notifications
• Non-functional
  • The system's dependebility will be ensured by replicated processing modules

Shaw&Garlan 1996:

The architecture of a software system defines that system in terms of computational components and interactions among those components. Components are such things as clients and servers, databases, filters, and layers in a hierarchcal system.

• Enterprise architecture
  • ... defines way how an enterprise uses many applications
  • metaphos: city planning
• Application architecture
  • ... defines the pieces that compose an application
  • metaphor: building architecture

• Business needs
• Technical aspects
• Organizational aspects

Gist of Software Architecture

• Describe Software Systems
  • by separation
• into components
  • and
• Relatinships between these components
  • by providing
• separate views
  • and by respecting
• explicit and implicit quality attributes

Example of an architecture bases on "Layers" architectural pattern.

UML would be one possibility and is most often used.

• Sofware architecture is a set of models of the overall software system
• All requirements relevant for the system's construction must be addressed, e.g.
  • Extendibility
  • Timing
  • Performance
  • Security

• Need for several views
• Requirements tie everything together
  • 4+1 view

• Logical view
  • The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include class diagram, communication diagram, sequence diagram
• Development view
  • The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML component diagram to describe system components. UML Diagrams used to represent the development view include the Pachage diagram.
• Process View
  • The process view deals with the dynamic aspects of the system, explains the system processses and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalabilty, etc. UML diagrams to represent process view include the activity diagram.
• Physical view
  • The physical view depicts the system from a system engineer's point-of-view. It is concerned with the topology of software components on the physical layer, as well as communicatoin between these components. This view is also known as the deployment view. UML diagrams used to represent physical view include the deployment diagram.

• Scenarios
• The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequencs of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. UML Diagram(s) used to represent the scenario view include the use case diagram.

• If it is not written down, it does not exist
• What are your rules for layering? how to ensure that you meet your latency goal?
• What if Cal gets hit by a bus?

• Too many dimensions of information
• Different stakeholders need different information
• Non-formal/non-UML diagrms are helpful
  • whiteboard sketches can be fine
  • but within developer context appropriate UML diagrams can be fruitful

• Multi-dimensional decisions are hard
  • architectural decisions
    • have stron, overarching impact
    • define system- and project structure
• All factors are interdependent
  • changeability impacts performance
  • security impacts adaptability
  • everything impacts cost
• Requirements change continuously
  • change is the only constant
  • architecture guides change

• communication among stakeholders
  • common understandng about the system
  • get consensus
  • basis for discussions and decisions
• document design decisions
  • guidelines for implementation
  • basis for evolution and iterations
  • helps structuring team and planning
  • checkpoints for goal achievment
• abstraction of the system
  • for buidling product lines and homogeneous systems
  • for outsourcing or acquiring parts

• Architecture is the same as design
  • Architects focus is on the boundaries and interfaces
• £Architecture is about infrastructure
  • Frameworks, applicatoin servers, and databases from a minor part of the problem space only
• Architecture solves technical problems
  • chances are your biggest problem isn't technical
• Architecture is rigid and fixed (up fron)
  • Understand the impact of change
  • Start with a walking skeleton
  • great software is not built, it is grown
• Architecture is pure science or pure art
  • requires both and more

• "all-in-one" person
• "Eierlegende Wollmilchsau"
• guarantee fulfillment of requirements
  • within budget
• demonstrate achievability
  • with models and/or prototypes
• design and construct
  • components, interfaces responsibilities, structure
• coach and soncult developer and other stakeholders
  • technology, project planning, risk management, organization, implementation, quality control

• Decide (under uncertainty, but decide)
  • Use uncertainty as a driver
  • Architectrual tradeoffs
• Document (adequately)
  • Communicatin is king, clarity and leadership its servants
  • record your rationale
• Proof feasibility
  • One line of working code is worth 500 lines of specification
  • Try before choosing
• Program
  • Architects must be hands on
  • Before anything an architect is a developer
  • if you design it, you should be able to code it
  • Architects always also implements
• Communicate
  • Stand up, talk the talk
  • Learn a new language
• Negotiate (with stakeholders)
  • Seek the value in requested capabilities
  • you're negotiating more than you think
• Simplify
  • Simplify essential complexity; reduce accidental complexity
  • Simplicity before generality, use before reuse
  • Make sure the simple stuff is simple
• Standardize
  • Reduce the entropy
• Listen
  • Hear the stakeholder's concerns
• Observe
  • Dont control, but observe
  • Get the 100-foot view
• Think (about the future)
  • Everything will ultimately fail
  • Focus on applicatoin support and maintenance
  • your system is legacy; design for it
  • you can't provide future-proof solutions
• Lead
  • Give developers autonomy
  • There is no 'I' in architecture

IBM:

• Believing the requirements
• Being seduces by the technology
• Majoring on your strengths and neglecting other areas
• Not stopping designers from designing
• Thinking you can to it all yourself

Woods:

• Scoping Woves
• Not casting your net widely
• Focusing on functions (forgetting qualities)
• Using Box and line descriptions
• Forgetting that it needs to be built
• lack of platform precision
• performance assumptions
• Do-It-Yourself security
• Lack of disaster recovery
• No backout plan

• Simplicity
• Abstraction
• Separation
• Structure
• Interface
• Communication
• Delivery of working systems

• Process: (1) A sequence of steps performed for a given purpose; for example, the software development process. (2) An executable unit managed by an operating system scheduler. (3) To perform operations on data
• Software development process. The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes, installing and checking out the software for operational use. Note: These actiivities may oerlap or be performed iteratively

• Software development cycle: The period of time that begins with the dexision to develop a software product and ends when the software is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, thest phase, and sometimes, installtion and checkout phase. Contrast with: software life cycle
• Software life cycle: The period of time that begins when a software product is conceived and ends when the sotware is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installtion and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlaap or be perfomed iteratively

• Risks as primary driver
• Architecture centric
• 4 phases
• Iterative and incremental
• "Heavy": lots of documents, roles and process specificatoin
• Adaptable

• Each phase ends with a milestone
  • Inception: lifecycle objectives (scope!)
  • Elaboration: Lifecycle Architecture
  • Construction: Initial operational capacility
  • Transition: Product release