Software Verification and Validation

Although validation and verification might mean the same, they are two different concepts that are used in software engineering.  Just to avoid confusion, everything can be narrowed to this:

Validation: Are we building the right system?

Verification: Are we building the system right?

It is true that both of them require approval, but it dependes on the type of approval you need. Validation checks that what is being done, is what we need. This has to do with complying with the requirements that are proposed by the project managers. Verification, in the other hand, is to check that what we are doing, is being done the correct way. It is all about complying the requirements, so everything converges on reading the requirements the good way.

I’m might contradict myself a bit, but verification and validation do have things in common. These are processes in order to assure software quality and guess what, it also has to do with software testing and evaluation. This is a diagram of what could comprehend each of the concepts, and also what they do have in common.

 

Credit to Easterbrook, from here I obtained most of this content.


Just keep it simple.

User Interface, what is it ? It is not only where they can interact and write commands, like in terminal, in fact, bash and terminal applications are user interfaces. But not everyone is as tech savvy as others. So that’s why we must take the final user into account. Not only because it is he the one who pays, but also the one you must help. So, long story, short UIs are:

The means by which the user and a computer system interact, in particular the use of input devices and software.

This concept is something that changes across history, we didn’t have those cool transparency effects on the Mac Lisa. Developers have adapted to what the user needs and their experience. By the way, this experience is called User Experience (UX) and it has a strong link with UI Design. In fact, design provides the experience. These two concepts transcend much  more than simple software. It applies for OS, software, websites and also hardware such as phones and home appliances. There are several tools to test the UX and all of them involves human interaction.

The Basics: Do’s and Dont’s

There are a few things you might want to take into consideration for your software projects. These are some guidelines (not rules). 

  • Remember that you are not the final user, so don’t assume anything. Do not assume the user knows how to even turn on the device. Yep, not even that.
  • Keep it simple. Yes, that simple.
  • Be consistent in all possible ways. Do not mix layouts, colors, styles. It is all part of a whole interface, so different styles or layouts might confuse the user if done.
  • Let the user know what’s happening. I don’t mean to have a console log , but let the
    Continue reading "Just keep it simple."

Open Source Software != Free Software

Open source software refers to software that is widely available. But it doesn’t stop there. With O.S.S. programmers and developers can modify and share it. And this is the most wonderful benefit from O.S.S. When software is open, people can distribute as much as they want to, but always giving credit to the author. ALWAYS. 

Open source projects, products, or initiatives embrace and celebrate principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development.

While this doesn’t mean you can copy it and sell it as if it was yours, you can learn from it. You can grab a piece of code and use it (again, giving credit) freely. According to the ACM Code of Ethics, it is not fair to obtain a profit out of someone else’s work. You wouldn’t like,  or do you ?

Talking about profit, the fact that O.S.S. is widely available doesn’t mean that it is free. Don’t worry, it is a common misconception. Some developers charge for O.S.S. and you still get all benefits from O.S.S. You can see it as a way to credit the author.


Software Development Tools and Resources

Activity for class. Thanks Carmina for making this post

The TC1019 Experience

20161028_091003

To work on a Software Development project one needs basic resources and good communication with the team, which are just as important as programming tools and a software development defined process.

Team:

Miguel Angel Cabral

Juan Pablo Ramirez

Diego Gracia

Carmina Pérez

View original post


Software Requirements…and stuff

As easy as it sounds, software requirements are requirements for software. But let’s dig a little bit deeper. Requirements are not only the functions required, actually this might be the least of the concerns in terms of requirements.  Requirements must surpass all of the client’s expectations.

There’s even a science in charged of this analysis; and it is called Requirement Engineering  its goal is to develop a very very very special and important document called the System Requirements Specification.

It involves mainly four steps, although there are text that claim it to be more than that and they are:

  • Feasibility Study:  This is the initial stage. In this one, the requirement engineer must meet the client in order to talk about the general expectations. Then, he produces a very wide and thorough analysis on the possible constrains, implementation cost, and objectives. It also explores the technical aspects of the project wit the future always in mind.
  • Requirement Gathering: This is the solid, concrete and full list of requirements. Usually, this list contains the explicit requirements and specifications of the project.
  • Software Requirement Specification: This is the formal and official document I talked about in the introduction. This is a natural language document in which all the interactions must be stated. And by all, I mean it. Every single interaction between hardware and software must be in there. Cross-plattform specification, security, limitations, maintainability must be there too.
  • Software Requirement Validation: All the previous was never validated nor analyzed. In this stage, the document is impressively analyzed. All variables are taken into account, feasibility, ethics, security, ambiguities, cost and many others. This is the most important stage, because what is stated in this final revision is what devs are going to work with.

