domingo, 6 de abril de 2014
Tecnicas de estimación de casos de uso
Esta tecnica es una mejora de la tecnica por puntos de función pero esta orientada por el diagrama de casos de uso que es producto del análisis de requerimientos.
El objetivo de esta tecnica es estimar las horas para ejecutar un conjunto de casos de uso, ello es asi porque un diagrama de casos de uso es un esquema gráfico del sistema a desarrollar.
Entre sus ventajas podemos destacar que trabaja bien con proyectos chicos, medianos o grandes y tambien con diferentes tipos de software, como desventaja y muy importante es que su aplicación es cara.
El método de punto de casos de uso consta de varias etapas que son las siguientes:
1.- Calcular los puntos de casos de uso no ajustados (UUCP)
Pesar los actores(AUW) y pesar los casos de uso(UUCW)
UUCP= AUW + UUCW
2.- Calcular los puntos de casos de uso (UCP)
Pesar factores tecnicos(TCF)
Pesar los factores ambientales(EF)
UCP= UUCP * TCF * EF
3.- Estimar horas-hombre
Horas hombre = UCP *20 ó UCP * 28 ó UCP * 36 dependiendo el valor.
Para pesar los actores:
| Tipo de actor | Descripción | Factor |
| Simple | Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API). | 1 |
| Medio | Otro sistema interactuando a través de un protocolo (ej. TCP/IP) o una persona interactuando a través de una interfaz en modo texto. | 2 |
| Complejo | Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). | 3 |
Para pesar los casos de uso hay dos formas:
1.- Por el número de transacciones :
| Tipo de caso de uso | Descripción | Factor |
| Simple | 3 transacciones o menos | 5 |
| Medio | 4 a 7 transacciones | 10 |
| Complejo | Más de 7 transacciones | 15 |
2.- Por el número de clases que tienen el caso de uso:
| Tipo de caso de uso | Descripción | Factor |
| Simple | Menos de 5 clases | 5 |
| Medio | 5 a 10 clases | 10 |
| Complejo | Más de 10 clases | 15 |
Para pesar los factores de complejidad tecnica:
| Factor | Descripción | Peso |
| T1 | Sistema distribuido. | 2 |
| T2 | Objetivos de performance o tiempo de respuesta. | 1 |
| T3 | Eficiencia del usuario final. | 1 |
| T4 | Procesamiento interno complejo. | 1 |
| T5 | El código debe ser reutilizable. | 1 |
| T6 | Facilidad de instalación. | 0.5 |
| T7 | Facilidad de uso. | 0.5 |
| T8 | Portabilidad. | 2 |
| T9 | Facilidad de cambio. | 1 |
| T10 | Concurrencia. | 1 |
| T11 | Incluye objetivos especiales de seguridad. | 1 |
| T12 | Provee acceso directo a terceras partes. | 1 |
| T13 | Se requiere facilidades especiales de entrenamiento a usuario. | 1 |
Para pesar los factores ambientales:
| Factor | Descripción | Peso |
| E1 | Familiaridad con el modelo de proyecto utilizado. | 1.5 |
| E2 | Experiencia en la aplicación. | 0.5 |
| E3 | Experiencia en orientación a objetos. | 1 |
| E4 | Capacidad del analista líder. | 0.5 |
| E5 | Motivación. | 1 |
| E6 | Estabilidad de los requerimientos | 2 |
| E7 | Personal part-time | -1 |
| E8 | Dificultad del lenguaje de programación | -1 |
Para calcular las horas hombre:
| Horas-Persona (CF) | Descripción |
| 20 | Si el valor es<=2 |
| 28 | Si el valor es<=4 |
| 36 | Si el valor es>=5 |
Referencias:
http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso
http://www.uv.mx/personal/asumano/files/2010/07/PUNTOS-DE-CASOS-DE-USO-2011.pdf
http://www.slideshare.net/darthuzkatorcekilates/puntos-de-caso-de-uso
Puntos de función
Los puntos de función son una metrica que nos permiten medir en números la funcionalidad del software. Esto nos da la posiblilidad de tener una idea de la calidad del software porque el proposito de todo esto es conocer la funcionalidad del sistema y eso es parte de la calidad.
A continuación se mostrara como calcular los puntos de función:
La primera tabla que se puede ver en la imagen sirve para calcula los puntos de función sin ajuste
para eelo se toman en cuenta el num de entrada, de salidas, de peticiones, de archivos y de interfaces que pueda tener nuestro sistema y se multiplica por un caso que puede ser simple, medio o complejo eso depende de nuestro numero que hayamos puesto pero para medir la complejidad esa metrica la marcamos nosotros.
En este ejemplo se puede ver que el número de entrada es complejo al igual que el número de salidas y el número de interfaces, mientras que el número de peticiones y el número de archivos son de complejidad media. Los resultados se suman y el total son los puntos de función sin ajuste.
La segunda tabla muestra como calcular los puntos de complejidad de procesamiento, se tiene que considerar lo siguiente:
- Son 14 puntos de complejidad.
- Cada factor se evalua en una escala de 0 a 5
Tomando en cuenta estos factores una vez dado un valor a cada punto de complejidad se suma y saca un total.
Una vez calculado los puntos de función sin ajuste y los puntos de complejidad se aplica la siguientes formulas:
- Factor de complejidad de procesamiento (FCP)
- FCP= 0.65 + (0.01 * PCP)
- = 0.65 + (0.01 * 39)
- =1.04
- Total de puntos de funcion (FP)
- =155 * 1.04
- =161.2
Referencias
A. J. Albretch, J. E. Gaffney, Software Function, Source
Lines of Code, and Development Effort Prediction: A Software Science
Validation, IEEE Transactions on Software Engineering, Vol 9, No. 6, noviembre
de 1983.
C. R. Symons, Function Point Analysis: Difficulties and
Inprovements, IEEE Transactions on Software Engineering, Vol 14, No. 1, enero
de 1988.
C. F. Kemerer, B. S. Porter, Improving the Reliability of
Function Point Measurement: An Empirical Study, IEEE Transactions on Software
Engineering, Vol 18, No. 11, noviembre de 1992.
International Function Point Users Group (IFPUG) Home Page,
http://www.ifpug.org/home/docs/ifpughome.htmlIFPUG, Guidelines to Software
Measurement, IFPUG, 1994.
lunes, 24 de febrero de 2014
PSP Formatos
PSP tiene una serie de formatos que ayudan a hacer un correcto análisis del software a desarrollar.
Los procesos definidos nos ayudan a administrar los proyectos, ya sea trabajando en equipo o trabajando solo. Lo primero que hay que hacer para poder definir los procesos que van a intervenir en un proyecto es:
1. Identificar las actividades principales.
2. Separar los elementos complejos que pueden
intervenir.
3. Establecer los criterios de entrada y de
salida para cada fase del proceso.
4. Medir de manera correcta el
proceso, para tener bien entendido el desempeño personal.
5. Estimar correctamente cuando debe finalizar
cada tarea.
6. Medir con precisión todos los
datos que intervinieron para futuros programas.
7. Identificar las fases del proyecto que más
problemas causaron.
8. Mejora continua tomando en cuenta datos anteriores.
Formatos
Formato del Registro de Tiempo
El formato, que se presenta a
continuación, es el formato del registro de tiempo y que contiene diversos
campos, aunque conforme se avance de nivel, se van agregando más campos y
demandas.
El
propósito de éste formato es el de registrar el tiempo empleado en cada fase
del proyecto. Al mismo tiempo, estos datos son utilizados para complementar el
resumen del plan del proyecto.
Formato de registro de defectos
El propósito general del registro de defectos reside en promover la mejora continua cada vez que se
haga un proyecto. Cada fase de PSP debe de contar con un registro de defectos,
ya sean revisiones, compilaciones o pruebas.
Formato de Resumen de Plan de Proyecto
Este es el formato más importante de todos. En
el formato se muestra el resumen del plan del proyecto, este formato reúne las
estimaciones y los datos reales que conforman al proyecto en toda su amplitud
para que al final se realicen las comparaciones necesarias y exista un histórico
de todos los proyectos realizados.
Como
se puede apreciar en este formato, existen tres campos diferentes. Dos de estos
campos tienen que ver con los defectos encontrados y removidos en cada fase.
Este formato es esencial ya que
es un respaldo para cada proyecto que se desarrolla. En él se pueden encontrar
los datos que serán útiles para el siguiente proyecto parecido que se
desarrolle. Es importante que los datos se escriban con claridad y con
precisión para que cada fase de desarrollo sirva para tener un margen de
comparación con proyectos futuros.
Conclusión
Los formatos son una parte muy importante a tomar en cuenta ya que en ellos es donde se ve reflejado realmente el trabajo realizado en el proyecto, tienen como objetivo principal documentar lo que se realizó bien y también lo que se realizo mal, todo esto con el fin de saber que tanto del proyecto hemos realizado y que nos falta por hacer ademas también los formatos permiten incluso dar pautas a mejoras del proyecto obteniendo un mejor producto del que se hubiera realizado sin utilizar ningún formato.
Referencias
Calero, C. (2010). Calidad del producto y proceso
software. En C. Calero, Calidad del producto y proceso software (pág.
668). Madrid: Editorial Ra-Ma.
PSP
PSP o proceso personal de software es un conjunto de practicas destinadas a el desarrollo de software, fue inventado por Watts Humphrey en 1995 y esta dirigido a estudiantes o desarrolladores sin experiencia con el fin de que puedan utilizar un modelo de calidad sin tantas complicaciones como lo es ISO o CMMI.
También es utilizado como una guía de trabajo para aquellos que desarrollan utilizando el modelo CMMI (siendo estos programadores más experimentados).
Beneficios
Los datos y su análisis permitirán determinar las fortalezas y debilidades.
Los datos y su análisis posterior conducirán hacia nuevas ideas para la mejora del proceso.
Se tendrá control total sobre el calendario, aceptando sólo aquellos compromisos que se puedan cumplir.
La parte de calidad ayudará a producir mejores productos de trabajo.
Desventajas
El usar lineas de código como métrica tiene desventajas ya que depende del lenguaje de programación porque algunas acciones a realizar pueden ocupar menos lineas de un lenguaje a otro por ejemplo java y phyton el segundo necesita menos lineas para lograr lo mismo que en el primero.
PSP sólo requiere un estimado del tiempo de interrupción, en lugar de obligar al usuario a registrar el tiempo real.
Es subjetivo determinar si una parte del software es reutilizable.
PSP esta especialmente enfocado al desarrollo de software y no toma en cuenta el tiempo empleado en la negociación de los requerimientos con el cliente.
Conclusión
PSP es muy útil tanto para desarrolladores novatos como experimentados, en especial los novatos ya que si se entiende muy bien este proceso o forma de trabajar se puede comprender más fácilmente modelos más complejos como CMMI ademas que tanto PSP como CMMI se complementan, otra cosa importante que voy a remarcar es que el desarrollador debe de adaptar PSP a sus necesidades y no pensar que debe de tratar de seguir PSP al pie de la letra ya que solo marca lo que debe de contener la documentación más no una forma especifica de hacerlo.
 |
