Monografias.com > Computación > Software
Descargar Imprimir Comentar Ver trabajos relacionados

Ingeniería del software




Enviado por Pablo Turmero



    Monografias.com
    Concepto de Ingeniería de Sistemas Concepto de sistema,
    conjunto de cosas que ordenadamente relacionadas entre sí
    contribuyen a un determinado objeto. De forma recursiva, las
    partes de un sistema pueden ser consideradas como nuevos sistemas
    (subsistemas). Los sistemas informáticos están
    compuestos por ordenadores y sus periféricos. Entre ellos
    podemos distinguir dos tipos de subsistemas: Sistemas Hardware,
    son los elementos materiales, los que se pueden tocar. Sistemas
    Software, los programas que gobiernan el funcionamiento del
    computador. El objetivo de los sistemas informáticos es el
    tratamiento de la información: almacenamiento,
    elaboración y presentación de datos. De esta forma
    se automatizan determinadas acciones. En la concepción del
    sistema informático no solo se decide el trabajo a
    realizar, sino también cómo ha de ser utilizado por
    los usuarios.

    Monografias.com
    Concepto de Ingeniería del Software Características
    del software (lo contrario para el hardware): No se desgasta ni
    envejece, y por este motivo no requiere reparaciones ocasionales
    Su duplicación es poco costosa, lo caro es el desarrollo
    Puede ser modificado fácilmente, tanto que es necesario un
    control de versiones La Ingeniería del Software comprende
    las técnicas y procedimientos ingenieriles para el
    desarrollo del software. La IS no se plantea solo una actividad
    de programación, previamente son necesarias las fases de
    análisis y diseño y posteriormente la
    integración y la verificación, incluso el
    manteniendo cuando el producto ya está en
    explotación. (CICLO DE VIDA). Inicialmente la tarea de
    desarrollo era realizada individualmente por hábiles
    creativos, de forma poco disciplinada. El trabajo en equipo
    supone la división y organización del trabajo
    utilizando metodologías de desarrollo. En los 70 y los 80
    empiezan a usarse herramientas CASE (Computer Aided Software
    Engineering). En los 90 IPSE e ICASE.

    Monografias.com
    La crisis del Software Se produce cuando surge la necesidad de
    desarrollar aplicaciones software demasiado complejas, a mediados
    de los 60. Para superar la crisis: Aparición de
    metodologías concretas de desarrollo Concepción de
    la Ingeniería del Software como disciplina Trabajo en
    equipo y especialización (analistas, programadores, …)
    No se ha llegado a una situación estable, sino a una
    evolución permanente con avances continuos en la IS,
    forzados por el rápido abaratamiento y aumento de
    capacidad del hardware.

    Monografias.com
    Mitos del Software El hardware es mucho más importante que
    el software El software es fácil de desarrollar El
    software consiste exclusivamente en programas ejecutables El
    desarrollo del software es sólo una labor de
    programación Es natural que el software contenga
    errores

    Monografias.com
    Formalización del proceso de desarrollo La
    ingeniería supone la existencia de procesos bien
    establecidos para la realización de actividades de
    desarrollo, construcción, fabricación, etc. El
    ciclo de vida es el proceso de desarrollo y mantenimiento del
    software. Según el modelo elegido se describen un conjunto
    de actividades para llevar a cabo el ciclo de vida, Los modelos
    clásicos: MODELO EN CASCADA MODELO EN V
    Prácticamente identifican actividades similares y
    sólo se diferencian en la forma de
    presentación.

    Monografias.com
    MODELO EN CASCADA

    Monografias.com
    MODELO EN CASCADA ANÁLISIS, determinar qué debe
    hacer el software -> especificación DISEÑO,
    descomponer y organizar el sistema para que los módulos
    puedan ser desarrollados por separado CODIFICACIÓN,
    escribir el código fuente de cada módulo y realizar
    sobre ellos las pruebas necesarias INTEGRACIÓN, combinar
    todos los módulos y probar el sistema completo antes de
    pasar a su explotación MANTENIMIENTO, durante la
    explotación es necesario realizar cambios ocasionales bien
    para corregir errores o para introducir mejoras, Se trata de
    aislar cada fase de las otras, lo que facilita la
    especialización de los desarrolladores. Al final de cada
    fase se requiere un proceso de revisión`para evitar que
    los errores se propaguen a fases posteriores provocando la vuelta
    atrás.

    Monografias.com
    MODELO EN CASCADA AMPLIADO

    Monografias.com
    MODELO EN CASCADA Cada fase debe generar una información
    de salida precisa y suficiente: DOCUMENTOS DE REQUISITOS DEL
    SOFTWARE (SRD), es una especificación precisa y completa a
    partir de los requisitos establecidos por el cliente. DOCUMENTO
    DE DISEÑO DEL SOFTWARE (SDD),descripción de la
    estructura global del sistema, especificación de
    qué debe hacer cada uno de los módulos y de
    cómo se combinan. CÓDIGO FUENTE, el programa
    debidamente comentado (documentación interna). SISTEMA
    SOFTWARE, el ejecutable producto dela fase de integración
    y la documentación de las pruebas realizadas. DOCUMENTOS
    DE CAMBIOS, después de cada modificación realizada
    en la fase de mantenimiento: problema detectado y solución
    adoptada

    Monografias.com
    MODELO EN V

    Monografias.com
    MODELO EN V AMPLIADO

    Monografias.com
    MODELO EN V Incluye fases similares a las del modelo en cascada
    pero de forma jerárquica. En horizontal se representa el
    avance en el desarrollo y en vertical el nivel de detalle.
    VERIFICACIÓN, comprobación de que una parte del
    sistema cumple con sus especificaciones. VALIDACIÓN,
    comprobación de que un elmento satisface las necesidades
    del usuario identificadas durante el análisis.

    Monografias.com
    PROTOTIPOS En los modelos clásicos se insiste en las
    actividades de revisión de resultados al final de cada
    fase para evitar la vuelta atrás, que no se contempla de
    una forma organizada y resulta muy costosa. Están
    orientados a una forma de desarrollo lineal. PROTOTIPO, es un
    sistema auxiliar que permite probar experimentalmente soluciones
    parciales a los requisitos del sistema Para que el coste de
    desarrollo del prototipo sea bajo en relación al del
    sistema final podemos: Limitar las funciones Limitar su capacidad
    Limitar su eficiencia Evitar limitaciones de diseño,
    utilizando un hardware más potente que el que
    ejecutará el sistema final Reducir la parte a
    desarrollar

    Monografias.com
    PROTOTIPOS RÁPIDOS Su finalidad es solo adquirir
    experiencia, no se aprovechan como producto (usar y tirar). Se
    denominan maquetas cuando su funcionalidad o capacidad es muy
    limitada. El sistema final se codifica totalmente partiendo de
    cero, no se aprovecha el código del prototipo Lo
    importante de estos prototipos es que se desarrollen en poco
    tiempo.

    Monografias.com
    PROTOTIPOS RÁPIDOS

    Monografias.com
    PROTOTIPOS EVOLUTIVOS En este caso se intenta aprovechar al
    máximo el código del prototipo, y para ello se
    emplea el mismo hardware/software del sistema final. Se realizan
    fases de análisis y diseño parcial, que se van
    ampliando hasta construir el sistema final mediante adiciones
    sucesivas. Se puede considerar un modelo en cascada en bucle, de
    manera que en cada iteración se va avanzando en el
    desarrollo. HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se
    emplean lenguajes de 4ª generación, que son de alto
    nivel y de tipo declarativo. También se emplean lenguajes
    de especificación, como VDM y Z. Si disponemos del
    compilador correspondiente podemos obtener automáticamente
    el código del prototipo. En el desarrollo de prototipos es
    clave la reutilización de software.

    Monografias.com
    PROTOTIPOS EVOLUTIVOS

    Monografias.com
    MODELO EN ESPIRAL Puede considerarse como un refinamiento del
    modelo evolutivo general que introduce el análisis de
    riesgo como elemento fundamental para guiar la evolución
    del proceso de desarrollo. En la dimensión radial se
    representa el esfuerzo realizado en el desarrollo (siempre
    creciente) En cada iteración 4 fases:
    PLANIFICACIÓN, determina que parte del desarrollo se
    abordará en ese ciclo. ANALISIS DE RIESGO, evaluar
    diferentes alternativas para esa parte del desarrollo
    seleccionando la más ventajosa y tomando precauciones para
    evitar los posibles inconvenientes. INGENIERÍA, las
    actividades de los modelos clásicos EVALUACIÓN, se
    analizan los resultados de la fase de ingeniería.

    Monografias.com
    MODELO EN ESPIRAL

    Monografias.com
    MANTENIMIENTO DEL SOFTWARE El mantenimiento no representa una
    actividad específica, sino que consiste en rehacer parte
    de las actividades correspondientes a las otras fases del
    desarrollo para introducir cambios sobre una aplicación ya
    en fase de explotación. MANTENIMIENTO CORRECTIVO, su
    finalidad es corregir errores que no fueron detectados en el
    desarrollo del producto. MANTENIMIENTO ADAPTATIVO, modificar una
    aplicación para adaptarla a las nuevas necesidades del
    entorno. MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo
    versiones mejoradas del producto

    Monografias.com
    GESTIÓN DE CAMBIOS El mantenimiento supone la
    realización de una serie de cambios sucesivos Si afectan a
    la mayor parte del sistema se puede plantear como un nuevo
    desarrollo. Cada cambio debe ser documentado con: INFORME DEL
    PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el
    cliente. INFORME DE CAMBIO, describe la solución dada al
    problema y el cambio realizado REINGENIERÍA, es necesaria
    cuando el desarrollo de una aplicación no está
    documentado y se dispone solamente del código. Se llama
    también ingeniería inversa porque supone
    reconstruir y documentar las fases de análisis y
    diseño llegando a la estructura modular de la
    aplicación y las dependencias entre módulos y
    funciones. Estas actividades organizan y documentan un sistema
    deficiente.

    Monografias.com
    GARANTÍA DE CALIDAD Para evaluar la calidad son necesarias
    técnicas de aplicación de métricas precisas
    tanto sobre los productos software como a sus procesos de
    desarrollo. McCall propone un esquema basado en valoraciones a 3
    niveles: FACTORES, valoración significativa de la calidad
    en base a los criterios establecidos CRITERIOS, aspectos de nivel
    intermedio que influyen en los factores de calidad
    MÉTRICAS, mediciones puntuales de determinadas
    características del producto. Entre los factores de
    calidad tenemos: CORRECCIÓN, grado en que cumple con las
    especificaciones FIABILIDAD, grado de ausencia de fallos
    EFICIENCIA, reilación entre la cantidad de resultados y
    los recursos requeridos SEGURIDAD, dificultad para el acceso a
    datos por personas no autorizadas FACILIDAD DE USO, esfuerzo
    requerido para el aprendizaje de la aplicación
    MANTENIBILIDAD. Facilidad para corregir el producto en caso
    necesario. FLEXIBILIDAD, facilidad para modificar el producto
    FACILIDAD DE PRUEBA, depende del esfuerzo requerido para
    comprobar su corrección o fiabilidad TRANSPORTABILIDAD,
    facilidad para adaptar el producto a otra plataforma
    REUSABILIDAD, facilidad para usar partes del producto en otros
    desarrollos INTEROPERATIVIDAD, facilidad del producto para
    trabajar con otros

    Monografias.com
    PLAN DE GARANTÍA DE CALIDAD (SQAP) Es un documento formal
    para organizar el proceso de desarrollo software de manera que se
    asegure la calidad del producto final. Debe contemplar:
    Organización, dirección y seguimiento de los
    equipos de desarrollo Modelo de ciclo de vida a seguir,
    detallando fases y actividades Documentación requerida,
    determinando contenido y guión de cada documento
    Revisiones y auditorias, para garantizar que las actividades y
    los documentos son correctos Organización de las pruebas,
    a distintos niveles Organización de la etapa de
    mantenimiento, determinando cómo gestionar la
    realización de cambios

    Monografias.com
    REVISIONES Consiste en inspeccionar el resultado de una actividad
    para determinar si es aceptable o contiene defectos que han de
    ser subsanados. Las revisiones deben ser formalizadas y
    contempladas en el modelo de ciclo de vida: Deben ser realizadas
    por un grupo de personas y no individualmente El grupo de be ser
    reducido Debe ser imparcial, nada que ver con los desarrolladores
    Se debe revisar el producto, pero no el productor ni el proceso
    de producción Se debe establecer de antemano una lista
    formal de comprobaciones Se debe levantar acta de la
    reunión de revisión, recogiendo las decisiones
    tomadas

    Monografias.com
    PRUEBAS Consiste en hacer funcionar el producto o una parte de
    él y comprobar si los resultados son correctos. No permite
    garantizar la calidad del producto. En general no es posible
    probar un producto de forma exhaustiva, debido a su
    complejidad.

    Monografias.com
    GESTIÓN DE CONFIGURACIÓN CONFIGURACIÓN,
    disposición de las partes que componen una cosa y le dan
    su peculiar figura. La CONFIGURACÏÓN SOFTWARE se
    refiere a la manera en que diversos elementos se combinan para
    construir un producto software. Se han de combinar todos los
    elementos que intervienen en el desarrollo: Documentos del
    desarrollo Código fuente Programas, datos y resultado de
    las pruebas Manuales de usuario Documentos de mantenimiento,
    informes de problemas y cambios Prototipos intermedios Normas
    particulares del proyecto Dado que los elementos software van
    evolucionando a lo largo del desarrollo se requiere: Control de
    versiones, almacenar de forma organizada las sucesivas versiones
    de cada elemento de la configuración. Control de cambios,
    garantizar que las diferentes configuraciones del software se
    componen de elementos compatibles entre sí (línea
    base).

    Monografias.com
    NORMAS Y ESTÁNDARES IEEE, Institute of Electrical and
    Electronics Engineer de USA [IEEE93] DoD, Departament od Defense
    de USA [DoD88] ESA, Agencia Europea del Espacio [ESA91] ISO,
    organismo internacional de normalización (International
    Standars Organization). En España AENOR. METRICA-2,
    desarrollada por el Consejo Superior de Informática del
    MAP. Se basa en la metodología de análisis y
    diseño de Yourdon/DeMarco.

    Monografias.com
    MODELADO DE SISTEMAS El análisis y la definición de
    los requisitos debe dar lugar a la especificación
    software, en la que se concretan las necesidades que se desean
    cubrir y se fijan las restricciones con las que debe trabajar el
    software. El modelado de los sistemas tiene como objetivo
    entender mejor el comportamiento requerido y facilitar la
    comprensión de los problemas planteados. Se trata de
    establecer modelos conceptuales que reflejen la
    organización de la información y las diversas
    transformaciones que se deben llevar a cabo con dicha
    información. Las metodologías de análisis de
    requisitos tratan de facilitara obtención de uno o varios
    modelos que detallen el comportamiento deseado del sistema.

    Monografias.com
    CONCEPTO DE MODELO Un modelo conceptual es una abstracción
    lógico-matemática del mundo real que facilita la
    comprensión del problema a resolver. Se trata de ofrecer
    una visión de lato nivel, sin descender a explicar
    detalles concretos del mismo. Indica QUÉ hace el sistema y
    no CÓMO lo debe hacer. Los OBJETIVOS a cubrir con los
    modelos son: Facilitar la comprensión de l problema
    Establecer un marco para la discusión que simplifique y
    sistematice el análisis Fijar las base para el
    diseño Facilitar la verificación del cumplimiento
    de los objetivos del sistema

    Monografias.com
    TÉCNICAS DE MODELADO (I) DESCOMPOSICIÓN. MODELO
    JERARQUIZADO, aplica el “divide y vencerás”, y
    así el problema queda dividido en un subconjunto de
    subproblemas. Se trata de una descomposición funcional que
    se denomina horizontal o bien se descompone tratando de detallar
    la estructura, de forma vertical. Para completar el modelado es
    necesario establecer los interfaces entre las partes del sistema
    para posibilitar el funcionamiento del sistema global.
    APROXIMACIONES SUCESIVAS, podemos tomar como partida el modelo de
    un sistema similar, y luego mediante la experiencia del analista
    y el conocimiento del problema que proporciona el experto se
    irán proponiendo modelos intermedios, discutiendo sus
    ventajas e inconvenientes. EMPLEO DE DIVERSAS ANOTACIONES, el
    lenguaje natural introduce imprecisiones, repeticiones e incluso
    incorrecciones en el modelo. Es recomendable emplear notaciones
    gráficas que sean entendibles por todos los que participan
    en el proyecto. Se suele recurrir a notaciones precisas que
    combinan texto, tablas, diagramas y gráficos.

    Monografias.com
    TÉCNICAS DE MODELADO (II) CONSIDERAR DISITNTOS PUNTOS DE
    VISTA, en la elaboración del modelo es necesario adoptar
    un determinado punto de vista. Si así la
    descripción es insuficiente conviene adoptar más de
    uno. REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en campo
    de aplicación en que se enmarca el sistema a desarrollar.
    Hay que considerar: Normativa que afecta al sistema Otros
    sistemas semejantes Estudios recientes en el campo de la
    aplicación, bibliografía, etc. Las ventajas de
    realizar un modelos más general son: Facilitar la
    comunicación entre el analista y el usuario del sistema,
    p.e. usando la misma terminología. Creación de
    elementos realmente significativos del sistema, si se ajusta a la
    normativa específica establecida. Reutilización
    posterior del software desarrollado.

    Monografias.com
    ANÁLISIS DE REQUISITOS DE SOFTWARE El análisis es
    la fase de definición del futuro sistema y tiene una
    importancia decisiva en el desarrollo de todas las etapas
    posteriores. Con el análisis de requisitos se trata de
    caracterizar el problema a resolver. El “cliente”
    trabaja con el analista para elaborar las especificaciones y
    posteriormente se encargarán de verificar el cumplimiento
    de las mismas (contrato). El análisis debe producir un
    modelo válido necesario y suficiente para recoger todas
    las necesidades y exigencias del sistema, así como las
    restricciones que los limiten. Para una especificación
    correcta se requiere: Completo y sin omisiones Conciso y sin
    trivialidades Sin ambigüedades Sin detalles de diseño
    o implementación Fácilmente entendible por el
    cliente Separando requisitos funcionales u no funcionales
    (capacidades mínimas y máximas, interfaces
    estándares, recursos necesarios, seguridad, fiabilidad,
    mantenimiento, etc. División y jerarquía del modelo
    global, con el fin de simplificar su comprensión
    Incluyendo los criterios de validación del sistema, para
    comprobar si se ajusta al contrato inicial.

    Monografias.com
    TAREAS DEL ANÁLISIS Dependiendo de las
    características y complejidad del sistema se podrán
    seguir los siguientes pasos: ESTUDIO DEL SISTEMA EN SU CONTEXTO,
    análisis del dominio en un contexto globalizador
    IDENTIFICACIÓN DE NECESIDADES, detectar necesidades de
    medios dentro de plazos y presupuestos ANÁLISIS DE
    ALTERNATIVAS Y ESTUDIO DE VIABILIDAD, tanto técnica como
    económica ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo
    que podemos usar técnicas gráficas, texto,
    herramientas CASE, etc. ELABORACIÓN DEL DOCUMENTO DE
    ESPECIFICACIÓN DE REQUISITOS, dónde se recogen las
    conclusiones del análisis y sirve de punto de partida para
    el diseñador. REVISIÓN CONTINUADA DEL
    ANÁLISIS, a menudo en las etapas de diseño e
    implementación se hace necesaria la revisión de
    alguno de los requisitos, o bien por cambios de criterio del
    cliente

    Monografias.com
    NOTACIONES PARA LA ESPECIFICACIÓN La especificación
    es una descripción del modelo del sistema a desarrollar.
    Se debe usar una notación fácil de entender por el
    cliente: Lenguaje natural, utilizando explicaciones más o
    menos precisas y exhaustivas. Es posible limitar precisiones y
    ambigüedades si se establecen reglas de uso del lenguaje.
    Diagramas de flujo de datos Diagramas de transición de
    estados Descripciones funcionales. Pseudocódigo. Se emplea
    un preciso lenguaje natural estructurado. No se debe detallar
    demasiado el cómo, pues esto corresponde a la fase de
    diseño, donde se usan lenguajes estructurados como PLD.
    Descripción de datos, de trata de detallar la estructura
    interna de los datos que maneja el sistema. En la
    metodología Yourdon se conoce como diccionario de datos,
    incluyendo nombre de cada dato, utilización y estructura.
    Diagramas de modelos de datos

    Monografias.com
    DIAGRAMAS DE FLUJO DE DATOS (DFD) Se trata de realizar un modelo
    gráfico para representar el flujo de datos que entra en el
    sistema, las transformaciones que debe realizar y la salida
    producida. También se representan las entidades externas
    la sistema que producen o consumen datos. El DFD inicial es el de
    contexto, posteriormente y de forma jerárquica se van
    desarrollando otros DFD’s que detallan las
    transformaciones, las entradas y salidas del diagrama detallado
    deben coincidir con el proceso correspondiente. Recoge de forma
    estática los procesos, dónde en el último
    nivel de refinamiento se especifican en lenguaje natural
    estructurado, y su interrelación.

    Monografias.com
    DIAGRAMAS DE TRANSICIÓN DE ESTADOS Describe el
    comportamiento dinámico del sistema basándose en
    sus estados más importantes. Al igual que en los
    autómatas de estados finitos, los eventos motiva el cambio
    de estado del sistema.

    Monografias.com
    DIAGRAMAS DE MODELO DE DATOS Se trata de organizar e
    interrelacionar los datos que utiliza el sistema. El MODELO
    ENTIDAD-RELACIÓN permite definir todos los datos y
    establecer las relaciones que deben existir entre ellos.

    Monografias.com
    DOC. DE ESPECIFICACIÓN DE REQUISITOS El documento o la
    especificación de requisitos (SRD o SRS) recoge de forma
    integral los resultados del análisis. Puede haber
    documentos previos al SRD, como estudios de viabilidad o de
    alternativas posibles. El SRD debe ser revisado con cierta
    frecuencia durante el desarrollo y debe facilitar la
    varificación de las especificaciones (contrato). Diversos
    organismos de estandarización hacen propuestas sobre la
    estructura del SRD: IEEE, DoD, etc. Vemos el modelo de SRD de la
    Agencia Espacial Europea. Dependiendo de las
    características y complejidad del proceso tal vez no sea
    necesario cubrir todos los apartados.

    Monografias.com
    MODELO DE SRD Introducción Objetivo: objetivos,
    participantes, calendario,… Ámbito, identificará
    y dará nombre al producto Definiciones, siglas y
    abreviaturas Referencias, la descripción
    bibliográfica de los documentos referenciados.
    Panorámica del documento Descripción general
    Relación con otros proyectos, similares o complementarios
    Relación con proyectos anteriores o posteriores Objetivo y
    funciones Consideraciones de entorno Relaciones con otros
    sistemas, que utilicen entradas o salidas indirectas de
    información Restricciones generales: metodologías,
    lenguajes, de hardware,… Descripción del modelo, es el
    apartado más extenso y más importante. Se utilizan
    todas las notaciones y herramientas disponibles

    Monografias.com
    ESTA PRESENTACIÓN CONTIENE MAS DIAPOSITIVAS DISPONIBLES EN
    LA VERSIÓN DE DESCARGA

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter