Unified Modeling Language

uml_logo

 

Lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group).

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un “plano” del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

En el modelo unificado del lenguaje hay dos tipos de diagramas, los estructurados y los de comportamiento. En los de estructura se representan los conceptos más importantes de un sistema. En el caso de un programa Orientado a Objetos el más común es el que está compuesto por 3 partes, el nombre de la clase, sus atributos y métodos.

Los del comportamiento definen comunicación, secuencia, actividad, interacción etc.


Software requirements elicitation and specification

agilesoftwarerequirements

Lo primero que se tiene que hacer en el ciclo de vida del software es la educción de requerimientos, esto significa encontrar lo que el cliente o usuario desea. Una lista de requerimientos deseados donde se discute con el cliente que espera del software. Entonces se organiza la información en orden de importancia. Si hay problemas se discute y se negocia hasta llegar a un acuerdo.  Una vez que se conocen los deseos del cliente, se hacen especificaciones de los requerimientos, lo cual es el proceso de grabar los requerimientos del cliente en cualquier forma (documentos, graficas) Esto contiene los requerimientos funcionales y no funcionales entre otras cosas.

 


Functional and non-functional requirements

What is a functional requirement?

Refers mainly to the expected function of the product. Product or system features, or what the program does is what the functional requirements are. Definitely it is easier to determine the functional requirements than the non-functional because they are almost obvious.

What is a non-functional requirement?

These requirements refer mainly to the attributes that include performance, security, usability, etc. Developers usually miss these requirements because they focus mainly on the functional requirements. When addressing incorrectly these non-functional requirements, the system actually fails. For example, the lack of usability or performance can lead to frustration or system problems. This is why non-functional requirements are so important for a system to succeed.

 

 

To be more precise, in software engineer, functional requirements define the functions of the system, is the description of the feature required. It also includes description of the required functions. Some examples of functional requirements are calculations, technical details, data manipulation and processing.

Non-Functional requirements focus on quality factors and effectiveness. These factors are what give value to the software and make the functional requirements function appropriately.

 

Sqa.org.uk. (2016). Functional and Non-Functional Requirements. [online] Available at:http://www.sqa.org.uk/e-learning/SDM03CD/page_02.htm [Accessed 13 Sep. 2016].

SearchSoftwareQuality. (2016). Functional vs non-functional requirements, what is the difference?. [online] Available at:http://searchsoftwarequality.techtarget.com/answer/Functional-vs-non-functional-requirements-what-is-the-difference [Accessed 13 Sep. 2016].


Waterfall Method

The original Waterfall method, as developed by Royce, is featured in Figure 1. The steps include Requirements Determination, Design, Implementation, Verification, and Maintenance. Other models change the Requirements phase into the Idea phase (Jonasson, 2008), or break the Requirements phase out into Planning and Analysis (Hoffer, George, Valacich, 2008). Furthermore, some models further break the Design phase out into Logical and Physical Design subphases (Hoffer, et al, 2008). As previously mentioned, however, the basic underlying principles remain the same.

The Waterfall method makes the assumption that all requirements can be gathered up front during the Requirements phase (Kee, 2006). Communication with the user is front-loaded into this phase, as the Project Manager does his or her best to get a detailed understanding of the user’s requirements. Once this stage is complete, the process runs “downhill” (Hoffer, et al, 2008).

The Design phase is best described by breaking it up into Logical Design and Physical Design subphases. During the Logical Design phase, the system’s analysts makes use of the information collected in the Requirements phase to design the system independently of any hardware or software system (Hoffer, et al, 2008). Once the higher-level Logical Design is complete, the systems analyst then begins transforming it into a Physical Design dependent on the specifications of specific hardware and software technologies.

The Implementation phase is when all of the actual code is written. This phase belongs to the programmers in the Waterfall method, as they take the project requirements and specifications, and code the applications.

The Verification phase was originally called for by Royce to ensure that the project is meeting customer expectations. However, under real-world analysis and design, this stage is often ignored. The project is rolled out to the customer, and the Maintenance phase begins.

During the Maintenance phase, the customer is

Continue reading "Waterfall Method"

Agile Software Development

In the late 1990’s, several methodologies began to gain increasing public attention, each having a different combination of old and new ideas. These methodologies emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code.

The term “Agile” was applied to this collection of methodologies in early 2001 when 17 software development practitioners gathered in Snowbird, Utah to discuss their shared ideas and various approaches to software development. This joint collection of values and principles was expressed in the Manifesto for Agile Software Development and the corresponding twelve principles.

The Agile Alliance was formed shortly after this gathering to encourage practitioners to further explore and share ideas and experiences.

 

12 Principles of Agile Software Development

1

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4

Business people and developers must work together daily throughout the project.

5

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7

Working software is the primary measure of progress.

8

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9

Continuous attention to technical excellence and good design enhances agility.

10

Simplicity–the art of maximizing the amount of work not done–is essential.

11

The best architectures, requirements, and designs emerge from self-organizing teams.

Ethics in Software Engineering

When it comes to every job, there always are work ethics, and software engineering is not an exception. This is the short version.

