miércoles, 20 de junio de 2007

TAREAS DE INGENIERIA DE SOFTWARE

UNIDAD 1 ( TAREA 1 ) DEFINICIONES

CALIDAD.- Conjunto de propiedades y características de un producto que le confieren su aptitud para satisfacer una necesidad.

CALIDAD DEL SOFTWARE.- Es el grado en que un sistema o proceso cumple con los requerimientos específicos y necesidades del usuario.

SOFTWARE EMPOTRADO.- Controla productos y sistemas de los mercados industriales y de consumidores.

Características
· Reside en memoria de sólo lectura
· Puede ejecutar funciones muy limitadas y esotéricas (eje. control de teclas de un horno)
· Suministrar una función significativa
· Capacidad de control

(TAREA 2 ) CRISIS DE LA INGENIERIA DEL SOFTWARE
La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda. La complejidad del software producido y demandado se incrementa constantemente. El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software; y con él se etiquetaron a los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial.
Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son:
Baja Calidad del Software.
Tiempo y Presupuesto Excedido.
Confiabilidad Cuestionable.
Altos Requerimientos de Personal para desarrollo y mantenimiento.
Posibles causas de la crisis del software
Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa madurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:
Proyectos gestionados con un sobre-presupuesto.
Proyectos gestionados con sobre tiempo.
Software de baja calidad.
El software a menudo no satisfacía los requerimientos deseados.
Los proyectos fueron inmanejables, con un código difícil de mantener.

( TAREA 3) EXITOS Y FRACASOS DE LA INGENIERIA DE SOFTWARE

Los usuarios, ¿están satisfechos con el software existente? Sí y no. Los logros son
indiscutibles, pero todos hemos oído de sistemas difíciles de usar, que no resuelven el
problema del usuario, que "se cuelgan" o que funcionan mal.

Ejemplos de fracasos:

Sperry Corporation y el IRS (recaudación de impuestos en USA), "un fiasco de 4000 millones de dólares", de 1980 a 1996.

Therac25,equipo de radioterapia, murieron varios pacientes por uso no previsto de teclas.

SDI, proyecto de defensa estratégica (“guerra de las galaxias”), requiere 114000 años de pruebas para asegurar una confiabilidad de 109,mínimo requerido para aplicaciones de alto riesgo.

Un caza Harrier confundió un radar de la policía caminera con un blanco enemigo (1996).

(TAREA 4) EVOLUCION DEL SOFTWARE EN CUANTO A LENGUAJES DE PROGRAMACION
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java[1] o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML)[2], la notación OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP)[3], OPEN[4], MÉTRICA (que también soporta la notación estructurada).

(TAREA 5 ) OBJETIVOS DE LA INGENIERIA DE SOFTWARE

Aumentar la productividad y trabajo de los Ingenieros de Software.
Mejorar la calidad de los productos de Software.
Facilitar el control del proceso de desarrollo de Software.
Suministrar a los desarrolladores las bases para construir Software de alta calidad en forma eficiente.
Definir una disciplina que garantice la producción y mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
( TAREA 6 ) DEFINICIONES DE

El término software de productividad corresponde a una denominación peculiar. Bajo este nombre se acostumbra incluir a hojas de cálculo, procesadores de textos, graficadores y otros. Mientras que los procesadores de texto y graficadores pueden considerarse más como herramientas de trabajo, las hojas de cálculo se destacan por el valor educativo que pueden representar.

PRODUCTIVIDAD.- Es una medida relativa que mide la capacidad de un factor productivo para creare determinados bienes en una unidad de tiempo.

PRODUCTIVIDAD.- Relación entre el producto obtenido y los insumos empleados, medidos en términos reales; en un sentido, la productividad mide la frecuencia del trabajo humano en distintas circunstancias; en otro, calcula la eficiencia con que se emplean en la producción los recursos de capital y de mano de obra.

PRODUCTIVIDAD.- Es la capacidad para producir que se observa a partir de un elemento con capacidad de producir o mediante la combinación de diferentes factores de producción.

(TAREA 7 ) PARADIGMAS DE LA INGENIERIA DE SOFTWARE

