diff options
Diffstat (limited to 'src/notes/ase.md')
| -rw-r--r-- | src/notes/ase.md | 754 |
1 files changed, 0 insertions, 754 deletions
diff --git a/src/notes/ase.md b/src/notes/ase.md deleted file mode 100644 index 5618803..0000000 --- a/src/notes/ase.md +++ /dev/null @@ -1,754 +0,0 @@ -# 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. |