Video Transcript: Development

Hello everybody, and welcome back to Information Systems this introductory  course. You are almost done. We're in Module 10, already in week 10, and we're going to be talking about how we actually develop information systems and what goes on behind the scenes to get these technologies in our hands, in our  pockets, in our desktop and ready to use. So first, I would like to start off with a  prayer, if you'll join me, Dear Heavenly Father, I'd like to thank you for each and  every student who's come here to learn, and I hope that they have that every  student has their their mind wide open, their heart wide open, they're able to just understand what we're what we're learning, and be able to really apply it for the  betterment of their families, of their workplaces, and just to serve you better. So  in your heavenly name, we pray amen. We're going to jump right into the week  10 IS development, and we're going to go ahead and talk about the learning  objectives. Now that we fully covered the components of an information system.  We're going to talk about actually making them and creating them so upon  successful completion today, hopefully you're going to be able to explain the  overall process of how you develop a new software application. We're going to  explain the differences between software development and methodologies of  there's there's different approaches you can take for developing software. We're  going to talk about some of those differences. We're going to be able to explain  the differences between the different programming languages used to develop  software, and understand some of the issues surrounding development  websites and mobile applications. You know, some of the challenges that that  exist. And then finally, we're going to identify the four primary implementation  policies. So programming, programming is needed. There we go. I'm going to  put myself in that corner right there. Programming is needed to take ideas or  business solutions and bring them to reality. So if it's something that you're  imagining and something that you wish you could do with your technology, with  your hardware and software, programming is going to be needed to have those  those tasks executed. Small changes can be implemented in a short timeframe  with a streamlined process, and then larger changes are going to require a  software development methodology, and those are going to guide and manage  the process, and then we're going to talk about agile, we're going to talk about  lean methodologies, and those those ways that we can have a development in a really logical, patterned way, where it's it's comprehensive And it's consistent. So the systems development life cycle this SDLC, you're going to see this in the  book and in our slides. In this way, SDLC developed in the 1960s to manage  large software development projects still in wide use today. It's called waterfall  methodology. It's very structured. Each phase has an end deliverable that you  need to turn in before you go on to the next phase. And every phase has to be  completed before the next one can start in this waterfall methodology. And then  the phases are are written here. I'm not going to go over each one of them with  you in this in this waterfall methodology, from preliminary analysis all the way 

through maintenance. But if you would like, this is in your textbook and in your  supplemental readings that you can go through and look at each one of these  methodologies and the phases involved. And here they are. Next one there's  this rapid application development, RAD, this is going to focus on quickly  building a working model, getting feedback from users as it's going. And then  we're updating the working model in real time. This is best for smaller projects. It gives users the availability, availability to give feedback. So in real time, you're  asking those users, how's it going? What? What do you need? What could be  better? So the overall requirements are defined, the team is formed. We're  deciding how feasible it is. And then we go right around the right around the  phases here and again, I'm not going to go through. Each individual phase. But  if this is something that appeals to you in terms of developing an information  system and software development, this would be a place to start if you are  interested in either the waterfall approach or the rapid application development,  the R, A, D. Now we're getting into the agile methodologies, and this is a more a  more current method. I am personally a Certified Scrum Master, so scrum uses  these agile methodologies for an iterative approach. And so what you're going to notice here for Agile is that it's going to be small teams. They're cross functional, and it's done in some very small increments. So it's daily status meetings that  you're going to hold short little sprints or time frame increments for each change, and then a working project is completed at the end of each iteration. Each little  version that you do, you're going to demonstrate it to your stakeholders and  seek their feedback. So that's part of those, those agile methodologies, which is  when we're talking about, for instance, like a mobile application that's being  built, more than likely, it's going to be some part of this agile or some combined  method that will include some strong leaning on the agile methodology. Next  we're going to talk about the lean methodology. This is the last one we're going  to talk about. So this takes an initial idea and we develop a minimal viable  product. So the MVP, this works best in an entrepreneurial environment. So  we're going to, well, we could start anywhere in the cycle, but we're, if we're  building, then we're going to write some code and we're going to measure, then  we're going to measure the data. We're going to learn what happens. Once we  learn what happens, we're going to get ideas and start building again. And the  cycle just keeps repeating itself for that lean methodology. And so for this one,  it's going to be that just in time module, or just in time methodology, where it's  when we're talking about Lean, it's going to be just ultimate efficiency with  resources, whether those are human resources, financial resources, you'll notice on here that there isn't coding that happens until that measurement and the  learning takes place. So that is the lean methodology. And again, if you have an  interest, by all means, there's more about each one of these software  development methodologies in the supplemental readings. So as you're moving  through the feedback in this one, it's really important to get it's going to be the 

