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.
- -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.
- -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.
- -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.
- -This is where the software is designed and programmed.
- -This step ensures that the software does what the client requested.
- -When software is modified to meet client’s or the market’s new requirements.
- -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.
- -The model takes the fundamental software process activities. -Seperate process phases: -- Requirement specification -- Software design -- Implementation -- Test
- -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.
- -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.
- -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.
- -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.
- -The overall system architecture is established in this phase. -Identify and describe the fundamental system abstractions and their relations (UML)
- -The design is implemented in the indivivual program parts. -The design is tested to verify that it meets the specification.
- -The individual program parts are integrated and the whole system it tested. -The software is delivered to the client.
- -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.
- -For software that needs to be flexible while it is being developed.
- -The software must interface with hardware. -In this case the hardware is not flexible, thus the software must be.
- -When total security is a requirement of the specification and design. -These systems must have finite specifications and design documents.
- -Part of a larger system being developed by several parties. -This makes finite specifications extremely necessary.
- -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.
- -Activities in sequence versus all activities at the same time. -Agile development is very flexible and the requirements may be constantly changing.
- -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.
- -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.
- -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.
- -Yes, it can be either one or a mix of both.
- -Identify the system increments in advance. -A predictable waterfall plan is split into parts.
- -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.
- -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.
- -Development costs are reduced -The amount of analysis and documentation that has to be redone is much less than waterfall.
It is easier to get client feedback -The clients can comment on demonstrations of the different versions and see the progress.
Earlier delivery of new software -New features can be made available even if they are not fully completed.
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.
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.
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.
- -With the overview of the requirements, components are searched for that provide the necessary functionality.
- -The requirements are polished with the knowledge of the reusable components that were found.
- -If an application that meets the requirements is available, it is configured for use in the new system.
- -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.
- -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 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.
- -Goal: to handle changes in the project. -Small teams. -Environment is turbulent and fast-paced, project focused.
- -Goal: predictability, stability and security. -Larger teams and projects. -Environment: stable, few changes, organisation focused.
- -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.
- -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.
- -Requirements: can withstand unpredictability. -Development: simple design, small increments, refactoring is assumed to be cheap. -Test: Test cases define the requirements.
- -Requirements: Formal project, user interface, quality, predictable requirements. -Development: Comprehensive design, larger intervals, refactoring is costly. -Test: Documented testplans and procedures.
- -Cockburn characteristics can describe a programmers personality. -One type may be more favourable than another depending on agile/plan-driven approach.
- -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.
- -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.
- -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.
- -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
- -Scrum master is a manager. -No communication with the client. -New tasks are added to the sprint backlog in the middle of a sprint.
- -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.
- -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)
- -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.
- -For increasing quality and effictivity. -What went well/bad? -How can this be improved for the future?
- -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
- -Ensure everyone is keeping in-line with SCRUM -Not the management leader -Ensure the team is effective -Deal with the teams blockages
- -They own the backlog -Programmers, UI, UX and so on
- -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.
- -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, …
- -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)
- -Communication, simplicity, feedback, courage.
- -Pair programming -Customer on-site -Acceptance test -Daily standup (short meetings)
- -Teams implement exactly what was asked for. Nothing more. -Strive for simple designs and quality code.
- -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.
- -Developers should be honest. -Don’t make excuses for issuse. -Don’t be afraid to make big changes.
- -E.g. If tests are good, do them all the time. -Takes all good things, and places them at the core of the process.
- -Unit test, pair review, customer on-site, continuous integration, testing, early test, unit test, TDD.
- -Brief feature request, a promise for conversation. -Written on a card with criteria for confirmation on the back.
- -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
- -“As a
Exploration, planning, iterations to first release, productionizing, maintenance.
- -Iteration
- -Elicitation and analysis of needs. -Specification of requirements. -Validation of requirements.
- -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.
- -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)
- -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.
- -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.
Consistency checks: -Requirements should not conflict with others.
Completeness checks: -The requirement specification should be comprehensive for every function and the limits that the client wants.
Realism checks: -Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame.
Verifiability: -You should be able to create tests that verify whether or not a requirement is met.
Requirement reviews -Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts.
Prototyping -Develop executable models of the system and verify with the client that it meets their expectations.
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.
Discovery & Classification -This is the process of interacting with the stakeholders to find their requirements.
Categorization -Take the unstructured list of requirements and group related requirements together.
Prioritization & Negotiation -Conflicts can arise when there are multiple stakeholders. -Prioritize the most important requirements, through negotiation, discussions, compromises and meetings.
Documentation -Here the requirements are documented.
Many stakeholders with conflicting needs. -Stakeholders speak their own “language”. -Lack of communication because things are assumed to be “obvious”.
- -Stories, Scenarios.
- -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.
- -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.
- -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.
- -Short description on a type of user, a goal and a reason.
- -Product Feature: Corresponds to an Epic. -Epic: A collection of related user stories. -User story: Breakdown of an Epic.
- -The experiences a person has, when interacting with the software.
- -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.
- -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.
- -Risks that threaten the project plan. -Time will be wasted and costs will rise.
- -Architectural design. -Arrises because problems can be harder to solve than expected. -Vagueness in the specification. -Project gets older and starts to decay.
- -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.
- -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.
- -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)
- -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.
- -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.
- -Observe how risks change over time. -How the probabilities, loss, or the environment, change over time.
- -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.
- -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.
- -Personal shortcomings, unrealistic schedule, wrong function…
- -Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc…
- -Quality is evaluated aesthetically, symbolically and functionally -Quality can be either objective or subjective. -Quality may not always be obvious.
- -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.
- -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.
- -Are we building a system that is fit for use? -Compliance with the users expectations and experiences?
- -Do we pass all tests and requirements? -Are we building a system with all the requirements implemented? -Unit/integration tests
- -Testing: of programmes and prototypes. -Review: of specifications, documentation and programs.
- -A user must participate in order to validate. -Verification focuses on the compliance to the specifications and a client usually doensn’t participate.
- -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.
- -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.
- -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.
- -For documents, designs, architectures, plans, etc.
- -For functionality and dynamic use of the program.
- -A model that shows the connection between tests at different levels and primary activities that drive the tests.
- -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.
- -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)
- -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.
- -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.
- -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.
- -Ensure that code can be implemented securely. -Ensure that the business and service application function as expected and deliver every change to production.
- -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.
- - - - - - -- cgit v1.2.3-70-g09d2