So, what is software engineering anyway? So, I'm going to play back a little video about software engineering. >> My name is Chris County Corban. I worked at Apple on IOS. What is software engineering. We've got four pictures of things here. We have a world of Warcraft. We have Call of Duty 4, airplane, and we have the New York stock exchange. But what do they all have in common? So hopefully it will be too much of a reach to think that all of them have a code in common and a lot of it. Just for a little bit of a frame of reference. Boeing 747 has more lines of code than it does parts including nuts and bolts. I was really blown away by when I heard this. How much lines of code? Specifically, a Boeing 747 has 4 million lines of code in it. And most games that you play today have about 6 million lines of code. And just for reference. So, these are really huge software systems that really can't be thought of as one line or one class at a time. The software engineer needs to think about the design of different levels, from one line of code all the way up to the entire system. So, let's think about scheduling that for just a moment. If I can write one source line of code per minute, there's 60 minutes in an hour and there's 40 hours an average work week. That gives me 2400 source lines of code per week per software engineer. We take that, we multiply that by the usual 50 work weeks per year. That means every software engineer can crank out 120,000 source lines of code per year. Pulling that all together, I have two million lines of code estimated in a project. With the amount of code I can crank out from each engineer, I need the very least 17 software engineers to get this on the software shelves for the holiday season. You get a feeling that these things need to be planned out a lot. And also that you have to work in teams. Then, also writing one line of code per minute on average believe it or not is actually pretty hot shot in the software industry. And actually it really is, mainly because so much of your job as a software engineer is so much more than coding. Let's talk about one company may have heard about amazon.com. It's one website. It's relatively large and pretty complex. Software team was going to go to one small software upgrade pretty easy. But the upgrade didn't go out so hot and it caused a 90 minute outage. So, is that priceless? Not exactly. Estimated to cost amazon was $2.8 million dollars in lost. That's not just revenue that they they lost from customers, where they could have come back later and bought this product later. Now, this is actually $2.8 million Amazon lost because the website was down. The customer needed something then, and they lost that $2.8 million. So, somebody got fired. The system wasn't safety critical but it is financial critical. So, this team needed a better understanding of the process for developing a critical system. And how to bring an upgrade online without taking down the system. In this case, Amazon would have benefited from a better defined software development process. As a software engineer, you have to answer a lot of questions. One question, is how much code you have to write. But there are a lot of other questions that remain to. How can I help the customer? What's required to solve the customer's problem? How will the user interact with the system? What operating system, language, hardware is going to be used? What is the overall software system structure and how do different components interact with each other? How do I organize my team? So, we're all effective. And can we finish the game and time to have it on shelves for holiday shopping? The real common trend here, is that you have to talk to a lot of people to make this happen. You have to interact with customers who are asking for the system, people who will use the system, domain experts, banking, avionics, security, medical scientists, engineers from other engineering disciplines. And even most closely with other engineers on the project. Another big underlying theme here is communication. Software engineering is a very social activity. You don't sit in a cube and write code in a corner, you're always working with people and it's a very people driven field. But that doesn't mean that software engineers don't get their hands dirty writing programs, using the latest technologies and techniques we live and breathe that as well. And also, it's important to note that it's not just project management and communication. But it's also not about coding either. By now you might be seeing that software engineering doesn't exactly equal CS. Both majors try to solve real world problems using code, but how they go about that is very different. So, for example, if a bridge falls down, is a scientist or engineer. Well, not so much the scientists, more the engineer. Scientists build things to learn something new. And engineers learned things to design and build quality products. Scientists want to achieve scientific breakthroughs. Engineers want to avoid engineering failures. Computer scientists want to understand the algorithm, and the foundations of computing theory. Whereas software engineers want to learn and design the principles of best practices for building quality software system. And lastly, computer scientists want to know the basic technology works and how to improve it. While software engineers, want to know the characteristics of technology so they can design the most appropriate technology into their software system. >> So, what is software engineering? If you take a look at Wikipedia or some references online, you're going to get different definitions. So, notice that software engineering is a disciplined development method. So, that means we try to develop something in a disciplined way instead of like your programming assignment, right? You simply open up the source code and then type in something, it's that hard. Okay, Iit's not disciplined. Okay. So, that's why software engineering and we are talking about something disciplined, okay. And then it requires some built in quality. So, we try to achieve some quality in the final product. And try to solve some real user problem, okay. In some application domain. And then it requires a team effort because you have to work in a team. And finally it's going to be multi-version. Okay, it's not one off. Okay, unlike again, unlike your programming assignment is one off. Okay, in software engineering or in a large software project, it's not going to be just one off. So, that's why we need software configuration management to keep track different versions of the software that we have developed. So, software engineering involves a modeling activity. So, we have to capture all the use of requirements and then we have to build a model. And there are two models that we have to build. One, is what we call the requirements model. We try to capture all the requirements from our users or from our client. Okay, then we have to build a solution model which is the actual model that we're going to use for implementation. Okay. And then we have to match the requirement model with the solution model. And it's a problem solving activity. We try to look for the most appropriate solution in the presence of change. And that's why it's not algorithmic, it's systematic. And it's a low range acquisition activity. Notice that this lollipop acquisition activity is not a linear process. You learn while you're developing the project. And sometimes you may have to unlearn because you have learned something wrong, okay. And in the worst case, you may even have to need to start over again because you are totally wrong. Then you have to start again, okay. And it's a rationale management activity because our assumptions and solutions may change from time to time because of bugs or technology. And we may need to revisit decisions from time to time. And that's why it's important that we document all the things within the project. Because it's important to remember why we make the decisions or why we make this choice. And we can remember all the decisions and all the choices that we have made in the project, within the documentation that we have in the project. So, that's why it's important that we document everything within the project. So, these are what we have covered in this lecture to deal with the software development complexity. We have to choose the most appropriate design goals, usually two or three of them at the very beginning of the project. And then we try to utilize modularity and also incremental development techniques. That means we try to chunk the large software systems into many smaller pieces and then we try to handle a small piece at a time. And also we have to use effective software engineering techniques. From a technical point of view, there are two things that we have to do within a software engineering project. First thing, is software engineering. That means we have to build models, we have to document the system, and keep all the requirements and all the solutions that we have come up with within the project. And this is what we mean by programming in the large. And also, another thing that we have to do is of course coding. Okay, building the system and this is what we mean by programming in the small, coding. And notice that, while coding is an important software development activity. Software engineering is also essential because it's going to help reduce the complexity of the project. And eventually helps achieve higher quality and also more maintainable software systems. And that's all I want to cover in this lecture.
