Regresión lineal

--Originally published at Hermes's Blog

En quince casas de la ciudad se observó durante un período de tiempo la diferencia de temperatura promedio (en grados centígrados) entre la temperatura en la calle y la temperatura en casa, y el consumo de electricidad diario en kWh

Graficas de datos

Regresión lineal

Podemos percibir que entre más sube la diferencia de temperatura entre la casa y la calle
suele haber más consumo de energía eléctrica.

Aplique regresión lineal y obtenga la función lineal que se ajusta a estas mediciones.

corriendo el siguiente código con los datos proporcionados obtenemos los resuldatos de a1 = 3.39553 a0 = 37.1618, lo que quiere decir que el y = 37.1618 + 3.39553 * x es un modelo lineal que se ajusta apropiadamente a estos datos.

Error estándar de la estimación

El error estandar está definido por la desviación estandar entre la raíz del numero
de datos: std_dev / sqrt(n). Así pues, encontramos que el error estandar de la
estimación es de 509.583.

Coeficiente de correlación

El coeficiente de correlación de Pearson es una medida de relación lineal entre dos variables aleatorias
cuantitativas y lo podemos utilizar como índice para medir el grado de relación de dos variables.

Regresión lineal

Encontramos que el coeficiente de correlación en los datos es de -6.81036e+31.

Grafica de la regresión lineal

Regresión lineal

Conclusiones


Regresión lineal

Método de Jacobi & Método de Gauss-Seidel

--Originally published at That Class Blog

Introducción y antecedentes

Ambos son métodos semejantes, usados para calcular la solución a un sistema de ecuaciones lineales (De forma Ax = b).

Requisitos de los métodos

Para ambos:

  • El sistema de ecuaciones se tiene que poder representar en una matriz cuadrada
  • La diagonal no debe tener elementos nulos
  • La matriz tiene que se dominante (Los elementos en la diagonal tienen que tener el coeficiente de mayor magnitud de la ecuación)

Diferencias

En Jacobi, para cada iteración, se usan los valores previamente estimados de las variables (O si es la primer iteración, los valores de las variables definidas por el usuario o las default). En cambio en Gauss-Seidel, el método va reemplazando las variables calculadas en la iteración anterior, por las de la iteración actual inmediatamente. Así el método reduce el número de iteraciones totales.

Diagramas de flujo

Se realizaron los diagramas de flujo para resolver un sistema de 3 ecuaciones y 3 incógnitas

Jacobi

Método de Jacobi & Método de Gauss-Seidel

Gauss-Seidel

Método de Jacobi & Método de Gauss-Seidel

¿Es un método iterativo?

Sí. Al final de cada iteración, el método ya tiene una aproximación a la solución. Durante la siguiente iteración, se utilizan los resultados previos obtenidos para calcular las nuevas soluciones.

Código

Jacobi: GitHub

Gauss-Seidel: GitHub

Criterio de convergencia del método

Relajación (qué es y para qué sirve?)

Pruebas y resultados con sistemas de 3 o 4 incógnitas

Casos de falla

Conclusiones


Método de Jacobi & Método de Gauss-Seidel

That’ll go there, and this’ll go here

--Originally published at Ce qui est chouette

This post will cover Chapter 10 of Software Project Survival Guide.

Software Architecture. This architect isn’t the one dude who liked drawing so he decided to dedicate his life to drawing buildings and building little model constructions (says the guy who doesn’t really know what an architect does), nor is he the guy from How I Met Your Mother. Have you met him, though?

The architecture phase of a software project is when the software is mapped out using design diagrams and prototypes. It provides a means of exploring alternatives that may cost less, like using a Red Black Tree instead of a Priority Queue for scheduling, looking at you Linux Scheduler. If you’d like to read more on the Completely-Fair Scheduler, I suggest the following article by M. Jones: Inside the Linux 2.6 Completely Fair Scheduler.

During the architecture phase, back to the topic at hand, the architect partitions the system into subsystems, specifying the interaction between them and documents technical plans. This phase, however, shouldn’t really start until the Planning Checkpoint Review is held.

That’ll go there, and this’ll go here
Architect on flickr under a CC License.

The architecture document should include the following:

System Overview. A brief description of the system without going into specifics, so as to provide a picture for the developer. It should include a discussion of the alternatives considered and why some weren’t selected and some where.

Conceptual Integrity. The architecture document should be created in such a way that the solution provided for the problem seems almost obvious, keeping it simple. The document should be short and include several diagrams. Keep it natural and easy.

Subsystems and Organizations. Define the major subsystems as clusters of functionality, of a certain aspect of the system. Describe the responsiblities of each subsystem and how they communicate with one another; this communication should be restricted, as in Object-Oriented Programming, to keep a certain level of modularity.

Notation. Describe the notation that’ll be used for diagrams and pseudocode, such as UML and the Cormen’s weird but useful pseudocode notation.

Change Scenarios and Change Strategy. List the parts of the software that are likely to need changes and how the team should go about those changes.

Reuse analysis and build vs. Build decisions. Define what components will be written from scratch, reused from other projects (if any) or bought (if any). In any of the two latter cases, the rest of the software has to be built around the framework bought (or reused).

Approach to Standard Functional Areas. The architecture document should include the following regarding to the functional areas of the software:

  • External Software Interfaces. Is any external software used? Include how to interact with it.
  • User Interfaces. How is it isolated from the rest of the software.
  • Database Organization. How’s it organized and what does it contain.
  • Data Storage. What’s not stored in the database, the file formats, are there any major data structures.
  • Key Algorithms. Are they defined or should they be defined later on?
  • Memory Management. How memory’s allocated.
  • String Storage. Messages used.
  • Concurrency/Threads. Whether the software is multithreaded.
  • Security. Is there a requirement to operate in a secure environment?
  • Localization. How the software will work on countries with other languages.
  • Networking. How it supports network operations.
  • Portability. How it runs on other environments (UNIX-based or Windows systems).
  • Programming Language. Can it be implemened on any or does it have to be in a specific language?
  • Error Handling. What the error-handling strategy is.

Requirements Traceablity. Make sure that every requirement is taken care of by one of the subsystems.

Support for a Staged Delivery PlanDescribe how the software will adjust to fit a staged delivery, how’s it going to be developed in each stage and delivery of planned functionality.

Software Architecture is really never done, but at some point implementation must begin, so aim at simplicity, minimalism and coverage of all requirements to know when it’s reasonable to start coding.

This wasn’t that later, your neighborhood guy.

 

 


That’ll go there, and this’ll go here

Shut up, he’s got the talking stick!

--Originally published at Ce qui est chouette

This post will cover Chapter 9 of Software Project Survival Guide.

A definition for quality that McConnell provides is the following: “the degree to which the software satisfies both stated and implied requirements” (1997).

Quality is important in software, because as time passes what the user will remember is his experience with the software, delivering late is not even that important, as the user will use the software anyway. What they’ll remember is whether they liked their experience with the software.

To ensure quality the team ought to commit. Meaning planning quality assurance activites and write them down, starting them before or during software requirements activites, assign a knowledgeable group to quality assurance, and provide the required funding.

Shut up, he’s got the talking stick!
Talking stick by Kathy Wrathall on flickr under a CC License.

It’s important to keep in the pipeline a Quality Assurance Plan which consists of the following:

Defect Tracking. Keep record of each defect, where and when it was detected, when and how it was resolved. This information should be made public through change control, so that team members are aware of the defect and the whole staff can keep track of how many defects remain in the software.

Unit Testing. Carried out by the developer of the unit (subroutine, module, class).

Source-code Tracing. Carried out by the programmer that wrote the source code. They go through the code line-by-line using a debugger.

Technical Reviews. Carried out by team members on work they didn’t do themselves. Consists of checking if quality is met on the UI, requirements specification, architecture and design. It’s advisable that senior developers review junior developers work, not just to assure quality, but to encourage that interaction. Technical Reviews follow a general pattern:

  • Notification and distribution. The developer notifies reviewers (or a moderator) that the their work product is ready to be reviewed, then the material is distributed for review.
  • Preparation. Reviewers review the work product, usually against a checklist of common errors, and schedule a review meeting.
  • Review Meeting. Reviewers, the developer (and moderator) meet to review together the work product, keeping focus on detecting defects.
  • Review Report. Results and statistics are commited to a written document, including defects detected and information needed to add them to defect tracking.
  • Follow-Up. The developer or some other person makes changes (if they were required), these changes are reviewed and the product is declared to have passed the review. Add the material to a list of materials that have been reviewed already.

Integration Testing. Carried out by the developer of the new code, they test it with other code that’s been integrated already.

System Testing. Carried out by a designated group or by the quality assurance group (independent to the development). Consists of executing the software to find defects. System testing alone won’t be enough to assure quality, it must be combined with the aforementioned stepts for that purpose.

Some companies, instead of keeping system testing inside the team, deploy what’s called a beta version of the software to the consumers. Beta testing is performed for several reasons like building a relationship with the user, getting expert consulting or polishing the user-interface according to usage.

To ensure that quality is met overall, the team must designate a group to wield the quality assurance baton. Whoever holds the stick has the responsibility of ensuring quality assurance activities are performed and is responsible for determining whether the software is ready for release; this must be determined according to measurable criteria, meaning “no more than 2 bugs” and the likes.

Laters, a quality assured fellow.


References
McConnell, S. (1997). Software Project Survival Guide. Microsoft Press. [Kindle Edition]

Shut up, he’s got the talking stick!

Requirements: Ch. 8 SG

--Originally published at That Class Blog

The first “real” ideas of the project are reflected in UI prototypes and user manuals. But before doing that, something essential for the whole project needs to be gathered: The Requirements. How? Doing interviews to users and comparing products (Just remember that the difficult part is not to record what the user wants, but making him understand what he wants). And then? Write them, specify them, analyze, compare, build storyboards and prototypes. After all of that you have your requirements.

Overview of the process

  1. Identify end users that can define the product: They should be interested in the product in a way that you can deposit your complete trust in their criteria.
  2. Interview those end users: Here you will obtain the basic set of requirements.
  3. Build simple interactive UI: Really, as simple as possible. But make different alternatives. In paper storyboards are an easy way to present the requirements in a way everyone can understand.
  4. Show the UI to the end users and receive feedback. Work on the feedback on show it again. Do this until the end user is satisfied.
  5. Develop a style guide: The standards of the product look and feel.
  6. Extend the prototype to include every functionality: Now that you have every requirement defined and how each one must look, you can introduce everything. Still, it’s a throwaway, but lets try to work on a single one.
  7. Treat that prototype as the base line: Because you know what to reach, you can start giving formal estimates to the boss.
  8. Write the end user documentation: What will the user see, the basic “how does it work” and how to interact with it.
  9. Write the non end user documentation: The things that the user doesn’t care about, but someone else might. Like another team that might make an upgrade, and maybe needs to understand how the algorithms work, how the software interacts with the hardware, etc.

And that’s it.


Requirements: Ch. 8 SG

Requirements: Ch. 8 SG

--Originally published at That Class Blog

The first “real” ideas of the project are reflected in UI prototypes and user manuals. But before doing that, something essential for the whole project needs to be gathered: The Requirements. How? Doing interviews to users and comparing products (Just remember that the difficult part is not to record what the user wants, but making him understand what he wants). And then? Write them, specify them, analyze, compare, build storyboards and prototypes. After all of that you have your requirements.

Overview of the process

  1. Identify end users that can define the product: They should be interested in the product in a way that you can deposit your complete trust in their criteria.
  2. Interview those end users: Here you will obtain the basic set of requirements.
  3. Build simple interactive UI: Really, as simple as possible. But make different alternatives. In paper storyboards are an easy way to present the requirements in a way everyone can understand.
  4. Show the UI to the end users and receive feedback. Work on the feedback on show it again. Do this until the end user is satisfied.
  5. Develop a style guide: The standards of the product look and feel.
  6. Extend the prototype to include every functionality: Now that you have every requirement defined and how each one must look, you can introduce everything. Still, it’s a throwaway, but lets try to work on a single one.
  7. Treat that prototype as the base line: Because you know what to reach, you can start giving formal estimates to the boss.
  8. Write the end user documentation: What will the user see, the basic “how does it work” and how to interact with it.
  9. Write the non end user documentation: The things that the user doesn’t care about, but someone else might. Like another team that might make an upgrade, and maybe needs to understand how the algorithms work, how the software interacts with the hardware, etc.

And that’s it.


Requirements: Ch. 8 SG

Planning in advance: Ch. 7 SG

--Originally published at That Class Blog

