 Welcome to this course on computer programming. In this session, we are going to discuss some basic principles of software engineering. You will recall that we have seen different categories of software such as system software, application software, embedded software, and web applications, etcetera. We have noted that practical software is always rather large and is complex. It requires significant efforts to design, build and operate such software and to maintain such software. First, let me comment on the size of software and the corresponding efforts required to design and build such software. Software size is often expressed in one of the two forms. The first measure, lines of code, this is the number of lines of your C plus plus programs for example, or L O C is one measure of the size. Larger the number of lines, longer should it take for human beings to construct such software. Another and more popular measure of the software size is function points. These are actually points which define different functionalities and based on the complexity of these functions, you can together conclude that this software is either more complex or less complex. The size of the software obviously increases if it has a large number of function points to be implemented. Here are typical nomenclature associated with different categories based on the lines of code as the size measure. For example, 100 to 1000 lines of code would be regarded as tiny software, up to 10000 lines of code could be regarded as small software, up to 100000 lines of code could be regarded as medium software. Software which is considered large is actually more than 100000 lines of code, often extending up to 1 million. Very large software is categorized by size of the order of 10 million and of course, there are a very few rare systems which are called huge because they comprise of more than 10 million lines of code. Now, in order to build such software of different size, you would need to estimate how many people are required to build that software. People's effort are often expressed in terms of person months. A person month is usually how much one person working full time for a month can develop and deliver. Please note that it is not just the count of lines of code that one can write in a month. That way, I know many of you can write even 500 lines of code in a single day. Here for measuring the productivity, we are talking about total number of tested, documented and working lines of code. So, it involves a huge lot of effort ordinarily. While the productivity of individuals differ it is considered adequate if a person, a professional programmer can produce 15 to 25 lines of code per day. This is a useful indicator. Many of you think that this is a very small productivity. It is not if you consider that every line of code is part of a piece of software delivered which is completely tested, documented and is working perfectly. We now come to the concept of engineering this software. First of all, we remember that software is not manufactured like other artifacts. It is developed or is engineered. Hardware which is also engineered and often manufactured actually wears out, but the software does not wear out. In fact, it will continue to function till eternity if the supporting hardware is available. However, the software may become unmentainable. That means it grows to such a big size that to modify it to add functionality becomes practically impossible in terms of the time and effort required. It is at this juncture that you will replace this software by some other software that you would develop. Now, if software is to be developed or engineered, let us understand what engineering is. This is a traditional definition of engineering. It is the analysis, design, construction, verification and management of technical entities or even social entity. The well-accepted definition of engineering and it tells you exactly what are the activities involved in carrying out any engineering activity. Analysis, design, construction, verification and management. IEEE, a US body with global presence defined software engineering in 1993 as follows. Application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software is called software engineering. In short, this is nothing but application of engineering to software. Let us consider the life cycle of any software. We are familiar with application systems, but this applies generally to all categories of software. First, there is a conceptualization where you say that for certain functionality you need to develop the software. You have to then carry out a feasibility study. Is it economically feasible? Is it time wise feasible to develop such a software? When you think it can be done, you then carry out a systems analysis to detail out complete functional requirements of that software. Once that is accomplished, you then proceed to do a design of the system. System design often comprises of an overall architecture because a large software will comprise hundreds of modules and you need to decide how these modules will interplay with each other. Having done a detailed design and documented it and reviewed it and confirmed that it is definitely a good design, then you proceed to do software development. This is where you start writing programs. So, all participants may kindly note that in a course, in a first course in programming, we tend to immediately start writing a program when we see a problem. But in real life, particularly for complex software, all these steps are essential before you write even one line of code. Once the software development is completed, the software has to be tested and you have to do what is known as quality assurance. The testing and quality assurance ensures that there are no mistakes or what is popularly known as bugs in your software because a buggy program or a program which has errors will behave significantly badly when deployed in actual practical environment. The testing and quality assurance is done by the team of people who develop that software. But additionally, the user on behalf of whom you are developing that software will insist on carrying out his or her own acceptance test. Once the software is accepted, it is implemented. This implementation for large and complex systems could involve months and years of effort where you have to train all users, create all master files or master data, start doing these transactions, verify that the transactions are happening correctly and so on and so forth. Once the system is implemented, there is a stage where you say we are going live with the new system or new software. From that point onward, the software become operational. Continuing operations of large software is a task in itself and this operational aspect is also part of the software life cycle. It is during such continued operations that new bugs are reported or new functional requirements arise which need to be incorporated. All of these become part of the maintenance of software which is an ongoing activity because errors can be found at any point in time during operations. New requirements can emerge at any point in time during operations and therefore, maintenance is almost a perpetual activity. This includes bug fixing as I mentioned, correcting errors which are discovered during use. This also includes functional enhancement. Equally importantly, a new application might come up in the world which is deployed for certain functionality and your application might have to be interfaced with that new application. Even this requirement which is not strictly the functional enhancement of the existing software, but an overall enhancement for the benefit of end user through interfacing to other software application is also considered part of the software maintenance. It is an interesting factor of software life that after any software system is put to use, this becomes an ongoing activity for the entire life of software usage. It is not uncommon to notice that software maintenance often constitutes 40 percent to 80 percent of the total software life cycle cost. The moral of the story is we should write high quality software in the first place and not wait for the testing that is done by developers or the errors being located during the software maintenance phase. From the point of view of our C programming course, perhaps what is most pertinent to all of us is the notion of a coding style because we should be concerned with the quality of code that we write. We must ensure that the code that we write is bug free or errorless. More importantly, it should be human readable, human understandable and human modifiable. When we write a code which has no errors, all that we have ensured is that the C plus plus compiler correctly understands our intent, translates our programs into machine language software which works in an error free fashion. But because the software that we write will be required to be maintained, will be required to be modified, will be required to be extended and all of these tasks are going to be done by human being, it is equally important to ensure that the software that we write is handleable by humans. That is the reason why there are established coding styles and coding standards. These are recommended for all programming languages and for all programming environments, often enforced by organizations which make their lifetime work as developing commercial software for clients. These coding styles and coding standards are specific to programming languages. A useful reference to coding style for C plus plus is given here. This is part of the wiki books chapter on style conventions and equally useful reference on coding conventions which also includes some basics of software engineering in a generic sense is again another wikipedia article on coding conventions. There are some additional interesting references which I have added here. The first one is a reference to a great book. It is an actually collection of essays on software engineering titled mythical man month. This was written by Frederick Brooks in 1975 and the observations made then are valid even today. Here is another reference to a timeless book called programming psychology. This was written by Dr. Gerald M. Weinberg. Curiously many of those observations are valid even today. There are several articles in wikipedia which describe different aspects of software engineering. Those of you are interested I would request you to refer to these and of course to a large number of books on different facets of software engineering which are available in the market. In summary we have learned basic principles of software engineering. As far as we are concerned as a part of the C plus plus programming course our take away is to minimally ensure that the C plus plus programs which we write should a perform the intended functions correctly. That means the programs are bug free or error free. B they should be well documented for human perusal because human beings are likely to read these programs. Documentation which is accompanying your program but is outside the program. Inline documentation of course is written using comments which are permitted in every programming language including C plus plus of course. Additionally it would be preferable if we write our C plus plus programs which are generic and extendable. Last but not the least your program should be usable in conjunction with other software as well. In conclusion I would say that software engineering is best appreciated after we have written some thousand two thousand lines of code in our lives. However just as in any good manners the best time to acquire good habits is right from the beginning. I would suggest that while you write your C programs try to incorporate the basic decency of using a good convention a good coding style and develop yourselves actually and automatically into good software professionals. Thank you so much.