Agile Modeling Sabiha mam

So, you can call that technique an Agile Modeling Approach. Clear?

Now, what do we mean by User Centric Approach?

It's user involvement that we're seeing in prototyping. The user interaction from first to last was the same. The user was with me every step of the way. In this way, if you develop a system, it will be a user-centered approach. Well, this model is not if you create a system development technique by yourself and call it Eigen Modeling.

For an approach to be called a modeling approach, it has some values and some principles that we have to accept. What are the four values? One is communication, simplicity, feedback, and courage.

First of all, in my definition, which was user-centric approach, I have to communicate with the user from the beginning to the end. Communication must be maintained. It is the relationship between the system developer and the user. There is another relationship between your team and the team of the system analyst.

Now you may be asking, why should this relationship be strong? We need to know because we are prototyping or using RAD. We already said that our objective is to solve the problem of traditional SDLC. As Eigen Modeling is a new system development approach, its task is also to solve the problem of traditional SDLC.

What was the problem of traditional SDLC? It was time-consuming. Now, to reduce the time as much as possible, I will put my hand in every place. Okay, now the analysts have thought a lot and analyzed a lot. The way to reduce time is to increase communication.

How do you think that one of your development team is designing while another is implementing, and there is no communication between them? Now, the one who designed the design, what did he do? The developer implemented it, but many things could be in the design that the designer had in his mind. The developer might not understand what the designer was designing, and he could have a problem with the design. Now, if there is a gap, these problems are fixed by the designer one by one. Time is wasted in many ways between these two works.

Now is the time for our designer to sit together and work on what the designer is doing.

Sir, if there is any question, turn off the mic.

Simplicity: The point of simplicity is that you are doing a big job, like a normal website. No matter how small you say it is, it is not so small that you can do it all at once. Of course, it is a job. According to the values, how do you start? From small, as many requirements as you have, you study all of them. Which is the most essential requirement? You start from fulfilling that requirement, then slowly you add other requirements. Start the work from small to simple, and then the task will not seem so big.

Okay, point number three is feedback. The feedback is the feedback. I told you a little earlier that it should be a user-centric approach. From whom will I take this feedback? I will take this feedback from my user. I will use the system or the prototype and give feedback on it. From that feedback, I will add the information to the next prototype and give it to the user for feedback. This is a very important point.

Modeling means prototyping, which can be many things. Prototyping may not be okay. Whatever you think you are designing, you will design it with the user. You will do it with the user.

Point number four is courage. Courage is the mentality of doing something new. How do you think you make a prototype with a lot of pain? Okay, after making it, you give your prototype to the user who is very happy with it. The user says that he doesn't like it and won't do it again. What will be your approach? You will get angry here. You can't get angry. The user says that no matter how much you like it, you will redo the system according to the user's requirement. Courageous work requires a lot of courage. Can you understand now?

You may say that in traditional SDLC, I actually do these things. Yes, in traditional SDLC, you do these things because the basic work of software development is actually these things. But in traditional SDLC, I do one thing after another, and this Agile Modeling says prototyping. I do some work in parallel. I can understand what happens, my work time is reduced.

Well, that's the value. Next, in the case of Agile Modeling principles, there were four values, and there were four principles. 14 is fine. Many places give 14 points. In this book, since 14 points are given, then 14 points are the first point, which is to satisfy the customer through delivery of working software.

It will be how to ensure the satisfaction of my user or customer. I make a prototype or a model of it instantly and show it to the user. If the user is satisfied, then I will do the next thing. You will show the version in the next one month. Okay, now you are delaying one and a half months instead of one month. Then, you can't do customer satisfaction. You have to fulfill the user requirement on time. Then, user satisfaction can be ensured. This is the principle of Eigen Modeling. I am reducing time. There is no option to delay here. You have to fulfill the user's requirement within the time frame you are given.

