4.1. Modelado: análisis, diseño, documentación.

4.2. Construcción: codificación, pruebas y evaluación, manual del usuario, manual técnico.

4.3. Medida, métrica e indicador.

4.4. Tipos de métricas: métricas de proceso, métricas de proyecto, métricas orientadas a punto de función, métricas

orientadas al tamaño, métricas para la calidad del software.

4.5. Implementación y mantenimiento: entrega, retroalimentación del cliente.

Análisis del proyecto de software

4.1. Modelado: análisis, diseño,

documentación.

Análisis

Análisis:

• Para el desarrollo de un proyecto de software concluya con éxito, es de importancia que antes de empezar a codificar los programas que constituirán la aplicación de software compleja, se tenga una completa y plena comprensión de los requisitos del software.

Análisis (cont.)

Pressman establece que la tarea de

análisis de requisitos es un proceso de descubrimiento,

refinamiento, modelado y

especificación.

Se refina en detalle el ámbito del

software, y se crean modelos de los

requisitos de datos, flujo de información

y control, y del comportamiento

operativo.

Se analizan soluciones

alternativas y se asignan a diferentes

elementos del software.

El análisis de requisitos permite al

desarrollador o desarrolladores

especificar la función y el rendimiento del software, indica la

interfaz del software con otros elementos

del sistema y establece las

restricciones que debe cumplir el

software.

El análisis de requisitos del software puede dividirse en cinco áreas de

esfuerzo que son:

Reconocimiento del problema:

Reconocer los elementos básicos del problema tal y como los perciben los

usuarios finales.

Evaluación y síntesis:

Definir todos los objetos de datos observable externamente, evaluar el flujo y

contenido de la información, definir y elaborar todas las funciones del software,

entender el comportamiento del software en el contexto de acontecimientos que afectan

al sistema.

Modelado:

Crear modelos del sistema con el fin de entender mejor el flujo

de datos y control, el tratamiento funcional y el comportamiento operativo y el contenido de la

información.

Especificación:Realizar la especificación formal del

software.

Revisión:Un ultimo chequeo general de

todo el proceso

Requerimientos funcionales

Definen los alcances del sistema en cuanto a las acciones que deben de realizar y en cuanto

a la transferencia de datos entre todas las diferentes del sistema.

Los requerimientos funcionales son los que se encargan de definir lo que la herramienta de

software debe hacer.

Requerimientos no funcionales

Los requerimientos no funcionales son aquellos que definen lo que la herramienta

de software debe tener en cuanto a apariencia, sensación, operabilidad y

mantenimiento.

De acuerdo con Galvis, el objetivo de la etapa de análisis cuando se sigue una metodología de

Ingeniería de Software Educativo es determinar el contexto en el cual se va a crear la aplicación para

poder derivar los requerimientos que deberá atender la solución interactiva como complemento

a otras soluciones basadas en uso de otros medios, teniendo en claro el rol de cada uno de los medios educativos seleccionados y la viabilidad de

usuarios.

Según Galvis se debe tener en

cuenta

Características de la población objetivo:

• Se refiere a cuestiones como la edad, características físicas y mentales, experiencias previas, expectativas, actitudes, aptitudes o intereses.

Conducta de entrada y campo vital:

• Es necesario ubicar la herramienta de software dentro de las áreas bajo las cuales se desenvuelve el paciente.

Problema o necesidad de atender:

• Es necesario ubicarse dentro del contexto del problema que pretende atacarse.

Justificación de los medios interactivos a utilizar:

• El apoyo informático debe ser tomado en cuenta siempre y cuando no exista un mecanismo mejor para resolver el problema

1.- Diseño:

El diseño es el primer paso en la fase de desarrollo de

cualquier producto o sistema de ingeniería.

De acuerdo con Pressman, el objetivo del diseño es producir un modelo o representación de una entidad que se va a construir posteriormente.

Según MacGlaughilin 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

requerimientos explícitos obtenidos

en la etapa de análisis.

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

puedan y mantienen el software.

El sueño debe proporcionar una idea completa de lo que es

el software.

Tipos de diseño:

Diseño del

software

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

en los modelos conceptuales

desarrollados durante el análisis del

sistema.

Implica diseñar la decisión sobre la distribución de

datos y procesos.

El diseño es la primera de las tres

actividades técnicas que implica un

proceso de ingeniería de software; estas etapas son diseño,

codificación y pruebas.

Generalmente la fase de diseño

produce un diseño de datos, un

diseño arquitectónico, un diseño de interfaz,

y un diseño procedimental.

Diseño de datos:

• Se encarga de transformar el modelo de dominio de la información creado durante el análisis.

Diseño arquitectónico:

• Se define las relaciones entre los principales elementos estructurales del programa.