feedback is going to be given to two different forms, direct observation and  discussion with the users, so it's asking them how it's going, and then also  usage statistics gathered from the software itself. So people can say they love it, but if the statistics show they're not really using it, that's going to be, you know, a better glimpse into the real picture of what's happening usually requires several  iterations, as the team uses feedback to decide, you know, to make good  choices. That's why we do small little sprints. And then the team is going to  decide whether to continue in the same direction, or maybe pivot in the direction of a new, minimal viable product. All right, you'll notice in this course, we've  talked a lot about different kinds of triangles. This one is our Quality Triangle for  software development, and so we have quality time and cost and on this Quality  Triangle, so decisions are made during development that affects all three  factors, but only two of these factors can really be addressed that require  compromise or trade off, because you can't compromise all three points of the  triangle. So you can pick two and make changes and compromise without  choosing the three. So if we start on the left there at quality. You're asking  yourself for each one of those iterations of the software, does it meet the  requirements or doesn't it? Is the quality there? Are there minimal bugs? No  bugs? How's it working? We go up to the top of the triangle for time. Do we need to spend more time, or do we need to spend less time on this project? Are we on on our time budget, and then going down to the right we're looking at our  financial budget? Do we need to spend more money or spend less money on  this project? So there needs to be a balance among the three points of the  triangle. Here quality time and cost when we have a software development  again, focusing on two at the most, that you can really make some good  compromises programming languages. If you are familiar with programming  languages, you will know that there are, there are quite a few, and that this is an  area where you don't need to necessarily have a formal degree, formal  education to be able to make a very big impact in the field. If you do have the  skill set of knowing a programming language, there are were used. If you're  going to develop a new system, you would use these languages. And typically  there's multiple generations of a language. So looking here at the arrows, that  first generation, that would be something like machine coding, the zeros and  ones that we were talking about, that binary on and off switches. It's machine  dependent. As we move on to the second era, the second generation is going to be more of an assembly language, some English, like phrases, it is still machine dependent into the third generation, similar to a spoken language. So we're  really noticing some evolution and some maturity in the coding language. It's still machine dependent. This is going to be more of like your JavaScript, and then in the fourth generation here, faster development. It uses developer environments  that help generate the code. So when the developers are more involved in  setting the code, it is machine independent at this point in the fourth generation. 

And the examples of this one would be SQL, that we talked about, that SQL  search language, SQL and SPSS, if you're familiar with that. So that's going to  be that more of the fourth generation, fourth generation, machine independent  programming languages. All right, so when we are talking about software  development decisions, it depends how big your organization is, and it depends  what your goals are, but every new development project should decide whether  to create it themselves, using in house personnel, or whether to buy one that  has already been developed. So here's some if we're going to purchase one that has already been developed for us, there are some advantages and  disadvantages, and here they are. We see that it is less expensive to do it this  way. It's more quickly available. It's already been built. It's already been tested.  The bugs have been worked out. It already exists on the market. The  disadvantages of purchasing software rather than building an in house would be that the same software might be used exactly by your competitors. So if you did  have that competitive advantage of having the narrow focus that we talked  about, or your uniqueness, that might be really compromised here, of  purchasing instead of creating, then there's there's not really customizations that can be done if you're already purchasing a product that exists in the  marketplace, if you build that software yourself, and you use your in house  developers to do that for you, it's going to be completely customized to your  needs. So that's definitely an advantage. It's not going to be used by your  competitors. It's going to be proprietary to you and to your organization. So it's  going to help you keep that competitive advantage and the competitive edge  disadvantages, of course, is that it is more expensive. It's not going to be  available quickly. You're going to have to wait for a complete development  schedule and testing, and the bugs are going to have to get worked out, and it's  not going to be that ready to go off the shelf. Solution. End user computing. So  this is one of those steps right before testing, which we're going to be talking  about next, that others people who aren't in IT develop their own solutions that  aren't trained in programming or software development. This means that there  are programs that exist for let's say you are not you don't have coding  experience, you're not an IT professional, but you still have opportunities here  with this end user computing to go into a program that kind of has some guide  rails on it, even though you don't speak a programming language and you're not  familiar, you're still able to make some of these developments in information  systems. So advantages of doing this development is closer to those that are  actually going to use them. The end users have more input into the development of the information systems and the software, and another advantage is that you  may receive it sooner than. If you were to go through IT channels from the IT  professionals that might have a very full workload doing these iterative designs  that we talked about. Disadvantages, of course, several applications may  perform the same functions. It's a little more clunky. It's not as if you were going 

to design it yourself, it would be much more customized. It's probably not going  to be tested and bug free. It's going to be something that is a little more  cumbersome and it's not always backed up the way it would be if it went through a formal design process with a professional designer, but it's an option. Testing,  this is going to be a critical part of any development. We're going to test it out.  We're going to check for bugs, fix them before the system is implemented,  before it gets rolled out. I currently work for a mobile application, and we have  been live in the app store for about a year, and live in the Google the Android  market for about nine months, and we are still all the time working out bugs,  being able to go through the software and find problems that we can fix before it  goes to a much wider audience. So we look at the different tests available, the  unit test, the system test and the user acceptance test. So again, of course, as  you drill down the unit test is done by the programmers who make it for their  modules alone. Kind of a hard way to test it, though, because you know if you  made it, you understand it. And so a better test would be when we drill down to  the system test. This is done once the individual units are bug free. It's  integrated with other bug bug free models. And now we test it as a whole. So it's not just one programmer testing the thing they made. Now it's the as a whole.  We're going to test the whole thing together. And then the user acceptance test  is going to be the most rigorous of the three, because that's the actual end users are putting it to the test, and we're checking usability. We're checking  functionality, bugs, errors, problems. It's going to get tested and retested. There  we go, until we get it right. So that's the testing phase of software design. So  okay, so let's say we have this product. We've We've tested it, the bugs are  shaken out. How are we going to implement? How are we going to implement?  Is the question of what we've made. So there's several implementation  methodologies that exist, and here's a list of them, the first one being this direct  cutover that you can see this is going to be a new system is turned on, the old  system is turned off. It's a direct it's exactly how it sounds. A direct cutover. It's  the riskiest, but it's the least expensive. Because the reason it's least expensive  is that you don't need to support two systems at the same time. You're just cold  turkey, turning one off, turning the other one on. And the reason it's risky, of  course, is that if there are any problems, you don't have that legacy system in  place to fall back upon. You are committed to the new methodology. The next  one on the list, here you see is the pilot implementation. And this is a small  group is going to use the new system first. It's going to have a smaller impact on the organization if something goes wrong and you still have the old system  running, just in case. So if you if the pilot group does decide, listen, this just  wasn't ready yet. We're still working out too many bugs. You still have the other  one in place for the vast majority of your enterprise or your organization, and it's  just that pilot group that is going to be affected now. It certainly has pros and  cons and the fact that it's going to take a lot longer to roll out something in a 

pirate in a pilot model than it would be to just directly cut over parallel operation  is the third way that we're going to be able to implement this new methodology,  and that's going to be all transactions are entered into the new system and the  

old system simultaneously. Very expensive to maintain two systems, so you  wouldn't want to do this parallel operation for very long, but it's the least risky. So depending on what type of computing you're doing, how sensitive the  information is, if you're prone to how catastrophic would it be if you lost all this  transaction data, this might be what your organization would really need, if it's  very risk averse, or if it needs this type of security, you can identify the bugs and  still go back to the old system if you need to without really risk, like you would in  some of the first the first two. And then finally, we have our. Phased  implementation, and this is our new functions are implemented as parts of the  old functions are turned off. So this is kind of even those people in your  organization who are really dragging their feet and they don't want to do the new methodology, eventually they're not going to have a choice, because the old  things are going to be in phases, turned off, and you're kind of forced to use the  new one until eventually you are you have slowly moved completely from the old system to the new system. I'm sure in your workplaces, you have experienced  one or more of these implementation methodologies as companies have rolled  out new forms of technology to you. I think I have experienced every one of  them. I would say my favorite is probably that pilot implementation group, kind of letting a few go first, see how it goes. You still have a bit more speed, but  severely less, a lot less risk. So I think that is kind of my style in terms of  implementation, but certainly pros and cons for all four methodologies. All right,  so how do we support when we're implementing methodologies, we don't just  say, Okay, guys, here's the new here's the new system. Figure it out and go. Of  course, not every implementation requires support in two key areas, and here  they are. Here on your screen, we have change management and maintenance. So look at the change management one that's going to be all proposed changes should be communicated to all affected personnel, including IT, and IT should be managing which code has been tested and signed off by the end users prior to  implementation. So it really takes the reins on this one and makes sure that  testing is happening the way it should, and that they are managing all parts of  that change over from one system, from the legacy system, to the new system.  The next area where your employers are going to need support is in  maintenance, and often newly implemented systems still need changes for fixing bugs and management needs to ensure that the system continues to run and is  aligned with the business priorities and is still working well in the day to day,  even though we have, you know, our new systems in place. So we have made it to our our summary here, hopefully, as we've gone through the different ways  that we can actually build a system, talked about the coding language,  explaining that the overall process of developing a new software application, you

can kind of talk, talk to that process, the differences between software  development methodologies and then the programming languages that are used to actually develop that software. And then, in some cases, like we talked about, not even having to know a programming language and still being able to  develop software. And then finally, understanding some of those issues  surrounding the development of websites and mobile applications and how  we're actually going to implement them once it is created. So we are coming  back next week for our globalization and the digital divide, and kind of what that  means regionally, when we are, you know, so connected, and what it means  globally to be so connected. We're going to talk through the pros and cons of  that and this digital divide that you may have been hearing about. That is for  some people will tell you it is shrinking. Others will tell you it is growing rapidly,  and we're going to look at the arguments on both sides of that for the digital  divide. So I am really looking forward to seeing you soon. Thank you so much  for your continued hard work and your just open mind to learn these new things,  and I will see you very soon. Thank you.