Partial preview of the text
Download Software Engineering Cheat Sheet: Complete Guide in Just 4 Pages and more Cheat Sheet Software Engineering in PDF only on Docsity!
‘Software engineering is an engineering whose alm isthe pr delivered on time, within budget and that satisfies its requirements, ‘Software Engineering Paradigms refer to the various methods, models, and approaches used during the software development process. These paradigms provide structured ways to plan, design, develop, test, and maintain software systems. Advantages:_- Provides structure and clay. - Aids problem-solving and implementation. - Enhances code ‘and reuse. - Improves reliability and ily. Disadvantages: - Hard to learn for beginners - May not suit all p ation with afferent pa Limits: lity to new tech or needs. SDLE_ Software Development Life Cyle (SOLC) refer to he proces of planing, developing testing, nd mantaning tt the sy 10 Phases: 1. Requirement Analysis: Gathering ‘od nage juser needs. 2. System Design: Structuring the architecture ‘and components. 3. Development: Writing and implementing code. 4. Testing: Ensuring functionality and fixing issues. 5. Deployment: ng the for use. 6. M and fixing the post-releas ‘SDLC provides a framework for delivering high-quality software efficiently and systematically. Waterfall Model: - The waterfall model isa sequential approach to software development - The development process is. divided into distinct phases, and each phase must be completed before moving on to the next one. ‘Steps in the Waterfall Model: 1. Feasibility Study: Determines if the system is viable based on budget, technology, and integration capabilities, 2. Requirements Gathering: Collecting and defining the purpose, scope, and goals of the project. 3. Analysis: Documenting fu and system speci 4, Design: Planning UI, etch dels. 5 phewettio: Wing oodecbling th eltinseprng.6.Txt png of quality that is , in n \ Implementation Band unit Testing Implementation and unit T Release Il Prototyping Model: This model is used when customers are unsure about the exact project requirements. A prototype of the end product is first developed, tested, and refined based on customer feedback until an acceptable version is functionality, performance, and quality. 7. Deployment: the: to the pr ‘Maintenance: Ongoing support, bug fixes, and updates. Advantages: Simple and easy to understand. phases ‘completing one phase before moving to the next. Well-sulted for projects with clear and stable requirements. 3: No feedback loops, making it hard to revise earlier stages. Difficult to accommodate changes in requirements. Unsuitable for complex projects with frequently changing needs. Testing happens late in the process. : Small to medium-sized projects with well-defined requirements. Applications with a fixed scope or well-established design. Projects with experienced teams and minimal need for ongoing feedback. ieee as IMerative Enhancement Model - The model of isa ‘approach where steps, known as are unt the |e complete. - The development process Is divided Into ‘smaller cycles, with each cycle adding new ‘oF refining existing ones. - is developed ntally, with each iteration improving or adding new functionality. Characteristics of Iterative Enhancement Model - Allows flexibility and adaptability, enabling software to be refined over time based on feedback. - Useful when the customer's requirements are unclear or when there's high complexity. - Reduces project risks by delivering working software quickly. -Priorizes malor functionalities, with customers specifying requirements iteratively. - Requires skilled analysts to manage dependencies between functionalities. ‘Advantages - Fu software is after each cycle, and helps imp cycles. - Parallel development can be planned. - Progress is measurable. - Changes to scope/requirements are less costly. - Testing and debugging are easier due to smaller iterations. Disadvantages - Not suitable for projects where th star comet defen cbpars, Rees gh shiled resources to understand dependencies beim functionalities. at Model - Apache web server - Mozilla Firefox . (SAP, Salesforce) - Other examples: Wikipedia, Linux. Requirement Engineering is the ‘of proven p tools, and notations to a proposed systems. behavior and its associated the fu lity of. . + Specty the interfaces external tothe software item.» Provide performance specications «Set forth the qualification criteria for software testing. * Set forth the human factors engineering specifications for the user interface. Define what the system should do, focusing on specific functionalities or behaviors (e.g., user authentication, data processing). ine how the system should perform, 1, which serves as the forthe final ital requirements are gathered, followed by the creation of a quick design ‘and prototype. The the prototype, providing that leads to refining the prototype. This continues until the the final version. ter the customer ‘approves the prototype, actual software development follows using an iterative waterfall approach. Even with a working prototype, an SRS document is created for traceability, verification, and test case design. For GUI components, the ‘approved prototype serves as the requirements specification, eliminating the need for further analysis. Strengths: - Ideal for projects facing technical and requirement risks, as the prototype helps mitigate these risks. ‘Weaknesses: - Can increase development costs for routine projects with minimal risks. - Most effective when risks are Identified early; Hf new risks emerge during development, the model may become less effective and unsuitable for such Projects. Quick Design [ Develop Prototype { ceceina ane | | : ronienent ‘Requirements Process Model: The requirements process starts with a business or engineering problem and generates specifications for a system to solve that problem. It consists of four activities: 1 Requirements Elicitation: Requi tation isthe process of working with ‘to gather their needs, “articulate their problems, identify conflicts, and establish clear project scope and boundaries. It ensures stakeholders have the chance to explain their needs and describe what they want the new system to do. Dimensions: Understanding Un ‘Non-Eunctional Requirements: Defi quality aspects like performance, security, and reliability e.g., sponse time, system uptime). EXAMPLE: In an airline tracking system: - Functional Requirement: The system shell assign @ unique PNR number to ‘each booking and allow users to check the status of their fights. - Non-Functional Requirement: The system shall display the flight status within 3 seconds of entering the PNR number and ensure that only authorized personnel can modi flight details. Parameters Functional Requirements Non-Functional Requirements Requirement Tis nonemnandl ory Capturing Type itis captured in use cases. | itis captured as a quality ‘allribate End Result Product Feature Product Properties Capturing Easy to Capture Hard to Capture Objective: Helps to verity the Helps to verity the functionallty of the software. performance of the software. Area of Focus Focuses on user-requirement, Focuses on the user's expectation & experience. the problem, U ng the domain, identifying clear 19 the needs, Understanding the systems constraints, Writing business objectives forthe project. 2. Requirements Analysis: ng, ding, and synthesizing the req in context. ‘3. Requirements Specification: Creating documents outlining software and system specifications. ‘Conducting formal and informal reviews to ensure the requirements meet customer needs ‘4, Requirements Validation: in the intended environment. rene —— close gaps | | Contin ad correch ‘lctation techniques are used to gather requ from ‘The choice of technique depends on the nature of the system being developed and the preferences of the stakeholders. 1L Interviews: Direct conversations to understand needs. - Pros: Clear insights. - Cons: Jargon and missed activities. 2. Prototyping: Bulld a prototype to clarify ambiguous requirements. - Pros: Visualizes unclear needs. - Cons: Risk of Documentation ibe what the product | Describe how the product ‘does. w scope creep. 3. Facilitated St meetings. - Pros: C ‘and Product Info: Product features Product Propertios entificetion. - Cone: Dotnet nividuse ney bles results. Emergent Properties: Some requirements represent emergent properties of software, meaning they cannot be 4.08 Engineers: ‘users in their = Pros: insights. - Cons: Time-consuming. bya single but depend on how all For example, the throughput of a cal center depends on how the telephone system, information system, and operators interact under real ‘operating conditions. Emergent properties are heavily influenced by the system architecture and how components collaborate to fulfil the overall requirements. 5. User Stories: Short descriptions of features in customer terms. - Pros: Simple and easy to understand, - Cons: May lack detail for implementation. ‘The selection of an elicitation technique should be based on the projects nature, stakeholders‘ needs, and the clarity required for the systems requirements, ) FAST isa team-oriented approach that combines brainstorming ‘sessions with active participation from both customers and developers. The goals to gather information, share ideas, ‘and create specifications collaboratively. ‘Guidelines 1. Arrange a ata neutral site. 2. rules for p 3.Use an} agendato ‘encourage free flow of ideas. 4. Appoint a facilitator to guide the session. 5. Prepare materials such as a definition mechanism board, worksheets, and wal stickers. 6. Ensure participants avold criticizing or debating during the session. FAST Session Preparations Each attendee is asked to list: 1. Objects that ae part ofthe systems environment. 2. Objects produced by the system. 3. Objects used by the system. Additionally, participants should list constraints, functions, and performance criteria. ‘Activites of a FAST Session 1. Participants present their lists. 2. Combine the lists for each topic. 3. Engage ina group ecunion, 4, ret conn Bt, Form bere to wok on repens. 6 Prevent the pect criteria. 8. drafts the final specifications. the.ces Dara = «ype of Unifed Molin Langwge (UN) degra tt erent th ntacton batwoon ators (users or external systems) and a system under consideration to accomplish specific goals. It provides high-level view ‘of the systomis functionality by illustrating the various ways users can interact with it. ‘Use Case Diagram Notations: 1. Actors: External entities interacting with the system (users, devices). 2. Use Cases: Specific actions the system can perform (represented by ovals). 3. System Boundary: Defines the scope ofthe system (represented by a rectangular box). 
