Author: Jose Carlos Peñuelas Armenta

Sofware design

https://farm1.static.flickr.com/143/357358126_63fb3325d6.jpg 
flickr photo by funkandjazz https://flickr.com/photos/phunk/357358126 shared under a Creative Commons (BY-NC-ND) license


Software design is the process of implementing solutions to a set of problems, it´s a plan to solve the problems with a constant aproach. Software design involves all the components of the software, from the specifications to the architecture. As I like to see it, is a set of rules created by you to fulfill the requirements. The design is not just about the looks, it is also about how it works internally and how the users interact with the program. It´s important because it defines and solidify the process of developing, defining a design is about setting the software requirement analysis and plan the other parts from these specifications, at the end you will have a complete development plan with a constant that makes sure your software makes sense and will do what you, the customer and the users wants, that is the design. As Reeves describes software development, "programming is not about building software; programming is about designing software".

One way of describing a sofware design is using any documentantion method, actually, there is no predefined way of describing a design. You can do it with Unified Modeling Language, flow charts or anything that is readable to somebody else, like just listing the steps. 

The design can be implemented by a framework or by software design patterns.

Just for fun, here is another music video:




source:
https://en.wikipedia.org/wiki/Software_design
http://www.developerdotstar.com/mag/articles/reeves_design.html

Sofware design

https://farm1.static.flickr.com/143/357358126_63fb3325d6.jpg 
flickr photo by funkandjazz https://flickr.com/photos/phunk/357358126 shared under a Creative Commons (BY-NC-ND) license


Software design is the process of implementing solutions to a set of problems, it´s a plan to solve the problems with a constant aproach. Software design involves all the components of the software, from the specifications to the architecture. As I like to see it, is a set of rules created by you to fulfill the requirements. The design is not just about the looks, it is also about how it works internally and how the users interact with the program. It´s important because it defines and solidify the process of developing, defining a design is about setting the software requirement analysis and plan the other parts from these specifications, at the end you will have a complete development plan with a constant that makes sure your software makes sense and will do what you, the customer and the users wants, that is the design. As Reeves describes software development, "programming is not about building software; programming is about designing software".

One way of describing a sofware design is using any documentantion method, actually, there is no predefined way of describing a design. You can do it with Unified Modeling Language, flow charts or anything that is readable to somebody else, like just listing the steps. 

The design can be implemented by a framework or by software design patterns.

Just for fun, here is another music video:




source:
https://en.wikipedia.org/wiki/Software_design
http://www.developerdotstar.com/mag/articles/reeves_design.html

Sofware design

https://farm1.static.flickr.com/143/357358126_63fb3325d6.jpg 
flickr photo by funkandjazz https://flickr.com/photos/phunk/357358126 shared under a Creative Commons (BY-NC-ND) license


Software design is the process of implementing solutions to a set of problems, it´s a plan to solve the problems with a constant aproach. Software design involves all the components of the software, from the specifications to the architecture. As I like to see it, is a set of rules created by you to fulfill the requirements. The design is not just about the looks, it is also about how it works internally and how the users interact with the program. It´s important because it defines and solidify the process of developing, defining a design is about setting the software requirement analysis and plan the other parts from these specifications, at the end you will have a complete development plan with a constant that makes sure your software makes sense and will do what you, the customer and the users wants, that is the design. As Reeves describes software development, "programming is not about building software; programming is about designing software".

One way of describing a sofware design is using any documentantion method, actually, there is no predefined way of describing a design. You can do it with Unified Modeling Language, flow charts or anything that is readable to somebody else, like just listing the steps. 

The design can be implemented by a framework or by software design patterns.

Just for fun, here is another music video:




source:
https://en.wikipedia.org/wiki/Software_design
http://www.developerdotstar.com/mag/articles/reeves_design.html

Software requirements elicitation and specification


Requirements elicitation is the action of listing all the specifications and requirements for a software before starting the development. The requirements can be set by the users, customers or even the engineers. This requirements list describe what must be done and what must not be done, also what are the functional and non-functional requirements of the system.

Software requirements specification is the description of the whole software. It not only includes the requirements elicitacion but also a number of possible cases or uses to the program.
Goals:
  • Facilitating reviews
  • Describing the scope of work
  • Providing a reference to software designers (i.e. navigation aids, document structure)
  • Providing a framework for testing primary and secondary use cases
  • Including features to customer requirements
  • Providing a platform for ongoing refinement (via incomplete specs or questions)

This is important to know because it set ups the negotiation between the customer and the developer. Also, it sets and specific and accurate path to follow during the development because it tells you what the customer wants and what are your posibilities or limitations. It can help to decide how to work and which frameworks or tools use. The whole desired model is described by the Software requirements specification. Even tough is not a guide to describe what you need, at least you know where to start and what to do.


Once more, here is another music video, enjoy:



sources:
https://en.wikipedia.org/wiki/Software_requirements_specification
https://en.wikipedia.org/wiki/Requirements_elicitation

Software requirements elicitation and specification


Requirements elicitation is the action of listing all the specifications and requirements for a software before starting the development. The requirements can be set by the users, customers or even the engineers. This requirements list describe what must be done and what must not be done, also what are the functional and non-functional requirements of the system.

Software requirements specification is the description of the whole software. It not only includes the requirements elicitacion but also a number of possible cases or uses to the program.
Goals:
  • Facilitating reviews
  • Describing the scope of work
  • Providing a reference to software designers (i.e. navigation aids, document structure)
  • Providing a framework for testing primary and secondary use cases
  • Including features to customer requirements
  • Providing a platform for ongoing refinement (via incomplete specs or questions)

This is important to know because it set ups the negotiation between the customer and the developer. Also, it sets and specific and accurate path to follow during the development because it tells you what the customer wants and what are your posibilities or limitations. It can help to decide how to work and which frameworks or tools use. The whole desired model is described by the Software requirements specification. Even tough is not a guide to describe what you need, at least you know where to start and what to do.


Once more, here is another music video, enjoy:



sources:
https://en.wikipedia.org/wiki/Software_requirements_specification
https://en.wikipedia.org/wiki/Requirements_elicitation

Software requirements elicitation and specification


Requirements elicitation is the action of listing all the specifications and requirements for a software before starting the development. The requirements can be set by the users, customers or even the engineers. This requirements list describe what must be done and what must not be done, also what are the functional and non-functional requirements of the system.

Software requirements specification is the description of the whole software. It not only includes the requirements elicitacion but also a number of possible cases or uses to the program.
Goals:
  • Facilitating reviews
  • Describing the scope of work
  • Providing a reference to software designers (i.e. navigation aids, document structure)
  • Providing a framework for testing primary and secondary use cases
  • Including features to customer requirements
  • Providing a platform for ongoing refinement (via incomplete specs or questions)

This is important to know because it set ups the negotiation between the customer and the developer. Also, it sets and specific and accurate path to follow during the development because it tells you what the customer wants and what are your posibilities or limitations. It can help to decide how to work and which frameworks or tools use. The whole desired model is described by the Software requirements specification. Even tough is not a guide to describe what you need, at least you know where to start and what to do.


Once more, here is another music video, enjoy:



sources:
https://en.wikipedia.org/wiki/Software_requirements_specification
https://en.wikipedia.org/wiki/Requirements_elicitation

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" →

Functional and non functional requirements

A functional requirement is something the product needs to work, perform an action and fulfill the purpose. It answers the question of "What does it do?". They describe the minimal requirements of the product functionality. A non-funtional requirement is something that the product have to increase it quality. It answers the question of  "How does it do it?". Non-functional requirements are extras made to improve the functionality of the product.

Eventhough the definition is mostly used for engineering purposes, it can be used to describe all kind of products and subjects. An example of a product can be a shoe. One functional requirement can be to protect the feet. One example of a non-functional example is that the shoe has the right size and right weight for maximum comfort.

Knowing the requirements while developing a program is very important because it can save you time. Probably you want to present a functional software to a company in a week but you can get distracted if you spend your time coding non-functional requirements like the design or the resizable database. I mean, yes, non-functional requirements can be everything today, they are very useful to attract more users or to get a real distinction over all the other programs that do the same. However, sometimes the time is running and people want to see results as quickly as posible, while developing make sure to cover first the minimal requirements and list them to follow an ordered process, later you can start adding colors and extra features. Remember, if the time is on your back, don´t lose time on non-functional requirements and make sure the program do what is meant to do.

Lets get heavy this time, enjoy the headbanging:


source:
https://en.wikipedia.org/wiki/Non-functional_requirement
https://en.wikipedia.org/wiki/Functional_requirement

Functional and non functional requirements

A functional requirement is something the product needs to work, perform an action and fulfill the purpose. It answers the question of "What does it do?". They describe the minimal requirements of the product functionality. A non-funtional requirement is something that the product have to increase it quality. It answers the question of  "How does it do it?". Non-functional requirements are extras made to improve the functionality of the product.

Eventhough the definition is mostly used for engineering purposes, it can be used to describe all kind of products and subjects. An example of a product can be a shoe. One functional requirement can be to protect the feet. One example of a non-functional example is that the shoe has the right size and right weight for maximum comfort.

Knowing the requirements while developing a program is very important because it can save you time. Probably you want to present a functional software to a company in a week but you can get distracted if you spend your time coding non-functional requirements like the design or the resizable database. I mean, yes, non-functional requirements can be everything today, they are very useful to attract more users or to get a real distinction over all the other programs that do the same. However, sometimes the time is running and people want to see results as quickly as posible, while developing make sure to cover first the minimal requirements and list them to follow an ordered process, later you can start adding colors and extra features. Remember, if the time is on your back, don´t lose time on non-functional requirements and make sure the program do what is meant to do.

Lets get heavy this time, enjoy the headbanging:


source:
https://en.wikipedia.org/wiki/Non-functional_requirement
https://en.wikipedia.org/wiki/Functional_requirement