Elabora una síntesis de tu capítulo.
VIRTUALES DEBEN REPARTIRSE EL CAPITULO 25 AL 29.
QUIENES FALTEN DEL 30 AL 32, Y ABORDAR APENDICE 1 Y 2.
Se va a publicar la síntesis en 1, 2 o 3 comentarios, dependiendo del contenido.
No tendrán valores las síntesis en las que:
- Copiaron y pegaron.
- No explicaron
-Con errores ortográficos.
- y que no incluyan todas las paginas.
Por lo tanto:
+ deben incluir todos los temas
+ explicar el capitulo como si lo estuvieran platicando, siempre utilizando un lenguaje técnico.
+ utilizar una redacción amena y que genere interés.
Capitulo 15: Técnicas de revisión
ResponderEliminarMariana Pimentel :presencial CAP:18 APLICACIONES VENCIONALES
ResponderEliminarItzel Delgado
ResponderEliminarCapítulo 22
Valeria Citlaly Delgado Medina
ResponderEliminarCapítulo : 23
Capitulo 16 Aseguramiento de la calidad del software
ResponderEliminarAdán Alejandro Alatorre Casillas
Natalia Nicol García Hernández: capítulo 24 “CONCEPTO DE ADMINISTRACIÓN DE PROYECTO”
ResponderEliminarMaría Fernanda Padilla Díaz Capítulo 28:
ResponderEliminarAdministración del riesgo
Fátima Valeria García Rodríguez , capitulo 26 Estimación para proyectos del software
ResponderEliminarÁngel Emmanuel Monroy Baeza
ResponderEliminarCapítulo 27: Calendarización del proyecto
Este comentario ha sido eliminado por el autor.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarKevin Meza Mulgado
ResponderEliminarCapitulo 27
Calendarización de proyectos
Cipactly candelaria flores vidales
ResponderEliminarCapítulo 25
Métricas de proceso y de proyecto
Diana Ailin Ramírez Gutiérrez, capítulo 29 Mantenimiento y reingeniería
ResponderEliminarDiana Victoria Pimentel Becerra
ResponderEliminarCapítulo 20
Prueba de aplicaciones web
bien compartido
EliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarYeraldi Elizabeth Alanis Peña
ResponderEliminarCapitulo 30: mejoramiento del proceso de software
Mariela becerra becerra
ResponderEliminarCapítulo 30: mejoramiento del proceso y del software
Éste tema habla del software y de cómo vamos a ir mejorándolo. MPS qué es el MPS pues el MPS es mejoramiento del proceso del software que de eso trata el tema de cómo mejorarlo y como va evolucionando por así decirlo Éste proceso se ven cinco pasos
Eliminar1) valoración del proceso de software actual, 2) educación y capaci- tación de profesionales y gerentes, 3) selección y justifica- ción de elementos de proceso, métodos de ingeniería del software y herramientas, 4) implementación del plan MPS y 5) evaluación y afinación con base en los resultados del plan.
El software que es renovado tiene menos defectos y se reducirán las fallas entonces este capítulo nos habla pues del software y su MPS
Este comentario ha sido eliminado por el autor.
ResponderEliminarKimberly Guadalupe Alaniz Silva
ResponderEliminarCapítulo 31:Tendencias emergentes en ingeniería de software
KIMBERLY GUADALUPE ALANIZ SILVA
EliminarVIRTUAL
1°SEMESTRE
CAPÍTULO 31: TENDENCIAS EMERGENTES EN INGENIERÍA DE SOFTWARE
31.1 EVOLUCIÓN TECNOLÓGICA:Se argumenta que la evolución tecnológica es similar a la evolución biológica, pero que ocurre a un ritmo más rápido y que ocurre como resultado de realimentación positiva. El lector observará que muchas tendencias de investigación y tecnológicas nunca llegan a la madurez. La gran mayoría de las tecnologías "prometedoras" en el dominio de la ingeniería de software ya que las tecnologías de computación evolucionan a través de una " curva S ", que muestra crecimiento relativamente lento durante los años formativos nivelación conforme la tecnología llega a sus límites.
31.2 OBSERVACIÓN DE LAS TENDENCIAS EN INGENIERÍA DEL SOFTWARE: Esta tiene la posibilidad de acumularse a partir de tendencias a largo plazo en comparación y tecnológicas relacionadas. Las tendencias en investigación "están impulsadas" por las percepciones generales del estado del arte y de la práctica. Las tendencias tecnológicas ocurren cuando las tendencias en investigación se extrapolan para satisfacer necesidades industriales.
31.3 IDENTIFICACIÓN DE "TENDENCIAS BLANDAS": Tienen un conjunto de características únicas que definen la forma en que se dirigen los negocios, la dinámica que surge dentro de una compañía, los distintos conflictos de mercadeo que se aplica a los clientes locales y la interacción de cultura humana. Ya que el proceso de software puede proporcionar el marco conceptual para la ejemplificación de estos métodos y herramientas, por lo cual es muy importante identificar por qué puede ver problemas.
Finalmente la cultura humana en sí impacta la dirección de la ingeniería de software, y representan fuerzas subyacentes, causas primeras, necesidades humanas básicas, actitudes, aspiraciones, etc.
SEGUNDA PARTE
EliminarKIMBERLY GUADALUPE ALANIZ SILVA
CAPÍTULO 31
Continuando con la (identificación de tendencias blandas), en ella encontramos la 31.3.1ADMINISTRACIÓN DE LA COMPLEJIDAD: Ya que en ella se considera las interfaces para un sistema de mil millones de LOC, tanto en el mundo exterior como en otros sistemas interoperables, para la internet o sucesor y para los millones de componentes internos que deben trabajar en conjunto para hacer que opere exitosamente computación.
31.3.2 SOFTWARE DE MUNDO ABIERTO: En el se diseña para adaptarse en un entorno en cambio continuo "al autorganizarsu estructura y autoadaptar su comportamiento".
31.3.3 REQUERIMIENTOS EMERGENTES:Al comienzo de un proyecto de software, existe un a verdad obvia que se explica por igual a todo participante involucrado, además los requerimientos cambian, pero esto no es algo nuevo.
31.3.4 LA MEZCLA DE TALENTO: Se refiere a los sistemas basados en software se vuelven más complejos, y conforme la comunicación y la colaboración entre equipos locales se vuelven un lugar común por lo cual un equipo de ingeniería de software puede cambiar.
31.3.5 BLOQUES CONSTRUCTORES DE SOFTWARE: Quienes fomentan una filosofía de la ingeniería de software enfatizan la necesidad de la reutilización de código fuente, clases orientadas a objeto, componentes patrones y software COTS.
31.3. 6 CAMBIO DE PERCEPCIONES DE "VALOR": Se le considera el software de computadora , y la percepción moderna del valor cambia del valor empresarial (costo y rentabilidad) a valores de cliente.
31.3.7 FUENTE ABIERTA: El movimiento fuente abierta es un método de desarrollo para software que aprovecha el poder de la revisión de pares distribuida y la transparencia de procesos.
TERCERA PARTE DE LA SÍNTESIS
EliminarCAPÍTULO 31
KIMBERLY GUADALUPE ALANIZ SILVA
CONTINUO CON LOS SIGUIENTES SUBTEMAS:
31.4 DIRECCIONES DE LA TECNOLOGÍA: La tecnología es un nuevo proceso, un método único con una herramienta excitante, por lo cual d la ingeniería del software tiene que ver menos con la tecnología y más con las personas y su habilidad para comunicar sus necesidades y para convertir dichas necesidades en realidad. La tecnología cae en cascada a través de la comunidad de la ingeniería del software y ocurre verdaderamente un cambio muy amplio. Dentro de este subtema encontramos otros de ellos que lo componen y son:
1.- TENDENCIAS DE PROCESO: Pueden argumentarse todas las tendencias empresariales.
2.- EL GRAN DESAFÍO: Los sistemas basados en software sin duda se volverán más grandes y más complejos conforme pase el tiempo por lo cual es la tendencia innegable.
3.- DESARROLLO COLABORATIVO: Desde el inicio de cualquier proyecto de software cada participante debe compartir información a través de un desarrollo acerca de las metas y objetivos básicos.
4.- INGENIERÍA DE REQUERIMIENTOS: Este requiere en una adquisición, elaboración, negociación, especificación y validación.
5.- DESARROLLO DE SOFTWARE IMPULSADO POR MODELO: En este nos habla que los ingenieros de software se aferran a la abstracción virtualmente en cada paso de proceso de ingeniería de software.
6.- DISEÑO POSMODERNO: Se trata de comprender las tendencias en el diseño del software.
7.- DESARROLLO IMPULSADO POR PRUEBAS: Los requerimientos impulsan el diseño y desarrollo para el cimiento de una construcción.
CUARTA PARTE DE LA SÍNTESIS
EliminarCAPÍTULO 31
KIMBERLY GUADALUPE ALANIZ SILVA
Continuo con los subtemas:
31.5 TENDENCIAS RELACIONADAS CON HERRAMIENTAS: Cada año se introducen cientos de herramientas de ingeniería del software de grado industrial, por lo cual la mayoría las aportan los proveedores de herramientas, quienes afirman que su herramienta mejorará la administración del proyecto, el análisis de requerimientos, el modelado de diseño, etc. Lo cual en este subtema podemos encontrar otros de ellos que la componen y son:
1.- HERRAMIENTAS QUE RESPONDEN A TENDENCIAS BLANDAS: Es la necesidad de abministrar la complejidad, acomodar requerimientos emergentes y establecer modelos de procesos, etc.
2.- HERRAMIENTAS QUE ABORDAN TENDENCIAS TECNOLÓGICAS: Esto se logra cuando los participantes trabajan como un equipo. Por lo cual las herramientas tecnológicas es la creación de un conjunto de herramientas que da apoyo al desarrollo impulsado por modelo.
FINALMENTE DE LA SÍNTESIS ES EL RESUMEN
31.6 RESUMEN: Este capítulo 31, nos habla sobre las tendencias que tienen efecto sobre la tecnología de ingeniería del software ya que provienen de las áreas de negocios, organizacional, mercado y cultura. Lo cual dichas tendencias blandas pueden guiar la dirección de la investigación.
Ya que conforme se introduce nueva tecnología, se avanza a través de un ciclo de vida, por lo cual el grado en el que cualquier tecnología de software gana adopción extensa y está ligado a su habilidad para abordar los problemas impuestos por las tendencias blandas y duras.
Finalmente los entornos de herramientas responderán a una necesidad creciente de comunicación y colaboración ya que al mismo tiempo integran soluciones puntuales específicas de dominio que pueden cambiar la naturaleza de las actuales tareas de la ingeniería de software.
Evelyn Natalia Rivera González.
ResponderEliminarcapítulo 32: COMENTARIOS FINALES.
Andrea Paulina Hernández Méndez
ResponderEliminarCapítulo 29: mantenimiento y reingenieria
Jonathan Yahir Cervantes Suarez.
ResponderEliminarApéndice 1 : introducción de UML
Síntesis De La Introducción De UML.
EliminarQue significados tiene la abreviación (UML),Es el Lenguaje Unificado de Modelado y sirve para visualizar, especificar, construir y documentar los artefactos de un sistema de software intensivo un ejemplo:
Los arquitectos de edificios crean planos para que los use una compañía constructora.
Los creadores de la UML, Grady Booch, Jim Rumbaugh e Ivar Jacobson desarrollaron el UML a mediados de los años noventa del siglo pasado con mucha realimentación de la comunidad de desarrollo de software.
Existe varios UML por ejemplo el UML 2.0 este proporciona 13 diferentes diagramas para el uso de modelado de software y su función es analizar los diagramas de clase en caso de uso de secuencia, comunicación, actividad y estado.
Existen muchas características opcionales en diagramas de UML ofrece dichas opciones de modo que pueda expresar todos los aspectos importantes de un sistema tiene la flexibilidad para suprimir aquellas partes del diagrama que no son relevantes para el aspecto que se va a modelar.
Las divisiones que conforma la UML
EliminarDiagramas De Clases.
UML proporciona una visión estática o de estructura de un sistema, sin tener que mostrar la naturaleza dinámica de las comunicaciones entre los objetos de
las clases, existen varios diagrama que son las cajas su función es que son íconos utilizados para representar clases e interfaces, cada caja se divide en partes horizontales ,primero la parte superior que contiene el nombre de la clase, segundo la sección media menciona sus atributos y por ultimo la tercera sección del diagrama contiene las operaciones o comportamientos de la clase.
Diagramas De Implementación.
Su función es la estructura de un sistema de software y es útil para mostrar la distribución física del sistema, entre plataformas de hardware y entornos de ejecución.
Diagramas De Uso De Caso.
Ayudan a determinar la funcionalidad y características del software desde la perspectiva del usuario, para proporcionarle una aproximación de tal manera que
funcionen.
Diagramas De Secuencia.
Su función es mostrar las comunicaciones dinámicas entre objetos durante la ejecución de una tarea.
Diagramas De Comunicación.
Indica el orden temporal de las comunicaciones pero enfatiza las relaciones entre
los objetos y clases en lugar del orden temporal.
Diagramas De Actividades.
Este diagrama muestra el comportamiento dinámico de un sistema o de parte de
un sistema a través del flujo de control entre acciones que realiza el sistema.
Diagramas De Estado.
este UML modela los estados de objetos y sus acciones que se realizan dependiendo de dichos estados y las transiciones entre los estados del los objetos
Mariam Delgado Trujillo
ResponderEliminarCapítulo 23: Métricas de producto
Laura Isela Lara Delgado
ResponderEliminarCapitulo 27: calendarización de proyectos
Viernes 24 de Septiembre de 2021
EliminarYurécuaro Michoacán,
Laura Isela Lara Delgado
Capitulo 27: Calendarización de proyectos
Este capitulo habla sobre que un joven en los años 90 fue elegido para que hiciera o escribiera un programa de computadoras para la aplicación de fabricación automatizada.
Qué es?
Tiene que crear una red de tareas de ingeniería de software que le permitirá concluir el trabajo a tiempo, una vez creada la red, deberá asignar resposabilidades para cada tarea, asegurarse que se realizen todas ellas y adaptar la red conforme los riesgos que habrá cuando se convierta en realidad.
Quién lo lleva acabo?
Los gerentes de proyecto de software que usan la información solicitada a los ingenieros de software.
Cuál es el producto final?
Se produce el calendario del proyecto y la información relacionada.
Cómo me aseguro de que lo hice bien?
La Calendarización adecuada requiere que todas las tareas aparezcan en la red, el esfuerzo y la calendarización se asignen de manera inteligente a cada tarea, las interdependencias entre tareas se indiquen de manera adecuada, se asignen los recursos para el trabajo que se va a realizar y se proporcionen hitos cercanamente espaciados de modo que pueda darse seguimiento al progreso.
Es importante hacer una calendarización adecuada para que nuestro trabajo este bien hecho.
Sin importar el modelo que se elija, el trabajo que realiza un equipo de software se logra a través de un conjunto de tareas que permiten definir, desarollar y apoyar el software de computadora.
Los proyectos de desarrollo de concepto inician cuando debe explotarse el potencial para alguna nueva tecnologia.
Definición de una red de tareas:
Las tareas y subtareas individuales tienen independencias en función de una secuencia, además, cuando más de una persona está involucrada en un proyecto de ingeniería de software, es probable que las actividades y tareas de desarrollo se realicen en paralelo. Cuando esto ocurre, las tareas concurrentes deben coordinarse de modo que se complementen en el momento en el de las tareas posteriores requieran sus productos operativos.
https://docs.google.com/document/d/1ewpSgoT612EKll8xldBFv6hfE5-55qANT1cPHsxUhkU/edit?usp=drivesdk
ResponderEliminarhttps://docs.google.com/document/d/1nKeSl2w8tq-0tH36ZMGJ6SpjbcG-bHNxQRWqzQl7x8A/edit?usp=drivesdk
ResponderEliminarhttps://docs.google.com/document/d/1R3QarBpTJG1Sx6LYIa_tYicLnhT4cIcyLUmxLKIQP24/edit?usp=drivesdk
ResponderEliminarhttps://drive.google.com/file/d/1IcFbLOtQlz1hPJThHA5uWRKG_T9Z0PIN/view?usp=sharing
ResponderEliminarhttps://drive.google.com/file/d/1fD0vwszccbOZJhSmY1vD6okKhrzCkkxX/view?usp=sharing
ResponderEliminarAct. 1 de 5
EliminarPublicó todo
Diana Victoria Pimentel Becerra
ResponderEliminarCapítulo 20
Existe una urgencia que siempre impregna un proyecto web. Los participantes fuerzan para poner la webapp en línea.
Los modelos de requerimientos y de diseño no pueden probarse en el sentido clásico: por ello,
el equipo debe realizar revisiones técnicas y pruebas ejecutables. La intención es
descubrir y corregir errores antes de que la webapp esté disponible para sus usuarios finales.
Los conceptos de pruebas para aplicaciones web prueban el proceso de ejecución del software con la intención de encontrar y corregir los errores.
Para entender los objetivos de las pruebas dentro de un contexto de ingeniería web, debe
considerar las muchas dimensiones de calidad de la webapp.
En el contexto de esta discusión,
se consideran las dimensiones de calidad que son particularmente relevantes en cualquier análisis de las pruebas de la webapp.
La calidad se incorpora en una aplicación web como consecuencia de un buen diseño. Se evalúa
aplicando una serie de revisiones técnicas que valoran varios elementos del modelo de diseño
y un proceso de prueba que se estudia a lo largo de este capítulo.
La seguridad se prueba al valorar las vulnerabilidades potenciales e intenta explotar cada
una. Cualquier intento de penetración exitoso se estima como un fallo de seguridad.
La función se prueba para descubrir errores que indican falta de conformidad con los
requerimientos del cliente. Cada función de la webapp se valora en su corrección, inestabilidad y conformidad general con estándares de implantación adecuados.
Puesto que muchos tipos de pruebas de webapps descubren problemas que se evidencian primero en el lado del cliente con frecuencia se
ve un síntoma del error, no el error en sí.
bien compartido
EliminarDiana Victoria Pimentel Becerra
ResponderEliminarCapítulo 20
La estrategia para probar webapps adopta los principios básicos de todas las pruebas de software y aplica una estrategia y las tácticas que se recomendaron para los sistemas orientados a objetos.
El uso de la palabra planificación (en cualquier contexto) es un anatema para algunos desarro-
lladores web que no planifican; sólo arrancan, con la esperanza de que surja una webapp asesina. Un enfoque más disciplinado reconoce que la planificación establece un mapa de ruta para todo el trabajo que va después.
El proceso de prueba de webapps comienza con pruebas que ejercitan la funcionalidad del contenido y la interfaz que son inmediatamente visibles para el usuario final. Los errores en el contenido de la webapp pueden ser tan triviales como errores tipográficos
menores o tan significativos como información incorrecta, organización inadecuada o violación de leyes de la propiedad intelectual. La prueba de contenido combina tanto revisiones como generación de casos de prueba ejecutables.
Las webapps modernas hacen mucho más que presentar objetos de contenido estáticos. En
muchos dominios de aplicación, la webapp tiene interfaz con sofisticados sistemas de gestión
de base de datos y construyen objetos de contenido dinámico que se crean en tiempo real,
usando los datos adquiridos desde una base de datos.
https://docs.google.com/document/d/1--QquRdwEqH1WiP3ZRsfcRxgwcTADGhbPSGux9sNklY/edit
ResponderEliminarSintesis del capitulo 30
ResponderEliminar"MEJORAMIRNTO DEL PROCESO DE SOFTWARE"
Pues el mejoramiento del proceso de software abarca un conjunto de actividades que conducirán a un mejor proceso de software de mayor calidad, el personal que impulsa el MPS es quien hace el mejoramiento del proceso de software, algunas organizaciones de software conforme trabajan sus practicas de ingeniería del software y deben abordar las debilidades en sus procesos existentes y intentan mejorar su enfoque para él trabajo de software, el resultado final es un proceso de software mejorado que conduce a software de mayor calidad, el software que produce su organización se entrega con menos defectos
¿Que es MPS? Es el termino de mejoramiento del proceso de software y implica muchas cosas, la estrategia de MPS transforma el enfoque existente sobre el desarrollo de software en algo que es más enfocado, aunque una organización puede elegir un enfoque relativamente informal del MPS, su enfoque consiste en enfatizar los métodos de valoración y examinar un conjunto bien definido de características que le permiten determinar si el proceso muestra calidad, un modelo de madurez se aplica dentro del contexto de un marco conceptual MPS, la parte dura del MPS no es establecer las características que definen un proceso de software de alta calidad.
El CMMI se desarrollo y actualizo por partes del software, el CMMI representa un metamorfosis de proceso en dos formas diferentes: 1 como modelo continuo y 2 como un modelo en etapas, la CMMI define cada área de proceso en términos de metas específicas
EliminarUn proceso de software no triunfara sin un personal de software talentoso y motivado. El modelo de madurez de capacidad de personal es un mapa de caminos para implementar practicas que mejoran de manera continua la capacidad de la fuerza de trabajo de una organización. SPICE: una iniciativa internacional para dar apoyo a la valoración de proceso ISO
ISO/IEC 15504 para valoración de proceso de software
BOOTSTRAP:un marco conceptual MPS para organizaciones pequeñas y medianas que se adecuan
El MPS representa un trabajo duro y requiere inversión sustancial de dinero y de personal, quienes impulsan MPS arguyen que un proceso de software mejorado conducirán a calidad de software mejorada
El trabajo MPS de las dos décadas que son: los marcos conceptuales y los modelos que se desarrollaron
Un marco conceptual de mejoramiento del proceso de software define las características que debe presentar si debe lograr un proceso de software efectivo, un modelo de madurez de proceso proporciona un indicio global de la madurez del proceso, unos de los elementos clave de cualquier plan MPS son la educación y la capacitación.
https://drive.google.com/file/d/1Vhi7dYZnpvjho46AItrbLGJAAdiViCu8/view?usp=sharing
ResponderEliminarBien compartido
Eliminarhttps://drive.google.com/file/d/1pBToJ2cVR54rCYRULr7jUPve5cEdZm-5/view?usp=sharing
ResponderEliminarhttps://drive.google.com/file/d/1IqWav3kWFrEzfnN3sV4PdY8RGZnP7hs7/view?usp=drivesdk
ResponderEliminarhttps://drive.google.com/file/d/1cUBQeeDdmsmDeDK7EFcnO6sx16kNvdVW/view?usp=sharing
ResponderEliminarKevin Meza Mulgado
https://drive.google.com/file/d/1hRYZ8KezWyGEemwAX-ETdhYp0TKz8_2K/view?usp=sharing
ResponderEliminarhttps://drive.google.com/file/d/1v5XyZ_ld7cdGgEQi2MrzhyzIKGCSu2_r/view?usp=sharing
ResponderEliminarMaría Fernanda Padilla Díaz
ResponderEliminarYurécuaro Michoacán 24 de Septiembre
Preparatoria "Lázaro Cárdenas"
SÍNTESIS
CAPÍTULO 28
"Administración del riesgo"
En este capítulo nos hablan sobre las maneras de reparar, de analizar o de sobrellevar un riesgo ya que todos los programas proyectos y elementos de un software tienden a tener un 70% de probables riesgos durante los procesos.
Por ejemplo: En el libro acerca de administración y análisis de riesgos de Robert Charette presenta una definición conceptual de riesgo:
Primero, el riesgo se preocupa por los acontecimientos futuros.
Ayer y hoy están más allá de la preocupación activa, pues ya cosechamos lo que previamente se sembró por nuestras acciones pasadas.
La pregunta tiene que ver, por tanto si es que podemos, al cambiar nuestras acciones de hoy, crear una oportunidad con una situación diferente para poder mejorar a nosotros mismos en el mañana.
Después del análisis de cómo llevar o lidiar con esto tenemos dos puntos importantes para conocer parte por parte cada una de estas cosas ya que forma parte de un proceso al llevar un registro de los riegos que puedan ocurrir.
¿Qué es?
El análisis y la administración del
riesgo son acciones que ayudan al equipo de software a entender y manejar las dudas. Muchos problemas pueden desordenar un proyecto de software.
Un riesgo es un problema potencial:
puede ocurrir, puede no ocurrir. Pero, sin importar el resultado realmente es una buena idea identificarlo, valorar su
probabilidad de ocurrencia, estimar su impacto y establecer un plan de contingencia para el caso de que el problema realmente ocurra.
¿Quién lo hace?
Todos los involucrados en el proceso de software (gerentes, ingenieros de software y otros interesados) participan en el análisis y la administración del
riesgo.
¿Por qué es importante?
Un ejemplo claro está en la consigna de los boy scouts:
“Estar preparados”. El software es una empresa difícil. Muchas cosas pueden salir mal y no sabemos con que frecuencia lo puedan hacer.
Por esta razón es que debemos estar preparados, comprender los riesgos y tomar medidas
proactivas para evitarlos o manejarlos son elementos clave
de una buena administración de proyecto de software.
●Como una conclusión dejaré un documento con imágenes sobre los temas para analizar un riesgo ya que para esto se necesitan hacer diagramas, tablas en las que se explica de una mejor manera todas las visualizaciones de posibles fallas/riesgos.
Eliminar●IDENTIFICACIÓN DE RIESGOS: Identificarse solamente por quienes tienen clara comprensión de la tecnología, el personal y
el entorno específico del software que se construye. Para identificar los riesgos específicos del producto, debemos examinar el plan del proyecto y desarrollar
respuesta a la siguiente pregunta:
¿Qué características especiales de este producto pueden amenazar el plan del proyecto?
Un método para identificar riesgos es crear una lista de verificación de riesgos. La lista de verificación puede usarse para identificación del riesgo y así enfocarse sobre algún subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:
• Tamaño del producto: riesgos asociados con el tamaño global del software que se va a construir o a modificar.
• Impacto empresarial: riesgos asociados con restricciones impuestas por la administración o por el mercado.
• Características de los participantes: riesgos asociados con la sofisticación de los participantes y con la habilidad de los desarrolladores para comunicarse con los participantes
en forma oportuna.
• Definición del proceso: riesgos asociados con el grado en el que se definió el proceso de software y la manera como se sigue por parte de la organización desarrolladora.
• Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas por usar para construir el producto.
• Tecnología por construir: riesgos asociados con la complejidad del sistema que se va a construir y con lo “novedoso” de la tecnología que se incluye en el sistema.
• Tamaño y experiencia del personal: riesgos asociados con la experiencia técnica y de proyecto global de los ingenieros de software que harán el trabajo.
https://drive.google.com/file/d/14iRaBA7sO18mqjjqsp1rYkOgBlVaHEm5/view?usp=drivesdk
●ESTRATEGIAS REACTIVAS DE RIESGO FRENTE
EliminarA ESTRATEGIAS PROACTIVAS DE RIESGO: La estrategia que se considera más inteligente para la administración del riesgo es ser proactivo.
Una estrategia proactiva comienza mucho antes de iniciar el trabajo técnico. Los riesgos potenciales se identifican, su probabilidad e impacto se valoran y se clasifican por importancia. Luego, el equipo de software establece un plan para gestionar el riesgo.
El objetivo principal es evitarlo, pero, dado que no todos los riesgos son evitables, el equipo trabaja para
desarrollar un plan de contingencia que le permitirá responder en forma controlada y efectiva. A lo largo del resto de este capítulo se estudia una estrategia proactiva de gestión del riesgo dejándonos varios métodos para revisar, realizar y mejorar.
https://drive.google.com/file/d/1wWBPEFRRVvdZFNNA8CBQPVKJpRyrV1xw/view?usp=drivesdk
ResponderEliminarKarely vianey lara gamiño
ResponderEliminarEstrategias de prueba de software
¿Qué es? La prueba comienza “por lo
pequeño” y avanza “hacia lo grande”. Es decir que las
primeras etapas de prueba se enfocan sobre un solo componente o un pequeño grupo de componentes relacionados y se aplican pruebas para descubrir errores en los
datos y en la lógica de procesamiento que se encapsularon
en los componentes. Después de probar éstos, deben integrarse hasta que se construya el sistema completo. En este
punto, se ejecuta una serie de pruebas de orden superior
para descubrir errores en la satisfacción de los requerimientos del cliente. Conforme se descubren, los errores
deben diagnosticarse y corregirse usando un proceso que
se llama depuración El software se prueba para descubrir errores que se cometieron de manera inadvertida conforme se diseñó y construyó. Pero, ¿cómo se realizan las pruebas? ¿Debe realizarse un plan formal para las mismas? ¿Debe probarse el programa completo, como un todo, o aplicar pruebas sólo sobre una pequeña parte de él? ¿Debe volverse a aplicar las pruebas que ya se realizaron mientras se agregan nuevos componentes a un sistema grande? ¿Cuándo debe involucrarse al cliente? Éstas y muchas otras preguntas se responden cuando se desarrolla una estrategia de prueba de software? El software se prueba para descubrir errores que se cometieron de manera inadvertida conforme se diseñó y construyó. Pero,
¿cómo se realizan las pruebas? ¿Debe realizarse un plan formal para las mismas? ¿Debe probarse el
programa completo, como un todo, o aplicar pruebas sólo
sobre una pequeña parte de él? ¿Debe volverse a aplicar
las pruebas que ya se realizaron mientras se agregan
nuevos componentes a un sistema grande? ¿Cuándo debe
involucrarse al cliente? Éstas y muchas otras preguntas se
responden cuando se desarrolla una estrategia de prueba
¿Quién lo hace? El gerente de proyecto, los ingenieros de software y los
especialistas en pruebas desarrollan una estrategia para probar el software ¿Quién lo hace? El gerente de proyecto, los ingenieros de software y los especialistas en pruebas desarrollan una estrategia para probar el software.
ResponderEliminar¿Por qué es importante? Con frecuencia, la prueba
requiere más esfuerzo que cualquiera otra acción de ingeniería del software. Si se realiza sin orden, se desperdicia
tiempo, se emplea esfuerzo innecesario y, todavía peor, es
posible que algunos errores pasen desapercibidos. Por
tanto, parecería razonable establecer una estrategia sistemática para probar el software
¿Cuáles son los pasos? La prueba comienza “por lo pequeño” y avanza “hacia lo grande”. Es decir que las primeras etapas de prueba se enfocan sobre un solo componente o un pequeño grupo de componentes relacionados y se aplican pruebas para descubrir errores en los datos y en la lógica de procesamiento que se encapsularon en los componentes. Después de probar éstos, deben integrarse hasta que se construya el sistema completo. En este punto, se ejecuta una serie de pruebas de orden superior para descubrir errores en la satisfacción de los requerimientos del cliente. Conforme se descubren, los errores deben diagnosticarse y corregirse usando un proceso que se llama depuración ¿Cuáles son los pasos? La prueba comienza “por lo
pequeño” y avanza “hacia lo grande”. Es decir que las
primeras etapas de prueba se enfocan sobre un solo componente o un pequeño grupo de componentes relacionados y se aplican pruebas para descubrir errores en los
datos y en la lógica de procesamiento que se encapsularon
en los componentes. Después de probar éstos, deben integrarse hasta que se construya el sistema completo. En este
punto, se ejecuta una serie de pruebas de orden superior
para descubrir errores en la satisfacción de los requerimientos del cliente. Conforme se descubren, los errores
deben diagnosticarse y corregirse usando un proceso que
se llama depuración
¿Cuál es el producto final? Una Especificación pruebas documenta la forma en la que el equipo de software prepara la prueba al definir un plan que describe una estrategia procedimiento con pasos de prueba específicos y los tipos de pruebas que se realizarán.
¿Cómo me aseguro de que lo hice bien?
la Especificación pruebas antes de realizar las pruebas, es
posible valorar si están completos los casos de prueba y las
tareas de la misma. Un plan de prueba y procedimientos
efectivos conducirán a la construcción ordenada del software y al descubrimiento de errores en cada etapa del
proceso de construcción.
La revisión en general es dar un repaso u supervisión a algo en específico, como un trabajo, un proceso, etc. Pero en la informática es principalmente usada para revisar que la base de algún programa esté correctamente desarrollada. Y lógicamente hay muchas técnicas para revisar estos conceptos; que estos no contengan errores o problemas desarrollables
ResponderEliminarEn el desarrollo del software aplicar distintas técnicas de desarrollo, las cuales purifican y hacen que se obtenga un mejor resultado. Todos los seres humanos cometen errores, puede ser que pase por alto algún dato que provoque que el resultado salga con deformidades. Y las distintas técnicas para revisar y localizar errores para ser corregidos.
Lógicamente esto se debe realizar antes de que sea entregado a los usuarios finales, los que deben realizar la técnica de revisión son los mismos desarrolladores que la hacen. La técnica de revisión se divide en seis etapas distintas: Planeación, preparación, estructurar la reunión, resaltar los errores, hacer las correcciones (fuera de la revisión) y verificar que las correcciones se hayan hecho en forma apropiada. A final de esto queda como resultado una lista de errores base, los cuales ya descubiertos y localizados es más fácil corregirlos y darles soporte, para que al final quede un software de calidad y sin errores.
El objetivo de cualquier revisión técnica es detectar errores y descubrir aspectos que tendrían un efecto negativo sobre el software a desarrollar. Cuanto antes se descubra y corrija un error, es menos probable que se extienda a otros productos del trabajo de ingenieria, software y amplificarlo, lo que supondría un mayor esfuerzo para corregirlo.
Para determinar si las actividades de control de calidad están funcionando, deben determinarse varias métricas. Estos se enfocan en el esfuerzo requerido para realizar la revisión y los tipos y gravedad de los errores descubiertos durante la revisión. Una vez que se recopilan las métricas, se utilizan evaluar la efectividad de las revisiones realizadas. Los datos de la industria indican que las revisiones tienen un alto retorno de la inversión.
Un modelo de referencia para la formalidad de la revisión identifica los roles de las personas, planificación y preparación, estructura de la reunión, enfoque de corrección y verificación como las características que indican el grado de formalidad con que se realiza una revisión.
Las revisiones informales son casuales por naturaleza, pero se pueden utilizar de manera
eficaz para detectar errores. Las revisiones formales están más estructuradas y tienen más
probabilidades de dar como resultado un software de alta calidad.
Las revisiones informales caracterizan por una planificación preparación minimas, poca registro desarrollo. parte de esta categoría
Una revisión técnica formal es una reunión simplificada que demostrado ser extremadamente eficaz para detectar errores. Los recorridos inspecciones establecen roles definidos para cada revisor, estimulan planificación preparación anticipada, requieren aplicación de revisión definidas orden de mantener registros hacer informes. comentarios de usuarios centralmente mejor forma de encontrar posteriormente percepción desarrollador.
CAPITULO 22: ADMINISTRACION DE LA
ResponderEliminarCONFIGURACION DEL SOFTWARE
En este capítulo se habla de que cuando se construye software de computadora,
ocurren cambios. Y puesto que ocurren, es necesario administrarlos de manera
efectiva. También es importante distinguir lo que es un apoyo y una administración
del software, ya que el apoyo son las actividades de la ingeniería que ocurren
después de que es entregado al cliente en cambio la administración son actividades
de rastreo y control cuando se comienza el proyecto del software.
Como ya fue mencionado esta administración son actividades diseñadas el cambio
de los productos ya que pueden cambiar, esta administración también puede ser el
control de los cambios hechos y el reporte de los cambios que ya se realizaron. En
este proceso se llegan a crear posiciones de apoyo para administrar el proceso ACS
(administración de la configuración del software)
Este proceso de administración es muy importante ya que si esto no se hace es muy
fácil de que se ocasione un problema ya que los cambios se descontrolaron y el
proyecto del software no estará bien estructurado y la calidad de este no será buena
y no será entregada en la fecha indicada por eso es esencial que este proceso sea
bien estructurado.
Cuando el software sea elaborado se debe identificar este software. Ya que esto
está hecho se hacen mecanismos para el control de los cambios para así
asegurarse que la calidad del software está bien y no sucedió nada con los cambios
y las personas que lo reciban sepan de estos y así no sea complicado para ellos y
puedan realizar reportes.
Una de sus metas principales es que sea más fácil de que los cambios puedan
acomodarse y así reducir el esfuerzo que se utiliza al momento de realizar cambios
en el software.
La salida del proceso se divide en tres partes: 1) programas de cómputo, 2)
productos de trabajo que describen los programas, 3) datos o contenido. La ACS se
desarrollaron para administrar el cambio a lo largo de la vida del software al igual
que puede verse como algo que caracterice bien la calidad del software y de lo que
se aplique a lo largo del software.
Esta configuración se compone de un conjunto de objetos llamados ítems de
configuración del software, que se producen de una actividad de ingeniería del
software (ICS). Ya que se desarrolle el objeto de configuración se convierte en línea
de referencia estos dan el resultado de la creación de dicho objeto. El control de
versiones es un conjunto de procedimientos que administran el uso de estos
objetos.
correcto, si cumplió
EliminarFátima Valeria García Rodríguez
ResponderEliminarYurécuaro Michoacán 24 de septiembre
CAPITULO 26 Estimación para proyectos del software
La planificación se trata de que requiere adoptar un compromiso inicial aun cuando es probable que este en compromiso y que resulte erróneo siempre debemos de hacer estimaciones donde vamos a ver hacia un futuro y que se acepte cierto grado de incertidumbre habitual.
Las estimaciones son un arte y una ciencia, es tan importante una acción que no necesita realizarse de forma azarosa existen técnicas útiles para la estimación del tiempo y esfuerzo.
Las estimaciones de recursos, costo y calendario para un esfuerzo de ingeniería requieren experiencia que es el acceso a una buena información histórica .La descomposición del problema, Un importante enfoque de la estimación y que se vuelve más difícil porque el refinamiento de los elementos del problema todavía puede ser formidable.
Nos dice que la información histórica tiene fuerte influencia sobre los riesgos de estimación. El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones pero no debe volverse obsesivo acerca de la estimación los modernos enfoques de ingeniería del software como modelos de proceso evolutivos.
26.2 Proceso de planificación del proyecto
El objetivo es proporcionar un marco conceptual que permita al gerente hacer estimaciones razonables de recursos, costo y calendario además las estimaciones deben intentar definir los escenarios de mejor caso y peor caso de modo que los resultados del proyecto puedan acortarse.
26.3 Ámbito y factibilidad del software
Este describe las funciones y características que se entregan a los usuarios finales
. Los usuarios finales desarrollan un conjunto de casos de uso
Las funciones descritas en el enunciado del ámbito se evalúan en algunos casos se desglosan para proporcionar como más a detalle y comience el proceso de la estimación.
26.4 Recursos
Esta es la segunda tarea que son los recursos requeridos para lograr el esfuerzo del desarrollo del software.
26.4.1 Recursos humanos
El planificador comienza por evaluar el software y selecciona las habilidades requeridas para completar el desarrollo.
Este comentario ha sido eliminado por el autor.
EliminarEste comentario ha sido eliminado por el autor.
Eliminar26.4.2 Recursos del software reutilizables
EliminarEl software se basa en componentes ISBC que ponen en énfasis en la reusabilidad que es la creación y reutilización de bloques constructores del software que son llamados componentes y se dividen por componentes comerciales que pueden adquirirse de una tercera parte o proyecto anterior . También están los componentes de experiencia completa que son especificadores, diseños, códigos o datos de pruebas existentes.
Componentes de experiencia parcial donde se construye el proyecto en cuestión. Y componentes nuevos que son el equipo de software debe construir para el proyecto en cuestión.
26.4.3 Recursos ambientales
Soporta un proyecto de software con frecuencia que es llamado entorno de ingeniería de software
26.5 Estimación de proyectos del software
Nunca será una ciencia exacta porque hay demasiadas variables como humanas, técnicas, ambientales y políticas y que pueden afectar al costo final del software y al esfuerzo aplicado para su desarrollo.
26.6 Técnicas de descomposición
La estimación es una forma de resolución de problemas y a veces el problema para resolver es decir desarrollar la estimación de un costo y esfuerzo para un proyecto de software es muy complejo como para considerarse.
26.7 Modelos de estimación Empíricos
Un modelado de estimación del software usa formulas empíricamente inferidas para predecir su esfuerzo como una función de LOC o PF .
Los datos empíricos soportan la mayoría de los modelos de estimación se infiere de una muestra limitada de proyectos por eso ningún modelo de estimación es adecuado para toda clase de software y se debe calibrar para que refleje las condiciones locales el modelado debe probarse aplicando los datos recopilados de los proyectos completados.
26.7.2 El modelo COCOMO II
Se llama así por modelo constructivo de costos este se convirtió en uno de los modelos de estimación de costo más utilizado y estudiado en la industria .se fue hasta un modelo más exhaustivo.
26.8 Estimación para proyectos orientados a objetos
1Desarrollar estimaciones usando descomposición de esfuerzo, Análisis PF y cualquier otro método que sea aplicable para aplicaciones convencionales.
2. Usar el modelo de requisitos y desarrollar casos de uso así mismo determinar un conteo.
3. Determinar el número de clases clave que son llamadas clases de análisis
4. Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicador para clases de apoyo.
5. Multiplicar el número total de clases
6. Comprobación cruzada de la estimación basada en clase.
26.10 La decisión de hacer
Los pasos involucrados en la adquisición del software se definen por lo crucial del software que se va en comprar y por el costo final esta decisión de hacer toma con base la fecha de entrega, el costo de adquisición, el costo de apoyo exterior.
En resumen de lo que vimos en todo este capitulo el planificador de proyectos del software debe de tener 3 cosas importantes que son cuanto tardara ,cuando esfuerzo deberá tener , y cuantas personas van a estar involucradas además el planificador sirve para predecir los recursos del software y hardware .
Las estigmatizaciones se usan al menos dos de las técnicas que es el numero de LOC ,Valores seccionados dentro del dominio , numero de casos de uso , numero de personas . También algo muy importante que nos comentaron en este capitulo sobre el tema es que la estimación nunca va a ser exacta pero si es una buena combinación de datos históricos.
CAPITULO 18: PRUEBAS - APLICACIONES
ResponderEliminarEste dice que las pruebas requieren que el desarrollador deseche nociones preconcebidas sobre lo “correcto” del software recién desarrollado y luego trabajen duro para diseñar casos de prueba a fin de “romper” el software Existe el mito de que no habría errores pero ese es el mito ya que claro que tenemos bastantes errores En este capítulo se estudian técnicas para el diseño de casos de prueba de software para aplicaciones convencionales. Este diseño se enfoca en un conjunto de técnicas para la creación de casos de prueba que satisfacen los objetivos de prueba globales y las estrategias de pruebas.
18.1 FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE
Sus fundamentos son 8 y son los siguientes:
COMPROBABILIDAD: La comprobabilidad del software significa simplemente saber con cuánta facilidad puede probarse [un programa de cómputo].” Las siguientes características conducen a software comprobable.
OPERATIVIDAD: Está dice que “Mientras mejor funcione, más eficientemente puede probarse.” Si un sistema se diseña e implementa teniendo como objetivo la calidad, relativamente pocos errores bloquearán la ejecución de las pruebas, lo que permitirá avanzar en ellas sin interrupciones.
OBSERVABILIDAD: Está “Lo que ve es lo que prueba.” Las entradas proporcionadas como parte de las pruebas producen distintas salidas. Los estados del sistema y las variables son visibles o consultables durante la ejecución. La salida incorrecta se identifica con facilidad. Los errores internos se detectan y se reportan de manera automática.
ResponderEliminarCONTROLABILIDAD: “Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.” Todas las salidas posibles pueden generarse a través de alguna combinación de entradas, y los formatos de entrada/salida (E/S) son consistentes y estructurados.
DESCOMPONIBILIDAD. “Al controlar el ámbito de las pruebas, es posible aislar más rápidamente los problemas y realizar pruebas nuevas y más inteligentes.” El sistema de software se construye a partir de módulos independientes que pueden probarse de manera independiente.
SIMPLICIDAD: “Mientras haya menos que probar, más rápidamente se le puede probar.” El programa debe mostrar simplicidad funcional (por ejemplo, el conjunto característico es el mínimo necesario para satisfacer los requerimientos); simplicidad estructural (la arquitectura es modular para limitar la propagación de fallos) y simplicidad de código (se adopta un estándar de codificación para facilitar la inspección y el mantenimiento).
ESTABILIDAD: “Mientras menos cambios, menos perturbaciones para probar.” Los cambios al software son raros, se controlan cuando ocurren y no invalidan las pruebas existentes. El software se recupera bien de los fallos.
COMPRENSIBILIDAD: “Mientras más información se tenga, se probará con más inteligencia.” El diseño arquitectónico y las dependencias entre componentes internos, externos y compartidos son bien comprendidos. La documentación técnica es accesible al instante, está bien organizada, es específica, detallada y precisa. Los cambios al diseño son comunicados a los examinadores.
18.2 VISIONES INTERNA Y EXTERNA DE LAS PRUEBAS
ResponderEliminarCualquier producto sometido a ingeniería (y la mayoría de otras cosas) pueden probarse en una de dos formas: al conocer la función específica que se asignó a un producto para su realización, pueden llevarse a cabo pruebas que demuestren que cada función es completamente operativa mientras al mismo tiempo se buscan errores en cada función, al conocer el funcionamiento interno de un producto, pueden realizarse pruebas para garantizar que “todos los engranes embonan”; es decir, que las operaciones internas se realizan de acuerdo con las especificaciones y que todos los componentes internos se revisaron de manera adecuada.
18.3 PRUEBA DE CAJA BLANCA
La prueba de caja blanca, en ocasiones llamada prueba de caja de vidrio, es una filosofía de diseño de casos de prueba que usa la estructura de control descrita como parte del diseño a nivel de componentes para derivar casos de prueba. Al usar los métodos de prueba de caja blanca, puede derivar casos de prueba que: garanticen que todas las rutas independientes dentro de un módulo se revisaron al menos una vez, revisen todas las decisiones lógicas en sus lados verdadero y falso, 3) ejecuten todos los bucles en sus fronteras y dentro de sus fronteras operativas y 4) revisen estructuras de datos internas para garantizar su validez.
18.4 PRUEBA DE RUTA BÁSICA
La prueba de ruta o trayectoria básica es una técnica de prueba de caja blanca propuesta por primera vez por Tom McCabe [McC76]. El método de ruta básica permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño de procedimiento y usar esta medida como guía para definir un conjunto básico de rutas de ejecución. Los casos de prueba derivados para revisar el conjunto básico tienen garantía para ejecutar todo enunciado en el programa, al menos una vez durante la prueba.
18.5 PRUEBA DE LA ESTRUCTURA DE CONTROL
La técnica de prueba de ruta básica es una de varias técnicas para probar la estructura de control. Aunque la prueba de ruta básica es simple y enormemente efectiva, no es suficiente en sí misma. En esta sección se estudian otras variaciones acerca de la prueba de la estructura de control.
18.6 PRUEBAS DE CAJA NEGRA
ResponderEliminarLas pruebas de caja negra, también llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las técnicas de prueba de caja negra le permiten derivar conjuntos de condiciones de entrada que revisarán por completo todos los requerimientos funcionales para un programa. Las pruebas de caja negra no son una alternativa para las técnicas de caja blanca. En vez de ello, es un enfoque complementario que es probable que descubra una clase de errores diferente que los métodos de caja blanca.
18.7 PRUEBA BASADA EN MODELO
La prueba basada en modelo (PBM) es una técnica de prueba de caja negra que usa la información contenida en el modelo de requerimientos como la base para la generación de casos de prueba. En muchos casos, la técnica de prueba basada en modelo usa diagramas de estado UML, un elemento del modelo de comportamiento, como la base para el diseño de los casos de prueba. La técnica PBM requiere cinco paso:
1. Analizar un modelo de comportamiento existente para el software o crear uno
2. Recorrer el modelo de comportamiento y especificar las entradas que forzarán al software a realizar la transición de estado a estado.
3. Revisar el modelo de comportamiento y observar las salidas esperadas, conforme el software realiza la transición de estado
4. Ejecutar los casos de prueba
5. Comparar los resultados reales y esperados y adoptar una acción correctiva según se requiera
18.8 PRUEBA PARA ENTORNOS, ARQUITECTURAS Y APLICACIONES ESPECIALIZADOS
En ocasiones, los lineamientos y enfoques únicos para pruebas se garantizan cuando se consideran entornos, arquitecturas y aplicaciones especializados. Y adaptarse a situaciones especializadas, vale la pena considerar individualmente sus necesidades únicas.
18.9 PATRONES PARA PRUEBAS DE SOFTWARE
El uso de patrones como un mecanismo para describir soluciones a problemas de diseño específicos se estudió en el capítulo 12. Pero los patrones también pueden usarse para proponer soluciones a otras situaciones de ingeniería de software; en este caso, prueba del software. Los patrones de prueba describen problemas y soluciones de prueba comunes que pueden auxiliar en su tratamiento.
18.10 RESUMEN
El objetivo principal para el diseño de casos de prueba es derivar un conjunto de pruebas que tienen la mayor probabilidad de descubrir errores en el software. Para lograr este objetivo, se usan dos categorías diferentes de técnicas de diseño de caso de prueba: pruebas de caja blanca y pruebas de caja negra. dos categorías diferentes de técnicas de diseño de caso de prueba: pruebas de caja blanca y pruebas de caja negra. Las pruebas de caja blanca se enfocan en la estructura de control del programan bases de caja blanca se enfocan en la estructura de control del programa
GWYNETH LEONOR ALVAREZ ZARAGOZA
ResponderEliminarYURÉCUARO, MICH. A VIERNES 24 DE SEPTIEMBRE DEL 2021.
APÉNDICE 2: CONCEPTOS ORIENTADOS A OBJETO.
CAPÍTULO 32: COMENTARIOS FINALES.
ResponderEliminarEn este capítulo hablamos de todo un poco, con esto me refiero a que tocamos temas de los capítulos anteriores.
la ingeniería de software esta formada por hechos rápidos e impredecibles, pero no todo puede ser perfecto, en ocasiones el proceso de frecuencia puede llagar a se lento. La tecnología avanza desde hace siglos, la tecnología de software es útil para todos los profesionales.
LA IMPORTANCIA DE SOFTWARE-REVISIÓN.
En el primer capítulo se habló sobre la importancia que tiene el software en un computador y su función. Software nos ofrece ventajas competitivas en el mercado. Los productos operativos que tiene software son un articulo qué es más importante que los de otros. Se habla del software qué es requerido para dar soporte a un computadora, el cual presenta nuevos desafíos dramáticos para nosotros como sociedad. debemos de recodar que cunado una tecnología es de gran impacto se debe manejar con un gran cuidado para evitar problemas.
LAS PERSONAS Y LA FORMA EN QUECONSTITUYEN SISTEMAS.
Todo tiene importancia, cada vez la tecnología avanza, lo cual implica el crecimiento y actualización del software, pero no todo es bueno, al aumentar esto también aumentan los problemas y claro que estos necesitan una solución, es entonces donde entran los grupos de ingenieros de software que se encargan de la resolución de estos, cuando el crecimiento de software aumente también aumentan las personas que trabajan en el.
NUEVOS MODOS PARA REPRESENTAR LA INFORMACIÓN.
se menciona que la gran mayoría de software fueron construidos para el proceso de datos e información. Un reto que enfrenta actualmente el grupo de ingenieros de software es el construir un tipo de sistema que nos proporcione o queden el siguiente paso, o sea crear un sistema que sea capaz de extraer información y de una forma más fácil y eficaz, lo cual seria de gran ayuda para todos los usuarios.
LA VISTA LARGA.
la importancia que tiene crear un sima que extraiga información de una forma más rápida es importante, esto debido a el avance tecnológico qué está surgiendo. En esta parte se menciona un libro del autor Ray Kurzweil, según lo que estuve leyendo, en el habla de lo ya antes mencionado que es el avance tecnológico, nos dice que llegara un punto en el que el ritmo del cambio tecnológico será tan rápido, y su impacto tan profundo que la vida humana cambiara de una forma irreversible. Me preguntó ¿ cuándo sucederá esto?, y ¿Qué cambios habrá?.
LA RESPONSABILIDAD DEL INGENIERO DE SOFTWARE.
Es importante que los ingenieros que trabajan en software sean unos profesionales, con esto quiero decir que, tengan los conocimientos necesarios sobre sistemas, diseño, y todo aquello relacionado con software, con el objetivo de realizar un buen desempeño, también se requiere de un compromiso y de seguir ciertas reglas ya establecidas como lo puede ser no robar datos, etcétera.
UN COMENTARIO FINAL.
Hemos llegado al final, el autor de este libro buscaba expresar su conocimiento, sobre un tema poco conocido e incluso de poco interés para algunas personas. Pero finalmente todo esto es algo importante, sin duda la tecnología está por todos lados, por eso es importante conocer sobre ella. El software es algo muy importante, que cada vez crese y se actualiza, esto seguirá pasando con el paso del tiempo, para esto hay barios ingenieros trabajando en sus mejoras para cubrir las necesidades del usuario. por estos motivos es necesario que todos los ingenieros de software se preparen día con día
UN COMENTARIO FINAL.
https://drive.google.com/file/d/12L79KRABHqRYmGxmxO4bjaPA-iKkYYKQ/view?usp=sharing
ResponderEliminarhttps://docs.google.com/document/d/1skKYza4W8Pgyb3agYHCiVSAbJjNrqzRK/edit?usp=drivesdk&ouid=104437668318676127748&rtpof=true&sd=true
ResponderEliminarFatima Refugio Hidalgo Ayala
ResponderEliminarcapitulo 14
https://drive.google.com/file/d/1uTZS6ciHrTl_e0CfrFkAmt4J3Bm6mY5H/view?usp=drivesdk
ResponderEliminar¿Qué es calidad?
EliminarCalidad … sabes lo que es, pero no sabes lo que es. Algunas cosas son mejores que otras, tienen más calidad. Pero cuando tratas de decir lo que es la calidad además de las cosas, todo se desvanece… No hay nada de qué hablar ¿Cómo saber lo que es, o incluso saber que existe? Si nadie sabe lo que es, entonces, para todos prácticos, no existe en absoluto. Todos los propósitos prácticos, en realidad si existe ¿En qué otra cosa se basan las calificaciones? ¿Por qué paga fortunas la gente por algunos artículos y tira otros a la basura? Es obvio que algunas cosas son mejores que otras… Pero ¿En qué son mejores? Y además vueltas y más vueltas, ruedas de metal que patinan sin nada en lo que hagan tracción. ¿Qué demonios es la calidad? ¿Qué es?