diff options
Diffstat (limited to 'dst/ase.html')
| -rw-r--r-- | dst/ase.html | 920 |
1 files changed, 920 insertions, 0 deletions
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 @@ +<!DOCTYPE html> +<html> +<meta charset="UTF-8"> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> + +<title>Q1. Software Process Model - Waterfall — adamski.wtf</title> +<link rel="icon" type="image/png" href="favicon.png"> +<link rel="stylesheet" href="styles/style.css"> + +<p class="header"><a href="/">adamski.wtf</a></p> +<h1 id="Q1.%20Software%20Process%20Model%20-%20Waterfall">Q1. Software Process Model - Waterfall</h1> + +<h2 id="What%20is%20software%20engineering%20a%20response%20to?">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%20system%20complexity">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%20to%20use%20software%20engineering%20methods">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%20engineering%20process%20activities">Software engineering process activities</h2> + +<h3 id="Software%20specification">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%20development">Software development</h3> + +<p>This is where the software is designed and programmed.</p> + +<h3 id="Software%20validation">Software validation</h3> + +<p>This step ensures that the software does what the client requested.</p> + +<h3 id="Software%20evolution">Software evolution</h3> + +<p>When software is modified to meet client’s or the market’s new requirements.</p> + +<h2 id="What%20is%20a%20software%20process%20model">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%20model">Waterfall model</h3> + +<p>The model takes the fundamental software process activities. +Seperate process phases: +- Requirement specification +- Software design +- Implementation +- Test</p> + +<h3 id="Incremental&#47;iterative%20development">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%20and%20configuration">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%20model-2">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%20analysis%20and%20definition">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%20and%20software%20design">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%20and%20unit%20testing">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%20and%20system%20testing">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%20and%20maintenance">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%20should%20you%20consider%20using%20waterfall?">When should you consider using waterfall?</h2> + +<p>For software that needs to be flexible while it is being developed.</p> + +<h3 id="Embedded%20systems">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%20systems">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%20software%20systems">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%20can%20I%20decide%20on%20waterfall?%20-%20analyse%20home%20ground">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%20driven%20versus%20agile%20processes?">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%20model">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%20and%20configuration-2">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.%20Software%20Process%20Model%20-%20Incremental&#47;iterative">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%20it%20be%20both%20plandriven%20and%20agile?">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%20approach">Plan-driven approach</h3> + +<p>Identify the system increments in advance. +A predictable waterfall plan is split into parts.</p> + +<h3 id="Agile%20approach">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%20(balance&#47;mix)">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%20are%20advantages%20of%20incremental?">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%20disadvantages%20are%20there?">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.%20Software%20Process%20Model%20-%20Integration%20and%20configuration">Q3. Software Process Model - Integration and configuration</h1> + +<h2 id="What%20are%20the%20phases?">What are the phases?</h2> + +<h3 id="Requirements%20specification">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%20discovery%20and%20evaluation">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%20refinement">Requirements refinement</h3> + +<p>The requirements are polished with the knowledge of the reusable components that were found.</p> + +<h3 id="Application%20system%20configuration">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="Advantages&#47;disadvantages">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.%20Comparison%20of%20plandriven%20and%20agile%20including%20Homeground">Q4. Comparison of plandriven and agile including Homeground</h1> + +<h2 id="What%20is%20the%20difference%20between%20plandriven%20and%20agile?">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%20does%20B%C3%B6hm&#47;Turner%20define%20primary%20factors?">How does Böhm/Turner define primary factors?</h2> + +<h3 id="Application">Application</h3> + +<h4 id="Agile-2">Agile</h4> + +<p>Goal: to handle changes in the project. +Small teams. +Environment is turbulent and fast-paced, project focused.</p> + +<h4 id="Plandriven-2">Plandriven</h4> + +<p>Goal: predictability, stability and security. +Larger teams and projects. +Environment: stable, few changes, organisation focused.</p> + +<h3 id="Management%20(onsite,%20qualitative%20control,%20tacit%20knowledge)">Management (onsite, qualitative control, tacit knowledge)</h3> + +<h4 id="Agile-3">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-4">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-2">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%20axis%20on%20the%20Home%20Ground%20Decision%20tool">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%20is%20continuous%20integration%20and%20how%20does%20it%20relate%20to%20agile?">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%20development">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.%20Key%20features%20of%20SCRUM">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%20pillars">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%20values">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%20errors">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%20SCRUM">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%20planning">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%20review">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%20retrospective">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%20owner">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%20master">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.%20Key%20features%20of%20XP%20-%20eXtreme%20Programming">Q6. Key features of XP - eXtreme Programming</h1> + +<h2 id="What%20is%20XP?">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%20of%20XP%20that%20fit%20to%20SCRUM">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%20does%20XP%20and%20SCRUM%20have%20in%20common?">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%20values%20are%20XP%20based%20on%20according%20to%20Larman?">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%20is%20XP%20extreme?">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%20some%20key%20practices%20in%20XP?">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%20is%20a%20user%20story?">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%20maps%20-%20User%20story%20mapping">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%20is%20the%20format%20a%20user%20story?">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%20does%20XP%20describe%20Lifecycle%20for%20a%20System?">How does XP describe Lifecycle for a System?</h2> + +<p>Exploration, planning, iterations to first release, productionizing, maintenance.</p> + +<h2 id="What%20is%20the%20iteration%20called%20in%20XP?">What is the iteration called in XP?</h2> + +<p>Iteration</p> + +<h1 id="Q7.%20Product%20Planning:%20Requirements%20Elicitation,%20Product%20Vision,%20Product%20Roadmap">Q7. Product Planning: Requirements Elicitation, Product Vision, Product Roadmap</h1> + +<h2 id="What%20main%20requirement%20activities%20are%20there?">What main requirement activities are there?</h2> + +<p>Elicitation and analysis of needs. +Specification of requirements. +Validation of requirements.</p> + +<h2 id="Elicitation%20and%20analysis%20of%20needs">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%20specification">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%20validation">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%20validation%20techniques">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%20are%20the%20steps%20in%20elicitation?">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%20is%20it%20difficult%20to%20elicit%20requirements?">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%20is%20a%20recognized%20way%20to%20communicate%20requirements?">What is a recognized way to communicate requirements?</h2> + +<p>Stories, Scenarios.</p> + +<h2 id="How%20are%20requirements%20documented%20in%20Waterfall%20and%20in%20SCRUM,%20in%20Product%20Planning?">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%20are%20requirements%20negotiated%20with%20stakeholders%20in%20Waterfall%20and%20SCRUM?">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.%20Product%20Refinement%20and%20Forecasting:%20User%20story%20mapping,%20personas,%20stakeholders,%20product%20backlog">Q8. Product Refinement and Forecasting: User story mapping, personas, stakeholders, product backlog</h1> + +<h2 id="What%20is%20a%20persona?">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%20is%20a%20user%20story?-2">What is a user story?</h2> + +<p>Short description on a type of user, a goal and a reason.</p> + +<h2 id="Where%20do%20we%20use%20the%20terms:%20Product%20Feature,%20Epic,%20User%20story?">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%20is%20a%20user%20journey?">What is a user journey?</h2> + +<p>The experiences a person has, when interacting with the software.</p> + +<h2 id="What%20are%20the%20key%20characteristics%20of%20a%20product%20backlog?">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.%20Risk%20Management">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%20of%20risk%20categories">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%20of%20risk">Categories of risk</h2> + +<h3 id="Project%20risks">Project risks</h3> + +<p>Risks that threaten the project plan. +Time will be wasted and costs will rise.</p> + +<h3 id="Technical%20risks">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%20risks">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%20do%20you%20do%20risk%20analysis?">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%20risks%20and%20calculate%20risk%20exposure%20and%20describe%20consequence.">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%20are%20risk%20management%20part%20of%20project%20management">How are risk management part of project management</h2> + +<h3 id="Waterfall%20&#47;%20plan-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%20-%20inspect%20and%20adapt%20is%20reduction%20to%20produce%20the%20right%20product">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%20are%20B%C3%B6hms%20primary%20risks?">What are Böhms primary risks?</h2> + +<p>Personal shortcomings, unrealistic schedule, wrong function…</p> + +<h1 id="Q10.%20How%20is%20quality%20defined?">Q10. How is quality defined?</h1> + +<h2 id="Software%20quality%20attributes">Software quality attributes</h2> + +<h3 id="Nonfunctional%20requirements">Nonfunctional requirements</h3> + +<p>Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc…</p> + +<h3 id="Functional%20requirements">Functional requirements</h3> + +<ul> +<li>Requirement Specification (waterfall)</li> +<li>Product backlog and User Stories (agile)</li> +</ul> + +<h2 id="What%20is%20quality?">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%20of%20quality">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%20invest%20or%20pay%20for%20Quality%20Management?">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%20(fit%20for%20use)">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%20(requirement%20specification%20being%20met)">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%20for%20verification%20and%20validation">Techniques for verification and validation</h2> + +<p>Testing: of programmes and prototypes. +Review: of specifications, documentation and programs.</p> + +<h2 id="Is%20it%20verification%20or%20validation?">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.%20Test%20and%20review">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%20is%20peer%20review?">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%20is%20the%20difference%20between%20review%20and%20test?">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%20is%20review%20good?">When is review good?</h2> + +<p>For documents, designs, architectures, plans, etc.</p> + +<h2 id="When%20is%20test%20good?">When is test good?</h2> + +<p>For functionality and dynamic use of the program.</p> + +<h2 id="What%20is%20the%20V-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%20tests%20at%20different%20levels:">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%20is%20test%20done?">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.%20Configuration%20Management%20and%20DevOps">Q12. Configuration Management and DevOps</h1> + +<h2 id="What%20is%20DevOps,%20how%20can%20you%20define%20it?">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%20is%20the%20purpose%20of%20Continuous%20Integration?">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%20is%20the%20purpose%20of%20Continuous%20Testing?">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%20is%20the%20purpose%20of%20Continuous%20Delivery%20and%20Deployment?">What is the purpose of Continuous Delivery and Deployment?</h2> + +<h3 id="Continuous%20Delivery">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%20Deployment">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> +<p class="footer"><a href="/">adamski.wtf</a></p> +</html> |