PARADIGMA.- Un paradigma de programación es una colección de modelos conceptuales que juntos modelan el proceso de diseño y determinan la estructura de un programa.

TIPOS DE PARADIGMAS DE PROGRAMACIÓN
Que soportan técnicas de programación de bajo nivel
Que soportan métodos de diseño de algoritmos
Que soportan soluciones de programación de alto nivel
Basado para el desarrollo de sistemas expertos
De programación lógica
De programación funcional
De programación heurística
Orientado al objeto







( TAREA 8 ) MITOS EN LA INGENIERIA DE SOFTWARE
· Muchas de las causas de la crisis del software pueden ser encontradas en una mitología que surge durante los primeros años del desarrollo del software
· Los mitos del software propagaron información errónea y con fusión
· Los mitos del software tienen varios atributos que los hacen insidiosos:
· Aparecen como declaraciones responsables de hechos
· Tuvieron un sentido intuitivo
· Frecuentemente fueron promulgados por expertos que " estaban al día "
· Surgen en los primeros años del desarrollo
MITOS DE GESTIÓN
Los gestores están normalmente bajo la presión de cumplir presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. El gestor se agarra a un mito del software aunque tal creencia sólo disminuya la presión temporalmente.
MITOS DEL CLIENTE
Un cliente que solicita una aplicación software puede ser interno a la compañía o una compañía exterior.
El cliente cree en los mitos que existen sobre el software debido a que los gestores y trabajadores responsables hacen muy poco para corregir la mala Información.
Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el desarrollo del software.
MITOS DE LOS REALIZADORES
Los mitos en los que aún creen muchos programadores se han fomentado durante cuatro décadas de cultura Informática.
Las viejas formas y actitudes tardan en morir.

UNIDAD 4

CALIDAD DEL SOFTWARE

– “Concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos con los estándares de desarrollo
explícitamente documentados y con las características implícitas
que se espera de todo software desarrollado profesionalmente”
.
– “El conjunto de características de una entidad que le confieren su
aptitud para satisfacer las necesidades expresadas y las implícitas”





UNIDAD 5

QUE ES REINGENIERIA DE REINGENIERÍA

Reingeniería es la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras espectaculares en medidas críticas y contemporáneas de rendimiento, tales como costos, calidad, servicio y rapidez.

ORIGEN DE LA REINGENIERÍA
El concepto de Reingeniería nace a raíz de la Guerra entre Estados Unidos y España en el año de 1898 cuando, después de un análisis efectuado por la marina de guerra Norteamericana sobre los disparos realizados, se detectó que, de 9.500 disparos, sólo 121 hicieron impacto, cosa que en la época era un gran resultado.
En el año 1899, el mismo estudio detectó que en las prácticas de tiro contra una embarcación estática durante un tiempo aproximado de 25 minutos, únicamente dieron en el blanco dos.
Años mas tarde, en 1902, en las mismas prácticas efectuadas por la marina de guerra norteamericana, se hizo blanco, dentro de un cuadrado de 50 pulgadas cuadradas, la mitad de las veces que se disparó (50 % de aciertos).
Todos estos disparos se hacían en las mismas condiciones (1 milla de distancia o 1.6 kilómetros), lo que demostraba que los cambios hechos en tan solo 3 años habían llevado del 1.3 % al 50% de efectividad. Todo ello se debió a un oficial de la artillería naval, llamado William Sowden Sims, quien, en virtud del uso del proceso de Reingeniería, modificó de manera radical la forma de efectuar los disparos.
Sims cambió la forma en que operaban directamente la técnica y maquinaria que rodeaba el envío de proyectiles a través de la Reingeniería, sin utilizar tecnología adicional y sin necesidad de aumentar el personal y mucho menos de incrementar los costos.
Sin embargo, a principios del siglo XX, el oficial Sims fue ignorado en numerosas ocasiones por razones políticas y sociales, a causa de las antiguas tradiciones que imperaban en la marina norteamericana en aquel momento. Así fue hasta que las teorías de Sims llegaron a oídos del entonces presidente de los Estados Unidos, Roosevelet, quien, al tener conocimiento de las mismas, las puso en práctica de forma tan espectacular que aquel joven oficial se convirtió tiempo después en Almirante.



No hay comentarios: