Articles

Lecture – 21 Software Metrics and Quality

July 12, 2019



quality software development and what are the practices that we should use when measuring our software and developing towards quality so first question that we have to address is why do we need to measure why measurement so we can see that if you want to compare two different things you need to measure you can say that a person is taller than the other or a person is heavier than the other when you can measure you can compare and when you can compare you also have a choice that means you have some sense of quality and that quality is quantified in terms of the values after measurement and once you measure you can decide so choice is possible and then progress is possible so if you know that something is wrong something is not as per the quality for example your code may not be efficient you have measured the efficiency now if you can try to achieve higher efficiency or say utilization so once you are able to measure you have some quantities with you that is numbers now you know what is expected and in order to improve you can also objectively try to achieve better measures of higher quality so measurement helps us distinguish different things that means we are able to compare and we have we are able to capture quality in terms of some quantity or we are trying to quantify the qualities and once we are able to do that we will be able to exercise our choice and also we will be able to progress or we will be able to make corrective steps we can encourage call it events we have the numbers based on of the number so basically when we want to deal with software we want to have these objective measures so that different people can use it once you have an objective measure everybody understands the meaning and there is only one way to calculate these numbers then there is uniformity and practice so we want to have these objective measures and then we want to apply these measures to various tasks so if we are able to measure our software we can compare we can exercise choice and we can also improve based on the measure so these are the important considerations which drive this the practice of measurement in software engineering so what is the use of software measurement this slide captures some of the points how good is the design so if we measure we will be able to know whether a design is good or bad bad designs are mostly hard to understand implement maintain and evolve so the your software might be correct but the design of the software may be very complex so once I tried one experiment for a small problem in a class in my class there were about 20 to 25 designs so now if we have many designs for a same problem you have to choose one of them so you should be able to measure you should be able to tell objectively which design is good and bad so that we should strive to achieve so we should find out if there are any objective criteria with which we can measure our designs so we can for example we can say I'm using 10 classes to achieve the solution somebody else might be using three classes somebody else may be using five classes which one is better so you cannot say if I use less number of classes or less number classes have better design or use too many classes have a better design so there must be some criteria to firstly to measure that means to count and to come up with the measures and then to compare them to associate them with quality factors in software engineering so one important point is about design then we also need to look at the code complex code is mostly hard to understand test debug and change so if the code is very complex it will be hard to understand so sometimes so it also deals with styles so the algorithm could be same but the code that is written by different people also it differs how much efforts will be required this is another use of software measurement so if we have the measures of your software or if can predict for example the number of classes that are going to be required to implement your software you can find out how many people will be required how much time is required that means you can estimate your man months you can estimate your cause so to develop the software you need to find out how much efforts are going to be required and this is this deals with your management aspect of software so in order to design implement test maintain debug and deploy how much efforts will be required so these measures can also be useful from that point of view so that is to say that software measures help in decision making in various lifecycle phases so this is the relying motivation but if you are able to measure your software product and also the process it basically helps you in various kinds of decision-making in various phases of your software lifecycle so what are the attributes and that can be captured that means what you can capture through these measures about software so basically we are trying to cap of the quality how good is the product efforts our resource estimates we can capture them progress of development how far you have progressed how much is still remaining so that is the most important question which everyone wants to ask when you are developing in front of with deadlines in front of you and complexity or difficulty how complex is the task how difficult is a task you all obviously won't measure this you want to capture this attributes through your measures process quality also how good is your software development process you want to capture if possible so quality factors usability correctness efficiency modularity portability simplicity understandability security robustness completion that means how much you have completed how many functions how many use cases have been over so is it 90% complete 95% complete so you want to have these measures and based on these you have some assessment of the quality of your software so measurement is quite important and these are the attributes which we would like to capture quality of your software of your process the progress of your development then the complexity and difficulty and also the efforts or your resource estimates so we would like to capture these through measures and correlate these numbers with some of these with these quality attributes so in this lecture we are going to look at some of the basics of measurement and see and look at the motivation and various measures and some important properties associated with measurement so that we have a good introduction to measurement and then we will also look at how you can organize your process and how you can use some of the good practices which are known in the software community or which are which are well-established as good practices so first we will take a look at different aspects of measurement so which one is a good measure that is a question which comes from mine so lines of code is it a very good measure will it capture everything that we just said so consider for example you have a thousand line program and a five hundred line program so can you say that thousand line program is more complex than the 500 line program so how can you use this measure so this is a measure LOC lines of code so this definitely tells you about the code size in terms of number of lines but does it reflect on how good the code is how complex the code is is it a high quality code can you say that thousand line program is a high quality code and five hundred and programs the locality code or can you say that thousand line program is more complex than 500 line program so you cannot make these statements but you can say that thousand line program is larger than 500 line program in terms of number of lights that much you can say so LOC is a measure it tells you about the length of the code maybe you can associate this with time required to understand the code say if I have 1 million lines of code I can have some estimates from that number if I know that I have a hundred line program again I have some estimates about the efforts required at the time required to understand this one so it is useful but it cannot capture everything so that means we need to associate the appropriate appropriateness of a measure to when we have we are using it in a specific context so for example LOC can be appropriate in one context but not in another so this leads to question what to measure so you can of course measure lines of code and use it so what to measure and the answer depends on what what is your need so when are you going to use these measures for what purpose so now there are plenty of measures available and you can go through the metric databases or there is a lot of material available papers are available so many measures are available and you can use appropriate measures in a given context and also so the important point that we want to highlight is what to measure depends on what is your purpose and accordingly you can choose the right measure and apply it to your context so we will have some attributes mention here on this slide what to measure in software what can be measured can we can be measure length of the software can we measure the size so the answer is yes but the units are different so we won't measure the size you can look at the lines of code for example there are different kinds of size measures so size you can measure you can measure togetherness of modules components so we know that we want to achieve high cohesion within a module we do not want to put unrelated things unrelated functions are unrelated completely unrelated classes in one module so that property is the cohesion property so you want to have high cohesion that means the model should be together so we want to measure this togetherness of modules components and we also want to measure dependence of modules on each other that means how much a model depends on another model so we want to achieve a very good separation of our components or modules so that they are independent once we have this good modularization we know that we can do parallel development we can give different modules to different programmers we can test them differently and then only we have to make a build so independence or separation of concerns is a very important principle in software engineering so you want to separate these concerns and you want to reflect them into different modules which are separated so we also want to measure the separation how separated they are our other any couple so coupled together or are they very highly coupled there has to be some coupling because modules interact so you do not simply have your software as simply in completely independent modules otherwise it will be simply a collection of library you want to software that is executing and that has lots of collaborating components so coupling will be there but how heavy is a coupling how modules are interdependent on each other is it a very spaghetti coupling or is it a very clean structured decomposition where you have a very very good low coupling and but there is collaboration through low coupling and you have very highly cohesive module so each module is together so the components in a modular together but different modules are not very tightly coupled to each other so this is what you would like to achieve so you want to achieve a high cohesion look low coupling and at the same time you want to achieve separation of concerns and also collaboration so if we have these measures of coupling in cohesion with us we will be able to tell whether a given module is highly cohesive or it's low on cohesion and then reflect back on the programmer and ask the programmer to or the designer to improve on the design or the code whichever is the cause of this cause of bad coupling or bad cohesion so dependence of modules on each other we would like to measure then we would like to measure code complexity or organization of code how complex is your code Oh good organization have you whether the organization is good or how bad it is defects discovered per lines of code so we want to find out how many defects have been discovered so far so if you have 100 lines of code and if you have discovered 20 defects you have 2500 so you have 1 by we have one defect per say file eyes of code and if if you have the same number of defects for a larger program that means the program is probably better or less error-prone so this is a good measure it doesn't see defects also are of different severity so you may have smaller number of defects but they could be very severe whereas trivial or minor defects but more in number may be more tolerable than lesser defects but severe say specifically say in mission critical systems if there is one defect that shuts down the whole system it could cost very heavily so defects discovered per lines of code is of course a good measure but it doesn't tell you about severity of your defects so that that's something different so but however it is a measure and it can tell you whether the programmer is making many mistakes and so on so during testing you have to measure this so not only that you are measuring your software source code but you are measuring also during your testing phase you are measuring number of defects that are being discovered for a given module or code and then you can relate it to the people or the resources involved and try to improve so we can use these measures we can feedback these measures into the process and improve on the quality of the software so then time spent on different processes you can measure the time and then so that you can control the process well the number of requirements for your software we can measure so if you have too many requirements so simple measure could be num this number of use cases in your requirements document so if you are too many use cases you have some measure of how much it's going to take to carry out this project so you would like to measure measure these things so these are some examples so based on the goals of your measurement and what you want to measure you need to gather data so this is data gate the correction is important so you need to gather the related data in order to measure so sometimes the data can be collected automatically you can write tools which can directly give you measure for example if you are measuring your code you can write tools and get these measures and during testing also you can count number of defects and so on and few measures could be also the data could be manually maintained in form tables and so on so it is important that appropriate life cycle stages you keep an accounting system and keep gathering the data so that you can collect these measures and then you can feed back into the the quality of the software so that is a important point so that once you measure your software once you have these measures you can you can use them to choose to improve upon the software so to improve the quality of software now we will look at some aspects of measurement so what are the different kinds of the different kinds of measures can we classify them so so one important concept to study in measurement is scale so we have we could have measures on different scales there Kannamma kn'l scale ordinal scale interval scale ratio scale absolute scale so let us look at these scales what they are and what kinds of measures we have and what can we do them so the first one is the nominal scale so in on the nominal scale items are assigned to groups or categories no number is generated for example you can have ordering no ordering is implied so you have so no quantitative information is generated but you have groupings or categories examples are whether your programs are recursive or non recursive programs or programs that use portable features and those that use non portable features binary executable programs source programs DLL components object libraries so you can classify them or categorize your programs or functions or modules in these different classes different types of errors so it is one way so it is basically classifying so this scale you get groupings of categories but you can't order them so you cannot say one is better than the other or you can't have on this using this measure you basically say this is different from the other and it is a qualitative difference but there is no quantity associated with this but we do use these measures and they are also very helpful then you have the ordinal scale on which you order your measurement so measurements are ordered so higher number and we present a higher value lower number represents lower value so but the numbers are only for the purpose of ordering say for example cold warm hot this is an ordinal scale so but you can't say whether cold means one-third as hot or hot is cold plus mom so these numbers are basically for the purpose of ordering or in this case cold warm hot against a college bang or miss to Ortiz what is three but you cannot say what is called plus warm and or you can't say cold means one third as hot for example you have CMM maturity levels initial repeatable define managed optimizing so these gives you an ordinal scale how often software fails daily weekly monthly yearly or never if it fails so our software is never failed so you have this ordinal scale so ordinal scale is also useful length is also often used in social engineering then you have the interval scale where you have intervals that separate classes and the interval is known so that is based on value you know exactly when the item crosses one class and goes to another so the classes are order different classes or the categories are ordered addition and subtraction is fine but you can't take ratio you cannot use multiplication division so for example temperature in Celsius or Fahrenheit scale you can say that 30 degree centigrade to 31 degree centigrade or 20 to 21 degree centigrade is one degree hotter than earlier but you cannot say 50 degrees is twice as hot as 25 degrees so example in software engineering is logs of events on different dates you can't say yesterday was half today but you can say that today is one day more than yesterday so you have these intervals and they are also ordered addition subtraction is fine and addition subtraction is not fine in the ordinal scale which is possible in the interval scale so then we have the ratio scale ratio scale has ordering intel sizes and wishes are also possible so value 0 is available and represents absence of the measured attribute example you have length 5 field is half of 10 feet temperature on Kelvin scale or LOC length of code as statement count you can say 100 lines is half the length with respect to 200 lines so and then you have the absolute scale counting entities in the entity set where you can simply count the entities so all arithmetic operations are meaningful and there is only one way to measure that is by counting so length of program when measured as statement count LOC is not the absolute scale as you can measure it in different ways for example you can have number of lines or number of words etc but LOC has statement count is absolute scale measure of number of lines of code so if you are saying that I am simply measuring number of lines of code then the LOC is absolute called number of failures number of project engineers so these are your absolute scale measure now let us look at some of the metrics which we can use in the software lifecycle say for example you have length which gives you physical size of the product it is not enough to understand the real complexity in order to estimate efforts cost etcetera so the length or number of lines of code will not it is not enough to to gauge the real complexity but but it is a useful measure then the functionality so size can be also found out in terms of functionality how heavily from how much functionality is present in the software how loaded is the software in terms of functions or the functionality that it provides so these are also some size matrix and then the complexity matrix mainly talked about or mainly provide the measures of the problem complexity algorithmic solution complexity structural complexity or cognitive complexity there is an understandability of your software how easily you can understand the software so these are various aspects of complexity so these are basically your size make various size matrix so you are trying to measure your software size in terms of these aspects linked the length of the software or the functionality of the software so the size in terms of the functionality provided or the complexity of your problem domain and the solution so let us look at linked and it's a simple set of matrix so you have lines of code but when you say that you have say thousand lines of code you also specify what have you done with commands blank lines bigger declarations or if you had say more statements and one line of your printout how do you how did you count them so when you measure LOC or to explain these so that they can be compared so you have to have standard about measurement so that in a set up or say in any company values report these figures everybody will know what you mean and then you follow the same practice again again so that the different entity is measured at different times can be compared so lines of code when you report you have to also explain how comments blank lines declarations and many statements on one table lines are accounted so you have another measure called e lock or he loc or n/a love c which many counts non commented effective lines of code so you can say n LOC is 28 means 20 are the non commented effective lines of code or c lock which gives you number of commented lines in the program so how many commented lines are available in the program so which is your c lock so these are various length related measures functionality there is an important term a major available in software in code function points which is FP or which is computed in terms of number of external inputs number of external outputs number of external inquiries number of external files and number of internal files you can say dependent you can change files interfaces and so on so but these different factors are taken into account and each count identity has a weight associated simple average and complex say for example you have various external inputs and solve they might be simple some of them average and some of them complex so this kind of measure measurement could be subjective so one person may say that something is complex another person might put it as average so there is some kind of subjectivity associated here but you give these weights and then as per a table these weights are picked weights are these numbers various numbers and then the formula you compute your for FP or your function points measure so this is one one way to measure your functionality because you are talking about inputs outputs files used or different number of entities use number of external inquiries in the software so you are trying to measure the functionality in some sense then another good measure is a simple number use cases in OAD complexity we know that we have the people notation and you have various kinds of complexities you can compare them so if suppose you have you may have you may say that I'm a I have function as a constant time algorithm so irrespective of your input size it takes it has the same number of steps that have to be executed you may have a logarithmic linear quadratic exponential complex algorithm so once you measure this you know how complex your algorithm is and how the timings are going to vary based on the input sizes so you basically measure time and space complexity both so you want to also say is the space required so that you can use your resources effectively now you would like to measure structure so we just talked about measuring size various aspects of size for software that is it could be your length in terms of functionality in terms of complexity you could also want to measure the structure of your code or your software so one interesting measure is macabeo cyclomatic complexity it basically measures number of regions in the flow graph number of predicate nodes in the flow graph plus 1 or e minus n plus 2 so in this figure you have these arrangements are you have predicate nodes are decision nodes where you have the first so here you have 1 2 3 & 4 regions so are these these also represents the number of independent parts that you will have to that you can use in your testing phase and so on so we have seen this similar pictures in the lectures on testing so this is one good measure that talks about naka by cyclomatic complexity but you can see that a program can be very large and still have same macabeo cyclomatic complexity as if a small program so it is possible so you know in a sense it doesn't it measures basically the say for example it is useful in testing but it may not really tell you where the program is really complex or you may have a very big big big program but it does tell you something about your decision nodes or predicate knows that the structure of your program and you can use this in testing because you have these number of you can use these number of independent paths and you have the coverage criteria are derived from maccabees complexity now we will see how coupling and cohesion could be measured so there are different kinds of coupling as we see on the slide we have plate a coupling Stamper playing control coupling and so on so you have these through these kinds of couplings various kinds of couplings modules are interrelated or interconnected with each other so you would like to measure these number of interconnections of different kinds of coupling or maximum of the number of interconnections per module say for example at most what is the heaviest coupling in the in the entire system or average number of interconnections per module in the system so you can measure coupling through these coupling connections number of coupling connections and you can also look at cohesion so there is one ordinal scale for cohesion so you have the functional sequential communicational coincidental and so different kinds of cohesions and you can say functionally cohesive is the best or cohesion so which has a good so we are putting all the components together so that is a best cohesion and coincidental cohesion is that they're just together but it's not really cohesion so we have put some of the classes so there are various classes in which you can define the cohesion and then you can say one is better than the other so the best is the cohesion where which is due to abstraction so you are putting components together because they are achieving some related functionality and the abstraction of the model is one so that is the basic wage and possible so there is one one such scale available but you can also measure cohesion in terms of your code example you can try to find out whether a class can be partitioned into two by partitioning the class classes functions into two partitions such that each set of functions use different set of variables if that is possible then the class is not cohesive if it's partition able in that way or you can find out whether a class is highly cohesive or not so cohesive so there is a measure available in object-oriented software metric suit for measuring lack of cohesion so we are going to have now the slide on various object-oriented metrics so the object oriented community has come up with quite a few metrics which can measure for object oriented design and object oriented software or on certain record so CK that is timber and camryn and the mood matrix which are the two important suits which can be looked at but there are many other metrics available so for example you can measure number of methods in a class average number of methods per class or depth of inheritance tree how deep is your inheritance tree so if it's too deep then then it's considered to be complex in terms of say the behavior different polymorphisms possible or the behavior or the tracing required to understand which method is going to be invoked through the inheritance tree so number of children coupling between objects responds for a class or RFC lack of cohesion amongst methods there is Elcom attribute hiding factor method inheritance factor attribute inheritance factor polymorphism factor and coupling factor so various metrics are available in the object-oriented as well and the main references for these are the CK and the mood papers you can pick them up now there they are also covered in many textbooks so some of these are quite simple so they can be also obtainable through tools or by also for manual counting so these measures are useful so as we can see that we are trying to measure various attributes of which connect to quality of the software and then we want to feed back into the quality of software based on the measures for example if you find that class is very is not cohesive you you may want to redesign your system or if you find that there is very heavy coupling between two classes you may want to reconsider a design and you may want to move or you may want to apply some refactorings on your design and we are just your collaborating classes or the hierarchy so that these figures improve so if you have some quantification of your design in code you can use that in order to redesign the system or refactor the system so this is a very interesting approach to also soft revolution and refactoring you can do it based on matrix as well if you have the set of tools available and if you have this expertise available that can make it possible to interpret these measures so interpretation of measures is also very important area so given a set of measures how to interpret about the quality of software or the corrective steps that are required in order to improve on the quality so it is an important area also area of research and many interesting metrics are available and one can go through them and the key is to apply the right set of matrix in the right context and also interpret this matrix so that you can feed back into the quality of software now after having looked at measurement and some of the matrix and their importance in software engineering we will now move on to some guidelines for coding in development so to quality related guidelines so that if you practice these they will they will lead to improvement in the quality of your software so we might have seen these in our earlier lectures but I am putting it down again to emphasize some of these aspects which can be practiced even in the in the small when you program in your data structures assignments or any or any class assignments when you code in groups or when you when you code against the course projects you can try to use some of these techniques and they they come in the long way so that it affects the quality of your software and we cannot they are scalable they can be used in the in the large as well so for example use assertions in your code from time to time so this is called defensive programming style you can apply it for modules functions procedures classes and so different kinds of modules so why defense because these can act as defense against errors which you can make so if you use assertions in your code the assertions can capture various errors so assertions can be of different kinds but there could be preconditions they could be used as postconditions invariants if you are using assertions very heavily so if so there could be practices that recommend very heavy user physicians so it depends on the context in which you're working the project in which you're working if in a project assertions are used very heavily they could be removed once the code is well tested or some of them could be removed once the code is very well tested and for online defense typically technique used is that of exceptions so the software should be able to catch an error or an exceptional condition and handle it so that that gives you a handle to gracefully terminate your software or to be handle conditions so we can use assertions when you're developing your code and then possibly remove them when the code is well tested and when you want to deploy it but you can use it and you can use exceptions for online defense so for example if you know that yourself there is not handling certain situations and if they arise you can create exceptions through them catch them so this is very important that if you know that you cannot handle a situation you have to terminate software gracefully or there has to be a part to handle these kinds of failures so it should not be an abrupt termination that means the software does not know that there is a fault and then also these are very severe failures they can cause where receiver failures so exceptions are very important and which can be used it should be used so programming languages do provide support for handling exceptions for example or assertions so you have the C assert micro Java cert expressions exception throw catch mechanism the classes for the exceptions and the throw catch mechanism of the exception handling for example you have it in Java and so on so you can use assertions and exceptions in your code frequently so try to use them in your smaller assignments so that you can improve on your developmental practices so we will look at what are these preconditions what can you do with preconditions you can check your input parameters for example whether a number provided is within a range we can check local acceptability for the message or function whether the function add a Dom item message can be served is there capacity in the buffer so that item can be added so you can check these at the input itself as soon as function is invoked so these are preconditions and then then you can write your actual business logic so the business logic does not have to worry about this conditions they will be guaranteed when you come to business logic so so you can separate this part in the precondition code and postconditions you can check the outgoing results whether value being returned is within range that is guaranteed and you can check for the local state that is for example after executing your business logic just before returning your call whether your local state is in a consistent means is consistent for example stack location becomes available after a pop successful pop so you can check these in your post conditions and then you have invariants different kinds of invariants you know you can have class invariants throughout the lifetime of the instance the invariant remains to for example balance is never negative in an account and if it goes negative obviously there is some problem and if that is the case you can raise an exception or you can raise an alarm so the programming language has to support these so that you can specify them and and monitors can be inserted in the code so loop invariants can be specified which are valid during the lifetime of a loop so loop index for example should be within a range defined by your min Max of your loop index now we'll talk about organizing your modules how do you organize your modules how do you decompose them nicely so that you follow the separation of concerns and that reflects into quality of your module organization so right related functions in one file write a header file for this module user program that uses this module is in a different file the user program includes the header file user module and function module can be separately compiled to object code and then you can link these two together to produce an executable so this is a good style if if you follow this the same thing can be same thing is used in large-scale development when you actually separate the concerns you have many modules and you have the module signatures or the header files which specify the interfaces so you basically you are separating the interfaces from implementation so a module that is using another module can be still developed if you have the interface for that for the other module available with you so this is what basically we are trying to capture and this figure captures this process so you have this function you have the header file or the interface defined in this pile and you have the user file that means you have one module here which actually is going to need this module but you do not need to wait for this module to be developed you can see that this path is different and this path is completely different so you can take these two independent paths you can have two programmers taking these paths simultaneously so that you can speed up the development process so but that you are this the module which depends on this module has to include this function prototype and this module uses this function prototype so this confirms to this prototype so this has to be done before you can start developing this module or this module so that means you can take these independent paths you can exploit these independent paths so once you develop this function code you can compile it to object code make it ready once you develop user code and compile it cobs I could make it ready and then you can link when both are available you have your deployed software or a dot out for example in your simple Linux environment so then you make it a practice to use make files so you can use make utility to organize your program compilation and building processes so if you use sophisticated tools these can be specified in the if you use the integrated development environment the make files or the build files can be specified through the environment itself so that it organizes the build on its own you do not need to key them in one by one so however for your small assignments do try to write your make files so dependencies can be captured for example the dependencies here that in order to produce a wrote out you need this and you need this and if you have already compiled this if this the user class changes or if the user file changes you do not need to recompile this so these dependencies you want to capture somewhere and when you simply execute the make file when you want to build the software you are building only those units which need to be build because the changes have been done to the files which are being used by the module that you are building so I have an example make file for example you can say these when you want to make something when you want to make software so this is so whole represents the entire software so this is your symbol which are using and these are your actual units for example you have the entropy handler so these are some executable files you want to generate so you want to build the whole software you need to build these in order to build in program you need to build these datos and how can they be built they can be built by running this command g + + whatever so this is your sample make file and you can do the main page of make file and find out the format or on internet you can download examples or send me mail if you want to have these samples then how do you organize your code so do you use comments follow conventions for names of variables constants classes functions for example class names could start with capitals variable name on these not start with capitals then constants can be written with all capitals and so on so you know interfaces can start with an I capital and then the interface name so once you follow this convention stick to them so that you follow them uniformly and it's easier to your code becomes easier to understand and it can be also understood by someone else once the conventions are known it is easy to follow the code then use proper indentation the printout should look good so this is important so there are many good guidelines for different languages or you can you can look at some of these and try to follow good indentation for your code so that the code should look good so if the when you take a printout it should look good so that it is easy to follow the code then when you develop try to develop your test cases first so what you want to test so when the software is going to be handed over to the customer how will the customer test so imagine yourselves in the role of the customer and try to list the test that you are going to plan out that the test that you are we are going to carry out on the software so write test cases first that gives you a very good view of what you are going to what is required or what what you are going to do with the software at any point of time let your code be executable so when you start writing your programming assignment you can say you can just start the one empty main if it's a C file and the executable file is ready but it does not have anything so but however you can now add functionality is one by one and then it develops one by one so you are not writing the entire code in one big bang and then once you compile it you might get hundreds of errors so in order to avoid that situation if you incremental e develop it and if you keep it executable or runnable from time to time it may run but it may run partially so that's not a problem but getting plenty of errors in one Big Bang you know makes it difficult for you to go through the errors and fix those bugs some of them could be syntactic some of them could be logical as well so the architecture blows up step by step or at any time the software is enabled but with varying functionality coverage so this is the practice which you can put in when you do small-scale programming and it comes a long way also it helps you in large-scale software development so other good practices are listed here use tools which what is available for example make files available use or integrated development environments are available use them so there are various kinds of tools and many many case tools are available so whatever is available to you at in a given setup start so I am basically talking about your labs which you carry out I say for exams or fringe in lab try to use tools which our tools are available debuggers you should try to use for debugging your code then produce good documentation for your question documentation should not be taken as documentation for documentation sake it is for the purpose of understanding you firstly understanding your own code and then somebody else should be able to understand it modified Volvic so good documentation is important it say when you analyze your software when you are saying if you are following OAD you are going to produce class diagrams interaction diagrams and so on so that gives you very good documentation so that you can develop it well you can test it well you can understand your own code somebody else can understand evolve it maintain it debug it and so on so documentation is very important pair programming is when effective practice where if the code is very complex you can do it in pairs sometimes two brains put together is a good practice if something that you are not able to handle are not able to see another person can see it quickly so usually it's an effective practice to carry out projects quicker then if you have heart bugs take a printout show it to a friend or you can relax to sometime and come back to the back sometimes a bug can bug you for I use amounts of time for example for four days but can bug you when you are writing your assignments you may not be able to find the bug easily because you are so much accustomed to your code that you don't even see a bug which could also be trivial so one good way to fix fix a bug is if you are not able to fix the bug in say half an hour whenever you can take a printout of that portion of the code and try to read the printout maybe you will spot the bug or if you is still not able to spot the bug you can show the code to your friend and so on so you can apply some of these techniques so these are some good practices which are known to boots off to practitioners so you follow some of them meet your local experts and you know coding your development or local software engineer so that you can put into practice some of these good guidelines which are available to you so this is about the factors that can go into quality software development in long run so we looked at measurements and different aspects of measurement and we also looked at some good practices which you can apply so that your software quality improves

