1

Funciones de un Ingeniero de Software

identificar sus necesidades.

los correctos.

que incluya fuentes de información, módulos de procesamiento de información, y resultados esperados.

Realizar el análisis de los requisitos.

ramas de la arquitectura.

Determinar las necesidades esenciales y no esenciales, así como las que son de segundo nivel. Impedir la introducción de defectos tempranamente en la construcción del sistema. Construir el documento de requisitos de usuarios. Establecer una estructura básica inicial del sistema. Establecer interacciones, interrelaciones y sus contextos en dicha estructura. Definir la especificación de la arquitectura del sistema, en forma de un documento técnico

Análisis de Requerimientos.

1.-La obtención de requisitos consiste en capturar el propósito y funcionalidades del sistema

desde la perspectiva del usuario. Las técnicas para esta tarea son: Entrevistas, Escenarios,

Prototipos, Reuniones de Grupo, Observación.

Las fases de una entrevista son: planificación, preparación, inicio, desarrollo, cierre y conclusiones.

Los casos de uso no son únicamente exclusivos al modelado de requisitos, ya que inicialmente fue

ideado para la captura de requisitos funcionales de un sistema, hoy en día se aplica en otros

ámbitos de la ingeniería de software.

2.-El análisis de requisitos es el proceso de estudiar las necesidades del usuario para obtener una

definición detallada de los requisitos.

El modelo conceptual que tiene como objetivo fundamental facilitar la comprensión de los

requisitos, mediante su presentación en un lenguaje o notación que comprendan quienes van a

trabajar con los requisitos.

Notaciones del modelado conceptual.

a) La notación de Casos de Uso de UML, es la más utilizada para el modelado y captura de

requisitos funcionales. Consta de Actor, Caso de Uso, Escenarios, Relaciones y una

Representación detallada.

b) Modelos entidad-relación.

c) Diagramas de clases UML.

d) Notaciones formales.

2

3.-Se denomina especificación de requisitos al proceso de documentar el comportamiento

requerido de un sistema de software. A menudo utiliza una notación de modelado u otro lenguaje

de especificación.

4.-La validación de requisitos consiste en examinar los requisitos para asegurarse de que definen

el sistema que el cliente y los usuarios desean.

Para la validación de requisitos se tienen varios métodos, los cuales son:

a.- Revisión de requisitos.- Un grupo de personas revisa los documentos de requisitos en

busca de inconsistencias, malentendidos, puntos poco claros o conflictos entre requisitos.

Como resultado se elabora y publica una lista de problemas y posibles soluciones.

b.- Prototipado.- El desarrollo de un prototipado constituye una inmejorable forma de

probar cualquier producto. Un prototipo es un modelo fácilmente ampliable y modificable

de un sistema de software, donde se muestran su interfaz y las funcionalidades de

entrada-salida más relevantes.

c.- Validación de modelado.- Sirve para verificar si el modelo es consistente y se refleja

adecuadamente los requisitos reales del sistema.

d.- Pruebas de aceptación.- Consiste en la elaboración de un plan, que establece cómo

deben ser verificados los diferentes requisitos.

Se puede crear una matriz de seguimiento, la cual es una tabla de donde se relacionan dos

documentos, probablemente de dos etapas distintas de desarrollo. Lo anterior es para seguir la

pista de los requisitos a lo largo del desarrollo, fundamentalmente en el diseño, plan de pruebas y

casos de prueba, en cuyo caso recibe el nombre de Matriz de Seguimiento de Requisitos.

5.- Otros elementos del análisis de Requerimientos.

Se denomina actor a un rol perfectamente definido que una persona puede desempeñar en el

Proceso de requisitos.

a. Usuarios.- Se trata de un grupo heterogéneo que comprende a todos aquellos que operan

el software.

b. Clientes.-Todos aquellos que tienen interés en adquirir el software o representan de algún

modo al mercado potencial al que se dirige el software.

c. Analistas de mercado.- Personas especializadas en recabar las posibles necesidades del

mercado obteniendo requisitos a través de los posibles clientes potenciales.

El documento de especificación de requisitos de software contiene un conjunto exhaustivo y

preciso de requisitos, modelados de un lenguaje de especificaciones y validados, los cuales

sirven como contrato entre lo que desea el cliente y lo que los desarrolladores se

comprometen a construir.

3

Existen dos tipos de requisitos Funcionales y No funcionales.

Un requisito funcional define una función que un sistema o componente de sistemas debe ser

capaz de llevar acabo. Ejemplos:

Imprimir contratos de alquiler, almacenar la información relativa a los contratos de alquiler,

guardar información de pagos y ventas, realizar el seguimiento por cliente del estado de

pagos, etc.

Un requisito No funcional son aquellos que especifican aspectos técnicos que debe incluir el

sistema y que pueden clasificarse en restricciones y calidades. Ejemplos:

El sistema debe estar disponible el 95% de tiempo en un periodo de 24 horas, el desarrollo

debe regirse por procesos y actividades definidos por la metodología de la Administración

Pública Española, el registro de datos debe cumplir con la Ley Orgánica Española.

Modelos de Procesos

Los modelos prescriptivos del proceso de software se han aplicado durante muchos años en un

esfuerzo encaminado a ordenar y estructurar el desarrollo de software.

A) El modelo en cascada sugiere una progresión lineal del marco de trabajo que a menudo

resulta inconsistente con la realidad moderna en el mundo del software (por ejemplo, el

cambio continuo, los sistemas de evolución, las fechas de entrega restringidas). Entonces

el modelo se puede aplicar en las situaciones en las cuales los requisitos están bien

definidos y son estables.

B) Desarrollo rápido de aplicaciones está diseñado para proyectos grandes que se entregan

en marcos de tiempo reducido.

C) Los modelos incrementales producen software como una serie de entregas.

D) Los modelos evolutivos reconocen la naturaleza evolutiva de la mayoría de los proyectos

de Ingeniería de software y están diseñados para ajustarse al cambio

E) El modelo de prototipos y el de espiral generan productos de trabajo incrementales con

rapidez. Y se adaptan para aplicarlos desde el desarrollo hasta el mantenimiento del

sistema.

F) Modelo basado en componentes destaca la reutilización y ensambladura de los

componentes

Según Bennatan, hay cuatro tipos de componentes:

1. Componentes ya Desarrollados.- Se adquiere de un tercero o de desarrollo

internamente para un proyecto previo y que han sido ampliamente validados.

4

2. Componentes Experimentados.- Especificaciones, diseño, código o datos de

prueba existentes que se desarrollan para proyectos previos o similares. Los

miembros del equipo tienen experiencia en dicho componente

3. Componentes con Experiencia Parcial.- Especificaciones, diseño, código o

datos de prueba existentes que se desarrollan para proyectos previos que

requieren modificaciones sustanciales y que cuentan con experiencia limitada.

4. Componentes nuevos.- El equipo de software debe crear o construir nuevos

componentes de software.

El proceso unificado de un proceso de software guiado por los casos de uso, de arquitectura

céntrica, iterativo e incremental. El proceso unificado se define con 5 fases:

1- Una fase de inicio.

Comunicación con el cliente, actividades de planeación, desarrollo y refinamiento de casos

de uso.

2- Una fase de elaboración. Comunicación con el cliente, actividades de modelado con un

enfoque de la creación de modelos de análisis y diseño.

3- Una fase de Construcción. Refina y traduce el modelo de diseño de componentes de

software implementados.

4- Una fase de transición. Transfiere el software del desarrollador al usuario final para

realizar las pruebas beta y obtener la aceptación.

5- Una fase de Producción en la cual se realiza el monitoreo continuo y el soporte

Diseño

Antes de que el diseño y la construcción de un sistema basado en computadora quedan comenzar,

es necesario entender los requisitos.

Los miembros del equipo de software realizan 7 funciones distintas dentro de la ingeniería de

requisitos: Inicio, Obtención, Elaboración, Negociación, Especificación, Validación y Gestión.

La elaboración posterior expande los requisitos hacia un modelo de análisis, es decir, una

colección de elementos del modelo basado en escenarios, en actividades y clases, de

