Software Engineering and Architecture

• 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

• Lean -> less documentation
• Deliver capabilities quickliy

The best architectures, requirements and designs amerge from self-organizing teams.

this leads to the belief, that architecture will gradually emerge.

• The software might not need new software concepts and design decisions, which have already been made.
• preexisting conditions already fix it
• there is a de-facto architecture setup in the domain

The phrase "agile architecture" evokes two concepts:

• An architecture that is versatile, easy to evolvee, and easy to modify, while resilient enough not to degrade after a few changes
• An agile way to define an architecture, using an iterative lifecycle, allowing the architectural design to tactically evolve over time, as the problem is better understood

In the best of worlds, we'd like an agile process that leads to a flexible architecture.

Architecture, design and building the system musto go hand in hand

1. Design emerges. Architecture is a collaboration
2. The bigger the system, the longer the runway
3. Build the simplest architecture that can possibly work
4. When in doubt, code or model it out
5. They build it. They test it, They run it.
6. There is no monopoly on innovation
7. Implement architectural flow

• Separatoin of cencerns
• They all chieve this separation by dividing the software into layers. Every concept for clean architecture has at least one layer for business rules, and another layer for user and system interfaces.

• Independent of frameworks: The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools, rather than forcing you to cram your system into their limited constraints
• Testable: The business rules can be tested without the UI, database, web server, or any other external element
• Independent of the UI: the UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules
• Independent of the database: You can swap out oracle or SQL server for mongo, BigTable, CouchDB, Blockchain or something else. Yout business ruls are not bound to the databse.
• Independent of any external agency: In fact, your business rules don't know anything at all about the interfaces to the outside world.

The overriding rule that makes this architecture work is the dependency rule: Source code dependencies must point only nward, towards hogher-level policies. -> Nothing in an inner circle can know anything at all about something in an outer circle.

• Enterprise business Rules (Entities)
  • Entities encapsulate enterprise-wide critical business rules
  • Entities encapsulate the most general and high-level rules
  • Important: They are the least likely tho change when something external changes
  • If you don't have an enterprise and are wrtiting just a single applicatoin, then these entities are the business objects of the applicatoin
• Application Business Rules (Use Cases)
  • The software in the use cases layser contains application-specific business rules. It encapsulates and implements all of the use cases of the system.
  • Use cases orchestrate the flow of data to and from the entities, and direct those entities to use their critical business rules to achieve the goals of the use case.
• Interface Adapters
  • Adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the database or the web
  • GUI: It is this layer, for example, that will wholly contain the MVC architecture of a GUI, i.e. presenters, views and controllers. The models are likely just data structures that are
  • Database: For example, if the database is a SQL database, then all SQL should be restricted to this layer
  • Any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities
• Frameworks & Drivers
  • Outermost layer: Glue code to connect UI, databses, devices etc. to the inner circles
  • Composed of frameworks and tools such as the database and the web framework
  • Generally you don't write much code in this layer, other than glue code that communicates to the next sircle inward

Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain.

Also a traditional methodoligy in Softare engineering.

Principles:

• Iterative and incemental
• Use case driven
• Architecture centric
• Risk focused

Issues:

• Can be "process" and "artifacts" heavy
• Is there a "transition" phase?

• Project Failure is too high
• Despite the application of (heavyweight) methodologies, technology projects still regularly fail more than would be acceptable in any other industry
• The evolution of technology (hardware) and tools (IDEs etc.) has outstropped methodologies by an oder of magnitude

• 57%: Poorly scoped projects
• 44% Technical or integration issues
• 36%: Poor implementation staff or services
• 35%: Buggy software
• 30%: Unattainable business requirements
• 27%: Loss of executive sponsorhips

For reasons 1, 3, 5 & 6  the methodology didn't work. For the others was the solution the problem.

• Methodologies to make software development process more disciplied and predictive
  • More planning
  • Greater Attention on analysis of reqirements (-> Reqirements Engineering)
  • Tie down scope and sign-off
  • Detailed and documented design before coding
  • Strict change control to suppress change

Set of values and principles shared by representatives from 

• Extreme Programming, SCRUM, DSDM,
• Adaptive software development, Crystal
• Feature-Driven development, Pragmatic Programming
• and others sympathetic to the need for an alternative to documentation driven, heavyweight software development process

founded it 2001.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• The highest priority is to satisfy the customer through early and continuous delivery of valuable software
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliveer working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the ob done.
• The moste efficient and effective method of conveying infromation to and within a development team is face-toface conversation.
• Woring software is the primary measure of progress
• Agile processes promote sustainable develpment. The sponsors, develepers, and users should be able to maintain a constant pace indefinitely.
• Continzous attention to technical excellence and good design enhances agility.
• Simplicity- the art of macimizing the amount of work not done - is essential
• The best architectures, requirements, and designg emerge from self-organizing tems.
• At regular intervals, the team revlects on how to become more effective, then tunes and adjusts its behavior accordingliy.

In the agile methodology used for software prjects. It is based on 11 Priciples structured in 3 Areas:

• Problem (risks in development projects)
  • 4 variables
  • cost of change
• Core Values
  • Feedback
  • Communication
  • Simplicity
  • Courage
  • Respect
• Activities
  • Listening
  • Coding
  • Testing
  • Designing

• Schedule slips
• Project cancled
• System does not evolve gracefully (defect rate increases)
• Defect reate
• Business misunderstood
• Business changes
• False feature rich
• Staff turnover

The role of XP is to give us priciples and practices in order to deal with these risks!

• 4 variables (and their relations):
  • Time (results out of the next 3 variables)
  • Resources
  • Quality
  • Scope
• External forces (customers, managers) can set the values for 3 of the variables.
• The develpment team sets the value for the 4th one.

• Communication
• Simplicity
• Feedback
• Courage
• Respect

• We wqill do what is needed and asked for, but no more
• This will maximize the value created for the investment made to date
• We will take small simple steps to our goal and mitigate failures as they happen
• We will create something we are proud of and maintain it long term for reasonable costs

• Everyone is part of the team and we communicate face to face daily
• We will work together on everything from reqirements to code
• We will create the best solution to our problem that we can together