Vous êtes sur la page 1sur 19

UNIDAD IV

INSTITUTO TECNOLGICO DE TLALNEPANTLA


DEPARTAMENTO DE SISTEMAS Y COMPUTACION

INGENIERIA EN TECNOLOGIAS DE INFORMACION Y COMUNICACIONES

UNIDAD IV ANALISIS DEL PROYECTO DE SOFTWARE

PROFESOR: DR. ANTONIO NAVARRETE PRIETO

AGOSTO-DICIEMBRE 2013

1 DR. ANTONIO NAVARRETE PRIETO

4.1

MODELADO, ANALISIS, DISEO Y DOCUMENTACION

4.1.1 MODELADO

El modelado es una actividad de definicin formal de aspectos del mundo fsico y social que nos rodea con el propsito de entender y comunicar, para lo cual es una actividad de modelado que permite combinar problemas: Empricos: especificaciones ligadas al mundo real Formales: abstraccin, estructura y representacin del conocimiento del problema. De ingeniera: mtodos formales de construccin

Tipos de modelado. Se puede elegir entre una variedad de esquemas conceptuales:

1) Lenguaje natural. Muy expresivo y flexible, Pobre al intentar captar la semntica del modelo, mejor para la toma de requerimientos 2) Notacin semi formal. Captura estructura y alguna semntica, puede llevar a cabo algn razonamiento, chequeo de consistencia y animacin. 3) Notacin formal. Semntica muy precisa y son muy complejos.

Tcnicas de modelado:
Modelado de empresa Metas y objetivos Estructura organizacional Actividades, procesos y productos Roles y trabajos de agentes
2

Modelado de requerimientos funcionales Vistas estructurales (de datos) Vistas de comportamiento Requerimientos de tiempo

Modelado de requerimientos no funcionales. De productos, de procesos y externos

4.1.2 ANALISIS
Definicin. Proveer un marco de trabajo para modelar de forma detallada el sistema como parte de la obtencin y anlisis de requerimientos (Sommerville): Aproximacin al modelo conceptual orientada en los datos El diagrama de flujo de datos (DFD) es el elemento ms representativo Se deben entender los requerimientos necesarios para continuar

en la evolucin del sistema. Debilidades No provee mtodos efectivos para tratar con requerimientos no funcionales No ayuda al usuario a decidir el mejor mtodo para cada caso. Produce demasiada documentacin Modelos muy detallados que son de difcil comprensin por parte de los usuarios

Conceptos centrales del Anlisis Transformacin de datos Actividades que transforman los datos Flujo de datos Indica el paso de datos de la entrada del mismo hacia la salida
3

Representa grupos de datos o elementos de datos

Almacenamiento de datos Lugar donde se deja informacin para su uso posterior Los almacenes de datos son pasivos, no transforman los datos

4.1.3 DISEO EN LA INGENIERA DEL SOFTWARE

El diseo del software se sita en el ncleo tcnico del proceso de ingeniera del software y se aplica independientemente del paradigma del desarrollo utilizado. El diseo del software es la primera de las tres actividades tcnicas: diseo, codificacin y prueba: necesarias para construir y verificar el software. Cada actividad transforma la informacin de manera que se obtenga finalmente un software valido. La importancia del diseo del software se puede decir con una sola palabra: calidad. El diseo nos proporciona representaciones del software en las que se pueden valorar la calidad. El diseo externo de software requiere de concebir, planear y especificar sus caractersticas de un producto de programacin. Estas caractersticas incluyen la definicin de despliegues de pantalla y los formatos de reportes, la definicin de las entradas y salidas de datos, as como las caractersticas funcionales, los

requerimientos de desempeo y la estructura general del producto.

A) CONCEPTOS FUNDAMENTALES DEL DISEO

A)

Abstraccin. Cuando consideramos una solucin modular para cualquier problema, se puede plantear muchos NIVELES DE ABSTRACCIN. Al NIVEL SUPERIOR DE ABSTRACCIN se establece una solucin en trminos amplios usando el lenguaje del entorno del problema. A NIVELES MAS BAJOS, se conjuga la terminologa orientada al problema con la terminologa orientada a la implementacin
4

