Software Engineering

Key

ISW-ES 6A Y 6B

Subject Manual

Da clic aquí para descargarlo

Justification

Give the student the ability to apply methodologies for modeling solutions, planning and managing software projects, to facilitate the implementation of an information system.

Dar al alumno la capacidad de aplicar metodologías para el modelado de soluciones, la planeación y la administración de proyectos de software, que facilite la puesta en marcha de un sistema de información.

Objective

The student will be able to manage the development of a software project, through the application of techniques or methodologies that allow to detect the costs, material and human resources necessary for the organization, generate a planning, monitoring and quality control of it.

El alumno será capaz de gestionar el desarrollo de un proyecto de software, mediante la aplicación de técnicas o metodologías que permitan detectar los costos, recursos materiales y humanos necesarios para la organización, generar una planificación, seguimiento y control de calidad del mismo.

Abilities

• oral and written communication
• Troubleshooting
• Analysis and synthesis capacity
• Logical design
• Conceptual design

• Comunicación oral y escrita
• Resolución de problemas
• Capacidad de análisis y síntesis
• Diseño lógico
• Diseño conceptual

Generic competences for developed

• Solve problems
• Apply knowledge in practice
• Work autonomously and in a team
• Capacity for analysis and synthesis

• Resolver problemas
• Aplicar los conocimientos en la práctica
• Trabajar en forma autónoma y en equipo
• Capacidad para análisis y síntesis

Capacities to develop in the subject

Identify the functional areas of the organization that handle large amounts of information by analyzing processes and documents to determine the needs of databases.

Identificar las áreas funcionales de la organización que manejan grandes cantidades de información mediante el análisis de procesos y documentos para determinar las necesidades de bases de datos.

Competences to which the subject contributes

Determine information requirements of the organization through instruments or techniques for gathering information to obtain technical specifications of the database to be designed.

Determinar requerimientos de información de la organización mediante instrumentos o técnicas de recopilación de información para obtener especificaciones técnicas de la base de datos a diseñar.

Estimation of time (hours) necessary to transmit the learning to the student, by unit of learning

• Total hours per semester: 105
• Total hours per week: 7
• Credits: 6

Introduction

Software is a key factor that differentiates modern products and services, we find it in organizations of all kinds. The term software engineering was coined in 1968 at a conference to discuss the "software crisis". Large software projects had delays and poor performance due to the informal approach that was handled. The need to create an engineering discipline applied to the production of software was highlighted, today we can define software engineering as the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of the software and includes all the aspects of the production of software. Today the development of complex, reliable and low-cost software is possible thanks to software engineering. It is important that the student understands the software engineering process and forms a criterion about the different models of the process, their differences, advantages and disadvantages; so in your working life you can select the most appropriate one. The student in the subject will estimate, manage, model and test a software project, allowing him to know and handle the problems that a project manager faces. In the course, the necessary skills are developed in each of the stages of the software development process.

El software es un factor clave que diferencia los productos y servicios modernos, lo encontramos en organizaciones de todo tipo. El término ingeniería de software fue acuñado en 1968 en una conferencia para discutir la “crisis del software”. Los grandes proyectos de software tenían retrasos y un pobre desempeño debido al enfoque informal que se manejaba. Se destacó la necesidad de crear una disciplina de ingeniería aplicada a la producción de software, hoy podemos definir a la ingeniería de software como la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, funcionamiento y mantenimiento del software y comprende todos los aspectos de la producción de software. Hoy en día es posible el desarrollo de software complejo, confiable y de bajo costo gracias a la ingeniería de software. Es importante que el alumno comprenda el proceso de ingeniería de software y se forme un criterio acerca de los diferentes modelos del proceso, sus diferencias, ventajas y desventajas; así en su vida laboral pueda seleccionar el más apropiado. El alumno en la asignatura estimará, administrará, modelará y probará un proyecto de software, permitiéndole conocer y manejar los problemas a los que se enfrenta un administrador de proyecto. En la asignatura se desarrollan las competencias necesarias en cada una de las etapas del proceso de desarrollo de software.

Glossary

• Software project management. Process by which the responsibility for successful completion of a software project is fulfilled.
• Software quality. Process to ensure that a software development team follows quality standards.
• CMMI. Integrated approach for the maturity modeling of the process capacity. Supports discrete and continuous maturity modeling and integrates systems and maturity models of software engineering processes.
• COCOMO (Constructive Cost Model). Barry Bohem formulas to calculate the probable labor requirements, in person-month, to build an application, and the probable time it will take, based on the lines of estimated codes.
• Cyclomatic complexity. It is a software metric that provides a quantitative measurement of the logical complexity of a program.
• Diagram of use cases. Diagram representing the sequence of actions, some performed by some application and others by the user, which are common when using the application; the user has a particular role in this interaction and receives the name of "actor" regarding the use case.
• Class diagram. It is a type of static structure diagram that describes the structure of a system, showing its classes, its attributes, operations or methods and the relationships between classes.
• Collaboration or communications diagram. It is a diagram that shows organized interactions around the roles.
• Gantt chart. Graph used by project managers to show project tasks, the agenda associated with these tasks and the people who will work on them.
• Interaction diagrams. Represents the way in which a Client (Actor) or Objects (Classes) communicate with each other in response to an event.
• Sequence diagram. Diagram formed by the application objects showing a sequence of function calls between them.
• Software process model. It is a representation of each of the phases that are carried out to develop or build software. Some models are: waterfall, spiral, evolutionary, incremental, etc.

• Administración del proyecto de software. Proceso mediante el cual se satisface la responsabilidad de una terminación exitosa de un proyecto de software.
• Calidad del software. Proceso de asegurar que un equipo de desarrollo de software sigue los estándares de calidad.
• CMMI. Enfoque integrado para el modelado de madurez de la capacidad del proceso. Apoya los modelados de madurez discretos y continuos e integra sistemas y modelos de madurez de los procesos de la ingeniería del software.
• COCOMO (Constructive Cost Model). Fórmulas de Barry Bohem para calcular los requerimientos probables de mano de obra, en persona-mes, para construir una aplicación, y el tiempo probable que tomará, con base en las líneas de código estimadas.
• Complejidad ciclomática. Es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.
• Diagrama de casos de uso. Diagrama que representa la secuencia de acciones, algunas realizadas por alguna aplicación y otras por el usuario, que son comunes al usar la aplicación; el usuario tiene un papel particular en esta interacción y recibe el nombre de "actor" respecto al caso de uso.
• Diagrama de clases. Es un tipo de diagrama de estructura estático que describe la estructura de un sistema, mostrando sus clases, sus atributos, operaciones o métodos y las relaciones entre las clases.
• Diagrama de colaboración o de comunicaciones. Es un diagrama que muestra interacciones organizadas alrededor de los roles.
• Diagrama de Gantt. Gráfico utilizado por los gestores de proyectos para mostrar las tareas del proyecto, la agenda asociada con estas tareas y las personas que trabajarán en ellas.
• Diagramas de interacción. Representa la forma en cómo un Cliente (Actor) u Objetos (Clases) se comunican entre sí en petición a un evento.
• Diagrama de secuencia. Diagrama formado por los objetos de la aplicación que muestra una secuencia de llamadas a funciones entre ellos.
• Modelo de proceso de software. Es una representación de cada una de las fases que se llevan a cabo para desarrollar o construir software. Algunos modelos son: cascada, espiral, evolutivo, incremental, etc.

Units & Evidences

FORMATO DEL CUADERNO DE TRABAJO

Da click aquí para descargar el formato del cuaderno de trabajo

CARPETA COMPARTIDA EN BOX.COM

EIT6A Schedule

EIT6B SCHEDULE

TÍTULO: UML AUTOR: Howard Podeswa AÑO: 2010 EDITORIAL O REFERENCIA: Anaya Multimedia-Anaya Interactiva LUGAR Y AÑO DE LA EDICIÓN España, 2010 ISBN O REGISTRO: 9788441527195

TÍTULO: Ingeniería del Software AUTOR: Roger S. Pressman AÑO: 2010 EDITORIAL O REFERENCIA: McGraw-Hill LUGAR Y AÑO DE LA EDICIÓN Madrid, 2010 ISBN O REGISTRO: 9786071503145

TÍTULO: Estimación de costos y administración de proyectos de software AUTOR: Capers Jones AÑO: 2008 EDITORIAL O REFERENCIA: McGraw-Hill LUGAR Y AÑO DE LA EDICIÓN México, 2008 ISBN O REGISTRO: 9789701067055

TÍTULO: UML AUTOR: Carlos Fontanela AÑO: 2010 EDITORIAL O REFERENCIA: Alfaomega Grupo Editor LUGAR Y AÑO DE LA EDICIÓN México, 2010 ISBN O REGISTRO: 9789871609222

TÍTULO: Ingeniería de Software AUTOR: Ian Sommerville AÑO: 2010 EDITORIAL O REFERENCIA: Pearson Educación LUGAR Y AÑO DE LA EDICIÓN Madrid, 2010 ISBN O REGISTRO: 9786073206037

TÍTULO: Gestión De Proyectos Con Microsoft Proyect 2010 AUTOR: Manuel a. Castro AÑO: 2011 EDITORIAL O REFERENCIA: Alfa Omega Grupo Editor LUGAR Y AÑO DE LA EDICIÓN México, 2011 ISBN O REGISTRO: 9789586828086

Introduction to Software Engineering

1. ¿Qué es software? Programas de cómputo y documentación asociada.
2. ¿Cuáles son los atributos del buen software? El buen software debe entregar al usuario la funcionalidad y el desempeño requeridos, y debe ser sustentable, confiable y utilizable.
3. ¿Qué es ingeniería de software? La ingeniería de software es una disciplina de la ingeniería que se interesa por todos los aspectos de la producción de software.
4. ¿Cuáles son las actividades fundamentales de la ingeniería de software? Especificación, desarrollo, validación y evolución del software.
5. ¿Cuál es la diferencia entre ingeniería de software y ciencias de la computación? Las ciencias de la computación se enfocan en teoría y fundamentos; mientas la ingeniería de software se enfoca en el sentido práctico del desarrollo y en la distribución de software.
6. ¿Cuáles son los principales retos que enfrenta la ingeniería de software? Se enfrenta con una diversidad creciente, demandas por tiempos de distribución limitados y desarrollo de software confiable.
7. ¿Cuáles son los costos de la ingeniería de software? Aproximadamente 60% de los costos del software son desarrollo, y 40% de prueba. Para el software elaborado especificamente, los costos de evolución superan con frecuencia los costos de desarrollo.
8. ¿Cuáles son los mejores métodos y técnicas de la ingeniería de software? Aún cuando todos los proyectos de software deben gestionarse y desarrollarse de manera profesional, existen diferentes técnicas que son adecuadas para distintos tipos de sistema. Por ejemplo, los juegos siempre deben diseñarse usuando una serie de prototipos, mientras que los sistemas críticos de control de seguridad requieren de una especificación completa y analizable para su desarrollo. Por lo tanto, no puede decirse que un método sea mejor que otro.
9. ¿Qué diferencias ha marcado la Web a la ingeniería de software? La Web ha llevado a la disponibilidad de servicios de software y a la posibilidad de desarrollar sistemas basados en servicios distribuidos ampliamente. El desarrollo de sistemas basados en Web ha conducido a importantes avances en lenguajes de programación y reutilización de software.
10. ¿Qué tipos de productos software existen? Existen los productos genéricos y productos personalizados (o a la medida).

Estos son los atributos del buen software:

1. Mantenimiento
2. Confiabilidad y seguridad
3. Eficiencia
4. Aceptabilidad

Estos son algunos estándares de comportamiento aceptable de software:

1. Confidencialidad
2. Competencia
3. Derechos de propiedad intelectual (patentes y copyright)
4. Mal uso de computadoras (el uso incorrecto para daño a terceros)

