Software Development Life Cycle (SDLC) The Software Development Life Cycle (SDLC) is a structured process used by software developers and engineers to design, develop, test, and deploy software systems. The goal of SDLC is to produce high-quality software that meets or exceeds customer expectations, reaches completion within time and cost estimates, and operates efficiently and effectively.Phases of the SDLC: SDLC consists of several well-defined stages or activities, each of which contributes to the successful development and maintenance of software. 1. Requirement Gathering and Analysis e Objective: Understand what the client or user needs from the software. ¢ Activities: e Stakeholder interviews e Surveys/questionnairese Document analysis e Feasibility study (technical, operational, financial) e Deliverable: Software Requirement Specification (SRS) document. 2. System Design e Objective: Translate requirements into a blueprint for software architecture. e Activities: e High-level design (HLD): system architecture V tabase design, modules. data flowe Low-level design (LLD): logic for individual components e Choose technologies, tools, platforms ¢ Deliverables: Design documents, system architecture diagrams 3. Implementation (Coding) ¢ Objective: Convert the design into a functioning software system by writing code. ve Ensuring the code meets the design specifications. e Unit testing each module during development to ensure individual parts function correctly. e Version control (e.g., using Git) to manage the codebase and track changes. 4. Testing ¢ Objective: Identifying and fixing any defects, ensuring the software works as expected. e Activities: LVe Unit testing (test individual modules) e Integration testing (test how modules work together) e System testing (test the complete system) ¢ Acceptance testing (check if software meets user requirements) ¢ Deliverables: Test cases, bug reports, tested code5. Deployment ¢ Objective: Deliver the software to the client or release it to users. e Activities: e Install software in production environment e Migration of data (if needed) e User training and documentation e Deliverables: Deployed application, user manuals6. Maintenance e Objective: Ensure the software continues to work well after deployment. e Activities: e Bug fixes and updates e Performance enhancements ¢ New feature integration e Support and troubleshooting e Deliverables: Updated versions, patches, maintenance logsCommon SDLC Models There are several methodologies that implement the SDLC in different ways, such as: e Waterfall Model (linear and sequential) e Agile Model (iterative and incremental) e \V-Model (verification and validation) ¢ Spiral Model (risk-driven iterative approach) ¢ DevOps (collaboration between development and operations)In Software Engineering, the Software Development Life Cycle (SDLC) consists of a series of well-defined activities or phases that guide the development of software from inception to retirement. These activities ensure systematic, efficient, and high-quality software production.Software Myths i- iq Sofware Myths means common belie€s about Software evelopment shat ceyy notbe true: -—these myths con Some tines ‘Teads to false expectatie {he Myths are classitied ‘nto ee they are I+ Management myth ; 2. customer myth 3 practifioner myth ian the Management myth ~the managers are responsible —for the deueloping. ~the soPtaate “Sty Some of “the Management ryt aes gen bebe ch Myth :- he Management hinks we already: “Pave woth full o€ stanolands & procedures" By reading these ‘bicks. we Geuelop sofleware Reality : s- Tf all Stardard & procedures are pres in ips to” léuelop a, Sofkene but ib 3 7870 books —that hel fer the maintain correct quattly. " SI Maitgs possible -SSA Spe +t au orandanos & procegurs7 ~~ books —that ’ helps Ho" déuelop a, - Solace but possibie fe she * maintain. . correct quality. cs ig 70 che aN Myth tng ney peopl inte “sthe * ‘pmniscl keads, do finish athe project \ in sheduled -tirne Wonks Reality 2— Pauling new people into ~he project cannok ~ make* the project. can, Complete in intime and tb eda the. ime: period +o. explain overall project and the money will also increayed. :Be Castomer myth :— customer myths are gererally chie 40 fake erpectabn Beaierdesines myths. ener. xavig casherens Te Satisfaction with ite setume chevelefer customer can gilt Gre regutrererts 40, an add more regiiremenk later” | TaelsSRR IE PST. cor can add more tegertremenr tater “Tn Th it ret possiby when we write overall Br design 2 pregrat ard. add lew wrote *Porges (progam. when nee requirement Ye ockted n eerall propio” by ~the- cusleener 3 a3. Develop next Vension oh sleo 4. Revfeus 4 Plan for next phase,Dunt* I. Define cbrective > —_— oa. Tents and resolve atecks 3. Dawelop nextThe Spiral Model is a software development process model that combines the features of the Waterfall Model and Prototyping Model. It emphasizes iterative development and risk management, making it especially useful for large, complex, and high-risk projects. Spiral Model — Key Features: 1. Iterative Nature: The software is developed in iterative steps or "spirals." 2. Risk Handling: Each phase includes risk analysis and risk mitigation. v 3. Customer Feedback: Continuous3. Customer Feedback: Continuous involvement of the customer through prototyping and evaluation. 4. Flexibility: Requirements can evolve and change through iterations. © Phases of the Spiral Model: Each loop (or spiral) is divided into four main quadrants: 1. Planning Phase: ¢ Define objectives. v e Identify [Link] (bothe Identify requirements (both functional and non-functional). 2. Risk Analysis Phase: e Identify potential risks. e Perform risk analysis and mitigation strategies. e Evaluate alternative solutions. 3. Engineering Phase: ¢ Develop and verify the next version of the product. e Includes coding, testing, and deployment in iterations. 4, Evaluation Phase y,4. Evaluation Phase: e Review and evaluate the progress with the customer. e Plan for the next iteration based on feedback. YJ When to Use Spiral Model: e Projects with unclear or evolving requirements. e High-risk software applications (e.g., financial, military). e Projects that require frequent revisionssf Summary: The Spiral Model is suitable for dynamic and high-risk projects where continuous refinement and risk management are essential. Its cyclic approach allows developers to build progressively while addressing potential risks early.— AALAYERED TECHNOLogy: Io layered technology | Software Is Seen In gion SB Retin© Layered Technology in Software Engineering Layered technology in software engineering refers to a structured approach to software development where the entire process is divided into distinct layers, each with specific responsibilities. This concept ensures a systematic, organized, and manageable development lifecycle.1. 1. Tools ¢ Definition: Automated or semi- automated software used to support the software development process. e Examples: ¢ IDEs (e.g., Visual Studio, Eclipse) e Testing tools (e.g., Selenium, JUnit) e Version control tools (e.g., Git, SVN) 2. 2. Methods ¢ Definition: Technical methods that provide the Te for building software.2. 2. Methods ¢ Definition: Technical methods that provide the "how-to" for building software. e Includes: e Requirements analysis e Design methods (e.g., UML diagrams) ¢ Coding practices e Testing strategies e Goal: Ensure that the product is built correctly and efficiently. 3. 3. Process Vv3. 3. Process ¢ Definition: The framework that binds tools and methods together to produce quality software. e Examples: ¢ Software Development Life Cycle (SDLC) models like: e Waterfall e Agile e Spiral e Process activities: Planning, tracking, quality assurance ¢ Goal: Deliver V ‘tware on time, withine Goal: Deliver software on time, within budget, and according to requirements. 4. 4. A Quality Focus ¢ Definition: A continuous emphasis on quality at each layer. e Activities: e Reviews e Audits e Testing e Metrics collection ¢ Goal: Ensure high reliability, maintainabil J derformance, andEach upper layer builds on the support provided by the lower layers. Quality focus wraps all other layers to ensure consistent improvement and adherence to standards. sy? Key Benefits: ¢ Modularity and scalability in development e Easy management and maintenance e Supports standardization and automation ¢ Helps achieve high-quality software productsProcess Framewomk Framework Achyittes | Task Sets | milestone, Mont Product [enh Umbmella ActivitiesThe Software Process Framework in software engineering refers to a structured set of activities and practices used to develop software systems. It provides a foundation or blueprint for software development by organizing how tasks are performed, how outputs are created, and how progress is tracked. %, Core Activities in a Software Process Framework Most software process frameworks are built around a set of umbrella and framework activities:These are fundamental to any software process model: Activity Communication Planning Modeling Construction Description Oo Understand and gather software requirements from stakeholders. Estimate resources, time, cost, and develop a project schedule. Create design models for data, architecture, interfaces, and components. Involves coding ( \ lopment) and testing of tha enftaaraModeling Create design models for data, architecture, interfaces, and components. Construction Involves coding (development) and testing of the software. Deployment Deliver the finished product to the customer, gather feedback, and perform updates. Y 2. Umbrella Activities (Support Activities) uActivities) These run alongside the framework activities and support the development process: Activity Description Oo Project Tracking Ensure the project stays on and Control track in terms of timeline, Risk Management Quality Assurance (QA) Configuration cost, and quality. Identify, analyze, and mitigate potential risks in the project. Enforce standards, procedures, and testing to ensure software quality. v Control chanaes in software(QA) Configuration Management Technical Reviews Documentation proceaures, ana testing to ensure software quality. Control changes in software to maintain integrity and traceability. Regular peer reviews of code and design for correctness and efficiency. Record all aspects of the software process and product for future reference.Waterfall Process Model yf Definition: The Waterfall model is a linear and sequential software development process where each phase must be completed before moving to the next. It flows downwards like a waterfall — hence the name.Requirements adhering § Arahat 0 an Planning $ Design y Leal y (Tateg |, ! \ Matntenancé |Phases of the Waterfall Model 1. Requirements Gathering and Analysis e In this initial phase, all potential requirements of the system to be developed are gathered from stakeholders, customers, and domain experts. e The focus is on what needs to be done, not how. ¢ The output is a detailed Requirements Specification Document. JAdvantages of the Waterfall Model 1. Simple and Easy to Use: Clear structure and well-defined stages. 2. Easy to Manage: Due to its rigidity, it’s easier to manage with clear milestones. 3. Well-documented Process: Each phase has specific deliverables and documentation. 4. Works well for smaller projects: Especially when requirements are well understood.Disadvantages of the Waterfall Model 1. 3€ Inflexibility to Changes: Difficult to go back and change requirements or design once a phase is completed. 2. € Late Discovery of Issues: Testing happens late, so design flaws or incorrect assumptions may surface too late. 3. € Poor Model for Long-Term or Complex Projects: Not ideal for projects with uncertain or evolving requirements. 4. S€ No Customer Feedback during Development: Customers only see the final product, wh, v May not meetWhen to Use the Waterfall Model e Requirements are clearly defined and fixed. e Technology is well understood. e The project is short or relatively simple. e Minimal risk of requirement changes. e High emphasis on documentation.Sure! In Software Engineering, software myths refer to widely held but false beliefs about software development and management. These myths often cause misunderstandings, poor decision-making, and inefficient practices in software projects. They can be held by managers, developers, or customers, and typically stem from outdated or oversimplified ideas about how software is created. Let's explore these myths in detail, categorized based on the group that typically holds them: ¢ 1. Management Myths These are myths held by managers or those in charge of planning, budgeting, or supervising software development.¢ 1. Management Myths These are myths held by managers or those in charge of planning, budgeting, or supervising software development. Myth 1: “We already have a book of standards and procedures—won't that give us good software?” ¢ Reality: Standards and procedures are useful, but they must be applied thoughtfully and customized to each project. Blindly following rigid procedures doesn't guarantee success or quality software. Myth 2: “Hiring more programmers will speed up the project.” e Reality: Adding more people to a late project often delays it further (Brooks’ Law). New team members ce mT and¢ 2. Customer Myths These are misconceptions held by clients or end- users of the software. Myth 1: “A general statement of objectives is enough to start writing programs—we can fill in the details Tae e Reality: Lack of clear and detailed requirements leads to confusion, rework, and project failure. Proper requirements analysis is essential before development begins. Myth 2: “Software is easy to change, so we can add features anytime.” e Reality: While software is flexible, making changes late in the process can be costly, time-consuming, and_risky, especially without proper change man. iment.¢ 3. Developer Myths These myths are typically believed by software engineers or programmers themselves. Myth 1: “Once we write the program and get it to work, our job is done.” e Reality: Development is only one part of the software life cycle. Maintenance, testing, documentation, and support are ongoing and significant responsibilities. Myth 2: “Until 1 get the program running, | have no way of knowing whether it will ols ale e Reality: With proper design, modeling, and testing, developers can anticipate and fix issues before the code is complete. es¢ Why Are Software Myths Dangerous? e They set unrealistic expectations. e Lead to poor project planning and wasted resources. e Cause conflict between stakeholders. ¢ Result in low-quality software or project failure.