Diseño de interfaz:

• Describe como se comunica el software consigo mismo, con los sistemas que operan con el, y con los operadores que lo emplean.

2.-Arquitectura del software

El diseño de la arquitectura del software se refiere a la

estructura global del software y las maneras en

que esa estructura proporciona integridad

conceptual a un sistema. (Shaw)

La arquitectura es la estructura jerárquica de los módulos del programa, la manera de interactuar de estos componentes, y las

estructura de los datos usados por estos

módulos.(Pressman)

Propiedades Estructurales

Este es el aspecto de la representación de

software que define los componentes de un

sistema, y la manera en que se empaquetan

estos componentes e interactúan unos con los

otros.

Propiedades Extra-funcionales

Esta especificación se refiere al como consigue

la arquitectura del diseño los requisitos de

rendimiento, capacidad, fiabilidad, seguridad,

adaptabilidad, y otras características de las

herramienta de software.

Familias de sistemas relacionados

Se refiere a que el diseño debería tener la

capacidad de utilizar bloques de construcción

arquitectónica reutilizados.

3.- Diseño de la interfaz

Durante este proceso (Rubbin) se crean los siguientes modelos

Un modelo del diseño del sistema, que incorpora representaciones de datos,

arquitectónicos, de interfaces y procedimiento del software.

Un modelo de usuario que muestra el perfil de los usuarios finales del sistema.

Es un proceso que empieza con la creación de diferentes modelos de función del sistema.

Documentación

La documentación se presenta en base a los métodos orientados a objetos propuestos por Martin y Odell.

• Diagramas de eventos

• Diagramas de contexto

• Tarjetas CRC

Se utilizan las siguientes técnicas para documentar los componentes mas relevantes de la herramienta de software:

Explicación:

Diagramas de eventos:

• Para ilustrar la manera en que un usuario del software interactúa con los entornos virtuales.

Diagramas de contexto:

• Para ubicar el campo de acción que abarcara el software.

Tarjetas CRC:

• Utilizada para representar todas las clases dentro de un diseño.

4.2. Construcción: codificación,

pruebas y evaluación, manual del

usuario, manual técnico.

Codificación:

Cuando el resultado de las pruebas no sea satisfactorio será necesario modificar el código, lo que podrá introducir nuevos errores. Si la programación es estructurada será más fácil localizar la disfunción y la posterior modificación y las pruebas del código, dónde

podemos introducir puntos de test.

Previamente a la codificación es necesario elegir el lenguaje que se empleará así como la metodología de programación. También se pueden establecer en el equipo unas normas y un estilo de programación común, lo que mejorará la coordinación y facilitará el

trabajo. Además se consigue facilitar el mantenimiento y mejorar la reusabilidad del software.

La fase de codificación constituye el núcleo central en cualquiera de los modelos y tiene una importancia fundamental ya que elabora los programas fuente.

Cuando alguna de las pruebas no resulta positiva es necesario repetir la codificación o la integración y probar de nuevo.

Nos vamos a referir a las últimas fases del ciclo de vida: codificación, pruebas de unidades, integración y pruebas de sistema.

Pruebas y evaluación:

Consiste en comprobar que el software realice

correctamente las tareas indicadas en la especificación del

problema.

Una técnica de prueba es probar por

separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo.

Se considera una buena práctica el que las pruebas

sean efectuadas por alguien distinto al

desarrollador que la programó,

idealmente un área de pruebas; sin perjuicio de lo

anterior el programador debe hacer sus propias

pruebas.

En general hay dos grandes formas de

organizar un área de pruebas, la primera

es que esté compuesta por

personal inexperto y que desconozca el

tema de pruebas, de esta forma se evalúa que la documentación

entregada sea de calidad, que los

procesos descritos son tan claros que cualquiera puede entenderlos y el

software hace las cosas tal y como están descritas.

El segundo enfoque es tener un área de pruebas conformada por programadores

con experiencia, personas que saben

sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles

que personal inexperto no consideraría.

Manual de usuario:

Un manual de usuario se trata de una guía que ayuda a entender el

funcionamiento de algo.

Es un documento de comunicación técnica que busca brindar asistencia a los sujetos que usan un

sistema o servicio.

Elaboración de un manual de

usuario:

Pasos del manual del usuario:

• Portada: De que se trata el documento y ¿quién lo elaboro?

• Introducción: Describe el uso del documento (¿para qué sirve?) y ¿de qué habla?

• Análisis y requerimientos del sistema (¿que se ocupa para poder instalarlo y usarlo?)

• Explicación del funcionamiento: Debes de poner paso a paso y con pantallas bien explicadas cómo funciona el programa

• Glosario

Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor dificultad posible.

Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el programa.

Especificar los alcances y las limitaciones que tiene el programa.

Un buen punto de partida para un manual de usuario, es hacer de cuenta que las personas que lo van a leer no tienen el más mínimo conocimiento sobre computadores.

Manual técnico:

Su extensión depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas técnicas en donde se

describe en cada una las características de cada recurso.

Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada

sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del

equipo, garantías, soporte, proveedores y equipo adicional.

Elaboración del manual técnico

En este caso el manual técnico, debe incluir:

Paradigma de programación

seleccionado y sus beneficios.

Lenguaje de programación

seleccionado y sus beneficios frente a otros

lenguajes.

Estandarización de código utilizada.

Diseño del sistema.

Un manual técnico es aquel que va dirigido a un público con conocimientos técnicos sobre algún área, mientras que, por ejemplo, un manual de usuario va dirigido a un público

más general, el cual no necesariamente debe tener conocimientos específicos en el área de interés.

4.3. Medida, métrica e indicador.

Medida:

La medición es el acto de determinar una medida

Una medida proporciona una indicación cuantitativa de la

extensión, cantidad, dimensiones, capacidad o tamaño de algunos

atributos de un proceso o producto.

Métrica

Una métrica es una medida cuantitativa del grado

en que un sistema, componente o proceso posee

un atributo dado

Indicador

Un indicador es una métrica o combinación de

métricas que proporcionan una visión profunda

del proceso del software, del proyecto de

software o del producto en si.

Que permiten los indicadores?Los indicadores del proyecto

permiten al gestor:

• Evaluar el estado del proyecto en curso.

• Seguir la pista de riesgos potenciales.

• Detectar áreas problemáticas antes de que se conviertan en críticas.

• Ajustar el flujo y las tareas de trabajo.

• Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la IS.

Los indicadores del proceso permiten:

• Al gestor, evaluar lo que funciona y lo que no.

• A la organización, tener una visión profunda de la eficacia de un proceso ya existente.

4.4. Tipos de métricas: métricas de proceso,

métricas de proyecto, métricas orientadas a

punto de función, métricas orientadas al

tamaño, métricas para la calidad del software.

Tipos de métrica:

DEL PROCESO

Tiempo de desarrollo

Reusabilidad Productividad

DEL PRODUCTO

TamañoEstructura de

datosLógica

métricas orientadas a punto de

función:

La medida de punto de función se propuso en

1979 y trata de medir la funcionalidad o utilidad

del software.

Cálculo del punto de función

Hay que completar la siguiente tabla de valores

del dominio de la información:

Cálculo del punto de función (cont.)

Entradas de usuario. Son entradas que proporcionan

diferentes datos a la aplicación. No confundirlos

con las peticiones de

usuario.

Salidas de usuario. Son

reportes, pantallas o

mensajes de error que

proporcionan información. Los elementos de un

reporte, no se cuentan de

forma separada.

Peticiones de usuario. Es una

entrada interactiva que

produce la generación de

alguna respuesta del software en

forma de salida interactiva.

Archivos. Son los archivos que

pueden ser parte de una

base de datos o independientes.

Interfaces externas. Son

los archivos que se usan para

transmitir información a otro sistema.

Donde:

Cálculo del punto de función (cont.) Indicaciones: Contar cada medida por separado. Asociar, de alguna manera, un valor de complejidad a

cada medida. La siguiente tabla muestra una heurística para decidir la complejidad de todo el sistema.

Para cada medida, multiplicar su cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha.

Sumar la columna de la extrema derecha y obtener un total T que indica el valor del dominio de la información.

Responder a cada una de las siguientes catorce preguntas y

asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es

incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es

esencial.

¿Requiere el sistema copias de seguridad y de recuperación fiables?

¿Requiere comunicación de datos?

¿Existen funciones de procesamiento distribuido?

¿Es crítico el rendimiento?

¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?

¿Requiere entrada de datos interactiva?

¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?

¿Se actualizan los archivos maestros de forma interactiva?

¿Son complejas las entradas, las salidas, los archivos o las peticiones?

¿Es complejo el procesamiento interno?

¿Se ha diseñado el código para ser reutilizable?

¿Están incluidas en el diseño la conversión y la instalación?

¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

Sumar los puntos asignados a cada

respuesta y obtener un total F que indica un valor de ajuste de

complejidad.

El punto de función FP se calcula con

la siguiente ecuación:

PF = T * (0.65 + 0.01 * F).

Métricas ampliadas de punto de

función.

Los puntos de función fueron diseñados originalmente para sistemas de información y por eso le da más importancia a los datos y menos a los aspectos de control y funcionales.

Para subsanar esto, se han propuesto los puntos de característica y los puntos de función 3D.

Métricas ampliadas de punto de

función. (cont.)

Puntos de característica.

• Se calcula igual que el punto de función y solo agrega la cuenta de algoritmos.

• En este contexto se define un algoritmo como un problema de cálculo limitado que se incluye dentro de un programa de computadora específico.

• Invertir una matriz, decodificar un string o manejar una interrupción son ejemplos de algoritmos.

Puntos de función 3D.

• Los puntos de función 3D se calculan llenando la siguiente tabla:

Métricas ampliadas de punto de

función. (cont.)

Métricas ampliadas de punto de función. (cont.).

donde:

Transiciones. Ocurre cuando el software pasa de un estado a otro como resultado de algún suceso. En un sistema de altas, bajas y cambios, al tomar la opción de altas, pasa del estado "menú principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.

Transformaciones. Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformación. Leer datos de un archivo y guardarlos en memoria no.

Peticiones de usuario. Definidas igual que para el punto de función.

Salidas de usuario. Definidas igual que para el punto de función.

Entradas de usuario. Definidas igual que para el punto de función.

Datos externos. Equivale a la suma de los archivos y las interfaces externas tal y como están definidos para el punto de función.

Estructuras internas de datos. Son arreglos, listas ligadas, pilas, colas, etc.

Métricas ampliadas de punto de

función. (cont.)

Para cada medida, contar por separado, de acuerdo a algún

criterio de asignación de complejidad, las veces que aparezca

con complejidad baja, media y alta.

Para cada medida, multiplicar cada

cuenta por el factor de complejidad

correspondiente, sumar las tres

cantidades y escribir el total en la columna

de la extrema derecha.

Sumar la columna de la extrema derecha y obtener el punto de

función 3D.

Indicaciones:

Funcionalidad de los lenguajes de

programación

La tabla siguiente proporcional estimaciones

informales del número de líneas de código que

se necesitan para construir un punto de función

en varios lenguajes de programación:

Funcionalidad de los lenguajes de

programación (cont.)

Observando la tabla podemos decir que, en

promedio, un programa en ensamblador tendrá

320/128 = 2.5 veces más líneas de código que un

programa en C que haga lo mismo, y casi 11

veces más que un lenguaje orientado a objetos

(OOL) con la misma funcionalidad.

métricas orientadas al tamaño:

Los programas se escriben en lenguajes muy distintos y con propósitos muy diferentes, usando técnicas y métodos dispares, pero con una característica común: tienen un tamaño.

Este tamaño se determina habitualmente tomando como referencia el programa en código fuente

El tamaño es una medida empleada fundamentalmente por tres razones: es fácil de obtener una vez que el programa ha sido completado, es uno de los factores más importantes en los métodos de desarrollo, y la productividad se expresa tradicionalmente con el tamaño del código.

La medida de tamaño más usada es la cantidad de líneas de código que se representa como Ss, y se mide en LOC (Lines Of Code, líneas de código).

Para programas grandes es más adecuado el uso de KLOC (miles de líneas de código) representadas como S.

métricas para la calidad del software:

El estudio de la calidad y fiabilidad tiene una importancia cada vez

mayor en el mundo de la Ingeniería del Software. No sólo se trata de obtener sistemas desarrollados correctamente, de acuerdo a los

requerimientos y a los estándares establecidos, sino que se pretenda

conseguir programas fáciles de mantener y, lo que es más

importante, sistemas fiables en tareas críticas.

Los errores de codificación, con ser los más conocidos, no son los más importantes, son los más tratados

pues es más simple automatizar su detección. Los errores en las

pruebas son muy importantes pues dan por válido un código que no lo es, y permiten que se entregue un sistema defectuoso. Los errores de mantenimiento pueden deberse a la ignorancia de fallos antiguos o a la

introducción de otros nuevos.

4.5. Implementación y

mantenimiento: entrega,

retroalimentación del cliente.

Implementación

Es la ultima fase del desarrollo de Sistemas. Es

el proceso instalar equipos o Software nuevo, como

resultado de un análisis y diseño previo como

resultado de la sustitución o mejoramiento de la forma de

llevar a cavo un proceso automatizado.

Al Implantar un Sistema de Información lo primero que

debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los

requerimientos del análisis y permitir que los usuarios

puedan operarlo.

Implementación (cont.)

Existen varios enfoques de Implementación:

Es darle respons

abilidad a los grupos.

Uso de diferentes estrategias

para el entrenamie

nto de los usuarios.

El Analista de Sistemas necesita

ponderar la situación y

proponer un plan de

conversión que sea

adecuado para la

organización.

El Analista necesita formular medidas

de desempeño con las

cuales evaluar a los

Usuarios.

Debe Convertir

físicamente el sistema

de información antiguo, al

nuevo modificado.

Mantenimiento

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

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.