SEIP Notes - Software Engineering in the Industrial Practice (IN2235) PDF

lOMoARcPSD|39768292 SEIP Notes - Zusammenfassung Software Engineering in der industriellen Praxis (IN2235) Software Engineering in der industriellen Praxis (IN2235) (Technische Universität München) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 SEIP Notes Week 1: Software Classes Three traditional Software Development approaches: - Custom software development (CSD) - Commercial - non-standard - Fully customised - Non-reusable, company speciÞc - Standard software development (STD) - Commercial development - Standardised - Partially customised - Fully reusable, domain-speciÞc for many customers - Open-source software development (OSS) - Non-commercial - Standardised, highly customisable - Fully reusable for many customers Four classes - Graphics and media - Graphics editing application (STD, OSS): for editing and rendering graphics in vector/ bitmap format - Graphics animation engine (CSD, STD): for animating 2D/3D virtual worlds of games and TV - Audio/Video processing systems: for live processing and post-production of streams - Business and data - Oﬃce productivity application (STD, OSS): for productivity in desktop based oﬃce environment - Business information system (CSD, STD): for driving business processes through information management - Data management system (OSS): for storing and retrieving persistent data - Machinery and network - Technical control system (CSD): for controlling a physical machinery or technical system - Network communication system (OSS): software for communicating data over a computer network - Operating system kernel (STD, OSS): software kernel for operating a physical/virtual computing device - Development and tools - Software development kit (OSS): libraries and frameworks of reusable functionality for developing software - Software development tools (OSS): tools for editing, linting, compiling, packaging and installing software - Operating systems tools (OSS): software tools for high-level operating a physical virtual computing device Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Software Development Approaches Four kinds of software development approaches: Software prototyping: develop an early sample or model of software solution by mocking or cheating to test a concept/idea/process Software bricolage: develop single instance of software by integrating partial solutions to prove feasibility or to provide a service Software craftsmanship: develop production grade software solution by a professional to solve a usually complicated problem Software engineering: develop production grade solution by a professional to solve a usually complex problem Development approaches are usually combined in practice: - Prototyping and craftsmanship are earlier stages of craftsmanship or engineering - Craftsmanship can be part of engineering - Each approach requires a special skill Software Engineering Engineering vs software engineering: Engineering: systematic application of scientiÞc and technological knowledge to build/maintain complex production-grade solutions Software engineering: systematic application of engineering knowledge, principles, approaches, practices, methods, and experiences to the development of software. For both following Code of conduct holds: commit yourself to highest ethical and professional conduct; accept responsibility in making decision consistent with safety, health, welfare of public, and apply state of art techniques. Comply with principles of sustainable development. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 TRUE Manifesto Targeted (adequate, suitable, focused): - Solution and approach have to be in reasonable proportion to problem - Avoid over-engineered and cobbled together solutions - Avoid one size Þts all approaches Reasoned (considered, assessed, deliberate): - Think carefully in advance about solution and approach because thinking is cheaper than correcting - Develop Òbig pictureÓ Þrst, add details as late as possible - Conceptual modelling key to understand problems and solutions Up-to-date (educated, experienced, insistent): - develop high quality solutions with up-to-date methods and technologies - IT world is recurrently revolutionising itself - Continuously educate ourself and assess emerging approaches and products - Not satisÞed with mediocre solutions Evolutionary (sustainable, harmonic, contextual): - Develop sustainable solutions that optimally Þt in their context - Nature teaches us only evolutionary solutions run in long run - Learn from experience of past to improve future - Avoid Òquick hacksÓ Software Engineering Metamodel Software engineering can be understood through a meta-model based on four distinct but linked models. Craftsmanship model: - Targets the WHEREBY & HOW - Spans from professions of individual persons, their corresponding know-hows and practices, to the underlying templates and tools Discipline model: - Targets HOW & WHAT - Disciplines are grouped into Areas motivated by inclinations of individual persons - Each discipline described through input and output artefacts and their aspects Workßow model: - Targets WHAT & WHO - Describes a workßow of cycles which contain steps - A ßow are the runs through those steps Process model: - Targets WHO & WHEN - Maps activities onto project execution schedule, based on horizontal tracks of roles and vertical periods of phases Key message: Master SE means understanding Discipline, Workßow, Process and Craftsmanship models in that order. Never start with particular process model. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Software Engineering Disciplines SE can be understood through 20 distinct disciplines, grouped into 10 areas, each grouped into 5 inclinations. Inclinations: Business-oriented and domain speciÞc: - Analysis - Software requirements: Identify needs - Domain modelling: Determine solutions - Experience - User experience: Optimise workßow - User interface: Design user interfaces Constructive and technological: - Architecture - Software architecture: design software - System Architecture: design systems - Development - Software development: implement code - Software refactoring: refactor code Analytical and domain speciÞc: - Analytics - Software reviewing: review code - Software testing: test solution - Comprehension - Usage documentation: document solution - User training: train users People-oriented and process-oriented: - Management - Product management: push product - Process management: steer process - Adjustment - Project coaching: support members - Change management: involve stakeholders Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 2: Software engineering workßow Workßow model describes how work is segregated in Software Engineering. There are 3 main cycles and 2 auxiliary ones, which express the iterative approaches. Every cycle has one of the Þve inclinations of SE which represents diﬀerent types of people. Business Cycle: - Understand: understand problem and requirements of user - Ideate: idea solution adequate for the problem and requirements - Explore: Prototype, explore, assess ideas, approaches and technologies - Specify: Rigorously specify functionality and quality of solution Development Cycle: - Design: design architecture how to implement solution - Implement: implement solution outside-in from coarse to Þne aspects - Build: build and package solution from artefacts - Verify: rigorously review and test function/non-functional aspects of solution Operations Cycle: - Deploy: Ship and deploy solution and updates in automated way - Integrate: Integrate solution with its environment - Operate: ensure our infrastructure and solution can be operated securely - Monitor: continuously minor solution and infrastructure in runtime Cycles are interlinked and cycle at diﬀerent speeds (Sx), with S(B) >= S(D) >= S(O), to prevent lagging in later cycles. 2 aux cycles: Product management: envision, conÞgure, release, rollout Project management: Initiate, deÞne, plan, steer Software engineering steps: We can understand SE on an operational level through these 20 distinct steps, performed within the workßow above. Each step belongs to one primary discipline and maybe some secondarily disciplines. Software Engineering Artefacts Four artefact sets cluster individual artefacts and their contained aspects. Artefact represented in graphical/textual form Aspects structure an artefact internally Software requirements speciÞcations (Domain focus) - Requirements - Customer journey - Solution vision - Functional / non-functional requirements - Domain Model - Data model Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 - Use cases + scenarios - Personas + test cases - User Interface - Usage concept - Language conventions - Dialog patterns + storyboard - Visual design Software architecture speciÞcations (Technology focus) - Viewpoint - Context and functionality view - Information and currency view - Development and deployment view - Operations view - Perspective - Bunch of BS Software implementation results (Domain focus) - Source code - Application - Build and test automation - Deployment and operation automation - Binary code - Application Software documentation results (Technology focus) - User guide - Usage tutorial - Functionality reference - Release info - Operations guide - ConÞguration reference - Deployment and operation procedures In a SE project we also have additional internal artefacts created by the disciplines. The shown ones are just the external ones. Software Engineering Eﬀorts Software products follow life cycle of 7 temporal non-equally sized phases. SE disciplines focus eﬀorts on those phases. Amount of human resource diﬀers between phases as well. Development: Inception: Initial setup, deÞne goal, establish necessary resources Elaboration: Scope roughly speciÞed, architecture deÞned, skeleton crafted Construction: Step by step product is speciÞed, implemented, tested, deployed Transition: Final product rolled out Maintenance: Production: Regular bug Þxes, upgrades, updates.. Retirement: Bug Þx and update on demand only Termination: archiving all source Þle and destroying infrastructure Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Uncertainty & Elaboration Cone of uncertainty: - The cone of uncertainty tells how variability of project scope (measured in eﬀort, cost or features) changes over time. - Early development phases: inception & elaboration have to ensure variability is reduced noticeably - For agile/iterative approaches, during construction phase the scope further shifts due to step- by-step learned details of solution Walking Skeleton: - Elaboration phase important for the creation of Walking Skeleton - Design of technical foundation without any domain-speciÞc functionalities - Goal to establish integration of all technical aspects onto which domain-speciÞc functionalities can later be put onto Agile Þxed price contracts: Contract with two types of conditions - One for inception + elaboration phase, usually time & material based but Þxed duration based - Used to gather necessary Þgures and to make experiences - One for construction+transition phase based on deferred estimate Þgure, usually Fixed-user- story or Þxed-price based. (Amount of user-stories multiplying by average wage, results in a cost) User story is a features wanted from customer perspective, written in Þrst person of a user Goal of agile Þxed price contracts is to shrink the cone of uncertainty at Þrst, lowering risks, and also such that the customer remains ßexible in scope during construction and transition phase. Requirements Basics Requirements speciÞcation: Document focusing on WHAT and WHY of solution, not concrete technical HOW. Should be SMART: speciÞc, measurable, achievable, relevant, and time-bound. Two types of requirements: - Functional requirements: (Shall do) A condition or capability that solution must provide - Non-function requirements: (Shall be, words ending -ility). Architect takes care of this one. Requirements can be positive (backing) or negative (Trade-oﬀ), if they support one another or if they conßict with one another. Architect takes care of latter. Example: scalability supports availability, but security interferes with usability Requirements can also be enduring (Þxed) or volatile (unstable). Depending if requirements lasts forever or can change over time. Architect takes care of latter. Non functional requirements: Many potential non functional requirements, architect must try to minimise this quantity. Make sure they are very clearly deÞned as there can be great similarities between requirements and diﬀerences can be very subtle. The ones that almost always have to be considered are: maintainability, usability, security, availability, reliability, performance, responsiveness, and adaptability. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 3 Architecture Stargate We can deÞned architecture both structurally scientiÞc through the measurable elements or wholly artistic through the harmony and accord of all parts. The ÒtruthÓ lies in between. 4 Aspects of architecture: Engineering: requirements, process, estimation Science: algorithms, data structures, protocols Craftsmanship: coding, debugging, testing Art: user experience, graphics design, coding style Adequacy and Beauty Adequacy is the measure of how suitable something in its environment fullÞlls its imposed requirements from the perspective of an individual. It is a relative and subjective measure but is essential because allows people to better structure their perceptions and judgment. Beauty is deÞned as the perception of how simple, elegant, natural, securing, and evident (SENSE) something is, from the evolutionary perspective of a person. Beauty is an absolute and subjective perception but is essential as the SENSE aspects are universal across people. King Discipline Architecture Architecture is considered the kingÕs discipline in SE because it is the central link between all the speciÞc domains and technologies. The architecture construction takes place in the design phase of the BizDevOps workßow. Manifesto for IT Architecture: Policy statement that should be followed. - Emphasis on continuously raising the bar, even after 50 years, must be continued to develop - Mission is design, implementation, and maintenance of IT solutions - Entitlement: continuously raising the bar and help others learn the craft. Goal is to achieve maximum value for clients - Values: there are basic values and then there are even more important values prioritised over the others ones - Sustainable concepts over latest technologies - Constructive craftsmanship over analytical engineering - Proactive improvement over reactive correcting - Inherent quality over tested robustness - Operational delight over functional usefulness Complex vs Complicated Complex refers to the higher level, macro diﬃculty of a system where it involves a lot of many diﬀerent connected parts which take time to comprehend in total, but which may individual be easy to explain. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Complicated refers to the lower level, micro diﬃculty of a system because it may involve many complicated parts which to understand and explain in detail each one may be diﬃcult The architecture has to master the complex aspects of a system and the development has to master the complicated aspects of it. Architecture Space The architecture space consists of three dimensions: - Artefact abstractness: We can look at artefacts concretely as the solution, or what they are based on like the tools, templates, technologies, patterns, principles, or lastly maxims. - Architecture scope: The Þeld of architecture from low level technical (infrastructure, infrastructure) to high level domain speciÞc (application , business): - Architecture zoom: The detail level of each layer from the architecture scope, from landscape, to singleton, to atom. In space of architecture scope and zoom there are 4 types of architectures: - Business architecture - Software architecture - System architecture - Enterprise architecture Architecture Ontology So that architectures can communicate meaningfully, must deÞne and agree on basic terms. Two main loops in ontology: Loop 1: Architecture description gives rationale for decisions which should be back referencing to requirements. Should not document the WHAT but the WHY because WHAT can be seen in code. Loop 2: Architecture description also gives views and aspects, called viewpoints and perspectives. Both together provide insights at scope and zoom level and are documented via speciÞc language. Only insights given which address a concern of Stakeholder, nothing more. Architecture Maxims There are 20 Maxims that an architect should follow and not break. Proven basis and no silver bullet say that we should base ourselves on existing reference architecture but it has to be clear that we have to adapt these and probably canÕt use them exactly as they are. Stepwise reÞnement and component orientation say regarding time and for risk minimisation one always goes from coarse to Þne. Simplicity trumps is misleading, nothing in IT is simple or easy and if it is the understand might not be there. Or someone invested a lot of time to make it seem simple and thatÕs the idea, making inherently complex things simple again. Should I list all the maxims??? Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 4 Architecture Principles There are 28 principles or 14 pairs of principles that architects should follow in general but may violate if he has good reason. For example a particular project-speciÞc requirementÉ Logical separation: One of the most important principles because many other principles automatically follow, such as Structural modularity (splitting solution into manageable structural components). Loose coupling and strong cohesion: That individual components should be independent from each other but within the components everything has to be working together to achieve the functionality. In practice these principles are just one. Open extensibility and close changeability: Meaning that components should be extensibility by third parties at Þxed interface and that to add new features one shouldnÕt have to modify the code. Known as Open-Close in literature. Over Simplicity: Design aspects of solution are as simple as possible and only as complicated as necessary. One of the hardest principles to implement. Encapsulated complexity: Complex related aspects are encapsulated into a single component. Component Design Software architecture is all about components and interfaces. So component design is a central task. DeÞnition of a component: - Encapsulates a certain how-how, is potentially reusable and replaceable. - Has a behaviour and a state and hides internal complexity of both behind small contractual interfaces. - Can be considered as a white box or a blackbox depending on whether internal details can be viewed from outside or not. - Components are arranged hierarchically into categories and have explicit dependencies among each other Distinction between component and module: - Component more general, any group of anything - More speciÞc, source-code unit: module DeÞnition of a module: - Know-how encapsulating, potentially reusable and substitutable source code - Hides its operations and data implementation behind API (application programming interfaces) Two ways to derive components: - Separation of concerns: which unique concern or task does the component have - Single responsibility principles: what is unique responsibility of component Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Interface Design Interface: - Well-deÞned, shielding, abstracting boundary of a passive providing component - Consists of one or more distinguishable interaction endpoints - Component is access by exchange of input/output information at endpoint under a speciÞc contract ÒGoodÓ interfaces have following properties: - Proportional: interface is smaller and size proportional to functionality behind it - Expressive: provides powerful programming model - Orthogonal: allows combinatorial use-cases - Concise: generates little ÒBoilerplate codeÓ during use Many software patterns for interfaces. An interesting one is the leaky two-layer facade. We have an upper convenient use-case related interface and a lower feature-related interface. The lower facade is the leaky one and implements the upper one. Component Hierarchy A component is any group of anything in software architecture nevertheless we can categorise them into a hierarchy. There are three levels: - Macro architecture: deal with Systems / Applications which consist of Zones which are either Tiers or Areas. The zones themselves consists of Programs. - Meso architecture: deal with the Programs in the system, arranged in Units, and those are consist of Modules. - Micro architecture: Deal with the modules that consist of functions and blocks. These consist of statements and expressions. Five primary units of thinking are systems, programs, modules, functions and stokes. Application Composition - Applications are composed of one or more executable programs - An executable in turn can leverage externalised objects or shared objects - These are in turn composed of components In a microservice architecture the executable are called microservices. Four distinct types of components: Library, framework, Composable and module. Can be distinguished by characterising aspects: - If they provide an API to the consumer of component - If they require consumer of component to fulÞl some service provider interface (SPI) Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 5 Architecture patterns deÞniton: - Name: unique, catchy, associative - Description: concise, precise, normative - Problem: contextual, regularly occurring, practically relevant - Solution: general, highly reusable, best practice Architecture patterns especially allow one to communicate eﬃciently and beneÞt from their capture experience (best practice). Layer architecture: - Horizontally split code or data into logical, sometimes spatially, distinct layers. - Layer not allowed to have knowledge about upper layer - Closed layering: layer only knowledge about directly underneath layer - Open layer or leaky abstraction: layer can have relationship with any layer below it If layering extends across network boundaries or a physical boundary, we speak of Tiers. Split code logically and spatially into tiers that are network connected. If program is split into user-interface focusing layer and a data focusing layer we speak of front end and back end. Not to be confused with client and server which are tiers of a system through their special roles, and they themselves can have front end and backend. Facade: special layer that separate modules of two layers in a program, acts as a broker. Middleware: Variant of facade at system level instead of program level, broker between client/ server communication. Slice Architectures Slicing: code or data is split logically and optionally spatially into slices. Similar to layers but slices are drawn vertically. - Slices are isolated from each other, clearly distinct, and named - Slices in same layer should be as independent as possible - In case of relationships, no cycle should exist Special variants of slices: - Concerned modules: slices of a layer that realise domain-speciÞc or technical concern - Common package: slice of a tier, where commonalities of other layers moved to - Use-case slices: slices of tier dedicated to a certain domain-speciÞc use-case Command-query responsibility segregation architecture: Code of program or tier (across all layers) is split into two slices, one for queries/reads and one for commands/writes. Micro-service: split code of a tier (across all layers) into distinct loosely coupled domain-speciÞc functionalities. Execute as a separate program. Self-contained system: split code across all layers and tiers into distinct separately executable sub systems. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Flow Architectures Patterns Flow architectures: - Concerned with data ßow or communication of application - Three classical approaches - Pipes and Þlters: directed graph built - Nodes are components of type source, Þlters, sink - Edges of graph are pipes, data transmission links between components - Ports and adapters: Hexagonal architecture - Hub and spoke structure is setup - Hub are the components of application core - Spokes consists of a component with a Port (interface) and the Adapter (implementation) - Central hub acts as communication centre between Spokes, and can reduce number of paths drastically, from Nx(N-1)/2 to N paths. Process Architectures Patterns Process architectures are all about interaction between containers, processes or threads. All three encapsulate code and data. - Containers: strongest capsule, encapsulates CPU, RAM, hard disk, and network (e.g Docker container). Can contain one or more processes - Process: encapsulates CPU and RAM (e.g unix process). Can contain one or more threads. - Thread: weakest capsule, only CPU (e.g unix thread) Process / Thread Pool: - To answer multiple requests at same time, applications use multiple processes per request - Use a pool of process/thread to avoid creating new ones at every request - This increases run time performance - Classically pool split into single master process/thread and multiple worker processes/threads - Permanently running master delegates requests to workers and controls them - Starting the master starts initial set of workers and stopping mater stops all pending workers Cluster Architectures Patterns Master-Slave: - Static replication of data from master server to slave servers - Clients can send read requests to all server but write requests exclusively run via master - Usually leads to increased read performance - Master is assigned statically and has to be re-assigned manually usually in case of outage Leader-Follower: - Dynamic replication of data from leader server to multiple follower servers - Client can send read and write request to all servers - Followers will internally forward write requests for client to leader server - Leader is selected automatically via election protocol in event of failure of current leader server - Advantage is for Clients it feels like master-master but without complex conßict resolution strategy Master-Master: - Genuine synchronisation of data between master servers - Client can send read or write request to any master server - Master servers must internally resolve conßicts to prevent simultaneous changes to same data Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Networking Architectures Patterns In networking architecture the network communication between computer nodes is addressed. - Point-to-point: simplest form, communication via direct connection of nodes - Routing: packets are forwarded to intermediate routers and then to destination node - Peer to peer: all nodes are client and server roles, no central hub - Client/Server: Multiple nodes in client role (making requests) and multiple in server role (serving responses) - Bus/Broker: have one central hub that forwards packages to all other nodes - Forward/Reverse proxy: If there is a forwarding node in front of source node or target node - VPN: we place logical secure overlay network over a physical network Communication Architectures Patterns Communication architectures address the type of communications between components. Primarily four diﬀerent kinds of message transmission: - Unicast: source node sends to exactly one target node - Anycast: source node sends to group of target nodes, but message is only delivered to one in the group - Multicast: Source node sends to group of target nodes and message is delivered to everyone - Broadcast: Sends message to all reachable target nodes without these nodes even being known to the sender Two kinds of messages: - Datagram: each message consist of one network packet with no guarantees of arrival - Stream: message consist of sequence of network packets. We have some guarantees in case of package congestion at intermediate nodes. Two modes of client/server communication: - Pull: A client has to send a request to receive message from server (Usually UniCast/AnyCast as a stream) - Push: Client subscribes to server and will receive certain type of messages (Usually BroadCast/ Multicast with datagram) Week 6 Data Structure Architecture Patterns 6 types of data structure types: - Scalar: (e.g Integer, String) - Tuple: ordered Þxed size sequence of scalar - Sequence: ordered sequence of elements - Set: unordered set of elements - Map: unordered set of elements indexed by key - Graph: unordered set of elements indexed by following link between each element Data evolution approaches is how data changes over time. 6 types: - In-place editing: data simply changed directly, no previous state available - Stacking revisions: entire data set copied before each revision so entire data record doesnÕt have to be copied - Structural diﬀerence: stores only technical diﬀerence between old and new data records - Operational transformation: technical change operations stored as a journal Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Data sharing approaches: É this is too much Data store types: - Relational table store: most common type, mysql - Graph store: most elegant type - Document store: most convenient, Data Persistence Architecture Patterns 3 aspects in the domain of data guarantee: - CAP: usually have to to a trade-in, decide for our data to be Consistent + Partition tolerant (CP) or Available + Partition tolerant (AP). CanÕt have both - Base systems: prioritise AP (noSQL systems) - Acid: prioritise CP (newSQL systems) Data access grouping: two forms - Transaction: we bracket the operations in a technical transaction and make sure either all or none can be executed - Compensation: We can undo operations with domain-speciÞc compensation operations Data access: if two processes/threads want access same data, diﬀerent rulesÉ - Shared read/write: everyone can read and write - Shared read / exclusive write: shared data for reading but only one can write at a time - Shared nothing: No shared access to data for both operations Data consistency: two patterns - Exclusive locking: only one person accesses data at a time - Optimistic locking: every can access and then conßicts are resolved later Data spreading and aggregation: - Data River (1-to-N): data is given from one master node to multiple slave nodes, increase read performance - Data mart or Data Lake (N-to-1): data given from many master nodes replicated to one slave node, to evaluate or cache the data Data transfer: - Replication: stream or copy data from master to slave node. Can read data faster or use slave nodes as backup in case of master failure - Synchronisation: Continuously stream or copy data between multiple master nodes and resolve potential concurrent data modiÞcations Application Reference Architecture We can diﬀerentiate between 7 logical layers in an application: -Technical Data (data structures) -Abstract Data (data objects) -Domain Data (domain objects) -Domain service -Domain interaction -Abstract interaction -Technical interaction There are 4 diﬀerent ßows through the layers: - Action ßow: from top to bottom, because all actions start from user - Error Flow: from bottom to top, as worst case the error has to reported to user - Data ßow and state ßow: go in both directions trivially Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Thin client: only technical interaction on the client system Rich client: entire user interface on client system, technical, abstract, and domain interaction Fat client: no other server, fully standalone program. Client-server Architecture Thin client: application consists of single custom server program only. Server renders UI and keeps the UI state on server. Advantage: easily updatable Disadvantage: server has to keep all the UI state of clients, can lead to it being a bottleneck Rich client: application consists of custom client and server program. Client program renders the UI and keeps the state on client. Advantage: higher reaction time, only little data has to be exchanged between client and server. Server isnÕt bottleneck Disadvantage: Updates have to be done through installation procedure Skip information system architecture Reactive System Architecture Enables realisation of reactive systems. - Strongly interact with their environment - Continuously process data streams as small messages - React at any time with tight time limits - Continuously observe en and adapt their behaviour Primarily used in real-time communication (internet of things) where services have to be elastic, highly scalable, reliable, and high fault tolerance. Week 7 Formal languages: in a technology stack usually dozen languages used, must be picked carefully by architect. Two types: - Declarative language: expresses a target state (WHAT) let machine do the work. - Imperative language: expresses how to get to a target state (HOW) tell the machine what to do. Declarative usually preferred, especially in very dynamic and error prone environments. Technology platforms: Various levels of software ranging from low level (operating system related) more diﬃcult, to higher level more easy (business-logic related) Technology platform less about choosing coding language and more about choosing particular ecosystem for a speciÞc kind of software. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Technology Stack A technology platform consists of a language, optional run time environment and a standard library. Additionally frameworks and libraries extend this to a technology stack. - Run-time environment and the frameworks very invasive to programming model - Can almost never be replaced afterwards - Therefore in walking skeleton, main focus on deÞning and integrating technology stack - While application is implemented once, technology stack usually deÞned by company and reused several times over a few years - Large companies usually deÞne technology stack and platforms in their enterprise blueprints Software Deployment During software deployment, an application is installed on Þle system for execution. Bare Amalgamation: - Þles copied into central directory - Easy to realise but makes clean removal later very hard Unmanaged heap: - each application copied in separate directory (macOS.app) - Very easy to realise and removal also - But no repair possibilities Managed heap: - central package manager is used (.pckg macOS) - One installer per application - Easy uninstall, repairable, dependencies Container image: - if want application more independent of operating system, and install as shielded unit - Application bundled with all dependencies and a part of the OS Virtual machine image: - if more shielding is wanted - Application bundled with all dependencies and complete OS installed on VM Solution appliance: - A step further and we also include the underlying hardware, all bundled into one total solution Cloud Computing Resources Cloud computing has four essential dimensions Cloud characteristics (How?) - On demand - Self-service - Automatable - Network-access - Multi-tentncy - Measured service - Elasticity - Pay-per-use Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Cloud approaches (What?) Specify what is provided - IaaS (infrastructure as a service): only network and computer, usually a virtual machine - CaaS (container as a service): Provides (Host) Operating System and a Container Run-Time in addition to IaaS - PaaS (platform as a service): provides surrounding tools and libraries and an application run- time - FaaS (Function as a service): provides PaaS and additional service events and mesh - SaaS (Software as a service): provides application and its service in addition to PaaS Cloud scope (Who?): - Public cloud: for public cloud computing - Community cloud: for cloud computing within closed group of organisation - Private cloud: for cloud computing within single organisation Cloud location (Where?): - Provider hosting: resources physically provided at external provider - On-premises: resources locally provided at organisation Cloud Native Architecture DeÞnition: applications developed, installed, and operated to maximise cloud computing advantages. Infrastructure provided by central service platform. Objective: high scalability and high availability for the services of the platform aswell as the microservices of the application A bit moreÉ Oﬄine Capability Importance for user experience: crucial to have good user experience even when client/server network is oﬄine Challenges in Temporary Network Oﬄine Situations: ¥ Switched Virtual Private Networks (VPN). ¥ Changed mobile network cells. ¥ Failed network components. These maturity levels describe the capabilities of an application during an oﬄine phase, providing various degrees of functionality and user interaction depending on the oﬄine scenario. Oﬄine Scenarios Maturity Levels: ¥ Oﬄine Unaware: ¥ Client fails implicitly with network errors. ¥ Oﬄine Aware: ¥ Client explicitly disables the user interface and displays a modal error message. ¥ Oﬄine Read: ¥ Client allows read operations but no write operations on locally cached data. ¥ Oﬄine Read & User-Exclusive Write: ¥ Client allows atomic read operations on any data and write operations on user- exclusive, locally cached data. ¥ Oﬄine Read & Atomic Write: ¥ Client allows atomic read/write operations on any locally cached data. ¥ Oﬄine Transactional Read / Write: ¥ Client allows non-atomic (transactional) read/write operations on any locally cached data. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 8 Version Control Architecture DeÞnition: Version control involves systematically versioning all source code artefacts in a Version Control System (VCS) like subversion or git. We have several phases: - Development phase - Alpha phase - Beta phase - Release candidate phase - Release phase - Maintenance phase Branching strategies: - Vendor branch: - holds unchanged copies of third-party sources - Regularly integrated into trunk for potential modiÞcations - persists as long as product exists - Trunk (M Branch): - Maintains currently integrated state of next major version (M) of the product - Persist throughout productÕs lifecycle - Feature branch: - Derived from Trunk or another feature development branch - Contains the changes during development of new feature - Regularly synchronised with trunk through merging or rebasing - Integrated into trunk at end of feature development and deleted after - Release Branch (M.N Branch) - Branched from trunk usually after beta phase and before release candidate phase - Receives bug Þxes from trunk via cherry picking - Used for creating release versions - Persists as long as version M.N is not end-of-life - Hot-Þx branch (M.N.K) - Derived from M.N Branch when needed, typically just before Þrst hot Þx Assembly Process Architecture In the assembly process architecture, DevOps pipeline is used to transition from version of software in the version control system (CVS) to a running instance in operations. DevOps Pipeline phases: - Development (build standard process): automated through continuous integration (CI) - Operations (Deployment standard process): automated through continuous deployment (CD) Assembly process: acts as a state machine, ensuring meaningful backward activities for all forward activities for roundtrip capabilities Short circuit transitions: - Up to 4 short circuit transitions for eﬃcient ÒDeveloper LoopÓ in software development - Shortcut from build standard process to deployment standard process Four types of external storage locations: - Version control system: stores raw source Þles - Source Distribution site: stores the source Þle for the build process - Binary Distribution site: stores binary Þle for deployment - Artefact repository: stores reusable build artefacts, especially libraries Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Data transfer: - The binary distribution site facilitates data transfer between development and operations - First three storage locations mainly facilitate data transfer between individuals Environments and Quality Assurance We have development environments, operation environments, and testing approaches. Development environments: - Development: e.g developerÕs workstation - Integration: e.g central server with continuous integration system - Test: e.g central server resembling production environment - Sandbox (optional): server that is copy of test for training and showcase Operations environments: - Staging: Copy of production environment - Dry-run: 1:1 copy of Staging - Production: Regular production environment - Failover: 1:1 copy of Production Testing approaches: - Unit testing: functionality testing of components on development environment - Integration testing: testing interaction of component on integration environment - System testing: testing function/non-function aspects of entire system on test environment - User acceptance testing: testing end-to-end functional of entire system on staging environment - Operation testing: testing availability of entire system on production environment To transfer artefacts between the 8 environments we use: - Development environments: utilise a version control system and an artefact repository - Operations environments: employ a corresponding artefact repository DevOps Toolchain DevOps Toolchain: Advised for support a DevOps approach on tool-side - Utilises a pattern where an Actor acts between two stores, processing Artefacts as inputs and outputs - Actors triggered by events or controlled by diﬀerent groups through interactions DevOps Pipeline Pattern: - Developer commit in Version Control (VC) system triggers automatic compilation and integration in continuous integration (CI) system - Results stored in artifact respository (AR) triggering automatic installation in continuous deployment (CD) system. - Installed application on run-time system accessible by testers and users Logical system: - VC and CI belong to development - CD and RT systems belong to operations - AR system used as common transfer points for both areas DevOps toolchain distributed across logically / physical separated environments Artifact types: - source component (foo.java), intermediate component (foo.jar), target component (foo.exe) Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Special cases: - Development environment unique for fast Òedit-build-install-start-stopÓ loop - AR system can exist 1 or 2 times based on the interweaving of Development and Operations. - Manual triggering of Deployment in the Production Environment via Infrastructure Automation system. Software ReÞnement Process - Software development is in principle a reÞnement process - From speciÞcation to service, various steps performed which represents value creation chain - In each step, previous artefact is reÞned with help of added resources - First steps to go from concrete speciÞcations to maximally reusable software package - Next steps to go from software package to concrete service Software Release Management In software release management, the releases of software controlled by 7 dimensions. - Evolution Stages (about Type of product and development stage: - Pre-stages: wireframe, prototype, proof-of-concept - Production-ready stages (based on target technology): walking skeleton, minimum-viable product, full product - Version number (product identiÞed by three numbers) - Major and minor version: refer to content of product - Revision: refers to maturity level of product - Maturity levels: - Alpha (incomplete, unstable) - Beta (complete, unstable) - Release candidate (complete, stable) - Release and release update - Points-in-time: Indicates state of current release (Development, snapshot, normal release) - Product editions: - Community/Enterprise edition (focus on target market) - Standard/Professional edition (focus on functionality) - Availability scopes - No availability (only internals) - Limited availability (special situations) - Early availability (early adopters) - General availability (all customers) - No coloration with maturity level - Distribution channels (should linked directly to VCS branches) - Bleed Channel (for visionary and die hards) - Edge channel (for early adopters) - Stable channel, solid channel (for all customers) Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 9 Think Clearly Important for architect to think clearly about problems. Exists a four stage ÒThink ClearlyÓ process, go through once or iteratively. First two are about acting analytically and objectively to diverge the problem. Collect many facts and build hypothesis. Last two are about acting subjectively, creatively, and courageously to converge the problem. Reduce hypothesis to a theory and integrate to the solution. Four distinct disciplines: - Investigate and research: Þnds facts with own knowledge/ research, verify through sources and classify with tags. - Structure and sort: sort facts, group via tags, connect related facts across groups, and sort facts in each group - Reduce and complement: replaces facts or renames, adds missing ones, prioritise certain facts, and discard irrelevant facts - Integrate and present: specialise or generalise facts if necessary, combine facts and convert into target presentation Problem Solving Heuristics DeÞnition: Experience-based techniques for problem solving when other approaches are ineﬀective Purpose: primarily for inspiration, preventing circling around problem, and Þnding new solution approaches. - Research: Investigate facts. - Brainstorming: Generate a large number of spontaneous solution ideas. - Analogy: Think about similar already-solved problems. - Reduction: Transform the problem into a previously solved one. - Abstraction: Solve the problem in a more abstract model. - Generalisation: Generalise the problem to one with fewer special cases. - Specialisation: Seek inspiration from a speciÞc case. - Variation: Change your perspective on the problem. - Lateral Thinking: Approach the problem indirectly and creatively. - Hypothesis Proof: Seek a solution by proving or disproving a possible Þctional solution. - Root Cause: Investigate the problem step by step. - Means End: Approach the solution in small steps. - Backward Search: Work backward from a Þctional solution. - Backtracking: Choose a partially new path after a failure toward the solution. - Divide & Conquer: Break the large problem into smaller, more manageable sub-problems. - Trial & Error: Try all possible solution combinations as a last resort or in a small solution space. Technology Life-Cycles We can classify a technological product using two models: Gartner Hype-Cycle for emerging technologies or Moore technology adoption life-cycle Gartner Hype-Cycle: - Illustrates typical life cycle of technology - Phases (x-axis): Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 - Innovation trigger - Peak of inßated expectations - Trough of disillusionment - Slope of enlightenment - Plateau of productivity - Customer exceptions (y-axis): - Reßects maturity of technology - Indicates market expectations at each stage Moore technology adoption life-cycle: - Describes technology adoption in various market types - Market participants: - Innovation: larger businesses, more risk oriented - Early adopters: younger, educated - Early majority: more conservative but open to ideas - Late majority: older, less educated, - Laggards: very conservative, oldest and least educated - Chasm - Represents a challenging gap between early market and mainstream market - Innovators dilemma - Maximum achievable market share follows S-curve over time - Critical points around 25% (the chasm) and 50% market share Open Source Software DeÞnition: - Software released under Open source license - Allows free distribution and modiÞcation of source code - Prohibits discrimination against people or purposes Open source personality streams: - Software sharing: political individuals advocating for social justice - Software hacking: artistic individuals with maximalist approach to SE - Software engineering: pragmatic individuals using SE in practical applications Open source licenses: Hundreds of licenses, categorised into a few classes based on strictness in protecting software Sorted by their copyleft eﬀect (clauses to keep freedom for original software and its extensions) No copyleft: Creative commons zero (CCO) - nearly unrestricted use Weak copyleft: Apache license oﬀering moderate protection for software and author Strong copyleft: Aﬀero general public license provides protection even in SaaS scenarios Back of the Envelope Calculation To get better feeling for scope and diﬃculty of an architecture, good idea to do back of envelop (rough calculation). Methodology: - Create two column table in spreadsheet with numbers and units - Enter known business-given key Þgures - Enter technology-given key Þgures - Conversion and comparison: perform comparison between the business and technology Þgures, unit-wise converted - Insights and decisive points: colour rows which provide crucial insights Method allows for identiÞcation of key insights and potential architecture deÞning points Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Weighted Decision Matrix Method to make decision transparently and comprehensibly (not necessarily objectively) and at same time documenting decision process. Decision to be made is choice among many alternatives Steps: - Setup: spreadsheet with alternatives as columns - DeÞne criteria for decision making: aim for concise set distinguishing alternatives - Weight assignment to each criterion - Evaluation: assess each alternative against every criterion - Calculation and decision Focus Area Maturity Model FAMM is a method to access maturity of an organisation with respect to a topic area. Big Picture: Method 8-D 4 business related and 4 technical dimensions to create a Big Picture in early stage. 1. Elevator pitch: overview with name, actors, purposes, devices. Outline solution in few sentences 2. Crux Flash: highlight key functionality, cruxes, and challenges 3. Customer Journey: describe actor roles and use cases in table 4. Dialog storyboard: present user interface through wireframe graphs and dialogue storyboard 5. Quality requirement: specify qualities and expectations in a table 6. System architecture: depict actors, layers, tiers, programs 7. Data model: represent entities and relationships with UML Class diagram 8. Sizing sketch Enables clear documentation and comprehension of system. Viewpoints & Perspectives In order to create architecture description (IT Konzept) for an application, one documents via Viewpoints and perspectives. Viewpoints are 2 dimensional diagrams with explanation of a single fact. Perspectives are explanation of an issue. Both derived from non-functional requirements Functionality (systemÕs functional elements) and information (static data structures and information ßows) most important viewpoints. Project Management Essentials in Software Engineering Understanding Project Management: ¥ Integral discipline alongside Software Architecture. ¥ Primary goal: Maintaining balance in the "Iron Triangle" Ð Time, Cost, and Scope. Iron Triangle Components: ¥ Time: ¥ Schedule (When?) ¥ Velocity (How rapid?) ¥ Cost: Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 ¥ People (Who?) ¥ Resources (With?) ¥ Scope: ¥ Functionality (What?) ¥ Quality (How well?) Adjusting the Balance: ¥ Any change in one aspect aﬀects the others, necessitating adjustments. ¥ Time, Cost, and Scope are interconnected; altering one requires adjustments in the remaining two. Trilemma Concept: ¥ Only two of three factors can be prioritised simultaneously: ¥ Cheap and good (e.g., Open Source Software) but not fast. ¥ Good and fast (e.g., Custom Software Development) but not cheap. ¥ Fast and cheap (e.g., "Quick Hack") but not good. Responsibilities of Non-Project Managers: ¥ Non-project managers are crucial in the Scope aspect. ¥ Changes in Scope often require a deep technical understanding of the application. Key Takeaway: ¥ A foundational understanding of Project Management is essential for maintaining balance and successful software engineering outcomes. Project Management Building Blocks UniÞed Structure: ¥ Every project management process in software engineering is constructed from the same set of building blocks. Building Blocks Characteristics: ¥ Structure: ¥ Can be part of the process (occur). ¥ May not be present at all. ¥ Could appear once or multiple times. ¥ Properties: ¥ Applied during the process. Adapting Existing Processes: ¥ Utilise deÞned building blocks to understand and modify an existing process. Creating a New Process: ¥ Execute Steps 1 to 12 in the speciÞed order. ¥ Choose building blocks to form the process. Flexibility: ¥ Each building block can be tailored based on the speciÞc project management requirements. Key Concept: ¥ Understanding and implementing project management processes involve assembling and adjusting these fundamental building blocks as needed. Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 List of questionsÉ Week1: Welche beiden Klassen von Software werden vor allem mit Hilfe des Ansatzes Custom Software Development entwickelt? Welchen Software-Entwicklungs-Ansatz sollte man wŠhlen, um ein komplexes betriebliches Informationssystem zu realisieren? Welchen Software-Entwicklungs-Ansatz sollte man wŠhlen, um eine komplizierte wiederverwendbare Bibliothek zu realisieren? Ist Software Engineering auch fŸr die Entwicklung einer nicht-komplexen Software in einem kleinen Team von zwei Personen sinnvoll? Ist ein extrem agiles Vorgehen mit stŠndigem Refactoring im Sinne des TRUE Manifesto fŸr Software Engineering? Wieviele Zyklen kennt man im Workßow Model des Software Engineering, in denen jeweils die Personen mit Šhnlichen Neigungen agieren? Welche Disziplinen im Software Engineering werden als die beiden Kšnigsdisziplinen angesehen? Week2: Was beschreibt das Workßow-Modell im Software Engineering? Welches Konzept erlaubt einem am besten zu verstehen, welche AktivitŠten in einem Software Engineering Prozess durchgefŸhrt werden mŸssen? Wie wird trotz Arbeitsteilung eine maximale Auslastung des Teams im Software Engineering erreicht? Welchen Fokus hat die Software Requirements SpeciÞcation? Wie wird die Software Engineering Phase genannt, welche den grš§ten Personalbedarf besitzt und in der primŠr die fachlichen FunktionalitŠten realisiert werden? Was wird insbesondere in der Projektphase ÒElaborationÓ entwickelt? Welche Art von Requirements sollte der Architekt primŠr im Auge haben und sollten von ihm explizit in der LšsungsÞndung addressiert werden? Nennen Sie 3 in der Praxis hŠuÞg zu berŸcksichtigende Non-Functional Requirements! Week 3: Wie kann man Architektur deÞnieren? †ber welche vier Aspekte kann man Architektur aufspannen? Kann man Angemessenheit oder Schšnheit allgemein messen? Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Kann man Angemessenheit oder Schšnheit im Kontext einer einzelnen Person messen? Wieso gilt Architektur als die ÒKšnigsdisziplinÓ im Software Engineering? Muss sich Architektur primŠr um komplexe oder komplizierte Aspekte eines Systems kŸmmern? Aus welchen drei Dimensionen besteht der IT Architecture Space? Welche vier Arten von Architektur kennt man in der IT? Was sollte eine Architecture Description (ITKonzept) neben dem WAS vor allem dokumentieren? Was sollte eine Architecture Description (ITKonzept) Ÿber Insights (Einblicke) vor allem addressieren? Aus GrŸnden der Risikominimierung sollte der ITArchitekt beim Stepwise ReÞnement schrittweise immer wie vorgehen? Week 4: ZŠhlen Sie mindestens 4 wesentliche Architecture Principles auf! ZŠhlen Sie mindestens 7 Eigenschaften/Aspekte auf, die eine Komponente besitzt! Was sind die beiden wichtigsten Wege, um in der Praxis einen Komponenteschnitt zu Þnden? ZŠhlen Sie mindestens 8 Eigenschaften/Aspekte auf, die eine Schnittstelle deÞnieren! ZŠhlen Sie mindestens 4 Eigenschaften/ Charakteristiken von guten Schnittstellen auf! Welche drei Komponentenkategorien kennt man auf der Ebene der Macro Architecture (aka System Architecture)? Welche drei Komponentenkategorien kennt man auf der Ebene der Meso Architecture (aka Software Architecure)? Welche fŸnf Komponentenkategorien kennt man auf der Ebene der Micro Architecture (aka Programming)? Was ist der wesentliche Unterschied zwischen einer Library und einem Framework? Week 5: Warum sind Architekturmuster interessant? Wie nennt man die entstehenden Einheiten, wenn Code oder Daten horizontal geschnitten werden? Was ist der Unterschied zwischen den LayerPŠrchen Front/Back End und Client/Server? Wie nennt man die entstehenden Einheiten, wenn Code oder Daten vertikal geschnitten werden? Wie nennt man die Slices eines Tiers, welche als getrennte Programme ausgefŸhrt sind, die sich jeweils um bestimmte fachlich abgeschlossene FunktionalitŠten kŸmmern? Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Mit Hilfe welcher Flow Architecture kann man N Komponenten so miteinander verschalten, da§ statt N x (N - 1) / 2 nur N Kommunikationswege entstehen? Mit welcher Process Architecture wird in der Praxis Ÿblicherweise ein Process/Thread Pool verwaltet? Welche einfache Cluster Architecture kann man einsetzen, wenn die Read-Performance einer Server-Anwendung gesteigert werden soll? Mit welcher Network Architecture kann man mehrere Knoten miteinander kommunizieren lassen, ohne da§ diese Knoten sich jeweils untereinander genau kennen mŸssen? Wie nennt man einen Rechnerknoten, der als Stellvertreter fŸr einen Zielknoten agiert? Welches bekannte Web-Protokoll nutzt eine auf Unicast, Stream und Pull basierende Kommunikation? Week 6: Nennen sie 3 Data Evolution Approaches, die es jeweils erlauben, auf die frŸheren StŠnde der Daten zuzugreifen? Wie nennt man den Ansatz, bei dem Daten von einem Master-System auf viele Slave-Systeme repliziert werden? Wie nennt man die Anwendungs-Architektur, bei der die gesamte BenutzeroberßŠche autonom auf dem Client lŠuft, wŠhrend der Server nur rein fachliche Services liefert? Wie hei§en die Web-Anwendungen, welche eine Rich Client Architektur umsetzen? Bei welcher Client-Architektur bietet die BenutzeroberßŠche die hšhere Reaktionsgeschwindigkeit? Mit welchem Layer-Pattern werden in einem Informationssystem die Interaction Components von den Service Components entkoppelt? In welcher Reihenfolge werden die Komponenten einer Anwendung gebaut? Welche zwei wesentlichen Anforderungen erfŸllen Reactive Systems? Was charakterisiert Reactive Systems in Bezug auf ihre Datenverarbeitung? Week 7: In welche zwei Klassen lassen sich formale Sprachen (Formal Languages) aufteilen? Ist die Technologie-Plattform Node.js geeignet, um auf der Ebene des Betriebssystems ein KernelSubsystem zu implementieren? Aus welchen drei Bestandteilen besteht eine Technology Platform? Aus welchen zwei zusŠtzlichen Bestandteilen besteht ein Technology Stack gegenŸber der Technology Platform? Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Welche zwei Bestandteile eines Technology Stack sind am ÒinvasivstemÓ fŸr das Programmiermodell? Wie sorgt man in einer Rich-Client Architecture dafŸr, da§ die zahlreichen technischen Aspects einer BenutzeroberßŠche adressiert werden? Bei welcher Art des Software Deployments wird die Application mit allen ihren AbhŠngigkeiten und einem Teil des Betriebssystems gebŸndelt installiert? ZŠhlen sie mindestens 5 der 8 Cloud Characteristics auf, die eine Resourcen Bereitstellung erfŸllen muss, damit es als Cloud Computing gilt! Bei welchem Cloud Approach wird nur Network und Computer bereitgestellt? Auf welchen zwei wesentlichen Aspekten basiert die Cloud-Native Architecture? Was bietet die Cloud-Native Architecture den Microservices der Anwendung? Wieso kann eine Ofßine-FŠhigkeit von Anwendungen im Kontext von Cloud Computing entscheidend sein? Week 8: Welche fŸnf Arten von Branches kennt man in einem Version Control SystemÒ? Welcher Art von Branch in einem Version Control System wird Ÿblicherweise nach der erfolgreichen Integration wieder gelšscht? Zwischen welchen beiden zeitlichen Phasen des Release-Managements wird in einem Version Control System Ÿblicherweise der Release-Branch vom Trunk abgezweigt? Wieso sollten in der Assembly Process Architecture bis zu vier sogenannte Short-Circuit Transitions zur AbkŸrzung vom Build Standard Process zum Deployment Standard Process unterstŸtzt werden? Welche vier Arten von externen Speicherorten kennt die Assembly Process Architecture? Wie hei§t die Kopie des Production Environments, auf dem u.a. (User) Acceptance Testing durchgefŸhrt wird? Welche beiden Actor-Systeme steuern beim DevOps Pipeline Pattern den automatisierten Integrations- und Installations-Prozess? Software-Entwicklung kann als Wertschšpfungskette verstanden werden. Welches Artefakt ist das maximal wiederverwendbare? Bei welchem Maturity Level im Software Release Management hat man eine noch unvollstŠndige und instabile FunktionalitŠt? Bei welchem Maturity Level im Software Release Management hat man eine bereits vollstŠndige aber Ÿblicherweise noch instabile FunktionalitŠt? Downloaded by Li Mo ([email protected]) lOMoARcPSD|39768292 Week 9: Im Think Clearly Prozess zum ÒKlardenkenÓ soll man Ÿber die ersten beiden und die letzten beiden Disziplinen wie denken? Wann ist die recht profane Problem Solving Heuristic namens Trial & Error akzeptabel? Welches Modell eines Technology Life-Cycles bildet den Reifegrad einer Technologie Ÿber die Zeit ab? Welches Modell eines Technology Life-Cycles bildet die Akzeptanz einer Technologie in verschiedenen MŠrkten ab? Wie nennt man den Effekt in Lizenzen von Open Source Software, bei dem dafŸr gesorgt wird, da§ die Software frei bleibt (im Sinne von Freiheit und VerfŸgbarkeit, nicht im Sinne von kostenlos) und zusŠtzlich alle ModiÞkationen und Erweiterungen ebenfalls frei bleiben? Welche Methode kann man anwenden, um ein besseres ÒGefŸhlÓ fŸr den Umfang und den Schwierigkeitsgrad einer zu entwickelnden Architektur zu bekommen? Wie kann man die qualitative Entscheidung fŸr die Auswahl einer aus vielen Alternativen transparent und nachvollziehbar treffen und gleichzeitig dokumentieren? Von wem kann man mit dem Das Focus Area Maturity Model (FAMM) den Reifegrad bestimmen? Was sollen die acht Dimensionen des 8-D Modells leisten? Welche zwei Viewpoints in der Architecture Description einer Anwendung sollten immer dokumentiert werden? Week 10: An welcher ÒStellschraubeÓ des Project Management sind in der Praxis auch die nichtProjekt- Manager stark mitverantwortlich? Ist ein spezieller Projektmanagement-Prozess im Software Engineering entscheidend? Downloaded by Li Mo ([email protected])

SEIP Notes - Software Engineering in the Industrial Practice (IN2235) PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue