Tag: #teamwork

UML

Unified Modeling Language (UML) is not a program language that where you can write code and create something that a computer will understand; but is a way to represent, build or record the elements of an oriented object software.

“Modeling is the designing of software applications before coding.”
                                    Says UML.org

In UML you design diagrams that can contain different elements of the software, for example, the most common is the one where you write the name of the class, its attributes and its methods. But it all depends of the diagram you use. In UML there are many different diagrams with different uses and elements that you can write.

Is not necessary to become an expert of UML because is not actually a must for learning actual coding, but is important to know about it because it helps in the design part of software. Creating an UML diagram is like drawing a sketch, is not that important and is unnecessary to put much effort on it, just with understanding the idea is enough.

There are many UML diagrams (13 to be exactly) so in the next section there are only the three most important.

Activity Diagram:

Activity Diagrams are used to design complex methods. It describes phases or activities done by the computer or an user. They are also used to describe business processes in a single usage scenario. They look a lot like flowcharts, actually, activity diagram is an upgraded version of flowcharts. Take a look at this example:
https://farm4.static.flickr.com/3522/3204423336_d1ff94dab3.jpg


flickr photo by jean-louis zimmermann https://flickr.com/photos/jeanlouis_zimmermann/3204423336 shared under a Creative Commons (BY) license

This example describe a generic shop process. As you can see some task are only for a specific agent and reading it is really Continue reading "UML" →

UML

Unified Modeling Language (UML) is not a program language that where you can write code and create something that a computer will understand; but is a way to represent, build or record the elements of an oriented object software.

“Modeling is the designing of software applications before coding.”
                                    Says UML.org

In UML you design diagrams that can contain different elements of the software, for example, the most common is the one where you write the name of the class, its attributes and its methods. But it all depends of the diagram you use. In UML there are many different diagrams with different uses and elements that you can write.

Is not necessary to become an expert of UML because is not actually a must for learning actual coding, but is important to know about it because it helps in the design part of software. Creating an UML diagram is like drawing a sketch, is not that important and is unnecessary to put much effort on it, just with understanding the idea is enough.

There are many UML diagrams (13 to be exactly) so in the next section there are only the three most important.

Activity Diagram:

Activity Diagrams are used to design complex methods. It describes phases or activities done by the computer or an user. They are also used to describe business processes in a single usage scenario. They look a lot like flowcharts, actually, activity diagram is an upgraded version of flowcharts. Take a look at this example:
https://farm4.static.flickr.com/3522/3204423336_d1ff94dab3.jpg


flickr photo by jean-louis zimmermann https://flickr.com/photos/jeanlouis_zimmermann/3204423336 shared under a Creative Commons (BY) license

This example describe a generic shop process. As you can see some task are only for a specific agent and reading it is really Continue reading "UML" →

Team talk about Agile Development

Today on Ken´s Class we talked about Agile Development.

Image result for agile

Agile Development is a methodology that was presented in the Agile Manifesto wrote in 2001. Gerardo Juarez and me discussed about the main principles about Agile Development presented in the manifesto. Agile Development was made to make the process of developing a software faster with only the functionla part, it is also about group collaboration and open communication with the customer.

The Agile Manifesto propose 12 principles to follow this methodology:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly 
It is also very important to say that Agile Development works in cycles. There is a time set for accomplishing short goals, after the time has ended the team shows their work to the customer so that him/she can give feedback. This cycle repeats until the job is done.

We think that Agile Development is very useful because it is about delivering only the functional part of the software, the design comes later, the simpliest the better. It is also useful when the customer is not sure about what he/she wants because it allows the team to change constantly during the elaboration of the program. Some disadvantages that some people
flickr photo by cote https://flickr.com/photos/cote/63914774 shared under a Creative Commons (BY) license
Continue reading "Team talk about Agile Development" →

Team talk about Agile Development

Today on Ken´s Class we talked about Agile Development.

Image result for agile

Agile Development is a methodology that was presented in the Agile Manifesto wrote in 2001. Gerardo Juarez and me discussed about the main principles about Agile Development presented in the manifesto. Agile Development was made to make the process of developing a software faster with only the functionla part, it is also about group collaboration and open communication with the customer.

The Agile Manifesto propose 12 principles to follow this methodology:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly 
It is also very important to say that Agile Development works in cycles. There is a time set for accomplishing short goals, after the time has ended the team shows their work to the customer so that him/she can give feedback. This cycle repeats until the job is done.

We think that Agile Development is very useful because it is about delivering only the functional part of the software, the design comes later, the simpliest the better. It is also useful when the customer is not sure about what he/she wants because it allows the team to change constantly during the elaboration of the program. Some disadvantages that some people
flickr photo by cote https://flickr.com/photos/cote/63914774 shared under a Creative Commons (BY) license
Continue reading "Team talk about Agile Development" →

Group talk about Ethics in Software Engineering



Today we talked about ethics in ken´s class.

Frida, Sara, José Manuel, Estefy, Hermes and me discussed what are ethics and why we need them while making software.

Ethics are important in software engineering because they contribute to society and human well-being, be honest and trusworthly, be fair, honor property rights, respect privacy and in general have a good professional conduct.  
Software engineering ethics are based on 8 principles that were principaly made to avoid harming others:

-Public
-Client and employer
-Product
-Judgement
-Management
-Profession
-Coleagues
-Self

We discussed a really important point about this, some said that the code of ethics is not a code of rules, it´s just made to suggest a proper conduct but following it or not is an obligation. I personally think that this depends on the place you are working, some companies care about their public image and they will fire you if they notice that you are doing something unethical, but others don´t care if they are harming others with their products and sometimes promote unethical software (see malware). Of course, it is optimal that every software engineer follow the code of ethics as a personal way of living but in reality some people and companies just care for money and they don´t care if they are doing something unethical as long as they are winning more.

Discipline vs Art

Software engineering is the last engineering created, but it will be the base for future careers that will change the way we see the world now. It’s different from others because you may get a virtual result that will function in real life and not necessary tangible one.

Software engineers can create something with a single a computer, and their limits are only the limits that they give themselves.

7c29296d7858f78f2e5f07df032818b5

Making software is not just programming; there’s a processes of planing before creating something and a process of improving it after you created it. But it’s always better to develop something that comes from our imagination, in that way we convert a piece of software into a piece of art.

20160816_093055.jpg

 

Collaboration:

Victor A. Najar

Miguel A. Cabral

Ramón García

Michelle Sagnelli