User Interface Design

User Interface Design can be resumed in one word: anticipation. We are all users and when we design an interface we should remember: what is the user going to need to do? are the elements easy to access, understando and to use?

What are the best practices for designing an interface?

Keep the interface simple. Best interfaces are invisible, if the design is successful the user can focus in their own goals.
Create consistency and use common elements. Create patterns in language, layout and design throughout the site to facilitate efficiency.
Strategically use color and texture. Color should not determine much in an interface, it can be used for highlighting.
Use typography to create hierarchy and clarity.
Interfaces exists to enable interaction, they are designed to do specific jobs.
Conserve attention at all costs.
Keep users in control by infoming them about the system status.
Every screen we design should support a single action of real value to the user.
Provide a natural next step, anticipate what the next interaction will be.
Appearance follows behavior, someone should be able to predict how an interface element will behave merely by looking at it.

Source:

Software design patterns

As software engineers, we all should already know that, when working on a new project, you start by establishing the way of attacking-solving the problem or software to develop. So it is important to get there are these things called patterns (software design patterns) which may help you as a guide to your way of working.

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

There are three design patterns we are going to talk about.

Structural

In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities, making it easier for these to work together.

Adapter
Match interfaces of different classes
Bridge
Separates an object’s interface from its implementation
Composite
A tree structure of simple and composite objects
Decorator
Add responsibilities to objects dynamically
Facade
A single class that represents an entire subsystem
Flyweight
A fine-grained instance used for efficient sharing
Private Class Data

Restricts accessor/mutator access
Proxy
An object representing another object

Creational

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

Abstract Factory
Creates an instance of several families of classes
Builder
Separates object construction from its representation
Factory Method
Creates an instance of several derived classes
Object Pool
Avoid expensive acquisition and release of resources by recycling objects

Continue reading "Software design patterns" →

One brick at a time- Software Architecture

What is software architecture?

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:

“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”

Architectural Landscape

User empowerment. A design that supports user empowerment is flexible, configurable, and focused on the user experience. Design your application with appropriate levels of user personalization and options in mind. Allow the user to define how they interact with your application instead of dictating to them, but do not overload them with unnecessary options and settings that can lead to confusion. Understand the key scenarios and make them as simple as possible; make it easy to find information and use the application.
Market maturity. Take advantage of market maturity by taking advantage of existing platform and technology options. Build on higher level application frameworks where it makes sense, so that you can focus on what is uniquely valuable in your application rather

Continue reading "One brick at a time- Software Architecture" →

Bibidi Badi-Software Design

What is software design?

It is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.

Software design may refer to either “all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems” or “the activity following requirements specification and before programming, as a stylized software engineering process.”

Software design usually involves problem solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.

There are several basic design principles that enable the software engineer to navigate the design process:

The design process should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.
The design should be traceable to the analysis model. Because a single element of the design model can often be traced back to multiple requirements, it is necessary to have a means for tracking how requirements have been satisﬁed by the design model.
The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited; design time should be invested in representing truly new ideas and integrating patterns that already exist when applicable.
The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain.
The design should exhibit uniformity and integration. A design is uniform if it appears fully coherent.

Continue reading "Bibidi Badi-Software Design" →

Let’s learn about some requirements

In software engineering, we have plenty kind of requirements, but in this blog we are really interested in to kinds of them. The software requirements elicitation and software requirements specification.

Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as “requirement gathering”.

The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:

‘Problems of scope’. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:

Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the

Continue reading "Let’s learn about some requirements" →

Don’t forget Maintenance

http://www.itservicemanagement-itil.com/software-maintenance-from-a-service-perspective/

In the software development lifecycle, the last phase (but not least) is Maintenance. Once you delivered software, defects are uncovered, environments might change and new requirementes will appear; thus, software maintenance is necessary. Its objective is to modify existing software while preserving its integrity. It’s also important to apply maintenance activities before the final delivery of software.

Maintenance consumes a major share of the financial resources in a software life cycle. I suppose its because it has no end (or until Retirement).

There are key issues that must be covered to ensure a good maintenance, basically they are:

Technical issues
Management issues
Cost estimation
Measurement

Techniques of Software Maintenance:

Program comprehension: To read and understand programs in order to implement modifications.
Reengineering: To alterate software to reconstitute it in a new form and to implement it. Refactoring is a reengineering technique that reorginizes the program without changing its behavior.
Reverse engineering: To identify software’s components and their relantionships to reach higher levels of abstraction. Its purpose is to produce graphs from source code.
Migration: To modify software so it can run in different enviroments.
Retirement: When software reaches the end of its useful life. A previous analysis must be done to make the retirement decision.

As you can see, maintenance can be the most important phaste of the lifecycle, without it, the previous steps won’t be used to the maximum.

Source:

http://swebokwiki.org/Chapter_5:_Software_Maintenance

Why is open source good for you?

3ea640b — https://www.linkedin.com/topic/open-source-software

Open source is software with source code that anyone can inspect, modify and enhance. A reason why software engineering has grown so much is open source. Because this type of sofware lets other people improve and utilize code that can be useful for themselves and for the owner of that software. That leads us to a circle of improvement and innovation in this discipline.

There are also another reasons why people like open source software, such as:

Control: you can examine the code and modify it as much as you want to.
Training: it helps people to become better programmers. The accessibility of this type of software let programmers to study and learn to make better software.
Security: Because anyone can view and modify open source software, then it is fixed, updated and upgraded more quickly than propietary software.

“Open source vaules and principles apply to the world beyond software. We like to think of open source as not only a way to develop and license computer software, but also an attitude” (From opensource.com)

The relevance of open source is to share. Sharing is what helping this industry to become better everyday.

Source:

Software implementation

Software implementation is all about bringing clarity in the code, improving its efficiency, reducing coding time and helping others to understand it.

There are different programming techniques, such as:

Structured programming: it encourages the developer to use subroutines and loops instead of using simple jumps in the code.
Top-down analysis: the problem is broken down into small pieces and each one is solved individually.
Modular programming: the code is broken into smaller group of instructions.
Structured coding. it sub-divides the modules into further smaller units of code.
Functional programming: it uses the concepts of mathematical functions. Functions can be first class and high order, pure, recursive, strict…

Clearly, these techniques are related and can be used in the same code.

Also, is very important to have a good programming style, which is set of coding rules followed by all the programmers to write the code. Most of the time, programmers must work with other people, who will use codes written by other developers. So it’s relevant to make programs readable and understandable.

Source:

Design is everything

softwaredesigncomic2 — http://www.benhallbenhall.com/2012/07/483/

While I was doing a research abour sofware design, I found a really interesting article by Jack Reeves, who describes a new perspective about this topic.

What do we think about when we hear software design? Well, I think about design patterns and diagrams, which it’s okay. But the article says something different that I like more.

In the software lifecycle we have design, implementation, testing,… And the coding part seems to be in the software implementation, but with extreme programming everything changes, because while you’re implementing you also design, then test, redesign, and so on.

The author of the article says that “real software runs on computers[…] it is not a program listing in C++”. That means the program itself represent a software design. Makes sense? So, practically every sept of a software project is part of the design process.

This idea matches the one discussed in my post about software being an engineering or a craft. The important thing is to know that the real purpose is to help people accomplishing a task.

Source:

http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

User interface design

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.

Choosing Interface Elements

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. Interface elements include but are not limited to:

Input Controls: buttons, text fields, checkboxes, radio buttons, dropdown lists, list boxes, toggles, date field
Navigational Components: breadcrumb, slider, search field, pagination, slider, tags, icons
Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows
Containers: accordion

Best Practices for Designing an Interface

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.
Be purposeful in page layout. Consider the spatial relationships between items on the page and structure the page based on importance.
Strategically use color and texture. You can direct attention toward or redirect attention away from items using color, light, contrast, and texture to your advantage.
Use typography to create hierarchy and clarity. Carefully consider how you use typeface. Different sizes, fonts, and arrangement of the text to help increase scanability, legibility and readability.
Make sure that the system communicates what’s happening. Always inform your users of location, actions, changes

Continue reading "User interface design" →