Point number two is to embrace change. Even if introduced later in development, is it that what you are doing is doing a lot of work right? You've just moved to the last stage of prototyping. Okay, don't spend too much time on prototyping. Your final model will be ready. Then, you just go to implementation. Now, at that point, your customer is saying that his interface looks better. Then, what you have to do is change the interface again. Maybe if the customer's requirement is like this, you have to embrace that change. Why? Because if I can't do that, I can't ensure my user's satisfaction.

Okay, point number one and point two are related, but if you read the 14 points at once, everything ultimately depends on customer satisfaction. Look at point number three: Continue to Deliver Functioning Software Incrementally and Frequently. This means that I do it through prototypes, and AD through whatever technique you apply. Involve the customer. I take you through your requirements. I show you some functioning software or prototypes. What happens to the user? It involves the user and excites him that he can see a working model of the thing he is thinking about. This way, you will ensure the involvement of the user. Instead of giving him a product at once, you slowly give him things. I'm making the model. See how it goes. Then, you add five more to the previous one. I'm adding some new requirements to the previous one. Now, you see how you feel. What's the benefit of that last change? The probability of that change is decreasing, plus the customer satisfaction and involvement you're able to ensure.

Then, it's about encouraging customers and analysts to work together daily. You'll see it; we call it on-site customer. Now, on-site customer means wherever my analysts and developers are working, bring the customer and sit down and work together with them. Okay? This is you, the customer. Encourage them, though many times they don't agree to work with you. So, who will do those jobs? They have to be redistributed again. Manpower is reduced. Now, to keep them idle, many times the top managers in the organization don't want it. So, what do you, the system analyst, have to do? You have to encourage them in your organization. I'll give them back to you within this time, but if they sit down with me and do the job, it'll be easier for me, faster and nicer, and you'll be able to get the job done.

Just talking about the customer, now we'll talk about the team members of the system analyst. Trust motivated individuals to get the job right. What is this job? The system analyst can't do it alone. You need more people, more team members. Now, you select these team members. How? Of course, you select him because you trust him. You have confidence in him, and he is highly motivated to do this work. Now, see, in this session, you have been asked to group, so you are grouping the people you like, who are your friends. Now, when you are allowed to work in the group, how do you divide the work? You will do it, but not as a team; it's individual work. When you can't learn anything from team work, when you become a big system analyst, if you still do nepotism like this, your friend is my friend, that's why I gave him the job, or he's my friend, so I did the work with him. If you act like this, you will never be able to deliver your work because your friend is not that highly motivated. He got the job because of his friend. If your friend is such a low-motivated person, even if you have 10 highly motivated people in your team, what will that one low-motivated person do? He will ruin the other 10 people. You have to see each person specifically, whether he is mentally fit to do the job, whether he is motivated. Then, you can complete your work timely and well.

Next is promoting face-to-face conversation. Another point among the team members is that your team member plus the organization comes first. Among the team members, you are now assigned to a team. What are you doing? If someone lives in the city, you can't communicate face-to-face. What do you do? Message on Messenger or WhatsApp, "I'm writing the report today. Let me check the report if it's okay." This is not a face-to-face conversation.


What's the problem here? Many things you don't want to type. Many things you'll think, "Damn, it. Ignore it. Madam will not look at something else. I think she will also look at it and give a presentation; let her do it. Am I right?" If she gets a low number, I will not get it again. You don't want to type the wrong mistakes, you're saying in your mouth, "You fix it; the comma is not read correctly here, let one person do the typing." Even if you sit next to them and see many mistakes, you can identify them to your friend, that you're making a mistake. So, face-to-face conversation between team members is important. No matter who does the work, sit down with everyone and discuss. If they do the work, a lot of mistakes come out during that discussion, which come out later in traditional SDLC.

Okay, now let's come to the customer and communication between your team members. It's the same thing with the customer. You make a little prototype and tell the customer that you use it and give me feedback after a week. He doesn't say anything. It is easy for him to sit down and listen to what everyone has to say.

Concentrate on the next point. Concentrate on getting the software to work. You're leaving out that if it's the customer, it's not actually used by the customer. I'm leaving this button blank. Okay, you can't do that. You don't provide a button that you don't have or that you can't implement. You can't do the work, but what is visible in front of your system is workable.