For example, the Association for Computer Machinery (ACM) has their established code of ethics that every Software Engineer must follow:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

 

Software engineering is a relatively young practice and compared with other engineering disciplines, its culture of professionalism is still developing. This is reinforced by the fact that most engineering ethics textbooks focus primarily on ethical issues faced by civil, mechanical or elecrical engineers. But software engineers build lines of code, not cars, rockets

Continue reading "Ethics in Software Engineering"

Software Engineering Historayyy lmao

Back in the good ol’ days where I wasn’t born and maybe you weren´t either, I’m talking about the 50’s and 60’s, software was delivered by hand and tested for a few hours before they could have the results back. The first widely used programming language was Fortran by your holyness IBM in 1957, along with Cobol, released by the US Department of Defense in 1962. But the processes of making software were still very slow and people accepted that they didn’t have the best methods, which led to something they called a Software Crisis, so in 1968 a conference was organized to find better ways of doing programming magic. At this conference is were the roots of Software Engineering were finally established.

Over the following decades, the discipline of programming saw a familiar tension between the scientific field, who gave the ideas of how to solve engineering challenges, and the crafty men that solved the practical needs of an industry faced with real-life time and cost pressures. Over the time more ideas came around, at the 80’s Object Oriented Programming came up as well as the use of GUIs to make interaction with the machine easier.

The next years leading up to these days the computing power of the machines programmers used was increased significantly,  but many don’t see this as a good thing, because before you had to write code as efficiently as possible with the little things you had, and now with so much capacity and memory, the quality of code has been downgrading leading up to wasteful software. Even if this phenomenon is true, recent years have been when there has been such an incredible development in the software industries, with the introduction of the Cloud, APIs and almost every industry realizing that they needed online presence

Continue reading "Software Engineering Historayyy lmao"

Software Development Life-cycle

The Software Development Life-cycle (SDLC) is a structured sequence of stages in software engineering that are followed in order to complete the desired software. A similar kind of system can also be applied to hardware configurations and processes. An example of a SDLC is Scrum, which I have previously written about, however there exist a gazillion other methods that are used, although some more popular than others.

Making software is like creating a new magic spell:

  • Preliminary Analysis: An analysis is made to see wether the preview of the proposed solution is viable, also looking at the possiblity of a different but equally feasable solution.
  • Systems Analysis: On this step the accepted idea is described, taking into account the organizational goals, facts and problems that could come up with the development. Suggestions to improve the proposed system are also made and included into the project if found useful.
  • Systems Design: The idea is now given shape, describing it in more deeply,  with layouts, diagrams and pseudocode , along with the business implications.
  • Development: Programming magic is done here.
  • Integration and testing: The magic is now brought into an enclosed space where it can be tested without harming anyone, looking for any mistakes that could break the space-time or something like that and fixing them.
  • Acceptance, installation and deployment: This is the final stage of developing your spell, where you teach other people (the organization’s system) the magic and they get to use it.
  • Maintenance: There is always room for improvement, specially with magic, you must keep your software up to date so it doesn’t become obsolete. On this step you can make changes to your initial software.
  • Evaluation: On this step, both the whole process of creating the system that was put in place and the system itself are evaluated in order
    Continue reading "Software Development Life-cycle"

Scrum Framework in Software Engineering

 

This post is a continuation of the post by José Manuel Salazar, which you can see over here.

Scrum Roles

Scrum is based on three roles that have different purposes:

  • Product Owner: The Product Owner is a person with vision, authority and availability. He/she is responsible for telling the team what to do and guiding them towards their goal. A Product Owner must not get too involved and let the team work as a self-sustained entity.
  • Scrum Master: The Scrum Master is the connection between the Product Owner and the team, however the master is not a manager in any way, this role’s function is to prevent the team from getting stuck and facilitating their sprint to victory. The Scrum Master will also show the Product Owner the successes of the team’s development process.
  • Team: The team is responsible for their own work and how they get organized, a scrum development team contains about seven dedicated members, but it usually can contain from three up to nine members.

The Sprint

The Scrum Framework is based on sprints, which are periods of time where the team goes at it with their project, these periods of time are usually one to four weeks long, the product is kept in a potentially shippable state at all times and at the end of each sprint, stakeholders and members meet to see the product so far and plan the next steps.

 

 

 


Software Engineering: Art, Craft or Science?

Software Engineering is becoming very popular this days and there is some discussion about wether creating software should be considered an art, a craft or a science. All answers seem reasonable so let’s take a look.

Let’s start with the difference between art, craft and science. Art is the way of representing and showing knowledge, art is subjective while science is about acquiring that knowledge and being as objective and exact as possible while a craft is considered an activity involving skill in making things by hand. Now, the name might make some people be biased, when you think about engineering you think about complex stuff and science however I think that Software Engineering implies a little of each three of the categories.

When people wonder about wether software engineering is an art, a craft or a science, it is a science because we try to follow formal approaches when possible and reasonable, it is a craft because experience and practice makes the master and it is an art because there are situations that leave room for creative and even artistic solutions.