We love Open Source!

Every single software developer talks about Open Source Software. They say, I love Open Source, Have you changed that program?, I’m installing Linux! But what the hell is Open Source?! Sometimes things are hard to explain and life is better with LEGOs, so here is an explanation of what open source is…

It was not that hard. Actually Open Source is really easy to explain. Open source software is software with source code that anyone can inspect, modify, and enhance. The source part is something that only programmers see and use to improve that program by adding features to it or fixing parts that don’t always work correctly.

But with a great project comes a great responsibility. Open source is not just about improving; someone has to promote and protect all that hard job. And here is where the Open Source Initiative gets in.

Their job is to protect and promote the work of developers. They also prevent the abuse of the ideals and ethos inherent to the open source movement.

Open source doesn’t just mean access to the source code. The distribution terms of open-source software must comply with some criteria. The Open Source Definition is that criteria.

There are a lot of Open Source programs that we see daily, and maybe we should get a chance to try them, and see whats the difference. And just maybe we will transform in those Open Source freaks. No one knows.

Bloggers that blogged in this blogpost:

Miguel Cabral

Victor Najar

Carlos Pedraza

Juan Pablo Ramirez

Sources:

https://opensource.org/

https://opensource.org/osd

https://opensource.com/resources/what-open-source

Understanding Software Architecture

Software Architecture is the representation of the program that helps to understand how the software will behave. It serves as a guide for the design and the implementation teams. And is the first line of the system’s quality, such as performance, modifiability, and security. None of these could be done without an architectural vision.

By building effective architecture, you can identify design risks and mitigate them early in the development process. It also gives an approach of the final design.

Like any other complex structure, software should be done on a solid foundation. Any failure in the future could result a risk for the application.

The most important part of it, is to always consider three things: The User, The System & The Business.

Finding a valance between the desire and specifications of each will result on a good architecture, and this will lead on a great application.

But unfortunately there are major problems that are hard to decode. That’s why we always need to think about this major concerns:

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?

The goal of architecture is to identify the things that affect the structure and functionality of the application. Good architecture reduces the business risks associated with building a technical solution.

The architecture is important in everything, and when talking about software, it’s the base for a good one; you don’t want the users to be mad at you.

Source:

http://www.sei.cmu.

Continue reading →

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. And 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 →

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.

4. Sequence Diagram

Testing: a critical phase in SD.

Software testing is a phase of the Software Development Life Cycle that focuses on executing a program and finding bugs. The process should validate and verify that the program meets the functional and non-functional requirements gathered in the first stage of the process.
During testing, the developers should find out if the program meets the technical and business needs that should have guided the design and coding phases. The program should work the way it was expected to and should be able to be implemented in the next stage.

Testing can be done as a process rather that a unique activity. It should take place during the whole software life cycle in small steps, to prevent defects in the code and to verify that the design is being implemented correctly.

Testing must be planned so reports and progress can be documented and the status of a program can be defined and updated. Preparations must be made by selecting conditions and designing test cases.

Static testing can be done without executing the code and it is used to verify the source code and static analysis.

Dynamic testing is done when the code is executed so results can be demonstrated. It is done during validation, some examples are unit testing, integration testing and system testing.

Uploaded by Guru99

Evaluations must be done during the testing phase to check that the needed criteria was met and whether the software passes the needed tests and can now be launched.

Software testing is a necessary part of software development because everyone makes mistakes (we are human after all) and they should be corrected because they may lead to unnecessary risks and expensive corrections. It is good to have someone else check these mistakes because they are more likely to spot these mistakes than the original

Continue reading →

Why use Design Patterns

Design patterns are a great solution to common problems during software design . These patterns aren’t a finished design that can be directly transformed into code but a sort of template one can use to solve a problem that can be applied and customized to specific situations.

Design Patterns help speed up the development process because they provide tested development paradigms, they provide solutions for issues that are not always visible at the beginning of the development process, sometimes these issues are only visible when the projects are implemented, this makes patterns a great way to avoid certain risks during and after the Software Development Life Cycle.

Patterns are based on iteration, so code can be reused to improve readability and understandability of the program in general, to avoid problems by providing general solutions that are documented.

There are three main design pattern types:

-Creational Design Patterns
These are mostly about instantiation and the creation of classes and objects by using inheritance and delegation effectively & efficiently.