Then, it's Encourage Continuous Regular and Sustainable Development. This is what I say in the class. Sustainable means maintaining sustainability in the Agile process. It is very difficult because I do not think about the future, but here in Agile Development, you're encouraging so that you think about the future to some extent and do the implementation. What will happen? The system will be sustainable.

Point number nine: Adopt Agility with Attention to Mindful Design. You have to embrace agility here. Agile is not just about working quickly. It's about thinking of agility, plus being mindful of what sustains you in the future. In combination with these two, you will follow your new technique. Understand that you will create a more mindful design. If you couldn't get the design done by doing the complete documentation by hand, or you couldn't provide the best output in less time, then it won't be an Agile model. You will do the work in less time, but you must ensure it is sustainable in the future. Focus on this point.

Point number ten: Support Self-Organizing Teams. What does Self-Organizing Team mean? You are a system analyst. What can you do? If you want, you can select five people from your company and form a team. You have fully announced that an offer is coming to us from such a company in your organization, and we will make software for them. If you want to work on this project, now they can come and form a team and say to you, "We can do this work together, with five or seven of us." This is a self-organizing team. Why should you support and encourage it? Because if there is a mutual connection between them, the tendency to speed up the work will be more. First, they have to bond, they have to get to know each other, they have to be free, then they start the work fully. Those who are self-organizing teams are already a team.

This is why we don't group you in your lab; we say that you group yourselves. You are given a lesson on making a self-organizing team, even though you don't think about what your job is or who is better for analysis in SAD. You don't think about who is your friend or who is a good student. If you group with them, you'll get good marks. The faster you get feedback, the faster you can create the next version.

Point twelve: Encourage Quality. Do you work quickly? If you do it according to your own will, you have to ensure the satisfaction of the user. If it takes you more than 15 days, you will give it. You also have to maintain the quality. When do you say that a system is of good quality? When the customer of that product is satisfied by using that product. When he says, "No, you can supply a good quality product," then you can say that your system is good. Quality is proportional to your customer satisfaction.

Number thirteen: Review and Adjust Behavior Casually. You are a system analyst. Everything you see is maintained. If you see a fight between two people in your team, now they don't come in front of you and they don't fight, but what will they do? They will be late for work. They don't deliver on time. You monitor them, and if you see that the relationship between the two of them is never really good, you remove one from the group and add another. This way, you occasionally adjust behavior within your team.

Okay, the last point is Adopt Simplicity. Simplicity? I mentioned earlier that the work should be started small. Don't try to do everything at once. It's okay if you try to do everything; the work will never be complete. The foremost point of the Agile model is communication, customer satisfaction, and dividing the work into small parts.

Okay, then I'm going to the next point, which is the four basic activities of Agile development. Now, it's called the four basic activities of Agile development. These are the four basic activities of any software development. What are the basic activities? Listening, designing, coding, and testing. Listening, what is the work before starting the work? I need to know how the system is behaving. Now, I need to know how. The customer will tell me from the customer. I will listen. This listening is listening. Now, don't you just do that in Agile development? You also do that in traditional SDLC. You have to listen. You will hear it or not, your software development phase will have customer involvement. The customer will give you feedback from time to time; you have to listen to those things.

Then, what is designing? Even though we say Agile development, say prototyping, and say AD, we don't do elaborate designs like that. But before implementing any work, you think in your mind that you are going to do some work. But you design it to some extent. That's right; you do the designing in your head and write it down in the book, and then you go to the implementation. What will I do later, and you are eating? Okay, it can't be done. You will listen to the work, then you will think in your mind, "What is my work actually? I will start with some requirements first. How should I start? Then, what will I do next? How will my work be completed quickly?" Okay, this kind of design you do roughly first, then you go to the next phase.

Point number three is coding, which has to be done in all cases. Okay, without the code, you can't implement what you think is your requirement. You implement it in the code. Then, testing is most important. You have done it, but don't give it to the customer immediately. What you have to do is test your whole system. Now, testing is done in many ways, which you will do in software engineering in the next semester. But after implementation, you can't hand over the work without testing. These four tasks, not only in Agile development but in any software development, are your basic tasks. If you omit even one of these four tasks, it will not be a software or complete software.

What does resource control mean? You have a limited amount of resources. How can you get maximum output out of that limited stuff? This resource control means, I mean, limited resources in this software development. I have this limited amount. What are the limited resources? What are my constraints? There are a few points that these constraints will be in front of you in terms of Eigen Modeling. You have to manage them.

What are the constraints? I am bringing all the rest. Then, what is my time? Time in this modeling is also my constraint. I will be given a time frame within which I have to work. Now, suppose you are a very good person, you understand the user's requirement, and you want the best for the customer. So, what did you tell the customer? You gave me one month, but if you give me another 15 days, then I will make your work more beautiful. It's not bad on your part; it's your good intention. But the problem is that since the customer has given you such a limited time frame of one month, it must mean that within a month, the user of the software will have the same usage as before. If you give it to him even after a week, his usage may decrease. It may be that you add new features for 15 days. Actually, the customer does not have much need for those features. Even without adding them, the customer could have worked with this software. But since you delayed 15 days, the customer no longer needs the software. Well, with this example, I want to explain that no matter how good your intentions are, if a customer gives you a time frame, you go out as much as you want to add new features, as much as you want to make the website more user-friendly. If you don't need it, if you take 10 requests and deliver the system to the user within the time frame, then if you talk to the user, the new version you create later, you will update in the next version. It is okay, but if you cross the time, it will not increase the satisfaction of the user. In the maximum case, the satisfaction will decrease. It is okay.

After that, the constraint is the problem. Now

, how is the constraint? My first two limits are okay. Now you can think about your time and the trouble they are giving you. The payment they are making you. You have given one month. Your time frame is one month. Okay, within one month, you will develop software. What can you do if you can't develop that software with the manpower you have? You can add new developers to the developers you have or hire new developers from the project you are doing. Now, you will hire a developer. He will not give you this money. Your organization will not give it. They will say you have to do it in one month. For one month, I will give you this money. If you can't hire new developers, you have to make do with what you have. Then, you have to worry that if you can't complete the task within a month with your developers, then you won't take the task because you have to match the pain to your pain. If it is more, then you can hire. If you see that you can't increase the difficulty in any way, in case you don't have the trouble or money to hire, you can do the work with the team members you have. If not, then you will take the work, but it cannot be done that way. I have hired now, then I will get from the organization. The organization will not pay you to hire people.

Well, you have to remember that the third point is quality. Take the previous example. You are asked to develop software within a month. Now you have fewer developers. You can't. Your suffering is not being increased. In that case, what will you do? You will reduce the quality. Naturally, you can do the kind of work that you can do in a month with 10 people. It is normal that you cannot do the same level of work in a month with five people, unless you have the experience of these five people. Either way, your quality is also a resource control variable. If your time is limited, if your pain is limited, your quality will vary accordingly. It can't be done in your limited time and limited difficulty.

You have to clear the fourth point, which is the scope. What does quality mean by quality? User satisfaction is okay. First is user satisfaction. With that, you will measure how your system is doing. Is it good quality or bad quality? We will see those measures. First of all, customer satisfaction is the number four point.

The scope is the scope. What is your opportunity to work? How much work you can do in one month? The customer has given you the goal of that organization. In that goal, how much you can do is your scope of work. The organization will ask you to do a lot of things. Okay, in one month, say, you mean that doing something that is actually not possible in a month, then what do you do first? Study the organization goal, understand the whole organization. Then, what is useful for that organization, plus what you can do as much as you can with the time frame that you have in a month. By estimating, you tell the user that if your time, cost, quality, scope meet all of these requirements, or if this work can be done, then I can do this work. That is, you do not have the scope to actually do more than the scope of that work because you do not have time, you do not have money. I can explain that they are resource control variables.

Next are Agile practices. So far, we've been learning the theoretical. What's actually happening in the theory? Okay? What's the theory of the method? Now that we have these four points. The first is short releases. This means your team will take a few requirements. After creating the list, they will take some requirements. What will they do with those requirements? They will make a prototype or make workable software. They will give it to the customer. The customer will see it, understand it, use it, and give feedback that yes, everything is fine. This way, for small releases, they will develop the big software. Now, it doesn't necessarily have to be a prototype; it can be workable software. Okay? A prototype means a model. You will make your company's software after seeing that. And short releases can be a prototype or workable software. You can divide your whole system into several modules, think of each module as workable software, create it, and give it to the user to use. Then, take feedback from him.

This is number two. What does that mean by 5, 8, 40? Seven days a week, seven days, two days off, five days working day. Five days you have to work eight hours. Okay, now if you want, you can do it eight hours five days, six days. How many hours are seven? You can do it in six and a half to seven hours, and you can do it in eight days. But in a week, you will make your developer work more than 40 hours, and that is more than eight hours in a day. What many people do is work 40 hours in three days, then take the rest of the four days off. But if he can't do more than eight hours in a day, then how many days does he have to work? Minimum five days, maximum seven days he has to work. But it can be more than 40 hours. Now, you can talk about it because after a lot of research, it has been found that a man in a week can give good output in 40 hours. The same person can give output. His brain is more active during that time. The rest of the extra time that he is working does not actually produce good output.

If I'm doing overtime by working more than eight hours a day, then after eight hours, his brain is not working like that. Okay? Then, the output he is giving me, the work he is doing, is definitely not of good quality. Then, why should I take that work? So, when you set the time, you have to think about how many of my developers I don't work more than 24 hours with because more than that won't work well. Then, you have to think about my workload together, and you will set your project completion time.

Well, number three is on-site customer. On-site customer is what I said a little earlier where we system analysts or developers will sit and work in the organization for which we are working or making software. A representative or a team of representatives will be with us so that what I am doing is getting approval from the other side. That way, there is satisfaction, plus the probability of any change is reduced after you go much later.

Well, then point number four is pair programming. What is pair programming? Pair programming is a work done by two people. Since the name is pair programming work, the work of programming or implementation work is implemented by two people. Now, why is it that we are doing Agile development without a limit? I say what happens to you in Agile Modeling is that no documentation is maintained. Now, suppose a developer is in the middle of developing a whole system website or in the middle of it, he gets a good job offer in another place. He leaves. Now, your work is half left. Right? You have to finish the work. Then, what will you do? You will put another person in that place. The developer will start from where he ends. Now, the problem is this: Is it small or not? You all seem to be developing websites so much. A big one is to understand who is doing what, but it will take a long time to understand. Okay, because I don't have any documentation here. I just read the code. Now, this problem can be minimized a bit. How? Now, if I add someone to him before he leaves, he doesn't need to code. He will just sit and watch the other person code. He will understand what he is doing. If he has any suggestion, he will give it. I added the team members, and then two people completed the rest of the work. This is in the case of modeling or this type of work where you do not maintain documentation. In this type of work, pair programming is very important. Any work should be done in a team.

Let's go ahead. These four are the practices of modeling.

See, we are learning a lot. One is the value of Agile modeling, the principal activities of Agile modeling, then what are the resource control variables, and are your practices of Eigen okay? Let's remember. Now we are new. Another one.

Here's another thing in the middle.

User stories. What do you mean by user stories? User stories are the requirements of the user that he tells you like a story. You're either a developer or an analyst. You know how to separate requirements, but when you're an organization, talk to a low-level employee, but he will tell you his requirements like a story. Okay, what you can't do there, you can't tell him to tell you the specific requirements. He will tell you a story. What do you do? Separate the requirements from that story. Now, you can't remember this story once you hear it, so it's best if you bring those stories down. Note down what happens. There is no chance of forgetting any point, no chance of missing out.


Certainly! Here’s the continuation:

---

