Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Lista de Entradas para Puntos Extra:
Saludos!
martes, 22 de noviembre de 2011
[PUNTOS EXTRA] Eventos, Errores y Excepciones
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Saludos!
[PUNTOS EXTRA] Sistemas Distribuidos
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Un sistema distribuido se define como una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina posee sus componentes de hardware y software que el usuario percibe como un solo sistema. El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común.
Compartición
de Recursos
La idea
de compartición de recursos no es nueva ni aparece en el marco de los sistemas
distribuidos. Los sistemas multiusuario clásicos desde siempre han provisto
compartición de recursos entre sus usuarios. Sin embargo, los recursos de una
computadora multiusuario se comparten de manera natural entre todos sus
usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o
computadoras personales dentro de un sistema distribuido no obtienen
automáticamente los beneficios de la compartición de recursos.
Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente.
Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente.
Apertura (opennesss)
Un
sistema informático es abierto si el sistema puede ser extendido de diversas
maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones
hardware (añadir periféricos, memoria o interfaces de comunicación, etc.) o con
respecto a las extensiones software (añadir características al sistema
operativo, protocolos de comunicación y servicios de compartición de recursos,
etc.). La apertura de los sistemas distribuidos se determina primariamente por
el grado hacia el que nuevos servicios de compartición de recursos se pueden
añadir sin perjudicar ni duplicar a los ya existentes.
Básicamente los sistemas distribuidos cumplen una serie de características:
Los interfaces software clave del sistema están claramente especificados y se
ponen a disposición de los desarrolladores. En una palabra, los interfaces se
hacen públicos.
Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo
uniforme de comunicación entre procesos e interfaces publicados para acceder a
recursos compartidos.
Los sistemas distribuidos abiertos pueden construirse a partir de hardware y
software heterogéneo, posiblemente proveniente de vendedores diferentes. Pero
la conformidad de cada componente con el estándar publicado debe ser
cuidadosamente comprobada y certificada si se quiere evitar tener problemas de
integración.
Concurrencia
Cuando
existen varios procesos en una única maquina decimos que se están ejecutando
concurrentemente. Si el ordenador está equipado con un único procesador
central, la concurrencia tiene lugar entrelazando la ejecución de los distintos
procesos. Si la computadora tiene N procesadores, entonces se pueden estar
ejecutando estrictamente a la vez hasta N procesos.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o mas procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo.
En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones:
1.- Muchos usuarios interactúan simultáneamente con programas de aplicación.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o mas procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo.
En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones:
1.- Muchos usuarios interactúan simultáneamente con programas de aplicación.
2.- Muchos
procesos servidores se ejecutan concurrentemente, cada uno respondiendo a
diferentes peticiones de los procesos clientes.
Escalabilidad
Los
sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas
diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un
servidor de ficheros, mientras que un sistema distribuido construido alrededor
de una red de área local simple podría contener varios cientos de estaciones de
trabajo, varios servidores de ficheros, servidores de impresión y otros
servidores de propósito específico. A menudo se conectan varias redes de área
local para formar internetworks, y éstas podrían contener muchos miles de
ordenadores que forman un único sistema distribuido, permitiendo que los
recursos sean compartidos entre todos ellos.
Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debería ser posible extender el sistema para darla servicio.
Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debería ser posible extender el sistema para darla servicio.
Tolerancia a Fallos
Los
sistemas informáticos a veces fallan. Cuando se producen fallos en el software
o en el hardware, los programas podrían producir resultados incorrectos o
podrían pararse antes de terminar la computación que estaban realizando. El
diseño de sistemas tolerantes a fallos se basa en dos cuestiones,
complementarias entre sí:
1.- Redundancia
hardware (uso de componentes redundantes)
2.- Recuperación
del software (diseño de programas que sean capaces de recuperarse de los
fallos).
En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas.
La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo.
Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina.
En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas.
La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo.
Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina.
Transparencia
La
transparencia se define como la ocultación al usuario y al programador de
aplicaciones de la separación de los componentes de un sistema distribuido, de
manera que el sistema se percibe como un todo, en vez de una colección de
componentes independientes. La transparencia ejerce una gran influencia en el
diseño del software de sistema.
El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son:
Transparencia de Acceso: Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de información locales.
El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son:
Transparencia de Acceso: Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de información locales.
Transparencia de Localización: Permite el acceso a los objetos de información sin conocimiento de su localización.
Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de información compartidos y de forma que no exista interferencia entre ellos.
Transparencia de Replicación: Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia de las réplicas.
Transparencia de Fallos: Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software.
Transparencia de Migración: Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a los programas de aplicación.
Transparencia de Prestaciones. Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia.
Transparencia de Escalado: Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicación.
Las dos más importantes son las transparencias de acceso y de localización; su presencia o ausencia afecta fuertemente a la utilización de los recursos distribuidos. A menudo se las denomina a ambas transparencias de red. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados.
Ventajas
Ø Procesadores
más poderosos y a menos costos
-
Desarrollo de Estaciones con más
capacidades
-
Las estaciones satisfacen las necesidades
de los usuarios.
-
Uso de nuevas interfaces.
Ø Avances
en la Tecnología de Comunicaciones.
-
Disponibilidad de elementos de
Comunicación.
-
Desarrollo de nuevas técnicas.
Ø Compartición
de Recursos.
-
Dispositivos (Hardware).
-
Programas (Software).
Ø Eficiencia
y Flexibilidad.
-
Respuesta Rápida.
-
Ejecución Concurrente de procesos (En
varias computadoras).
-
Empleo de técnicas de procesamiento
distribuido.
Ø Disponibilidad
y Confiabilidad.
-
Sistema poco propenso a fallas (Si un
componente no afecta a la disponibilidad del sistema).
-
Mayores servicios que elevan la
funcionalidad ( Monitoreo, Telecontrol, Correo Eléctrico, Etc.).
Ø Crecimiento
Modular.
-
Es inherente al crecimiento.
-
Inclusión rápida de nuevos recursos.
Desventajas
-
Requerimientos de mayores controles de
procesamiento.
-
Velocidad de propagación de información
(es lenta a veces).
-
Servicios de replicación de datos y
servicios con posibilidades de fallas.
-
Mayores controles de acceso y proceso
(Commit).
-
Administración más compleja.
-
Costos.
REFERENCIAS
[PUNTOS EXTRA] Anti-Patrones
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
¿Qué es un
Anti-Patrón de diseño?
Es un patrón
de diseño pero que conduce a una mala forma de solucionar el problema. Al documentarse
los anti-patrones, además de los patrones de diseño, se dan argumentos a los diseñadores
de sistemas para no escoger malos caminos, partiendo de documentación disponible
en lugar de simplemente la intuición.
Anti-patrones
de diseño orientado a objetos
Acoplamiento
secuencial (sequential coupling): Consiste en diseñar una clase cuyos métodos
requieren ser invocados en un orden determinado.
Problema del
yoyó (yo-yo problem): Consiste en construir estructuras demasiado largas por lo
tanto difíciles de entender lo que provoca que el programador tenga que estar
cambiando entre el uso de clases. Este antiproblema toma este nombre debido a
que el programador requiere estar moviéndose de arriba abajo atraves de todo el
código como lo hace un juguete yo-yo.
Poltergeist:
Consiste en usar objetos cuyo única funcionalidad es pasar la información a
terceros objetos o también emplear métodos simplemente para llamar a otro
método esto implica que el código sea más difícil de leer y que exista código
innecesario.
Objeto
todopoderoso (god object): Consiste en asignar muchas funcionalidades en una
única clase. Un programa estructurado suele estar dividido en varias partes. En
el caso de objecto todopoderoso el asignarle todo una clase no permite tener las
funcionalidades de nuestro programa dividido en varias clases.
REFERENCIAS
[PUNTOS EXTRA] Diseño de Pruebas Unitarias
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Saludos!
[PUNTOS EXTRA] Diagramas de Secuencia
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
A continuación, les presento algunos ejemplos de Diagramas de Secuencia que realizamos en el salón de clases en equipo.
El equipo consistió en:
- Lizbeth A. Treviño Treviño
- Jorge N. Montano González
Saludos!
[PUNTOS EXTRA] Interfaces Gráficas de Usuario
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Saludos!
[PUNTOS EXTRA] Conceptos
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Encontrar las definiciones de los siguiente conceptos:
REFERENCIAS
[PUNTOS EXTRA] Diagrama de Clases con "Umbrello"
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Ejercicio realizado en el salón de clases.
Saludos!
[PUNTOS EXTRA] Diagramas UML
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
UML (Unified
Modeling Language)
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 de negocio, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y componentes
reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Diagramas UML
-
La descripción escrita del comportamiento del
sistema al afrontar una tarea de negocio o un requisito de
negocio. Esta descripción se enfoca en el valor suministrado por el sistema a
entidades externas tales como usuarios humanos u otros sistemas.
-
La posición o contexto del caso de uso entre otros
casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de
usos coherentes y consistentes promueven una imagen fácil de comprender del
comportamiento del sistema, un entendimiento común entre el
cliente/propietario/usuario y el equipo de desarrollo.
Es práctica común crear especificaciones suplementarias para capturar
detalles de requisitos que caen fuera del ámbito de las descripciones de los
casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como:
rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
El diagrama describe la funcionalidad de un Sistema
Restaurante muy simple. Los casos de uso están representados por elipses y
los actores están, por ejemplo, los casos de uso se muestran como parte
del sistema que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de
uso. Si esta interacción es esencial para una descripción coherente del
comportamiento deseado, quizás los límites del sistema o del caso de uso deban
de ser re-examinados. Alternativamente, la interacción entre actores puede ser
parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son
una especie de rol, un usuario humano u otra entidad externa pueden jugar
varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma
persona.
REFERENCIAS
[PUNTOS EXTRA] Casos de Uso
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
A continuación, les presento unos ejemplos de Diagramas de Casos de Uso realizados en el salón de clases en equipo.
El equipo consistió en:
- Lizbeth A. Treviño Treviño
- Jorge N. Montano González
> Buscaminas
> iTunes
> SIASE
Saludos!
[PUNTOS EXTRA] Patrones de Diseño
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Los patrones de diseño son la base para la búsqueda de
soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño
de interacción o interfaces.
Un patrón de
diseño es una solución a un problema de diseño. Para que una solución sea
considerada un patrón debe poseer ciertas características. Una de ellas es que
debe haber comprobado su efectividad resolviendo problemas similares en
ocasiones anteriores. Otra es que debe ser reutilizable,
lo que significa que es aplicable a diferentes problemas de diseño en distintas
circunstancias.
Un patrón de
diseño es:
-
una
solución estándar para un problema común de programación
-
una
técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios
-
un
proyecto o estructura de implementación que logra una finalidad determinada
-
un
lenguaje de programación de alto nivel
-
una
manera más práctica de describir ciertos aspectos de la organización de un programa
-
conexiones
entre componentes de programas
-
la
forma de un diagrama de objeto o de un modelo de objeto.
Los patrones
de diseño pretenden:
-
Proporcionar
catálogos de elementos reusables en el diseño de sistemas software.
-
Evitar
la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
-
Formalizar
un vocabulario común entre diseñadores.
-
Estandarizar
el modo en que se realiza el diseño.
-
Facilitar
el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no
pretenden:
-
Imponer
ciertas alternativas de diseño frente a otras.
-
Eliminar
la creatividad inherente al proceso de diseño.
No es
obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el
mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso
de los patrones puede ser un error".
Según la
escala o nivel de abstracción:
-
Patrones de arquitectura: Aquellos que
expresan un esquema organizativo estructural fundamental para sistemas de
software.
-
Patrones
de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o
sus relaciones) con las que construir sistemas de software.
-
Dialectos:
Patrones de bajo nivel específicos para un lenguaje de programación o entorno
concreto.
-
Interacción:
Son patrones que nos permiten el diseño de interfaces web.
Además,
también es importante reseñar el concepto de "anti-patrón de diseño", que con forma
semejante a la de un patrón, intenta prevenir contra errores comunes de diseño
en el software. La idea de los anti-patrones es dar a conocer los problemas que
acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes
sistemas acaben una y otra vez en el mismo callejón sin salida por haber
cometido los mismos errores.
REFERENCIAS
[PUNTOS EXTRA] Metodologías de Análisis y Diseño de Software
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
El Análisis
El análisis
consiste de un proceso que por medio una exploración básica procura determinar
los elementos a ser tenidos en cuenta para construir las bases de una solución.
Para esto hay
varias estrategias y documentos, los más llamativos son la lluvia de ideas y
los anteproyectos.
En la lluvia
de ideas generalmente se peca por considerar las cosas más fáciles de lo que
realmente son y por dejar ocultos algunos de los aspectos que son de
importancia crítica en el proyecto.
En cuanto al
anteproyecto se puede determinar que en la medida que sus tópicos sean llenados
a conciencia pueden ayudar a garantizar que el análisis sea realmente fructífero.
En esta etapa
también pueden ser levantados otros documentos que pueden incluso tratar de
adelantarse a la etapa de diseño, tales como la identificación de casos de uso
y la identificación de interrelaciones entre los subsistemas identificados o
las relaciones de comunicación con sistemas externos.
De este
aspecto solo una recomendación: la prisa no es buena, el afán por
detallar lo desconocido conduce a una ignorancia que sustenta la confianza
infundada que al final solo lleva a tener que volver al principio a hacer las
cosas bien y con buena letra.
El objeto del
análisis en si es muy simple y es tener una luz sobre donde comenzar. Tan
pronto se identifica esa luz, una lista de cosas por llevar a cabo (sin ser tan
profundos) se puede contemplar algo más.
Pero de lo
anterior que se debe hacer hasta qué punto se debe llegar, la respuesta es
simple también llegue hasta cuando note que empieza a diseñar, es decir, cuando
empiece a ver cantidades y la necesidad de abordar detalles complejos deténgase
a respirar. Si las cosas llegan a tomar un nivel de complejidad que lo lleva a
un consumo muy largo en análisis deténgase también ya habrá ocasión de pensar
en cómo solucionarlo lo cual necesariamente será en el diseño, lo importante en
esta etapa es identificarlo y en la medida de lo deducible rápidamente y concisamente
todo aquello que se le relacione.
Para lo
anterior que se debe identificar, y opcionalmente definir, en el análisis:
Identifique
la justificación para realizar el proyecto en la medida que esta sustente bien
el proyecto este se podrá proyectar como una inversión estable y rentable.
Listado de
instancias principales y tareas. Liste los conceptos más relevantes que
encuentre a su paso (personas, entidades, cuentas, reportes, estadísticas,
seguridad, clientes, usuarios, costos, personal, recursos, tiempo) y sus tareas
básicas respondiendo para ambos con textos descriptivos básicos inspirados en
aquello que el cliente expreso. Con lo anterior elabore un cronograma dadas las
prioridades.
Alcances y limitaciones,
básicas pero sustentables. Si encuentra algo que pueda tomar muchos recursos márquelo
y asígnele una prioridad o una cantidad.
Identificar a
los participantes del proyecto y los roles que jugaran en el mismo.
Un nombre
para el proyecto, uno en lo posible atractivo
Defina lo más
claro posible un objetivo principal y varios específicos a nivel de metas.
El Diseño
Consiste del
proceso que toma los insumos identificados en el análisis para
decantarlos para dar lugar a conceptos, ideas, procesos, operaciones,
etc., que son en si el primer acercamiento, no precisamente a la solución, pero
si a identificar claramente la problemática o los requerimientos a soportar.
De lo
anterior, la premisa es conocer bien que se debe como construirlo y la única
preocupación en la mente de cada miembro del equipo de trabajo es como dar vía
con las herramientas existentes a una solución lo más cercana a lo deseado con
toda la calidad del caso.
Visto de otra
forma es en si la necesidad de saber cómo usar bien lo que hay a la mano, aun
si no se es un experto del todo, para llegar a conseguir la meta siendo conscientes
que se hace lo mejor en cada paso y que el factor de riesgo de tener que
corregir es mínimo y el factor de mejora está supeditado no a la necesidad de
completar cosas que no se hacen sino en la inevitable necesidad que producen
las cosas que cumplen lo que deben hacer y es evolucionar para dar más
soluciones.
[PUNTOS EXTRA] Casos de Sistemas Fallidos
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada
a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
El “Happy Day” se
conoce cuando el programador construye e implementa el sistema y al momento de
hacer las pruebas y distribuir el producto no llega a presentar ningún error,
esas ocasiones son contadas.
Siempre habrá situaciones en las
que después de analizar, desarrollar e implementar el sistema, habrá algún
detalle que corregir en dicho sistema, ningún sistema es perfecto y es por lo
mismo que existen los ingenieros para corregir los problemas que surgen en los
sistemas.
La
crisis del Software
Se implementó en el tiempo que se
creó el software, ya que no siempre se obtenían los resultados esperados, los
costos eran excesivos y poco flexibles, por ese motivo surgió la ingeniería de
software en 1968.
La crisis de software
se refiere a que no es fácil ni existen herramientas para
escribir programas libres de errores, fáciles de entender ni tampoco que sean
verificables. Tampoco existen herramientas para medir exactamente cuánto tiempo
tomará desarrollar un programa. Así que tampoco se puede definir exactamente
cuánto tiempo tomará la creación del proyecto ni la cantidad de personal
necesario.
Las aplicaciones son muy
complejas para utilizarse por una sola persona, por lo que hoy en día sigue
siendo muy difícil definir estimaciones precisas de los costos y del
tiempo necesario para un proyecto.
Al final de la entrada se
encuentra una liga a un video donde se presenta el comercial de
Windows 98.
Y también el siguiente caso es un
caso singular de Bill Gates y su nuevo Win 98, y en ésta ocasión fue
un evento cubierto por la CNN. En este caso el compañero de Bill
Gates estaba explicando la capacidad de Win 98 para instalar un scanner
con sus propios driver pero ocurrió un error fatal y se
muestra la pantalla azul de la muerte por lo que se sorprende el compañero
de Bill Gates. Al final Bill Gates aclara: “Debe ser por esto por lo que aún no
estamos comercializando Windows 98, ¿¿no??“, a lo que su compañero apenado
responde, “Absolutamente, absolutamente!!“.
Al final de la entrada se
encuentra una liga a un video donde se presenta lo mencionado recientemente.
REFERENCIAS
Suscribirse a:
Entradas (Atom)