Software Process Models

Definición de proceso de software
Es una serie de actividades relacionadas que conduce a la elaboración de un producto de software. Estas actividades pueden incluir el desarrollo de software desde un lenguaje de programación.

Desarrollo de las aplicaciones de negocios
Hoy en día, estas aplicaciones se desarrollan con frecuencia extendiendo y modificando los sistemas existentes, o configurando e integrando el software comercial o componentes del sistema.

Existen muchos diferentes procesos de software, pero todos deben incluir cuatro ctividades que son fundamentales para la ingeniería de software:

1. Especificación del software: Tienen que definirse tanto la funcionalidad del software como las restricciones de su operación
2. Diseño e implementación del software: Debe desarrollarse el software para cumplir con las especificaciones.
3. Validación del software: Hay que validad el software para asegurarse de que cumple lo que el cliente quiere.
4. Evolución del software: El software tiene que evolucionar para satisfacer las necesidades cambiantes del cliente.

Modelos de proceso de software
Son una representación simplificada de un proceso a otro, ofreciendo información parcial acerca de dicho proceso. Los principales son:

1. El modelo en cascada (waterfall): Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representa como fases separadas del proceso, tal como definición de requerimientos, diseño del sistema y del software, implementación y prueba de unidad, integración y prueba del sistema, operación y mantenimiento.
2. Desarrollo incremental: Este enfoque vincula las actividades de especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior.
3. Ingeniería de software orientada a la reutilización: Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde cero.

Más modelos de proceso del software

1. Presentación sobre los modelos de proceso de software (español):
Da clic aquí para descargar la presentación
2. Presentación sobre los modelos de proceso de software (inglés):
Da clic aquí para descargar la presentación

INDICACIONES: De la presentación 1 (en español), diapositiva 6, en tu cuaderno dibuja un diagrama de cada uno de los modelos de proceso de software.

EC1: Cuestionario sobre modelos de proceso de software

INDICACIONES: Estudia los conceptos y modelos vistos en los temas 1 y 2.

ED1: Exposición de casos de estudio donde aplicar los modelos de proceso de software

INDICACIONES: En equipos y utilizando los modelos de procesos de software vistos en el tema2, elabora una presentación siguiendo los criterios de la rúbrica de evaluación, el modelo de procesos de software adecuado para un caso de estudio de su elección.
Presentation (slides order):

1. Presentation cover: University name, Logo, Subject name, topic name, unit name, evidence name and type, professor name, team members names, date and city.
2. Description of the software process model.
3. Graphic representation of software process model.
4. Features of the software process model.
5. Advantage of the software process model.
6. Disadvantages of the software process model.
7. Software to implement with the software process model.
8. Why do you think to use this software process model for the software?
9. Describe the prototype
10. Conclusions

1. What do you think about how the companies select the methodologies for develop software?
2. If you had the opportunity of work in a development company, what position would you like to have and why?
3. Of the software process models, What do you think is the hardest and easiest to implement and why?
4. What are the phases of software development of your model, and how long do you need for end each one?

Kanban Methodology

¿Qué es Kanban?
Es un sistema de producción altamente efectivo y eficiente. Es una herramienta que sirve para conseguir la producción "JUST IN TIME". Kanban significa en japonés etiqueta de instrucción. Es una etiqueta que sirve como orden de trabajo cuya información es útil para saber qué se va a producir, cuánto se va a producir, cómo se va a producir y cómo se va a transportar, entre otra información. Esta metodología se puede implementar para proyectos industriales y de TI.

Propósito
El objetivo de Kanban es minimizar el TEP (Trabajo En Progreso), o stock, entre los procesos. Para lograr esto Kanban se asegura que el proceso superior produzca partes sólo si el proceso inferior las necesita. "Por demada" significa que los trabajadores del proceso inferior consumen las partes que necesitan de los procesos superiores.