| Diagrama de PSP |
Vídeos que te pueden ayudar a entender mejor que es PSP
Un vídeo interesante y un poco diferente que explica que es PSP:
Referencias
Calero, C. (2010). Calidad del producto y proceso
software. En C. Calero, Calidad del producto y proceso software (pág.
668). Madrid: Editorial Ra-Ma.
Escobar, C. J. (08 de 06 de 2010). asprotech.blogspot.mx.
Recuperado el 06 de 02 de 2013, de Personal Software Process PSP elementos:
http://asprotech.blogspot.mx/2010/06/personal-software-process-psp-elementos.html
sábado, 22 de febrero de 2014
Infografia
Introducción
¿Que es una infografia?
Vídeos que pueden ayudarte a entender mejor lo que es una infografía
Conclusión
Actualmente existen muchas formas de expresar la información hacia otro individuo pero algunos métodos son mejores que otros, uno ellos es la infografia.
¿Que es una infografia?
La infografia es una representación visual de un texto que nos ayuda a comprender de una manera más dinámica algún tipo de información, esta es una forma de llegar más fácilmente a la persona que queremos transmitirle la información ya que el ser humano tiende a ser una persona mayormente visual para entender el mundo que lo rodea.
Ejemplos
Conclusión
La infografía es un buen método para dar a entender algo ya que la imagen complementa al texto haciendo que sea muy fácil de entender para el lector e incluso pueda generar verdadero aprendizaje.
Como opinión personal pienso que todos los libros o artículos informativos deberían tener infografías ya que en mi caso y no creo ser el único, a mi se me dificulta un poco más leer libros, revistas, periódicos etc., que no contienen imágenes por que realmente después de un tiempo de lectura se vuelve cansado y aburrido haciendo que pierda mi interés de aprender.
Para más información puedes visitar los siguientes enlaces:
Curador de Contenidos
Introducción
Como ya había mencionado en mi publicación anterior, nuestra sociedad actual vive un problema muy grave llamado infoxicación, pero para este problema existe una nueva solución llamada curación de contenidos.
¿Qué es la curación de contenidos?
Es la acción realizada por el curador de contenidos que consiste en buscar la información de Internet, revisarla y comprobar que su contenido sea adecuado(Que sea útil y fácil de entender para el lector), también comparte la información que previamente revisó.
Actualmente existen universidades que imparten el curso de Curador de Contenidos por ejemplo la Universidad Carlos III de Madrid.
Conclusión
Es importante este tipo de trabajo ya que el Internet esta en constante expansión y la información que esta albergada ahí es demasiada y de muy baja calidad en su mayoría es por ello que pienso que la curación de contenidos debería de ser una carrera e incluso hasta una materia que debería de ser impartida desde primaria para tener gente mejor preparada y evitar la infoxicación que esta en constante expansión.
Vídeos que pueden serte útiles para entender mejor este tema:
Para más información puedes visitar los siguientes enlaces:
Infoxicación
Introducción
La infoxicación o sobrecarga informativa consiste en en tener demasiada información sobre cualquier tema, produciendo la dificultad de tomar decisiones ante una situación, por ejemplo al hacer una investigación para la escuela, cuando se busca el tema en el buscador este arroja miles o millones de resultados sobre el tema esperado, como consecuencia a eso la persona que realizo la búsqueda no sabe que pagina es la que contiene la mejor información y no solo eso sino que tampoco sabe cual de esas páginas contiene resultados que sean verdaderos o respaldados por una fuente confiable.
 |
| La infoxicación nos sobresatura |
Desarrollo
Causa
La causa de este problema es el continuo crecimiento de Internet y que las personas que suben información (la mayoría) solo copian la misma información ya existente anteriormente o luego las investigaciones no tienen la calidad deseada.
Así, nos encontramos hoy con una red sobre saturada, llena de información(muchas veces inútil, errónea o incompleta y esta sigue en constante crecimiento) con publicidad molesta e inservible.
Actualmente los expertos consideran que es difícil combatir este problema.
Algunas herramientas para combatir este problema:
Rastreadores de información: Programas capaces de clasificar el contenido de una pagina.
Barras que suprimen mensajes emergentes: Complementos para el buscador que oculta la mayor parte de la publicidad (esto también beneficia al usuario a no caer en publicidad falsa que puede contener virus o publicidad que redireccione a paginas no deseadas).
Clasificación del correo electrónico: Este es un servicio que Microsoft o Google están ofreciendo ya, consiste en clasificar el contenido del correo como deseado y no deseado ayudando así al usuario a prevenir ataque informáticos o publicidad indeseada entre otras cosas.
Otra cosa que podemos hacer para no caer en la infoxicación es revisar de donde obtenemos la información y aun obteniéndola de fuentes confiables es mejor realizar nuestro propio contenido a partir de ella y no sólo copy-paste.
Conclusión
La infoxicación es un problema grave que a mi parecer va a seguir empeorando si no hacemos algo, tenemos que revisar la información existente, clasificarla y ordenarla, pero esto no parece ser así ya que solamente se esta produciendo por la mayoría de los usuarios de Internet información copiada y de baja calidad.
 |
| Esta en nuestras manos detener este problema. |
Algunos vídeos que te puede ayudar a entender más acerca de este tema:
Para mas información acerca de la infoxicación puedes revisar los siguientes enlaces:
http://es.wikipedia.org/wiki/Sobrecarga_informativa
http://franganillo.es/ansiedad.pdf
http://www.amazings.com/ciencia/noticias/041103b.html
http://www.monografias.com/trabajos6/biso/biso.shtml
http://www.infonomia.com/img/pdf/sobrevivir_infoxicacion.pdf
lunes, 27 de enero de 2014
Mapa de resumen de la unidad I
Introducción
Este es un pequeño y sencillo mapa conceptual que resume los puntos vistos en la primera unidad de Calidad en el desarrollo de software, los temas que se vieron en la unidad son los siguientes:
1.1 Conceptos básicos de calidad en la ingeniería de software
Desarrollo
Este es un pequeño y sencillo mapa conceptual que resume los puntos vistos en la primera unidad de Calidad en el desarrollo de software, los temas que se vieron en la unidad son los siguientes:
1.1 Conceptos básicos de calidad en la ingeniería de software
- ¿Qué es calidad?
- ¿Qué es una norma?
- ¿Qué es un estándar?
- ¿Que es un proceso?
- Modelos de calidad
- Institutos que regulan la calidad.
1.2 Factores y características del software
1.3 Métricas del software
 |
| Imagen realizada por mi. |
Desarrollo
El tema 1.1 nos habla de los conceptos básicos de la calidad en el desarrollo de software, también abarca el nombre de algunos estándares y nombres de organizaciones que certifican en el ámbito de calidad, con esto el alumno puede darse una pequeña idea de lo extenso que es el ámbito de calidad, no solo en el software si no mas bien de la empresa en general.
El tema 1.2 Habla sobre los factores y características de calidad en el software, en pocas palabras son atributos que debe tener el software para que sea de calidad, pero para poder medir esos atributos y asegurar que realmente se están cumpliendo se utilizan las métricas (tema 1.3) que son aquellas que van a medir una característica de algo y nos arrojan datos medibles para tener un mejor control.
Conclusión
Es importante conocer estos temas, deben de tenerse bien en claro porque una buena practica de desarrollo de software debe de aplicar la calidad con todo lo que ella conlleva. El estudio de estos temas e incluso la practica de los mismos puede parecer tedioso, porque normalmente el estudiante o el programador inexperto piensa que un proyecto es simplemente pedir los requerimientos y sentarse a programar. A lo que quiero llegar con esto es hacer ver a quien lea este articulo y este interesado en desarrollar software que utilice normas de calidad, procesos y métricas que posiblemente pueda tardado y tedioso al principio pero el resultado seguramente sera mucho mejor que solo sentarse a programar sin llevar un correcto orden y que seguramente se tenga que rehacer el programa ya que no hay evidencia de algo que mida y cumpla con las expectativas del cliente.
Bibliografías
Conclusión
Es importante conocer estos temas, deben de tenerse bien en claro porque una buena practica de desarrollo de software debe de aplicar la calidad con todo lo que ella conlleva. El estudio de estos temas e incluso la practica de los mismos puede parecer tedioso, porque normalmente el estudiante o el programador inexperto piensa que un proyecto es simplemente pedir los requerimientos y sentarse a programar. A lo que quiero llegar con esto es hacer ver a quien lea este articulo y este interesado en desarrollar software que utilice normas de calidad, procesos y métricas que posiblemente pueda tardado y tedioso al principio pero el resultado seguramente sera mucho mejor que solo sentarse a programar sin llevar un correcto orden y que seguramente se tenga que rehacer el programa ya que no hay evidencia de algo que mida y cumpla con las expectativas del cliente.
Bibliografías
Certification,
G. S. (s.f.). GLC. Recuperado el 12 de 01 de 2014, de GLC Mexico:
http://www.glc-mexico.com/glcmexico.php
eduComons.
(s.f.). eduComons. Recuperado el 12 de 01 de 2014, de eduComons:
http://212.128.130.23/eduCommons/ciencias-sociales-1/investigacion-evaluativa-en-educacion/contenidos/EFQM.pdf
ISO. (s.f.). ISO.
Recuperado el 12 de 01 de 2014, de ISO: http://www.iso.org/iso/home.html
López, A. T.
(2006). Estandares de calidad para pruebas objetivas. Colombia:
Magisterio.
Miguel, P. A.
(2009). Calidad. España: Paraninfo.
Normex.
(s.f.). Normex. Recuperado el 12 de 01 de 2014, de Normex:
http://www.normex.com.mx/
Olya. (s.f.). Olya.
Recuperado el 12 de 01 de 2014, de Certificación de Calidad Internacional:
http://www.internationalqualitycertification.com/
Calero, C.
(2010). Calidad del producto de software. En C. Calero, Calidad del
producto de software (pág. 270). España: Ra-Ma.
Velasco, J.
(2005). Introduccion a la gestion de la calidad: Generalidades y control
estadistico. Teoria y práctica. En J. V. Sánchez, Introduccion a la
gestion de la calidad (pág. 179). Colombia: Piramide.
Sommerville,
I. (2005). Ingenieria del software. En I. Sommerville, Ingenieria del
software (pág. 687). Madrid: Pearson Education.
Tuya, J.
(2007). Tecnicas cuantitativas para la gestión en la ingeniería de software. En
J. Tuya, Tecnicas cuantitativas para la gestión en la ingeniería de
software. España: Netbiblo.
WillyDEV.
(s.f.). www.willydev.net. Recuperado el 16 de 01 de 2014, de
www.willydev.net: http://www.willydev.net/descargas/WillyDEV PlaneaSoftware.Pdf
domingo, 19 de enero de 2014
Tema 1.3
¿Que es una métrica?
Una métrica es cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u otra característica o un software o sistema de información, generalmente para realizar o para la planificación de proyectos de desarrollo.
¿Para que nos sirve una métrica?
Las métricas nos ayudan a entender tanto el proceso técnico
que se utiliza para desarrollar un producto,
el producto se mide para intentar aumentar su calidad.
La
medición es muy común en el mundo de la ingeniería. Medimos potencia de
consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos
por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo
común en el mundo de la ingeniería del software. Encontramos dificultades en
ponernos de acuerdo sobre que medir y como va evaluar las medidas.
Hay varias razones para medir un
producto:
1. Para indicar la calidad del
producto.
2. Para evaluar la productividad
de la gente que desarrolla el producto.
3. Par evaluar los beneficios en
términos de productividad y de calidad, derivados del uso de nuevos métodos y
herramientas de la ingeniería de software.
4. Para establecer una línea de
base para la estimación
5. Para ayudar a justificar el
uso de nuevas herramientas o de formación adicional.
Métricas del software.
Son
las que están relacionadas con el desarrollo del software como funcionalidad,
complejidad, eficiencia.
MÉTRICAS TÉCNICAS: Se centran en
las características de software por ejemplo: la complejidad lógica, el grado de
modularidad. Mide la estructura del sistema, el cómo está hecho.
MÉTRICAS DE CALIDAD: proporcionan
una indicación de cómo se ajusta el software a los requisitos implícitos y
explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte
a los requisitos que me pide el cliente.
MÉTRICAS DE PRODUCTIVIDAD. Se
centran en el rendimiento del proceso de la ingeniería del software. Es decir
que tan productivo va a ser el software que voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA.
Proporcionan medidas e información sobre la forma que la gente desarrolla el
software de computadoras y sobre todo el punto de vista humano de la efectividad
de las herramientas y métodos. Son las medidas que voy a hacer de mi personal
que hará el sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es
para saber en qué tiempo voy a terminar el software y cuantas personas voy a
necesitar. Son medidas directas al software y el proceso por el cual se
desarrolla, si una organización de software mantiene registros sencillos, se
puede crear una tabla de datos orientados al tamaño
MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas
indirectas del software y del proceso por el cual se desarrolla. En lugar de
calcularlas las LDC, las métricas orientadas a la función se centran en la
funcionalidad o utilidad del programa. Las métricas orientadas a la función
fueron el principio propuestas por Albercht quien sugirió un acercamiento a la
medida de la productividad denominado método del punto de función. Los puntos
de función que obtienen utilizando una función empírica basándose en medidas
cuantitativas del dominio de información del software y valoraciones subjetivos
de la complejidad del software.
Conclusión
Las métricas del software son importantes ya que con ellas podemos establecer un punto de referencia de la calidad que se quiere alcanzar en el producto a desarrollar, sin ellas no se tendría una estimación de la calidad lograda en el producto o software.
Suscribirse a:
Entradas (Atom)