What is Software Engineering? | Definition of Software Engineering - Information Technology

What is Software Engineering? | Definition of Software Engineering 

Many of us can call it to some capacity whether you're a completely self-taught whether you have went for you know a one-day crash course or boot camp or whether you went for four years at college you know at the end of the day it all seems to be the same it's all coding right so does that mean that any one of us can just go out and be a professional software developer surely that's too easy and as it turns out you're right it's not just like that so what sets apart a hobbyist programmer from a professional developer the answer is software engineering hello and welcome back to another random  what is software engineering well you can think of it as a standardized structured and saira approach to writing code to basically you know treating the whole development process from start to finish in a standardized manner of course the question is why do we want to do things this way why do we want to actually formalize things if you know programming is something you can do sitting at home well there are a couple of reasons why first and foremost we have to be sure that we are building the correct product don't forget now that you're working as a professional developer you're going to have to actually deliver what the customer wants do this so that's one very important point secondly you want to ensure that you're writing code to a certain standard again this is only sort of really useful in a professional environment you know when you're writing code that you expect to maintain over months or years or when you're working together in a team certain conventions certain coding styles now become important and thirdly you want to ensure that your court meets a certain level of rigor and what that means is it needs to be correct it needs to be deficient it needs to be secure and software engineering actually defined some techniques in which you can actually boost

your confidence on these things so yeah in the real world software engineering is a very important skill and that is why today we'll be taking a look at some basics of software engineering we'll be taking a look at you know what it really is how we really go about doing it as well as how it all fits together hopefully with this idea in mind when you actually start off with your software engineering course at school well it makes things slightly easier for you so yeah let's basically be long and short of it let's jump into our first part one software engineering is often you don't sort of mixed up with programming really software engineering starts before any development even begins and we start off by actually understanding what the customer wants first now as a hobbyist programmer we not we don't do this part we just sort of jump in right cool and hopefully you know the inspiration comes to us as we are doing it has again when you're developing in a professional context you can't quite do things that way instead the first thing you need to do is requirements gathering it's interesting how much time is actually devoted to this and it's so important because if you develop the wrong product you've just wasted a whole bunch of time you don't want that you want to make sure that you've actually developed something that is useful and used to be SVS value this sounds simple right so down if your customer asked them what do you want except a lot of the time they don't know what they want either and that's why a very actually many interesting approaches to requirements gathering as well as requirements analysis that gets us to a point where we can write a piece of software that you know will ensure that a customer is satisfied to us such a degree let's take a look at some of these techniques as well as

How they can be useful of course the simplest way to understand your customers requirements is to simply get them to provide a list however there are many shortcomings of doing things this way I mean the list could be very long and yet because it is actually you know structured by them non-programmers it may not be something that is perfectly useful for you so usually it's for the best for you to actually go out and gather your own requirements and here are some ways of doing so about the bulk of the methods involved you know you go into them and seeing what they actually want but there are many structured ways of doing it some examples include surveys interviews and focus groups these are of course as you expect mostly conversational in nature but well at least you're one taking down the notes you are the one directing the whole session so the outcomes will absolutely be more productive alternatively if an existing software suite is already available you can also observe your users actually using them by taking note of the things that used to as well as their pain points you can create a better program for them however what's probably the most interesting of the lots is use case analysis so let's take a look at that use case analysis is a very interesting way of actually expressing you know what a user once because the approach is to actually describe a real usage scenario and we're doing this from the point of view of the user not from you know our point of view SD coder there generally is a pretty specific format for doing this and most notably what we have is a main success scenario expressed as a series of steps remember that there is no jagan here and what this means is well everything is sort of very intuitive very descriptive of what user sees on screen and how they interact with it so what we have here is just a very you know kind of contrived example for a Sales System you know in order to add a sale you want to actually initiate that your program will require you to specify some information namely the name and quantity and when you do supply the information well the information gets start onto the system and that is basically unit from start to finish what's going to happen when you do this this is just access scenario now usually we expand use cases by talking about other kinds of scenarios that could possibly happen for example this would be an error condition if you actually give it a quantity less than 1 how does this software react well in this case it basically gives an error and then returns back to step 2 to wait for the user to you know correct their mistake so as you can imagine a use case could get quite long when there are multiple expansions in addition to this some extra is mentioned we can include our preconditions which you know are the conditions that have to be true before we can actually start with this scenario as well as