¿Cómo es Kanban?
Es un tablero que pone a la vista la información necesaria para controlar la evolución del producto e involucrar de forma natural a todos los integrantes en la resolución y la gestión de los problemas. Se divide en un lienzo en columnas y unas etiquetas Kanban que contienen información de qué se va a producir, medios que se utilizarán en la producción, cantidad y encargado del proceso. Una limitante del Kanban tradicional es que se hace en papel y sus datos no se pueden transmitir directamente a un sistema de información.

ACTIVIDAD 1: Elabora un tablero KANBAN (puede ser en cascara de huevo) como el que se muestra en la ilustración. Después elabora una serie de post-its para tus compañeros del equipo. El tablero deberá ser amigable.

Software project team roles and responsibilities

Roles en el desarrollo de software
En el siguiente documento PDF encontrarás información acerca de los diferentes roles en un proyecto de desarrollo de software.
Da clic en esta liga para acceder al documento

ACTIVIDAD1(Individual): A continuación hay una lista de personas que comunmente trabajan en proyectos de desarrollo de software. Investiga y anota en tu cuaderno cómo se escriben y pronuncian cada uno de estos puestos en inglés:

1. Administrador del proyecto
2. Analistas
3. Diseñadores
4. Programadores
5. Téster
6. Aseguradores de calidad
7. Administrador de configuración
8. Ingeniero de validación y verificación
9. Documentador
10. Ingeniero de manutención
11. Cliente comprometido

• Nombre del puesto:
• Descripción del puesto:
• Objetivos del puesto:
• Actividades y metas del puesto (representarlo con la tabla):
• Integrantes del equipo con los que se relaciona el puesto:
• Herramientas de trabajo del puesto:
• Plan de trabajo del puesto:

UP phases & activities

EP1: Elaboración de matriz de habilidades

Elabora tres matrices con la ponderación (Básico, Medio, Avanzado, Consolidado) utilizando la metodología Kanban:

1. Actividades-Habilidades
2. Personal-Habilidades
3. Personal-Actividades

Project Estimation

INDICATIONS: Answer the following questions using the references.

1. What is COCOMO?
2. What is a Module?
3. What is a module size?
4. Describe the sizing method (SLOC, Function Points, Adaptation and Reuse)
5. Describe the function type (inputs, outputs, files, interfaces, queries)
6. What is DM, CM, IM, SU, AA, AT and ATPROD?
7. What are the types of estimation? (Are three)
8. Define the following word in spanish: effort, sched, PROD, COST, INST, Staff, RISK

ED1: COCOMO Estimation

INDICACIONES: Elabora una estimación para un proyecto utilizando el software COCOMO.
LINK DE DESCARGA DE COCOMO


PROBLEMA1: Elabora una cotización utilizando el software COCOMO para la implementación de sistemas en los departamentos de una institución educativa.

• El nombre del proyecto es SI-ESCOLAR
• Agregar un módulo llamado VINCULACION, donde el método para obtener el tamaño del módulo se base en 3000 SLOC. El lenguaje a desarrollar es ORIENTADO A OBJETOS. La tasa de trabajo se mide en 1500 dólares mensuales. El modelo de desarrollo será EARLY DESIGN por ser proyecto nuevo.
• Agregar un segundo módulo llamado SEG_EGRESADOS, donde el método para obtener el tamaño del módulo se base en 3500 SLOC. El lenguaje a desarrollar es ORIENTADO A OBJETOS. La tasa de trabajo se mide en 1500 dolares mensuales.
• Agregar un módulo llamado INCUBACIÓN, donde el método para obtener el tamaño del módulo se basa en 4000 SLOC. El lenguaje a desarrollar es ORIENTADO A OBJETOS. La tasa de trabajo se mide en 1500 dólares mensuales.
• Menciona cuál es el esfuerzo OPTIMISTA, MEDIO y PESIMISTA
• Menciona cuáles serían las semanas invertidas si el desarrollo es OPTIMISTA, MEDIO y PÉSIMO
• Menciona cuál es el costo del proyecto si el desarrollo es OPTIMO, MEDIO y PÉSIMO
• Menciona cuáles son el número de personas qué tendrán que trabajar para un desarrollo OPTIMO, MEDIO y PÉSIMO.

