Durante el curso de ken el método que utilizo de enseñanza fue muy distinto al que estamos acostumbrados, pero la verdad se me hizo algo muy interesante y necesario porque fuera de la escuela cuando ye estemos trabajando en algo no vamos a tener un profesor que nos diga que estudiar y vamos a tener que siempre seguir aprendiendo algo nuevo.
Al principio del curso la metodología no me pareció algo muy nuevo que digamos porque muchos profesores ya están dando algo del tema de la clase y nos hacen estudiar la mayoría fuera de la clase, pero la verdad la manera de que ken nos enseñó cosas que si podemos utilizar fuera de los salones de clase y siempre nos mantuvo guiados de una manera u otra fue lo que más me gusto del curso.
Estas dos palabras son utilizadas muy frecuentemente en el testeo de software. Verificación es el proceso de evaluar el producto para ver si cumple con las expectativas de cada parte y la validación es muy parecida pero lo que cambia es que debes de ver si una parte cumple con las expectativas es ver si todo el producto en sí las cumple.
La diferencia es en el objetivo que quieren lograr, la verificación es para comprobar si durante el desarrollo del producto se está haciendo de la manera correcta y la validación es para comprobar que el producto está terminado y listo para ser publicado o vendido.
En conclusión, estas partes del testeo de software son muy parecidas, pero ambas son necesarias para la creación eficaz y eficiente del producto.
first, I wanted to let something clear, and it is that I´m not an ISC and I actually don´t really enjoy a lot of the computing things, a lot of talks I didn´t even knew what they were all talking about. Just keep this in your head.
Also disclaimer, this was meant to be in a video but due to technical reasons I couldn´t upload it so I just transcribed it as it sounded in an attempt to not get misunderstood.
The way of teaching
First we´ll start with the way of teaching, the #FlippedClassroom. I have to say I really liked it, I´ve had another class with Ken before so I already knew what to expect more or less. Although I´m not as in love as some other people like Ken and a bunch of ISC, I think it´s a really good way of changing things a bit.
It really is a good way to draw people´s attention and hunger for knowledge, it didn´t work on me because I don´t like this things, and I kinda needed to be forced into the classroom. But I get it, ISC are like 99.999% of your students, I mean I wouldn´t have changed for me. What I´ll say is that all the passion you bring to the classes can really get contagious, and that´s the mark of a great teacher.
Ooohh also…the chats with other people were great. Again, I´m not really interested so I didn´t get the liking too much. But the majority of the group really liked them. So they must have really been interesting.
Aaahh… the blogs, if there´s one thing I really don´t enjoy are the blogs. I mean…I DID learned from them(point for the blogs) but making them
Well, this time its time to say Thank you. In our lives, we can regret plenty of different things. But I am sure one of the biggest regrets you, me and I will have, are also the most difficult ones. Not saying things on time.
Always be sure to say what you feel. Either you are happy, sad, angry, even hungry. Shout it. Never shut it up. This is really a small post but what I am feeling, what I want to say is:
THANK YOU KEN. THANK YOU FOR BEING THIS AWESOME TEACHER THAT GETS OUT THE ROUTINE TO TRY TO TEACH US SOMETHING BIGGER THAN A SIMPLE SCHOOL SUBJECT. YOU TRIED TO TEACH US A LIFE LESSON (AS IS SELF-LEARNING AND RESPONSIBILITY TO SAY AN EXAMPLE).
I CAN SAY FROM EVERYONE THAT WE ALL HAD GROWN ON A WAY. SOME PEOPLE MORE THAN OTHERS BUT AT THE END IS LEARNING AND GROWING WHICH IS THE IMPORTANT THING IN LIFE.
ALWAYS KEEP MOVING, ALWAYS KEEP LIVING, EXPLORING, LEARNING. HAVE THAT CHILD SOUL AND REMEMBER, IF THINGS ARE NOT SO GOOD; NO WORRIES. SOON EVERYTHING IS GOING TO BE ALL RIGHT.
Software is supposed to cover a user’s necessity and satisfy its requirements. For doing this, the software is supposed to evolve as the necessity itself evolves and new requirements start to surface. The process of finding new necessities and improving the software through time is called maintenance.
The purpose of maintenance is to:
Improve the design
Interface with the software
Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used
Migrate legacy software
The main characteristics of the maintainer’s activities are:
Maintaining control over the software’s day.-to-day functions
Maintaining control over software modifications
Perfecting existing functions
Identifying security threats and fixing the vulnerabilities
Preventing software performance from degrading
Types of maintenance
Corrective maintenance: Correct discovered problems. It also covers emergency maintenance
Adaptive maintenance: Performed after delivery to be sure that software remains effective
Perfective maintenance: Modifications of a software after delivery to detect errors and latent faults.
If of testing we are talking, the verification and validations are our next targets.
The terms ‘Verification‘ and ‘Validation‘ are frequently used in the software testing world but the meaning of these terms are mostly vague and debatable. You will encounter (or have encountered) all kinds of usage and interpretations of those terms, and it is our humble attempt here to distinguish between them as clearly as possible.
First of all.
The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. Its objective is to ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements.
We constantly should be asking to our self: Are we building the product right? How are we going to do this? Simple, by:
And evaluating plans, requirement specs, design specs, code and test Cases
The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements. Its objective is to ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment.
This time we need to ask: Are we building the right product? Our evaluation item is the product (software) and the way of doing it is by testing, testing testing testing.
This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now)
So now, lets talk about one important aspect when building software. We gotta have always in mind that helping the regular user have this intuitive way of using the app-software will lead us to a more successful development.
Here is where the User Interface Design comes to matter.
User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand, and use to facilitate those actions. UI brings together concepts from interaction design, visual design, and information architecture.
Users have become familiar with interface elements acting in a certain way, so try to be consistent and predictable in your choices and their layout. Doing so will help with task completion, efficiency, and satisfaction.
Input Controls: buttons, textfields, checkboxes, radio buttons, dropdown lists, list boxes, toggles, date field
Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows
Everything stems from knowing your users, including understanding their goals, skills, preferences, and tendencies. Once you know about your user, make sure to consider the following when designing your interface:
Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging.
Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly. It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site.
Software development efforts result in the delivery of a software product that satisfies user requirements. Accordingly, the software product must change or evolve. Once in operation, defects are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle begins following a warranty period or postimplementation support delivery, but maintenance activities occur much earlier
Software maintenance is an integral part of a software life cycle. However, it has not received the same degree of attention that the other phases have. Historically, software development has had a much higher profile than software maintenance in most organizations. This is now changing, as organizations strive to squeeze the most out of their software development investment by keeping software operating as long as possible. The open source paradigm has brought further attention to the issue of maintaining software artifacts developed by others.
Maintenance is needed to ensure that the software continues to satisfy user requirements. Maintenance is applicable to software that is developed using any software life cycle model (for example, spiral or linear). Software products change due to corrective and noncorrective software actions. Maintenance must be performed in order to
improve the design;
interface with other software;
adapt programs so that different hardware, software, system features, and telecommunications facilities can be used;
migrate legacy software; and
Five key characteristics comprise the maintainer’s activities:
maintaining control over the software’s day-to-day functions;
maintaining control over software modification;
perfecting existing functions;
identifying security threats and fixing security vulnerabilities; and
preventing software performance from degrading to unacceptable levels.
This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now) will be as
Humans are not perfect, and since we are the ones doing the programming, a lot of times programs have what´s known as bugs, or errors(Fun Fact: they are called bugs because way back in times of the ENIAC, what caused problems were literal bugs who crawled to the machine).
Sometimes bugs can be as disastrous as cracking your program the second you run it and ruin everything you´ve worked so hard for!!! and other times they´re not as bad, but either way the best thing to do is spray Raid over them and kill them(please don´t spread Raid ver your computer, that thing is really toxic).
Software testing is just what it sounds like, to run your own program and see how it works, so you can correct any mistakes you may have made. This is usually made in order to debug your program, or to give it maintenance(which a lot of times ´maintenance´ means a new bug was discovered). While it may seem easy, it often gives not-experienced programmers(like me) a really really hard time.
This is a huge topic and has a lot of coverage in it, so we´ll start from the beginning.
Why do we do it?
Well, first of all, a crash in your program carries a risk of damaging your hardware. Also the people funding or contracting you don´t want to pay for later debugging, because that is quite expensive. A study from the NIST in 2002 found that this is the cost of debugging at later phases of the development.
I had already heard about the privacy clause, this clause that tells you not to work for the competence for some time after you leave a company. And the author of the blog was really mad about it(I can understand, it really is a stupid tactic) but what he doesn´t say is that anyway you look at it, companies want to keep their models, their desicions, etc. to themselves, so is it really cool to do it? because there was a time when companies would hire people to go and work in other companies to get internal info. Overall I think the same as everyone, it´s bad for both sides
I´ve heard in some of my financial classes that what companies are doing now, instead of forcing people to not work somewhere else is that they´re putting a privacy clause, where you can be sued(very heavily sued) if you leak info. From what I understood, the way it works is that when the employee leaves the company, he has some time of vigilance where if they think he has leaked info(because the other company is doing something similar, or something along those lines) they can go to trial.
The thing to understand is that yes, companies care about the employees, but they also want to make money and leaked information may get their trum card overturned.