Even thought someone might say that its impossible to plan before knowing which are the requirements, but… THAT ISN’T TRUE! There are several thing to do. More specifically, 7 things.

Project Vision

For a team to share a vision and final objectives (Objectives aren’t requirements), the team functioned effectively. This will make improvements in very aspect of the team; from organizational and administrative improvements, such as decision making; to motivation and influence on the team.

The vision must be specific and motivational, but the most important characteristic is that it must be achievable. Finally, everyone must commit to the vision.

Executive Sponsorship

This refers to designate the support that the team or person that has heavy decision impact on the project. This person or team will approve every feature, user interface, release…  And it’s important that if this entity is a team, each member must represent a different interest.
Because no one likes to have the same boss multiple times… Imagine the same reproach by each boss when you get something wrong.

Project Scope Targets

Features, schedule and budget are things that can and should be declared before any real requirements definition. Well… an exact definition of theses 3 things can’t really be done, but  a real tentative target must be defined. A recommended technique to define this sort of things is to define an upper and lower limit for everything, this provides a margin to deal with the uncertainty.

Publicizing Plans and Projects

Big mistake: TO KEEP THE PLANNING SECRET. People need and should know what are they going to face in the future. If the manager doesn’t inform the programmers or the testers, considerations might not be taken to make a plan that can adapt to them. So, because there isn’t a plan that they approve, or at least that they can prepare for, people run out of control. What should always be public? You ask:

  • List of tasks completed
  • Defect statistics
  • Top 10 risk list
  • Percent of schedule used
  • Percent of resources used
  • Status reports given to upper management

Risk Management

Every project must commit to risk management. What does this mean? Well, to provide the all the necessary means to predict, act and resolve risks. What should be provided? An approach, resources and funds, and make the assessment of risk impact the project (I mean, if you know something is coming, let’s act on it). And which are the approaches available? Here, have a list:

  • Risk officer: Spotter of emerging risks. A “pessimistic” person that will try to find every possible problem during development.
  • To 10 risk list: A list, with possible risks and how is currently being fought.
  • Risk tracing: A system that prioritizes risks, if they are open or closed to process, and who is working on them.

Remember that each entry of the top 10 risk list needs to have a reason to be there. Answer why is that a risk and needs management, how is it going to be resolved, what steps are needed to solve it, who will do each step, when can a step be started, how much is going to cost. The answers need to be recorded.

Oh, and there can be a channel, available to everyone to report risks. The managers and officers can’t see everything.

Personnel Strategies

Basic knowledge to staff buildup: Senior staff at the requirements stage, add more staff to the development stage. And just because you need staff, you shouldn’t hire available people, you need to hire good and skilled people, even if that means to wait a little bit.

The team roles (For you to remember) are:

  • Project manager
  • Product manager
  • Architect
  • UI designer
  • End-user liaison (interact with users)
  • Developers
  • QA/Testers
  • Tool smith (develop utilities for the development)
  • Build coordinator (running daily builds)
  • Risk officer
  • End-user documentation specialist
  • Optional: Tiger teams (2 people temporary teams to solve problems fast)

Oh, and a last thing

Time accounting

Just… keep track on how is the personnel spending their time. OK? Good. This will help when making estimates, and presenting those estimates to the upper management.

And that’s it…

It’s a lot to take in. But when you do all of this, you have finally a SOFTWARE DEVELOPMENT PLAN.

Bye!

 

 

 


Planning in advance: Ch. 7 SG

Planning in advance: Ch. 7 SG

--Originally published at That Class Blog

Even thought someone might say that its impossible to plan before knowing which are the requirements, but… THAT ISN’T TRUE! There are several thing to do. More specifically, 7 things.

Project Vision

For a team to share a vision and final objectives (Objectives aren’t requirements), the team functioned effectively. This will make improvements in very aspect of the team; from organizational and administrative improvements, such as decision making; to motivation and influence on the team.

The vision must be specific and motivational, but the most important characteristic is that it must be achievable. Finally, everyone must commit to the vision.

Executive Sponsorship

This refers to designate the support that the team or person that has heavy decision impact on the project. This person or team will approve every feature, user interface, release…  And it’s important that if this entity is a team, each member must represent a different interest.
Because no one likes to have the same boss multiple times… Imagine the same reproach by each boss when you get something wrong.

Project Scope Targets

Features, schedule and budget are things that can and should be declared before any real requirements definition. Well… an exact definition of theses 3 things can’t really be done, but  a real tentative target must be defined. A recommended technique to define this sort of things is to define an upper and lower limit for everything, this provides a margin to deal with the uncertainty.

Publicizing Plans and Projects

Big mistake: TO KEEP THE PLANNING SECRET. People need and should know what are they going to face in the future. If the manager doesn’t inform the programmers or the testers, considerations might not be taken to make a plan that can adapt to them. So, because there isn’t a plan that they approve, or at least that they can prepare for, people run out of control. What should always be public? You ask:

  • List of tasks completed
  • Defect statistics
  • Top 10 risk list
  • Percent of schedule used
  • Percent of resources used
  • Status reports given to upper management

Risk Management

Every project must commit to risk management. What does this mean? Well, to provide the all the necessary means to predict, act and resolve risks. What should be provided? An approach, resources and funds, and make the assessment of risk impact the project (I mean, if you know something is coming, let’s act on it). And which are the approaches available? Here, have a list:

  • Risk officer: Spotter of emerging risks. A “pessimistic” person that will try to find every possible problem during development.
  • To 10 risk list: A list, with possible risks and how is currently being fought.
  • Risk tracing: A system that prioritizes risks, if they are open or closed to process, and who is working on them.

Remember that each entry of the top 10 risk list needs to have a reason to be there. Answer why is that a risk and needs management, how is it going to be resolved, what steps are needed to solve it, who will do each step, when can a step be started, how much is going to cost. The answers need to be recorded.

Oh, and there can be a channel, available to everyone to report risks. The managers and officers can’t see everything.

Personnel Strategies

Basic knowledge to staff buildup: Senior staff at the requirements stage, add more staff to the development stage. And just because you need staff, you shouldn’t hire available people, you need to hire good and skilled people, even if that means to wait a little bit.

The team roles (For you to remember) are:

  • Project manager
  • Product manager
  • Architect
  • UI designer
  • End-user liaison (interact with users)
  • Developers
  • QA/Testers
  • Tool smith (develop utilities for the development)
  • Build coordinator (running daily builds)
  • Risk officer
  • End-user documentation specialist
  • Optional: Tiger teams (2 people temporary teams to solve problems fast)

Oh, and a last thing

Time accounting

Just… keep track on how is the personnel spending their time. OK? Good. This will help when making estimates, and presenting those estimates to the upper management.

And that’s it…

It’s a lot to take in. But when you do all of this, you have finally a SOFTWARE DEVELOPMENT PLAN.

Bye!

 

 

 


Planning in advance: Ch. 7 SG

Eliminación de Gauss y Gauss-Jordan

--Originally published at That Class Blog

Arturo Fornés – A01227071
Miguel Montoya – A01226045


Introducción y antecedentes

Gauss y Gauss-Jordan son ambos algoritmos del Álgebra Lineal que sirven para encontrar la solución a un sistema lineal (sistema de ecuaciones). Un sistema lineal puede tener una solución única, una infinidad de soluciones o ninguna solución. La solución única de un sistema de ecuaciones se encuentra despejando las incógnitas y encontrando su valor; se tiene una infinidad de soluciones cuando al despejar alguna de las ecuaciones quedan en 0=0; no se tiene solución cuando alguna de las ecuaciones resulta en 0=a, a != 0.

Requisitos de los métodos

  • Una matriz de dimensión n x n.
  • Un sistema de ecuaciones con una solución única.

Diferencias entre uno y otro método

Usando el método de Gauss se obtiene una matriz triangular superior; la última incógnita tiene una solución y se sustituye en la penúltima y se sigue este procedimiento para las siguientes filas en este orden.

Usando Gauss-Jordan se obtiene una matriz en forma escalonada reducida, es decir donde el pivote de cada fila es 1 y todo elemento que no sea el pivote es 0, se forma una diagonal de 1’s. Al llegar a la forma escalonada reducida de la matriz, ya se tiene la solución en el vector con el cual se expandió la matriz de coeficientes para formar el sistema lineal.

Diagramas de flujo

Gauss

Eliminación de Gauss y Gauss-Jordan

Gauss-Jordan

