Unidad 1. Análisis y resolución de problemas

Desarrollo del pensamiento computacional. 

Unidad 1. Análisis y resolución de problemas 

1. Concepto de problema

Un problema es un evento en el que se produce un obstáculo que impide la continuidad de alguna acción la cual requiere de atención para encontrar una solución que permita su secuencia. 

2. Tipos de problemas

• Problemas de decisión
• Problemas de búsqueda 
• Problemas de optimización
• Problemas de conteo

2.1. Problemas de decisión 

Los problemas de decisión son los que pueden ser resueltos por una afirmación (verdadero) o una negación (falso). 

2.2. Problemas de búsqueda

Los problemas de búsqueda son los que pueden ser resueltos mediante el proceso de encontrar un valor determinado. 

2.3. Problemas de optimización

Los problemas de optimización son los que pueden ser resueltos mediante un proceso inmejorable para encontrar un valor determinado. 

2.4. Problemas de conteo

Los problemas de conteo son los que pueden ser resueltos mediante una cantidad total de los valores determinados. 

3. Metodología para la resolución de problemas

1. Método de Pólya
2. Pasos del método de pólya
3. Ciclo de vida del software 

3.1. Método de Pólya

A George Pólya se le atribuye el descubrimiento del método Polya. Es un científico matemático que nació el 13 de diciembre de 1887 en Hungría, realizo sus investigaciones en las Universidades de Brown y Standford en E.U.A. donde elaboro algunos libros y documentos en los que muestra que para entender algo se tiene que comprender el problema. 

El Método Pólya se trata de la solución de problemas matemáticos,ya que para llegar a la respuesta se tiene que realizar un proceso: pausa, reflexión ajustes en el proceso. 

3.2. Pasos del Método Pólya 

3.2.1. Entender el problema

Se tiene que identificar y analizar detenidamente el problema su contexto, así como también sus alcances y limitaciones. 

3.2.2. Trazar un plan 

Seleccionar alguna forma en que se puede resolver un problema, estableciendo ciertas pautas al diseñar la estrategia en las que permita la implementación de pruebas para poder identificar su solución. 

3.2.3. Ejecutar el plan

Cuando se tiene la estrategia para encauzar el problema se implementa cuidando siempre que todo lo establecido se lleve a cabo, de no ser así siempre se puede volver a comenzar, ya que se puede rediseñar el plan para llegar a la solución.

3.2.4 Revisar

Cuando se encuentra la solución es preciso cerciorarse de que es la adecuada, para ello tendrá que revisar la forma en que se aplicó y ejecutó el plan; siempre procurando establecer distintos caminos para llegar a la solución y que esta sea lo más comprensible para todos. 

4. Ciclo de vida del software

Modelos:

1. Ciclo de vida lineal
2. Ciclo de vida en cascada puro
3. Ciclo de vida en V
4. Ciclo de vida tipo Sashimi
5. Ciclo de vida en cascada con subproyectos
6. Ciclo de vida iterativo
7. Ciclo de vida por prototipos
8. Ciclo de vida evolutivo
9. Ciclo de vida incremental 
10. Ciclo de vida en espiral
11. Ciclo de vida orientado a objetos

4.1. Ciclo de vida lineal 

Es el más popular para el desarrollo de software pequeños, generalmente internos de una empresa, por su simplicidad, administración y economía, esto debido a que desbarata el proyecto en fases que son desarrolladas de manera independiente las cuales no se retroalimentan de ahí su principal desventaja al utilizarlo ya que que al finalizar una se inicia con la siguiente y así sucesivamente, de existir algún problema en las fases sería complicado el regreso. En este se encuentran los sistemas que realizan Altas, Bajas y Modificaciones de datos (ABM) únicamente se guardan datos en una base de datos para realizar posteriormente una consulta simple. 

4.2. Ciclo de vida en cascada puro

Es uno de los ciclos en los que es necesario conocer a detalle los requerimientos del software y se comprenda su funcionalidad, debido a su poca flexibilidad y gran cantidad de restricciones, pero con él se crea software de gran calidad. 

No es un ciclo lineal ya que permite repetir y regresar a alguna fase. Al termino de cada fase se realizan revisiones para poder continuar con la siguiente. 

Los resultados son visibles hasta encontrarse en fases finales. 

4.3. Ciclo de vida en V

Es un ciclo utilizado en aplicaciones simples que requieren gran confianza, es similar al de cascada puto, pero este permite controlar mejor las correcciones en el desarrollo del software, debido a su mejor comunicación entre fases. 

4.4. Ciclo de vida tipo Sashimi

Es un ciclo similar al de cascada puro, sin embargo en este se aumenta la eficiencia y muchas veces su calidad ya que se pueden brincar fases, pero esto conlleva a que se deje por un lado la documentación del software lo que puede generar inconsistencias. Su representación está basada en el modelo del estilo japonés para representar al pescado cortado crudo. Es utilizado cuando se realiza un software que compartirá la unidad central de proceso (CPU), memoria o espacio en disco duro con otro software. 

4.5. Ciclo de vida en cascada con subproyectos

Es usado cuando se desarrollará el software con varios programadores ya que esta diseñado para que cada fase se desarrolle en paralelo divididas en subfases independientes lo que permite administrar adecuadamente los tiempos. Sin embargo, puede tener dependencias entre subfases que inmovilizan temporalmente el desarrollo.

4.6. Ciclo de vida iterativo

Es un ciclo que permite entregar una versión beta al cliente del software final, lo que hace que se comprenda mejor lo que el cliente solicita; se basa en el ciclo de vida en cascada puro, pero como su sombre lo indica es la iteración de varios ciclos de vida en cascada los que permiten entregar al cliente una versión mejorada y con más funciones durante cada iteración, por lo que en cada entrega el cliente lo utiliza, evalúa y propone mejoras que pueden ser corregidas en próximas versiones y se continúa hasta que el cliente quede complacido. 

Es utilizado cuando no existen o no son comprensibles los requerimientos, lo que conlleva a que se trabaje directamente en el desarrollo de versiones beta. 

4.7. Ciclo de vida por prototipos

Es un ciclo utilizado para validar los requisitos en cualquiera de los ciclos de vida. Se toman requisitos generales y con estos se realizan prototipos en el que el objetivo es desarrollar un software que sirva de intermedio para conocer la funcionalidad que tendrá el software final y a partir de este realizar los ajustes necesarios. Se utiliza para migrar, innovar o usar tecnologías nuevas y poco probadas en los que no se tenga la certeza sobre lo que se desea lograr, sin embargo es muy costoso ya que muchas de las veces se tienen que desarrollar varios prototipos para mostrarlos al cliente. 

4.8. Ciclo de vida evolutivo

Se va trabajando poco a poco según los requisitos. El ciclo va encaminado a desarrollar una versión en base a los requisitos y de ahí se evalúa para determinar si es este el software deseado, de no ser así se repite el proceso, en el cual evolucionan los requisitos. Se utiliza cuando los requisitos al inicio no están completos. 

4.9. Ciclo de vida incremental

En este se repite el ciclo de vida en cascada cada que se crea una funcionalidad del software, el cual va integrando el producto final. En cada repetición se crea una versión independiente en la que los requisitos son subsanados. Se utiliza para ciertos clientes que requieren comenzar a trabajar en él de inmediato. 

4.10. Ciclo de vida en espiral 

En este se repiten los ciclos de vida por prototipos e incremental, los cuales terminan cuando el software satisface las necesidades. Sin embargo, en este ciclo se involucra al riesgo ya que no se tienen correctamente definidos los requisitos y se carece de todas las funciones del software. 

Se realizan cuatro actividades:

1. Planificación, en donde se liberan los requisitos
2. Análisis de riesgo, en donde se decide si continua con el desarrollo
3. Implementación, en donde se desarrolla un prototipo en base a los requisitos
4. Evaluación, en donde el cliente evalúa si satisface sus necesidades, si es así se termina el desarrollo del software, de no ser así se toman nuevos requisitos y se continua con la siguiente repetición.

El software que se desarrolla en este ciclo comienza de manera rápida, ya que no se pone tanta importancia en los errores porque estos pueden solucionarse en la siguiente rama de la espiral. 

Requiere de mucho tiempo, ya que involucra una infinidad de vueltas en la espiral; y de mucha comunicación con el cliente. 

Es utilizado en empresas para grades proyectos de software internos en donde se desconocen todos los requisitos y en donde el cliente es un usuario que siempre se encuentra disponible. 

4.11. Ciclo de vida orientado a objetos

Este ciclo es más flexible que los anteriores, se basa principalmente en la abstracción de los requisitos, lo que permite analizar y desarrollar las características esenciales del objeto. En este ciclo se utilizan fichas clase-responsabilidad-colaboración (CRC) en las que se escribe el nombre de la clase u objeto, los métodos (responsabilidades) y otras clases u objetos que necesita (colaboradores) que ayudan a fabricar los casos de uso. 

