Software development life cycle (SDLC) is a structured process that is used to design, develop, and test good-quality software. SDLC, or software development life cycle, is a methodology that defines the entire procedure of software development step-by-step.
Stages of the Software Development Life Cycle SDLC specifies the task(s) to be performed at various stages by a software engineer or developer. It ensures that the end product is able to meet the customer’s expectations and fits within the overall budget.
Stage-1: Planning and Requirement Analysis Planning is a crucial step in everything, just as in software development. In this same stage, requirement analysis is also performed by the developers of the organization. This is attained from customer inputs, and sales department/market surveys.
Stage-2: Defining Requirements In this stage, all the requirements for the target software are specified. These requirements get approval from customers, market analysts, and stakeholders. This is fulfilled by utilizing SRS (Software Requirement Specification).
Stage-3: Designing Architecture SRS is a reference for software designers to come up with the best architecture for the software. Hence, with the requirements defined in SRS, multiple designs for the product architecture are present in the Design Document Specification (DDS).
Stage-4: Developing Product At this stage, the fundamental development of the product starts. For this, developers use a specific programming code as per the design in the DDS
Stage-5: Product Testing and Integration After the development of the product, testing of the software is necessary to ensure its smooth execution. Although, minimal testing is conducted at every stage of SDLC. Therefore, at this stage, all the probable flaws are tracked, fixed, and retested. This ensures that the product confronts the quality requirements of SRS.
Stage-6: Deployment and Maintenance of Products After detailed testing, the conclusive product is released in phases as per the organization’s strategy. Then it is tested in a real industrial environment.
advantages and Disadvantages of SDLC
Advantages Of SDLC Structured Approach:- SDLC provides a structured approach to software development, In addition, it enables developers to plan and organize their work more efficiently. Besides, this approach helps to minimize errors, increase productivity, and ensure the timely delivery of software. Risk Management:- SDLC helps to identify and manage risks associated with software development. Further, by identifying potential risks early in the development process, developers can take steps to mitigate them, which reduces the overall risk of software development. Consistency:- SDLC ensures consistency in offshore software development by providing a standard framework and methodology. Besides, this consistency helps to improve the quality of the software and ensures that the end product meets the client’s expectations. Collaboration:- SDLC encourages collaboration among team members by providing a common application frameworks and language for communication. This collaboration helps to improve the overall quality of the software and ensures that the end product meets the client’s requirements. Cost-Effective:- SDLC helps to reduce development costs by identifying potential issues early in the development process using prototype software like Figma and others. Furthermore, by identifying issues early, developers can take steps to mitigate them.Which reduces the overall cost of development.
Disadvantages Of SDLC Time-Consuming:- SDLC can be time-consuming, especially if the development process is complex. This can result in delays in the delivery of software, which can be frustrating for clients. Inflexibility:- SDLC can be inflexible, especially if the requirements change during the development process. This inflexibility can result in a suboptimal end product that does not meet the client’s expectations. High Upfront Cost:- SDLC requires a significant upfront investment in terms of time, money, and resources. Moreover, this can be a barrier to entry for small businesses or startups that may not have the resources to invest in SDLC. Overemphasis on Process:- SDLC can sometimes place too much emphasis on the process and not enough emphasis on the end product. And then this can result in a lack of innovation and creativity in the final product.
Q) 1) What is Software Development Life Cycle? Explain with a neat sketch. 2) What are the advantages and Disadvantages of SDLC? 3) Briefly Describe the Phases of Software Development Life Cycle. How is it different from software development life cycle? 4) State and explain various phases of software development life cycle.
Waterfall model The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (downwards like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.The waterfall model is the earliest SDLC approach that was used in software development. The waterfall development model originated in the manufacturing and construction industries, where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process
The waterfall model is a software development model used in the context of large, complex projects, typically in the field of information technology. It is characterized by a structured, sequential approach to project management and software development. Features of the SDLC Waterfall Model Sequential Approach : The waterfall model involves a sequential approach to software development, where each phase of the project is completed before moving on to the next one. Document-Driven : The waterfall model relies heavily on documentation to ensure that the project is well-defined and the project team is working towards a clear set of goals. Quality Control: The waterfall model places a high emphasis on quality control and testing at each phase of the project, to ensure that the final product meets the requirements and expectations of the stakeholders. Rigorous Planning: The waterfall model involves a rigorous planning process, where the project scope, timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.
Phases of SDLC Waterfall Model The Waterfall Model is a classical software development methodology that was first introduced by Winston W. Royce in 1970. It is a linear and sequential approach to software development that consists of several phases that must be completed in a specific order. The Waterfall Model has six phases which are: 1. Requirements: The first phase involves gathering requirements from stakeholders and analyzing them to understand the scope and objectives of the project. 2. Design: Once the requirements are understood, the design phase begins. This involves creating a detailed design document that outlines the software architecture, user interface, and system components. 3. Development: The Development phase include implementation involves coding the software based on the design specifications. This phase also includes unit testing to ensure that each component of the software is working as expected. 4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the requirements and is free from defects. 5. Deployment: Once the software has been tested and approved, it is deployed to the production environment. 6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing any issues that arise after the software has been deployed and ensuring that it continues to meet the requirements over time.
The classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can be started after the completion of the previous phase. That is the output of one phase will be the input to the next phase. Thus the development process can be considered as a sequential flow in the waterfall. Here the phases do not overlap with each other.
These analyzed requirements are documented in a software requirement specification (SRS) document. SRS document serves as a contract between the development team and customers. Any future dispute between the customers and the developers can be settled by examining the SRS document. Alpha testing: Alpha testing is the system testing performed by the development team. Beta testing: Beta testing is the system testing performed by a friendly set of customers. Acceptance testing: After the software has been delivered, the customer performs acceptance testing to determine whether to accept the delivered software or reject it. Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered during the product development phase. Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the system based on the customer’s request. Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in a new environment such as working on a new computer platform or with a new operating system.
Advantages of the SDLC Waterfall Model Easy to Understand: The Classical Waterfall Model is very simple and easy to understand. Individual Processing: Phases in the Classical Waterfall model are processed one at a time. Properly Defined: In the classical waterfall model, each stage in the model is clearly defined. Clear Milestones: The classical Waterfall model has very clear and well-understood milestones. Properly Documented: Processes, actions, and results are very well documented. Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like define-before-design and design-before-code. Working: Classical Waterfall Model works well for smaller projects and projects where requirements are well understood. Disadvantages of the SDLC Waterfall Model No Feedback Path: In the classical waterfall model evolution of software from one phase to another phase is like a waterfall. It assumes that no error is ever committed by developers during any phase. Therefore, it does not incorporate any mechanism for error correction.
Difficult to accommodate Change Requests: This model assumes that all the customer requirements can be completely and correctly defined at the beginning of the project, but the customer’s requirements keep on changing with time. It is difficult to accommodate any change requests after the requirements specification phase is complete. No Overlapping of Phases: This model recommends that a new phase can start only after the completion of the previous phase. But in real projects, this can’t be maintained. To increase efficiency and reduce cost, phases may overlap. Limited Flexibility: The Waterfall Model is a rigid and linear approach to software development, which means that it is not well-suited for projects with changing or uncertain requirements. Once a phase has been completed, it is difficult to make changes or go back to a previous phase. Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential approach, which means that stakeholders are typically involved in the early phases of the project (requirements gathering and analysis) but may not be involved in the later phases (implementation, testing, and deployment). Late Defect Detection: In the Waterfall Model, testing is typically done toward the end of the development process. This means that defects may not be discovered until late in the development process, which can be expensive and time-consuming to fix. Lengthy Development Cycle: The Waterfall Model can result in a lengthy development cycle, as each phase must be completed before moving on to the next. This can result in delays and increased costs if requirements change or new issues arise.
When to Use the SDLC Waterfall Model? Well-understood Requirements: Before beginning development, there are precise, reliable, and thoroughly documented requirements available. Very Little Changes Expected: During development, very little adjustments or expansions to the project’s scope are anticipated. Small to Medium-Sized Projects: Ideal for more manageable projects with a clear development path and little complexity. Predictable: Projects that are predictable, low-risk, and able to be addressed early in the development life cycle are those that have known, controllable risks. Regulatory Compliance is Critical: Circumstances in which paperwork is of utmost importance and stringent regulatory compliance is required. Client Prefers a Linear and Sequential Approach: This situation describes the client’s preference for a linear and sequential approach to project development. Limited Resources: Projects with limited resources can benefit from a set-up strategy, which enables targeted resource allocation.
Applications of SDLC Waterfall Model Safety-Critical Systems: The Waterfall Model is often used in the development of safety-critical systems, such as aerospace or medical systems, where the consequences of errors or defects can be severe. Government and Defense Projects: The Waterfall Model is also commonly used in government and defense projects, where a rigorous and structured approach is necessary to ensure that the project meets all requirements and is delivered on time. Projects with well-defined Requirements: The Waterfall Model is best suited for projects with well-defined requirements, as the sequential nature of the model requires a clear understanding of the project objectives and scope. Projects with Stable Requirements: The Waterfall Model is also well-suited for projects with stable requirements, as the linear nature of the model does not allow for changes to be made once a phase has been completed. Q) Briefly explain about the Waterfall model. What are the advantages and disadvantages of Waterfall model?
V-model The V-model is a type of SDLC model where the process executes sequentially in a V-shape. It is also known as the Verification and Validation model. It is based on the association of a testing phase for each corresponding development stage. The development of each step is directly associated with the testing phase.
Design Phase: Requirement Analysis: This phase contains detailed communication with the customer to understand their requirements and expectations. This stage is known as Requirement Gathering. System Design: This phase contains the system design and the complete hardware and communication setup for developing the product. Architectural Design: System design is broken down further into modules taking up different functionalities. The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood. Module Design: In this phase, the system breaks down into small modules. The detailed design of modules is specified, also known as Low-Level Design (LLD). Testing Phases: Unit Testing: Unit Test Plans are developed during the module design phase. These Unit Test Plans are executed to eliminate bugs at the code or unit level. Integration testing: After completion of unit testing Integration testing is performed. In integration testing, the modules are integrated, and the system is tested. Integration testing is performed in the Architecture design phase. This test verifies the communication of modules among themselves. System Testing: System testing tests the complete application with its functionality, interdependency, and communication. It tests the functional and non-functional requirements of the developed application. User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the production environment. UAT verifies that the delivered system meets the user’s requirement and the system is ready for use in the real world.
Q ) Write a short note on V Software Development Life Cycle model
Spiral Model The Spiral Model is a combination of the waterfall model and the iterative model. It provides support for Risk Handling. The Spiral Model was first proposed by Barry Boehm. The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic and iterative approach to software development. In its diagrammatic representation, looks like a spiral with many loops. The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the spiral is called a phase of the software development process.
Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution. Develop the next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-far developed version of the software. In the end, planning for the next phase is started.
The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For example, a single loop spiral actually represents the Iterative Waterfall Model. The spiral model incorporates the stepwise approach of the Classical Waterfall Model. The spiral model uses the approach of the Prototyping Model by building a prototype at the start of each phase as a risk-handling technique. Also, the spiral model can be considered as supporting the Evolutionary model – the iterations along the spiral can be considered as evolutionary levels through which the complete system is built.
Advantages of the Spiral Model Risk Handling: The projects with many unknown risks that occur as the development proceeds, in that case, Spiral Model is the best development model to follow due to the risk analysis and risk handling at every phase. Good for large projects: It is recommended to use the Spiral Model in large and complex projects. Flexibility in Requirements: Change requests in the Requirements at a later phase can be incorporated accurately by using this model. Customer Satisfaction: Customers can see the development of the product at the early phase of the software development and thus, they habituated with the system by using it before completion of the total product. Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental approach to software development, allowing for flexibility and adaptability in response to changing requirements or unexpected events. Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk management, which helps to minimize the impact of uncertainty and risk on the software development process. Improved Communication: The Spiral Model provides for regular evaluations and reviews, which can improve communication between the customer and the development team. Improved Quality: The Spiral Model allows for multiple iterations of the software development process, which can result in improved software quality and reliability.
Disadvantages of the Spiral Model Complex: The Spiral Model is much more complex than other SDLC models. Expensive: Spiral Model is not suitable for small projects as it is expensive. Too much dependability on Risk Analysis: The successful completion of the project is very much dependent on Risk Analysis. Without very highly experienced experts, it is going to be a failure to develop a project using this model. Difficulty in time management: As the number of phases is unknown at the start of the project, time estimation is very difficult. Complexity: The Spiral Model can be complex, as it involves multiple iterations of the software development process. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple evaluations and reviews. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a significant investment in planning, risk analysis, and evaluations. Q) Briefly explain about the Spiral Software Development Life Cycle What are the Pros and Cons of Spiral Software Development Life Cycle?
Unified Process The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a flexible and iterative approach to developing software. It focuses on creating working software increments, collaborating with team members, and adapting to changes.
Key Principles of Unified Process Iterative and Incremental: Unified Process divides the development process into multiple iterations, with each iteration adding new functionality incrementally. Use Case Driven: The Unified Process focuses on identifying and prioritizing use cases that represent the system’s functionality from the user’s perspective. Architecture-Centric: The Unified Process emphasizes defining and refining the system architecture throughout the development process. Risk Management: Unified Process identifies and manages project risks proactively to minimize their impact on the project’s success. Continuous Validation: Unified Process ensures continuous validation of the system’s requirements, design, and implementation through reviews, testing, and feedback.
Phases of Unified Process Unified Process (UP) is characterized by its iterative and incremental approach to software development. 1. Inception This is the initial phase where the project’s scope, objectives, and feasibility are determined. Key activities in this phase include identifying stakeholders, defining the initial requirements, outlining the project plan, and assessing risks. 2. Elaboration In this phase, the project requirements are analyzed in more detail, and the architecture of the system is defined. Key activities include developing use cases, creating the architectural baseline, identifying key components, and refining the project plan. 3. Construction This is the phase where the actual implementation of the system takes place. Key activities include developing, testing, and integrating the system components, as well as continuously verifying that the system meets the requirements. 4. Transition In this final phase, the software is deployed to end users. Key activities include user training, final system testing, and transitioning the system to the operations and maintenance team. These phases are iterative, meaning that they may be revisited multiple times throughout the project to incorporate feedback, make improvements, and address changes in requirements. This iterative approach allows for flexibility and adaptability, making the Unified Process well-suited for complex and evolving software projects.
Q) Describe various stages in Unified process model
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment. The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach frameworks Scrum, Kanban, Extreme Programming,Feature -Driven Development (FDD),lean practices pair programming, test-driven development, stand-ups (daily meetings), sprint planning, and sprints (iterations) Agile Software Development Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it
Agile is a Mindset Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty. Agile Manifesto The Agile Manifesto was written in 2001 by seventeen independent-minded software practitioners value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Value 1: Individuals and interactions In the past, a lot of software teams would concentrate on having the best possible tools or processes with which to build their software. The Agile Manifesto suggests that while those things are important, the people behind the processes are even more so. Having the right group of individuals on your software team is vital to success. The best possible tools in the wrong hands are worthless. Perhaps even more important is how these individuals communicate with each other. The interactions between team members are what helps them to collaborate and solve any problems that arise. Value 2: Working software Previously, software developers would spend ages creating detailed documentation. That was before they even started writing a single line of code. And while documentation isn’t a bad thing, there comes a point when you should focus on providing your customers with working software. The Agile Manifesto places shipping software to your customers as one of the highest priorities. You can then gather feedback to help you improve future releases.
Value 3: Customer collaboration Once upon a time, contracts were king. You would draw up contracts with your customers who would then detail the finished product. As a result, there was often a contrast between what the contract said, what the product did, and what the customer actually required. According to the Agile Manifesto, the focus should be on continuous development. You need to build a feedback loop with your customers so that you can constantly ensure that your product works for them. Value 4: Responding to change Can you imagine a time where you would draw up a roadmap and it would never change? Well, in the past that’s exactly what happened. The trouble with static roadmaps is that we don’t live in a static world. Needs and requirements are always shifting, and priorities are always changing. That static roadmap will soon grow outdated. That’s why the Agile Manifesto suggests that a software team should have the ability to pivot and change direction whenever they need to, with a flexible roadmap that reflects that. A dynamic roadmap can change from quarter to quarter, sometimes even month to month, and agile teams are able to keep up with those changes.
Q) What are the four values of the Agile Manifesto? Explain What are the principles of Agile development? Explain.
What is Agile Model? The Agile Model was primarily designed to help a project adapt quickly to change requests. So, the main aim of the Agile model is to facilitate quick project completion. To accomplish this task, agility is required. Agility is achieved by fitting the process to the project and removing activities that may not be essential for a specific project. Also, anything that is a waste of time and effort is avoided. The Agile Model refers to a group of development processes. These processes share some basic characteristics but do have certain subtle differences among themselves. Agile SDLC Models/Methods Feature-driven development (FDD): FDD approach is implemented by utilizing a series of techniques, like creating feature lists, conducting model evaluations, and implementing a design-by-feature method, to meet its goal. This methodology is particularly effective in ensuring that the end product is delivered on time and that it aligns with the requirements of the customer.
Scrum: Scrum methodology serves as a framework for tackling complex projects and ensuring their successful completion. It is led by a Scrum Master, who oversees the process, and a Product Owner, who establishes the priorities. The Development Team, accountable for delivering the software, is another key player. Extreme Programming (XP): Extreme Programming uses specific practices like pair programming, continuous integration, and test-driven development to achieve these goals. Extreme programming is ideal for projects that have high levels of uncertainty and require frequent changes, as it allows for quick adaptation to new requirements and feedback Lean Development: Lean Development is rooted in the principles of lean manufacturing and aims to streamline the process by identifying and removing unnecessary steps and activities. This is achieved through practices such as continuous improvement, visual management, and value stream mapping, which helps in identifying areas of improvement and implementing changes accordingly.
agile SDLC models The steps involve in agile SDLC models are: Requirement gathering Design the Requirements Construction / Iteration Testing / Quality Assurance Deployment Feedback
Requirement Gathering:- In this step, the development team must gather the requirements, by interaction with the customer. development team should plan the time and effort needed to build the project. Based on this information you can evaluate technical and economical feasibility. Design the Requirements:- In this step, the development team will use user-flow-diagram or high-level UML diagrams to show the working of the new features and show how they will apply to the existing software. Wireframing and designing user interfaces are done in this phase. Construction / Iteration:- In this step, development team members start working on their project, which aims to deploy a working product. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing, and System Testing. A brief introduction of these three tests is as follows: Unit Testing:- Unit testing is the process of checking small pieces of code to ensure that the individual parts of a program work properly on their own. Unit testing is used to test individual blocks (units) of code. Integration Testing:- Integration testing is used to identify and resolve any issues that may arise when different units of the software are combined. System Testing:- Goal is to ensure that the software meets the requirements of the users and that it works correctly in all possible scenarios. Deployment:- In this step, the development team will deploy the working project to end users. Feedback:- This is the last step of the Agile Model. In this, the team receives feedback about the product and works on correcting bugs based on feedback provided by the customer.
Q) Give importance of Agile software development Write a short note on Agile SDLC workflow Define agility. Why is it required? What are the phases of Agile Software development Life Cycle? Explain
Scrum is a process framework used to manage product development and other knowledge work. Scrum Practices Events 1) Sprint The Sprint is a timebox of one month or less during which the team produces a potentially shippable product Increment. Typical characteristics of Sprints: Maintain a consistent duration throughout a development effort A new Sprint immediately follows the conclusion of the previous Sprint The start date and end date of Sprint are fixed 2) Sprint Planning A team starts out a Sprint with a discussion to determine which items from the product backlog they will work on during the Sprint. The end result of Sprint Planning is the Sprint Backlog. Sprint planning is an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items.
3) Daily Scrum The Daily Scrum is a short (usually limited to 15 minutes) discussion where the team coordinates their activities for the following day. Each day at the same time, the team meets so as to bring everyone up to date on the information that is vital for coordination: each team member briefly describes any “completed” contributions and any obstacles that stand in their way. Usually, Scrum’s Three Questions are used to structure discussion. The meeting is normally held in front of the task board. This meeting is normally timeboxed to a maximum duration of 15 minutes, though this may need adjusting for larger teams. What did you do yesterday? What will you do today? Are there any impediments in your way? 4) Sprint Review At the end of the Sprint, the entire team (including the product owner) reviews the results of the sprint with stakeholders of the product.
Artifacts 1) Product Backlog The product backlog is an ordered list of all the possible changes that could be made to the product. 2) Sprint Backlog The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint Goal. 3) Definition of Done The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.
Roles The Product Owner The product owner is a role team responsible for managing the product backlog in order to achieve the desired outcome that the team seeks to accomplish. The Scrum Master The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use. The Development Team The development team consists of the people who deliver the product increment inside a Sprint. The main responsibility of the development team is to deliver the increment that delivers value to every Sprint.
The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limiting work in progress (WIP), Practices Kanban systems use mechanisms such as a kanban board to visualize work and the process it goes through Limit work in progress When you establish limits to the amount of work you have in progress in a system and use those limits to guide when to start new items, you can smooth out the flow of work and reduce lead times, improve quality, and deliver more frequently. Manage flow The flow of work in service should maximize value delivery, minimize lead times and be as predictable as possible. Implement feedback loops Feedback loops are an essential element in any system looking to provide evolutionary change.
Roles Service Request Manager Understands the needs and expectations of customers, and facilitates the selection and ordering of work items at the Replenishment Meeting. Service Delivery Manager Responsible for the flow of work to deliver select items to customers. Facilitates the Kanban Meeting and Delivery Planning.
Kanban
Extreme Programming Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team. Dynamically changing software requirements Practices Pair Programming Pair Programming means all production software is developed by two people sitting at the same machine. Pair programming consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so. Stories Describe what the product should do in terms meaningful to customers and users.
Weekly Cycle An iteration, in the context of an Agile project, is a timebox during which development takes place, the duration of which: may vary from project to project, usually between 1 and 4 weeks is in most cases fixed for the duration of a given project The Weekly Cycle is synonymous with an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories. The goal by the end of the week is to have running tested features that realize the selected stories. The intent behind the time-boxed delivery period is to produce something to show to the customer for feedback. Quarterly Cycle The Quarterly Cycle is synonymous with a release. Incremental Design The practice of Incremental Design suggests that you do a little bit of work upfront to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features.
Ten-Minute Build The goal of the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes. Continuous Integration Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. Test-First Programming – TDD - Instead of following the normal path of: develop code -> write tests -> run tests The practice of Test-First Programming follows the path of: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat Test-driven development write a “single” unit test describing an aspect of the program run the test, which should fail because the program lacks that feature write “just enough” code, the simplest possible, to make the test pass “refactor” the code until it conforms to the simplicity criteria repeat, “accumulating” unit tests over time
Lean Software Development (LSD) is an agile framework used to streamline and optimize the software development process. It may also be referred to as the Minimum Viable Product (MVP) strategy as these ways of thinking are very similar since both intend to speed up development by focusing on new deliverables. Lean Software Development (LSD) is an approach derived from lean manufacturing principles aimed at optimizing efficiency and minimizing waste in the software development process. Prevent Defects: It integrates quality assurance throughout the development process to prevent defects. Eliminate Waste: It focuses on activities that add value to the customer and eliminates those activities that do not add value. Fast Delivery: Reduces cycle time to deliver software quickly and respond to feedback and changing requirements rapidly. Delay Decisions: Delay decisions until they can be made based on facts.
Benefits of LSD Increased Efficiency: LSD reduces delays and inefficiencies by identifying and eliminating non-value-adding activities. Higher Quality: It integrates quality assurance throughout the development process, thus preventing defects and ensuring quality products. Faster Delivery: Shorter development cycles allow for quicker release of features and updates, thus meeting customer demands more rapidly. Adaptability: Delaying decisions until they are necessary and are based on facts, allowing teams to adapt to changes and new information. Enhanced Collaboration: Engages customers throughout the development process, ensuring that their needs and feedback are continuously addressed.
Limitations of LSD Here are some key limitations of LSD: Cultural Resistance: Implementing LSD requires a significant cultural shift and if there is resistance to change from team members and management then it can hinder its adoption and effectiveness. Learning Curve: There is a steep learning curve associated with understanding and applying lean principles and practices effectively. Requires Strong Leadership: Successful implementation of LSD requires strong and committed leadership to guide the transition. Difficulty in Measuring Waste: In LSD, determining waste is subjective and challenging. It requires a deep understanding of processes and value streams. Resource Intensive: Implementing LSD requires an initial investment in training, tools, and process redesign. This can be significant.
Q) Briefly explain about the Lean Software Development Life Cycle What are the Pros and Cons of Lean Software Development Life Cycle