Eliminación de Gauss y Gauss-Jordan

¿Es un método iterativo?

Ninguno de los dos métodos, Gauss ni Gauss-Jordan, es iterativo, hay iteraciones dentro de ellos pero no se aproxima de manera iterativa al resultado. Un método iterativo es definido por realizar una aproximación a la solución en cada una de sus iteraciones; Gauss y Gauss-Jordan calculan una solución una única vez, en ambos casos un vector solución.

Archivo de script en Scilab

Gauss: GitHub.

Eliminación de Gauss y Gauss-Jordan

Gauss-Jordan: GitHub.

Eliminación de Gauss y Gauss-Jordan

Pivoteo, y escalamiento.

El pivote en una matriz es definido como el primer elemento que sea diferente de 0 en una fila. La forma escalonada se obtiene al seguir un patrón de escalones entre los pivotes, donde el pivote de una fila se encuentre a la derecha del pivote de la fila anterior.

Pruebas y resultados con sistemas de más de 3 incógnitas

 

Casos de falla

Ambos métodos, Gauss y Gauss-Jordan, fallarán para sistemas que no tengan una solución única o en los que el pivote de una fila se encuentre a la izquierda del pivote anterior. Lo último se puede evitar reacomodando manualmente las filas (intercambiándolas entre sí).

Conclusiones


Eliminación de Gauss y Gauss-Jordan

Eliminación de Gauss y Gauss-Jordan

--Originally published at That Class Blog

Arturo Fornés – A01227071
Miguel Montoya – A01226045


Introducción y antecedentes

Gauss y Gauss-Jordan son ambos algoritmos del Álgebra Lineal que sirven para encontrar la solución a un sistema lineal (sistema de ecuaciones). Un sistema lineal puede tener una solución única, una infinidad de soluciones o ninguna solución. La solución única de un sistema de ecuaciones se encuentra despejando las incógnitas y encontrando su valor; se tiene una infinidad de soluciones cuando al despejar alguna de las ecuaciones quedan en 0=0; no se tiene solución cuando alguna de las ecuaciones resulta en 0=a, a != 0.

Requisitos de los métodos

  • Una matriz de dimensión n x n.
  • Un sistema de ecuaciones con una solución única.

Diferencias entre uno y otro método

Usando el método de Gauss se obtiene una matriz triangular superior; la última incógnita tiene una solución y se sustituye en la penúltima y se sigue este procedimiento para las siguientes filas en este orden.

Usando Gauss-Jordan se obtiene una matriz en forma escalonada reducida, es decir donde el pivote de cada fila es 1 y todo elemento que no sea el pivote es 0, se forma una diagonal de 1’s. Al llegar a la forma escalonada reducida de la matriz, ya se tiene la solución en el vector con el cual se expandió la matriz de coeficientes para formar el sistema lineal.

Diagramas de flujo

Gauss

Eliminación de Gauss y Gauss-Jordan

Gauss-Jordan

Eliminación de Gauss y Gauss-Jordan

¿Es un método iterativo?

Ninguno de los dos métodos, Gauss ni Gauss-Jordan, es iterativo, hay iteraciones dentro de ellos pero no se aproxima de manera iterativa al resultado. Un método iterativo es definido por realizar una aproximación a la solución en cada una de sus iteraciones; Gauss y Gauss-Jordan calculan una solución una única vez, en ambos casos un vector solución.

Archivo de script en Scilab

Gauss: GitHub.

Eliminación de Gauss y Gauss-Jordan

Gauss-Jordan: GitHub.

Eliminación de Gauss y Gauss-Jordan

Pivoteo, y escalamiento.

El pivote en una matriz es definido como el primer elemento que sea diferente de 0 en una fila. La forma escalonada se obtiene al seguir un patrón de escalones entre los pivotes, donde el pivote de una fila se encuentre a la derecha del pivote de la fila anterior.

Pruebas y resultados con sistemas de más de 3 incógnitas

 

Casos de falla

Ambos métodos, Gauss y Gauss-Jordan, fallarán para sistemas que no tengan una solución única o en los que el pivote de una fila se encuentre a la izquierda del pivote anterior. Lo último se puede evitar reacomodando manualmente las filas (intercambiándolas entre sí).

Conclusiones


Eliminación de Gauss y Gauss-Jordan