comportamiento y orientados al flujo.

Objetivo:

Las herramientas para el modelado del análisis proporcionan la capacidad de desarrollar modelos

basados en escenarios, modelos basados en clases y modelos de comportamiento mediante la

notación UML.

El objetivo del modelado de análisis es crear una variedad de representaciones que muestren los

requisitos del software para la información, función y el comportamiento, esto se logra

implementando dos filosofías de modelado, el Análisis estructurado y el Análisis orientado a

objetivos.

5

El análisis estructurado considera al software como un transformador de información, que ayuda

al ingeniero de software a identificar los objetivos de datos, sus relaciones y la manera en la cual

estos objetivos de datos se transforman mientras fluyen a través de las funciones de

procesamiento del software.

El Análisis orientado a objetivos examina un dominio de problema definido como un conjunto de

casos de uso en un esfuerzo para extraer clases que definen el problema. Cada clase tiene un

conjunto de atributos y operaciones.

El modelo de análisis lo componen 4 elementos: Modelos Basados en Escenarios, de Flujo,

Basados en Clases y Basados en Comportamiento

M. B. Escenarios M. B. en Flujo M. B. en Clases M. B. en Comportamiento

Muestran los requisitos del software desde el punto de vista usuario

Se enfoca en el flujo de objetivos de datos conforme a las funciones de procesamiento que los transforman. Los modelos de flujo se derivan del análisis estructurado

Utiliza información derivada de elementos de modelo orientado al flujo y basado en escenarios para extraer clases candidatas, atributos y operaciones de las narrativas basadas en texto.

Utiliza la entrada de los elementos basados en escenarios y basados en clases para representar los estados de las clases de análisis y del sistema como un todo. Esto se logra identificando los estados, definiendo los eventos que ocasionan que una clase tenga una transición

El caso de uso - Una descripción narrativa basada en una plantilla de una interacción entre un actor y el software. El caso de uso derivado durante la obtención de requisitos define los casos clave para la función o interacción especifica; pero el resultado final proporciona la entrada necesaria a las otras actividades del modelado de análisis.

Diagrama de Flujo de Datos. Muestra la manera en que una entrada se transforma en una salida conforma a los objetivos de datos se mueven a través del sistema. Los nodos representan procesos, los vértices las entradas y salidas a los mismos. Los diagramas de Flujo de Datos pueden descomponerse en sub-diagramas hasta llegar al nivel de granularidad. Los sustantivos son entidades externas (cajas), objetos de datos o de control (flechas) o almacenamiento de datos

Los paquetes de análisis - se utilizan para categorizar y agrupar clases de manera que sean manejables para los sistemas grandes.

Diagramas de Secuencia – Indica cómo los eventos causan transiciones de un objeto a otro, se puede decir que es una versión corta de los casos de uso

6

(líneas dobles).

Diagrama de Actividad es una representación gráfica del tipo de un diagrama de flujo que muestra el flujo del procesamiento dentro de un escenario especifico.

Este elemento de modelado también muestra el flujo de control (representación que ilustra la forma en que los eventos afectan el comportamiento del sistema).

Diagramas de Clase- Es un conjunto de clases y la relaciones entre ellas, las cuales permiten modelar cualquier entidad mediante la enumeración de sus características que pueden ser estáticos (atributo) o dinámicos (métodos).

Diagramas de Estado- Representa los estados activos para cada clase y los eventos (disparadores) que ocasionan cambios entre estados activos

Diagramas de Carril - ilustra la forma en que el flujo de procesamiento incumbe a varios actores o clases.

Modelos CRC- (Clase Responsabilidad Colaborador ) Puede usarse en la definición de relaciones entre las clases. Además aplica una variedad de notaciones del modelado UML, para definir jerarquías, relaciones, asociaciones, agregaciones y dependencias entre clases.

El flujo de información durante el diseño de software depende de la transformación del modelo de

análisis en un modelo de diseño. La tarea de diseño produce un diseño de Datos-clase, un Diseño

arquitectónico, un diseño de Interfaz y un diseño de Componentes

7

Elementos del diseño de datos.-

