diff options
Diffstat (limited to 'src/notes/ase.md')
| -rw-r--r-- | src/notes/ase.md | 754 |
1 files changed, 754 insertions, 0 deletions
diff --git a/src/notes/ase.md b/src/notes/ase.md new file mode 100644 index 0000000..5618803 --- /dev/null +++ b/src/notes/ase.md @@ -0,0 +1,754 @@ +# Q1. Software Process Model - Waterfall +## What is software engineering a response to? +- Increasing system complexity. +- Failure to use software engineering methods. + +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. It is easier to get client feedback +The clients can comment on demonstrations of the different versions and see the progress. + +3. Earlier delivery of new software +New features can be made available even if they are not fully completed. + +## 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. 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. + +# 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 +- Criticality: impact of defects +- Personell: average cockburn type +- Dynamism: % requirement change per month +- Culture: % thriving on chaos vs. order +- Size: # of personnel + +## 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 + +- Prototype plan: establish objectives +- Outline definition: define functionality +- Executable prototype +- Evaluation report + +# 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 +- Scrum board +- Project burndown +- Sprint burndown + +## 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 <user> I want <feature> so that <why>". +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. Consistency checks: +Requirements should not conflict with others. + +3. Completeness checks: +The requirement specification should be comprehensive for every function and the limits that the client wants. + +4. Realism checks: +Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame. + +5. Verifiability: +You should be able to create tests that verify whether or not a requirement is met. + +## Requirement validation techniques +1. Requirement reviews +Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts. + +2. Prototyping +Develop executable models of the system and verify with the client that it meets their expectations. + +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. + +## What are the steps in elicitation? +1. Discovery & Classification +This is the process of interacting with the stakeholders to find their requirements. + +2. Categorization +Take the unstructured list of requirements and group related requirements together. + +3. Prioritization & Negotiation +Conflicts can arise when there are multiple stakeholders. +Prioritize the most important requirements, through negotiation, discussions, compromises and meetings. + +4. Documentation +Here the requirements are documented. + +## 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. Keyperson from team dies, a supplier is not delivering as promissed. + +## 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 +- Requirement Specification (waterfall) +- Product backlog and User Stories (agile) + +## 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. |