5.4 Modern Process Transitions

[0:05]Welcome back students. So in this lecture we'll try to understand about modern process transitions. So what are these modern process transitions and what are the different models we have we'll try to understand. So in this in your project management success means the hard work that is made for your project development is taken as your success here. So in order to make this success transition so we are working with two different aspects. First is your cultural shift and second is your we'll try to go with the second one also. So what is this cultural shift? So whenever there is any changes, there are any changes led in your project development, your cultural shifts will help you in understanding whether they can be incorporated into your project or not. So under your culture shifts, first we'll try to understand about the first point that is lower level and mid-level managers are performers here. So here in this case when your project development goes into picture, so most of the effort is taken only from the lower level and middle level managers here and others like other higher level managers will not put that hard work when you they go with your software development. So next point is requirements and designs are fluid and tangible. So here in your the conventional process, it is actually focused on the documentations or the sequence of steps that are involved and they should be presented in terms of your documentations. But when you go with your iterative model, that is your modern approach, it is majorly focusing on the results rather than your documentations. So it is majorly focusing on the sequence of progress that is made throughout your project development. So this is how your modern process modern process transition from your requirements to design level. Next ambitious demonstrations are always encouraged here. So here the purpose of your early life cycle model, it is used to check whether your cascade has put on or not. So but when you if there are there could be the stakeholders who are ambitious to have their results at the early stages. But this is not accepted, but most of the modern approaches will give you a positive result in the early stages, in your early releases only when you don't come across any errors. Fourth, good and bad project performance is more much more obvious earlier in the life cycle. So here like, so whenever your project development is made, your conventional model will check whether it is good or bad at the latest stages. But in your modern approaches, so you can identify whether your project development that is made is good or bad at the early stages. If it is good, the cost vested or impact of your project development would be very less. But if it is bad, the total cost vested also increases automatically. So this is about your good or bad project performance. Next early increments will be immature. So in your conventional model early increments, like early iterations or early improvements in your requirements is not possible. But when you go with your modern approaches, in your iterative model, you can increase the iterations or you can improve your requirements at the early stages. But this improvement will also impact on the total cost and efforts vested by your project. Vested on your project. Next artifacts are less important early, more important later. So initially your modern approach will not focus on the artifacts, but later based on the requirements of your project, the artifact sets will play the major role in your project development when you go with your modern process transitions. Fifth, real issues are surfaced and resolved systematically. So in this case, so whenever a project if if if you assume if the project is said to be a successful. So this successful organization of your project could be done uh, could be made at the early stages. So here if if while while your first release if you identify that the project is releasing any errors, so what is the cause of these errors and how these errors could be rectified are supposed to be identified and resolved systematically in your modern approaches but not in your conventional approaches. And next you have quality assurance is everyone's job, not a separate discipline. So in your conventional model, at every phase, everyone plays their own responsibilities. But in your modern in your modern approaches, the quality assurance of your project development is taken as a responsibility of every person or every test case, like automation tools that are being used in your project. And it is not taken as a separate point here. So there is no meaning if you provide a separate team in order to identify only a quality assurance and there is separate quality for each and every phase. So quality should be taken as an individual unit or a common unit and the quality should be taken at each and every phase from your project development. So next you go with performance issues arise early in the life cycle. So in your conventional model, like uh the project project may not perform very well. And if if if the project is not performing well, uh, so the people who are developing your project need to work more in order to improve the performance of your project. So in your modern approaches also, uh like we uh project managers will not ensure that the performance of your project is quite good. So it is always recommended to improve the performance of your project even though it is in your conventional or modern approach. Next you go with your investments in automation are always necessary. So your conventional model will not focus on your automations, but your modern approaches will majorly focus on automating these particular processes. So this automation could be because of reducing your cost or this could be in order to like improve the quality of your project. And next good software organizations should be more profitable. So your modern approaches will always assume that the organizations which are profitable as your good software organizations. Right. So that is all about your first point and second is denouement. So in this particular denouement, we'll try to understand we'll try to compare your conventional model with your modern software approaches. So this conventional software approach it is actually categorized on this four on this four points. So first, your conventional model it always assumes that sequential actions will always fetch a good result. That is from your coding to testing, a sequence of steps are supposed to be followed. Say first it always ensures that only your requirements are done, then it will make sure that analysis is done and then you go with your design designing that particular project and so on. So it will majorly focus on sequential actions only. And next uh so you can achieve so your conventional model will majorly focus on achieving 100% of accuracy at each and every artifact level in your project development throughout your life cycle process. And it is going to treat each and every artifacts, each and every component and each and every requirement of your project as equal and very important. So it will not say that whatever artifacts you have taken may may not be used. If there are some artifacts which are of no use also, your conventional model will assume that they are very important. And last your conventional model, so it is going to achieve like high fidelity of your output at each and every stage of your life cycle model. Right. But when you go with your modern iterative approaches, it is quite different from your conventional model. So here in your modern approaches, it is going to make use of your round trip engineering and each at each and every level it is going to impact or provide some improvements in your project. And second, it is going to understand what are the drivers in your project development to provide high fidelity and it is going to work according to those particular drivers only. Next it is going to postpone until right. It is going to postpone the complete completeness of your project or consistency of your project. So this will be done until the complete life cycle is first, like until your complete life cycle is done, it is going to postpone this inclusions into your project. Right. So this is going to provide you, this particular diagram will provide you how your project schedule to deployment is different in your conventional model to your modern approaches. So in your conventional model, so your actual progress starts from your starts from either third milestone or fourth milestone, that is majorly from your development phase. But in your modern project approaches, your actual profile starts from the very first phase and at each and every iterations you are going to provide some projectile profile or some outputs at your each and every iteration. So this should satisfy the target at each and every release, your modern profile will give a release of target profile at each and every level. Right. So if you want to move like a conventional model to a more mature model or a or your modern approach, you are supposed to make use of your modern architectures and tools. So these architectures and tools will majorly focus on these three points. First is ready. So you should be ready in order to identify, like you should be ready to understand what are the new approaches that are supposed that are available. What new technologies are available available in your project development and you should also be ready to include them into your project. Second, you are supposed to aim. So here this particular aim is nothing but you are supposed to select what is the critical portion of your project and focus on that particular critical portion of your project development. And third, fire. So fire is going to be how you are going to execute this high level plans of your project development after identifying the new tools and creating some target to that particular by using those tools. So this is all about your modern transitions in your project. That is all for this lecture. Thank you.