Modelos y Sistemas Clase 1 y 2

El software y la Ingeniería de Software

TP1-2020 ( Para descargar)

Código Classroom: ck6ozet

Si lo queres leer desde aca
                     ⬇⬇⬇⬇⬇⬇

Trabajo Práctico N°1

1) Luego de leer el TEXTO 1, completar la tabla comparativa con las diferencias entre hardware y software respecto a los siguientes puntos de vistas:

- Calidad – Fase de manufactura – Fallas – Causa de desgaste – Causas de deterioro – Reutilización de componentes –

2) Habiendo leído el TEXTO 2, responder:

a) ¿Qué representa la mala calidad en el software?

b) ¿Qué se hace si se desarrolla un sistema a partir de una heredada de mala calidad?

c) ¿Qué tipos de cambios se hacen a los sistemas heredados?

3) Dar dos ejemplos que indiquen el efecto del software en nuestra sociedad (dos positivos y dos negativos).

4) Considerando las 7 categorías del software, ¿podría aplicarse a cada una el mismo enfoque de la ingeniería del software? ¿Por qué?

5) Del texto WEBAPPS, responder:

            a) ¿Cuáles eran las funcionalidades de las webs antiguamente? (Antes de ser webapps)

b) Definir webapps y describir su funcionalidad.

c) ¿Cuál es la relación entre la inmediatez, los datos y la carga impredecible?

d) Da dos ejemplos de webs donde es importante la seguridad.

e) ¿Cuáles son las diferencias con otros softwares?

6) ¿Qué significa mito para vos?

7) Luego de leer el texto Mitos del Software:

a) ¿Qué es un mito para la Ingeniería de Software?

b) ¿Cuáles son las consecuencias de que sigan en pie?

c) ¿Quiénes son los responsables de que estos continúen?

Anexo. Lecturas.

TEXTO 1

El software se desarrolla o modifica con intelecto; no se manufactura en el sentido clásico. Aunque hay algunas similitudes entre el desarrollo de software y la fabricación de hardware, las dos actividades son diferentes en lo fundamental. En ambas, la alta calidad se logra a través de un buen diseño, pero la fase de manufactura del hardware introduce problemas de calidad que no existen (o que se corrigen con facilidad) en el software.

Ambas actividades dependen de personas, pero la relación entre los individuos dedicados y el trabajo logrado es diferente por completo (véase el capítulo 24). Las dos actividades requieren la construcción de un “producto”, pero los enfoques son distintos. Los costos del software se concentran en la ingeniería. Esto significa que los proyectos de software no pueden administrarse como si fueran proyectos de manufactura.

El software no se “desgasta”. La imagen de la derecha muestra la tasa de falla del hardware como función del tiempo. La relación, que es frecuente llamar “curva de tina”, indica que el hardware presenta una tasa de fallas relativamente elevada en una etapa temprana de su vida (fallas que con frecuencia son atribuibles a defectos de diseño o manufactura); los defectos se corrigen y la tasa de fallas se ubica a un nivel estable durante cierto tiempo. No obstante, conforme pasa el tiempo, la tasa de fallas aumenta de nuevo a medida que los componentes del hardware resienten los efectos acumulativos de suciedad, vibración, abuso, temperaturas extremas y muchos otros inconvenientes ambientales. En pocas palabras, el hardware comienza a desgastarse.

El software no es susceptible a los problemas ambientales que hacen que el hardware se desgaste. Por tanto, en teoría, la curva de la tasa de fallas adopta la forma de la “curva idealizada” que se aprecia en la imagen de la izquierda. Los defectos ocultos ocasionarán tasas elevadas de fallas al comienzo de la vida de un programa. Sin embargo, éstas se corrigen y la curva se aplana, como se indica. La curva idealizada es una gran simplificación de los modelos reales de las fallas del software. Aun así, la implicación está clara: el software no se desgasta, ¡pero sí se deteriora!

