From 0ed4646ee7f469352762771d5e04d931c27ce5ad Mon Sep 17 00:00:00 2001 From: Adam Date: Sat, 23 Apr 2022 19:15:16 +0200 Subject: Populating repo --- dst/ase.html | 920 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 920 insertions(+) create mode 100644 dst/ase.html (limited to 'dst/ase.html') diff --git a/dst/ase.html b/dst/ase.html new file mode 100644 index 0000000..9d6df59 --- /dev/null +++ b/dst/ase.html @@ -0,0 +1,920 @@ + + + + + +Q1. Software Process Model - Waterfall — adamski.wtf + + + +

adamski.wtf

+

Q1. Software Process Model - Waterfall

+ +

What is software engineering a response to?

+ + + +

There are no universal notations, methods or techniques for software engineering. +This is because different types of software require different approaches.

+ +

There are cases where software projects or software can fail.

+ +

Increasing system complexity

+ +

As new software technology helps us to build bigger, more complicated systems, the requirements change.

+ +

Systems need to be developed and delivered faster meaning more complicated systems are required. +This means more requirements for the systems.

+ +

Failure to use software engineering methods

+ +

It is easy to develop programs without using software engineering techniques… BUT +This can result in more expensive software development and less reliable, readable systems. +To solve this issue, more education and training is required on these techniques.

+ +

Software engineering process activities

+ +

Software specification

+ +

This is where the clients and the developers define the software that should be produced. +This is where the software is limited in terms of what is should be.

+ +

Software development

+ +

This is where the software is designed and programmed.

+ +

Software validation

+ +

This step ensures that the software does what the client requested.

+ +

Software evolution

+ +

When software is modified to meet client’s or the market’s new requirements.

+ +

What is a software process model

+ +

A software process model is a set or related activities that leads to a software product. +An abstract descriptions of high level software processes. +These can be used to explain different approaches to software development. +These can be interpreted as frameworks that can be expanded and personalized to create more specific software engineering processes.

+ +

Waterfall model

+ +

The model takes the fundamental software process activities. +Seperate process phases: +- Requirement specification +- Software design +- Implementation +- Test

+ +

Incremental/iterative development

+ +

This approach combines the activities with specification, development and validation. +The system is developed in a series of versions (increments) +Each version adds some functionality on top of the previous version.

+ +

Integration and configuration

+ +

This approach depends on the availability of reusable components or systems. +The systemdevelopment process focuses on configuring these components to be used in new contexts and integrate them with the system. +This lets you reuse code from previous projects and save time and money.

+ +

Waterfall model

+ +

Activities are done in a sequence. +Handover of workproducts between phases and milestones are used to monitor progress. +Waterfall model is an example of a plan-driven process. +You are supposed to have all of the process activities and phases planned out before you start development. +The phases in the model directly reflect the fundamental development activities.

+ +

Requirements analysis and definition

+ +

The systems services, limits and goal and made concrete through consulting with the users. +They are then defined in detail and are used as the system specification.

+ +

System and software design

+ +

The overall system architecture is established in this phase. +Identify and describe the fundamental system abstractions and their relations (UML)

+ +

Implementation and unit testing

+ +

The design is implemented in the indivivual program parts. +The design is tested to verify that it meets the specification.

+ +

Integration and system testing

+ +

The individual program parts are integrated and the whole system it tested. +The software is delivered to the client.

+ +

Operation and maintenance

+ +

The system is now installed and in use. +The system is maintained to any issuse that weren’t found earlier. +The system is improved over time.

+ +

When should you consider using waterfall?

+ +

For software that needs to be flexible while it is being developed.

+ +

Embedded systems

+ +

The software must interface with hardware. +In this case the hardware is not flexible, thus the software must be.

+ +

Critical systems

+ +

When total security is a requirement of the specification and design. +These systems must have finite specifications and design documents.

+ +

Large software systems

+ +

Part of a larger system being developed by several parties. +This makes finite specifications extremely necessary.

+ +

How can I decide on waterfall? - analyse home ground

+ +

When one phase ends another begins. +Steps come ordered and don’t allow for going back and redoing parts. (waterfall flows only down) +When the requirements are mostly unchanging.

+ +

Plan driven versus agile processes?

+ +

Activities in sequence versus all activities at the same time. +Agile development is very flexible and the requirements may be constantly changing.

+ +

Incremental model

+ +

You can iterate within increments and the increments can be planned. +You work within fixed time slots and update the project backlog continuously. +Incremental is an agile process, where you end with multiple versions that you can show the clients as the project progresses. +This allows for the client to come with feedback along the way.

+ +

Integration and configuration

+ +

Development risk is reduced by reuse but there is the risk of not being able to make the desired changes at all or in the time frame. +Most projects have some level of code reuse. +This is often informal. +This reuse requires looking for the existing code, changing them to meet the requirements and integrating them with the new code.

+ +

Q2. Software Process Model - Incremental/iterative

+ +

The incremental development is based on the idea that: +1. Develop in prototypes. +2. Get feedback from the users and others. +3. Develop over multiple versions until the required system is produced.

+ +

Incremental development is the most common approach to developing applications and software.

+ +

Can it be both plandriven and agile?

+ +

Yes, it can be either one or a mix of both.

+ +

Plan-driven approach

+ +

Identify the system increments in advance. +A predictable waterfall plan is split into parts.

+ +

Agile approach

+ +

The early increments are identified. +The later increments depend on progress and the clients priorities. +You work in fixed timeframes and update the full project backlog as you go.

+ +

Agile-manifest (balance/mix)

+ +

Focus on the individuals and teamwork rather than the processes and tools. +Good software comes before comprehensive documentation. +Work with the client instead of using contract work. +Deal with changes instead of sticking to the plan.

+ +

What are advantages of incremental?

+ +
    +

  1. Development costs are reduced +The amount of analysis and documentation that has to be redone is much less than waterfall.

    2. +

  2. It is easier to get client feedback +The clients can comment on demonstrations of the different versions and see the progress.

    3. +

  3. Earlier delivery of new software +New features can be made available even if they are not fully completed.

    4. +
+ +

What disadvantages are there?

+ +
    +

  1. The project is not visible +Managers can have difficulty measuring progress. +It would be a waste of resources to produce documents that reflect the different versions.

    2. +

  2. The system structure can get messy over time +Changes lead to messy code. +It gets increasingly difficult to add new functions to a system. +Large, complex systems with large teams struggle with incremental for this reason. +Large systems need a stable architecture. +Responsibility of the different teams needs to be clear with respect to this architecture. +This has to be done in advance.

    3. +
+ +

Q3. Software Process Model - Integration and configuration

+ +

What are the phases?

+ +

Requirements specification

+ +

The inital requirements are suggested +They don’t need to be developed in more detail. +They should include short descriptions of important requirements and desired functionality.

+ +

Software discovery and evaluation

+ +

With the overview of the requirements, components are searched for that provide the necessary functionality.

+ +

Requirements refinement

+ +

The requirements are polished with the knowledge of the reusable components that were found.

+ +

Application system configuration

+ +

If an application that meets the requirements is available, it is configured for use in the new system.

+ +

Advantages/disadvantages

+ +

This model reduces the amount of software that must be developed. +This in turn, reduces the costs and risks.

+ +

You usually don’t have control of the software that is being reused. +This can include for example how and when new version are released and how the functionality is changed.

+ +

Q4. Comparison of plandriven and agile including Homeground

+ +

What is the difference between plandriven and agile?

+ +

Plandriven

+ +

Plandriven means the desired result can be predicted. +Plandriven = waterfall. +Plandriven is an approach where the development process is planned in detail. +A project plan is created that registers the work that needs to done, who should do it the development plan and the work tools. +Managers use this plan to support project decisions and as a way to measure progress. +This is a traditional approach to software development.

+ +

Agile

+ +

Agile expects changes and frequent user inspection to get the best results. +Agile = Iterative, more detailed Scrum and XP +Agile methods are iterative, the software is developed and delivered in stages. +These versions are not planned in advance but are chosen underway. +Decisions on what should be included in a version depend on the clients priorities.

+ +

How does Böhm/Turner define primary factors?

+ +

Application

+ +

Agile

+ +

Goal: to handle changes in the project. +Small teams. +Environment is turbulent and fast-paced, project focused.

+ +

Plandriven

+ +

Goal: predictability, stability and security. +Larger teams and projects. +Environment: stable, few changes, organisation focused.

+ +

Management (onsite, qualitative control, tacit knowledge)

+ +

Agile

+ +

Customer relations: dedicated clients on site, focused on prioritised changes +Planning and control: qualitative control. Who and how doensn’t matter as long as it gets done. +Communications: Tacit knowledge. People do things without needing much explanation or discussion.

+ +

Plan-driven

+ +

Customer relations: More formal and infrequent. Focused on contract decisions. +Planning and control: Documented plans, quantitative control. It is important to know who does what. +Communications: Explicit. Plans must be discussed and verbalized and shared with the others.

+ +

Technical

+ +

Agile

+ +

Requirements: can withstand unpredictability. +Development: simple design, small increments, refactoring is assumed to be cheap. +Test: Test cases define the requirements.

+ +

Plan-driven

+ +

Requirements: Formal project, user interface, quality, predictable requirements. +Development: Comprehensive design, larger intervals, refactoring is costly. +Test: Documented testplans and procedures.

+ +

People

+ +

Cockburn characteristics can describe a programmers personality. +One type may be more favourable than another depending on agile/plan-driven approach.

+ +

5 axis on the Home Ground Decision tool

+ + + +

What is continuous integration and how does it relate to agile?

+ +

As soon as the work on a task is complete, it is integrated into the whole system. +After such integration, all the unit tests must pass. +Continuous integration uses tools to automate the process. +Depends on unit tests. +Does NOT remove the need for tests.

+ +

Prototype development

+ + + +

Q5. Key features of SCRUM

+ +

Openness of all work. +Respect each other. +Focus on the common goal. +Courage for difficult decisions. +Duty to the common goal.

+ +

3 roles. +5 events. +3 artifacts.

+ +

Assets

+ + + +

Three pillars

+ +

Transparency: Everyone knows what needs to be done and who is doing what. +Inspect: Keep an eye on where we are heading (daily meetings). +Adapt: Change if it is necessary.

+ +

Core values

+ +

Commitment: to reach the sprint goal. +Focus: on what needs to be done in the sprint. +Openness: Communication is key, don’t hide issuse. +Respect: for each other +Courage: to do the right thing

+ +

Typical errors

+ +

Scrum master is a manager. +No communication with the client. +New tasks are added to the sprint backlog in the middle of a sprint.

+ +

Daily SCRUM

+ +

Inspect progress towards the sprint goal. +Adjust the backlog accordingly. +Update (how far are we?) +Short meeting (15 min) +Tell the others if you need help.

+ +

Sprint planning

+ +

Work together with the whole SCRUM team for sprints. +Look in the backlog. +Make a sprint backlog. (this can’t be changed from the outside)

+ +

Sprint review

+ +

Check development status. +Sprint review max 4 hours with sprints of 4 weeks. +The client participates along with the team. +Only talk about what has been done. +Dialogue, no presentation. +Update the backlog.

+ +

Sprint retrospective

+ +

For increasing quality and effictivity. +What went well/bad? +How can this be improved for the future?

+ +

Roles

+ +

Product owner

+ +

Stakeholder contact +Updates/prioritises the product backlog +Can be a person dedicated to the client +The goal is the maximise product value +Can delegate but is responsible

+ +

SCRUM master

+ +

Ensure everyone is keeping in-line with SCRUM +Not the management leader +Ensure the team is effective +Deal with the teams blockages

+ +

Developers

+ +

They own the backlog +Programmers, UI, UX and so on

+ +

Q6. Key features of XP - eXtreme Programming

+ +

What is XP?

+ +

An agile, incremental development method with focus on: +- Collaboration +- Quick and early software creation +- Skillfull development practices +XP takes all the ‘good things’ the extreme. (testing, pair programming).

+ +

The customre should be available full time for the use of the XP team. +In XP, the customer is a member of the dev team and is responsible for bringing requirements.

+ +

Pair programming: developers work in pairs, checking each other’s work to ensure quality.

+ +

Qualities of XP that fit to SCRUM

+ +

Pair-programming. +Writing unittests before the code (with the help of TDD). +Partners often have to integrate their code (use continuous integration). +Refactor as often as possible. +Collective ownership of code. +Customer on-site, user stories, planning game, …

+ +

What does XP and SCRUM have in common?

+ +

Work should be done incrementally/iteratively. +Teamwork, transparency, communication and prioritisation are crucial. +Requirements are broken down into bite-size pieces. +There is overlap with the roles. (XP client and SCRUM’s product owner)

+ +

What values are XP based on according to Larman?

+ +

Communication, simplicity, feedback, courage.

+ +

Communication

+ +

Pair programming +Customer on-site +Acceptance test +Daily standup (short meetings)

+ +

Simplicity

+ +

Teams implement exactly what was asked for. Nothing more. +Strive for simple designs and quality code.

+ +

Feedback

+ +

Early and frequent feedback is crucial. +Feedback can come from unittests, team members and the client. +Continuous integration. +Acceptance test that the client performs. +Short sprints.

+ +

Courage

+ +

Developers should be honest. +Don’t make excuses for issuse. +Don’t be afraid to make big changes.

+ +

How is XP extreme?

+ +

E.g. If tests are good, do them all the time. +Takes all good things, and places them at the core of the process.

+ +

Name some key practices in XP?

+ +

Unit test, pair review, customer on-site, continuous integration, testing, early test, unit test, TDD.

+ +

What is a user story?

+ +

Brief feature request, a promise for conversation. +Written on a card with criteria for confirmation on the back.

+ +

Story maps - User story mapping

+ +

To see the bigger picture of the user stories. +To understand how things are now and to imagine how they could be. +Visualize the stories you tell about your software.

+ +

Story maps consist of: +* User + - a card that tells a story about a type of person, doing something to reach a goal. +* Activities + - Jobs done by similar people to reach a time +* Backbone + - Activies and jobs on a higher goal tier, give the user story structure. + - This is a big goal, that the little goals are attached to. +* User tasks + - Short, concise sentences that explain the goal. +* Sub-tasks + - Break down more complicated goals. +* Release slices + - Identify tasks. The smallest number of tasks that allow specific users to reach their goal.

+ +

Story map process has 4 levels

+ +

What is the format a user story?

+ +

“As a I want so that ”. +Who, what, why.

+ +

How does XP describe Lifecycle for a System?

+ +

Exploration, planning, iterations to first release, productionizing, maintenance.

+ +

What is the iteration called in XP?

+ +

Iteration

+ +

Q7. Product Planning: Requirements Elicitation, Product Vision, Product Roadmap

+ +

What main requirement activities are there?

+ +

Elicitation and analysis of needs. +Specification of requirements. +Validation of requirements.

+ +

Elicitation and analysis of needs

+ +

There are two fundamental approaches to Requirement Elicitation: +1. Interview, where people talk about what they are doing. +2. Observation or etnography, where you observe how people do their work and which technologies they use and so on.

+ +

Use a mix of interview and observation to gather information. +This can be used to find the requirements that form the basis of further discussion.

+ +

Requirement specification

+ +

Is a process in which you write down user and system requirements into a document. +Ideally, these requirements should be clear, consistent, complete and easy to understand. +User requirements should be written in natural language and supplemented with dialogue and tables in the document. +System requirements can also be written in natural language, but other notations, graphs, maths, etc can also be used. (state machines, automata)

+ +

Requirement validation

+ +

Is the process of controlling of ensuring that the system requirements will are really what the client wants. +There are different checks that can be used to validate the requirements.

+ +
    +

  1. Validity checks: +Check if the requirements reflect the users real needs. +User needs can change over time, so this is an important thing to keep track of.

    2. +

  2. Consistency checks: +Requirements should not conflict with others.

    3. +

  3. Completeness checks: +The requirement specification should be comprehensive for every function and the limits that the client wants.

    4. +

  4. Realism checks: +Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame.

    5. +

  5. Verifiability: +You should be able to create tests that verify whether or not a requirement is met.

    6. +
+ +

Requirement validation techniques

+ +
    +

  1. Requirement reviews +Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts.

    2. +

  2. Prototyping +Develop executable models of the system and verify with the client that it meets their expectations.

    3. +

  3. Test-case generation +Tests can be designed along with requirements instead of after the fact. +If it is difficult to design tests for a requirement, that can mean the requirement is unrealistic.

    4. +
+ +

What are the steps in elicitation?

+ +
    +

  1. Discovery & Classification +This is the process of interacting with the stakeholders to find their requirements.

    2. +

  2. Categorization +Take the unstructured list of requirements and group related requirements together.

    3. +

  3. Prioritization & Negotiation +Conflicts can arise when there are multiple stakeholders. +Prioritize the most important requirements, through negotiation, discussions, compromises and meetings.

    4. +

  4. Documentation +Here the requirements are documented.

    5. +
+ +

Why is it difficult to elicit requirements?

+ +

Many stakeholders with conflicting needs. +Stakeholders speak their own “language”. +Lack of communication because things are assumed to be “obvious”.

+ +

What is a recognized way to communicate requirements?

+ +

Stories, Scenarios.

+ +

How are requirements documented in Waterfall and in SCRUM, in Product Planning?

+ +

Waterfall: Verify the requirement specificatino with strict change management. +SCRUM: Product vision and product backlog, are discussed and updated every sprint. +Product Planning: Product vision, release plans and/or product roadmaps. +XP: User Stories.

+ +

How are requirements negotiated with stakeholders in Waterfall and SCRUM?

+ +

Waterfall: Be up front in the requirements phase - state it now or it will be difficult later on. +SCRUM: Ongoing refinement of product backlog with stakeholders, say what is most important now, we will continue. +XP: Customer on-site.

+ +

Q8. Product Refinement and Forecasting: User story mapping, personas, stakeholders, product backlog

+ +

What is a persona?

+ +

User personas are a useful technique to describe users of your product. +A fictional character with a name, picture, relevant characteristics, behavior, opinions and a goal. +Different people can have different goals. +Understand a personas goal is useful for creating a product that is meaningful to the users.

+ +

What is a user story?

+ +

Short description on a type of user, a goal and a reason.

+ +

Where do we use the terms: Product Feature, Epic, User story?

+ +

Product Feature: Corresponds to an Epic. +Epic: A collection of related user stories. +User story: Breakdown of an Epic.

+ +

What is a user journey?

+ +

The experiences a person has, when interacting with the software.

+ +

What are the key characteristics of a product backlog?

+ +

This is to do list of items a SCRUM team must tackle. +- Software requirements. +- User stories. +- Descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.

+ +

Q9. Risk Management

+ +

A risk is a potential problem. +The possibility of loss or damage. +Risk Management: project leaders must evaluate the risks that can affect a project, monitor them, and handle them when problems arrise.

+ +

Example of risk categories

+ +
    +
  1. Uncertainty, project, technical, business.
    2. +
  2. Keyperson from team dies, a supplier is not delivering as promissed.
    3. +
+ +

Categories of risk

+ +

Project risks

+ +

Risks that threaten the project plan. +Time will be wasted and costs will rise.

+ +

Technical risks

+ +

Architectural design. +Arrises because problems can be harder to solve than expected. +Vagueness in the specification. +Project gets older and starts to decay.

+ +

Business risks

+ +

Market risk. What if no one uses the product? +Strategic risk. We don’t need that new component after all. +Sales risk. How the fuck do we sell this?! +Management risk. The top management don’t support the project anymore. +Budget risks. Budget or personnel is lost.

+ +

How do you do risk analysis?

+ +

Risk analysis and management are actions, that help a software team understand and handle uncertainty. +It is a good idea to identify risks. +Evaluate the probability of risks. +Estimate the impact of a risk and form a reaction plan for if the risk actually happens.

+ +

Identify risks and calculate risk exposure and describe consequence.

+ +

Risk exposure = probability * loss, describe consequence. +Probability < 100%. If p = 100% then it’s an issue.

+ +

Prioritize according to risk exposure, establish cut-line. +Deal with the risks above the line, accept the ones below.

+ +

Establish for each risk above the cut-line (RMMM: Risk Mitigation, monitor, management)

+ +

Mitigate

+ +

We want to prevent the risk from becoming an issue. +We can reduce the probability. +Or try to reduce the associated loss. +Risk exposure = probability * loss.

+ +

Manage

+ +

For when a risk has become a loss, try to minimize the loss. +This assumes the mitigation activity was unsuccessful. +This is done by the project leader.

+ +

Monitor

+ +

Observe how risks change over time. +How the probabilities, loss, or the environment, change over time.

+ +

How are risk management part of project management

+ +

Waterfall / plan-driven

+ +

Risk and risk plans are part of the plans in project management. +Development of others plans to contribute to identification of risk. +It is planned.

+ +

Agile - inspect and adapt is reduction to produce the right product

+ +

Daily SCRUM: Do you have any impediments? +Sprint review: Inspects risk related to product and stakeholder. +Sprint retrospective: Adresses risks related to how the team works.

+ +

What are Böhms primary risks?

+ +

Personal shortcomings, unrealistic schedule, wrong function…

+ +

Q10. How is quality defined?

+ +

Software quality attributes

+ +

Nonfunctional requirements

+ +

Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc…

+ +

Functional requirements

+ + + +

What is quality?

+ +

Quality is evaluated aesthetically, symbolically and functionally +Quality can be either objective or subjective. +Quality may not always be obvious.

+ +

Definition of quality

+ +