Here are some examples:
• Abstract Factory
• Builder
• Factory Method
• Object Pool
• Prototype
• Singleton

-Structural Design Patterns
These patterns are about pattern composition and structure so functional interfaces can be composed.

Here are some examples:
• Adapter
• Bridge
• Composite
• Decorator
• Façade
• Flyweight
• Private Class Data
• Proxy

-Behavioral Design Patterns
These are patterns centered on object communication between objects.
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Null Object
• Observer
• State
• Strategy
• Template Method
• Visitor

Sources:

Design Patterns

Designing our surroundings

Software Design focuses on the way internal modules or components of a system interact with each other so it is not the same thing as Software Architecture. This the “how” phase of the Software Development Life Cycle.

This process transforms the user requirements into a developer friendly understandable and specific format that the programmer(s) can later code and implement.
An SRS (Software Requirement Specification) document should be created to assess user requirements, and the design phase finds a solution to the problems planted during the requirement gathering phase.

Charis Tsevis - Calling... — Charis Tsevis –
Calling…
A mozaic with Apple products since 1998. (Best viewed large)
All photos courtesy by Apple
Made in Synthetik Studio Artist, Adobe Photoshop and Apple QuickTime Pro with custom scripts.

There are several design levels to be considered:

-Architectural Design: highest level of abstraction or a general blueprint.
-High-Level Design: a less abstracted view that focuses on how the components of a system can be implemented in modules.
-Detailed Design: Detailed designs of systems and subsystems that defines a logical structure for each module and the communication interfaces.

Some keys for good software design are:
-Modularization: Often used as a technique to divide a software system into many small segments called modules that should carry out independent tasks.
-Concurrency: Changing sequential execution into concurrent means splitting the software into independent modules that can be executed in parallel.
-Coupling: a measure for defining the level of inter-dependability between modules, for example: content, common, control, stamp and data.
-Cohesion: A measure for defining the intra-dependability of the elements of a module, for example: co-incidental, logical, temporal, procedural, etc.

Sources:

Difference between Software Architecture and Software Design

Software Design Basics

Software Requirements

In order to define what a piece of software can do, you have to define clearly the functions and requirements that it must contain for the customer to be satisfied and your team to know what to do and how.

The goal is to arrive at a Software Requirements Specification (SRS) Document, a spec sheet that details what the software can do.

Photo by Nathanael Coyne on Flickr. CC BY-NC-ND

Requirement Engineering is a discipline that aims towards understanding client's requirements and translating them into technical and detailed specifications for the developers, it consists of four basic steps:

Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION

It is an organized process to gather requirements for the software, it has four steps.

First the developer gets the requirements from the client, then they are prioritized and categorized, next they are reviewed with the stakeholders to remove any ambiguity or doubts about the requirements, finally, they are documented correctly for the next phases of development.

One or more of these methods can be Continue reading →

Software Requirements

Photo by Nathanael Coyne on Flickr. CC BY-NC-ND

Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION

It is an organized process to gather requirements for the software, it has four steps.

One or more of these methods can be Continue reading →

Software Architecture

Software architecture (not to be confused with architecture design) is mostly the externally visible components of a system.

In this phase of the Software Development Life Cycle the main concern is “what” a system should do while software Design is about “how” a system achieves its goals.
Architecture is a higher level of abstraction and it scopes all of the system, not just the modules like in the design.

Architecture is the blueprint for building the design, it aids in understanding how a certain system must behave, it must meet the technical and operational requirements. The structural elements and interfaces of the system are selected to compose the project and they are separated into modules that must later be designed.

Architecture is important because all software must have solid foundations. Common problems or failures must be detected so long term consequences can be avoided.

There are some key things to consider when building a systems architecture:

-User Empowerment
-Market Maturity
-Flexible Design
-Future Trends

Here is a video to understand the difference between software design and architecture:

Uploaded by Software Architect CA

Some software architecture styles are:

-Structure (component-based, layered)
-Shared Memory (data-centric, rule-based)
-Messaging (event-driven, asynchronous messaging)
-Adaptive Systems (plug-ins, Microkernel, reflection)
-Distributed Systems (2-tier, 3-tier, n-tier, peer2peer)

Sources:

Difference between Software Architecture and Software Design

What is Software Architecture?