es un esfuerzo para plantear una solucin. A medida que nos movemos a travs del proceso del diseo, se reduce el nivel de abstraccin. Finalmente, al NIVEL INFERIOR DE ABSTRACCIN la solucin se establece de manera que pueda implementarse directamente, se construye el cdigo. A medida que nos movemos a travs de diferentes niveles de abstraccin, trabajamos para crear abstracciones procedimentales (es una secuencia dada de instrucciones que tiene una funcin especfica y limitada), abstracciones de datos (es una coleccin 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 diseo descendente. En cada paso (del refinamiento), se descomponen una o varias instrucciones del programa en cuestin en instrucciones mas detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones termina cuando todas las instrucciones se expresan en trminos de cualquier lenguaje subyacente de programacin. La abstraccin permite a un diseador especificar procedimientos y datos, y suprimir detalles.

El refinamiento ayuda al diseador a revelar detalles de bajo nivel a medida que progresa el diseo. Ambos conceptos ayudan al diseador a crear un modelo de diseo completo a medida que evoluciona el diseo.

C)

Modularidad. 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 mdulos, que estn integrados para satisfacer los requisitos del programa, con el fin de imponer un ordenamiento jerrquico en el uso de las funciones. Puede ser utilizada para aislar a las
5

dependencias funcionales; para mejorar el desempeo de un producto o para facilitar la depuracin, las pruebas, la integracin, el ajuste y la modificacin de un sistema.

Caractersticas de los mdulos:

Tienen capacidad de descomponerse. Contienen instrucciones, lgica de proceso y estructuras de datos. Pueden ser compilados aparte y almacenados en una biblioteca. Pueden quedar incluidos dentro de un programa.

D)

Concurrencia. Los sistemas de programacin pueden ser categorizados

como secuenciales o concurrentes. En un sistema secuencial solo una porcin 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 mltiples. Existen problemas especficos para sistemas concurrentes como la condicin de bloqueo o deadlock, la exclusin mutua y la sincronizacin de procesos y la condicin de bloqueo es una condicin indeseable que ocurre cuando todos los procesadores de un sistema se quedan esperando a que otros procesadores complementen la accin de sus procesos respectivos para poder continuar. E) Verificacin. Un diseo es verificable si puede demostrarse que el diseo general del producto que satisface los requerimientos del cliente. Esto se desarrolla comnmente en dos pasos: 1. Verificacin de los requerimientos. 2. Verificacin del diseo.

F)

Esttica.- Tanto en las artes como en las ingenieras las condiciones estticas son fundamentales para el diseo; as como la simplicidad, elegancia y claridad de un propsito distingue de un producto de alta calidad de los mediocres. Se refiere aquellas propiedades que van mas all de la satisfaccin de los requerimientos.

B) EL PROCESO DEL DISEO


El diseo del software es un proceso mediante el que se traducen los requisitos en una representacin del software. Desde el punto de vista de gestin del proyecto, el diseo del software se realiza en tres pasos:

EL DISEO PRELIMINAR: se centra en la transformacin de los requisitos en los datos y la arquitectura del software. EL DISEO DETALLADO: se ocupa del refinamiento de la

representacin arquitectnica que lleva a una estructura de datos detallada y las representaciones algortmicas del software. DISEO DE LA INTERFAZ: establece la disposicin y los mecanismos para la interaccin hombre-mquina.

C) DOCUMENTACIN DEL DISEO.


El esquema de documentacin presenta una descripcin completa del diseo del software y esta formada por varias secciones: A. mbito. B. Documentos de referencia. C. Descripcin del diseo. D. Mdulos, para cada mdulo.
7

E. Estructura de archivos y datos globales. F. Referencias cruzadas para los requisitos. G. Provisiones de prueba. H. Empaquetamiento. I. J. Notas especiales. Apndices.

4.2 CONSTRUCCION, CODIFICACION, PRUEBAS Y EVALUACION, MANUAL DEL USUARIO Y MANUAL TECNICO