Durante su vida, el software sufrirá cambios. Es probable que cuando éstos se realicen, se introduzcan errores que ocasionen que la curva de tasa de fallas tenga aumentos súbitos, como se ilustra en la “curva real”. Antes de que la curva vuelva a su tasa de fallas original de estado estable, surge la solicitud de otro cambio que hace que la curva se dispare otra vez. Poco a poco, el nivel mínimo de la tasa de fallas comienza a aumentar: el software se está deteriorando como consecuencia del cambio.

Otro aspecto del desgaste se ve cuando un componente del hardware se desgasta es sustituido. En cambio, no hay refacciones para el software. Cada falla de éste indica un error en el diseño o en el proceso que tradujo el diseño a código ejecutable por la máquina. Entonces, las tareas de mantenimiento del software, que incluyen la satisfacción de peticiones de cambios, involucran una complejidad considerablemente mayor que el mantenimiento del hardware.

Aunque la industria se mueve hacia la construcción basada en componentes, la mayor parte del software se construye para un uso individualizado. A medida que evoluciona una disciplina de ingeniería, se crea un conjunto de componentes estandarizados para el diseño. Los componentes reutilizables han sido creados para que el ingeniero pueda concentrarse en los elementos verdaderamente innovadores de un diseño; es decir, en las partes de éste que representan algo nuevo. En el mundo del hardware, volver a usar componentes es una parte natural del proceso de ingeniería. En el del software, es algo que apenas ha empezado a hacerse a gran escala.

Un componente de software debe diseñarse e implementarse de modo que pueda volverse a usar en muchos programas diferentes. Los modernos componentes reutilizables incorporan tanto los datos como el procesamiento que se les aplica, lo que permite que el ingeniero de software cree nuevas aplicaciones a partir de partes susceptibles de volverse a usar. Por ejemplo, las actuales interfaces interactivas de usuario se construyen con componentes reutilizables que permiten la creación de ventanas gráficas, menús desplegables y una amplia variedad de mecanismos de interacción. Las estructuras de datos y el detalle de procesamiento que se requieren para construir la interfaz están contenidos en una librería de componentes reusables para tal fin.

TEXTO 2

Hay veces en las que los sistemas heredados tienen diseños que no son susceptibles de extenderse, código confuso, documentación mala o inexistente, casos y resultados de pruebas que nunca se archivaron, una historia de los cambios mal administrada… la lista es muy larga. A pesar de esto, dichos sistemas dan apoyo a las “funciones básicas del negocio y son indispensables para éste.

La única respuesta razonable es: hacer nada, al menos hasta que el sistema heredado tenga un cambio significativo. Si el software heredado satisface las necesidades de sus usuarios y corre de manera confiable, entonces no falla ni necesita repararse. Sin embargo, conforme pase el tiempo será frecuente que los sistemas de software evolucionen por una o varias de las siguientes razones: El software debe adaptarse para que cumpla las necesidades de los nuevos ambientes del cómputo y de la tecnología, debe ser mejorado para implementar nuevos requerimientos del negocio y ampliarse para que sea operable con otros sistemas o bases de datos modernos. La arquitectura del software debe rediseñarse para hacerla viable dentro de un ambiente de redes.

Cuando ocurren estos modos de evolución, debe hacerse la reingeniería del sistema heredado para que sea viable en el futuro.”

WEBAPPS

En los primeros días de la Red Mundial (entre 1990 y 1995), los sitios web consistían en poco más que un conjunto de archivos de hipertexto vinculados que presentaban la información con el empleo de texto y gráficas limitadas. Al pasar el tiempo, el aumento de HTML por medio de herramientas de desarrollo (XML, Java) permitió a los ingenieros de la web brindar capacidad de cómputo junto con contenido de información. Habían nacido los sistemas y aplicaciones basados en la web (denominadas webapps). En la actualidad, éstas se han convertido en herramientas sofisticadas de cómputo que no sólo proporcionan funciones aisladas al usuario final, sino que también se han integrado con bases de datos corporativas y aplicaciones de negocios.

Son una de varias categorías distintas de software, pero diferentes. Powell sugiere que los sistemas y aplicaciones basados en web “involucran una mezcla entre las publicaciones impresas y el desarrollo de software, entre la mercadotecnia y la computación, entre las comunicaciones internas y las relaciones exteriores, y entre el arte y la tecnología”.

La gran mayoría presenta los siguientes atributos:

• ·     Uso intensivo de redes. Una webapp reside en una red y debe atender las necesidades de una comunidad diversa de clientes. La red permite acceso y comunicación mundiales o tiene acceso y comunicación limitados.
• ·        Concurrencia. A la webapp puede acceder un gran número de usuarios a la vez. En muchos casos, los patrones de uso entre los usuarios finales varían mucho.
• ·        Carga impredecible. El número de usuarios cambia en varios órdenes de magnitud de un día a otro.
• ·        Rendimiento. Si un usuario debe esperar demasiado (para entrar, para el procesamiento por parte del servidor, para el formado y despliegue del lado del cliente), él o ella quizá decidan irse a otra parte.
• ·        Disponibilidad. Aunque no es razonable esperar una disponibilidad de 100%, es frecuente que los usuarios de webapps populares demanden acceso las 24 horas de los 365 días del año. Los usuarios en Australia o Asia quizá demanden acceso en horas en las que las aplicaciones internas de software tradicionales en Norteamérica no estén en línea por razones de mantenimiento.
• ·        Orientadas a los datos. La función principal es el uso de hipermedios para presentar al usuario final contenido en forma de texto, gráficas, audio y video. Además, las webapps se utilizan en forma común para acceder a información que existe en bases de datos que no son parte integral del ambiente basado en web (por ejemplo, comercio electrónico o aplicaciones financieras).
• ·        Contenido sensible. Calidad y naturaleza estética del contenido.
• ·        Evolución continúa. A diferencia del software de aplicación convencional que evoluciona a lo largo de una serie de etapas planeadas y separadas cronológicamente, las aplicaciones web evolucionan en forma continua. No es raro que algunas (específicamente su contenido) se actualicen minuto a minuto o que su contenido se calcule en cada solicitud.
• ·        Inmediatez. Aunque la inmediatez —necesidad apremiante de que el software llegue con rapidez al mercado— es una característica en muchos dominios de aplicación, es frecuente que tengan plazos de algunos días o semanas para llegar al mercado.
• ·        Seguridad. Debido a que se encuentran disponibles con el acceso a una red, es difícil o imposible limitar la población de usuarios finales que pueden acceder a la aplicación. Con el fin de proteger el contenido sensible y brindar modos seguros de transmisión de los datos, deben implementarse medidas estrictas de seguridad a través de la infraestructura de apoyo de una webapp y dentro de la aplicación misma.
• ·        Estética. Parte innegable del atractivo de una webapp es su apariencia y percepción. Cuando se ha diseñado una aplicación para comercializar o vender productos o ideas, la estética tiene tanto que ver con el éxito como el diseño técnico.

MITOS DEL SOFTWARE

Actitudes equivocadas que han ocasionado serios problemas a los administradores y a los trabajadores por igual. Sin embargo, las actitudes y hábitos antiguos son difíciles de modificar, y persisten algunos remanentes de los mitos del software.

·     Mitos de la administración. Los gerentes que tienen responsabilidades en el software con frecuencia se hallan bajo presión para cumplir el presupuesto, mantener la programación de actividades sin desvíos y mejorar la calidad.

Mito: Tenemos un libro lleno de estándares y procedimientos para elaborar software. ¿No le dará a mi personal todo lo que necesita saber? Realidad: Tal vez exista el libro de estándares, pero ¿se utiliza? ¿Saben de su existencia los trabajadores del software? ¿Refleja la práctica moderna de la ingeniería de software? ¿Es completo? ¿Es adaptable? ¿Está dirigido a mejorar la entrega a tiempo y también se centra en la calidad? En muchos casos, la respuesta a todas estas preguntas es “no”.

Mito: Si nos atrasamos, podemos agregar más programadores y ponernos al corriente Realidad: El desarrollo del software no es un proceso mecánico similar a la manufactura. A medida que se agregan personas, las que ya se encontraban trabajando deben dedicar tiempo para enseñar a los recién llegados, lo que disminuye la cantidad de tiempo dedicada al esfuerzo de desarrollo productivo. Pueden agregarse individuos, pero sólo en forma planeada y bien coordinada.

Mito: Si decido subcontratar el proyecto de software a un tercero, puedo descansar y dejar que esa compañía lo elabore.

Realidad: Si una organización no comprende cómo administrar y controlar proyectos de software internamente, de manera invariable tendrá dificultades cuando subcontrate proyectos de software.

·     Mitos del cliente. El cliente que requiere software de computadora puede ser la persona en el escritorio de al lado, un grupo técnico en el piso inferior, el departamento de mercadotecnia y ventas, o una compañía externa que solicita software mediante un contrato. En muchos casos, el cliente sostiene mitos sobre el software porque los gerentes y profesionales de éste hacen poco para corregir la mala información. Los mitos generan falsas expectativas y, en última instancia, la insatisfacción con el desarrollador.

Mito: Para comenzar a escribir programas, es suficiente el enunciado general de los objetivos —podremos entrar en detalles más adelante. Realidad: Aunque no siempre es posible tener el enunciado exhaustivo y estable de los requerimientos, un “planteamiento de objetivos” ambiguo es una receta para el desastre. Los requerimientos que no son ambiguos (que por lo general se obtienen en forma iterativa) se desarrollan sólo por medio de una comunicación eficaz y continua entre el cliente y el desarrollador.

Mito: Los requerimientos del software cambian continuamente, pero el cambio se asimila con facilidad debido a que el software es flexible. Realidad: Es verdad que los requerimientos del software cambian, pero el efecto que tienen varía según la época en la que se introducen. Cuando se solicitan al principio cambios en los requerimientos (antes de que haya comenzado el diseño o la elaboración de código), el efecto sobre el costo es relativamente pequeño. Sin embargo, conforme pasa el tiempo, el costo aumenta con rapidez: los recursos ya se han comprometido, se ha establecido la estructura del diseño y el cambio ocasiona perturbaciones que exigen recursos adicionales y modificaciones importantes del diseño.

·     Mitos del profesional.

Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad: Alguien dijo alguna vez que “entre más pronto se comience a ‘escribir el código’, más tiempo tomará hacer que funcione”. Los datos de la industria indican que entre 60 y 80% de todo el esfuerzo dedicado al software ocurrirá después de entregarlo al cliente por primera vez.

Mito: Hasta que no se haga “correr” el programa, no hay manera de evaluar su calidad. Realidad: Uno de los mecanismos más eficaces de asegurar la calidad del software puede aplicarse desde la concepción del proyecto: la revisión técnica. Las revisiones del software son un “filtro de la calidad” que se ha revelado más eficaz que las pruebas para encontrar ciertas clases de defectos de software.

Mito: El único producto del trabajo que se entrega en un proyecto exitoso es el programa que funciona. Realidad: Un programa que funciona sólo es una parte de una configuración de software que incluye muchos elementos. Son varios los productos terminados (modelos, documentos, planes) que proporcionan la base de la ingeniería exitosa y, lo más importante, que guían el apoyo para el software.

Mito: La ingeniería de software hará que generemos documentación voluminosa e innecesaria, e invariablemente nos retrasará. Realidad: La ingeniería de software no consiste en producir documentos. Se trata de crear un producto de calidad. La mejor calidad conduce a menos repeticiones, lo que da como resultado tiempos de entrega más cortos.

Para cualquier inquietud, dejen sus dudas en los comentarios