diff options
Diffstat (limited to 'dst/ase.html')
| -rw-r--r-- | dst/ase.html | 947 |
1 files changed, 0 insertions, 947 deletions
diff --git a/dst/ase.html b/dst/ase.html deleted file mode 100644 index 519af48..0000000 --- a/dst/ase.html +++ /dev/null @@ -1,947 +0,0 @@ -<!DOCTYPE html> -<html> - -<head> - <meta charset="UTF-8"> - <meta name="viewport" content="width=device-width, initial-scale=1.0"> - - <title>Q1. Software Process Model - Waterfall — adast.xyz</title> - <link rel="icon" type="image/x-icon" href="images/favicon.ico"> - <link rel="stylesheet" href="styles/style.css"> - <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css"> -</head> - -<body> - <header> - <a href="/" class="homepage-link">adast.xyz</a> - • - <a id="darkmodetoggle" class="fa fa-moon-o" onclick="switchTheme()" aria-hidden="true"></a> - </header> -<h1 id="q1.-software-process-model---waterfall">Q1. Software Process Model - Waterfall</h1> - -<h2 id="what-is-software-engineering-a-response-to">What is software engineering a response to?</h2> - -<ul> -<li>Increasing system complexity.</li> -<li>Failure to use software engineering methods.</li> -</ul> - -<p>There are no universal notations, methods or techniques for software engineering. -This is because different types of software require different approaches.</p> - -<p>There are cases where software projects or software can fail.</p> - -<h3 id="increasing-system-complexity">Increasing system complexity</h3> - -<p>As new software technology helps us to build bigger, more complicated systems, the requirements change.</p> - -<p>Systems need to be developed and delivered faster meaning more complicated systems are required. -This means more requirements for the systems.</p> - -<h3 id="failure-to-use-software-engineering-methods">Failure to use software engineering methods</h3> - -<p>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.</p> - -<h2 id="software-engineering-process-activities">Software engineering process activities</h2> - -<h3 id="software-specification">Software specification</h3> - -<p>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.</p> - -<h3 id="software-development">Software development</h3> - -<p>This is where the software is designed and programmed.</p> - -<h3 id="software-validation">Software validation</h3> - -<p>This step ensures that the software does what the client requested.</p> - -<h3 id="software-evolution">Software evolution</h3> - -<p>When software is modified to meet client’s or the market’s new requirements.</p> - -<h2 id="what-is-a-software-process-model">What is a software process model</h2> - -<p>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.</p> - -<h3 id="waterfall-model">Waterfall model</h3> - -<p>The model takes the fundamental software process activities. -Seperate process phases: -- Requirement specification -- Software design -- Implementation -- Test</p> - -<h3 id="incrementaliterative-development">Incremental/iterative development</h3> - -<p>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.</p> - -<h3 id="integration-and-configuration">Integration and configuration</h3> - -<p>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.</p> - -<h2 id="waterfall-model-1">Waterfall model</h2> - -<p>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.</p> - -<h3 id="requirements-analysis-and-definition">Requirements analysis and definition</h3> - -<p>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.</p> - -<h3 id="system-and-software-design">System and software design</h3> - -<p>The overall system architecture is established in this phase. -Identify and describe the fundamental system abstractions and their relations (UML)</p> - -<h3 id="implementation-and-unit-testing">Implementation and unit testing</h3> - -<p>The design is implemented in the indivivual program parts. -The design is tested to verify that it meets the specification.</p> - -<h3 id="integration-and-system-testing">Integration and system testing</h3> - -<p>The individual program parts are integrated and the whole system it tested. -The software is delivered to the client.</p> - -<h3 id="operation-and-maintenance">Operation and maintenance</h3> - -<p>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.</p> - -<h2 id="when-should-you-consider-using-waterfall">When should you consider using waterfall?</h2> - -<p>For software that needs to be flexible while it is being developed.</p> - -<h3 id="embedded-systems">Embedded systems</h3> - -<p>The software must interface with hardware. -In this case the hardware is not flexible, thus the software must be.</p> - -<h3 id="critical-systems">Critical systems</h3> - -<p>When total security is a requirement of the specification and design. -These systems must have finite specifications and design documents.</p> - -<h3 id="large-software-systems">Large software systems</h3> - -<p>Part of a larger system being developed by several parties. -This makes finite specifications extremely necessary.</p> - -<h2 id="how-can-i-decide-on-waterfall---analyse-home-ground">How can I decide on waterfall? - analyse home ground</h2> - -<p>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.</p> - -<h3 id="plan-driven-versus-agile-processes">Plan driven versus agile processes?</h3> - -<p>Activities in sequence versus all activities at the same time. -Agile development is very flexible and the requirements may be constantly changing. </p> - -<h2 id="incremental-model">Incremental model</h2> - -<p>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.</p> - -<h2 id="integration-and-configuration-1">Integration and configuration</h2> - -<p>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.</p> - -<h1 id="q2.-software-process-model---incrementaliterative">Q2. Software Process Model - Incremental/iterative</h1> - -<p>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.</p> - -<p>Incremental development is the most common approach to developing applications and software. </p> - -<h2 id="can-it-be-both-plandriven-and-agile">Can it be both plandriven and agile?</h2> - -<p>Yes, it can be either one or a mix of both.</p> - -<h3 id="plan-driven-approach">Plan-driven approach</h3> - -<p>Identify the system increments in advance. -A predictable waterfall plan is split into parts.</p> - -<h3 id="agile-approach">Agile approach</h3> - -<p>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.</p> - -<h3 id="agile-manifest-balancemix">Agile-manifest (balance/mix)</h3> - -<p>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.</p> - -<h2 id="what-are-advantages-of-incremental">What are advantages of incremental?</h2> - -<ol> -<li><p>Development costs are reduced -The amount of analysis and documentation that has to be redone is much less than waterfall.</p></li> -<li><p>It is easier to get client feedback -The clients can comment on demonstrations of the different versions and see the progress.</p></li> -<li><p>Earlier delivery of new software -New features can be made available even if they are not fully completed.</p></li> -</ol> - -<h2 id="what-disadvantages-are-there">What disadvantages are there?</h2> - -<ol> -<li><p>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.</p></li> -<li><p>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.</p></li> -</ol> - -<h1 id="q3.-software-process-model---integration-and-configuration">Q3. Software Process Model - Integration and configuration</h1> - -<h2 id="what-are-the-phases">What are the phases?</h2> - -<h3 id="requirements-specification">Requirements specification</h3> - -<p>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.</p> - -<h3 id="software-discovery-and-evaluation">Software discovery and evaluation</h3> - -<p>With the overview of the requirements, components are searched for that provide the necessary functionality.</p> - -<h3 id="requirements-refinement">Requirements refinement</h3> - -<p>The requirements are polished with the knowledge of the reusable components that were found.</p> - -<h3 id="application-system-configuration">Application system configuration</h3> - -<p>If an application that meets the requirements is available, it is configured for use in the new system.</p> - -<h2 id="advantagesdisadvantages">Advantages/disadvantages</h2> - -<p>This model reduces the amount of software that must be developed. -This in turn, reduces the costs and risks.</p> - -<p>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.</p> - -<h1 id="q4.-comparison-of-plandriven-and-agile-including-homeground">Q4. Comparison of plandriven and agile including Homeground</h1> - -<h2 id="what-is-the-difference-between-plandriven-and-agile">What is the difference between plandriven and agile?</h2> - -<h3 id="plandriven">Plandriven</h3> - -<p>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.</p> - -<h3 id="agile">Agile</h3> - -<p>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.</p> - -<h2 id="how-does-bhmturner-define-primary-factors">How does Böhm/Turner define primary factors?</h2> - -<h3 id="application">Application</h3> - -<h4 id="agile-1">Agile</h4> - -<p>Goal: to handle changes in the project. -Small teams. -Environment is turbulent and fast-paced, project focused.</p> - -<h4 id="plandriven-1">Plandriven</h4> - -<p>Goal: predictability, stability and security. -Larger teams and projects. -Environment: stable, few changes, organisation focused.</p> - -<h3 id="management-onsite-qualitative-control-tacit-knowledge">Management (onsite, qualitative control, tacit knowledge)</h3> - -<h4 id="agile-2">Agile</h4> - -<p>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.</p> - -<h4 id="plan-driven">Plan-driven</h4> - -<p>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.</p> - -<h3 id="technical">Technical</h3> - -<h4 id="agile-3">Agile</h4> - -<p>Requirements: can withstand unpredictability. -Development: simple design, small increments, refactoring is assumed to be cheap. -Test: Test cases define the requirements.</p> - -<h4 id="plan-driven-1">Plan-driven</h4> - -<p>Requirements: Formal project, user interface, quality, predictable requirements. -Development: Comprehensive design, larger intervals, refactoring is costly. -Test: Documented testplans and procedures.</p> - -<h3 id="people">People</h3> - -<p>Cockburn characteristics can describe a programmers personality. -One type may be more favourable than another depending on agile/plan-driven approach. </p> - -<h2 id="5-axis-on-the-home-ground-decision-tool">5 axis on the Home Ground Decision tool</h2> - -<ul> -<li>Criticality: impact of defects</li> -<li>Personell: average cockburn type</li> -<li>Dynamism: % requirement change per month</li> -<li>Culture: % thriving on chaos vs. order</li> -<li>Size: # of personnel</li> -</ul> - -<h2 id="what-is-continuous-integration-and-how-does-it-relate-to-agile">What is continuous integration and how does it relate to agile?</h2> - -<p>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.</p> - -<h2 id="prototype-development">Prototype development</h2> - -<ul> -<li>Prototype plan: establish objectives</li> -<li>Outline definition: define functionality</li> -<li>Executable prototype</li> -<li>Evaluation report</li> -</ul> - -<h1 id="q5.-key-features-of-scrum">Q5. Key features of SCRUM</h1> - -<p>Openness of all work. -Respect each other. -Focus on the common goal. -Courage for difficult decisions. -Duty to the common goal.</p> - -<p>3 roles. -5 events. -3 artifacts.</p> - -<h2 id="assets">Assets</h2> - -<ul> -<li>Scrum board</li> -<li>Project burndown</li> -<li>Sprint burndown</li> -</ul> - -<h2 id="three-pillars">Three pillars</h2> - -<p>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.</p> - -<h2 id="core-values">Core values</h2> - -<p>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</p> - -<h2 id="typical-errors">Typical errors</h2> - -<p>Scrum master is a manager. -No communication with the client. -New tasks are added to the sprint backlog in the middle of a sprint.</p> - -<h2 id="daily-scrum">Daily SCRUM</h2> - -<p>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.</p> - -<h2 id="sprint-planning">Sprint planning</h2> - -<p>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)</p> - -<h2 id="sprint-review">Sprint review</h2> - -<p>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.</p> - -<h2 id="sprint-retrospective">Sprint retrospective</h2> - -<p>For increasing quality and effictivity. -What went well/bad? -How can this be improved for the future?</p> - -<h2 id="roles">Roles</h2> - -<h3 id="product-owner">Product owner</h3> - -<p>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</p> - -<h3 id="scrum-master">SCRUM master</h3> - -<p>Ensure everyone is keeping in-line with SCRUM -Not the management leader -Ensure the team is effective -Deal with the teams blockages</p> - -<h3 id="developers">Developers</h3> - -<p>They own the backlog -Programmers, UI, UX and so on</p> - -<h1 id="q6.-key-features-of-xp---extreme-programming">Q6. Key features of XP - eXtreme Programming</h1> - -<h2 id="what-is-xp">What is XP?</h2> - -<p>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).</p> - -<p>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.</p> - -<p>Pair programming: developers work in pairs, checking each other’s work to ensure quality.</p> - -<h2 id="qualities-of-xp-that-fit-to-scrum">Qualities of XP that fit to SCRUM</h2> - -<p>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, …</p> - -<h3 id="what-does-xp-and-scrum-have-in-common">What does XP and SCRUM have in common?</h3> - -<p>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)</p> - -<h2 id="what-values-are-xp-based-on-according-to-larman">What values are XP based on according to Larman?</h2> - -<p>Communication, simplicity, feedback, courage.</p> - -<h3 id="communication">Communication</h3> - -<p>Pair programming -Customer on-site -Acceptance test -Daily standup (short meetings)</p> - -<h3 id="simplicity">Simplicity</h3> - -<p>Teams implement exactly what was asked for. Nothing more. -Strive for simple designs and quality code.</p> - -<h3 id="feedback">Feedback</h3> - -<p>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.</p> - -<h3 id="courage">Courage</h3> - -<p>Developers should be honest. -Don’t make excuses for issuse. -Don’t be afraid to make big changes.</p> - -<h2 id="how-is-xp-extreme">How is XP extreme?</h2> - -<p>E.g. If tests are good, do them all the time. -Takes all good things, and places them at the core of the process.</p> - -<h2 id="name-some-key-practices-in-xp">Name some key practices in XP?</h2> - -<p>Unit test, pair review, customer on-site, continuous integration, testing, early test, unit test, TDD.</p> - -<h2 id="what-is-a-user-story">What is a user story?</h2> - -<p>Brief feature request, a promise for conversation. -Written on a card with criteria for confirmation on the back.</p> - -<h2 id="story-maps---user-story-mapping">Story maps - User story mapping</h2> - -<p>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.</p> - -<p>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.</p> - -<p>Story map process has 4 levels</p> - -<h2 id="what-is-the-format-a-user-story">What is the format a user story?</h2> - -<p>“As a <user> I want <feature> so that <why>”. -Who, what, why.</p> - -<h2 id="how-does-xp-describe-lifecycle-for-a-system">How does XP describe Lifecycle for a System?</h2> - -<p>Exploration, planning, iterations to first release, productionizing, maintenance.</p> - -<h2 id="what-is-the-iteration-called-in-xp">What is the iteration called in XP?</h2> - -<p>Iteration</p> - -<h1 id="q7.-product-planning-requirements-elicitation-product-vision-product-roadmap">Q7. Product Planning: Requirements Elicitation, Product Vision, Product Roadmap</h1> - -<h2 id="what-main-requirement-activities-are-there">What main requirement activities are there?</h2> - -<p>Elicitation and analysis of needs. -Specification of requirements. -Validation of requirements.</p> - -<h2 id="elicitation-and-analysis-of-needs">Elicitation and analysis of needs</h2> - -<p>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.</p> - -<p>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.</p> - -<h2 id="requirement-specification">Requirement specification</h2> - -<p>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)</p> - -<h2 id="requirement-validation">Requirement validation</h2> - -<p>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.</p> - -<ol> -<li><p>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.</p></li> -<li><p>Consistency checks: -Requirements should not conflict with others. </p></li> -<li><p>Completeness checks: -The requirement specification should be comprehensive for every function and the limits that the client wants.</p></li> -<li><p>Realism checks: -Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame.</p></li> -<li><p>Verifiability: -You should be able to create tests that verify whether or not a requirement is met.</p></li> -</ol> - -<h2 id="requirement-validation-techniques">Requirement validation techniques</h2> - -<ol> -<li><p>Requirement reviews -Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts.</p></li> -<li><p>Prototyping -Develop executable models of the system and verify with the client that it meets their expectations.</p></li> -<li><p>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.</p></li> -</ol> - -<h2 id="what-are-the-steps-in-elicitation">What are the steps in elicitation?</h2> - -<ol> -<li><p>Discovery & Classification -This is the process of interacting with the stakeholders to find their requirements.</p></li> -<li><p>Categorization -Take the unstructured list of requirements and group related requirements together.</p></li> -<li><p>Prioritization & Negotiation -Conflicts can arise when there are multiple stakeholders. -Prioritize the most important requirements, through negotiation, discussions, compromises and meetings.</p></li> -<li><p>Documentation -Here the requirements are documented.</p></li> -</ol> - -<h2 id="why-is-it-difficult-to-elicit-requirements">Why is it difficult to elicit requirements?</h2> - -<p>Many stakeholders with conflicting needs. -Stakeholders speak their own “language”. -Lack of communication because things are assumed to be “obvious”.</p> - -<h2 id="what-is-a-recognized-way-to-communicate-requirements">What is a recognized way to communicate requirements?</h2> - -<p>Stories, Scenarios.</p> - -<h2 id="how-are-requirements-documented-in-waterfall-and-in-scrum-in-product-planning">How are requirements documented in Waterfall and in SCRUM, in Product Planning?</h2> - -<p>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.</p> - -<h2 id="how-are-requirements-negotiated-with-stakeholders-in-waterfall-and-scrum">How are requirements negotiated with stakeholders in Waterfall and SCRUM?</h2> - -<p>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.</p> - -<h1 id="q8.-product-refinement-and-forecasting-user-story-mapping-personas-stakeholders-product-backlog">Q8. Product Refinement and Forecasting: User story mapping, personas, stakeholders, product backlog</h1> - -<h2 id="what-is-a-persona">What is a persona?</h2> - -<p>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.</p> - -<h2 id="what-is-a-user-story-1">What is a user story?</h2> - -<p>Short description on a type of user, a goal and a reason.</p> - -<h2 id="where-do-we-use-the-terms-product-feature-epic-user-story">Where do we use the terms: Product Feature, Epic, User story?</h2> - -<p>Product Feature: Corresponds to an Epic. -Epic: A collection of related user stories. -User story: Breakdown of an Epic. </p> - -<h2 id="what-is-a-user-journey">What is a user journey?</h2> - -<p>The experiences a person has, when interacting with the software.</p> - -<h2 id="what-are-the-key-characteristics-of-a-product-backlog">What are the key characteristics of a product backlog?</h2> - -<p>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.</p> - -<h1 id="q9.-risk-management">Q9. Risk Management</h1> - -<p>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.</p> - -<h2 id="example-of-risk-categories">Example of risk categories</h2> - -<ol> -<li>Uncertainty, project, technical, business.</li> -<li>Keyperson from team dies, a supplier is not delivering as promissed.</li> -</ol> - -<h2 id="categories-of-risk">Categories of risk</h2> - -<h3 id="project-risks">Project risks</h3> - -<p>Risks that threaten the project plan. -Time will be wasted and costs will rise.</p> - -<h3 id="technical-risks">Technical risks</h3> - -<p>Architectural design. -Arrises because problems can be harder to solve than expected. -Vagueness in the specification. -Project gets older and starts to decay.</p> - -<h3 id="business-risks">Business risks</h3> - -<p>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.</p> - -<h2 id="how-do-you-do-risk-analysis">How do you do risk analysis?</h2> - -<p>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.</p> - -<h2 id="identify-risks-and-calculate-risk-exposure-and-describe-consequence.">Identify risks and calculate risk exposure and describe consequence.</h2> - -<p>Risk exposure = probability * loss, describe consequence. -Probability < 100%. If p = 100% then it’s an issue.</p> - -<p>Prioritize according to risk exposure, establish cut-line. -Deal with the risks above the line, accept the ones below.</p> - -<p>Establish for each risk above the cut-line (RMMM: Risk Mitigation, monitor, management)</p> - -<h3 id="mitigate">Mitigate</h3> - -<p>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.</p> - -<h3 id="manage">Manage</h3> - -<p>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.</p> - -<h3 id="monitor">Monitor</h3> - -<p>Observe how risks change over time. -How the probabilities, loss, or the environment, change over time.</p> - -<h2 id="how-are-risk-management-part-of-project-management">How are risk management part of project management</h2> - -<h3 id="waterfall-plan-driven">Waterfall / plan-driven</h3> - -<p>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.</p> - -<h3 id="agile---inspect-and-adapt-is-reduction-to-produce-the-right-product">Agile - inspect and adapt is reduction to produce the right product</h3> - -<p>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.</p> - -<h2 id="what-are-bhms-primary-risks">What are Böhms primary risks?</h2> - -<p>Personal shortcomings, unrealistic schedule, wrong function…</p> - -<h1 id="q10.-how-is-quality-defined">Q10. How is quality defined?</h1> - -<h2 id="software-quality-attributes">Software quality attributes</h2> - -<h3 id="nonfunctional-requirements">Nonfunctional requirements</h3> - -<p>Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc…</p> - -<h3 id="functional-requirements">Functional requirements</h3> - -<ul> -<li>Requirement Specification (waterfall)</li> -<li>Product backlog and User Stories (agile)</li> -</ul> - -<h2 id="what-is-quality">What is quality?</h2> - -<p>Quality is evaluated aesthetically, symbolically and functionally -Quality can be either objective or subjective. -Quality may not always be obvious.</p> - -<h2 id="definition-of-quality">Definition of quality</h2> - -<p>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.</p> - -<p>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.</p> - -<h2 id="why-invest-or-pay-for-quality-management">Why invest or pay for Quality Management?</h2> - -<p>Cost of not doing it is bad quality - fixing errors.</p> - -<p>Direct cost of error correction: -- Loss. (effort) -- Wasted work. (for users of the program) -- Maintenance usually has larger costs than development.</p> - -<p>Indirect cost of error correction -- Follows from poor quality (unsatisfied users) -- Has potentially severe consequences (losing customers)</p> - -<p>Quality Management reduces these costs significantly.</p> - -<h2 id="validation-fit-for-use">Validation (fit for use)</h2> - -<p>Are we building a system that is fit for use? -Compliance with the users expectations and experiences?</p> - -<h2 id="verification-requirement-specification-being-met">Verification (requirement specification being met)</h2> - -<p>Do we pass all tests and requirements? -Are we building a system with all the requirements implemented? -Unit/integration tests</p> - -<h2 id="techniques-for-verification-and-validation">Techniques for verification and validation</h2> - -<p>Testing: of programmes and prototypes. -Review: of specifications, documentation and programs.</p> - -<h2 id="is-it-verification-or-validation">Is it verification or validation?</h2> - -<p>A user must participate in order to validate. -Verification focuses on the compliance to the specifications and a client usually doensn’t participate.</p> - -<h2 id="v-model">V-model</h2> - -<h1 id="q11.-test-and-review">Q11. Test and review</h1> - -<p>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.</p> - -<h2 id="what-is-peer-review">What is peer review?</h2> - -<p>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.</p> - -<h2 id="what-is-the-difference-between-review-and-test">What is the difference between review and test?</h2> - -<p>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.</p> - -<h2 id="when-is-review-good">When is review good?</h2> - -<p>For documents, designs, architectures, plans, etc.</p> - -<h2 id="when-is-test-good">When is test good?</h2> - -<p>For functionality and dynamic use of the program.</p> - -<h2 id="what-is-the-v-model">What is the V-Model</h2> - -<p>A model that shows the connection between tests at different levels and primary activities that drive the tests.</p> - -<h2 id="name-tests-at-different-levels">Name tests at different levels:</h2> - -<p>Unit test, component test, integration test, system test, user acceptance test.</p> - -<p>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.</p> - -<h2 id="when-is-test-done">When is test done?</h2> - -<p>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)</p> - -<h1 id="q12.-configuration-management-and-devops">Q12. Configuration Management and DevOps</h1> - -<h2 id="what-is-devops-how-can-you-define-it">What is DevOps, how can you define it?</h2> - -<p>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.</p> - -<h2 id="what-is-the-purpose-of-continuous-integration">What is the purpose of Continuous Integration?</h2> - -<p>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.</p> - -<h2 id="what-is-the-purpose-of-continuous-testing">What is the purpose of Continuous Testing?</h2> - -<p>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.</p> - -<h2 id="what-is-the-purpose-of-continuous-delivery-and-deployment">What is the purpose of Continuous Delivery and Deployment?</h2> - -<h3 id="continuous-delivery">Continuous Delivery</h3> - -<p>Ensure that code can be implemented securely. -Ensure that the business and service application function as expected and deliver every change to production.</p> - -<h3 id="continous-deployment">Continous Deployment</h3> - -<p>Ensure that tests are automated and that every change is automatically implemented in production. -Makes the development and release process faster and more robust.</p> - -<p>Automated access to well defined environments. -Tools like Docker for containerization or Virtual Machines.</p> -<footer> - <a href="/" class="homepage-link">adast.xyz</a> - — - <a href="https://git.adast.xyz/explore/repos">Gitea</a> - • - <a href="https://github.com/adastx">Github</a> - • - <a href="https://odysee.com/@adamski:f">Odysee</a> - • - <a href="https://youtube.com/c/adamski1">Youtube</a> - • - <a href="https://www.twitch.tv/adastx">Twitch</a> - • - <a href="https://steamcommunity.com/id/adastx">Steam</a> -</footer> - -<script src="scripts/darktheme.js"></script> -</body> - -</html> |