 Hello everyone. Welcome to another live session. Today's session is about SPLC. I am Archana Rana and I have a colleague Ashwin here who is going to help with the session. So let's start with the agenda for today. Sorry for the delay. So this session is based on a professional experience and it does not necessarily reflect the views of the organization we work with. Let's quickly move on to the agenda. So we've already had a recorded session on STLC. So we'll quickly go through the overview and methodologies of STLC. We'll then go on to have a closer look at Agile and Scrum. And then we will also tie it back to the matching engine which we are going to cover in the next session, next live session. So starting with the definition of STLC, STLC stands for Software Development Life Cycle and it is a conceptual model that describes the stages involved in an information system development project. As the name suggests, it is a life cycle for software development. So it has various stages involved, well-defined stages. Let us go through the stages now. This is at a high level, this is a basic model of STLC. There may be variations to this, but this kind of covers most of the stages involved in STLC. STLC gives a structure to the development of software. It starts with planning. This is where we define the scope of the project. We also do a feasibility study in this phase. Once that is done, we move on to the requirements analysis phase. This is the phase where we work very closely with the customer and we identify all the requirements for the project. The end state of this is a requirements specification document. Once that is done, once all the requirements have been gathered, we move on to the design stage. This is where we identify what components are required in the system. We also break it down into smaller components. We try to design each and every component. We also design the interaction among various components. We also emphasize on the how and not what. We then move on to the implementation phase. This is where the coding is done. A design document from the previous phase is basically an input to this phase. This is where the actual coding happens, the test development. Basically, the application developers make sure that the code is written and tested well. We then move on to the testing phase. This is where the testers get involved and they try to validate the system against the initial set of requirements. The edge case is also covered in this phase. A test plan is basically what is referred to during this phase. Once the code is tested and validated by the testing team, it is ready to be packaged and released into production. That is where the release phase comes into the picture. This is where the code is actually deployed into production and it is live. We then move on to the maintenance phase, which is BAU. Any enhancements to the system, continuous enhancements to the system while it is live are done in this phase. That is basically at a high level the phases of STLC. STLC has evolved over time. There have been various different methodologies that have been found and used across the years, starting from the early 1970s. The earliest being the waterfall methodology, moving on to the V model, then the spiral model, then we move on to the rad, and so on and so forth. A lot of them are rational. The latest being the agile. Agile is very popular nowadays. It is incremental, user driven, it is light, it is flexible, iterative, all of that. We will cover agile in more detail later in this session. But before we go there, we will look at what waterfall is all about. If you look at the waterfall model, you see that the phases are sequential. It starts at the requirements phase, goes on to the design, implementation, testing and release. There is no flexibility in this that you cannot go back to the previous phase once one phase is done. You always move to the next phase. Also, if you look at the time between the requirements phase and the release phase, it is generally a lot. In some projects it could run into years. Therefore, waterfall did not really suit to the ever changing requirements of business. We went on to modify waterfall to suit and ever changing business requirements and this SDLC kept evolving to use different methodologies. Let us see what were the challenges with waterfall. If you see, you do not realize the value till the end of the project. If you look at the time when the project is actually ready to be delivered and used, it is already 12 months in this case, in this PPT. It could be more. The other thing is the implementation. The implementation takes too long, simply because all the requirements are taken up ahead and the implementation is done at one go. It just stretches too long. You also see that the testing is left till the end, very end. You keep building, you keep building and then towards the end you test. When you find out issues, then it is very difficult to incorporate because your software is now built to a great extent. Customers may need to change requirements and that is not... If you look at this, we do not want to go back to the requirements space, which means that the customer, if it all he needs, he sees a change in the requirements during the life cycle of software development. There is no flexibility to incorporate changing requirements in the middle of the waterfall model. You also do not seek approval from the stakeholders until late in the day, which means that the stakeholders only come to the frag end and they are not able to realize the value of the product anytime in the interim, which again may not meet all the requirements that were set up at the beginning of the project. Just to add to this, if you connect back to your own real world example of your own academic projects which you do, you may have a project guide who is assisting you with a problem statement and then you are trying to deliver something as part of your academic. If you are following through as a waterfall, you would be spending a lot of time in terms of defining that problem statement, designing it. Then as you start the implementation, you will start to realize that what you started to build, that definition of the scope of work has really started to change. At the end of the day, when you are nearing your academic project completion, you may not have really tested your software very well enough. You should be able to relate it very easily because this is something which connects back to my own academic career or the academic part. This is exactly what I went through when I did my project. Moving ahead, Archana would talk us through the software failures. Even though we have done a lot of planning, we do a lot of planning. There is a lot of structure to the way we develop software. It has been realized over time that the number of failures have been more, unfortunately, than the number of successes. If you look at this software failure example, some of them, the major ones in the last couple of years, are here. They have resulted in a loss of money in terms of millions of dollars. Now, these have been attributed most of them to the waterfall methodology that has been used to develop the software that these companies were using. These failures have been seen across the globe, small companies, big companies, across different industries. They are not limited to a particular industry. Therefore, we need to understand what can be done better in terms of software development that these can be avoided. Let us understand why software fails. This is one of the very common reasons why software fails from all the analysis that has been done on all the software failures that have happened in the past. The first one is incomplete or badly defined system requirements. It is very obvious that if you don't have the system requirements, the system that you are building will definitely not meet the requirements. Inaccurate estimates, simply because it is an offshoot of what is there in the first point. If you don't have the complete system requirements, you will not be able to estimate the project correctly. Lack of user involvement, again, like we saw in the waterfall, the customer involvement ends at the requirements phase and the customer is not involved throughout the lifecycle of the software development. Therefore, that also attributes to software failure because by the time you deliver the software, the customer requirements would have probably changed. Changing business requirements, again, in a dynamic world, business requirements are changing continuously and to be able to adapt to those requirements. We need a more flexible software development methodology rather than sticking to a sequential one where business requirements, there is no scope for accommodating ever-changing business requirements. Late system integration, again, if you look at the bigger software projects, those were built in silos, like different components were built separately and by the time it was time to integrate them, it was very late in the software development lifecycle and that's when sometimes it was realized that they don't talk to each other. Late system integration was another factor that attributed to software failure majorly. Bad coding practices is the last one. Obviously, when you don't write the code well, you cannot scale it. It's not scalable, it's not maintainable and that also makes the software redundant after a while. So let me take this on agile model. So we talked about the history of development methodologies. We started with waterfall. We talked about in 1970 is when waterfall was formulated. But prior to that as well, software development was happening. But there wasn't a standard which was laid out. But 1970 is when waterfall standard was laid out. After that, people continued to evolve and improve with that process. And then what we see in 1990 is when like 17 set of developers who were working towards improving software development methodologies in their own areas came together and formed or coined a word called as agile. But it's nothing. It's agile in itself if you look at. It's not really a process. It's more of a philosophy or a set of values. Now, some of these is what we have mentioned here. Like it revolves around like self-organizing teams. It's incremental delivery of software product with iterative manner, working software where the focus is more on delivering working software then more on documenting things and then making progress towards those documentation and then converting them into the software. But it's more about build that software, produce it to the customer, get a buy-in early enough rather than on the signing off on documentation with software requirements, specifications or BRDs etc. The focus is also more on people like building teams with motivated people who are willing to be cross-functional go beyond their space and be able to leverage their current skill sets and also skill sets of other individuals and contribute towards the product delivery. Collaborative, like work collaboratively with the customers rather than bringing in the customer at the very end. Adaptable, like as change in requirements come through, agile talks about like how can we have a mechanism such that we are adaptable to those changes. So those are certain values which coin around on agile. Now, there are various models of frameworks that are part of the agile and the generic model if you look at, we are looking at requirements as part of the overall SDLC lifecycle but these requirements as we talked about as challenge in waterfall, they are dynamic in nature. So we are saying we would continue to have dynamic requirements in a real world but we continue to deliver them in an iterative manner such that we do the plan, design, build, test, review all of that in a single iteration and then produce incremental product but in an iterative fashion such that we can go back and revisit what we have delivered if there is a need to enhance the functionality if a change comes in, how do we factor that change in which is what this generic model is allowing us to facilitate such kind of changes and the dynamism within the real world and such that once we go through this iteration incremental at some point in time we would have something called as an incremental shipable product which could then be reduced to the customers which is what is the generic agile model. Now, from this we will understand the agile manifesto and again I will hand it back to Archana to talk about the agile manifesto. Thank you. So agile is based on a manifesto and there are 12 principles behind this manifesto. So the manifesto says that if you look at the attributes on the right-hand side agile says we do value that but we value the thing on the left more. So value process and tools we value individuals and interactions more which means that individuals are important within a team like Archana mentioned they have to be talking to each other all the time including the stakeholders, the customers the testers, the developers they should be cross-functional teams everybody should be able to do everything else everything within the project so interactions are very important also customer collaboration is very important we need to continue to involve the customer in the project we have to showcase a working software early in the cycle so that he can give us feedback as to what needs to be enhanced and what needs to be added to the product that has been shipped to him and that way we give him some incremental value over time and we also so working software is a primary progress is a primary determination of progress in a software development life cycle from an agile perspective so we want to show working software incrementally using agile responding to change of following a plan so agile says that we welcome changing requirements even late in the cycle we do not follow a set plan that if this is what we were set to do and if there are some changing requirements coming later in the cycle we will not adapt to them or we will not take them so just wanting to change is also another manifesto for agile yeah so like while the items on the right side do have value but agile signifies items on the left to be more significant than items on the right which does not mean that we do not want to do the items on the right we definitely want to do them but the focus is more on the items which are on the left now moving ahead so these are the various frameworks which come under the agile umbrella so as I said agile in itself is not really a process but it is more of a philosophy and values but these are the things which are the real models and which fall under the agile umbrella of which Scrum is the most popular framework in the industry and there are typically an organization doesn't necessarily follow just one framework it is practices which are spanning across these frameworks is what like the organizations pick it up and then it could be a hybrid model or it could be a combination of some of these frameworks is what the organizations go through on Scrum we would go a little bit in depth in the follow-up session but just to touch upon one or two frameworks here XP is extreme programming and it focuses on pair programming code reviews, unit test coding automation of those unit test is something what XP signifies is on feature driven development which is FDD is a mechanism where the team focuses on feature based deliveries like if you think about an online shopping portal the features could be like having an ability to view the inventory having an ability to add items to an inventory or to a shopping cart having an ability to carry out with the payments process so these are some of the features and then the team may focus on delivering specific features then the entire application of portal altogether so that is on feature driven development can ban is another which is like focuses on lean principles and it helps us to visualize the bucket of work in one specific process area and then from there like who all are the impacting users who do need to contribute towards delivering that software so that kind of visualization is what can ban gives us along with adopting the lean principles so moving ahead this is a very high-level perspective in terms of the project success rate so this is from a 2013 survey which was done by Abisoft and if you look at what this is helping us to project here is that if you look at the failure rates which are happening with waterfall like we are looking at like 18% failure rate along with 33% projects which are challenged for the other side with agile there is a good amount of success ratio as compared to waterfall which is like 64% projects are in a success rate and then 8% failure so all the more the significance is on agile that if we go through with agile delivery this project may be successful but it doesn't necessitate that it would never fail so Archana earlier talked about some of the reasons by software fields so whatever methodology you choose you could still end up with a failed project I do not address some of the issues which were called out earlier but the probability of that project succeeding is more with agile is what is the survey helping us to understand now it also doesn't mean that with more successful project all projects would fit under the agile umbrella there could be certain projects which would still make sense to go through with a waterfall methodology and so what are those so some of those points is what we have tried to highlight we are working with organizations which are like disparate organizations we don't have a fine control over it we may still want to go with a waterfall methodology if we are running with a limited budget a limited time fixed scope we may still want to go with waterfall with let's say the client or customer is not willing to engage with yourself as a product team you may still want to go with waterfall because then you are trying to scope it out and then make sure that whenever the client is available you can take the product back to the client so those are certain areas where waterfall may still make sense with agile obviously like if you are looking at a project which is completely owned and delivered by a specific organization it will be much more sensible to go with agile if you are looking at large projects which you do not have a very clear definitive goal or they are complex in nature agile would be very sensible to go with and if the customers themselves do not have very clear clarity in terms of their end goal agile would help because you are going with a iterative incremental product which you then take feedback at regular intervals with the customer and to shape up the way the product you want to develop so with that now what we would like to do is open up to questions here before we get into the next sessions of this model right so we are open for questions actually sir good afternoon ma'am you are not audible cannot hear you good afternoon sir good afternoon ma'am am I audible? yes it can be a bit louder please thank you my question is how do we find the complexity of a model in SDLC how do we find the complexity in each model so when you say complexity is it across let's say waterfall and agile etc or complexity within a project itself like let's say if you are building an example which I called out of a shopping online portal so are you saying how do we understand the complexity of building that product or complexity across various models across the models I am asking yeah so we don't necessarily find the complexity across the SDLC methodology so each model has their pros and cons so as we called out in waterfall also there are certain types of projects which would make sense to go with waterfall certain types which would make sense to go with agile but the complexity necessarily we try to understand basis the type of the complexity involved with the project which you are trying to build so let's say it's a attendance tracking system for your own college or let's say you are building this shopping portal or let's say you are building an exchange which we had called out in the earlier live session where we are looking at a market exchange and a matching engine to be build out so basis the type of the project which you are trying to build we try to understand the complexity involved with that product and then try to understand the various constraints in terms of who is trying to build it do you have a fixed scope fixed budget and basis that we take a decision in terms of what type of methodology would make sense does that help your question yes sir thank you actually what are the good coding practices one is obviously you should follow the language that you are coding in you should follow all the coding practices which are you know you have that coding language the other thing is you should try to do test driven development which means that your code must be covered you should try to write as many tests to cover your code all the code that you have written that is the other thing that you could do the third thing is that you should try to keep it as simple as possible don't make it very complex for somebody else who is reading your code to understand so to add to that there are tools available which help you to understand how maintainable is your code what type of violations do you have so there are tools like sonar which help you understand they will scan through your code base and would come out with certain metrics so there is something called as a cyclomatic complexity metrics which would tell you how complex is your code so like if you have more branching cells looping etc so the more branching which you have more control flows you are adding within your code and it increases the complexity so the general point is like decrease that complexity decouple it be as modular as possible try to build like single responsibility components as much as possible in terms of general coding practices there are tools available which would tell you that are you adhering to that programming languages aspects or not but the other piece which I talked about complexity modularity is those things which you need to consider on top of what Arjuna talked about on the test driven development having unit test for all the method which you are writing all the code which you are writing integration code from across your various layers right then at an end to end regression suit for your test strategy etc so those are certain things which you should consider another thing that you should think about production handling mechanism right that should be also full proof you should make sure that that is good the other thing is logging your logging is also very important because once your code is live unless you don't have good logging mechanism in place it's very likely that you know you will not be able to troubleshoot any issues what things are taken into consideration when deployment of a particular model deployment of a particular model what do you mean what do you mean yeah so on deployment right so again the way industry is functioning right and I'm talking and I'm trying to relate more from the way industry functions right so what we earlier talked about in terms of unit test integration etc so that is something which falls under something called as continuous integration right then the next piece to that is continuous delivery right wherein once you are done with your unit test integration test end-to-end test right and you have a good percentage of automation done to make sure that you whatever code base you are building adheres to the condition of satisfaction or to your acceptance criteria of your requirements you are able to do it in an automated fashion you could very well do it manually but that will take a lot of time but the way industry is moving towards is having an automated capability to validate your requirements with the acceptance criteria so once you have met with your acceptance criteria you are good to go ahead and move that into production as long as your customer is good with that right so you need to go back and get a feedback from the customer before you put that into production which is what we call in the industry is as a user acceptance test right now this is something which you could do it manually and in an automated fashion but where the industry is moving is in an automated fashion once that success criteria is met you can put your code base into production right but the way we are doing this is something called as continuous delivery where in an automated mechanism you have an ability to take your code base from your code base repository run through with all your tests and then get that deployed into a higher environment right the next model to that which we are moving towards like not the entire industry has moved is something called as continuous deployment which is there is a concept of blue-green deployment where you have something already in production right so let's say think of Amazon right you won't see Amazon going down right in most cases right and let's say they are trying to build certain features push it out right the way they may function is such that they have a version which is available which the user is accessing they build a feature now they have done with their continuous integration continuous delivery now as part of continuous deployment they take all the way into production deploy that but maybe open it up to certain set of beta users test it out in production and then open it up to the rest of the world which is the continuous deployment model so I think some of these aspects is what you need to consider into account in terms of how do you want to design your deployment model okay good afternoon sir sir my question is that what is the basis of the requirement gathering and how and what is the process of requirement gathering on what basis we are gathering the requirements from the user so we start with identifying the scope of the problem with the user we first talk understand what is the scope of the problem then we have a series of interactions with the user to understand what the requirement is we can break down the requirement into use cases right we can break down the requirement to use cases use cases is nothing but but you know putting the requirements as in smaller pieces breaking it down into smaller pieces and documenting that that could be one way of gathering the requirements in the agile world getting requirements could be in the form of user stories and creating a backlog using those user stories that Ashwin is going to cover in some time but at a high level it is more about collaborating with the customer trying to talk through the requirements documenting them down putting them down into paper either in terms of use cases or in terms of user stories in the agile world and basically trying to ask as many questions as you can everything that the user generally the customers are not able to tell everything up front so you will have to ask questions they themselves don't know what they have to tell you so you have to think about the system in every aspect and ask them the right questions the more you talk the more you ask questions the more you think through the scope and ask the right questions the more clear the requirements will be just to add to that again the relating back to the industry aspects right so there is something called as specification by example so whatever Ashwin had talked right you could devise a mechanism in a document you are trying to capture it but in terms of specification by example we are going to cover a basic scenario at the later part of this session to help you understand how you could capture those requirements which are in a very clear English manner with the customer, the developers right and whoever are the stakeholders they are able to easily understand those requirements and then you could take that even to run through with your automation test scenarios for acceptance criteria so we will touch upon that at a later point in the session so I am a Kashi Shugarna and my question is what is done in testing phase of SDLP so in testing what is done is that the software is now ready to be tested right so it has basically been built what we do is we take the additional set of requirements we try to validate the system against the acceptance criteria which was laid out at the beginning of that cycle of the project we also try to cover all the test cases right so the testing team typically will create a test plan and it will try to create test cases end to end test cases based on the initial acceptance criteria that was given by the business or the end users or the customer and they will try to validate the system based on that acceptance criteria they will write test plans, exhaustive test plans to run the system against those test plans they will also try to do white box testing black box testing they will try to get all the edge cases covered in that testing phase so essentially they will try to validate the system against the set of requirements that were set at the beginning okay AKS do you have any other question hello sir which model is the best to design cannot hear you could you please repeat and be a bit clear and loud the which software is best to design a software and why it is did not catch you but are you saying which software is used for designing to a software model and why it is not following are you can someone else repeat please the question sir the question is which model is best to design a software and why there is no best model as Ashwin had said earlier right it depends on your requirement if your scope is fixed it's defined it's well known it's time boxed then you may want to follow waterfall whereas if you are in a business complex business with ever changing requirements large project you may want to go the agile way so there is no one answer for any requirement for every requirement okay which next college knowledge institute Tamil Nadu do you have any questions we cannot hear you if you are asking any questions could you please come in front of the camera knowledge institute yeah question in agile software in agile software you mention that the accuracy would be about 64 to 68% when can we obtain them from percentage and how to obtain them you are saying you want those statistics the industry wide statistics is that the question yeah so it is published on ambisoft link right these are statistics which we have not ourselves gathered so there are some firms who go through with these kind of surveys right chaos is another one ambisoft is one so you could very well google up for ambisoft and chaos and you should be able to get those statistics for yourself they are all up they are available in the internet okay all right what next question do you have the major difference between agile and waterfall so see with the major difference right with waterfall is waterfall is very linear and sequential agile is not at all linear it is more of incremental and iterative development so we looked at those models right where we called out it goes into very waterfall manner with the waterfall itself that's why the name is coined as well as waterfall so you can't revisit the stage back in waterfall typically but with the agile you could very well go back and revisit the stage because you are trying to go through with an iterative cycle and then you are trying to come out with the product which is in an incremental fashion so that's the major difference so like for example you are in the middle of your development and the customer comes back and says that the initial requirement that I have given you is not not correct I want to change that requirement in agile you have the flexibility to incorporate that in your development cycle whereas in waterfall you will not be able to do that you just get the requirements at the beginning and you work on those requirements till the end of the project you don't really do any changes during the life cycle which is possible in the agile okay so next question please okay should we move ahead to the next college now okay Bansal institute luck now we cannot hear you we check your mic we can't hear you please check your mic please get your mic checked ask your technical person to check the mic IES college IES college Bhopal please go ahead with your question yes good afternoon sir my name is Swapnil Reddy I am from IES college of technology Bhopal yes what is your question Swapnil again your voice is low please be clear yes please ask your question Swapnil a platform software as a service real life platform on software as a service so your question is on what platform software as a service real life platform on software as a service okay so this is a cloud related question I assume when you are talking of software as a service right but the example is if you look at office 360 so you could have mobile word etc all available on the internet right you are not having it on your own local machines you can make use of those features online so that is a software as a service right there are other types of applications let's say which are more industry where let's say you are looking at a sales executive who is trying to reach out to the customers right and there is something called a sales force so which is also like on the internet the firms are going ahead and accessing those capabilities they are not hosting their own servers or writing their own code base to have those capabilities available someone is offering that application online and the consumer is going ahead and making use of those services is where the software as a service fits in so those are like couple of examples which I just called out okay so what are what next questions do you have yes there is another question can you explain about waterfall model so we did that in fact in the first session do you have any specific question for waterfall if you just want to understand those phases then I would just quickly go through those phases right so where waterfall again is linear sequential right you go through the requirements phase first after that once you are done with the requirements you come out with the software specification you sign off the requirements you go into the design phase then you come out with the build document which is also signed off right when I say sign off meaning you have agreed right as a build team along with your customers and the stakeholders that this is what you are going to build out so you will come out with the high level design document with the low level design documents right as part of the design after that you will go into your implementation phase where you will start to actually start to test out your software so and then once you are done with the testing your meta acceptance criteria then you go into your release stage and the maintain stage so that is what is waterfall very sequential right each stage takes its own sweet time you can't revisit back those stages with waterfall so you need to think through early enough in the cycle of all the requirements all the design aspects before you get into the implementation okay so we are moving ahead this is IIS University Jaipur Namaskar sir, Namaskar maam my question to you is how one should decide which model of SDLC is to be followed by us while developing some application so again you go back and look at the fitment of what we have explained right but in general if you are asking me if you are trying to build something for your own academics right I would strongly recommend making use of agile right this is from my own industry experience and also from my academics experience as I had called out earlier on right so we were trying to build a project in our academics right we took like 6 months at the end of the day when we were trying to submit it it wasn't what we started out at the complete scope had changed right we narrowed down the scope we cut down the testing cycle and then we just went ahead and submitted to a project guide right with agile we could have done it very differently we could have involved a project guide like in at a weekly cycle or a bi-weekly cycle produce something which is like end-to-end right and then present it to whoever is your stakeholder so in your academics it will be a project guide your teachers etc. professors but in a real world it will be the customer to whom you are bringing in at the end of each iteration present it get the feedback right and understand the course so which is what in the second section I am going to cover with agile scrum what is that model work so I will not elaborate a lot but that is what I would recommend for you ok any other questions any other questions are there any limitations of agile methodology yeah so the limitation is on time and money right you need to have the time at your hand to be in an iterative manner right you haven't thought through of your requirements or scope scoped out everything way ahead so you are the thought process is that you are trying to build in a dynamic world understand the change in requirement as you build something you want to gather feedback and incorporate that feedback back into the software so those are the things like let's say you could could be constrained with the money you could be constrained with the timing itself you may not have that time to say that you want to go through with iterations but you say that maybe I just have like a month's time and this is my fixed scope right and this is what I want to achieve at the end of the month then maybe waterfall is what would make sense not agile really but agile is where you are trying to build the product in the right manner which would give you the maximum return on investment right and which is where you look at going with an agile methodology okay any other question Shree Dutta institute Hyderabad not audible we cannot hear you we still cannot hear you we would need to come back to you right so please be okay go ahead please no it's not it's very unclear no I might as no it's very unclear and we can't hear you so what we'll do is we'll carry on with the session right we'll pause for the question and then we'll open up a question in a short while as well so we'll we are going back to the presentation not this one so now what we are going to cover is on agile and scrum we'll try to go through right with one of the frameworks which is most popular in the industry with agile which is scrum right so what is scrum right so let's try to understand so with scrum and with agile right we are looking at an iterative an incremental delivery model where let's say we are going through a requirements phase but let's say as you have started to prioritize certain requirements which are of significant value to the customer you may be good to pick up those requirements start to add them in a iteration now the iteration itself is something which is a time box event where you are looking at a weekly cycle or a bi-weekly or at the max four weeks which is a month's duration of an iteration where the team gets together now the team itself in a scrum model is very cross functional motivated team right and very focused on the prioritize item they themselves choose what items they are willing to pick it up from the prioritize list of requirements which is also called as the backlog product backlog they pick it up add it into a sprint focus on delivering that and get that reviewed so we are looking at an iteration of planned build test review in an iteration at the end of the iteration they come out with something called as potentially shipable product right and then which is something which they agree with the customer whether they want to release it at that point in time or do they want to continue it with the next incremental delivery and then maybe combine few incremental product delivery and then put it into production right but that's how a scrum model functions and we will try to understand the framework as well the overall framework so in scrum we are looking at three key roles right now the first role is a product owner a product owner is someone who like owns the vision of what is it that you want to build for that product he's the one who maximizes the return on investment of what is it that you want to deliver and how would it give you the maximum returns right a product owner prioritizes the requirements which is also called as prioritization of the product backlog right and then works very closely with the team right is always available right when the team needs the product owner to provide the right feedback right to understand or do the refinement of the requirements as and when needed right that's the key role of the product owner here one thing to understand is product owner is not a project manager right so they are two different very different aspects product owner's role is more on how do we get the right product build with the right returns on investment now the moving on to the second role scrum master scrum master is we also call it as 3 p's which is like problem solver right protects the team from external interference right allowing the team to focus on other sprint or the iteration backlog right and is also responsible to make sure that is able to facilitate the team to go along with the various ceremonies which are needed right that's the role of the scrum master again scrum master is not a manager is not leading the team but is more of a facilitator problem solver resolves any impediments which the teams has and facilitates the teams to go through with the various ceremonies which are involved right and our team is usually in a scrum team we are looking at a team size of 7 plus or minus 2 individuals right so that's the general guideline recommendation the team itself is very highly motivated group of individuals cross functional which means like we are not looking at creating specialist within a scrum team which is like a database specialist or a quality assurance specialist each individual may have certain skill sets and but they must be willing to be cross functional to go beyond their own areas and contribute whenever the team needs for product delivery now on ceremonies so there are these four key ceremonies the first one sprint planning which is the first ceremony which is being done in any sprint iteration first activity which the team gets together understands what is the prioritized product backlog which the product owner has prioritized pick up what items they would be able to deliver basis their capacity within the sprint and there are certain outcomes which is like what is the sprint backlog prioritized backlog what is the sprint goal which comes out of the sprint planning and which the team is focused for that duration to deliver daily scrum meeting this is a key meeting which the team goes through like they get together and they try to understand what is it that they achieved today or yesterday what is it that they are going to achieve today and then are they facing any issues or impediments so the intent is the entire team gets together and is able to help each other out as and when needed they also get a pulse of how the progress is being made as part of the daily stand up and there is no manager or product owner who comes in as part of this scrum meeting it is the entire team who is driving through with this ceremony on sprint planning there are two parts which is the first part is called as the what part the team tries to understand with the product owner what is it that the product owner wants them to deliver the how part is where the team just gets together to understand how are they delivered what this product owner needs them to deliver the third ceremony sprint review which happens at the end of the sprint where it is an inspect and adapt meeting which is the the team inspects along with the product owner along with the stakeholders how have they delivered the product is it meeting as per the expectations of the product owner and the customer if not what is it that they want to bring in a change within how the product delivery is happening and at the same time the team also does a demo of whatever they delivered as part of that weekly bi-weekly iteration which the team goes through and as part of the sprint review product owner also provides acceptance basis the acceptance criteria of the various stories or requirements and which is what then falls as a potential shipable product once the sign-off or acceptance is received by the product owner those pieces of those code bases what becomes part of the potentially shipable product which means that is something those functionalities are which can be pushed into production as and when the need arises but may not necessarily always put those into production so it also works with the product owner and the customer what makes sense now sprint retrospective is something which the team internally does excluding the product owner excluding the stakeholders this is a team to go through with their own internal improvement process right so they the focus here is more on people on the interactions which they had the process which they followed the tool sets which they adopted or are implementing any challenges which they are facing they will bring it out and as a team they get together to understand how they start to resolve some of those issues right so those are the ceremonies artifacts product backlog I have already talked about sprint backlog is the prioritize item within a sprint which the team selects out from the product backlog burn down charts are something which are helpful to give a pulse of the progress being done in the iteration so as and when the requirements or stories are completed they get marked as done which means we are burning down on the volume of effort which is out there which gives us a progress in terms of very nice graphs which tells us are we going to meet our target delivery date iteration or not so those are the high-level scrum framework moving ahead looking into the scrum workflow so we have a product backlog which is the prioritize wish list of product owner working in conjunction with the customer what items would give the maximum return of investment is how the product owner would prioritize the backlog sprint planning is where the team gets together picks up the top most items from the backlog figures out basis their availability basis the complexity of what would make sense to be part of the sprint backlog on which the team would work on for that iteration then they go through with a daily scrum each day of the sprint the sprint itself is typically spanning from 2 weeks to 4 weeks of duration sprint review we touched upon so after the backlog the team delivers for 2 weeks to 4 weeks and then in the sprint review they do an inspect and adapt meeting identify the potentially capable product and then they follow it up with a retrospective and then they give a feedback loop into the sprint planning of how the previous sprint went through so that's the overall scrum workflow and then a very quick glimpse of sprint planning so we figure out certain inputs which is team capacity, product backlog, business conditions, current product technology which also gets factored into the sprint planning the team analyzes this comes out with the sprint goal the sprint backlog and estimate the sprint backlog to say this is the kind of complexity which is involved in delivering certain stories or requirements the sprint retrospective again there are a lot of techniques available to understand how what opportunities are there for the team to improve with their processes and an agile team always focuses on bringing in continuous improvement so very key aspect of any agile team and it's a very important event which the team goes through one of the simple but effective retrospective technique is start stop and continue where all the team does is they get together understand what is it that they would like to start doing what is it that they want to stop doing which is having an improvement or like is anchoring the team to slow down with their productivity and what is it that they wish to continue doing and this is just one of the many ways of doing retrospective at the end of this they come out with certain clear actionable items one or two actionable items which the team goes back and feeds it back in the sprint planning so that's on agile and scrum now what I would like to do is before opening up for questions I would also like to go through this trade matching engine which is a segue into the next session which we are about to do where we would go through an example of trade matching engine now this is something which was communicated in the last session where we looked upon on an exchange problem where we are looking at a trading and settlement cycle so in very simple terms let me try to put it out so let's say there is an investor A wants to buy certain stocks from the exchange think of a Bombay stock exchange or a stock exchange where there are stocks being traded right now there is an investor A who wants to buy certain stocks goes to the buying broker says that I wish to buy XYZ stock the buying broker places and goes to the exchange to figure out is there anyone who is even selling those stocks which is where the investor B comes in because for any trade to happen you need two parties a buyer and a seller so investor A here is a buyer investor B is a seller so seller investor B says I need 50 stocks to sell investor A says I need 50 stocks so both request go through with their own broker so buying broker and selling broker they reach up to the exchange and the trade happens so which means investor B would be left with still 50 stocks and investor A would get 50 stocks but in order for this to happen there needs to be something called as a matching engine which is what is our own problem statement here for this session and also for the next session which we are going to look at we are going to see how do we build a matching engine which would match buy and sell trades now in terms of specification we are saying build a matching engine to match orders placed for buying and selling stocks so a market order so there are types of orders when we are calling out buying and sell stocks so there is one of the types of orders is called as a market order which is I am trying to buy stocks and the current price of the stock is let's say 100 rupees I wish to buy 50 stocks but I am not saying the seller says I am willing to give the stock at a price rate of rupees 105 which means 5 rupees above the market price the buyer says that I am okay with the price which is available in the market which is what is market order limit is like buyers say I am going to buy stocks only at rupees 100 he is putting in a limit price to it and the bid price is like what is the maximum price which a buyer is willing to pay and the ask is like minimum price that a seller is willing to sell the stock so that is the specification now for such type of problem scenario how do we using agile methodology we start breaking the entire problem statement into smaller chunks into smaller user stories or requirements is what we will try to understand and rather than building everything because with waterfall if this is the problem statement we would have built all the functionality which are needed and then deliver it like after few months to a customer but with agile we are trying to break it down and say what is the bare minimum thing which we may want to pick up and which is end to end which is meaningful which is valuable to the customer which we can pick it up and deliver it so what we are going to do is we are going to create a product backlog here so we have already created the backlog but this is to depict or help you guys understand how a product backlog would look like for a matching engine so the first story is like as a user so here it will be as an investor for example so I want to place a market order so that I am able to buy stock at the best possible price only focus is on market order having a feature which is to place a market order and be able to buy stocks right but if you look at the scope of the system we also want an ability to be able to sell stocks which is the second story I want to place a market order so that I am able to sell stock similarly I may want to buy stocks only at a limit price so the third story is I want to place a limit order so that I am able to buy stock at a specified price or lower which means we break it down into end to end functional deliverables which if we were able to deliver it added part of an iteration and if the team delivers this user would have value by that delivery right which is what is the core principle of this agile iterative incremental model how do we break down our overall product into various user stories which would be add value to the customer so we don't want to build let's say a matching engine or maybe a database layer or just a UI layer right which is of no value because you build a database layer but there is no customer who can do anything with that database layer so you need to think through like all your vertical layers which would go from your UI your business logic and going all the way up to the database if there are any external systems involved having that ability to connect to those external systems so having that end to end capability is the bare minimum chunk of slice which we are calling out in a user story now once this product backlog is carved out the team gets together and does the estimation basis the priority which is provided by the product owner right the estimations I have called out in terms of t-shirt size exercise or something called a story points so t-shirt size is nothing but in terms of lesser the size of the t-shirt less complex the story is to deliver higher the size of the t-shirt it is that relatively complex to deliver that piece of functionality so let us say we are starting with XS that is the smallest size then S as the t-shirt size then ML XL right double XL so and so forth so here we are saying the first story is XL it is very complex as compared to the rest of the other pieces because maybe that is the first thing which the team is trying to put together and maybe that is the only thing which they can deliver in a sprint right so if you look at the last column which is sprint in sprint 1 the team focuses only that specific item sprint 2 they are focusing on the next complex item and so and so forth so this is just to give you guys an idea of how in an industry when someone is making use of agile how they break down the requirements into deliverable, valuable functional stories the story should follow something called as an invest principle I will not talk about it but google through it and you will start to relate it back to what I am talking of what does it mean to be an invest principle right so this is the product backlog I am not talking of this because it is just the continuation on a similar concept of we have just extended with various additional functionalities and if we were to pick this up this would add incremental product delivery value to the overall product if you notice even the first story if the customer is happy the first story can be deployed to production and there can be value that can be gained out of that we will not have to wait for the second sprint or the third sprint to complete to put it into production the first story itself is a working piece of product which can be used immediately by the client so this is not going to be possible in a waterfall methodology exactly so now the last piece which I want to touch here is specification by example there was a question also called out in terms of how do we capture requirements and all of that so this is how we would capture those requirements which would also form the acceptance criteria to build the first story if you recollect it's as a user I want to place a market order so that I am able to buy stock at the best possible price here we are trying to break it down into something called as a given when then given let's say there is a stock foo which is traded in the exchange with the current market price of 100 and following sell orders are made to the exchange if you think of investor B making a sell order to the exchange with the stock price of 105 which is a price limit minimum price which the seller B wants which is 105 for the stock foo right and the seller B says I am willing to sell 200 quantity of foo with the 105 price right and also there is another stock which is BAS which the seller wants to sell but if you look at when part the user B1 so there is an investor A which is the user B1 wants to place market order to buy following stocks like wants to buy foo at a quantity of 50 then when then the user B1 is successfully able to place the market order and user B1 is able to buy following stocks so is able to buy foo with a price limit of 105 with a quantity of 50 right so this is only talking more from a market order and a buy perspective we are not yet talking of what happened to the seller B which is because we have not built that yet so we are going to simulate some of those capabilities that the seller B is already out there but we are going to build the B part of it or the buy part of it and then later on we come to the sell part of it but and if we were to pick this up this can be very well be automated against the code base which we built which helps us to make sure in an automated fashion that the acceptance criteria of a story is met so this is how overall the software delivery life cycle functions right with waterfall agile giving an example of scrum with a specification by example right now that's all I think we have to cover for this session and we will open up for a few questions for another 5 10 minutes and then we will follow it up with the next session Sagar Institute Bhopal good afternoon sir you are not audible good afternoon sir good afternoon you are audible please proceed ahead with your question we cannot hear you sorry we cannot hear you hello yes what is the role of maintenance in HDLC model so maintenance phase is when your product is already live in production and it's not that once you have made your product once the product is live in production it will not require any changes or enhancements based on the feedback from the end users you may still want to enhance it you may still want to add new features to it and that's what is maintenance phase there could be defects that may be may become evident only in the production phase when it is live which you may not have been caught in the testing phase they will have to be fixed as well so maintenance is nothing but doing certain small enhancements plus defect fixes etc that are identified when the product is live the project is live okay next question please is there any practical example of that customer's requirement has changed after development of any software and then change has been after development after the development of that software yeah it could be it could be as simple as say you know let me think about something so what's the question is there a live example where software requirement has changed after the software has been delivered can you think of an example okay so there are like ample right it happens in everyday right so think about it like if I put it like let's say Jeff Bezos as Amazon CEO comes and says that he wants an ability right to have let's say Alexa as you guys all know right so the software engine which is like AI right having an ability to buy let's say stocks right someone calls out that he wants to buy he wants to build this capability to say if someone says buy XYZ stock go ahead and buy it right but let's say and I think this happened in real life let's say the news was going on someone called out to buy stock etc and Alexa was open and it went out and did this right so you've already built the product it is out there with the customers there's a change in requirement now you want to do it like at for each and every point in time right but maybe you want to have a code word or something which is which would tell you that you are the authenticated voice talking to Alexa and you build that capability and I'm just making this up right but this is just so that you guys are able to relate the implication of something which goes into production you build had a requirement but then the requirements change because of various business conditions or user conditions and then you want to go back and change things right and how do you manage that so which is what is the real example where certain things could change even in financial organizations like you're building certain screens right which is what your customer wanted but realized after three months that maybe that's not the right thing to do because it's not maybe giving that right efficiency and there's certain better way to do it they'll come back saying that okay I want to build the screen in a different manner all together and how do you incorporate that in an iterative incremental model and it is where agile helps you to fit that in sometimes even when you know you're working on certain requirements we do a lot of we also make a lot of assumptions ourselves then going back and checking it with the customer so we base on assumptions we go and build out something and if we had to follow a waterfall method the only time that the customer gets to see that built is towards the end of the software development life cycle which is too late to incorporate any changes right so there are multiple such examples of the report that needs to be presented in a specific format and we assume that it is that format and we don't go back and check it with the customer and by the time we've already coded for the report when it comes out and he sees it it is not what he wanted so there can be multiple set examples not only one so we go into the next question now Sagar Institute do you have any other questions I have one more question sir okay so we'll take one last question from your institute now what is virtualization in cloud computing okay so see virtualization is something where you have let's say your physical hardware resources available right and then you want to spin up additional machines utilizing the same physical hardware right having their own guest operating system right which is where what is nothing but virtualization right you're creating a lot of virtual machines utilizing the underlying same physical hardware and each machine running with their own fixed set of resources and a guest operating system is nothing but is called as virtualization in the cloud model so it needs a layer which is called as a hypervisor layer which would allow your virtual machines to talk to the underlying physical hardware resources okay so we move on to another institute Valchand Institute Sholapur Obstacles faced in Scrum Obstacles faced in Scrum question I would think if there is a complex requirement which is not very clear even in Scrum that can happen the requirements that are given in a user story there could be gray areas around that we will need to prod the product owner more we need to understand those requirements I will go for that with Scrum we relate back to what we earlier talked about self-organizing teams we talked about a prioritized backlog we talked about having stories with invest principle which would have acceptance criteria what if all of those are not met what if you do not have self-organizing team what if you do not have cross functional team what if the requirements are not carved out early enough or if you do not have prioritized backlog you cannot really be able to function efficiently in a Scrum model so there are certain prerequisites which you would need to meet to be able to function very efficiently with Scrum if you are not able to meet those things you would essentially not be efficient and you might probably even fail to be able to follow agile and Scrum if you look at it right time is very less I mean the sprint itself is 2 to 4 weeks within that 4 weeks you have to develop a working software so if you do not follow the principles to the T then it is very likely that you will not be able to succeed ok I hope that helps your question any other questions no cannot hear you sorry keep the mic closer to you and speak up a little bit between SRS and PRS sorry please repeat we can hear you but you are not clear what is the difference between SRS and CRS so you are saying software requirement specification and customer requirement yes so in my opinion so customer let's say would give you a very high level requirement to begin with that this is what I want to build out but may not be that detailed enough in most cases then as a software team you come together start carving it out in terms of your software requirements basis what customer gave you right and then you are putting in detail with like what is your acceptance criteria to deliver those requirements and then you take it back to the customer saying that basis your customer requirements right this is the technology document on the software requirements which we have came out with which details out like the implementation the solution along with the acceptance criteria we are happy enough for us to proceed with that so that's the kind of high level difference between CRS and SRS okay alright so I think with that we would need to now close this SDLC live session because we have the next follow up coding session also lined up but before we call them up I would like to take 5 minutes to pick up or get questions on cloud because this is the week 4 where we had opened up the cloud primer MOOC session and I think there were a few questions which I was already passed on which I would like to share and bring it up but at the same time if any of the colleges have questions we would be happy to pick 1 or 2 questions on cloud related topic as well right so Valshan do you have any cloud related questions which you want to go for before I pick up the questions which were shared with me what is the need of cloud native applications what is the need of cloud native is it cloud native applications yeah I think you are asking the need of cloud native yeah so alright it's a good question for cloud applications there are various levels of maturity so before even we talk about cloud there are basic aspects which we would need to meet to be able to have those cloud running those applications running in the cloud environment right which is like being like cloud ready where you are saying you may not have access to the cloud environment and again it depends on the type of model which we are following is it an IS model is it a past model is it a SAS model right so your question I presume is more to do with past model is that a right understanding what are the applications that means what applications right you could have those applications running in an IS model or past I am connecting this to a past model which is like platform as a service where let's say you don't have access to the cloud but in IS you may still have access to the cloud and it will function very differently right but with a past model let's say you don't have access to the cloud environment so you will need to adhere to certain aspects which is called as a 12 app dev factor principle so I will not touch on that you can google it up so once you are adhering to that it will be eligible to have those applications running in cloud now the next levels are like looking at cloud native so there are intermediate levels but I am skipping them and moving on to cloud native cloud native is like you have everything what you need for your application to function available on the cloud so when I say that let's say database for example itself right you have a database running on cloud there are certain cloud providers which offer you those capabilities with those with your architecture and the requirement then you may have that application fully cloud native right the benefit you will get is like you are not dependent on any off-platform services you can scale up your instances like as quickly as possible in a cloud you don't need to worry about any other hardware and all those kind of things you will be able to have higher availability and higher resiliency by having applications which are cloud native with almost reduced downtime if at all if you are moving towards cloud native architecture is there one more question what are the risks that if the security of the cloud is breached sorry what is the risk if the security of the cloud is breached alright so the risk is again would depend back on to the application right so what is the application which you are hosting in cloud environment right and depending on the applications inherent risk you are going to take that risk by moving that application on to cloud again it will depend on the type of model which you are following right if you are going and again think of those deployment models which I had highlighted whether it is a private cloud public or a hybrid so with private the risk appropriately may decrease down as compared to public because things are within your control or your organization's control to a larger extent but if you are hosting them on the public you need to think about like the security mechanism by having the data transferred across your organization and the public cloud's organization and also if you are storing some data which is like we call that data at rest data at transit so you need to ensure that you have built in the security at these layers if you have you haven't then you are exposing the application inherent risk to by moving your apps on to cloud now as you said that they provide us a private cloud they also provide that we can virtual private network then is it really safe that we can means to have means they provide us a VPN that should accept it or not means they are safe or not different types of service provided VPN not able to clearly get it but are you saying is virtual private cloud safe or not is that the question no so this has nothing to do with whether it's virtual private cloud or your app in the cloud itself right so virtual private cloud is just a capability which Amazon has exposed right as a capability in Amazon but not all clouds may have that kind of a capability it's like let's say you are building an intranet in your own college right it's a subnet network which you are building and if there are multiple such subnets you are trying to create an internal cloud on a public cloud which is what is virtual private cloud right but the risk standpoint if you are asking again it will also depend on the application's inherent risk and have you built in those security mechanisms or capability that data at rest, data at transit etc even when you are in VPC or outside of VPC I think you would still be equivalently exposed from a risk standpoint so we'll move on to another college and I know in the interest of time we don't have a lot of time so I'll pick two last questions and then we are going to end with the cloud topic so this is Asia Pacific Haryana Panipat do you have a question for cloud good evening sir yes please go ahead with your question hello yes we can my question is how would we shoot for transporate cloud can you repeat your question how would we my question is how would we shoot data for transport in cloud so are you saying data transport in cloud is that your question how do we do data transport in cloud so again it will depend if that's the question on data transport right it will depend on what is your source destination right what type of channel are you trying to use for example let's say you may be trying to transmit data from one system in cloud to another system as a let's say HTTP connection right or an HTTPS connection so if the channel would be HTTPS right and you're trying to secure it using your certificates with HTTPS but if it's let's say TCPIP by using messages messaging systems etc you may want to use certificates to ensure that the channel is appropriately encrypted by following TLS 1.2 protocol etc so it will vary this is the type of data channel which we are looking at and the security mechanisms would appropriately vary right but these are the two examples probably I think it may help you to just relate back to your question so one last question now on cloud maybe another college one last question on cloud so this is Bansal Institute Lucknow Bansal Institute Lucknow do you have a question for cloud hello yes actually I was not connected earlier that's why I have a letter to the agile model can I speak? yes please go ahead so what is the role of Scrum master in agile and why we give the great preference of agile because we have already spiral model so why agile should be deployed? yeah so see the spiral model so there are two parts to this question one was I think why to go for agile when we already have a spiral and the second was the role of the Scrum master right so the first one is what I will try to answer which is on the spiral and agile so spiral is the first of the kind of iterative model which came through after waterfall, V model etc the way spiral function it hasn't come out with a framework per say like what kind of role what ceremony is who needs to do what etc all it talks about is it's a mix of iterative with a prototype capability and picking up the phases of waterfall but in a iterative prototyping model so you go through certain prototyping exercises with spiral so you'll have like prototype 1, 2, 3 after that you'll start to realize that now this model is taking you much more closer towards your product delivery and then you start with the actual product development so that is the spiral model but with agile we are looking whatever we are trying to deliver as part of the sprint we are looking to have them delivered which are product delivery which matches to the users acceptance criteria from the first iteration itself having the outcome being a potentially shipable product which potentially you can take that all the way into production with a lot of agile now if we specifically talk about scrum scrum would give you those frameworks in terms of a good structure for you to function under that agile principles by having the right set of roles which is like product owner, scrum master team who needs to do what the ceremonies the significance of those ceremonies and the lastly on the the various artifacts which you need to have as part of the scrum framework the benefit which you are getting and then it doesn't necessarily advocate that you need to stop there you can very well feel free to customize what you need which is where the scrum is helping you to bring in principles from extreme programming by saying let's do pair programming so when the team goes through with the retrospective they may feel that there is a need to do those kind of exercises feel free to bring those kind of things which is where is the benefit now the second question is the role of the scrum master so the role of the scrum master is a facilitator is protecting the team from any external interferences to allowing the team to focus on the sprint delivery the scrum master also resolves any impediments which the team is facing or facilitates in a way such that those impediments get resolved the person himself or herself may not be solving but can reach out to others to facilitate how those impediments get resolved so those are certain key responsibilities of the scrum master scrum master is not owning the entire delivery is only facilitating the team to function with those ceremonies and being protecting the team from any external interference and problem solver so those are the key responsibilities of scrum master so okay I think we come to a conclusion for the SDLC along with the cloud related question I hope you found this very helpful and useful so thank you so much please stay online we would have the next set of presenters come over so maybe we are taking a 15 minutes break and then the next set of presenters would come over for the next session alright thank you so much stay tuned