There are several types of requirements, (mainly two, read more

Continue reading "Software Requirements…and stuff"

Software Design: Patterns

Carlos Pe.

As we know, software design isn’t the code itself but the way that code must be structured in order to have a higher level of control over it. Patterns themselves are repeatable solutions to problems that occur constantly in software design. These type of structured ways of designing software aren’t finished designs that can be already transformed into code but they are descriptions that show how to solve certain problems. They are normally templates used in order to have a richer idea on what it will be developed in the future.

There are mainly 3 types of design patterns:

  • Creational design

    These patterns approach design by the instantiation of classes. They are divided in class creation which inherit in the instantiation step and object creational patterns that use delegation as it should be in order to achieve certain task. Some of these are:

    • Abstract Factory
    • Builder
    • Factory Method
    • Object Pool
    • Prototype
    • Singleton

View original post 114 more words


Software Architecture

 

 

Software Architecture is the way software solutions are structured for all the project itself. Software architecture takes into account all of the aspects. It takes into account performance, security, quality and plenty of other stuff including the requirements asked by the client. Just as in a house or a building, software must have solid foundation. Not taking into account all of the requirements can lead to expensive delays. Delays might be the best-case scenario, because sooner or later, it’s going to be fixed, but if engineers just ignore the  requirements, this can lead to unhappy customers that have poor, lame, and unstable software. Also, your job might be in a risk.

When designing the blueprints of the software you must take into consideration three things, the final user, the company goals, and the platform itself. ic350999And most important, they all have the same weight while taking decisions. There are no biased decisions in this topic. They all weigh the same because each one impacts the others in a certain way. For example, if the system is more complex, we might need the final user interface to be even more friendly due to the business requirements.

When designing the structure, the developers might want to take a look to the following questions.

  • How will the users be using the application
  • How will the application be deployed into production and managed?
  • What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
  • How can the application be designed to be flexible and maintainable over time?
  • What are the architectural trends that might impact your application now or after it has been deployed?

When the project team has all of these answered, now, it’s time to begin. Once we all know all of the project

Continue reading "Software Architecture"

UML: The Best Diagrams

1. Class Diagram

2. Activity Diagram

3. Deployment UML Diagram

In these type of diagrams, developers focus in the interaction between hardware and software. It is commonly used in network environments. It involves allof the harwdare equipment, from a single ethernet socket, all the way to racks from a data center, but it also involves databases, the software itself and many other things. This diagram is more useful when working with more than just code, and when you need interaction between hardware and software. Below you can find an example of a deployment diagram for a university.

uml-diagrams-10-638

4. Sequence Diagram


Application Programming Interfaces (API)

Natively, APIs are tools for other apps to communicate with each other. APIs started to grow since 2000. You might think that 16 years is a lot for technology growth. But APIs, natively, do the same stuff. The unique difference is that there are much more now, than 16 years ago. And obviously, they are much more complex, yet easier, to use. 

Some famous APIs are developed by huge companies like Google, Facebook, Twitter…etc Google is a really diverse company, and guess what, it has an API for every single product they offer (Ads, Google Maps, Google Drive, Search, YouTube, Google+, and much more).

 

You might think that only huge Silicon Valley companies have APIs, but NO. There are plenty of smaller companies that also have their APIs available to everyone in the world.

APIs are one of the most important things when a new startup emerges, APIs allow developers to build something cool that might be useful for the startup product.

For example, Phillips Hue has their API available for making third-party apps that might exploit all the possibilities that Hue has to offer. There are awesome things you can try just by using an API.

APIs work for web, mobile devices, and computer software. You can use Amazon on your site, tweet from your site, and much more things you can do with the use of APIs.

When you are thinking about something awesome, and start worrying about how to implement it, believe me, there is an API for that.

With APIs, possibilities are limitless.

 

Easter Egg: Check out this amazing API for IBM’s Watson.

 


Software Quality Testing

Quality is not only for handcrafts and arts, it is also involved in software engineering. Apparently, quality might be something quite immeasurable, but in reality, there are several ways to measure it in software. To accomplish this, there are mainly two methods for testing quality: defect and attributes. The latter being the most popular.

The defects approach is focused on determining the quality by counting the amount of defects, failure or lack of requirements. They are measured by their severity, likeliness to happen, and damage implications of the defect.

On the other hand, the attributes method focuses more on features and development quality itself. This method takes into consideration five main software characteristics:

  • Effectiveness
  • Efficiency
  • Satisfaction
  • Safety
  • Usability

Each one of them provides an insight on how each category performs throughout runtime process.

Software Quality Testing is one of the most important steps before releasing a new product. This phase marks the success of the product, because the testers are commonly the end user.