• El nombre del proyecto es SI-ENCUESTA
• Agregar un módulo llamado gestión, donde el método del tamaño del módulo se determina mediante PUNTOS DE FUNCIÓN. El lenguaje será en JAVA. El calculo del método se realiza USANDO TABLA y especificando lo siguiente: En los INPUTS el número de puntos de función promedio es de 50, OUTPUTS es de 40, FILES de 20, INTERFACES de 10 y QUERIES de 40. La tasa de trabajo al mes es de 2000 dólares.
• Agregar un módulo llamado alumnado, donde el método del tamaño del módulo se determina mediante PUNTOS DE FUNCIÓN. el lenguaje será en JAVA. El calculo del método se realiza USANDO TABLA y especificando lo siguiente: En los INPUTS el número de puntos de función promedio es de 40, OUTPUTS es de 45, INTERFACES de 15 y las QUERIES de 35. La tasa de trabajo al mes es de 2100 dólares. Considerar para los INPUTS y OUTPUTS el número de puntos ALTO a 60.
• Agregar un módulo llamado coordinación, donde el método del tamaño del módulo se determina mediante PUNTOS DE FUNCIÓN. El lenguaje será en JAVA. El calculo del método se realiza USANDO TABLA y especificando lo siguiente: En los INPUTS el número de puntos de función promedio es de 50, OUTPUTS es de 30, FILES de 30, INTERFACES de 15 y QUERIES de 45. La tasa de trabajo al mes es de 2000 dólares.
• Checar el porcentaje, esfuerzo y la cantidad de STAFF a relacionarse en cada fase (inception, elaboration, construction transition)
• Menciona cuál es el esfuerzo OPTIMISTA, MEDIO y PESIMISTA
• Menciona cuáles serían las semanas invertidas si el desarrollo es OPTIMISTA, MEDIO y PÉSIMO
• Menciona cuál es el costo del proyecto si el desarrollo es OPTIMO, MEDIO y PÉSIMO
• Menciona cuáles son el número de personas qué tendrán que trabajar para un desarrollo OPTIMO, MEDIO y PÉSIMO.

• El nombre del proyecto es PROCESST
• Agregar un módulo llamado TBASE en donde el método para estimar el tamaño es por REUSO Y ADAPTACIÓN. El lenguaje será ORIENTADO A OBJETOS. El porciento de diseño modificado es de 10%, el código modificado es de 20%, la integración modificada es de 20%, el entendimiento de software es de 40SU, una evaluación y aislamiento de 4AA, desconocmiento del software 0.4 UNFM, un AT de 10% y un ATPROD de 2400.
• Menciona cuál es el total de lineas de código
• Indica cuál es el total de horas/PM
• Menciona el porcentaje, esfuerzo y staff de las fases en cascada.
• Menciona cuál es el esfuerzo OPTIMISTA, MEDIO y PESIMISTA
• Menciona cuáles serían las semanas invertidas si el desarrollo es OPTIMISTA, MEDIO y PÉSIMO
• Menciona cuál es el costo del proyecto si el desarrollo es OPTIMO, MEDIO y PÉSIMO
• Menciona cuáles son el número de personas qué tendrán que trabajar para un desarrollo OPTIMO, MEDIO y PÉSIMO.

Software Project Management

Especificación de requisitos según el estándar de IEEE 830 (IEEE Std. 830-1998, 22 de octubre de 2008)
Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS) según la última versión del estándar IEEE 830. Según IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organización y el formato dados en el estándar 830, sí deberá incluir, de una forma o de otra, toda la información presentada en dicho estándar. El estándar de IEEE 830 no está libre de defectos ni de prejuicios, y por ello ha sido justamente criticado por múltiples autores y desde múltiples puntos de vista, llegándose a cuestionar incluso si es realmente un estándar en el sentido habitual que tiene el término en otras ingenier´ıas. El presente documento no pretende pronunciarse ni a favor ni en contra de unos u otros: tan sólo reproduce, con propósitos fundamentalmente docentes, cómo se organizaría un Documento de Requisitos según el estándar IEEE 830.

