okay so good day everyone uh today I'll be discussing or discuss uh from our meeting okay so we're in slide 10 okay so planning principle okay or Slide N okay so let's start here okay so we have uh here the principle number one which is understand the scope of the project so it means that whenever we are having our project no so it is given scope okay so knowing the [Music] scope especially uh next involveed the customer in the planning activity okay so we are also have a discussion uh during orile methodology one of the uh uh PES feedback so we need to check customer from our prototyp okay so it only means we need to consider as well to add the customer okay next we have here principle number three recognize that planning is iterative okay so model then for sure we need to consider there is anation okay next principle number four uh estimate based on what you know okay so it means that we need to estimate if te okay so what do weend it's either member or project so it may lead to uh not being able to meet the deadline okay due to the uh unforeseen circumstances so we need to estimate okay next we have principle number five consider risk as you define the plan okay so whenever we are doing a plan uh we need to consider uh creating as well a risk management plan okay so what do you mean by this so we need to list RIS and we need to have aeny okay what are your solution okay we already know okay and we can [Music] see okay next be realistic so people don't work 100% of every day we need to divide Accord te especially if we want it to be a quality workot socy as they work so or tired soend performance so we need to consider as well their feelings phical condition uh product when it comes to our project next adjust granularity as you define the plan so if ever then we need to adjust itjust according to our team okay next principle number eight Define how you intend to ensure quality okay so you need you need to [Music] divu okay so let's say for example usually we only have eight hours so as much as possible perance there are two stress fatig okay so we need to consider that next principle number nine describe how you intend to accommodate change so you need to see if there are change how would you uh face those uh changes okay next principle number 10 track the plan frequently and make adjustment as required so software project falls behind schedule one day at a time okay so you need to keep tracking no so you need to see to monitor if Nam deadline okay so you need to keep adjusting as well depend performance you need to consider deadline okay uh next modeling principle so we have two classes yeah requirements model also called as analysis model represent the customer requirements by depicting the software in three different domains information Dom functional domain and the behavioral domain okay followed by uh what do I mean by this so in meeting the requirements so we need to consider these domains effective and see we need to analyze if this model will fit our uh project next we have here design models so present characteristic of the software that help practitioner to construct it effective so the architecture the user interface and component level detail so design model it's more on the software itself no what are the characteristic software in terms of the architecture the interface and component level detail okay so we need to see this okay next we have here requirement for modeling principles the information domain of a problem must be presented and underscored okay so the domain that are presented there should be well clear okay okay next the function that the software performs must be defined so the software are also there okay okay next principle number three the behavior of the software as a consequence of external events must be represented okay so if ever uh there will be uh issues if ever behavior when it comes to software then uh we need to consider that as well so when it comes to risk management okay next principle number four the models that depict information function and behavior must be a partition in a manner that uncovers detail in a layer or hcal fashion okay if ever there are something that we need to plan you need to divide it and see to it that the team uh gets or understood or clear inform needed to be considered especially for the information function and behavioral then okay next the analysis task should move from essential information toward implementation detail okay so from analysis okay after we gather the information then implementation so just like with pramming first we have to understood before syx the then after we uh understood syntax and Theory then we move to laboratory we test what we have learned okay so that is the same as here as well after we understood information then we need to uh make sure that it will be implemented or applied okay next design modeling principles uh we have here principle number one design should be traceable to the requirement model okay so in the requirement model so we need to be able to see no if it fits no okay when we do design and for the our requirement model next principle number two always consider the architecture of the system to be built okay so you need to understood architecture no to produce so this is more on the planning side system itself not entirely member or team okay next principle number three design of data is as important as design of processing function [Music] okay why by drawing the diagram we were able to see next principle number uh five here numbering so here uh user interface design should be tuned to the needs of the end user however it every case it should stress e of use okay so it is already given a software who will be using it okay we need to understand orware we need to consider as well okay next principle number six here uh component level design should be functionally independent okay so it should stand by itself component level okay next components should be Loosely coupled to one another and to the external environment okay so every components when it comes to designing the system itself they should be all uh uh connected to each other okay principle number eight design representation model should be easily understandable okay so it is clear no inde to the it is or okay we need to consider okay who will be using the design as well okay next principle number nine uh the design should be developed iteratively with each iteration the should strive for greater Simplicity okay it should be uh well enough to be understood by the Target okay consider okay so if you fail to do it as well then most likely okay next we have here uh modeling principle okay so let's see here okay now uh principle number one so the primary goal of the software team is to build software not create models we are creating models uh okay now we are creating softwareand so by the end of the day or end of the project ACC next travel light so don't create more models than you need okay so what do you mean by this don't complicate things too many diagram if it's enough for one or two then that is better okay uh the more complex the diagrams or the design are the more project manager or client from the developers perspective okay or the member of the team perspective okay next strive to produce the simplest model that will describe the problem or the software the more simple the better okay if we'll sck to that then next build models in a way that makes them amendable to change okay so when we do uh models or when we follow models then there will be change if ever there will be change then somehow fible isely next uh be able to State exper purpose for each model that is created okay so we need to see what is the purpose of the model purose so make sure when you build the model say for example model you will create a hybrid model then what is the purpose of this okay next adopt the to develop to the system at hand okay models are there for us to follow okay the faces are there so we need to understood or understand activity activity for this phation okay releas feedback okay next try to build useful models but forget about building perfect models there's no such thing as a perfect model okay that is the reason why why agile models they differ okay there's no such thing as a perfect model okay but rather that will fit our project okay so model so maybe you can consider creating your own okay uh next principle number eight don't become uh dogmatic about the syntax of the model if it communic Ates content successfully representation is secondary okay so if the model uh present itself then that is already enough okay don't make it complex then then that is a good thing okay if your instinct tells you a model isn't right even though it seems okay on paper you probably have reason to be concerned okay so if ever uh there will be time TR or guts what do you mean by this if your guts tell you something then you need to see then think about it okay maybe there is something wrong maybe there will be uh wrong that will happen if gam okay so see to it analyze it okay okay next get feedback as soon as possible or as soon as you can okay it doesn't matter if your feedback is coming from your team or from your client okay feedback is good okay we have feedback because there is something wrong with what what our uh what we are doing project then it means okay of course okay the more feedback then the better we can see uh to fix model or project okay next construction principle so the construction activity encompasses a set of coding testing tasks that lead to operational software that is ready for delivery to the customer or end user so coding principles and concepts are closely aligned okay so programming style programming languages and programming methods so testing principles and concept lead to the design of testing that systematically uncover different classes of errors and to do so with a minimum amount of time and effort okay so usually when it comes to software engineering or in developing we have different kinds of testing principles okay how would you want to design to test your uh software okay what are the concepts that you want to consider means pre-made testing so we just need to be aware of it then we can just adopt it okay testing so what are the unit tting when it comes to coding principle and Concepts about it so coding principles or techniques actually already pre existing already maybe you can consider it there is a reason back developer up until now it's because it works okay next uh preparation principles so what do you mean by this so before you write one line of code be sure to understand of the problem you're trying to solve understand basic design principles and Concepts pick a programming language that meet the needs of the software to be built environment in which it will operate select a programming environment that provides tools that will make your work easier and create a set of unit tests that will applied once the component your code is completed so what do we mean by this okay you need to check if programming [Music] language will they be uh available create program uh 5 years from now software will still work integrated to other languages or other technology Okay so then okay so make sure to create a software May last okay next coding principles so as you begin writing your code be sure to constrain your algorithms by following structured what are the algorithms you want to consider okay software okay consider the use of pair programming so whenever we have PR programming usually to uh there are two people senior is Maybe Junior so they can help each other two senior maganda they can uh ask select data structure that will meet the needs of the design okay we need to create okay we can consider techniques already existent next understand the software architecture and create interfaces that are consistent with it okay so what are the uh techniques that consider when it comes to software architecture or you maybe you can considerate uh techniques like say for example for op we have abstraction we have for the interfaces uh consider encapsulation okay so those are already existing it works okay especially design patterns when it comes to programming soee techniques keep conditional logic as simple as possible okay so logic or false okay uh next uh create nested Loops in a way that makes them easily testable okay Loops or complicated or complex code so make sure that uh visible it is not a good code okay next select meaningful variable names and follow other local coding standards okay so we already uh discussed about this way way before variables variables are self-explanatory or self descriptive okay variable okay next write code uh that is self documenting an so or the code explain itself so simp okay next create a visual layout for example indentation and black lines that a understanding so we need to create a pro a code so that is the uh use of the white spaces okay okay not just okay next uh validation principles after you've completed your first coding pass be sure you conduct a code work through with appropriate okay [Music] so okay perform unit test and correct errors you have uncovered okay so we can see this through testing so then make sure you found then refactor the code okay so use the refractor [Music] method next uh testing principles uh principle number one so all test should be traceable to customer requirements okay it is all according customer okay next principle number two test should be planned long before testing begins okay the parto principle applies to Super testing okay so you can also consider youto uh principle so par principle 20% of uh uh problem Paran will be coming from the 80% of the solution okay uh next next uh testing should begin in the small and progress towards testing in the large okay so testing should begin in small okay large LGE and you do testing overwhel okay so better start small okay then go from go to large okay testing exhaustive testing is not possible okay so usually testing is uhal usually tting is especially forms us techniques process usually you need to [Music] consider according to the customer requirement okay next when uh when it comes to deployment no customer expectation for your software must be managed so too often the customer expects more than the team has promised to deliver and disappointment occurs immediately so you need to uh know or to point out okay so that is the reason why we have the feedback so as early as possible okay next principle number two a complete delivery package should be assembled and tested okay the customer already expecting it is working and okay next principle number three a support regime must be established before the software is delivered so an end user expects responsiveness and accurate information when a question or problem arises [Music] okay that is the worst okay principle number four appropriate instruction materials must be provided to the end user manual or properly documented code okay so there should be materials Customs for and also create a manual target audience okay next uh bagy software should be fixed first and delivered later okay so sofware relase or deploy okay we can't release a software Ted it only means it is possible there's no such thing as a software bugs that is the reason why in each testing Pace okay and that's it that's already our uh slide 20 so again uh this is the last topic that we have for midterms for soft uh software engineering okay so again uh thank you everyone and good luck with your exam