The post conditions and that is what will happen at the end of the day in this case we only have a post condition for the main success scenario but that of course is not the only outcome for example if the user closes the dialog box we can have a different post condition as well there is another way of expressing the same thing and that is true user stories now these tend to be less detailed but they really put you in the shoes of the user because well usually user stories I express like this as a statement the same and if it contains three important pieces of information firstly that is you know who this pertains to what they want to do as well as why they want to do that so this last part is something that may be missing from your use case we do all this for the purpose of getting good requirements that we can work with and so the next part is to actually analyze these requirements usually the first step will be to actually generate two kinds of requirements namely functional and non-functional requirements so let's take a look at what this means a functional requirement basically says what we need the system to do right it describes a function of the system conversely a non-functional requirement usually describes a characteristic so these could be say a performance requirement it doesn't actually say what the system needs to do but instead describe something about the process during which that is that once you have all your requirements in order you can then begin to build a prototype now usually prototypes are non-functional it's like I've done prototypes that are just powerpoints light the idea is you're gonna have to pitch that to your customer you know to show them what things look like how everything is laid out how one part of its program actually links to another and basically this gives them a very good view of how things are going to work at the end of the day of course this is the point where you have to go back and forth you know to tweak a prototype to make sure that their users needs I actually be met and only when this part is done you know when requirements are certain can we actually delve into serious development moving on to our second stage planning now to be honest planning to actually sort of runs concurrently with your requirements gathering

Analysis what a whole point of planning is that you now have to start the thinking about how you want to do things in your coming weeks and months it is this is something we tend to not do a lot you know when we are just a hobbyist programmer and we are sort of doing things on an exploratory basis however when we are working with a large project you know tens of thousands of lines of code interacting with each other it would be good to have say a road map or plan of some sort so we know how the different paths actually interact with each other as well as how we're going to approach developing them so yeah the planning process can be quite an in-depth process as well and here are some of the considerations we need to go through during this part one big aspect of planning is actually modularization and that is how they are actually going to break down our large program into smaller parts here's a sample of modularization in action basically we have a game and we've sort of split it out into these components in this particular breakdown we also have sort of the user in the equation and basically you know how modules actually link up to each other that many ways are formally representing this idea but the main point is thought needs to go into how things are going to be compact mentalize so that you know when you build things it's more organized usually during modularization we have two huge goals and that is to achieve high cohesion and low coupling here's what this means firstly Kohi refers to how much the elements within a module actually relate it to each other we can think of this in terms of what the module actually does or what data it works with high cohesion comes about when everything is strongly related so one example I have here is a records module in which well other functions actually involve working with the records either retrieving them unmended releasing them and well that is a highly cohesive module once that has low cohesion is one in which the tasks don't really have anything to do with each other usually we have the temptation to create say a utilities or tools module in which really they are just kind of grouped together because they have nowhere else to go and that is local you should now coupling on the other hand actually views of how modules interact with each other if modules are highly dependent on each other then we can say they are profoundly coupled and one great approach to test this is in the event that we change one module how much effect does that have on another module

How much do we have to actually modify the other module before everything works again in a best case when there is no coupling at all modifying one module does not require modifications to other modules you can just replace it the programs through works so that is our best case usually in situations of low coupling which is the good case two modules only pass messages to each other they don't care about the inner workings of each other and as a result they're not really dependent on each other if you swap out a different module as long as it speaks the same language then everything will work perfectly so going back to our game engine example here is a low coupling situation in which we can test if an enemy has hit the player we start off the game engine checking the position of the player by sending a request to the player module it complies by giving the location back the game engine can then test against the enemy module again to see where that is after getting the information back it can then perform a comparison that you are really colliding then the game engine sends another message to the player module telling it to actually deduct from the help oh yeah this is a situation in which we're just passing messages around and so well there is very little dependence we can easily expand the situation to have multiple players or multiple enemies and things will still work the same we can easily extend the situation to well a case of multiple players even multiple enemies of different types and everything will still work the same way and that's the beauty of setting things up like this high coupling on the other hand is when two modules highly dependent on each other going back again to our game engine example that is when well everything actually shares a game speed variable that is we actually store our sleep somewhere and everyone just talks to that speed object this creates a large amount of dependencies everywhere and yeah basically any modifications is going to confuse everything so yeah please don't do this when we correctly achieve high cohesion and low coupling we achieve what is known as a separation of concerts each module does its own thing it doesn't care about the other modules and this actually increases code readability as well as maintainability if you ever need to go in and fix or upgrade something you know to go just to that one place and you know for sure that you know making changes here firstly will not break anything else and secondly it's the only place you need to modify to be guaranteed that you know things are going to basically change the way you expected to because nowhere else in the code is handling the same task

Great advantages for actually doing things this way especially you know when you're working on a huge project or when you're working in a team and finally only after all this legwork is actually complete can we actually delve into development now get this slightly different from developing as a hobbyist because there are certain structured ways in which you actually go about with the development for example one very common thing in software engineering is what is known as patter now the idea is this generally you know the same kind of problem comes up a lot and so to make things simple we can solve it using a more or less standardized approach this is highly encouraged since it creates code that is more intuitive and easy to read as opposed to you know some creative ways in which you are trying to solve a common problem also if you follow a structured pattern you'll be more confident about its correctness because well again it's a tried and tested thing let's take a look at a common pattern called Model View controller or MVC for short the MVC pattern is particularly significant because of how it applies to fundamentally any program essentially any program that has you know a capacity or rationale components that interacts with a user interface can benefit from using this pattern so here's how it works essentially we start off with a model which as mention contains our data and logic one key point to note is that this model is totally conceptual it is the low-level portrayal of your data as well as the functions required to treat them or retrieve them however your user cannot directly you know look at this model and make any sense out of it instead if you want to show you user the content it needs to go through a view this view knows how to actually you know take the data from the model and present it in whatever way to the user of course right now everything is just one way if the user wants to actually modify the data transfer size they need to Poquette some controls and this allows the user to either change up what they are seeing or make some modifications to the data and be back it

This is how Model View and controller actually links everything together to make things more concrete you know going back to our sales example this may be how everything can be laid out so the information held in our model are the sales records the view for it is to actually display everything in a table for the user to actually interact with the various features we have a bunch of buttons in the sidebar and basically well that is the controller having things in this manner the additional advantage of substitutability and that is perhaps if we don't like the tableview well we can easily replace that with a child notice that in doing things this way we don't actually require any modifications to either the controller or the model you know the model the data stays exactly the same the controller as well doesn't change we are only changing up how we are presenting the same data so yeah when MVC is done correctly substitutability is something reiative similarly perhaps you know the user now is an administrator and we want to give them more tools to work with again all we have to do is to replace the controller the view and a model and not affect it but now the user actually has more controls don't forget of course that now you are number one working in a team number two working on a project that you know may be quite huge and yet needs to be iterated upon over time this is why one huge area of emphasis and software engineering is writing readable code cool that you can actually go back and modify and not have to spend too much time trying to understand what you meant writing the code first type this is why many good practices I actually put into place and if you follow these good practices you can make your code easier to read let's take a look at some of them one very common good practice is to avoid magic numbers and it so happens that I have a very good real-world example to show you basically I've recreated an Arduino project that involves an infrared sensor so when you press buttons on say you know your TV remote controller my project is actually able to pick it up and my code can understand which button is pressed and actually well reacts accordingly however the button pressed is actually read in as some weird numerical code like this it matches if I just left it in my code like that if I came back two months later no way in hell am I going to remember what all these numbers actually represent and yeah this basically is extremely harmful to code readability usually magic numbers are not quite arbitrary this perhaps testing site you know the screen width and height or maybe not just numbers that are preset by the programmer however it would be set just having a number hanging out here isn't good because you don't understand what it means and usually the workaround to this is to actually extract them to a variable or in this case because I'm using C++ I can also use a macro by assigning it to a meaningful need this code becomes much more readable this tells me that this is the previous button or my a very remote control and well that is infinitely more readable than just having a bunch of numbers like this so yeah they call this magic numbers as if the number was magically selected another good practice is variable naming now they're actually a lot of rules for this but the one I find the most useful is just well picking names that make sense for example when you have a function you want to call it something like database that really doesn't say a lot about what this function actually does instead what it's usually preferred for function names are actually verbs something that you know implies that an action will take place for example query database now tells us that okay this function actually hooks into the database

Runs a query so it is a verb it describes an action and that makes things so much clearer similarly for things like boolean variables we want to make sure that well you know when you look at it you know what it needs you know for example is on actually describes a state and this is even more useful when we use it in conjunction with if statements if power is not a statement that makes a lot of sense but we can basically read this one as if we were reading English because well saying if it's on it's very clear right if it's on you know this is true we do something apart from knowing how to code well there are also some tools that you know it will be good if you could get familiar with and one huge example of this our revision control systems you're probably a kind of github get have this a place in which people upload their code through a revision control system what these do is they help you keep track of changes so it can easily jump back and forth between versions at the same time they also help you collaborate with other coders because well everybody can actually commit their code and everything gets much together to create your final product and finally test it again something very different from you know when we actually do our own hobbyist development because well the way we normally test our programs is to just open it up you know randomly click around and if things work then that's all good but again when it comes to software engineering we need to be a little bit more confident than just saying well I sort of poked around in there for five minutes and everything seemed okay usually for larger scale projects what we do is automated testing that's right none of that marketing around you know trying to find bugs by just clicking around instead you use a tool and you basically tell it what to test so it goes from your code function by function and yeah runs a set of test cases on each one of them this is also known as unit testing and it's quite an important part of software engineering

What probably deserves the most emphasis is that testing is not for finding bugs right or actually you know properly testing a system what we are really doing is to check the real world you know what's happening in our program against our expectations so yeah with that in mind we can think about how we can actually perform testing and most commonly we use a technique called unit testing which is automated in nature now let's say we want to test this module we can actually use our testing tool to basically poke at it so for example we can actually you know test a function of it and critically along with that we actually give the expected results then we run the actual module itself you know it gives us back the answer and we can check it against our expectation the two things match all as well you know that the module is actually working the way you're expected to work well not with just one test right if we would actually perform a subsequent test and there is a mismatch in other words the test fails then not only do we know that there is a problem in the module we know exactly you know what sort of operation it fails on and how it violates our actual expectations so for example in this case we could perhaps infer that hey it's actually accidentally adding the two numbers instead of performing a subtraction so yeah usually when we have a bunch of unit tests and we run it and some of them fail it allows us to very quickly pinpoint the error on top of unit testing we also perform what is known as integration testing and this is basically when we use automated testing to test multiple modules instead so instead of testing one module to see if it's working correctly we are now testing to see if multiple modules working together are still doing that job correctly this is quite important because well modules can work correctly individually but if they don't linked in a way that doesn't make sense things could still be broken ed ENFP so it is still very important to actually test the integration between modules going back again to our sales example we can actually attempt to edit a record via the controller and then check to see if the model has changed if it has then it implies that this particular linkage is working correctly so these are testing methods in terms of testing methodologies there are generally two different approaches first there is what is known as black box testing and that is when we treat our module as a black box we don't care what's happening inside it instead we just work with its specifications we just supply it particular inputs expect it to do its magic and ignoring what it does we just check its output and see if that meets our expectations that's black box testing

Alternatively we can also do what it's known as white or glass box testing what we actually care about the internal implementation this can range from crapping out input strategically so that you know they actually exercise the internal implementation to actually delving deep and testing internal use features that may not be exposed when we look at it as a black box so yeah to kind of opposite approaches and both have their pros and cons as well as their values in best case we want to test fourth weeks after so far we're just testing our functions for correctness there are the things we can do as well for example GUI testing where we actually make sure there you know everything that appears specially to the user works the way we expect again the methodology is very similar because well what we are doing is still giving it an action in GUI terms so GOI testing in a real world could involve screen capture and screen reading tools as well as some automated method to generate keystrokes on your program security testing is another one while our basic methods do actually work as well we can also use some randomized methods for example on a login box we can review that lee-san random values to see you know if the system holds up if the system actually doesn't exhibit any flow this is important because when we are doing you know our basic testing we are feeding it values we're actually coming up with values to test however when it comes to you know something like security we have to kind of expect the unexpected to use a very cliche term and that's why using random input can be quite valuable when it comes to testing one metric is called coverage and that is a measure of how much code is actually being tested as your program gets complex you know your code is everywhere it's in functions and loops as an if statement so getting 100% code coverage is very difficult this actually made worse by things like say loops to really thoroughly test your program you have to test to make sure it works correctly when a loop runs once what it runs twice when it runs three times basically every possibility nice be covered and that is close to impossible similarly if your program actually has some kind of state you need to make sure that things are working correctly regardless of whatever speed your program is in and again that is very difficult especially when you know programs have many possible different speeds despite that across the Greater code coverage you have the better and in fact some programming methodologies completely surround the concept of testing and one example of this is test-driven development or TDD as its name implies TDD

Surrounds writing tests first so in fact before you actually write code you write your tests you wash your tests fail and then you basically fix the billing test you write just enough code to fix the test no more no less to continue you're going to have to write another test and basically you rinse and repeat and this is one way in which you know your program can get very good coverage and then go today we're taking a look at our four general phases of software engineering now it's important to note that you know even though we lay it out as sort of phase 1 phase 2 phase 3 and so on it's not really he'll completely separate a lot of the time these phases may overlap and insight sometimes become completely concurrent so that's an important thing to think about also what we've seen here is one cycle sort of the development process from start to finish except usually development doesn't really end there you know when you're done with your product your customer is happy you deploy it chances are after a while they might ask you for certain improvements and enhancements and then that fixes and basically the whole process starts again because again you have to ask them what do you want you don't go ahead and plan how to do it prototype it and then test it so it's the entire cycle all over again and for you know larger scale projects this could basically go on and on continuously now today as barely scrape the surface of software engineering as a subject really these are things that people go on you know for university causes to learn so there is certain knowing...