Al igual que otras actividades de la ingeniería de software, el diseño de datos crea un modelo de

datos algunas veces llamado también como Arquitectura de Datos.

8

Al nivel de abstracción, la traducción de un modelo de datos a una base de datos es esencial para

alcanzar los objetivos de negocio del sistema.

Tenemos tipos de métodos para el diseño.

Métodos estructurado.- Se basan en la aproximación descendente (top-down) que aboga por

descomponer el sistema completo en niveles funcionales desde la perspectiva global completa

hasta el nivel de detalle necesario para su implementación. Las características más importantes

de este modelado son la descomposición funcional, el modelado de datos y la representación del

flujo de información. Entre las técnicas más comunes se tiene.

A) Diagramas de flujo de datos.

B) Diagramas entinad-relación.

C) Diccionario de datos.

D) Diagramas de estructura.

Métodos orientados a objetos.

En UML los diagramas están clasificados en dos grupos:

a) Diagramas de estructura.- Reflejan la estructura física del sistema por medio de sus clases,

métodos, atributos, interfaces, paquetes, etc. Y sus relaciones.

b) Diagramas de comportamiento.- Muestran la forma en los distintos elementos del sistema

interaccionan, colaboran y cambian de estado durante la ejecución del sistema para

proveer la funcionalidad requerida.

Los diagramas de UML son:

1. Diagramas de casos de uso

2. Diagrama de clases

3. Diagrama de componentes

4. Diagrama de iteración

a. Diagramas de secuencia

b. Diagrama de comunicación

5. Diagrama de estado

6. Diagramas de despliegue

7. Diagramas de actividad

8. Diagramas de paquete.

Pruebas

El objetivo principal del diseño de casos de prueba consiste en derivar un conjunto de pruebas

que tenga la mayor probabilidad de descubrir errores en el software.

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados

que han sido desarrollados para un objetivo particular.

9

Un fallo es un efecto indeseado en las funciones o prestaciones desempeñadas por un software.

Se domina error o defecto a una imperfección en el software que provoca un funcionamiento

incorrecto del mismo.

Se puede emplear dos categorías: Las pruebas de caja blanca y las pruebas de caja negra.

a) Las pruebas de caja blanca se concentran en la estructura del control del programa, los

casos de prueba se derivan para asegurar que todas las instrucciones del programa se

ejecuten por lo menos una vez durante la prueba y que todas las condiciones lógicas se

ejerciten.

b) Las pruebas de caja negra. Los casos de prueba se basan en el comportamiento de la

entrada y la salida de datos

Las pruebas del sistema se enlistan a continuación:

1) Pruebas de funcionalidad y operativa.- Se trata de pruebas de la caja negra.

2) Pruebas de rendimiento.

3) Pruebas de aceptación

4) Pruebas de instalación.- Las pruebas de aceptación comparan el comportamiento de un

módulo o sistema de software completo con las necesidades del cliente.

5) Pruebas alfa y beta.

6) Pruebas de conformidad.

7) Pruebas de regresión

8) Pruebas de desgaste.

9) Pruebas de recuperación.

10) Pruebas de configuración.

11) Pruebas de usabilidad.- Evalúan la facilidad con la que los usuarios utilizan el software,

evalúa también la claridad de la documentación para el usuario.

Métricas

Tenemos tres tipos de entidades para medir la Ingeniería de Software.

Productos.- Es cualquier entregable o documento que resulta de cualquiera de las actividades

(procesos) del ciclo de vida del software. El código fuente, las especificaciones de requisitos , los

diseños, el plan de pruebas y los manuales de usuario son algunos productos.

Producto Atributos Internos Atributos Externos

Especificaciones Tamaño, reutilización Calidad, legibilidad

Diseño Tamaño, acoplamiento, cohesión, complejidad

Calidad, complejidad

10

Código Tamaño, complejidad Facilidad de mantenimiento, fiabilidad

Casos de prueba Numero de casos, % de cobertura. Calidad

Medidas por producto

I Atributos internos

Medidas del tamaño del sistema

a. La cuenta de líneas de código.

Los puntos de función miden el tamaño del software por la cantidad de funcionalidad

que proporcionan a los usuarios (sin considerar al código fuente). Se basan en la cuenta

de entradas, salidas, accesos y modificaciones a las bases de datos y ficheros que se

ponderada por la complejidad de cada uno de ellos. Un ejemplo de métrica indirecta en

el tamaño del software es la densidad de comentarios de un programa.

b. Medidas de complejidad del software

c. Medidas de documentación

d. Medidas de reutilización

e. Medidas de eficiencia

II Atributos externos

a. Modelo de McCall.

b. Modelo Bohem

c. Estándar ISO 9126 y su evolución ISO 14598.

Medidas por Proceso.- Son todas las actividades del ciclo de vida del software : requisitos ,

diseño, construcción, pruebes, mantenimiento, etc. Y su medición sirve para ver su estado para

después mejorarlos

Proceso Atributos Internos Atributos Externos

Requisitos Tiempo, esfuerzo, número de requisitos.

Calidad, coste, estabilidad.

Diseño Tiempo, esfuerzo, número de errores. Calidad, coste, estabilidad.

Diseño Tiempo, esfuerzo, número de errores. Calidad, coste, estabilidad.

Existen dos tipos de métricas:

Las Internas.- Incluyen el tiempo de desarrollo del producto, el esfuerzo y el número de

incidencias del desarrollo.

Las Externas.- Incluyen la facilidad de observación, la estabilidad del proceso o su coste.

11

Ejemplo. CMMI, SPICE, ISO 9000, SIX SIGMA Y COBIT.

Medidas por Recursos.- Cualquier entrada de una actividad. Por ejemplo, el número de personas

por actividad o por proyecto, las herramientas utilizadas (para requisitos, compiladores, etc.),

oficinas, computadoras, etc.

Recurso Atributos Internos Atributos Externos

Personal Edad, salario Productividad, experiencia.

Equipos Número de personas, estructura del equipo.

Productividad, experiencia.

Software Coste, número de licencias. Utilidad y factibilidad.

Hardware Marca, coste, especificaciones técnicas. Utilidad y factibilidad.

Existen las siguientes métricas para recursos:

Medidas de personal

Medición de las herramientas

Medición de los materiales

Medición de los métodos

Existen también metodologías y estándares de medición.

a. Método objetivo-pregunta-métrica

b. Estándar IEEE 1061-1998

c. PSM y el estándar ISO/MEC 15939

d. Estándar ISO/IEC 9126

Existen también Estudios Empíricos o evaluación Empírica de métricas de Ingeniería de Software

los cuales se basan en los siguientes instrumentos:

Entrevistas.- son estudios retrospectivos cuya intención es documentar relaciones y resultados,

siendo una de las herramientas más útiles para recabar un buen número de datos que

posteriormente serán analizados.

Casos de uso.- Son empleados para identificar y documentar factores clave que pueden afectar

los resultados de una actividad. Investigan por medio de la observación entornos reales para

contrastar o evaluar datos para descubrir tendencias.

Experimentos formales.- Se emplean para, de forma controlada y rigurosa, investigar aquellos

factores que afecten a las actividades a realizar. Medir el efecto de influencia de una variables

en otras. Un ejemplo es el estudio de que los estudiantes tienen diferentes niveles de

12

comprensión de la lógica de un programa en función de la herramienta de presentación

utilizada. Se demostró con el estudio que los estudiantes prefieren los diagramas de flujo, pues

les ayuda a comprender mejor los programas que el seudocódigo.

Los instrumentos anteriores se utilizan para estudios cualitativos y cuantitativos. Los cualitativos

buscan la interpretación de un fenómeno en su entorno natural, recabando información entre

las persona involucradas. Mientras que los cuantitativos buscan medir la influencia de una

variable en un fenómeno, es decir, la relación causa-efecto entre ambos.

Ejemplo. La relación entre la profundidad en la jerarquía de clases en un diseño orientado a

objetos y el número de errores en el código de una clase.

Benchmarking implica comparar las prácticas reales o planificadas del proyecto con aquellas de otros proyectos, a fin de generar ideas para mejorar o para establecer una norma por medio de la cual medir el desempeño de un proyecto.

Mantenimiento

Tipos de Mantenimiento

1) Mantenimiento correctivo.- Modificaciones reactivas a un producto de software hechas

después de la entrega para corregir defectos descubiertos.

2) Mantenimiento adaptatitvo.- Modificación de un producto de software realizada después

de la entrega para permitir que dicho producto siga en uso en un ambiente diferente.

3) Mantenimiento perfectivo.- Modificación de un producto de software después de la

entrega para mejorar el rendimiento o la facilidad de mantenimiento.

Las técnicas para el mantenimiento de software son:

1) Ingeniería inversa

a) I. inversa de datos.- Se aplica sobre un código de bases de datos para obtener los

modelos relacionales y para obtener el diagrama conceptual.

b) I. inversa de procesos.- Se aplica sobre el código de un programa para extraer su lógica

o obre un documento de diseño para obtener documentos de análisis o de requisitos.

2) Reingeniería.- Modificación de un producto de software o de ciertos componentes usando

para el análisis del sistema existente técnicas de ingeniería inversa y para la reconstrucción

herramientas de ingeniería directa.

3) Reestructuración

Calidad

Modelos de Calidad

1) Modelo de calidad de McCall. Tiene una serie de factores que se clasifican de la siguiente

forma:

13

A) Operación.- corrección, fiabilidad, eficiencia, integridad usabilidad.

B) Revisión.- facilidad de mantenimiento, facilidad de evaluación, flexibilidad.

C) Transición.- portabilidad, usabilidad, interoperabilidad.

2) Modelo de Boëhm

Utilidad General

Utilidad de cómo está Facilidad de mantenimiento Portabilidad

Fiabilidad, Eficiencia, Ergonomía

Facilidad de evaluación, comprensibilidad, Facilidad para modificar

3) Modelo de calidad de ISO/IEC 9126. Su objetivo es proporcionar tanto una especificación

de la calidad de productos software como un modelo para su evaluación. Se divide en

cuatro partes:

1) Modelo de calidad ISO/IEC 9126-1-2001

2) Métricas externas ISO/IEC TR 9126-2-2003

3) Métricas internas ISO/IEC TR 9126-3-2003

4) Calidad en las métricas de uso ISO/IEC TR 9126-4-2004

Otros modelos, estándares y especificaciones relacionados a la calidad en el software.

ITIL, TRILLIUM, BOOTSTRAP, PSP, TSP, TICKIT, SIX SIGMA, SPICE.

La Estimación de coste, plazos y esfuerzo

En general se puede definir ESTIMACION como el proceso de determinar una variable a partir de

otras conocidas. La Estimación de coste, plazos y esfuerzo es parte esencial de la Planificación de

cualquier tipo de proyectos.

Se tiene diferentes métodos:

A) Estimación mediante juicio de expertos.

a. Método Delphi.

b. Estimación de expertos por analogía.

B) Puntos de función

a. IFPUG

b. COSMIC

C) Modelos algorítmicos o paramétricos.

a. Regresión estadística. ISLIM, COCOMO

D) Métodos basados en Inteligencia Artificial.

a. Sistemas basados en reglas.

b. Razonamiento basado en reglas.

14

c. Redes neuronales.

d. Arboles de decisión.

E) Sistemas dinámicos.

F) Evaluación de modelos.

La Planificación y seguimientos del proyecto.

Consiste en identificarlas tareas del proyecto, las relaciones entre las tareas (el orden en que

deben ser ejecutadas), asignar los recursos a las tareas y estimar los plazos de ejecución las tareas.

Técnicas y métodos para la planificación:

A) Estructura de descomposición del trabajo.

B) Los métodos gráficos CMP (método del camino critico) y PERT (evaluación y revisión de

proyectos).

C) Diagramas de GANTT. Muestran las evolución de las tareas con sus fechas e hitos.

D) Método del Valor Conseguido (EVM) Permite hacer el seguimiento del proyecto integrando

información de plazos y costes, así como visualizar dicha información en una gráfica de tres

variables que muestran la evolución del proyecto.