Embed Size (px)
Citation preview
UNIDAD IV
DR. ANTONIO NAVARRETE PRIETO1
INSTITUTO TECNOLÓGICO DETLALNEPANTLA
DEPARTAMENTO DE SISTEMASY COMPUTACION
INGENIERIA EN TECNOLOGIAS DE INFORMACIONY COMUNICACIONES
UNIDAD IV
ANALISIS DEL PROYECTO DESOFTWARE
PROFESOR:DR. ANTONIO NAVARRETE PRIETO
Curso: 2015
2
4.1 MODELADO, ANALISIS, DISEÑO Y DOCUMENTACION
4.1.1 MODELADO
El modelado es una actividad de definición formal de aspectos del mundo físico y
social que nos rodea con el propósito de entender y comunicar, para lo cual es una
actividad de modelado que permite combinar problemas:
Empíricos: especificaciones ligadas al mundo real
Formales: abstracción, estructura y representación del conocimiento del
problema.
De ingeniería: métodos formales de construcción
Tipos de modelado. Se puede elegir entre una variedad de esquemas
conceptuales:
1) Lenguaje natural. Muy expresivo y flexible, Pobre al intentar captar la
semántica del modelo, mejor para la toma de requerimientos
2) Notación semi formal. Captura estructura y alguna semántica, puede llevar a
cabo algún razonamiento, chequeo de consistencia y animación.
3) Notación formal. Semántica muy precisa y son muy complejos.
Técnicas de modelado:
A) Modelado de empresa
Metas y objetivos
Estructura organizacional
3
Actividades, procesos y productos
Roles y trabajos de agentes
B) Modelado de requerimientos funcionales
Vistas estructurales (de datos)
Vistas de comportamiento
Requerimientos de tiempo
C) Modelado de requerimientos no funcionales.
De productos, de procesos y externos
4.1.2 ANALISIS
Definición. Proveer un marco de trabajo para modelar de forma detallada el sistema
como parte de la obtención y análisis de requerimientos (Sommerville):
Aproximación al modelo conceptual orientada en los datos
El diagrama de flujo de datos (DFD) es el elemento más
representativo
Se deben entender los requerimientos necesarios para continuar
en la evolución del sistema.
Debilidades
No provee métodos efectivos para tratar con requerimientos no
funcionales
No ayuda al usuario a decidir el mejor método para cada caso.
Produce demasiada documentación
Modelos muy detallados que son de difícil comprensión por parte de los
usuarios
4
Conceptos centrales del Análisis:
1. Transformación de datos
Actividades que transforman los datos
2. Flujo de datos
Indica el paso de datos de la entrada del mismo hacia la salida
Representa grupos de datos o elementos de datos
3. Almacenamiento de datos
Lugar donde se deja información para su uso posterior
Los almacenes de datos son pasivos, no transforman los datos
4.1.3 DISEÑO EN LA INGENIERÍA DEL SOFTWARE
El diseño del software se sitúa en el núcleo técnico del proceso de ingeniería del
software y se aplica independientemente del paradigma del desarrollo utilizado. El
diseño del software es la primera de las tres actividades técnicas: diseño,
codificación y prueba: necesarias para construir y verificar el software. Cada
actividad transforma la información de manera que se obtenga finalmente un
software valido.
La importancia del diseño del software se puede decir con una sola palabra:
calidad. El diseño nos proporciona representaciones del software en las que se
pueden valorar la calidad.
El diseño externo de software requiere de concebir, planear y especificar sus
características de un producto de programación. Estas características incluyen la
definición de despliegues de pantalla y los formatos de reportes, la definición de las
entradas y salidas de datos, así como las características funcionales, los
requerimientos de desempeño y la estructura general del producto.
5
I) CONCEPTOS FUNDAMENTALES DEL DISEÑO
A) Abstracción. Cuando consideramos una solución modular para cualquier
problema, se puede plantear muchos NIVELES DE ABSTRACCIÓN. Al NIVEL
SUPERIOR DE ABSTRACCIÓN se establece una solución en términos amplios
usando el lenguaje del entorno del problema. A NIVELES MAS BAJOS, se
conjuga la terminología orientada al problema con la terminología orientada a
la implementación es un esfuerzo para plantear una solución. A medida que
nos movemos a través del proceso del diseño, se reduce el nivel de
abstracción. Finalmente, al NIVEL INFERIOR DE ABSTRACCIÓN la solución se
establece de manera que pueda implementarse directamente, se construye el
código.
A medida que nos movemos a través de diferentes niveles de abstracción, trabajamos
para crear abstracciones procedimentales (es una secuencia dada de
instrucciones que tiene una función específica y limitada), abstracciones de datos
(es una colección determinada de datos que describen un objeto de datos), y las
abstracciones de control (implica un mecanismo de control del programa sin
especificar detalles internos).
B) Refinamiento. El refinamiento paso a paso (Stepwise) es una estrategia de
diseño descendente. En cada paso (del refinamiento), se descomponen una o
varias instrucciones del programa en cuestión en instrucciones mas detalladas.
Esta descomposición sucesiva o refinamiento de especificaciones termina
cuando todas las instrucciones se expresan en términos de cualquier lenguaje
subyacente de programación.
La abstracción permite a un diseñador especificar procedimientos y datos, y
suprimir detalles.
6
El refinamiento ayuda al diseñador a revelar detalles de bajo nivel a medida que
progresa el diseño. Ambos conceptos ayudan al diseñador a crear un modelo de
diseño completo a medida que evoluciona el diseño.
C) Modularidad. Es el atributo del software que permite a un programa se
manejable intelectualmente. Se divide el software en componentes
identificables y tratables por separado, denominados módulos, que están
integrados para satisfacer los requisitos del programa, con el fin de imponer un
ordenamiento jerárquico en el uso de las funciones. Puede ser utilizada para
aislar a las dependencias funcionales; para mejorar el desempeño de un
producto o para facilitar la depuración, las pruebas, la integración, el ajuste y la
modificación de un sistema.
Características de los módulos:
a. Tienen capacidad de descomponerse.
b. Contienen instrucciones, lógica de proceso y estructuras de datos.
c. Pueden ser compilados aparte y almacenados en una biblioteca.
d. Pueden quedar incluidos dentro de un programa.
D) Concurrencia. Los sistemas de programación pueden ser categorizados como
secuenciales o concurrentes. En un sistema secuencial solo una porción del
sistema se encuentra activa en un momento dado; los sistemas concurrentes
tienen procesos independientes que pueden ser actividades en forma
simultanea, si existen procesadores múltiples.
Existen problemas específicos para sistemas concurrentes como la condición de
bloqueo o deadlock, la exclusión mutua y la sincronización de procesos y la condición
de bloqueo es una condición indeseable que ocurre cuando todos los procesadores de
7
un sistema se quedan esperando a que otros procesadores complementen la acción
de sus procesos respectivos para poder continuar.
E) Verificación. Un diseño es verificable si puede demostrarse que el diseño
general del producto que satisface los requerimientos del cliente. Esto se
desarrolla comúnmente en dos pasos:
a. Verificación de los requerimientos.
b. Verificación del diseño.
F) Estética.- Tanto en las artes como en las ingenierías las condiciones estéticas
son fundamentales para el diseño; así como la simplicidad, elegancia y claridad
de un propósito distingue de un producto de alta calidad de los mediocres. Se
refiere aquellas propiedades que van mas allá de la satisfacción de los
requerimientos.
II) EL PROCESO DEL DISEÑO
El diseño del software es un proceso mediante el que se traducen los requisitos
en una representación del software. Desde el punto de vista de gestión del proyecto,
el diseño del software se realiza en tres pasos:
EL DISEÑO PRELIMINAR: se centra en la transformación de los
requisitos en los datos y la arquitectura del software.
EL DISEÑO DETALLADO: se ocupa del refinamiento de la
representación arquitectónica que lleva a una estructura de datos
detallada y las representaciones algorítmicas del software.
DISEÑO DE LA INTERFAZ: establece la disposición y los mecanismos
para la interacción hombre-máquina.
8
III) DOCUMENTACIÓN DEL DISEÑO.
El esquema de documentación presenta una descripción completa del diseño del
software y esta formada por varias secciones:
A. Ámbito.
B. Documentos de referencia.
C. Descripción del diseño.
D. Módulos, para cada módulo.
E. Estructura de archivos y datos globales.
F. Referencias cruzadas para los requisitos.
G. Provisiones de prueba.
H. Empaquetamiento.
I. Notas especiales.
J. Apéndices.
4.2 CONSTRUCCION, CODIFICACION, PRUEBAS Y EVALUACION,
MANUAL DEL USUARIO Y MANUAL TECNICO
El desarrollo de una visión conceptual de un sistema de programación incluye la
determinación del tipo de sistema a desarrollar. Este puede ser un sistema de base
de datos, un sistema de graficas, un sistema de telecomunicaciones, un sistema de
control de proceso o bien un sistema de procesamiento de datos; igualmente, el
sistema puede combinar aspectos de diversos tipos. En cada una de estas
aplicaciones existen diversos puntos de vista, así como terminologías, herramientas y
notaciones adecuadas para esa clase de aplicaciones; resulta esencial que el grupo
de diseño del producto tenga fuerte entendimiento conceptual de la naturaleza del
9
sistema por desarrollar y que, además, este familiarizado con las áreas apropiadas;
no es raro encontrar que los grupos de diseño estén compuestos de uno o más
especialistas de cada área relacionada.
4.2.1 CONSTRUCCION DEL SOFTWARE POR PASOS
La construcción del software por pasos es una técnica para descomposición del
software mediante sus especificaciones de alto nivel hasta sus niveles más
elementales; esta técnica también se denomina “desarrollo a pasos de un programa”
y “refinamiento sucesivo”. Inicialmente propuesta por Wirth, esta técnica requiere de
las siguientes actividades:
1. Descomposición en niveles elementales.
2. Aislamiento de los aspectos de diseño que no sean totalmente
interdependientes.
3. Proposición al máximo de las decisiones que conciernen a los detalles de
representación.
4. Demostración cuidadosa de que en cada paso sucesivo, el refinamiento
es solo una expresión fiel de los pasos anteriores.
4.2.2 CODIFICACION MEDIANTE LOS NIVELES DE ABSTRACCIÓN
Dijkstra describió por primera vez los niveles de abstracción como una técnica de
diseño hacia arriba, en la cual un sistema operativo se diseño como una división de
niveles jerárquicos, comenzando en el nivel 0 (asignado al procesador, interrupciones
de reloj de tiempo real) y subiendo hasta el nivel de procesamiento de programas
10
independientes del usuario. Así mismo se auxilia de la ingeniería de software
asistida por computadora.
a) Herramientas (CASE). Son un conjunto de métodos, utilidades y técnicas
que facilitan la automatización del ciclo de vida del desarrollo de sistemas
de información, completamente o en alguna de sus fases.
La arquitectura de entorno, compuesta por la plataforma hardware y el soporte del
sistema operativo (incluida la red y la gestión de la base de datos), constituye la base
del CASE. Pero el entorno CASE, en sí mismo, necesita otros componentes. Un
conjunto de servicios de portabilidad constituyen un puente entre las herramientas
CASE y su marco de integración y la arquitectura de entorno. El marco de integración
es un conjunto de programas especializados que permite a cada herramienta CASE
comunicarse con las demás, para crear una base de datos de proyectos y mostrar
una apariencia homogénea al usuario final (el ingeniero de software).
La principal ventaja de la utilización de una herramienta CASE, es la mejora de la
calidad de los desarrollos realizados y, en segundo término, el aumento de la
productividad. Para conseguir estos dos objetivos es conveniente contar con una
organización y una metodología de trabajo además de la propia herramienta.
Tipos de CASE. No existe una única clasificación de herramientas CASE y, en
ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse
atendiendo a:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.
11
4.2.3 PRUEBA DEL SOFTWARE
Sin duda el mercado actual no ha ayudado a mejorar ninguna de las etapas de
producción de software, debido a la carrera por salir lo antes posible al mercado. Por
ejemplo, Windows'98 no podía salir en 1999. Sin duda, la etapa más perjudicada es
la de testeo o prueba del software. Aquí describiremos algunas herramientas que
existen hoy para facilitar esta tarea.
Un programa no solamente debe estar libre de errores, sino que es igualmente
importante que el rendimiento del programa final no sea mayor o menor a lo
proyectado originalmente. Escribir un programa que se ejecute como se planeó no es
una tarea simple. Por lo tanto, el proceso de software incluye verificación y
validación.
Este proceso tiene tres etapas bien definidas:
1. Pruebas de desarrollo e ingeniería
2. Pruebas de aseguramiento de calidad internas
3. Pruebas con usuarios
Organización para la prueba de software. En cualquier proyecto de software
existe un conflicto de intereses inherente que aparece cuando comienza la prueba. Se
pide a la gente que ha construido el software que lo pruebe. Esto parece totalmente
inofensivo; después de todo, ¿quien puede conocer mejor el programa que los que lo
han desarrollado?. Desgraciadamente esos mismos desarrolladores , programadores
tienen un gran interés en demostrar que el programa esta libre de errores, que
funciona de acuerdo con las especificaciones del cliente y que estará listo de acuerdo
con los plazos y el presupuesto.
Una estrategia de prueba del software. El proceso de la ingeniería del software
se puede ver como una espiral. Inicialmente la ingeniería del sistema define el papel
del software y conduce al análisis de los requisitos del software donde se establece el
12
campo de información la función el comportamiento, el rendimiento, las restricciones
y los criterios de validación del software. Al movernos hacia el interior de la espiral
llegamos al diseño y por último a la codificación. Para desarrollar software de
computadora damos vuelta en espiral a través de una serie de flujos o líneas que
disminuyen el nivel de abstracción en cada vuelta.
4.2.4 EVALUACION DEL PROYECTO DE SOFTWARE
A. Prueba de Caja Negra. Los datos de prueba se escogerán
atendiendo a las especificaciones del problema, sin importar los detalles
internos del programa, a fin de verificar que el programa corra bien. Con
este tipo de pruebas se intenta encontrar:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a la bases de datos
externas
Errores de rendimiento.
B) Prueba de la Caja de Cristal. Principia con la observación de que un
programa difícilmente puede considerarse como probado por completo si
su código contiene partes que nunca han sido ejecutadas. Este método
analiza la estructura lógica del programa y, para cada alternativa que
puede presentarse, los datos de prueba ideados conducirán a ella. Se
procura escoger los que verifiquen cada posibilidad en las proposiciones
case, las cláusulas de cada proposición if y la condición de terminación de
cada ciclo.
B. Prueba de la Caja de Pandora. Consiste en abstenerse de realizar
pruebas de depurar bastante bien un proyecto; se deja al cliente que lo
ensaye y acepte. El resultado es una bomba de tiempo.
13
Otros tipos de pruebas.- Hay cuatro tipos de pruebas que un producto de
programación debe satisfacer:
A. *Pruebas funcionales.
B. *Pruebas de desempeño
C. *Pruebas de tensión
D. *Pruebas estructurales
4.3 MEDIDA, METRICAS E INDICADORES
A) MEDIDA
Una medida proporciona una indicación cuantitativa de la extensión,cantidad, dimensiones, capacidad o tamaño de algunos atributos de unproceso o producto.
Hay cuatro razones para medir:
Caracterizar.
Evaluar.
Predecir.
Mejorar.
B) MÉTRICA
Una métrica es una medida cuantitativa del grado en que un sistema,componente o proceso posee un atributo dado. Las métricas son elfundamento de los indicadores.
C) INDICADORES
Un indicador es una métrica o combinación de métricas que proporcionan unavisión profunda el proceso del software, del proyecto de software o delproducto en si. Los indicadores del proceso permiten, Al gestor, evaluar loque funciona y lo que no. Los principales objetivos en un indicador permitenestablecer:
14
a. Métricas del proyecto = indicadores del proyecto.
b. Métricas del proceso = indicadores del proceso.
Los indicadores del proyecto permiten al gestor:
a. Evaluar el estado del proyecto en curso.
b. Seguir la pista de riesgos potenciales.
A medida de que los proyectos de software aumentan en complejidad, se observa
que no existe una relación simple entre el precio de software al cliente y los costos
involucrados en el desarrollo, así como la falsa creencia que hay una relación entre el
número de desarrolladores contra el número de funcionalidades del proyecto. Por eso
y para facilitar el proceso de estimación se han establecido a lo largo del tiempo,
métricas que ayudan a dar una idea aproximada del tamaño del software:
Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta
forma de medir el tamaño de un software era utilizado cuando los lenguajes de
programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban
ampliamente desarrollados. Hoy en día es impráctico tratar de estimar el software a
través de sus líneas de código ya que depende de la experiencia de los
programadores o si hablamos de lenguajes de programación dinámicos como Ruby,
Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de
programación.
Medidas relacionadas con la función (UFC – Puntos de Función). El total de
puntos de función no es una característica simple sino que es una combinación de
características del software a las cuales se les asigna un valor que cambia
dependiendo de su complejidad. UFC es igual a la suma de los “n” elementos
evaluados por el peso asignado al tipo de función.
Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de
función tienen en cuenta esto y multiplican los UFC iniciales por un factor de
complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una
15
desventaja de los puntos de función se presenta cuando el sistema está orientado por
eventos. Por eso algunos autores piensan que UFC no es muy útil para medir
productividad.
Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo
II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son
usados en los lenguajes orientados a objetos y de scripts. Dan valor a cada pantalla
dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy
complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los
módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto
puede ser relacionado directamente a las historias de usuario de algunas
metodologías agiles con lo cual facilita la estimación de la iteración.
Modelo Constructivo de Costo: COCOMO II
Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model)
creado por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro
Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión
del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia
del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo
mecanismos de predicción de tiempo.
Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes
momentos del desarrollo ya que la estimación de costos debe de ser un proceso
dinámico a lo largo del desarrollo, actualizando constantemente las variables, la
evolución del equipo de desarrollo, las herramientas y lenguajes involucrados. Los
distintos niveles son:
Construcción de prototipos. Las estimaciones de tamaño están basadas en puntos
de aplicación con base en componentes reutilizables, prototipos y la fórmula para
estimar el esfuerzo requerido es muy simple: tamaño / productividad.
16
Diseño inicial. Está basado en los requerimientos originales del sistema a un alto
nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de
aplicación, esto nos sirve para hacer una predicción temprana del costo.
Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar
el código generado por los IDE’s o herramientas de generación de código reutilizable
como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes
reutilizables que facilitan el desarrollo como Apache Commons.
Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones más
precisas del tamaño del software, aquí es importante señalar que el software tiene
una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento
mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones
de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas
que nos permiten tener una variación muy pequeña con respecto al producto final.
Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1
donde se estima el esfuerzo del personal por mes (PM), después se hace la
estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección
del esfuerzo requerido (B) contemplando los factores involucrados (SF).
Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo
cual existen muchas aplicaciones que se encargan de realizar todas las fórmulas,
como USC COCOMO II que es la aplicación de la página oficial de COCOMO.
Por lo tanto, la estimación de costos es una actividad muy importante en el desarrollo
de software. Esta actividad no es estática sino que cambia en diferentes puntos del
ciclo de vida del desarrollo.
Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la
predicción de costos hasta la retrospectiva de comportamiento del costo, para lo cual
las herramientas de estimación nos ayudan a agilizar la tarea. Sin duda el poder
hacer predicciones con respecto al costo del software nos da ventajas que facilitan el
éxito de un proyecto, sin embargo esto no debe de ser exhaustivo ya que se tienen
17
variables que el modelo no contempla totalmente como la incertidumbre, la
complejidad o factores humanos de los cuales no se puede tener control, por lo cual
se deben tomar en cuenta los riesgos del proceso de desarrollo de software.
Una de las ventajas de COCOMO es el poder medir el comportamiento de costo de un
proyecto de software de forma interna para la empresa de desarrollo. Lo que nos
permite tener un referente en diferentes puntos del proyecto y así poder comprobar
que las proyecciones de costo originales se cumplan.
4.4 TIPOS DE METRICAS. METRICAS DE PROCESO, METRICAS DE
PROYECTO, METRICAS ORIENTAS A AL PUNTO DE FUNCION.
I. Medidas de Tamaño
II. Long. del Código / Tokens / Long. de especificación y diseño
III. Medidas de Funcionalidad
IV. Medidas de Estructura Lógica:
De Estructura de Código
De Estructura de Diseño
V. Acoplamiento / Cohesión / Flujo de Información Modular
4.4.1 METRICAS EN EL PROCESO Y METRICAS DEL PROYECTO
1. ¿Qué es? El proceso del software y las métricas del producto son una medida
cuantitativa que permite a la gente del software tener una visión profunda de
la eficacia del proceso del software y de los proyectos que dirigen utilizando el
proceso como un marco de trabajo.
2. ¿Quién lo hace? Las métricas del software son analizadas y evaluadas por los
administradores del software. A menudo las medidas son reunidas por los
ingenieros del software.
18
3. ¿Por qué es importante? Si no mides, sólo podrás juzgar basándote en una
evaluación subjetiva. Mediante la medición, se pueden señalar las tendencias
(buenas o malas), realizar mejores estimaciones, llevar a cabo una verdadera
mejora sobre el tiempo.
4. ¿Cuáles son los pasos? Comenzar definiendo un conjunto limitado de medidas
de procesos, proyectos y productos que sean fáciles de recoger.
5. ¿Cuál es el producto obtenido? Es un conjunto de métricas del software que
proporcionan una visión profunda del proceso y de la comprensión del
proyecto.
6. ¿Cómo puedo estar seguro de que lo he hecho correctamente? Aplicando un
plan de medición sencillo pero consistente.
4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION
La medida de punto de función se diseñó originalmente para aplicarse a aplicaciones
de sistemas de información de gestión. Para acomodar estas aplicaciones, se enfatizó
la dimensión de datos (los valores de dominios de información) para la exclusión de
dimensiones (control) funcionales y de comportamiento.
Por esta razón, la medida del punto de función era inadecuada para muchos sistemas
de ingeniería y sistemas empotrados (que enfatizan función y control). Para remediar
esta situación se ha propuesto un número de extensiones a la métrica del punto de
función básica. Las métricas del software orientadas a la función utilizan una medida
de la funcionalidad entregada por la aplicación como un valor de normalización. Ya
que la «funcionalidad>> no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas.
Las métricas orientadas a la función fueron propuestas por primera vez por Allan
Albretch. Una extensión del punto de función es la llamada puntos de
características; es una ampliación de la medida del punto de función que se puede
19
aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto de
característica acomoda a aplicaciones en donde la complejidad del algoritmo es
alta. Las aplicaciones de software de tiempo real, de
control de procesos, y empotradas tienden a tener alta complejidad de
algoritmos y por lo tanto son adecuadas para el punto de característica. Los puntos
de función se derivan con una relación empírica según las medidas contables
(directas) del dominio de información del software y las evaluaciones de la
complejidad del software.
Los puntos de función se calculan completando la siguiente tabla:
Se determinan cinco características de dominios de información y se proporcionan las
cuentas en la posición apropiada de la tabla. Los valores de los dominios de
información se definen de la forma siguiente:
a. Número de entradas de usuario. Se cuenta cada entrada de usuario que
proporciona diferentes datos orientados a la aplicación. Las entradas se
deberían diferenciar de las peticiones, las cuales se cuentan de forma
separada.
b. Número de salidas de usuario. Se cuenta cada salida que proporciona al
usuario información orientada a la aplicación. En este contexto la salida se
20
refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos
particulares dentro de un informe no se cuentan de forma separada.
c. Número de peticiones de usuario. Una petición se define como una
entrada interactiva que produce la generación de alguna respuesta del
software inmediata en forma de salida interactiva. Se cuenta cada petición por
separado.
d. Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un
grupo lógico de datos que puede ser una parte de una gran base de datos o
un archivo independiente).
e. Número de interfaces externas. Se cuentan todas las interfaces legibles
por la máquina (por ejemplo: archivos de datos de cinta o disco) que se
utilizan para transmitir información a otro sistema.
Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de
complejidad. Las organizaciones que utilizan métodos de puntos de función
desarrollan criterios para determinar si una entrada en particular es simple, media o
compleja. Las métricas orientadas a Puntos de Función se caracterizan por:
a) Tener un componente empírico, basado en la experiencia de muchos
proyectos.
b) Tener en cuenta la complejidad, aunque es muy difícil de determinar en
un proyecto
c) Ser independientes del entorno tecnológico y de las metodologías
aplicadas.
d) Utilizar medidas indirectas, que se caracterizan por ser subjetivas y
difíciles de calcular, sin embargo el resultado obtenido es fácilmente
comparable.
21
4.5 IMPLEMENTACION Y MANTENIMIENTO DEL SOFTWARE
Al hablar de implementación y mantenimiento de software, hablamos de diversos
productos como software a la medida, sistema bolsa de trabajo, registro de usuarios,
sistema de reservaciones, de gestión, motor bienes raíces, outsourcing
programadores, mapas geográficos, servidores, aplicación server provider, Visual
Studio, on line, AJAX, SQL server, renta tiendas en línea, administrador de
contenidos, carrito de compras, cotizador, inventarios en linea, optimización y
posicionamiento web de sitios, portales o páginas en la red.
La importancia de la implementación y mantenimiento de software radica en brindarle
la capacitación necesaria para el correcto manejo del sistema y por otro lado permite
que se cumpla la finalidad de todo programa de software: dejar que el sistema haga
todo el trabajo pesado, brindándole el tiempo para trabajar sobre otras áreas de su
negocio. La implementación es un paso importante en el desarrollo de su software
porque es la parte donde el sistema se integra a su empresa, mejorando la eficacia
de los procesos, reduciendo el margen de riesgo de error e incrementando la
capacidad de su negocio para atender a un mayor número de clientes reduciendo
costos de operación sin perder calidad en sus procesos.
Esta es la parte que hace toda la diferencia al adquirir un software hecho a la medida
a propuestas ya existentes en el mercado. Si no se cuenta con una asesoría
profesional en la selección de éstas últimas, un software adaptable puede presentar
problemas en su implementación o no cubrir con los objetivos esperados, ya sea
porque el mismo sistema está diseñado sólo para desempeñar algunas de las
asignaciones o al momento de probarlo resulta inadecuado o incompatible para la
naturaleza de su negocio. Es por eso que muchas veces, un software hecho la
medida representa una opción sumamente atractiva ya que al ser un sistema
diseñado única y especialmente para usted, la implementación no representa ningún
problema sino que al contrario promueve el desarrollo de su empresa, ya que una vez
instalado genera una mejor eficiencia, un ahorro de tiempo y la capacidad de ser una
plataforma de donde se puede hacer futuras adaptaciones o módulos adicionales. La
22
implementación y mantenimiento de software es una pieza clave para el buen
funcionamiento de su negocio, y por ende, de su empresa.
El mantenimiento, por otro lado, es un aspecto necesario porque como toda
maquinaria humana requiere de un cuidado y revisión periódica no sólo para su
correcto funcionamiento sino para ir adaptando al sistema, los cambios y
requerimientos que se puedan ir presentando durante la marcha. Dos características
principales del mantenimiento de Software:
1. •El mantenimiento del software puede llevar hasta el 70% de todo el
esfuerzo gastado por una organización de desarrollo.
2. •El mantenimiento es mas que una “Corrección de errores”
Las 4 actividades que se llevan a cabo para describir el mantenimiento de software:
1.-Mantenimiento Correctivo
2.- Mantenimiento Adaptativo
3.-Mantenimiento Perfectivo
4.-Ingeniería Inversa o Reingeniería.
NOTA:
REALIZAR CUESTIONARIO INDIVIDUAL (10 PREGUNTAS) REALIZAR UN MAPA CONCEPTUAL DE LA UNIDAD REALIZAR SU PRESENTACION DE LA UNIDAD EN POWER-POINT REALIZAR UN CRUCIGRAMA DE LA UNIDAD, CON TRES PALABRAS
POR TEMA
“SE DEBERA UTLIZAR LOS FORMATOS ESTABLECIDOS PARA EVIDENCIATANTO TAREAS E INVESTIGACIONES, COMO DE MAPAS CONCEPTUALES”
SE ENTREGARA EN CD, O MEDIANTE EVIDENCIA ELECTRONICA (BLOG)
