 next session of embedded software testing lecture 8, here we go through software life cycle positive some issues are going already I think it is recorded something that is why I will restart lecture session 8 of embedded software testing in this session we will study life cycles that are followed for embedded software development and testing typically it is both and in detail we will understand what are specific software testing life cycle process elements that are required so we need to know some of the definitions of that criteria then there are sample prototypes of life cycle basically we need to understand what is life cycle what are the elements that are required to have an life cycle incremented how it is organized examples we will go through then we will study in detail about software testing life cycle and before that I will just re-emphasize what we studied in session 7 we started with an exercise for lecture 6 then we studied about TM method this is one of the important method that is being followed what it does is it will understand all the characteristics of the complex system or the embedded system of the test and it will apply the approach from various generic methods so the principles are we do life cycle infrastructure techniques or navigation so we studied about each one of this life cycle technical infrastructure or navigation then some of the characteristics that needs to be laid down for each of the embedded system in terms of safety critical or hardware restriction basically the behavior of the embedded system and the test needs to be characterized based on that we will apply the TM method then we had gone through some of the commercial tools what are those categorized in terms of measurement or in terms of editing debugging so all these are categorized so these are the basic categories of commercial tools so we had an example of snapshot of typical embedded system tools also we studied about the words different words what is software life cycle we know the various stages of software development and testing at different levels are used so those need to be considered for implementing an embedded system and testing so those stages of development are to be used or considered at different levels that is nothing but software life cycle stages so some of the points are process to be there there should be defined process for stages of development and testing and the life cycle should consider all aspects of software development such as requirements, design, implementation and again requirements could have derived requirements, requirements study, requirements analysis then design will have a high level to low level implementation can have a low level implementation and debugging testing so all these should be considered in terms of the complete software life cycle in the essence the complete of software life cycle will be divided into multiple software life cycle so in general what they do is they do a one stage prototyping life cycle then they will go for a formal life cycle these two typically they are using it in terms of embedded software system of course there are different types of life cycles that is going to be applied for each of them or the way how they want to are basically in industry to implement some methods of the system they first do the prototyping then they do the formal development so the prototyping will have a prototyping life cycle the formal one will have a formal life cycle so we will go through each of this how it is defined whatever differences etc before that before we study the prototyping and formal life cycle we will have an understanding of couple of words which are important entry and exit criteria so we know that as software life cycle will have different stages or elements of the life cycle so each life cycle or the stages have to have an entry that means what is entry entry is nothing but the conditions that must exist before an activity or unit of the different project life cycle can come in means before we start with of the life cycle the conditions that are required to start that activity has to be existing or should be available so that is the criteria to start that that is why it is called entry criteria exit criteria the conditions that must exist before an activity or unit of the different project life cycle can be being completed that means it is the other way before we announce or before we tell that that cycle or that activity is complete there are different conditions of criteria those need to be satisfied so those are all called exit criteria so these two are very important items that they use defining the software life cycle for each of the stage stage one will have an entry criteria conditions stage one will also have an exit criteria of different conditions similarly stage two will have an entry criteria for that stage exit criteria for that stage similarly all the pages of the life cycle will have entry criteria these two must exist for moving into different stages of the life cycle it could be any life cycle that you take this process is very important so some of the considerations for entry and exit criteria as per the law it is dependent that must have a section that means entry and exit should be in place and it is a dependency on that particular stage so without this it will not move then what are the expected deliveries or expected deliverables in that stage before we call it as an exit there are certain deliverables that stage ends with that is part of the exit criteria then how it translates entry re-entry that means suppose stage three can be said as complete by defining so and so deliverables and so and so deliverables have to be placed before moving the stage three into stage four so that stage three to stage four transition will have a defined elements those elements are called transition criteria transition from stage three to stage four that means the stage three will have some entry the stage three will have some exit also the stage three can re-enter again based on certain conditions getting transitioned within that so that is also called entry re-entry for that particular the stage and entry criteria conditions should identify participants or stakeholders for that identify participants or stakeholders re-enter into the same stage or process but re-entry transitioning expected deliverables are for each of the stage and there are certain dependent that must have items for each of the stage that needs to be identified so basically that must be considered so that is the these are some of the considerations that needs to be used for entry criteria of the life cycle process elements okay so we know that prototyping life cycle and formal life cycles are used in the general MS software development and testing so what are those we go through prototyping life cycle so typically prototyping life cycle is something like this you can see lot of blocks that are involved so as I said there is an entry into the life cycle of the prototype and there is an exit I will explain each of them there are this dotted block is nothing but the life cycle of the prototype so it starts with something like the box which is nothing but the entry we will go through what is that box gets similarly to come out of this life cycle there is another exit mechanism bottom you can see the example is system specification formal software life cycle that means it is ready to go for the formal life cycle it is the next stage as I said example prototype life cycle these are prototype life cycle entry and exit items which are mentioned for this life cycle so prototyping life cycle the software development is initiated in order to freeze the high level requirements to validate the software architecture and software performances that means primarily what we will do is something like we will identify a iterative model and the goal is to identify and freeze the high level requirements and we should be able to validate in a way the architecture what we have defined as the prototype and the software performance performance is what it could be to perform the various requirements that are required and during prototype development iterative description of software requirements software architecture design postcode and test cases will occur to lead to the software requirements that means majorly we concentrate on releasing the requirement releasing the architecture majorly it is a software requirements but to release that requirement we need to have some sort of a prototype architecture prototype design, prototype software something like prototyping the various aspects to prove that these requirements are viable and to do this as I said these elements are the items that are covered under here should be configured so what we do is we will have a configuration management also configuration management process and all the items produced during this development will be configuration managed means it could be an architecture it could be a design of source code all this part of the prototype all those should be configured and they should be under configuration management so this lifecycle will have all these elements covered under the prototyping and no formal change request management will be performed during prototype lifecycle so what is performed is these people what is not there is there here actually that means there is no formal change here formal means from the end system perspective from the user's perspective or from the customer's perspective customer has given an end requirement to achieve an end requirement what we do is we will divide the end requirement or the formal stage of development into prototyping and prototyping we will not release the customer it is something like an internal definition or proof of concept also it is called proof of concept is one of the very important thing industry they are following proof of concept is something like an internal development or testing process of course it depends on the management how they want to project this customers also can be involved but basically it is for internal confidence internal as well as within a defined framework this framework is nothing but prototyping and once we are good to go for the formal life cycle there could be some sort of approval from the customer which we take as an important step or stage of the prototyping which is nothing but the exit criteria and for doing that we may need or may not need a formal change request management which will be used for prototyping that means any of the defined whatever we do for doing all this architecture, design, source code and all may not require a formal framework it will all be internal defined it is no formal change request management will be performed during prototyping life cycle problems are recorded and report the system specification process follow up list a simple action item list will be there I will explain one of the how action item list will be used is also called a mom with action list so this is a follow up list or an action item list that will be used as I said during the development or some revisit into the some feasibility updates this needs to be reported it is all part of the system specification because we are not filled up with the requirements so that is very important that the specification is thorough and solid in the prototyping so that is one of the important criteria before we move into the next stage for we will have a team discussions that are organized between the system team and the software team and one thing that we need to know is that the system is usually defined with the help of customer as well as with the help of the system people it could be management or the seniors I would not say seniors also can be involved or the customer representative so this is at the system level and the team which are responsible for implementing team implementation testing development whatever it is and all that you can call so that is the team but the embedded team or the software team so these two will closely work and interact to make it the specification process to arrive at completion of prototyping of the prototyping lifecycle so it is an iterative model prototyping is an iterative development model I mean the process items which are there within the prototyping like architecture designs test cases will be iteratively developed as we progress we will revisit again to conclude on those items so that is an iterative model very prototype development iterative description of software requirements architecture design code this will occur so finally the end goal is to all these items will be configured because sometimes what will happen is before we while doing the updates we may need to revisit what is the basics on which these decisions are taken care of these also called as a POC program concept that is basically an incremental development of confidence gaining the stage in a constant customers also can involve and there is no formal inputs or changes are taken considered for the prototyping and the system specification process will be arrived in the help of the stakeholders the initial stakeholders like system team for software team so these are some of the items I will explain with an example software prototyping lifecycle you can see there is a dotted block this block is prototyping software lifecycle this needs to be entered then it is called software lifecycle click started for that what is the input system specification could be a customer given draft customer via given draft starting point that is what I mentioned in the lifecycle we start with this because what we are going to prototype so there has to be some draft of specification with the help of that lifecycle click starts so what are those data so what we do in the stage prototyping initialization stakeholders team identification who do what and all that and those initialization as a result of that we will come up with a SRS or a DD here SRS means software requirement specification DD is detail design or sort of called architecture it could be this it could be the other one also but the flow is whatever the arrows these are all some of the primitive items that needs to be there for prototyping then once we have this page with the initial SRS and initial design we will do an iteration of these items by defining real and evaluating so this will keep on getting and as a result of that it could result initial specification update and the same system specification is to have a updated SRS and design and the design and SRS we will go through definition of that here relation means what we do is we will try to implement our feasibility and try to understand so basically what they do is we do some kind of modeling that is in the off-hand system what they do is they develop different models connected how they interact, what are the interfaces what are the signals likely to flow and all that it is part of the modeling may be in another class I will explain all of these model phase there is a called model phase testing so either the model or it is a paper work or a issue or diagrams whatever it is to make it realize that this specification will have a exactly mentioned requirements that is the needed SRS the needed design and the prototype with these iterations with the help of updated system specification we will have a SRS do not get confused with system specification system specification could have something like a system level explain what is the system specification system level information such as it could be an electrical requirement it could be hardware requirement it could be mechanical it could be performance it will also have software so all this will be part of the system basically in embedded software we will take care of the software also for doing the software whether I can perform the software on the underneath system underneath the system will have electrical requirements and all that so these are some of the system level information this will be having but we need only the software related things that is why we will have concentrating on software requirement specification SRS detailed design and the source code all specific to software and we will use it as a procedure prototype result of software test result this will be iterated as I said iterative model sort of a thing in the prototyping life cycle the evaluation is with the help of group of test cases and procedures that will be used for evaluating it so this will go in cyclic way or iterative once done what we do is specification will review or we will do a evaluation so if the specification is final if it is not then we will iterate on that actually iterations of defining specification items how it can be realized we need to have a justification visibility there are some of the important items to be taken care for this iterative process so once this iterative items are done then once this specification final then we are good to have finalization of the prototype that means we have a defined set of an initial working model of the SRS proven concept of design and the source code to an extent it is working fine and we have few test cases sample procedures and reports which could validate the system to say that we have a prototype so these are some of the prototyping life cycles for example what I have depicted here that will be used before we go into the next life cycle which is nothing but formal life cycle so I repeat we start with an entry into the prototype life cycle with a system specification I will put a different color that should be easy green so that is system specification which will enter into the prototyping for the life cycle that means we will initiate with the prototyping life cycle we will come up with an initial SRS and detail design it could be architecture then on these initial SRS or design source code we start the iteration we define it each of the requirements of the specific functions or features that are required as part of the system I said the system will have many high level system level information out of which we will consider only the performance of software related items that is the goal of this prototyping so we do an update of the SRS release of code sample test procedures and sample results then we evaluate against that that is fine or if it we will take this path we will come back again so like this we continue once everything is final we are good to go for finalization and we will have a final or proof of concept working prototype which results final SRS design or architecture document basic code and sample test case results prototype items so we have done with the prototype so we know that the next one is a formal which is an important aspect of the embedded software systems you may wonder why we need prototype so what will happen is if I have a system and I have a customer requirements and I do not have confidence I need to say in 6 months I will develop a small embedded system and I will tell you where it is not easy actually and there has to be a thorough analysis proof of mechanism for that what we do is we will develop a small prototype it is really a short version of the actual online cycle and we will install it at the stage and we say we are good to start the formal life cycle and prototyping to formal life cycle can happen at any stage you do not need to have everything in place sometimes what will happen is only architecture and SRS this architecture is going to work I do not need to implement it but we have studied all the interfaces and you come to a conclusion that I am good to go for next life cycle that is the formal life cycle so that is what criteria criteria we could define all that criteria will be part of this prototyping life cycle so with that the prototyping life cycle ends for the embedded software before we start the formal life cycle so what we do in a formal life cycle all formal guidelines are established that means what are the formalities that we need in terms of implementing the complete formal life cycle will be followed or established entry and exit criteria are defined as I said entry and exit criteria what are those it is the conditions that must be there for each of the process icon before it starts it should be complete before we start the next process item so that will be defined in the formal process we know that in prototyping we do not have an entry criteria overall we have an entry overall we have an exit but in formal life cycle we have entry and exit for each of the stages within the formal life cycle and the stakeholders are defined who is going to do what means what is the team and what are the skills that we should have so those all will be part of the stakeholder identification and definition basically software life cycle data is defined with data identification and data organization so the life cycle will have several or various type of data that is involved the data will be all managed or managed for implementing the complete software life cycle will be part of this formal life cycle so we will take up an example formal life cycle method how it is so we have a planning to enter we know that what is planning in one of the last session I have told that this is a which will have all the environment how tests will be used, what are the guidelines check case, process everything will be part of the planning once we have the planning frozen we will actually start with the formal life cycle so I had put a simpler v life cycle it is called a v life cycle how it comes is an interesting part it looks like a v shape so v shape so why v shape is that as we go across the different stages in deep it is going to narrow down it is going to go deep with the final elements that is why it is called v life cycle what are the items that are there in the v life cycle so we have a specification we know that software specification we are done in the approach typing so we have a software specification we have an analysis of the specification which is nothing but the physical as part of that activity we have an outcome of SRS and after the specification we have design or architecture design also can be broken into high level design low level design it is also called high level design low level detail design or design whatever it is once we have the low level design we have the coding that means coding is done after the low level design is in place coding is nothing but implementation of the intended design so this is one side from the development perspective so this is the development perspective so this will go in conjunction for each of the cases so how it goes is we have the SRS I told and on par with the SRS or the high level we call we develop the test cases so for doing the testing we have the high level testing defined at the high level testing the input is we do not care about design coding anything we always look at so we will not look at any of the low level we all need to know the specification of the SRS to develop the test cases and procedures for high level and an activity as such the outcome is a TR test result so this is at the high level next for design we similarly develop an integration test case and test procedure this integration also can have its own test cases and test procedure so usually it is called ITP integration test plan or test procedure which will be part of this for doing the integration testing we will consider the design high level design why integration testing is called in the model different functionality or feature models that needs to be segregated each model how they interact each other those details are all considered for developing the integration test plan and as per the integration test plan we have the integration test cases and we do the testing at this level we do not care about higher level of course the inputs from the high level can be considered in terms of an understanding of the system but to map with what we do at the integration level we will definitely take design item as an input for doing the unit testing we have the source code or the implementation item sometimes what will happen is they also use the low level design for unit testing that depends on how you want to define so what they do is they will further divide this block into high level design one block, low level design block low level design block they do it for unit testing along with the coding but in general source code is a prime input for doing the unit testing and testing is also called as components so each of the components or each of the units which are implemented or coded will be tested so again they will have a test case test procedure and resulting in and all this TR TR TR you can see on the right hand side will be that goes that goes with the conjection of these left hand side elements specification design and coding that is why it is called as a V model so this is the formal life cycle so we have prototyping done in the previous prototyping life cycle that will be written as formal specification that specification is considered as input for that specification we develop testing in parallel to all the items that are required in the development for doing the testing updates so this is a formal life cycle example and we know that why we need to have testing identified for each stage because it is very important to identify the cost value for bugs at that stage so that the cost of maintenance or the updates of the products will be less as we identify the initial stages so that is one of the early sessions we have got through this graph which has identifying the cost cost of effect it grows up as we go deep into the prototyping we cannot afford to have a bug that is there in the product that is released because the cost will be very high because it has to go through several life cycle or the bugs could be at any stage or the common could be wrong or something like that so what we do is we will identify fixed results at the stages as early as possible before we release the product so that is what the story of this slide same thing is from the formal life cycle has been formal typically how it is there actually so we have a requirements we have a architecture or high level design we have a low level design we have an implementation these are the one side on the other side we have a on par with the requirements we have an acceptance test on par with the architecture we have an integration test we have an implementation at any test so a cut down version of this is being used here in the example formal life cycle here cut down is something like I had put one block for design which will be used for integration testing and there is no system testing so the system testing is used here for architecture point of view and requirements because acceptance test is required for the user or the customer here what I have to use is the requirements used for high level design similar but basically it is a model they use this from an example how it is depicted in a book called introduction to software testing by Aman and all of them so this is the embedded model life cycle I have been using it in a v-shape I mean let consider the relevant stages on here I can set testing stages this will go in handle for each of the cycle and what happens typically is that this will go in parallel why I say to do an acceptance test we do not need to do the we do not need to have an implementation so this is done for each stage we are going to start the acceptance test plan the high level test plan the test plan can be developed for the particular requirements still the design and the implementation is under we can still go ahead with the test plan we can write it so that will go in parallel to the requirements similarly when the design the system test plan or the integration test plan for the low level test can be updated or it can be started in parallel to these items once we are done with the implementing we do the unit testing and we will go with the actual testing to produce the results so plans and procedures can be written in parallel with all these left hand side items so that is about the V model here are some of the points which needs to be understood the requirements analysis phase of software development captures the customer needs as I said to call the customer inputs from the system perspective also will be used in developing the requirements and the requirements analysis and the acceptance testing is designed to determine whether impact meets the needs of the requirements in other words acceptance testing probes whether the software does what the user want this is something like a business perspective acceptance testing must involve users or other individuals who have strong knowledge as I said earlier the users or the testing team should have a strong system knowledge the system to the customer or who can basically report the test outcome to the user or the customer so it is very important that acceptance testing is used for delivering the product next one is the architectural design design phase of the software which uses components and connectors that is interaction of the various components to realize the system whose system specification to meet the previously identified requirements that means we have the high level requirements which will map with the different components as a interaction of the various components to come up with an overall design or the architectural design on par with the architecture design we have the system testing which is designed to determine here design means testing is designed to determine whether the assembled system it assumes that the pieces work individually and asks if the system works as a whole this level of testing usually works for design in specific problem whether design has any flaws all this will be identified in this testing it is very expensive place to find lower level parts and is usually not done by the program but that is separate testing team that means system testing is done independently with an identified team who will not bother about the lower level issues or lower level issues could be any of the signals drivers or hardware registers or the process related things but it looks at the system level so there is a separate dedicated team who will take care of system testing and that will be on par with the high level design or the architecture design the next one is the lower level design lower level design phase of the software which specifies the structure and behavior of subsystems that means there are different sub modules which will have some structure and behaviors all will be detailed in the lower level design so each of this will be intended to satisfy some functionality in the overall architecture that means each subsystem or sub modules will have its own defined feature or the function and on par with each of this lower level design this is a testing methodology called integration testing which is designed to assess whether the interface of these modules in the given subsystem have a constant communicate correctly let's take out this because so integration testing is on par with the lower level design which will identify all the interfaces between this lower level more on par with what is defined in the lower level design and it is consistent and the interfaces interface each other correctly and communicate appropriately the last one is the implementation of the programmed elements in the case of software development that actually produces the code as a result of implementation the input the source code on par with this implementation we have implementation that is designed to assess the units produced by implementation phase and the lowest level of testing in some cases such as when building general purpose library module or the low level source code new testing is done without knowledge of software applications what it means is as a low level unit it is tested with the help of parameter which will identify the flow within that module of the unit so that is how the implemented there are interesting of the implementation I think I have explained in the sessions about unit testing integration and all that here is a mapping of all the steps of testing in this model so this will go hand in hand with this different life cycle process so each life cycle will have an exit which will be an entry for the next that is what the entry and exit criteria that needs to be defined so we will go through this entry and exit criteria in the next session of course what are those life cycle process elements that needs to be defined so we know that each life cycle will have a process all this in the V model so what it is to have many money or what is the mandatory thing that we need to have for the life cycle process for each stage so there has to be an objective there should be a scope what are the inputs that are required so what it is going to produce then we have an exit criteria which defines the exit conditions for that stage so we will take an example in the next session for each of the life cycle process and we will identify I will explain about consumer electronics I will explain about automotive how the process are there in the next session so basically these are some of the elements that are mandatory used for a life cycle process objective of the stage scope entry criteria inputs outputs exit so those are required