Software Eksamen Pensum PDF

Requirements Engineering Requirements engineering phases: Elicitation (Gathering requirements) Is the process of identifying and collecting requirements from stakeholders, end-users, and other relevant parties. The reason you would gather such information is to know exactly what it is you are engin...

Requirements Engineering Requirements engineering phases: Elicitation (Gathering requirements) Is the process of identifying and collecting requirements from stakeholders, end-users, and other relevant parties. The reason you would gather such information is to know exactly what it is you are engineering, and what the clients are requesting. This is important so that you don't waste resources and time. To get this type of information you can have: interviews, surveys/questionnaires, workshops where you collaborate with clients, observe users interact with existing systems, etc. Analysis (Understand and refinding requirements) Ensure that the requirements that you have gathered are clear, unambiguous and doable. You can do this by f.eks. Looking for conflicts or overlaps in requirements, prioritize requirements based on what is important for stakeholders or to the project, create models like diagrams so that you can visualize the problem and requirements. Specification (Documenting requirements) Writing the requirements in a detailed and a structured format makes it easier to use as a reference for the development team. Examples that are often used for documenting these things are: Software requirements specification (SRS): A document outlining functional and non-functional requirements Use case descriptions: Highlight the scenarios, actors and workflows. Type of requirements Functional requirements: Functional requirements define what the system must do, its features and capabilities. Eks. “The system shall allow users to log in using their credentials.” Non-Functional requirements: Define system qualities or constraints, such as performance, security, and usability. Eks. “The system shall process 100 transactions per second.” User requirements: Describe the goal or tasks the user wants to achieve with the system. System requirements: High-level requirements that specify the systems components, environment, or infrastructure. Eks. “The system shall be compatible with both Windows and macOS.” Traceability The ability to track a requirement throughout the project lifecycle from origin to implementation and testing. This is important because it ensures that no requirements are overlooked during development. It also Facilitates changes by linking requirements to related artifacts (test cases, designs, etc). Improves accountability by identifying the origin of each requirement. Here are some examples of traceability: Requirement: “The system shall allow users to reset their passwords.” This is linked to: Design documentation: Outlines the password reset flow. Code module: Implements the password reset feature. Test case: Validates the password reset functionality. Characteristics of good requirements 1. Complete: Covers all necessary functionalities and details. Example: "The system shall allow the user to reset their password via email." 2. Correct: Reflects the true needs of stakeholders and avoids ambiguity or misinterpretation. 3. Feasible: Can be realistically implemented within the given technological, financial, and time constraints. 4. Testable: Can be verified through specific tests to ensure compliance. Example: "The system shall process a minimum of 50 transactions per second." 5. Unambiguous: Easy to interpret with a single, clear meaning.  Avoid vague terms like “fast” or “user-friendly” unless further specified. 6. Traceable: Can be linked to its source (stakeholder, business goal) and tracked throughout the development process. Use Cases Components of a use case Actors: Are individuals, systems, or entities interacting within the system. Types of actors: Primary Actor: Initiates the interaction to achieve a goal. Eks. A customer placing an order in a restaurant system. Supporting actor: Assists in completing the interaction. Eks. A kitchen system receiving the order details from the restaurant system. External actor: A system or organization interacting indirectly. Eks. A payment gateway used to process transactions. Pre-conditions: Conditions that must be true before the use case can begin. Here are some examples: PlaceOrder: The customer must be logged into their account. PayForOrder: The order must already be placed and saved in the system. Main flow: The standard sequence of steps that accomplishes the goal of the use case. Here are some examples: PlaceOrder: 1. Customer selects items to order 2. Customer submits the order 3. System saves the order and sends it to the kitchen Alternative flows: Variations or exceptions to the main flow, often handling edge cases or errors. Here are some examples: PlaceOrder: - Alternative flow: If a selected item is out of stock, notify the customer and suggest alternatives PayForOrder: - Alternative flow: If the card gets declined, allow the customer to choose another payment method. Post-conditions: Conditions that must be true after the use case is successfully completed. Eks. PlaceOrder: The order details are saved, and the kitchen receives the order. PayForOrder: The payment is processed, and receipt is sent to the customer. Use case relationships Include relationship: Represents a mandatory relationship where one use case always involves another. The purpose of this relationship is to reuse common functionalities between multiple use cases. F.eks. PlaceOrder includes ValidatePayment: “The ValidatePayment use case is executed every time the PlaceOrder use case is run” Extend relationship: Represents an optional or conditional relationship where additional functionality is added to a base use case. The purpose of this relationship is to model optional behaviour or exceptions. F.eks. PlaceOrder is extended by ApplyDiscount: “The ApplyDiscount use case is executed only if the customer enters a valid discount code.” UML DIAGRAMS BEHAVIORAL DIAGRAMS: Sequence diagrams - The purpose of sequence diagrams are to focus on dynamic behaviors by showing the interactions between objects over time. These types of diagrams capture message exchanges and method calls in a specific order. Here are the key components of behavioral diagrams: Actors - External entities interacting with the system. F.eks. A user Objects - System elements participating in the interaction. F.eks. Lifelines - Vertical dashed lines that represent the lifetime of an object. Messages - Arrow showing communication between objects (method calls or data exchanges.) Activation bars - Depicted as a thin rectangle on a lifeline, showcases when an object or actor is active or has control. Adding these bars helps clarify the sequence and timing of interactions. The actor in this image is shown as a stick figure as an external entity interacting with the system. The line going out from the actor represents a lifeline, wich shows the actors involvement in the interaction over time. In this case, the actor is initiating an interaction by sending a request. The system is represented by a class with two ports, port1 and port2. The lifeline for the class starts below it and continues down, showing the class’s participation throughout the sequence. When receiving the request from the actor, the class forwards the request to the data store, which is depicted as a circle representing a database or storage component. Each arrow between the elements represents a message. For example: The request message is sent from the actor to the Class. The Class processes the request and sends another request to the Data Store. The Data Store processes the request and sends a return message back to the Class. Finally, the Class completes its processing and sends a return message back to the actor. The activation bars indicate the periods during which the actor, class, or data store is actively performing a task or processing a message. STRUCTURAL DIAGRAMS Class diagrams: Class diagrams represent the static structure of a system, including classes, attributes, methods, and relationships. Here are the key elements in a class diagram: Classes - Boxes with three sections: Name - Identifies the class F.eks. Customer Attributes - Properties for the class F.eks. Customer name, email, etc. Methods - Operations or functions the class can perform. F.eks. PlaceOrder() Name: Book Attributes: Title: String Author: String Pages: Integer Methods: getSummary(): void Relationships: Association - A link between two classes. F.eks A customer places an order. This is how they are represented: 1, * 0..1 Aggregation - A ‘part-whole” relationship where parts can exist independently. F.eks Library and books. Composition - A “Part-whole” relationship where parts cannot exist without each other or the whole. Feks. Car and engine. A car would not work without an engine and is therefore useless. Inheritance - A subclass inherits attributes and methods from a parent class. Feks. admin extends a User. Here is an example for a restaurant system: Classes: Customer, Order, MenuItem Relationships: Customer places order. Order contains MenuItem. Composition - Order and menuItems. An order is nothing without menuItems. PACKAGE DIAGRAMS The purpose of package diagrams are to organize and group related elements into logical units/packages. This is to reduce the difficulty and enhance modularity. Here are the key components for package diagrams: Packages - Represented as folders. They group classes or other UML elements. Dependencies - Arrows show how one package relies on another. Here are some examples for E-commerce system: Packages: User Management: Contains User, Admin Order Management: Contains Order, Payment Inventory management: Contains Product, stock SOFTWARE DESIGN SOLID PRINCIPLES The SOLID principles are key guidelines for designing robust and maintainable object-oriented systems. Single responsibility Principle (SRP) A class should have only one reason to change, meaning it should have one clear responsibility. The purpose is to prevent classes from becoming too complex or tightly coupled. Here are some examples: Bad: A report class that handles both report generation and database access. Good: Split into report class and a reportRepository class for database access. Open/Closed principle (ICP) A class should be open for extension but close for modification. OCP allows adding new functionality without altering existing code, reducing the risk of introducing bugs. Here is an example: USe interfaces or abstract classes to extend behavior instead of modifying core functionality. Liskov Substitution Principle (LSP) Subclasses should be substitutable for their parent classes without breaking functionality. LSP ensures proper inheritance and avoids introducing bugs when using polymorphism. Here is an example: A subclass square should not violate behavior expected of its parent class rectangle. Interface segregation principle (ISP) A class should not be forced to implement interface it does not use. ISP avoids bloated interfaces and ensures each interface is specific to client needs. Here is an example: instead of a large animal interface with methods for both flying and swimming, create interfaces like ‘Flyable’ and ‘Swimmable’. Dependency Inversion Principle (DIP) High-level modules should not depend on low-level modules. Both should depend on abstractions. DIP promotes loose coupling by ensuring modules interact via avstractions. F.eks. A PaymentProcessor class depends on a PaymentMethod interface, not specific implementations like CreditCard or PayPal. OTHER PRINCIPLES Don’t Repeat Yourself (DRY) Avoid duplication code by abstracting repetitive logic into reusable functions or components. This enhances maintainability and reduces error caused by code duplication. F.eks. Extracting a common calculation into a helper function instead of repeating it across multiple classes. You Aren’t Gonna Need It (YAGNI) YAGNI principle tells you that you should not add functionality unless you absolutely need it. The purpose of YAGNI is to prevent overengineering and keep the codebase simple and focused. F.eks. Avoid implementing features based on assumptions of future needs. Law of Demeter (LoD) A class should only interact with its immediate “friends” and not with “strangers”. The purpose of this principle is to reduce dependencies between classes, promoting loose coupling. f.eks. instead of order.GetCustomer().getAddress(), use ordergetShippingAddress() to avoid chaining calls. SOFTWARE ARCHITECTURE Modular design - Modular design is dividing a system into smaller, independent modules with specific responsibilities. The purpose of this is to enhance maintainability, scalability and reusability. Here are some examples in an e-commerce system, separate modules could be: User management: handles registration and authentication. Order management: Manages order creation and tracking. Inventory management tracks stock levels. Cohesion - Cohesion is the degree to which elements within a module work together to achieve a single purpose. High cohesion - Modules have clear, focused responsibilities. Low cohesion - Modules handle unrelated tasks, making them harder to maintain. Here are some examples: A PaymentProcessor module that only handles payment logic has high cohesion. A module that processes payment and logs error has low cohesion. Coupling - Coupling is the degree of independency between different modules. Loose coupling: Modules interact through well-defined interfaces, minimizing dependencies. Tight coupling: Modules are heavily dependent on each other, making changes difficult. Here is an example: A PaymentProcessor module that depends only on an abstract PaymentMethod interface (loose coupling) Conceptual Integrity - The system’s architecture and design should maintain consistency across all modules. The purpose of conceptual integrity it to ensure that the design adheres to a unified vision or set of principles. Here is an example: Using consistent naming convertions, design patterns, and interface designs throughout the system. ARCHITECTURE PATTERNS Layered architecture - Organizes the system into hierarchical layers, each with specific responsibilities. The advantages with multiple layers is separation of concerns, scalability and ease of testing. Common layers: Presentation layer - User interface (UI) Business Logic layer - Core application logic Data access layer - handles database interactions Here is an example: A web application where the front-end (UI), back-end (logic), and database are separate layers. Model-View-Controller (MVC) - Separates application logic into three components: Model - Manages data and business rules View - Displays data to the user Controller - Handles user input and updates the model and view The advantages of MVC is that it promotes separation of concerns, making the system easier to test and maintain. Here is an example of a blog application: Model: Blog posts and comments View: HTML pages displaying posts Controller handles user actions like creating or editing posts Client-Server Architecture - Divides the system into two main components: Client - Requests service Service - Provides service The advantages of this is to centralize data management, scalability, and easy maintenance. Here is an example: A mobile app (client) interacting with a remote server to fetch data. VIEWS IN ARCHITECTURE Component and connector view - Focuses on the runtime behavior of the system by describing the components eks. Modules, services, etc, and their interactions eks. Method calls, data flows. Here are the key elements: Components: Represented as boxes (modules, database) Connectors: Represented as arrows showing communication between components. Example: A component diagram for a messaging app showing the interaction between the client, server and database. Module view - Focuses on the static organization of the system by showing how the system is divided into modules or packages. Here are the key elements: Modules: Represented as folder or packages Dependencies: Arrows showing how one module depends on another Example: A module view of an online shopping system with mackages like UserManagement, orderProcessing and Inventory. AGILE VS. PLAN-DRIVEN DEVELOPMENT AGILE DEVELOPMENT Agile Development - Agile is a flexible and iterative approach that focuses on delivering small, working increments of software frequently. Here are the key features: Iterative development: Work is broken into short cycles called iterations or sprints Working software: The primary measure of progress is functional software delivered early and updated frequently. Validation through iteration: Continuous feedback from users and stakeholders ensures the product meets requirements. Collaboration: Emphasis on close collaboration between developers, stakeholders and users. Advantages with Agile development is that it responds well to changing requirements. It involves stakeholders throughout the process. It also reduces the risk of building software that doesn’t meet user needs. Some challenges with this type of development is that it requires frequent communication and collaboration. It is less suited for projects with fixed scope and timelines. Scrum - Scrum is an Agile framework used for managing complex projects. It emphasizes iterative progress through small, cross-functional teams working collaboratively. Here are the key concepts of this framework: Roles in scrum: Product Owner: Is responsible for defining the product vision and prioritizing the product backlog. They act as the bridge between stakeholders and the development team. Scrum master: Ensures the team follows scrum practices and removes obstacles to progress. They facilitate scrum events like daily stand-ups and sprint retrospectives. Development team: A cross-functionaø team that works collaboratively to deliver parts of the product. Artifacts in strum Product backlog - Is a list of prioritized features, fixes and tasks to be implemented. This is owned by the product owner. Sprint backlog - Is a subset of product backlog selected for the current sprint. It is owned by the development team. Increment - Is a usable, potentially shippable product feature delivered at the end of each sprint. Events in scrum Sprint - A fixed time-box usually 1-4 weeks where a potentially shippable product increment is created. Sprint planning - A meeting to define what can be delivered in the print and how the theme will achieve it. Daily scrum (Stand-up) - A short daily meeting where the team discusses topics like what was done yesterday, what will be done today, and any other obstacles faced. Sprint review - A meeting at the end of the sprint to demonstrate the increment to gather stakeholder feedback. Sprint retrospective - Held after the sprint review to reflect on what went well, what didn't, and how processes can improve. Scrum values Commitment - Dedication to the team and print goals Courage - Facing challenges and delivering honest feedback Focus -Concentrating on the sprint goals Openness - Being transparent about progress and obstacles Respect - Mutual respect among team members PLAN DRIVEN DEVELOPMENT Plan-Driven Development - Is a structured linear approach where the project is planned in detail before development begins. This method is also known as the waterfall model. The key features are: Extensive documentation: Comprehensive requirements and design documents are created before coding begins. Predefined scope: The scope and goals of the project are fixed at the start. Sequential validation: Testing and validation are performed after the development phase is complete. The advantages of this type of documentation is that it works well for projects with clear and stabile requirements. It is suitable for highly regulated industries f.eks healthcare, aerospace, etc. It also provides cleat milestones and deliverables. Some of the challenges with plan-driven development is that it isn't very flexible when it comes to changes in requirements. It has a risk of delivering a product that no longer meets user needs by the end of development. TESTING AND VALIDATION Black-box testing - Testing the software without knowing the internal implementation. It focuses on inputs and expected outputs. The purpose of this type of testing ensures that the system meets user requirements and behaves as expected. Here is an example: Testing a login feature by providing valid and invalid credentials and checking the output without looking at code. White-box testing - Is testing the internal workings of the software, including code logic, structures, and algorithms. The purpose of this is to ensure that all paths, branches and loops in the code are tested. Here is an example: Testing a function that calculates discounts to ensure all conditions like customer type, purchase amount, etc are handled correctly. Acceptance testing - Testing conducted with the end user to validate that the software meets their needs and requirements. The purpose of this is to ensure that the software is ready for deployment. Here are two different types of acceptance testing: User acceptance testing (UAT): Performed by users to validate the system. Operational Acceptance testing (OAT): Focuses on non-functional aspects like performance and reliability. Here is an example: A retailer verifies that the e-commerce website allows customers to add items to a cart, check out, and receive an email confirmation. VALIDATION IN AGILE VS. PLAN-DRIVEN PROJECTS Agile validation - Agile validation happens when validation occurs continuously during development through iterations. This happens by getting frequent user feedback that ensures that changes are aligned with user needs. Tests are also automated and run frequently. Here is an example of agile validation: After each sprint, a demo is shown to stakeholders for validation. Plan-driven validation - Plan-driven validation is when validation happens in the later stages like After coding is complete. This type of validation occurs when tests are based on predefined requirements and documented extensively. When feedback is collected after major phases, such as development or testing, you get this type of validation. Here is an example: A team completes coding, conducts system testing, and then presents the finished product for user validation. TRACEABILITY MATRIX A traceability matrix is a document that links requirements to their corresponding design, implementation, and testing artifacts. A traceability matrix links requirements and testing artifacts to ensure all requirements are addressed. There are multiple reasons why one would do this. When ensuring completeness all requirements are addressed in the design and testing phases. Change management tracks the impact of changes in requirements. Accountability helps identify wich part of the system corresponds to specific requirements.