Software design

This entry will be short because it is just a defining post. In the following posts, I will explain software design details.

What is software design? It is indeed the first step of the SDLC. But aside from that, what is it? Well, desingning software means transforming requirements (oh, the important requirements) into something more concrete.

There are different levels of design, from more abstract to more concrete:

Architectural: components of the software
High level: modularization of the components
Detailed: interaction between components

flickr photo by ViaMoi https://flickr.com/photos/viamoi/3638697162 shared under a Creative Commons (BY-NC-ND) license

Unified Modeling Language

When one writes a small project, documentation and standards aren’t that important. But if the number of lines becomes bigger, documentation and standards are a “must”. In the standards, one of the most used is UML.

UML stands for Unified Modeling Language. Its main objective is to maintain an order in big projects. It is focused mainly on object oriented (OO) projects (those build in C#, Java, Ruby…), but it can also work with non OO projects (VB, Javascript…).

UML allows to build:

Structure diagrams: class, object, component…
Behavior diagrams: use case, activity, state machine…
Interaction diagrams: communication, sequence, timing…

UML as itself is not programming. It sets up the bases of the project, but it does not implement the funcionality of it.

flickr photo by yukop https://flickr.com/photos/yukop/7548393976 shared under a Creative Commons (BY-SA) license

Software requirements elicitation

After reading several of my past entries, one can conclude that some of the most important things in software engineering is the requirements analysis and the requirements themselves. In fact, this is the one post in which I talk even more about them. Why? Because requirements are a part of the software purpose. And developing software without a purpose is not only useless and illogical, but also stupid.

If you haven’t read any other of my articles, you might want to start here. Software requirements are requirements made by the customer and the public for a particular software to develop. They are not static: they can change, evolve in time. One day, the customer wants a rubber duck. Another, he wants a stone duck. Maybe one day he wants a laser gun.

The process to requirements is divided into 4 steps:

Feasability analysis: Is it possible to be developed? Is the customer not asking for Godzilla?
Requierement gathering: The team listens to the customer’s requirements.
Requirement specification: This is the same that in past step, but more specific. Example: the user asked for a tool to make sales report. In this step, he says that the tool must have the funcionality to make reports by different dates.
Requirement validation: After listening to the client, the team talks by itself and goes back to the client to check if the requirements are feasible, to check there are no misunderstandings, etc.

flickr photo by ljguitar https://flickr.com/photos/ljguitar/7697808370 shared under a Creative Commons (BY) license

Functional and nonfunctional requirements

When a software developer begins with a project, he needs to establish objectives. Some of them are client requirements. These can be classified as functional or nonfunctional. And no, nonfunctional does not mean they are useless or not that important.

A requirement is functional when it must do something. It’s not a static requirement. Example: the product must include an automatic backup tool.

On the other hand, a requirement turns out to be nonfunctional when it’s not precisely a function of the program, but rather a characteristic of it. Example: the product must have SSL.

An easier way to understand this is by taking the OOP focus: functional requirements are the same as methods, as well as nonfunctional requirements are the same as properties.

flickr photo by ollesvensson https://flickr.com/photos/ollesvensson/3335131082 shared under a Creative Commons (BY) license

Brief history of software engineering

This is going to be a short entry, given the nature of the topic and that many of this ideas will be talked about in future articles.

It is called “engineering” because early practitioners wanted to call it “software physics,” but that term was already in use. They wanted to call it software physics because they believed that the process of producing software could be formalized with such rigor that it would be on all fours with physics. Indeed, texts from the ’80s are populated with theories, derivations, tables, graphs, equations and formulae, apparently in an attempt to appear mathematical and scientific in nature (Curran, B. 2001).

Software engineering milestones:

1960’s – Software crysis: software was developed in a poor way, mainly in languages such as Fortran and Cobol. And, as the power of hardware became better, more complex programs were required.
1980’s – OOP: the magic starts. With OOP, programmers were able to write more readable and changes-friendly code as well as GUIs.
1990’s – Internet & HTML: With this, software began being uploaded. And with this, free software was born.
Today – Cloud computing and IoT are just some of the few technologies in the 201o’s.

flickr photo by wizzer2801 https://flickr.com/photos/wizzer/5357865167 shared under a Creative Commons (BY-NC-ND) license

Sources:

Curran, B. (October, 2001). What is Software Engineering?. Ubiquity. Read at: http://ubiquity.acm.org/article.cfm?id=763745
https://www.vikingcodeschool.com/software-engineering-basics/a-brief-history-of-software-engineering

Software Configuration Management

SCM article written on teams.

Hermes's Blog

Statistics:

53% of software projects overrun their schedules and budgets
31% are cancelled
Only 16% are completed
Projects made by large American software companies approximate to only 42% of clients’ requests.

Source: Keyes, J. (2004). Software Configuration Management. Boca Raton: Auerbach

SCM basic tasks:

Development and production of:

Configuration identification
Configuration change control
Configuration status accounting
Configuration auditis

Integration: consists on putting together the individual software parts in one single big project.

Types:

Merge: parallel development on the same stuff
Assembly: development of different pieces

Resultado de imagen para software configuration management

Software Configuration Management started in the 1950s, when configuration management, that was used for hardware and production control, was applied in software development.

Nearly all components that comprise modern information technology, such as Computer Aided Software Engineering (CASE) tools, Enterprise Application Integration (EAI) environments, Extract/Transform/Load (ETL) engines, Warehouses, EII, and Business Intelligence (BI), contain a great deal of metadata as well as his own repository…

View original post 370 more words

Software developing ethics

Every profession, in order to be professional (oh, I love recursion), must work with ethical principles. Software engineering is not the exception. Why? Because, without a code of ethics (CoE from now on).

In my particular case, I’ve chosen the ACM CoE. It talks about the relationship of the software engineer with several people. You can find it here. But, here’s a summary:

Public (people who use your software): Your products need to be consistent on what the public wants.
Client and employer (the ones who pay): The product must also satisfy their demands, without forgetting about the public.
Product (what you build): Produce quality products. Don’t write shitty code.
Judgment (what you think and do): Keep dignity and integrity.
Management (your subordinates): Pass this code and be sure it’s followed up.
Profession (what you do): Act professional, as in every other job.
Colleagues (other programmers with which you may or may not work): Support them, they are allies.
One self: Keep learning. Never stop studying.

If you want a summary of the summary, here’s this twitter:

ACM CoE Twitter summary: Code for the people & the client, code well, don't be an asshole & keep learning. #TC1019

— Miguel Miranda (@mmiranda_96) September 14, 2016

flickr photo by Medialab Prado https://flickr.com/photos/medialab-prado/14391836308 shared under a Creative Commons (BY-SA) license

Software Development Life Cycle

In this world, things tend to behave as cycles. We have a new president every 6 years, which it seems, does no difference, but we go through the same process. Every year we start with great promises, and as soon as time goes, we forget them.

Software development is not an exception. Why? Because even the best developed program can fail, not because it’s bad, but because people’s needs change. This scheme tries to generalize development in general: not focusing on details such as roles, time lapses and more. Instead, it breaks software development into 5 simple steps (some sources believe 6 or even 7):

Planning: What do you need? How will you develop?
Design: Are we using NoSQL this time? Is RoR better than Django? Is a binary tree better than a hash table?
Implementation: Coding, coding, coding…
Testing: Not only PEBCAKs tend to happen. Let’s prevent the ones in our side.
Evolution: This might be the hardest step to explain. Basically, software prepares for the next cycle.

One can notice this pattern in the waterfall method such as in agile development.

flickr photo by Sam Howzit https://flickr.com/photos/aloha75/7778968110 shared under a Creative Commons (BY) license

Agile development

Can one produce software the same way as cars are made in a factory? Is the sequential process efficient for ambiguous requirements?

flickr photo by cyclonebill https://flickr.com/photos/cyclonebill/2905044002 shared under a Creative Commons (BY-SA) license

Agile development is an alternative to traditional sequential development. It was purposed in 1970 by Dr. Winston Royce in his paper “Managing the Development of Large Software Systems”. He mentioned that this process does not work because the communication between each specialized group tends to fail. Also, sequential process supposes that all the requirements can be determined in the beginning, and this seldom happens. Sometimes, the requirements change, and in the production phase, the requirements may have changed completely, making the product completely useless.

Agile development is based on 12 principles, which can be found in the Agile Manifesto page:

Satisfying the customer during all phases.
Be ready for changes.
Deliver constantly. Don’t wait at the end.
Business people and developers work together.
Motivate employees. Make them feel like fish in sea.
Face-to-face conversation does matter.
Working software measures the progress.
Sustainability is essential.
Focus on good design and technical details.
Simplicity.
Teams organize by themselves.
Regular intervals of time make coordination and feedback better.

Agile development has several benefits over sequential development, which include:

Prevents analysis paralysis: this is one of the main problems in sequential development. You have made the requirements analysis and you’re building software, but in another step, you realize that several requirements have changed or have been added. You need to make another analysis in order to keep working. This does not happen in agile, since analysis is a step in every sprint.
Allows client to have a product every time: because of the sprints, each iteration returns a product, each time better. In this way, the client does not needs to wait until production phase.
Continue reading "Agile development" →

What is software engineering?

One cannot bake a cake without knowing what is a cake. Therefore, why should we study software engineering without knowing what is that?

flickr photo by James Cridland https://flickr.com/photos/jamescridland/5734151121 shared under a Creative Commons (BY) license

According to the ACM, software engineering “is concerned with developing and maintaining software systems that behave reliably and efficiently, are affordable to develop and maintain, and satisfy all the requirements that customers have defined for them” (2006). This definition, althrough complete, is confusing. Let’s split it by parts:

“developing and maintaining” – Software developing does not limits to developing.
“software systems” – This is obvious.
“that behave reliably and efficiently” – Is inefficient and/or unreliable software still software?
“are affordable to develop and maintain” – Sometimes starting from zero is easier.
“and satisfy all the requirements that customers have defined for them” – Software is built upon requirements. Otherwise, it’s not focused on customers.

I’ll stick with the definition by ACM to build my own definition.

Software engineering requires applying multiple areas to the building of software. This does not limit only to computing, but also science, industrial production and even art.

Science: Computer science is a thing. Algorithm analysis, pipelining, computer architecture, for mentioning some, are areas that relate directly.
Industrial production: Software engineering is a process, and as a process, it can be optimized in order to obtain better results with less resources (including time). This optimization can be compared to some non-software industries, which search for the closest path to perfection.
Art: Building software requires creativity. It requires to visualize complex things into simple solutions. I believe that a well written piece of code can be compared to a poem; an example can be found in Perl, which is a language that allows ofubuscated code, making a simple code quite hard to read. On the other side, some

Continue reading "What is software engineering?" →