Quality is a reflection of one or more peoples evaluation of the compliance of a product or service with their expectations. +Quality can be broken into three types of categories: +1. Product quality. +2. Process quality. +3. Quality of expectations.

+ +

Quality tradeoffs are unavoidable. +Quality consists of: +- Quality assurance: plan or design processes to prevent bad quality. +- Quality control: track that work products meet quality standards.

+ +

Why invest or pay for Quality Management?

+ +

Cost of not doing it is bad quality - fixing errors.

+ +

Direct cost of error correction: +- Loss. (effort) +- Wasted work. (for users of the program) +- Maintenance usually has larger costs than development.

+ +

Indirect cost of error correction +- Follows from poor quality (unsatisfied users) +- Has potentially severe consequences (losing customers)

+ +

Quality Management reduces these costs significantly.

+ +

Validation (fit for use)

+ +

Are we building a system that is fit for use? +Compliance with the users expectations and experiences?

+ +

Verification (requirement specification being met)

+ +

Do we pass all tests and requirements? +Are we building a system with all the requirements implemented? +Unit/integration tests

+ +

Techniques for verification and validation

+ +

Testing: of programmes and prototypes. +Review: of specifications, documentation and programs.

+ +

Is it verification or validation?

+ +

A user must participate in order to validate. +Verification focuses on the compliance to the specifications and a client usually doensn’t participate.

+ +

V-model

+ +

Q11. Test and review

+ +

Tests are a set of practices that support verification and validation. +The purpose is to ensure a program does what it is supposed to, and to discover errors before delivery. +This is done by making sure the progrm meets the requirements and by finding incorrect or undesirable behaviour. +Verification: Unit test, component test. +Validation: prototype test, user acceptance test.

+ +

What is peer review?

+ +

Evaluation of work of one or more people with similar skills (peers). +Mostly in the form of documents but can also be analysis of code.

+ +

What is the difference between review and test?

+ +

Review is static, and there is no interaction between errors found in review. +Tests are dynamic and errors can come as side-affects of an initial errors. +Reviews (inspections) and tests are complementary to quality techniques. +Both should be used under the verification and validation process. +Inspections can control compliance with a specifications but not with the clients or users actual requirements. +(Unless the user participates in the review. Prototypes are preferred for user participation) +Inspecions cannot control non-functional properties such as performance, usability, etc.

+ +

When is review good?

+ +

For documents, designs, architectures, plans, etc.

+ +

When is test good?

+ +

For functionality and dynamic use of the program.

+ +

What is the V-Model

+ +

A model that shows the connection between tests at different levels and primary activities that drive the tests.

+ +

Name tests at different levels:

+ +

Unit test, component test, integration test, system test, user acceptance test.

+ +

Unit test: confirm valid and invalid input. +Integration test: confirm that interfaces are compatible and work as expected. +Acceptance test: validate fit for use, exploratory test.

+ +

When is test done?

+ +

Plan driven: in the end (often a dedicated test-team aspart of QA) +Agile: all the time (test competence on the team, accept criteria on story, automated test, TDD)

+ +

Q12. Configuration Management and DevOps

+ +

What is DevOps, how can you define it?

+ +

DevOps is a method for both development and operation. +DevOps is a development method for IT systems that connects different activities in projects. +DevOps is a culture, that focuses on the entire software productions life cycle. +The goal is to remove barriers between development and operation teams, to be able to react quickly to the users needs. +It is also defined by The Three Ways: +1. Flow. +2. Feedback. +3. Continuous Learning.

+ +

What is the purpose of Continuous Integration?

+ +

When the code is checked, it is automatically integrated with the system. +Speed up the rate of delivery and run tests constantly. +Bsed on tools to automate the process. +Depends on a suite of unit tests. +Does NOT eliminate the need for testers.

+ +

What is the purpose of Continuous Testing?

+ +

Continuous Testing in DevOps is a type of software test that involves testing at all stages of a develoments lifecycle. +The goal is the continuously evaluate the quality of the software.

+ +

What is the purpose of Continuous Delivery and Deployment?

+ +

Continuous Delivery

+ +

Ensure that code can be implemented securely. +Ensure that the business and service application function as expected and deliver every change to production.

+ +

Continous Deployment

+ +

Ensure that tests are automated and that every change is automatically implemented in production. +Makes the development and release process faster and more robust.

+ +

Automated access to well defined environments. +Tools like Docker for containerization or Virtual Machines.

+

adamski.wtf

+ -- cgit v1.2.3-70-g09d2