Permite perfeccionar el software ya que hace fácil solucionar el problema. 

Se utiliza aunque el lenguaje no sea orientado a objetos en software para monitorear procesos, grandes sistemas de transacciones sobre la base de datos o procesamiento por lotes. 

--------------------------------------------------------------------------------------------------------------------------

Referencias bibliográficas

• Editor (marzo 22, 2016). Análisis de algoritmos. ConocimientosWeb.net. Recuperado el 26 de septiembre del 2017, en http://www.conocimientosweb.net/zip/article7258.html

• Facultad de Ingeniería, Universidad de la República (Uruguay). (septiembre 2, 2009). Curso: Teoría de la Computación. Unidad 2, Sesión 7: Complejidad computacional. Pp. 1-24. Recuperado el 26 de septiembre del 2017, en https://www.fing.edu.uy/inco/cursos/teocomp/unidad02/transpSesion07.pdf

• Pixabay (noviembre 4, 2015). Ilustración gratis. Recuperado el 26 de septiembre del 2017, en https://pixabay.com/es/de-distancia-junction-direcci%C3%B3n-1019796/

• Abián (marzo 28, 2009). Un diagrama de flujo para arreglar una lámpara que no funciona. Recuperado el 26 de septiembre del 2017, en https://commons.wikimedia.org/wiki/File:LampFlowchart-es.svg

• Hernández, Victor. M. Villalba G., Martha C. George Pólya: El padre de las Estrategias para la Solución de Problemas. Pp. 1-4. Recuperado el 26 de septiembre del 2017, en http://fractus.uson.mx/Papers/Polya/Polya.pdf

• GIPHY. ALGORITHM GIF. Recuperado el 26 de septiembre del 2016, en https://giphy.com/gifs/algorithm-WbdMEyP252goM

• Ordoñez Toledo, Areli (septiembre 5, 2014). Búsqueda de Información en Internet. Recuperado el 26 de septiembre del 2017, en https://es.slideshare.net/areliordoneztoledo/diagrama-de-flujo-de-bsqueda-de-informacin-en-internet

• Wikipedia® (agosto 25, 2017). Problema computacional. Recuperado el 26 de septiembre del 2017, en https://es.wikipedia.org/wiki/Problema_computacional

• pixabay. Alexas_fotos (septiembre 24, 2017). connect-2777620_960_720.png Recuperado el 26 de septiembre del 2017, en https://pixabay.com/es/conectar-conexi%C3%B3n-cooperaci%C3%B3n-2777620/

• Escalante Martinez, Silvia Brendy (enero, 2015) Método Pólya en la resolución de problemas matemáticos. Pp. 1-98. Recuperado el 26 de septiembre del 2017 en http://recursosbiblio.url.edu.gt/tesisjcem/2015/05/86/Escalante-Silvia.pdf

• VICUNADM (junio 18, 2014) Método de cuatro pasos de Polya. Recuperado el 27 de septiembre del 2017, en https://victorupiicsa2000.wordpress.com/2014/06/18/metodo-de-cuatro-pasos-de-polya/

• Monsalve, Wilmar (junio 2, 2009) imagen: problema.jpg Recuperado el 27 de septiembre del 2017, en http://diariodeprocesowilmarmonsalve.blogspot.mx/

• El Camaleon Taller Grafico Publicitario (agosto 1, 2012) imagen: 398830_153593588106519_316498068_n.jpg Recuperado el 27 de septiembre del 2017, en http://elcamaleontallergraficopublicitario.blogspot.mx/2012/08/como-hacer-un-plan-de-marketing.html

• Nuñez, Vilma vn. LANTILLAS DE SOCIAL MEDIA MARKETING. Recuperado el 27 de septiembre del 2017, en https://vilmanunez.com/plantillas-social-media-marketing/

• Bolívar, José Miguel (febrero 18, 2015) imagen: sistema-bajo-lupa.jpg Recuperado el 28 de septiembre del 2017, en http://www.optimainfinito.com/2015/02/la-triple-funcion-de-la-revision-en-gtd.html

• (s.f.) Capitulo 1. Implementación y Debugging. Ciclo de vida del software. Recuperado el 29 de septiembre del 2017, en https://ingsw.pbworks.com/f/Ciclo+de+Vida+del+Software.pdf