Software Development Lifecycle (SDLC) SDLC Phases 1) Planning Stage 2) Requirement Gathering and Analysis 3) Design 4) Implementation or Coding 5) Testing 6) Deployment 7) Maintenance 1.Planning Stage The planning stage (also called the feasibility stage) is exactly what it sounds like: the phase in which developers will plan for the upcoming project. It helps to define the problem and scope of any existing systems, as well as determine the objectives for their new systems. By developing an effective outline for the upcoming development cycle, they'll theoretically catch problems before they affect development. And help to secure the funding and resources they need to make their plan happen. Perhaps most importantly, the planning stage sets the project schedule, which can be of key importance if development is for a commercial product that must be sent to market by a certain time. 2.Analysis Stage The analysis stage includes gathering all the specific details required for a new system as well as determining the first ideas for prototypes. Developers may: • Define any prototype system requirements • Evaluate alternatives to existing prototypes • Perform research and analysis to determine the needs of end-users Furthermore, developers will often create a software requirement specification or SRS document. This includes all the specifications for software, hardware, and network requirements for the system they plan to build. This will prevent them from overdrawing funding or resources when working at the same place as other development teams. 3.Design Stage The design stage is a necessary precursor to the main developer stage. Developers will first outline the details for the overall application, alongside specific aspects, such as its: • User interfaces • System interfaces • Network and network requirements • Databases They’ll typically turn the SRS document they created into a more logical structure that can later be implemented in a programming language. Operation, training, and maintenance plans will all be drawn up so that developers know what they need to do throughout every stage of the cycle moving forward. Once complete, development managers will prepare a design document to be referenced throughout the next phases of the SDLC. 4.Development Stage The development stage is the part where developers actually write code and build the application according to the earlier design documents and outlined specifications. Product program code is built per the design document specifications. In theory, all of the prior planning and outlined should make the actual development phase relatively straightforward. Developers will follow any coding guidelines as defined by the organization and utilize different tools such as compilers, debuggers, and interpreters. Programming languages can include staples such as Java, PHP, Pythin, React and more. Developers will choose the right programming code to use based on the project specifications and requirements. 5.Testing Satge Building software is not the end. Now it must be tested to make sure that there aren’t any bugs and that the end-user experience will not negatively be affected at any point. During the testing stage, developers will go over their software with a fine-tooth comb, noting any bugs or defects that need to be tracked, fixed, and later retested. It’s important that the software overall ends up meeting the quality standards that were previously defined in the SRS document. Depending on the skill of the developers, the complexity of the software, and the requirements for the end-user, testing can either be an extremely short phase or take a very long time. 6.Implementation and Integration Stage After testing, the overall design for the software will come together. Different modules or designs will be integrated into the primary source code through developer efforts, usually by leveraging training environments to detect further errors or defects. The information system will be integrated into its environment and eventually installed. After passing this stage, the software is theoretically ready for market and may be provided to any end-users. 7. Maintenance Stage The SDLC doesn’t end when software reaches the market. Developers must now move into a maintenance mode and begin practicing any activities required to handle issues reported by endusers. Furthermore, developers are responsible for implementing any changes that the software might need after deployment. This can include handling residual bugs that were not able to be patched before launch or resolving new issues that crop up due to user reports. Larger systems may require longer maintenance stages compared to smaller systems. Software Development Lifecycle (SDLC) Software Development Life Cycle Models 1) Waterfall Model 2) V-Shaped Model 3) Prototype Model 4) Spiral Model 5) Iterative Incremental Model 6) Big Bang Model 7) Agile Model 1.Waterfall Model The waterfall model is the oldest of all SDLC methodologies. It’s linear and straightforward and requires development teams to finish one phase of the project completely before moving on to the next. Each stage has a separate project plan and takes information from the previous stage to avoid similar issues (if encountered). However, it is vulnerable to early delays and can lead to big problems arising for development teams later down the road. 2. Iterative model In the iterative process, each development cycle produces an incomplete but deployable version of the software. The first iteration implements a small set of the software requirements, and each subsequent version adds more requirements. The last iteration contains the complete requirement set. 3. Spiral Model Spiral models are flexible compared to other methodologies. Projects pass through four main phases again and again in a metaphorically spiral motion. It’s advantageous for large projects since development teams can create very customized products and incorporate any received feedback relatively early in the life cycle. 4. V- Model The V-model (which is short for verification and validation) is quite similar to the waterfall model. A testing phase is incorporated into each development stage to catch potential bugs and defects. It’s incredibly disciplined and requires a rigorous timeline. But in theory, it illuminates the shortcomings of the main waterfall model by preventing larger bugs from spiraling out of control. 5. Agile The agile methodology produces ongoing release cycles, each featuring small, incremental changes from the previous release. At each iteration, the product is tested. The agile model helps teams identify and address small issues in projects before they evolve into more significant problems. Teams can also engage business stakeholders and get their feedback throughout the development process. 6.Lean The lean methodology for software development is inspired by lean manufacturing practices and principles. The lean principles encourage creating better flow in work processes and developing a continuous improvement culture. The seven lean principles are: • Eliminate waste • Amplify learning • Make decisions as late as possible • Deliver as fast as possible • Empower your team • Build integrity in • Build holistically Agile What is Agile? What is Agile Software Development? Agile is a Mindset What are Agile Methodologies? 12 Agile Manifesto principles: a culture, defined Manifesto for Agile Software Development What is Agile Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. Whereas the traditional "waterfall" approach has one discipline contribute to the project, then "throw it over the wall" to the next contributor, agile calls for collaborative cross-functional teams. Open communication, collaboration, adaptation, and trust amongst team members are at the heart of agile. Although the project lead or product owner typically prioritizes the work to be delivered, the team takes the lead on deciding how the work will get done, self-organizing around granular tasks and assignments. The original Agile Manifesto didn't prescribe two-week iterations or an ideal team size. It simply laid out a set of core values that put people first. The way you and your team live those values today – whether you do scrum by the book, or blend elements of kanban and XP – is entirely up to you. What is Agile Software Development? Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD). Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints. 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. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context. One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context. There’s a big focus in the Agile software development community on collaboration and the self-organizing team. Agile is a Mindset Ultimately, 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. You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering better ways of developing software by doing it and helping others do it.” When you face uncertainty, try something you think might work, get feedback, and adjust accordingly. Keep the values and principles in mind when you do this. Let your context guide which frameworks, practices, and techniques you use to collaborate with your team and deliver value to your customers. Agile Subway map Key Agile Concepts Below are a few key Agile concepts. 1.User Stories: In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.” Each user story is expected to yield a contribution to the value of the overall product, irrespective of the order of implementation; these and other assumptions as to the nature of user stories are captured by the INVEST formula. A good user story should be: “I” ndependent (of all others) “N” egotiable (not a specific contract for features) “V” aluable (or vertical) “E” stimable (to a good approximation) “S” mall (so as to fit within an iteration) “T” estable (in principle, even if there isn’t a test for it yet) 2.Daily Meeting: 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 members 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. The daily meeting is structured around some variant of the following three questions: 1. What have you completed since the last meeting? 2. What do you plan to complete by the next meeting? 3. What is getting in your way? This meeting is normally timeboxed to a maximum duration of 15 minutes, though this may need adjusting for larger teams. To keep the meeting short, any topic that starts a discussion is cut short, added to a “parking lot” list, and discussed in greater depth after the meeting, between the people affected by the issue. 3. Personas: When the project calls for it – for instance when user experience is a major factor in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called “personas.” 4. Team: A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. A small minority of team members may be part-time contributors, or may have competing responsibilities. The notion of team entails shared accountability: good or bad, the outcomes should be attributed to the entire team rather than to any individual. The team is expected to possess all of the necessary competencies, whether technical (programming, designing, testing) or business (domain knowledge, decision making ability). Roles and responsibilities do not matter as much as results: a developer may test, perform analysis or think about requirements; an analyst or domain expert can suggest ideas about implementation, and so on. 5. Incremental Development: Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality. These are called “vertical” increments (that is, difference between successive product versions), as opposed to the opposite strategy which successively delivers complete technical components: for instance, creating a database schema, then building business rules on top of that, and only then implementing a UI. 6. Iterative Development: Agile projects are iterative insofar as they intentionally allow for “repeating” software development activities, and for potentially “revisiting” the same work products(the phrase “planned rework” is sometimes used; refactoring is a good example). 7. Milestone Retrospective: Once a project has been underway for some time, or at the end of the project, all of the team’s permanent members (not just the developers) invests from one to three days in a detailed analysis of the project’s significant events. Even more than an iteration retrospective, this should be a facilitated meeting, adhering to a structured format that varies according to objectives but will be specified in advance. The Agile Manifesto The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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 12 Principles 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 4 Business people and developers must work together daily throughout the project 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7 Working software is the primary measure of progress. 10 Simplicity–the art of maximizing the amount of work not done–is essential. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 11 The best architectures, requirements, and designs emerge from selforganizing teams. 9 Continuous attention to technical excellence and good design enhances agility. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Scrum Scrum Overview Sprints Sprint Planning Ceremonies Backlogs Backlog Refinement Standups Retrospective Roles Overview Of Scrum Scrum is an empirical process, where decisions are based on observation, experience and experimentation. Scrum has three pillars: transparency, inspection and adaptation. This supports the concept of working iteratively. Think of Empiricism as working through small experiments, learning from that work and adapting both what you are doing and how you are doing it as needed. The Scrum Values of Courage, Focus, Commitment, Respect, and Openness, are all important elements that Scrum Team members must consider when working together. The Scrum Values are particularly important in environments where experimentation is core to making progress. SCRUM Values In a nutshell, Scrum requires an environment where: • Increments of valuable work are delivered in short cycles of one month or less, which are called Sprints. Ongoing feedback occurs during the Sprint, allowing for inspection and adaptation of the process and what will be delivered. • The Scrum Team has a Scrum Master, a Product Owner and Developers, who are accountable for turning the selection of the work into an Increment of value during a Sprint. • The Scrum Team and other members of their organization, business, users or customer-base known as stakeholders, inspect the results of the Sprint and adjust for the next one. Scrum Accountabilities The people on the Scrum Team Scrum Master - the person on the Scrum Team who uses their knowledge of Scrum to help the team and organization to be as effective as they can be; they do so by taking approaches like coaching, teaching, facilitating and mentoring Product Owner - the person on the Scrum Team who makes sure that the team is creating the most valuable product they can create Developers - the people on the Scrum Team who work together to create the product Scrum Events Events that create regularity and minimize other meetings Sprint - short cycles of one month or less, during which the work is done; the Sprint contains all of the other Scrum events; a new Sprint starts immediately after the conclusion of the previous Sprint Sprint Planning - event dedicated to planning out the work that will take place during the Sprint Daily Scrum - event held every day where the Developers inspect the progress toward the Sprint Goal, uncover anything that may be getting in their way and adapt accordingly Sprint Review - event held at the end of the Sprint where the Scrum Team and key stakeholders review what was accomplished in the Sprint and what has changed in their environment; next, attendees collaborate on what to do next Sprint Retrospective - the Scrum Team gets together during this event to talk about how the last Sprint went and identify the most helpful changes to improve their effectiveness Scrum Artifacts The plans and work which are transparent and can be inspected allowing for future adaptation; Each artifact has its own Commitment which helps the team understand if they are making progress Product Backlog - an evolving, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team Commitment: Product Goal - the target the team plans against Sprint Backlog - a highly visible list of work that is the Developer’s plan for the Sprint, which may evolve as they learn Commitment: Sprint Goal - the single objective of the Sprint Increments - small pieces of work that serve as concrete stepping stones toward the Product Goal. You can deliver as often as needed during the Sprint and are not limited to only one release per Sprint. Commitment: Definition of Done - the description of what it takes for an Increment to be considered complete Prioritization Techniques What is prioritizing? Prioritizing means dealing with tasks, items, or work based on their importance. In order to successfully prioritize, it’s essential to list or rate tasks in order of importance. The more important a task is (whether this is due to deadline or impact), the higher of a priority it becomes. Why is prioritizing important? Task prioritization is important for 3 reasons: 1. Creates transparency into everything that needs to be done. 2. Determines the speed at which tasks need to be completed. 3. Ensures that you have enough time to complete every task for which you are responsible. Prioritizing tasks can also help maintain a healthy work-life balance, in addition to improving productivity and time management skills Priority levels for tasks Priority levels for tasks Critical Anything classified critical is considered urgent. Critical tasks are usually time-sensitive, and teams are expected to stop what they’re doing and attend to the immediate task at hand. If not, critical tasks can create risk and cost the business. Qualities of critical tasks: Ad hoc and time-sensitive Poses a risk if not handled immediately The deadline can be either ASAP, same-day, or next-day turnaround High priority These tasks are very important and must be completed ASAP. Because these tasks are not timesensitive, this type of task comes second on the priority scale after critical tasks. Qualities of high-priority tasks: Important but not time-sensitive Can be handled after any critical tasks Deadline can be within a couple of days or end of the week Neutral Neutral tasks are important, but they can usually wait to be done. Neutral tasks fall third to critical or highpriority issues. Qualities of neutral tasks: No immediate deadline, but should still be completed Fall third to critical and high-priority tasks Deadlines are outlined Low priority These tasks are usually items that can wait to be done. This type of task is great for filling up any free time. An example of low-priority tasks is those that your team can address when all other priorities are finished. Qualities of low-priority tasks: Completed when teams have time Floating deadlines move up or down depending on additional work Unknown These are tasks that pop up and are relegated to the backlog. Teams don’t usually have a deadline for these types of tasks but understand that they will be done eventually. Once teams have time, they will determine how to prioritize the task. Qualities of low-priority tasks: Backlog tasks with no estimated or outlined deadline Prioritization is determined when more information is available Kano Model Kano Model The Kano agile product development prioritization model takes into consideration actionable product feedback from users in development. That information is then used to assess which features should be prioritized in product development. When using the Kano Model, you have to determine the impact of each feature. Must-be: The customers consider the product functional only if these features are included. One-dimensional: These features have a dual nature. While they aren’t a must for a product to work, they remain extremely desirable to customers. The category is closely related to foreseeing customer needs and expectation. When a product includes what customers would be happy to get, they stay satisfied. But if you fail to deliver them, users are more likely to experience disappointment. Attractive: Features in this section add extra satisfaction, or even enjoyment and gratification. Basically, they are unexpected but nice-tohave features. On the other hand, their absence doesn’t leave customers dissatisfied. Indifferent: The attributes here represent the least possible impact on customers satisfaction. In a nutshell, they have no value. Reverse: The features falling into this category are considered to be the most annoying. Their presence has a rather negative effect on customer satisfaction. Alternatively, when they are not introduced, customers consider it a plus. Pros of the Kano model Highlighting the potential strengths and weaknesses of a product. One of the most valuable features of the Kano model is user feedback. The results of the Kano questionnaire help realize the future product’s advantages and disadvantages. It allows product managers to specify the product/market fit early in development. Ranking product features by their value for customers. The Kano model helps rate the product properties from the value proposition standpoint and tailor it to user needs. Cons of the Kano model Provides no details on resources required. Although the Kano model gives a more comprehensive picture on how to establish the priorities from the customer vantage point, it doesn’t account for time and costs that are necessary for a given release or a particular feature. Time-consuming practice. Since the Kano model originally involves the Kano survey – which may target a lot of potential customers – the efforts to process and estimate the results might be quite significant. It slows down the time-to-market and, consequently, distracts the team from execution. When assessing what to prioritize using the Kano Model, you use an X and Y-axis to determine the significance of each feature. As a result, you get a visual representation of what needs to be prioritized. It can also be more visually aesthetic for presentations. It is one of the simplest prioritization models that can help bring in team cooperation as everyone knows what they have to prioritize. Stack Ranking Stack Ranking Stack Ranking is one of the most popular forms of prioritization techniques that is currently used by a lot of software companies. It is also one of the easiest techniques that allow prioritization based on the user story. The technique considers each user story and then places it in an order of priority, ranking each task from the most important placed on the top of the tack to the least important placed on the bottom. This gives the company a setlist of priorities focusing on the most important feature to the least. MoSCoW Model MoSCoW Model Mo stands for Must be, which are features that the product cannot do without and must be included. S stands for Should have, which are features that should be included but are not that critical. C stands for Could have, which are features that just improve the experience but are not critical to the operation and functionality of the product. W stands for Won’t have, which are features the stakeholders have ruled against and won’t be part of the product. By prioritizing features using the work MoSCoW, you can prioritize the most important aspects first, which is the main objective of prioritization in agile product development. Essentially, products that are under M and S should be your priorities whereas, C is not that much of a priority. W is a canceled or a delayed feature to a later version, not the one you’re working on. Pros of MoSCoW prioritization Given such operational friendliness, the benefits of MoSCoW prioritization are quite obvious. Simplicity. The MoSCoW method doesn’t require deep understanding or complicated calculations. So, it’s easy for a team to keep in line with the whole prioritization process using a simple language. This promotes mutual understanding between team and stakeholders. Scheduling with MoSCoW is fast and transparent. Agility for scheduling and implementation. Since this prioritization method has no strict time limits, except for the Must-have category, it allows for changing suitable timeframes per feature. That way, a team can adjust feature deliveries or releases on favorable terms. Cons of the MoSCoW approach With such simplicity come some challenges. Lacks a clear consistency of implementation. Though the priorities may be easily set, the MoSCoW method does not introduce any sequencing of tasks and lacks planning. At the end of the day, it might put the entire release at risk. Lack of big picture focus. With MoSCoW suggesting the most-to-least critical requirements or features, the stakeholders still might not see a full picture of priorities. If the focus must be concentrated on key features that are important for a business, MoSCoW may mislead the team. So, the stakeholders have to allocate business goals by themselves. Creates imbalance between the required and slightly desirable. Often, the blurred lines between categories make it hard to decide on features that go into, say, Must and Should lists. That’s why floating tasks between all categories should be approached with great thought and care.