Okay, now let's learn another new Agile approach. It's called Scrum. I'm just telling you how it works. The first task is the same for everyone—collecting requirements. Now, whose requirement is it? Whose requirement is it? I can say the product. What are the requirements of that product? What is the next thing I will implement? I cannot call the requirement of this product a product specification because by specifying the requirement, we make the specification. We can call the system a product. I have that system list of final requirements. That thing is called that thing in this frame—Product Backlog. Clear?

Remember, nothing is called a System Requirement System. Here, they call it a product by specifying the requirement. The system specification or software specification is equivalent to the product specification. What is in your final specification list? The system? We call that specification list the Product Backlog.

Well, here's one thing—Sprint. A sprint is a 30-day time period that sets you a goal that we'll complete this work in the next 30 days. Let's say you're told to complete your total work in six months. You're going to come up with a sprint of 30 days. Sprint is nothing else; it's a time frame. What is a time frame? In this 30-day time frame, you're saving that you're going to do this or these things in 30 days. That's what I call a Sprint Backlog. Then, I can say Sprint Backlog is the subset of the Product Backlog because the Product Backlog is my total system requirements. From there, I pick some requirements and say these tasks I will do in the next 30 days. The tasks that I will do in those 30 days, this is my Sprint Backlog.

Well, now you say you have the Sprint Backlog, you are telling your developers or your team members that after 30 days, I see these tasks completed. Then, you are sleeping with oil in your nose. Why not? Because what will your developers do? We are human, right? What we do is we don't do anything until the deadline is 30 days away, and when there are five days left, your developers start working instead of fighting and eating and drinking. Doing it in a week is never going to be good.

Now, to solve this problem, we have the Daily Scrum. Product Backlog is gone, Sprint Backlog is gone, and next is Daily Scrum. The 30-day goal is set, but what will your team do? Meeting every day in this Sprint Backlog, you are doing today how much of the work you are doing, or what you are putting off for tomorrow. What are you doing each day in these 30 days? What are you doing today? What will you do next? What are you doing today? In tomorrow's meeting, you will say in today's meeting what you were doing yesterday. In tomorrow's meeting, you will say what happened to what you are doing today. In those 30 days, you have no chance to work at the last moment; every day, you have to update what you are doing.

Every day, because you're working on requirements, give that demo to the user. The user will use the feedback, and with the feedback, you'll select the next sprint, the sprint work. So, if you look at the process, but your prototyping is called Agile. Scrum says all but kind of similar to what they're doing themselves. When you become a system analyst, you can also update this Scrum in your own way. For example, here they are talking about Daily Scrum. I will do the Scrum meeting after three days. This is that you changed it a little bit, but it is not there anymore. What you did was modify it a little bit like this. By modifying small things, you can create your own approach—Eigen Modeling.

What can I understand? Hope everyone understands.

OK, no one has any questions from what has been taught today?

OK, then I will give you an assignment. I am supposed to take two CTs with you. See, OK?

Sir, my screen is showing.

Yes, ma'am. OK, I will give you the question here. There is no tension about it. There are two questions: one of 12 marks, and one of 8 marks. In the 12 marks question, you are given a scenario. Based on that scenario, you have to draw the use case diagram, OK? Here is the whole system. If you think about the requirements that are here, you draw the use case diagram. Of course, if you add any new features, no problem, but you have to show the use case diagram that represents the complete computerized library system. Can you understand the scenario well? Then read it. The use case diagram of a complete library, now, in that case, you represent the total system in a use case diagram. Don't do it. There is a high chance of making a mistake. Many things cannot be represented well. My suggestion for you is to divide each module into modules. OK? Suppose you are going to book or study. You are going to book one of its modules in the online library. Draw a use case diagram. Draw a separate use case diagram for a module of the book you are going to issue. This way, you can split the use case diagram and also show the total system in one use case diagram if you want. But if you show the whole in one, there is a chance of getting it wrong.

The next question is this: you are given a use case scenario. After reading the scenario, you are asked, as a System Analyst, which approach will you use to develop this form? You are asked to do a task by an organization, OK? Now, for that task, which modeling approach will you use? You will logically say in the description of the whole thing. You are told in the scenario—read the scenario well, then answer. There is nothing written to understand. Another thing is, don’t copy.