Download Software Engineering: Mid-Term Notes and more Study notes Software Engineering in PDF only on Docsity!
MID-TERM SE
C1:
1. Software Engineering - Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. 2. SE Layers - Tools - > Methods - > Process - > Quality 3. Software Process Activities - Software specification , where customers and engineers define the software that is to be produced and the constraints on its operation. - Software development, where the software is designed and programmed. - Software validation, where the software is checked to ensure that it is what the customer requires. - Software evolution, where the software is modified to reflect changing customer and market requirements. 4. Software Process: Plan-driven and Agile Processes - Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. - In agile processes , planning is incremental and it is easier to change the process to reflect changing customer requirements.
C2:
1. Functional and Non-functional requirements - Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. - Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. - Domain requirements: Constraints on the system from the domain of operation. **2. Requirements Specifications
- there are a number of generic activities common to all processes**
- Requirements elicitation
- Requirements analysis
- Requirements validation
- Requirements management
C4:
1. Advantages of explicit architecture - Stakeholder communication: Architecture may be used as a focus of discussion by system stakeholders. - System analysis: Means that analysis of whether the system can meet its non-functional requirements is possible. - Large-scale reuse: The architecture may be reusable across a range of systems 2. Architecture and system characteristics - Performance: Localise critical operations and minimise communications. Use large rather than fine-grain components. - Security: Use a layered architecture with critical assets in the inner layers. - Safety: Localise safety-critical features in a small number of sub-systems. - Availability: Include redundant components and mechanisms for fault tolerance. - Maintainability: Use fine-grain, replaceable components 3. 4 + 1 view model of software architecture - A logical view, which shows the key abstractions in the system as objects or object classes. - A process view, which shows how, at run-time, the system is composed of interacting processes. - A development view, which shows how the software is decomposed for development. - A physical view, which shows the system hardware and how software components are distributed across the processors in the system. 4. Layer Architecture - Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system.
C5:
1. Design Pattern - A design pattern is a way of reusing abstract knowledge about a problem and its solution. 2. Pattern Name - Description: Separates the display of object state from the object itself. - Problem description: Used when multiple displays of state are needed. - Solution description: See slide with UML description. - Consequences: Optimisations to enhance display performance are impractical. 3. Issues of Implementation i. Reuse level o The abstraction level: At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software. o The object level: At this level, you directly reuse objects from a library rather than writing the code yourself. o The component level: Components are collections of objects and object classes that you reuse in application systems. o The system level: At this level, you reuse entire application systems. ii. Configuration Management o The aim of configuration management is to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system. iii. Host-target Development o It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment. 4. Open-source development - Open-source development is an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process
o Domain testing: Testing the boundary condition against set of inputs o Scenario testing: Test based on a hypothetical story used to help a person think through a complex problem o Regression testing: Repeated testing on already tested program (after correction) ii. White Box o Static & Dynamic Analysis: Static analysis – code review, Dynamic analysis – executing code and analysing output o Statement coverage: Every statement is executed at least once o Branch coverage: Validating of all branches o Security coverage: To find out how ell system can protect itself from unauthorized access, hacking, etc. o Mutation coverage: Testing for the code that was modified after fixing a particular bug/defect. o Structural Testing: Help to measure the thoroughness of testing based on architecture of system (hierarchy)
6. Black Box Specification Test Data Invalid Valid Invalid Specifications Valid classes Invalid classes Integer ranges .. etween to > non - integer chars > chars uppercase letter to chars lowercase letters ot less than and not more than lower letters A , , C , D A C D others
7. White Box Specification