You Might Also Like

8 Comments

  • Reply Nadeesha Nirmani July 12, 2019 at 12:35 pm

    We are conducting a survey on estimating complexity Can you fill the survey great help!!!! thanks survey can be found in below link
    https://docs.google.com/forms/d/e/1FAIpQLSc4NcXBrt7n63Xfs6uk5cAAOsWe-hInJJ6z0fQMyTPTljOtQQ/viewform?usp=sf_link

  • Reply psych ./. July 12, 2019 at 12:35 pm

    pls die… jus die

  • Reply Ritesh July 12, 2019 at 12:35 pm

    Does he look like pissed off to anyone else or is it just me?

  • Reply Shrishail Baligar July 12, 2019 at 12:35 pm

    that guitar intro could have been a bit better! great lecture though

  • Reply FailingDarkness July 12, 2019 at 12:35 pm

    As a student in Mechanical Engineering, I can testify that it is the same in my field of study. Then, they will expect you to turn around and apply it to a project with no instruction whatsoever on how to do so. It is normal in Engineering to have to learn how to apply the knowledge through independent study.

  • Reply vijayaratnam purushowththaman July 12, 2019 at 12:35 pm

    I think He's to shy!!Not smart at all 😀

  • Reply Apoorv Kumar July 12, 2019 at 12:35 pm

    U are way better than my s/w eng. Teacher who does'nt know how to teach.
    Thanks sir.

  • Reply bandhurey July 12, 2019 at 12:35 pm

    Good theory, sound fundamentals!
    But the presentation is very slow paced and infroamtion is not directly usable. Examples are very academic.

  • Leave a Reply