INDICACIONES: Utilizando la especificación de requisitos según el estándar de IEEE 830 (IEEE Std. 830-1998, 22 de octubre de 2008), en equipos elaboren un documento para un proyecto de software en donde describan cada uno de los puntos según el estándar IEEE. Dividan el documento en dos columnas, de lado izquierdo van las indicaciones y de lado derecho la descripción del proyecto.

Software Tests

INDICACIONES: Utilizando la información de la tesis de maestría en informática "Proceso de Testing funcional independiente" de Beatriz Pérez Lamancha, Montevideo, Uruguay, responde elabora un diagrama conceptual con ilustraciones utilizando los siguientes terminos: Título central: Pruebas de Software

• Definiciones: pruebas, verificación, validación y prueba. Error, falta, defecto y falla. Requerimientos y su relación con la prueba. Elementos de la prueba.
• Consideraciones respecto a la prueba: no es posible probar completamente un programa, actitud frente a las pruebas.
• Clasificaciones de la prueba: prueba estructural vs funcional.
• Otros tipos de pruebas: pruebas de regresión, pruebas de humo, pruebas de automatizadas.
• Técnicas de pruebas: técnicas de caja negra, técnicas de caja blanca, técnicas según quién hace la prueba y técnicas basadas en la intuición o en la experiencia.

Control flow graphs

Some CFG examples: (a) an if-then-else (b) a while loop (c) a natural loop with two exits, e.g. while with an if...break in the middle; non-structured but reducible (d) an irreducible CFG: a loop with two entry points, e.g. goto into a while or for loop. A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution. The control flow graph is due to Frances E. Allen, who notes that Reese T. Prosser used boolean connectivity matrices for flow analysis before.
INDICACIONES: En el siguiente enlace encontrarás un video explicando la representación de las instrucciones de control metiante los CFG. Anóta un pseudocódigo y el ejemplo en CFG de las siguientes instrucciones:

1. Secuencia
2. Si
3. Si-Entonces-Si No
4. a y b
5. a o b
6. while
7. do while (repeat)
8. case

Software testing techniques

INDICACIONES: Responde el siguiente cuestionario y súbelo en la carpeta de UnidadIII del box.com

1. ¿Qué es una prueba de software?
2. ¿Cuáles son los objetivos de la prueba del software?
3. ¿Qué no garantizan las pruebas de software?
4. ¿Cuáles son los principios de la prueba?
5. ¿Cuáles son los diseños de casos de la prueba?
6. Defina, ¿qué se ejercita en la prueba de caja blanca?
7. Represente los grafos de prueba del camino básico:
8. Explique a detalle los algoritmos de la diapositiva 10 y 11.
9. Según el ejemplo anterior, explique cómo se llega a 4 caminos y cómo se recorren cada uno de ellos.
10. Explique, ¿Qué es la prueba del camino básico y mencione un ejemplo?
11. Según las pruebas de la estructura de control, explique, 1) prueba de condición, 2) prueba de flujo de datos, 3) prueba de bucles, además mencione ejemplos
12. Mencione los tipos de errores en las pruebas de caja negra
13. Mencione el diseño de pruebas de caja negra
14. Mencione los métodos de pruebas de caja negra
15. Mencione, ¿en qué consiste el diseño de partición equivalente y qué es una clase de equivalencia?
16. Mencione, ¿cómo identificar clases de equivalencia?

• Da clic aquí para acceder a la presentación para responder las preguntas.

EP1: Elaborar un documento del plan del proyecto y su programación de actividades

INDICACIONES: La evidencia se evaluará con el documento de requisitos según el estándar de IEEE 830 y con el diagrama GANTT.

EP2: Resolución de problemas mediante la técnica de caja blanca

INDICACIONES: La evidencia se evaluará con el documento word con las preguntas del tema4 - Software testing techniques.

EP3: Development of project class diagrams (Desarrollo de diagramas de clases del proyecto)

INDICACIONES: Elabora el diagrama de clases del videojuego Pokemon: