Overview of Software Engineering Principles

I am Dr. Bharati, Professor from the Department of Computer Science and Engineering, Satyabhama Institute of Science and Technology, deemed to be university. This session is going to be an introduction to the world software engineering. Let us start the discussion by understanding about the word software engineering and have a bird's eye view on the various phases of software engineering. Every engineering student learns coding by little practice. Every one engineering student becomes a programmer. But what differentiates a simple programmer simple programmer from a professional software engineer. To back my words, I have the words of Bill Gates, software is a great combination of artistry and engineering. Yes, we will start the discussion with the details about what is engineering. Engineering is a field of science and technology which makes you understand how to build machines, structures and technology in the most optimized and organized way. Then how software is called software engineering? Yes, software engineering is also a field which involves lot of optimization techniques because we build a software for a daily purpose of the human beings. So what is a software? Software is nothing but set of programs. But what differentiates a program from a software? Ideally a program's size is from 50 lines to 500 lines of code. Any set of programs which run more than this complexity or is meant for a customized purpose is called a software. So software is nothing but collection of programs, data structures and documents. So when I build a software involving number of people, money, time and so on, yes I need some engineering techniques also to be applied to it. So there are number of types of software that we build day in and day out as software professionals. One is system software, a software which helps you to talk to your computer at home, talk the hardware at home so examples of the system software can be your operating system your compilers interpreters etc we have real-time software which is used to analyze control and monitor the real world activities every one of us have a smartphone and you can call it as a real world software business software is a customized software for a particular business number of companies run their own erp softwares and crm softwares which are examples of this business software Engineering and scientific software purposely done for the algorithm crunching and number crunching purpose. Then we have the embedded software which is now available as tidbits, smart technology all over the world. Embedded software has now become a part and parcel of our life. Then comes the artificial intelligence software where we try to install the capabilities of a human being in a computer. Now an example for an artificial intelligence software is the computer. artificial software can be as simple as your video programming. So when software plays so much of importance in your daily life, every one of us start of the day and end our day with number of applications across in our smartphones, in your laptops, right from booking our train tickets or cinema tickets or even working in your college or office or everywhere, we need to build a software involving lot of human and other resources. So when so many resources are put in we need some engineering techniques which have to be applied to it software engineering plays a major role in this so what is software engineering by definition the application of systematic disciplined quantifiable approach in the development of software is called software engineering yes in software engineering once we get a problem from the customer we will try and understand where to start what to do to get to the solution and when do i say that i've got the solution and when do i give it to my customer with this whole satisfaction so i have a guideline which will tell me where to start how to understand the problem falling into the shoes of the customer and what are my steps of development and how do i end yes this are divided into various phase of software engineering first comes requirements gathering and analysis planning and getting the specifications designing development of the software testing your software and maintaining your software which is more important. The essence of the practice was perfectly given by Polya. He says it's very important to understand the problem but how do we understand the problem? Communicate to the customer the way he wants, analyze the input from the shoes of the customer, understand the problem better so that you start giving the best solution. Then number two, plan a solution for your software. Now this involves both modeling the software and also bringing out the perfect software design then is the carrying out of the problem which i mean doing your programming or your coding but following the best practices of the industry and last is the examining of the result and making the software work in your customers place which we call as testing and maintenance. So step one is understanding the problem which we call as the requirements gathering and analysis. But why is requirements gathering so important? You know requirements gathering is given the name requirements engineering the more you understand the problem the better solutions you get so understanding the problem involves lots of practices like just listing out all the requirements of the customer or doing a survey on the field or doing an interview with the customer talking to focus groups and doing observations of the industry and finally a use case analysis which is the current status of requirements gathering so if i am given a software to be be built for a medical application. When I know nothing about medical application, yes, I have to sit and talk to my customer to understand the problem and understand the requirements in his own terms. If I don't understand the problem in his own terms, I tend to give a solution that he may not be bothered. When I involve so much of money and cost, it is more important they understand the problem the better. The software's gathering itself uses 40% of the software's life cycle time. If you say a project dwells for a period of 12 months, then you spend more than 5 months understanding the problem and getting your requirements right. But what can be the major problem in requirements gathering? It's because the customer himself may not understand what is this requirement. He may come in with a new requirement day in and day out and you cannot turn him down. You have to take up every requirement and then try to accommodate it in your plan and do it as the deployment. This gives you a lot of options. case analysis which is the latest requirements gathering algorithm or the requirements gathering methodology is working on various scenarios of the problem. If I am asked to develop an application for a bank and an ATM application for a bank then I have to put on the shoes of the customer and try to find out what are the various situations which can happen. I can go to an ATM either for a deposit or for drawing money. When I draw money I may use the right password with the right card or I may have a wrong password for the right card so you have to think like the customer and write your program code to accommodate all these different scenarios that the customer will come across next comes requirements analysis where you try and analyze the various requirements given by your customer from your customers in your customer say for example we are working on a college software your customer can come and tell me see i want to collect all the details of my students and store it in a place and whenever Whenever I want, I want to use it. So what do you do? How do you convert this analysis into a specification? You have to write a form. You have to create a form where you collect the details. Say for example, the bio data of the students. And when you press the button of submit, it has to be stored in your database. So this is how you convert the unformalized requirements of your customer into formalized statements. So this is how you convert your requirements into a specification. So then. it comes to requirements i can classify my requirements into functional requirements and non-functional requirements so what is functional requirements something that the system should definitely do is called as a functional requirement say for example in my student information system i want the data to be collected to be manipulated and to be stored this is something the customer definitely wants okay and this is written in your specific document so this is called functional requirements what the system has to do what is non-functional requirements the quality characteristics of the customer of the system is called as the non-functional requirements say for example the customer places a query and he wants a result within two seconds this we technically call the response time so the customer wants the response time to be within two seconds so this is a non-functional requirement which is a quality attribute and also the performance of the system. Say the customer told you he will have thousand users to be using the system at a time, but you give him provisions of 10,000 users using the system at a time, is a non-functional requirement. You are improving the performance, you are improving the throughput. So when you do your requirements gathering, it does not stop with just understanding the problem and doing what the customer wants and also thinking aloud of what other non-functional requirements can be added to your system to make the system better. work then comes planning the solution yes i have understood what the customer wants what do i do next now i have to plan the entire timing of my project of what do i do next when do i go to my specifications place what type of a design do I do who will be the people involved in each phase of my problem and what kind of a technology am I going to use is my company or do I have an infrastructure to accommodate this technology do I do testing at what time what type of testing and so on so this is called as planning for the solution now when i plan i will not break my head taking the entire problem as such with the most important keyword that comes into play is called as modularization when you have a big problem in hand and when you want to solve the problem break it into smaller sub problems try finding out the solutions for smaller sub problems and then integrate it in them to a big problem so modular Modularization is dividing or splitting your bigger problem into smaller problem. But how do I split? Do I split it as such? No. When I split, I should make sure that does that does not disturb the functionality of my project. And each of the module that I have divided is independent in working. Now, when do we do this modularization? And when do we start designing a problem? We keep two important keywords in mind. One is called. called as cohesion and the other one is called as coupling. So what is cohesion? Cohesion tries to tell you how are the elements binded in your problem. An example, if I have to write a project in which a small program involves doing the mathematical functions on any two given numbers simply to be adding, subtraction, division, multiplication, do I put all these sub problems as a part of a main program or do I put them different different programs? If I put them as one program with subroutines, the functionality that works will be better. And if I have to make changes at a later date, changing will also be easier because I have to concentrate on one program. So if my program or if my project has more of such tightly bounded components, then the program tends to have less amount of errors. Two, most important now the keyword is called as coupling. So what is coupling? is this coupling what is the degree of dependence in your program is called as coupling so what do you call as degree of dependence when there are two or three programs which are supposed to send and receive data you try to put them together because people from different different places if they start talking it becomes a disturbance for the entire working so you put all those small programs which try to interlink or which try to collaborate very often into one module which improves cohesion and reduces coupling for a good program or for a good project it is very important to have high cohesion and a very low coupling that's the planning stop here no I do two types of design one is called as the architectural design and the other one is called as the detailed design architectural diagram design I can simply say when you start constructing your house what do you first think you first think about whether your house is going to be a single floor building or a double floor building or a triple floor building building or what kind of an architecture is going to follow whether you're going to have a doom structure on top or something so this outer baseline is first done and then you try to do your detailed design of where to put my living room my bedroom my bathroom and so on so that it allows me to freely communicate or freely move around my house the same is the best analogy for a software design too when i say architectural design i try to understand whether my software is going to work as in the internet as a real world software or whether it is going to talk to another hardware as an embedded software or whether it is going to follow some other architecture like a distributed system or so on. Once I decide on it then I go for the detailed design where comes these words of cohesion, coupling, modularization everything. So once my design is over I want to do a model. Here we call this as the prototyping. You create a model of your original software. and show it to your customer now if it's a civil problem if it's a building construction you make out a model which is called as a blueprint or you make a thermocool structure and then show it to your customer your customer says yes i'm happy no i want my changes but how do you do a prototyping in a software in software prototyping is nothing but creating dummy forms and showing the transition from one form to the other through your customer based on the way he gave you the requirements. Say for example He wants to take up the Pyrrha data, calculate the marks and then store it somewhere. You show him how you do it, form 1, form 2 and form 3. Your submit button, your next button, your delete button will not have a complete functionality except for transitioning from one form to the other. form so that becomes your prototyping you show this prototype to your customer your customer says yes you go on if he says no I want some more you make all those additional changes and then you go on next is carrying out the plan so what do you mean by carrying out the plan doing it as coding now when you code the industry has number of coding practices and standards it is mandatory that we follow those standard practices of coding and then use them in our software so what do you call as coding standards these are nothing but some rules and guidelines which tell you how to write a decent code example remove number of go to statements don't use go to statements don't use nested if a lot of nested ifs don't do complex calling and returning, complex parsing of data structures and so on. Also, when you name your program, name your subroutines, you also have number of naming practices to keep in mind. So, when your software is developed with these coding standards and naming practices, it is very easy for the customer to understand the problem and also deploy the problem in the customer's place. The last comes examining the result. Now, this involves both steps. testing and maintenance. So what is testing? You run the software again and again with an intention to find errors. The more errors you find out, the less complexities it will end up in the customer's place. So you try to find out the errors in your problem, which is called as bug fixing when you do your testing. Now testing has a number of terminologies and involved in it. We call it as unit testing and integration testing when it comes to levels of testing. Unit testing is the testing of the software. Unit testing is the testing is testing the most simplest part or the simplest unit of your software integration testing is when you put these individual tested units together you want to find out whether they communicate and collaborate in the way they have to there are certain places where you put these units in the wrong combination and they don't work so you make sure that they are integrated properly and the integrated software also works the way you want so to quickly say unit testing is the unit that you is designed which can be very smallest subroutine or a sub program and integration testing starts from putting two three units together and builds up on to the entire software then comes two important terms which is called white box testing and black box testing in black box testing we will be able to give some set of inputs to your software and you assume your software to be an opaque box which doesn't operate operation and gives you the output that you want. You will not have an understanding of how this input becomes an output. You only know a predicted output and you wait for the box to give you the required output. This is called validating a program. In white box testing you will be able to see the entire flow of your program and verify each and every line of code which is written in your program to give you the end result. To give you a very simple example, if I write a small program to add two given integers if I check whether my coding is right if I check whether I have placed my a plus B perfectly then I am doing my white box testing which is verification of my code but if I give two numbers two and two and check whether it gives me four which is the summation or if I give two and three and check whether I get the summation as five and not six then I do a validation which is a black box testing I am not bothered about what happens inside I expect only the output that I want so the entire software industry is now follows something called test driven development so what is test driven development yes you do unit testing integration testing white box testing black box testing but you make sure that you cover the entire code yours of your software perfectly tested so this is called as code coverage testing in abstracted terms it's called test driven development after this testing do I give my software as it is to my customer? No. The responsibility of the software developer do not stop just after testing. When the customer accepts after acceptance testing it is responsibility of the industry to go deploy the software in the customers place, make sure it works, make whatever adaptations that the customer wants deployed and also help the customer in initially using the software. And the maintenance extends as long as the as the life of the software extends at the customer's place. So these are the various important phases of software engineering. To summarize, we understand that building a software is also a complex task which needs lot of planning and engineering steps to be involved. So we have engineering steps involved as different phases of our software engineering. We start with understanding the problem, making out the best plan, best design, doing coding with standard practices, testing and maintaining the software at the customer's place. To sum up, I would say programmers and developers need to become software engineers. Think of a solution, then technology to implement it. Think of abstractions and then code it. So if you don't understand, you don't end up with the best result. So this session was a simple bird's eye view on what software engineering is. In the subsequent sessions we will have a detailing on each phase and also try and understand the various nuances of each and every phase of software engineering.

Every engineering student learns coding by little practice. Every one engineering student becomes a programmer. But what differentiates a simple programmer simple programmer from a professional software engineer.

To back my words, I have the words of Bill Gates, software is a great combination of artistry and engineering. Yes, we will start the discussion with the details about what is engineering. Engineering is a field of science and technology which makes you understand how to build machines, structures and technology in the most optimized and organized way. Then how software is called software engineering?

Yes, software engineering is also a field which involves lot of optimization techniques because we build a software for a daily purpose of the human beings. So what is a software? Software is nothing but set of programs. But what differentiates a program from a software? Ideally a program's size is from 50 lines to 500 lines of code.

Any set of programs which run more than this complexity or is meant for a customized purpose is called a software. So software is nothing but collection of programs, data structures and documents. So when I build a software involving number of people, money, time and so on, yes I need some engineering techniques also to be applied to it. So there are number of types of software that we build day in and day out as software professionals.

One is system software, a software which helps you to talk to your computer at home, talk the hardware at home so examples of the system software can be your operating system your compilers interpreters etc we have real-time software which is used to analyze control and monitor the real world activities every one of us have a smartphone and you can call it as a real world software business software is a customized software for a particular business number of companies run their own erp softwares and crm softwares which are examples of this business software Engineering and scientific software purposely done for the algorithm crunching and number crunching purpose. Then we have the embedded software which is now available as tidbits, smart technology all over the world. Embedded software has now become a part and parcel of our life.