El desarrollo de una visin conceptual de un sistema de programacin incluye la determinacin 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 terminologas, herramientas y notaciones adecuadas para esa clase de aplicaciones; resulta esencial que el grupo de diseo del producto tenga fuerte entendimiento conceptual de la naturaleza del sistema por desarrollar y que, adems, este familiarizado con las reas apropiadas; no es raro encontrar que los grupos de diseo estn compuestos de uno o ms especialistas de cada rea relacionada.

4.2.1 CONSTRUCCION DEL SOFTWARE POR PASOS

La construccin del software por pasos es una tcnica para descomposicin del software mediante sus especificaciones de alto nivel hasta sus niveles ms

elementales; esta tcnica tambin se denomina desarrollo a pasos de un programa


8

y refinamiento sucesivo. Inicialmente propuesta por Wirth, esta tcnica requiere de las siguientes actividades: 1. Descomposicin en niveles elementales. 2. Aislamiento de los aspectos de diseo que no sean totalmente interdependientes. 3. Proposicin al mximo de las decisiones que conciernen a los detalles de representacin. 4. Demostracin cuidadosa de que en cada paso sucesivo, el refinamiento es solo una expresin fiel de los pasos anteriores.

4.2.2 CODIFICACION MEDIANTE LOS NIVELES DE ABSTRACCIN

Dijkstra describi por primera vez los niveles de abstraccin como una tcnica de diseo hacia arriba, en la cual un sistema operativo se diseo como una divisin de niveles jerrquicos, comenzando en el nivel 0 (asignado al procesador,

interrupciones de reloj de tiempo real) y subiendo hasta el nivel de procesamiento de programas independientes del usuario. As mismo se auxilia de la ingeniera de

software asistida por computadora.


a) Herramientas (CASE). Son un conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de informacin, 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 gestin 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 integracin y la arquitectura de entorno. El marco de integracin es un conjunto de programas especializados que permite a cada herramienta CASE

comunicarse con las dems, para crear una base de datos de proyectos y mostrar una apariencia homognea al usuario final (el ingeniero de software). La principal ventaja de la utilizacin de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo trmino, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organizacin y una metodologa de trabajo adems de la propia herramienta.

Tipos de Case. No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en una clase determinada. Podran 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.

4.2.3 PRUEBA DEL SOFTWARE


Sin duda el mercado actual no ha ayudado a mejorar ninguna de las etapas de produccin de software, debido a la carrera por salir lo antes posible al mercado. Por ejemplo, Windows98 no poda salir en 1999. Sin duda, la etapa ms 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 verificacin y validacin.

10

Este proceso tiene tres etapas bien definidas: 1. 2. 3. Pruebas de desarrollo e ingeniera Pruebas de aseguramiento de calidad internas Pruebas con usuarios

Organizacin 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; despus de todo, quien puede conocer mejor el programa que los que lo han desarrollado?. Desgraciadamente esos mismos desarrolladores , programadores tienen un gran inters 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 ingeniera del software se puede ver como una espiral. Inicialmente la ingeniera del sistema define el papel del software y conduce al anlisis de los requisitos del software donde se establece el campo de informacin la funcin el comportamiento, el rendimiento, las restricciones y los criterios de validacin del software. Al movernos hacia el interior de la espiral llegamos al diseo y por ltimo a la codificacin. Para desarrollar software de computadora damos vuelta en espiral a travs de una serie de flujos o lneas que disminuyen el nivel de abstraccin en cada vuelta.

4.2.4 EVALUACION DEL PROYECTO DE SOFTWARE A. Prueba de Caja Negra. Los datos de prueba se escogern 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.
11

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 observacin de que un programa difcilmente puede considerarse como probado por completo si su cdigo contiene partes que nunca han sido ejecutadas. Este mtodo analiza la estructura lgica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirn a ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones case, las clusulas de cada proposicin if y la condicin de terminacin de cada ciclo. C. 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. Otros tipos de pruebas.- Hay cuatro tipos de pruebas que un producto de programacin debe satisfacer:

A. B. C. D.

*Pruebas funcionales. *Pruebas de desempeo *Pruebas de tensin *Pruebas estructurales

4.3 MEDIDA, METRICAS E INDICADORES A) MEDIDA Una medida proporciona una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. Hay cuatro razones para medir: Caracterizar.
12

Evaluar. Predecir. Mejorar. B) MTRICA Una mtrica es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Las mtricas son el fundamento de los indicadores. C) INDICADORES Un indicador es una mtrica o combinacin de mtricas que proporcionan una visin profunda el proceso del software, del proyecto de software o del producto en si. Los indicadores del proceso permiten, Al gestor, evaluar lo que funciona y lo que no. Nuestros objetivos son establecer: Mtricas del proyecto = indicadores del proyecto. Mtricas del proceso = indicadores del proceso.

Los indicadores del proyecto permiten al gestor: Evaluar el estado del proyecto en curso. Seguir la pista de riesgos potenciales.

4.4

TIPOS DE METRICAS. METRICAS DE PROCESO, METRICAS DE PROYECTO, METRICAS ORIENTAS A AL PUNTO DE FUNCION. I. II. III. IV. Medidas de Tamao Long. del Cdigo / Tokens / Long. de especificacin y diseo Medidas de Funcionalidad Medidas de Estructura Lgica: de Estructura de Cdigo de Estructura de Diseo
13

V.

Acoplamiento / Cohesin / Flujo de Informacin Modular

4.4.1 METRICAS EN EL PROCESO Y METRICAS DEL PROYECTO 1. Qu es? El proceso del software y las mtricas del producto son una medida cuantitativa que permite a la gente del software tener una visin profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo. 2. Quin lo hace? Las mtricas del software son analizadas y evaluadas por los administradores del software. A menudo las medidas son reunidas por los ingenieros del software. 3. Por qu es importante? Si no mides, slo podrs juzgar basndote en una evaluacin subjetiva. Mediante la medicin, se pueden sealar las tendencias (buenas o malas), realizar mejores estimaciones, llevar a cabo una verdadera mejora sobre el tiempo. 4. Cules son los pasos? Comenzar definiendo un conjunto limitado de medidas de procesos, proyectos y productos que sean fciles de recoger. 5. Cul es el producto obtenido? Es un conjunto de mtricas del software que proporcionan una visin profunda del proceso y de la comprensin del proyecto. 6. Cmo puedo estar seguro de que lo he hecho correctamente? Aplicando un plan de medicin sencillo pero consistente.

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION La medida de punto de funcin se dise originalmente para aplicarse a aplicaciones de sistemas de informacin de gestin. Para acomodar estas aplicaciones, se enfatiz la dimensin de datos (los valores de dominios de informacin) para la exclusin de dimensiones (control) funcionales y de comportamiento.

14

Por esta razn, la medida del punto de funcin era inadecuada para muchos sistemas de ingeniera y sistemas empotrados (que enfatizan funcin y control). Para remediar esta situacin se ha propuesto un nmero de extensiones a la mtrica del punto de funcin bsica. Las mtricas del software orientadas a la funcin utilizan una medida de la funcionalidad entregada por la aplicacin como un valor de normalizacin. Ya que la funcionalidad>> no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. Las mtricas orientadas a la funcin fueron propuestas por primera vez por Allan Albretch. Una extensin del punto de funcin es la llamada puntos de caractersticas; es una ampliacin de la medida del punto de funcin que se puede aplicar a sistemas y aplicaciones de ingeniera del software. La medida de punto de caracterstica acomoda a aplicaciones en donde la complejidad del algoritmo es alta. Las aplicaciones de software tienden a de tener tiempo alta real, de de

control de procesos, y empotradas

complejidad

algoritmos y por lo tanto son adecuadas para el punto de caracterstica. Los puntos de funcin se derivan con una relacin emprica segn las medidas contables (directas) del dominio de informacin del software y las evaluaciones de la complejidad del software. Los puntos de funcin se calculan completando la siguiente tabla:

15

Se determinan cinco caractersticas de dominios de informacin y se proporcionan las cuentas en la posicin apropiada de la tabla. Los valores de los dominios de informacin se definen de la forma siguiente:

Nmero de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicacin. Las entradas se deberan diferenciar de las peticiones, las cuales se cuentan de forma separada.

Nmero de salidas de usuario. Se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

Nmero de peticiones de usuario . Una peticin se define como una entrada interactiva que produce la generacin de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada peticin por separado.

Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un grupo lgico de datos que puede ser una parte de una gran base de datos o un archivo independiente).

Nmero de interfaces externas. Se cuentan todas las interfaces legibles por la mquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir informacin 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 mtodos de puntos de funcin desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. Las mtricas orientadas a Puntos de Funcin se caracterizan por: a) Tener un componente emprico, basado en la experiencia de muchos proyectos. b) Tener en cuenta la complejidad, aunque es muy difcil de determinar en un proyecto
16

c) Ser independientes del entorno tecnolgico y de las metodologas aplicadas. d) Utilizar medidas indirectas, que se caracterizan por ser subjetivas y difciles de calcular, sin embargo el resultado obtenido es fcilmente comparable.

4.5 IMPLEMENTACION Y MANTENIMIENTO DEL SOFTWARE


Al hablar de implementacin y mantenimiento de software, hablamos de diversos productos como software a la medida, sistema bolsa de trabajo, registro de usuarios, sistema de reservaciones, de gestin, motor bienes races, outsourcing

programadores, mapas geogrficos, servidores, aplicacin server provider, Visual Studio, on line, AJAX, SQL server, renta tiendas en lnea, administrador de contenidos, carrito de compras, cotizador, inventarios en linea, optimizacin y posicionamiento web de sitios, portales o pginas en la red. La importancia de la implementacin y mantenimiento de software radica en brindarle la capacitacin 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, brindndole el tiempo para trabajar sobre otras reas de su negocio. La implementacin 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 nmero de clientes reduciendo costos de operacin 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 asesora profesional en la seleccin de stas ltimas, un software adaptable puede presentar problemas en su implementacin o no cubrir con los objetivos esperados, ya sea porque el mismo sistema est diseado slo para desempear 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 opcin sumamente atractiva ya que al ser un sistema
17

diseado nica y especialmente para usted, la implementacin no representa ningn 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 mdulos adicionales. La implementacin 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 revisin peridica no slo para su correcto funcionamiento sino para ir adaptando al sistema, los cambios y requerimientos que se puedan ir presentando durante la marcha. Dos caractersticas principales del mantenimiento de Software: 1. El mantenimiento del software puede llevar hasta el 70% de todo el esfuerzo gastado por una organizacin de desarrollo. 2. El mantenimiento es mas que una Correccin 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.-Ingeniera Inversa o Reingeniera.

CUESTIONARIO
18

1. EN QUE CONSISTE EL REFINAMIENTO SUCESIVO PROPUESTO POR WIRTH? 2. EN QUE CONSISTE LA PRUEBA DE LA CAJA NEGRA Y QUE INTENTA ENCONTRAR? 3. POR QU ES IMPORTANTE EL DISEO EN LA INGENIERA DE SOFTWARE? 4. QU ES EL MANTENIMIENTO DE SOFTWARE Y CUALES SON SUS DOS CARACTERSTICAS? 5. QU ES EL MODELADO?, Y MENCIONA 3 TIPOS? 6. QU ES UNA MTRICA ORIENTADA A PUNTO DE FUNSIN? 7. QUE ES UNA MTRICA Y QUE ES UN INDICADOR? 8. MENCIONE LOS CONCEPTOS FUNDAMENTALES DE DISEO Y EXPLIQUE DOS? 9. MENCIONE LOS NIVELES DE ABSTRACCIN PROPUESTOS POR DIJKSTRA? 10. PROPORCIONA LA DEFINICIN DE ANLISIS DE ACUERDO A

SOMMERVILLE Y MENCIONE DOS DEBILIDADES?

19

Vous aimerez peut-être aussi