Revista 1

METODOLOGIA DE SOFTWARE

Evoluci贸n del software An谩lisis de los requisitos del software

La calidad del software

Herramientas del software Mantenimiento del software

Editores Jes煤s Albeiro G贸mez valdeleon

Evolución del software  Primera etapa (1950 – 1965) •

El software estaba en su infancia

•

Distribución limitada

•

Software a la medida

 Segunda etapa (1965 – 1975) •

Multiprogramación

•

Sistemas Multiusuario

•

Bases de datos

 Tercera etapa (1975 – 1985) •

Redes área local y global

•

Hardware de bajo costo

•

Sistemas distribuidos

 Cuarta etapa (1985 –2000) •

Tecnología de objetos

•

Tecnología de internet

•

Sistemas expertos

 Quinta etapa (2000) •

Omnipresencia de la web

•

Reutilización de información

•

Componentes software reutilizables

Incertidumbre Falta de seguridad, de confianza o de certeza sobre algo, especialmente cuando crea inquietud.

La complejidad en el software.

En un sistema, la complejidad es directamente proporcional al número de elementos involucrados y a la complejidad de cada elemento.

La mayoría de las aplicaciones que son especificadas, desarrolladas, mantenidas y utilizadas por una sola persona no son complejas.

La complejidad es parte esencial de los sistemas de software de gran tamaño. Se puede manejar, pero no se puede eliminar.

13 mayores mitos de la actualidad del software Más seguridad es mejor: explica que esta concepción no solamente no aporta nada a la empresa sino que puede suponer un perjuicio para la compañía más seguridad no implica necesariamente mejor seguridad ya que en primer lugar siempre es un trade-off y los costos de seguridad a veces son más altos de lo que vale la pena.

Un mayor ancho de banda evita los ataques DDOS: afirma Carl Herberger, vicepresidente de Soluciones de

Seguridad en Radware, quien dice que existe la creencia generalizada entre los administradores de TI que si sólo tuvieran un suficiente ancho de banda, los ataques de denegación de servicio (DDoS) se podrían evitar.

Contraseñas deben caducar regularmente: numerosos expertos recomiendan cambiar de forma regular sus contraseñas para evitar que sean conocidas por los hackers y por ende, el sistema pueda ser atacado.

La sabiduría de las multitudes: Una y otra vez, un empleado recibirá un email de alguien diciendo que hay un nuevo virus o algún otro tipo de peligro inminente surgido a través de Internet.

Tras esto, esa misma gente afirma que van a ponerse en contacto con el departamento de TI

La virtualización resolverá las amenazas de la consumerización: será resuelto si se tienen dos máquinas virtuales, una para el trabajo y otra para los asuntos personales, de esa manera, todos los riesgos en el aspecto personal serán contenidos y los datos no se trasladarán entre ambos entornos.

Las mejores contraseñas son aquellas completamente aleatorias: Es que si bien

de a pie, los virus informáticos son, sobre todo, un mito. Es decir, la mayor parte de lo que él sabe y conoce sobre los malware le viene de la ciencia ficción, de la televisión y el cine.

No somos un objetivo: Muchas empresas piensan que no vale la pena preocuparse por la piratería. Algunos otros dicen que no vale la pena porque son una pequeña empresa, que no están en el radar de nadie.

El software actual es más seguro que hace una década: El punto que a veces se pasa por alto es que, en comparación con la era de Windows 95, es que se está escribiendo mucho más código y más software que nunca por lo que "los metros cuadrados de código que estamos construyendo son más grandes que nunca”.

La transferencia de información a través de ssl es segura: "Las empresas suelen emplear SSL para enviar información confidencial de clientes o socios partiendo de la creencia de que la transferencia a través de sesiones SSL es segura", afirma Rainer Enders, director de Tecnología de NCP Engineering América.

Con un buen firewall no hay necesidad de un antivirus: afirma que lleva una década como administrador de un servidor de seguridad y explica que existe una gran cantidad de mitos acerca de los firewalls.

las contraseñas completamente aleatorias pueden ser fuertes, también tienen desventajas: por lo general, son difíciles de recordar y más lentas de escribir.

No se debe enviar muestras del malware que le haya atacado a las plataformas de intercambio de información: dice que ha

Todo virus debe producir un síntoma visible en la pantalla: Para el hombre

escuchado en numerosas ocasiones esta recomendación, fruto de un

"asesoramiento deficiente" como él mismo afirma.

Análisis de los requisitos del software La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.

Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software

Estructura de desglose del trabajo (EDT) Es un gráfico en el que los elementos de trabajo críticos, actividades y tareas de un proyecto, se representan para retratar sus relaciones entre sí y con el proyecto en su conjunto. La naturaleza gráfica de la EDT puede ayudar a un gerente de proyecto a predecir los resultados basados en diversos escenarios, lo que contribuye a optimizar la toma de decisiones en todo lo relativo a procedimientos y cambios.

Al crear una EDT, el director del proyecto define los objetivos clave primero y después identifica las tareas necesarias para alcanzar esas metas.

La estructura de desglose de trabajo se asemeja a la forma de un diagrama de árbol con el “tronco” en la parte superior y las “ramas” debajo. El objetivo se muestra en la parte de arriba del gráfico, con detalles cada vez más específicos que van apareciendo a medida que se va descendiendo.

desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.

La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.

La Gestión de la Configuración del Software (GCS/SCM) Es un conjunto de actividades diseñadas para identificar y definir los elementos en el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida, estableciendo relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos elementos, y auditando e informando de los cambios realizados.

La calidad del software Características propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se

Herramientas y métodos del software Métodos de ingeniería de software

Estructurado para el desarrollo de software Facilita la producción de software de alta calidad de una forma costeable No existe un método ideal Métodos se basan en la idea de modelos gráficos

Herramientas del software Una herramienta es un programa informático que usa un programador para crear, depurar, gestionar o mantener un programa.

Herramientas de calidad del Producto Software: HTML Validator ChecKing QA

Proceso de software Un proceso de desarrollo de software es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y sus procedimientos, componentes de software, metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.

Un proceso de software efectivo habilita a la organización a incrementar su productividad al

desarrollar software: • Permite estandarizar esfuerzos, promover reusó, repetición y consistencia entre proyectos.

• Provee la oportunidad de introducir mejores prácticas de la industria.

• Permite entender que las herramientas deben ser utilizadas para soportar un proceso.

• Establece la base para una mayor consistencia y mejoras futuras.

Necesitamos un proceso de software cuya funcionalidad esté probada en la práctica, y personalizado para que cumpla con nuestras necesidades específicas.

Mantenimiento del software El mantenimiento de la computadora es aquel que debemos realizar al computador cada cierto tiempo, bien sea para corregir fallas existentes o para prevenirlas.

• El periodo de mantenimiento depende de diversos factores: la cantidad de horas diarias de operación, el tipo de actividad (aplicaciones) que se ejecutan, el ambiente donde se encuentra instalada (si hay polvo, calor, etc.), el estado general (si es un equipo nuevo o muy usado), y el resultado obtenido en el último mantenimiento.

Tipos de mantenimiento: Mantenimiento correctivo: Tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de provocar un fallo. Un fallo se produce cuando el comportamiento de un sistema difiere con respecto al comportamiento definido en la especificación.

Mantenimiento adaptativo: Consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el que se ejecuta. Desde cambios en el sistema operativo, pasando por cambios en la arquitectura física del sistema informático, hasta en el entorno de desarrollo del software. Este tipo de

mantenimiento puede ser desde un pequeño retoque hasta una reescritura de todo el código.

Mantenimiento perfectivo: Conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.

Modelo DRA Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. Es una adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

El Desarrollo Rápido de Aplicaciones (DRA) (Rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

Estudio de factibilidad Un estudio de factibilidad permite determinar si se cuenta con el mercado suficiente para cumplir las proyecciones financieras de un negocio.

La complejidad de las decisiones de los negocios modernos exige un conocimiento confiable de los diversos mercados. La experiencia administrativa y los juicios son, por supuesto, ingredientes importantes para la toma de decisiones, pero deben reforzarse y expandirse con datos objetivos de investigaciones de campo sistemáticas.

La investigación de mercados tiene una función específica: auxiliar en la planeación efectiva y la toma de decisiones en los mercados. Éstos pueden ser de muchos tipos e implican actividades de consumo, industriales, comerciales e institucionales.

Gestión de Riesgos Es un enfoque estructurado para manejar la incertidumbre relativa a una amenaza, a través de una secuencia de actividades humanas, las cuales son: • Identificación de Riesgos • Estimación de Riesgos.

• Plan de Riesgos.

¿Qué es el Riesgo? El riesgo se define como la probabilidad de que una amenaza se convierta en un desastre.

qué, dónde y con quiénes se puede (y es necesario) aprender.

• Todo cambio implica un riesgo.

• El riesgo implica elección e incertidumbre.

Entornos virtuales de aprendizaje Un entorno virtual de aprendizaje (EVA) es un espacio con accesos restringidos, concebido y diseñado para que las personas que acceden a él desarrollen procesos de incorporación de habilidades y saberes, mediante sistemas telemáticos.

Los entornos virtuales de aprendizaje como instrumento de mediación, Suárez define los entornos virtuales como "un sistema de acción que basa su particularidad en una intención educativa y en una forma específica para lograrlo a través de recursos infovirtuales. Esto es, un EVA orienta una forma de actuación educativa dentro de unos márgenes tecnológicos". Y esa nueva forma de orientar la acción que nos proporcionan las TIC, y con ello un EVA, facilitan entre otras:

Las posibilidades de acceso a la información y a la comunicación (material digital e hipertextual).

La libertad del estudiante para orientar su acción, en tanto amplían su concepción del

La ampliación de estrategias de aprendizaje la relación con las tecnologías, y las posibilidades de aprender con tecnología y aprender de tecnología.

Los efectos cognitivos gracias a la interacción con la tecnología informacional, que ponen en evidencia que éstas modifican las estrategias de pensamiento, sus formas de representación, las estrategias de meta cognición, las formas de ver el mundo y ciertas habilidades de procesamiento y comunicación de la información, que efectivamente sirven de guía, apoyando y organizando, el proceso de aprendizaje.

La posibilidad de mejorar algunas habilidades cognitivas que dependen directamente del estímulo específico de cada herramienta, ampliando el repertorio de lo que podemos pensar y hacer cooperativamente.

Las representaciones simbólicas y herramientas complejas de actuación basadas en la interacción cooperativa entre personas.

modelos conceptuales desarrollados durante el análisis, existen: El Diseño de los datos: Trasforma el modelo de dominio de la información, creado durante el análisis, las estructuras de datos necesarios para implementar el Software.

El Diseño Arquitectónico: Define la relación entre cada uno de los elementos estructurales del programa.

El Diseño de la Interfaz: Describe como se comunica el Software , con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.

Diseño de software El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema de Ingeniería. Hay tres características que sirven como parámetros generales para la evaluación de un buen diseño.

El diseño debe implementar todos los requisitos explícitos obtenidos en la etapa de análisis.

El diseño debe ser una guía que pueda leer y entender los que construyen el código y los que prueban y mantienen el software.

El Diseño de procedimientos: Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto.

El Diseño es la única manera de materializar con precisión los requerimientos del cliente.

Construcción del software

El diseño debe proporcionar una idea completa de los que es el software.

El diseño del software desarrolla un modelo de instrumentación o implantación basado en los

El término de construcción de software hace referencia a la creación detallada del software básico, a través de una combinación de

codificación, comprobación, prueba de unidad, pruebas de integración, y depuración.

La área de conocimientos de construcción de software es conectada con el diseño de software y a la prueba de software. Esto es porque el proceso de construcción de software involucra la actividad de diseño y prueba de software de manera importante. También usa el producto del diseño y provee una de las contribuciones a hacer pruebas, tanto el diseño como la prueba siendo las actividades, no las áreas de conocimiento en este caso. Los límites claros entre el diseño, la construcción, y la prueba, variarán dependiendo de los procesos de ciclo de vida de software que son usados en un proyecto.

La construcción de software causa el volumen más alto de elementos de configuración que tienen que ser dirigidos en un proyecto de software (archivos fuente, el contenido, las pruebas, etcétera) típicamente. Por lo tanto, el área de conocimiento de construcción de software también es conectado con el área de conocimiento de administración de configuración de software.

Debido a que la construcción de software depende de herramientas y métodos, es probablemente que el área de conocimiento que está más vinculada es la de las herramientas de ingeniería de software y lo métodos.

Pruebas de software Las pruebas de software consisten en la dinámica de la verificación del comportamiento de un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son una serie de actividades que se realizan con el propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de un programa u ordenador; probando el comportamiento del mismo.

Pruebas como proceso

La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas.

Es un proceso de ejecución de un programa con la intención de descubrir un error, no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Objetivos de las pruebas de software.

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están: Detectar defectos en el software.

Verificar la integración adecuada de los componentes.

Verificar que todos los requisitos se han implementado correctamente.

Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.

Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.

Principios de las pruebas de software.

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan: La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.

La principal dificultad del proceso de prueba es decidir cuándo parar.

Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.

Una parte necesaria de un caso de prueba es la definición del resultado esperado.

Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.

El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.

Arquitectura de software.

La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construcción de un software, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación. Es considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto que establecen la estructura, funcionamiento e interacción entre las partes del software.

Componentes e interacciones Componentes La arquitectura de software se compone por: •

clientes y servidores.

•

bases de datos.

•

filtros.

•

niveles en sistemas jerárquico.

Interacciones Entre los componentes de la arquitectura de software existe un conjunto de interacciones entre las que sobresalen:

Arquitectura de software

•

llamadas a procedimientos.

•

comportamiento de variables.

•

protocolos cliente servidor.

•

transmisión asíncrona de eventos.

Características La arquitectura de software forma la columna vertebral para construir un sistema de software, es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del software.

Además es un modelo abstracto reutilizable que puede transferirse de un sistema a otro y que representa un medio de comunicación y discusión entre participantes del proyecto, permitiendo así la interacción e intercambio entre los desarrolladores con el objetivo final de establecer el intercambio de conocimientos y puntos de vista entre ellos.

Tipos de arquitecturas

Modelos estructurales Son similares a la vista estructural, pero su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición. Los modelos de framework a menudo se refieren a dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes específicos, como PRISM.

Modelos dinámicos Enfatizan la cualidad conductual de los sistemas ,”Dinámico” puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de la computación, tales como valores cambiantes de datos.

Modelos de proceso

Para utilizar la arquitectura de software se sigue un conjunto de patrones arquitectónicos, entre los cuales podemos encontrar: •

Cliente-Servidor

•

Blackboard.

•

Modelo entre capas.

•

Intérprete.

•

Orientado a servicios.

Modelos de la arquitectura de software La arquitectura de software cuenta con varios modelos, ellos son:

Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa construcción. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar arquitecturas.