Then comes the artificial intelligence software where we try to install the capabilities of a human being in a computer. Now an example for an artificial intelligence software is the computer. artificial software can be as simple as your video programming. So when software plays so much of importance in your daily life, every one of us start of the day and end our day with number of applications across in our smartphones, in your laptops, right from booking our train tickets or cinema tickets or even working in your college or office or everywhere, we need to build a software involving lot of human and other resources.

So when so many resources are put in we need some engineering techniques which have to be applied to it software engineering plays a major role in this so what is software engineering by definition the application of systematic disciplined quantifiable approach in the development of software is called software engineering yes in software engineering once we get a problem from the customer we will try and understand where to start what to do to get to the solution and when do i say that i've got the solution and when do i give it to my customer with this whole satisfaction so i have a guideline which will tell me where to start how to understand the problem falling into the shoes of the customer and what are my steps of development and how do i end yes this are divided into various phase of software engineering first comes requirements gathering and analysis planning and getting the specifications designing development of the software testing your software and maintaining your software which is more important. The essence of the practice was perfectly given by Polya. He says it's very important to understand the problem but how do we understand the problem?

Communicate to the customer the way he wants, analyze the input from the shoes of the customer, understand the problem better so that you start giving the best solution. Then number two, plan a solution for your software. Now this involves both modeling the software and also bringing out the perfect software design then is the carrying out of the problem which i mean doing your programming or your coding but following the best practices of the industry and last is the examining of the result and making the software work in your customers place which we call as testing and maintenance.

So step one is understanding the problem which we call as the requirements gathering and analysis. But why is requirements gathering so important? You know requirements gathering is given the name requirements engineering the more you understand the problem the better solutions you get so understanding the problem involves lots of practices like just listing out all the requirements of the customer or doing a survey on the field or doing an interview with the customer talking to focus groups and doing observations of the industry and finally a use case analysis which is the current status of requirements gathering so if i am given a software to be be built for a medical application.

When I know nothing about medical application, yes, I have to sit and talk to my customer to understand the problem and understand the requirements in his own terms. If I don't understand the problem in his own terms, I tend to give a solution that he may not be bothered. When I involve so much of money and cost, it is more important they understand the problem the better. The software's gathering itself uses 40% of the software's life cycle time.

If you say a project dwells for a period of 12 months, then you spend more than 5 months understanding the problem and getting your requirements right. But what can be the major problem in requirements gathering? It's because the customer himself may not understand what is this requirement. He may come in with a new requirement day in and day out and you cannot turn him down. You have to take up every requirement and then try to accommodate it in your plan and do it as the deployment.

This gives you a lot of options. case analysis which is the latest requirements gathering algorithm or the requirements gathering methodology is working on various scenarios of the problem. If I am asked to develop an application for a bank and an ATM application for a bank then I have to put on the shoes of the customer and try to find out what are the various situations which can happen.

I can go to an ATM either for a deposit or for drawing money. When I draw money I may use the right password with the right card or I may have a wrong password for the right card so you have to think like the customer and write your program code to accommodate all these different scenarios that the customer will come across next comes requirements analysis where you try and analyze the various requirements given by your customer from your customers in your customer say for example we are working on a college software your customer can come and tell me see i want to collect all the details of my students and store it in a place and whenever Whenever I want, I want to use it. So what do you do?

How do you convert this analysis into a specification? You have to write a form. You have to create a form where you collect the details.

Say for example, the bio data of the students. And when you press the button of submit, it has to be stored in your database. So this is how you convert the unformalized requirements of your customer into formalized statements.

So this is how you convert your requirements into a specification. So then. it comes to requirements i can classify my requirements into functional requirements and non-functional requirements so what is functional requirements something that the system should definitely do is called as a functional requirement say for example in my student information system i want the data to be collected to be manipulated and to be stored this is something the customer definitely wants okay and this is written in your specific document so this is called functional requirements what the system has to do what is non-functional requirements the quality characteristics of the customer of the system is called as the non-functional requirements say for example the customer places a query and he wants a result within two seconds this we technically call the response time so the customer wants the response time to be within two seconds so this is a non-functional requirement which is a quality attribute and also the performance of the system. Say the customer told you he will have thousand users to be using the system at a time, but you give him provisions of 10,000 users using the system at a time, is a non-functional requirement.

You are improving the performance, you are improving the throughput. So when you do your requirements gathering, it does not stop with just understanding the problem and doing what the customer wants and also thinking aloud of what other non-functional requirements can be added to your system to make the system better. work then comes planning the solution yes i have understood what the customer wants what do i do next now i have to plan the entire timing of my project of what do i do next when do i go to my specifications place what type of a design do I do who will be the people involved in each phase of my problem and what kind of a technology am I going to use is my company or do I have an infrastructure to accommodate this technology do I do testing at what time what type of testing and so on so this is called as planning for the solution now when i plan i will not break my head taking the entire problem as such with the most important keyword that comes into play is called as modularization when you have a big problem in hand and when you want to solve the problem break it into smaller sub problems try finding out the solutions for smaller sub problems and then integrate it in them to a big problem so modular Modularization is dividing or splitting your bigger problem into smaller problem.

But how do I split? Do I split it as such? No.

When I split, I should make sure that does that does not disturb the functionality of my project. And each of the module that I have divided is independent in working. Now, when do we do this modularization? And when do we start designing a problem? We keep two important keywords in mind.

One is called. called as cohesion and the other one is called as coupling. So what is cohesion? Cohesion tries to tell you how are the elements binded in your problem. An example, if I have to write a project in which a small program involves doing the mathematical functions on any two given numbers simply to be adding, subtraction, division, multiplication, do I put all these sub problems as a part of a main program or do I put them different different programs?

If I put them as one program with subroutines, the functionality that works will be better. And if I have to make changes at a later date, changing will also be easier because I have to concentrate on one program. So if my program or if my project has more of such tightly bounded components, then the program tends to have less amount of errors. Two, most important now the keyword is called as coupling. So what is coupling?

is this coupling what is the degree of dependence in your program is called as coupling so what do you call as degree of dependence when there are two or three programs which are supposed to send and receive data you try to put them together because people from different different places if they start talking it becomes a disturbance for the entire working so you put all those small programs which try to interlink or which try to collaborate very often into one module which improves cohesion and reduces coupling for a good program or for a good project it is very important to have high cohesion and a very low coupling that's the planning stop here no I do two types of design one is called as the architectural design and the other one is called as the detailed design architectural diagram design I can simply say when you start constructing your house what do you first think you first think about whether your house is going to be a single floor building or a double floor building or a triple floor building building or what kind of an architecture is going to follow whether you're going to have a doom structure on top or something so this outer baseline is first done and then you try to do your detailed design of where to put my living room my bedroom my bathroom and so on so that it allows me to freely communicate or freely move around my house the same is the best analogy for a software design too when i say architectural design i try to understand whether my software is going to work as in the internet as a real world software or whether it is going to talk to another hardware as an embedded software or whether it is going to follow some other architecture like a distributed system or so on. Once I decide on it then I go for the detailed design where comes these words of cohesion, coupling, modularization everything. So once my design is over I want to do a model.

Here we call this as the prototyping. You create a model of your original software. and show it to your customer now if it's a civil problem if it's a building construction you make out a model which is called as a blueprint or you make a thermocool structure and then show it to your customer your customer says yes i'm happy no i want my changes but how do you do a prototyping in a software in software prototyping is nothing but creating dummy forms and showing the transition from one form to the other through your customer based on the way he gave you the requirements.

Say for example He wants to take up the Pyrrha data, calculate the marks and then store it somewhere. You show him how you do it, form 1, form 2 and form 3. Your submit button, your next button, your delete button will not have a complete functionality except for transitioning from one form to the other. form so that becomes your prototyping you show this prototype to your customer your customer says yes you go on if he says no I want some more you make all those additional changes and then you go on next is carrying out the plan so what do you mean by carrying out the plan doing it as coding now when you code the industry has number of coding practices and standards it is mandatory that we follow those standard practices of coding and then use them in our software so what do you call as coding standards these are nothing but some rules and guidelines which tell you how to write a decent code example remove number of go to statements don't use go to statements don't use nested if a lot of nested ifs don't do complex calling and returning, complex parsing of data structures and so on.

Also, when you name your program, name your subroutines, you also have number of naming practices to keep in mind. So, when your software is developed with these coding standards and naming practices, it is very easy for the customer to understand the problem and also deploy the problem in the customer's place. The last comes examining the result. Now, this involves both steps.

testing and maintenance. So what is testing? You run the software again and again with an intention to find errors.

The more errors you find out, the less complexities it will end up in the customer's place. So you try to find out the errors in your problem, which is called as bug fixing when you do your testing. Now testing has a number of terminologies and involved in it. We call it as unit testing and integration testing when it comes to levels of testing.

Unit testing is the testing of the software. Unit testing is the testing is testing the most simplest part or the simplest unit of your software integration testing is when you put these individual tested units together you want to find out whether they communicate and collaborate in the way they have to there are certain places where you put these units in the wrong combination and they don't work so you make sure that they are integrated properly and the integrated software also works the way you want so to quickly say unit testing is the unit that you is designed which can be very smallest subroutine or a sub program and integration testing starts from putting two three units together and builds up on to the entire software then comes two important terms which is called white box testing and black box testing in black box testing we will be able to give some set of inputs to your software and you assume your software to be an opaque box which doesn't operate operation and gives you the output that you want. You will not have an understanding of how this input becomes an output.

You only know a predicted output and you wait for the box to give you the required output. This is called validating a program. In white box testing you will be able to see the entire flow of your program and verify each and every line of code which is written in your program to give you the end result.

To give you a very simple example, if I write a small program to add two given integers if I check whether my coding is right if I check whether I have placed my a plus B perfectly then I am doing my white box testing which is verification of my code but if I give two numbers two and two and check whether it gives me four which is the summation or if I give two and three and check whether I get the summation as five and not six then I do a validation which is a black box testing I am not bothered about what happens inside I expect only the output that I want so the entire software industry is now follows something called test driven development so what is test driven development yes you do unit testing integration testing white box testing black box testing but you make sure that you cover the entire code yours of your software perfectly tested so this is called as code coverage testing in abstracted terms it's called test driven development after this testing do I give my software as it is to my customer? No. The responsibility of the software developer do not stop just after testing.

When the customer accepts after acceptance testing it is responsibility of the industry to go deploy the software in the customers place, make sure it works, make whatever adaptations that the customer wants deployed and also help the customer in initially using the software. And the maintenance extends as long as the as the life of the software extends at the customer's place. So these are the various important phases of software engineering.

To summarize, we understand that building a software is also a complex task which needs lot of planning and engineering steps to be involved. So we have engineering steps involved as different phases of our software engineering. We start with understanding the problem, making out the best plan, best design, doing coding with standard practices, testing and maintaining the software at the customer's place. To sum up, I would say programmers and developers need to become software engineers.

Think of a solution, then technology to implement it. Think of abstractions and then code it. So if you don't understand, you don't end up with the best result. So this session was a simple bird's eye view on what software engineering is.

In the subsequent sessions we will have a detailing on each phase and also try and understand the various nuances of each and every phase of software engineering.

Transcript for:Overview of Software Engineering Principles

Transcript for:
Overview of Software Engineering Principles