• No se han encontrado resultados

PIS-ES REV00 INGENIERÍA EN SISTEMAS COMPUTACIONALES PRINCIPIOS DE INGENIERÍA DE SOFTWARE

N/A
N/A
Protected

Academic year: 2021

Share "PIS-ES REV00 INGENIERÍA EN SISTEMAS COMPUTACIONALES PRINCIPIOS DE INGENIERÍA DE SOFTWARE"

Copied!
38
0
0

Texto completo

(1)

INGENIERÍA EN SISTEMAS

COMPUTACIONALES

PRINCIPIOS DE

PIS-ES

REV00

(2)

DIRECTORIO

Secretario de Educación Pública

Mtro. Alonso Lujambio Irazábal

Subsecretario de Educación Superior

Dr. Rodolfo Tuirán Gutiérrez

Coordinadora de Universidades Politécnicas

Mtra. Sayonara Vargas Rodríguez

(3)

PÁGINA LEGAL

Participantes

Mtra. Claudia Araceli Rangel Jiménez - Universidad Politécnica de Aguascalientes

Primera Edición: 2011

DR

2011 Coordinación de Universidades Politécnicas.

Número de registro:

México, D.F.

(4)

ÍNDICE

INTRODUCCIÓN ... 1

PROGRAMA DE ESTUDIOS ... 3

FICHA TÉCNICA ... 4

DESARROLLO DE LA PRÁCTICA O PROYECTO... 6

INSTRUMENTOS DE EVALUACIÓN ... 8

GLOSARIO ... 25

BIBLIOGRAFÍA ... 27

ANEXO 1 LINEAMIENTOS PARA PRESENTAR TRABAJOS O REPORTES ESCRITOS ... 29

(5)

INTRODUCCIÓN

El presente manual tiene como objetivo ser una herramienta de apoyo y guía para el

profesor en la identificación de los objetivos, los contenidos y la programación,

correspondientes a la asignatura de Principios de Ingeniería de Software. El manual detalla

las habilidades y valores que desarrollará el alumno al cumplir con cada objetivo, también

provee de los instrumentos didácticos y de evaluación que se podrán aplicar durante el

curso.

El software es cada vez más complejo y en las empresas es común la necesidad de

producirlo minimizando recursos, por lo que se requiere de un análisis y diseño de sistemas

más detallado que permita la disminución de costos de desarrollo y mantenimiento; así

como de procesos de desarrollo maduros que faciliten dicha tarea.

Expertos en ingeniería de software se han dado a la tarea de generar modelos y estándares

que faciliten el desarrollo de software. “La ingeniería de software es una disciplina de la

ingeniería que comprende todos los aspectos de la producción de software desde las etapas

iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que

se utiliza.”

1

Para el quehacer del Ingeniero en Sistemas Computacionales es requisito imprescindible

conocer el proceso de ingeniería de software, las metodologías de desarrollo, los estándares

y herramientas que han sido propuestos y mejorados por los eruditos en esta materia.

Dada la relevancia de la asignatura para el Ingeniero en Sistemas Computacionales se

establece como objetivo de la asignatura que el alumno será capaz de desarrollar proyectos

de software haciendo uso de técnicas, herramientas y metodologías utilizadas en la

empresa para conocer las exigencias y las metodologías más comunes en el desarrollo

profesional de aplicaciones.

1

(6)

El contenido de la asignatura se divide en cinco unidades, en cada una de las cuales se

desarrolla un conjunto de habilidades. La unidad uno introduce al alumno en los conceptos

clave la ingeniería de software. La unidad dos expone temas sobre la administración de

proyectos, los cuales le permitirán realizar la planeación de un proyecto de desarrollo de

software. La unidad tres instruye al alumno en los métodos, técnicas y modelos que

requerirá para la obtención y especificación de los requisitos de un proyecto de desarrollo de

software. En la unidad cuatro se examinan conceptos referentes al diseño y construcción de

los componentes del sistema. En la unidad cinco el alumno conocerá y aplicará métodos y

técnicas para la creación de pruebas para la validación del software.

Principios de Ingeniería de software tiene influencia sobre las asignaturas de programación,

y administración de proyectos, debido a que permite al alumno generar software

eficientemente, ya que seguirá métodos formales de desarrollo, hará uso de herramientas y

estándares para mejorar la calidad de su producto y facilitar su tarea. Además de

introducirlo a los conceptos de gestión de proyectos de desarrollo de software.

(7)

PROGRAMA DE ESTUDIOS

V i g en ci a a p art i r d e sep t i emb re d el 2011

Pr e s e nc ia l N O Pr e s e nc ia l Pr e s e nc ia l N O Pr e s e nc ia l A l comp l et ar l a u n i d ad d e

ap ren d i z aj e el al u mn o será cap az d e:

* Identificar los elementos, fases y actividades del proceso de software.

Diseño y uso de organizadores previos. Identifica palabras clave, parafrasea. Lectura comentada. Elaboración de cuadro sinóptico.

X N/A N/A N/A N/A Pizarrón N/A 1 0 0 0 * Describir las características de los

diferentes modelos del proceso de software.

Elaboración de mapas conceptuales.

Elaboración de

resúmenes. X N/A N/A N/A N/A Pizarrón Equipo de cómputo,

cañón 2 0 0 1 * Seleccionar el modelo del proceso de

software para un proyecto de desarrollo de acuerdo a sus características.

E P 1: Elabora reporte de práctica "Proceso de software y modelos del proceso de software".

Utilizar diagramas ilustraciones y esquemas.

Práctica mediante la

acción. X N/A N/A N/A 1. Proceso de software y modelos del proceso de software

N/A Equipo de cómputo,

cañón 1 0 1 1 Documental Lista de cotejo para reporte de práctica. A l comp l et ar l a u n i d ad d e

ap ren d i z aj e el al u mn o será cap az d e:

* Identificar los elementos de un plan de trabajo y los recursos que se deben administrar en un proyecto de desarrollo de software. Exposición o presentación. Lectura comentada. Identifica palabras clave, parafrasea. Elaboración de resúmenes.

X N/A N/A N/A

Pizarrón. Procesador de

texto.

Equipo de cómputo. 4 0 1 0

* Diseñar el plan de trabajo para un proyecto de desarrollo de software el cual establezca el proceso a seguir, los mecanismos para el control de cambios, las métricas para evaluar la calidad del producto y la gestión de los riesgos.

Estudio de caso. Práctica mediante la

acción y proyecto. X X N/A Proyecto Final

Pizarrón Herramientas ofimáticas (procesador de textos, hoja de cálculo, modelado) Equipo de cómputo, cañón. 2 0 1 2 A l comp l et ar l a u n i d ad d e ap ren d i z aj e el al u mn o será cap az d e:

* Describir las actividades necesarias para la obtención, análisis y especificación de requerimientos del sistema. E D1: Expone los conceptos de la especificación de requerimientos del sistema.

Discusión dirigida. Investigación.

Exposición. X N/A X

Biblioteca N/A N/A

Aplicación para elaborar presentaciones electrónicas. Equipo de cómputo, cañón. 4 0 1 0 Campo Guía de observación para exposición oral de conceptos de requerimientos del sistema.

* Definir los requerimientos del sistema haciendo uso de técnicas y modelos para la obtención, representación y validación de los mismos.

Experiencia programada.

Experiencia

programada. X X N/A N/A N/A Pizarrón. Procesador de

texto.

Equipo de cómputo,

cañón. 7 0 2 3

* Elaborar la especificación formal de los requerimientos del sistema (funcionalidad, comportamiento, flujo de información).

Diseño y uso de organizadores previos.

Práctica mediante la

acción y proyecto. X X N/A N/A N/A

Herramientas de modelado y procesador de texto instalados. Equipo de cómputo. 4 0 2 2 A l comp l et ar l a u n i d ad d e ap ren d i z aj e el al u mn o será cap az d e:

* Diseñar la estructura de los datos, la arquitectura del software, el modelo de interfaces y el modelo de componentes del sistema, haciendo uso de modelos para la representación del diseño del software.

E P 1: Elabora la especificación del diseño de software de un proyecto de desarrollo de software basada en la especificación de requisitos generada previamente. Diseño y uso de organizadores previos. Práctica mediante la

acción y proyecto. X X N/A N/A N/A Pizarrón. Herramientas de

modelado y procesador de

texto.

Equipo de cómputo. 8 0 3 1 Documental

Lista de cotejo para el documento de especificación del diseño de software de un proyecto de desarrollo de software. Se sugiere que el proyecto de desarrollo de software sea el proyecto final de la materia.

* Seleccionar la técnica de desarrollo y el lenguaje de programación para la construcción de los componentes de software basado en las características del sistema a desarrollar.

E D1: Expone los motivos de la selección de la técnica de desarrollo y el lenguaje de programación a utilizar en un proyecto de desarrollo de software, de acuerdo a las características del sistema. Exposición. Lectura comentada. Resolver situaciones

problemáticas. X N/A N/A N/A N/A

Aplicación para elaborar presentaciones electrónicas. Equipo de cómputo, cañón. 5 0 1 3 Campo Guía de observación para exposición de motivos de la selección de la técnica de programación y el lenguaje de programación a utilizar en un proyecto de desarrollo. Se sugiere que el proyecto de desarrollo de software sea el proyecto final de la materia.

A l comp l et ar l a u n i d ad d e ap ren d i z aj e el al u mn o será cap az d e:

* Describir los diferentes métodos de prueba a nivel de unidad, de integración y de validación del software. Lectura comentada. Investigación. Elaboración de mapas conceptuales. N/A X X

Biblioteca N/A N/A Equipo de cómputo,

cañón. 2 0 1 0

* Diseñar pruebas de caja negra para la validación del software.

Exposición o presentación.

Práctica mediante la

acción. N/A X N/A N/A Pizarrón Equipo de cómputo,

cañón. 3 0 1 1 * Elaborar reportes de resultados de

las pruebas del software.

Diseño y uso de organizadores previos.

Experiencia programada N/A X N/A N/A

Herramientas de desarrollo elegidas para la implementación del software. Equipo de cómputo 2 0 1 1 PROGRAMA DE ESTUDIO DATOS GENERALES N OM B R E DE L P R OGR A M A E DU CA T I V O: I n g en i erí a en Si st emas Comp u t aci on al es

OB J E T I V O DE L P R OGR A M A E DU CA T I V O:Formar p rof esi on i st as comp et en t es p ara: esp eci f i car, d i señ ar, con st ru i r, i mp l an t ar, veri f i car, au d i t ar, eval u ar y man t en er si st emas d e t ecn ol og í as d e l a i n f ormaci ón q u e resp on d an a l as n ecesi d ad es d e su s u su ari os, mej oran d o l os n i vel es d e ef i ci en ci a, ef i caci a y p rod u ct i vi d ad d e l as org an i z aci on es en el en t orn o g l ob al i z ad o, t oman d o en cu en t a el f act or h u man o.

T OT A L HR S. DE L CU A T R I M E ST R E : 75 FE CHA DE E M I SI ÓN : Sep t i emb re, 2011

U N I V E R SI DA DE S P A R T I CI P A N T E S: U n i versi d ad P ol i t écn i ca d e A g u ascal i en t es N OM B R E DE L A A SI GN A T U R A : P ri n ci p i os d e I n g en i erí a d e Sof t w are

CL A V E DE L A A SI GN A T U R A : P I S- E S

OB J E T I V O DE L A A SI GN A T U R A : E l al u mn o será cap az d e d esarrol l ar p roy ect os d e sof t w are h aci en d o u so d e t écn i cas, h errami en t as y met od ol og í as u t i l i z ad as en l a emp resa.

P A R A L A E N SE Ñ A N ZA ( PR OF E SOR ) P A R A E L A P R E N DI ZA J E ( A LU M N O)

A ULA LA B ORA TORI O OTRO

CON T E N I DOS P A R A L A FOR M A CI ÓN E ST R A T E GI A DE A P R E N DI ZA J E E V A L U A CI ÓN

OB SE RVACI ÓN U N I DA DE S DE A P R E N DI ZA J E R E SU L T A DOS DE A P R E N DI ZA J E E V I DE N CI A S T É CN I CA S SU GE R I DA S E SP A CI O E DU CA T I V O PROY EC TO PRÁ C TI C A T E ÓR I CA P R Á CT I CA T É CN I CA I N ST R U M E N T O M OV I L I DA D FOR M A T I V A MA TERI A LES REQUERI D OS EQUI POS REQUERI D OS T OT A L DE HOR A S

1. I n t rod u cci ón a l a i n g en i erí a d e sof t w are

E C1: Resuelve cuestionario sobre fundamentos de la ingeniería de software y modelos del proceso de software. Documental Cuestionario sobre fundamentos de la ingeniería de software y modelos del proceso de software.

2. Gest i ón d e p roy ect os d e sof t w are

E P 1: Elabora el plan de trabajo de un proyecto de desarrollo de software.

N/A Documental

Lista de cotejo para el plan de trabajo de un proyecto de desarrollo de software.

4. Di señ o y con st ru cci ón

5. V al i d aci ón d el sof t w are

E P 1: Elabora el plan de pruebas para el software de un proyecto de desarrollo de software.

N/A Documental

Lista de cotejo para revisión del plan de pruebas generado para validar el software de un proyecto de desarrollo de software. Se sugiere que el proyecto de desarrollo de software sea el proyecto final de la materia, el cual se podrá ir complementando en cada unidad con los diferentes productos generados, de acuerdo a los requisitos sugeridos en el Anexo 2 del Manual de la Asignatura, o los que el profesor indique.

3. R eq u eri mi en t os d el si st ema E P 1: Elabora el documento de especificación de requerimientos de un proyecto de desarrollo de software. Documental

Lista de cotejo para el documento de especificación de requerimientos de un proyecto de desarrollo de software. Se sugiere que el proyecto de desarrollo de software sea el proyecto final de la materia.

Se sugiere que el proyecto de desarrollo de software sea el proyecto final de la materia.

(8)

FICHA TÉCNICA

PRINCIPIOS DE INGENIERÍA DE SOFTWARE

Nombre: PRINCIPIOS DE INGENIERÍA DE SOFTWARE

Clave: PIS-ES

Justificación: Para conocer las exigencias y las metodologías más comunes en el desarrollo profesional de aplicaciones. Objetivo: El alumno será capaz de desarrollar proyectos de software haciendo uso de técnicas, herramientas y metodologías utilizadas en la empresa.

Habilidades: Lectura, escritura, interlocución, síntesis de la información, aplicación de principios tecnológicos, relaciones en y con el entorno organizacional, relaciones interpersonales, toma de decisiones, lectura en segunda lengua. Competencias

genéricas a desarrollar:

Capacidad de análisis y síntesis; para resolver problemas; para aplicar los conocimientos en la práctica; para gestionar la información; y para trabajar en forma autónoma y en equipo.

Capacidades a desarrollar en la asignatura

Competencias a las que contribuye la

asignatura

 Determinar arquitectura

(hardware/software) para cubrir los requerimientos del cliente mediante el

análisis de las necesidades y

requerimientos.

 Proponer el plan de desarrollo de la solución propuesta para cubrir las expectativas del cliente a través del análisis del sistema.

 Estructurar requerimientos funcionales y no funcionales del sistema informático mediante un lenguaje de modelado, para cumplir con las expectativas del cliente.

 Verificar componentes del sistema en el diseño para satisfacer las necesidades del cliente, mediante la semántica propuesta por el modelo.

 Diagnosticar requerimientos del cliente para identificar los elementos que conforman el sistema informático, mediante técnicas diagnósticas a través de encuestas de levantamiento de datos.

 Esquematizar requerimientos del cliente por medio de un lenguaje de modelado para garantizar el desarrollo óptimo del sistema.

(9)

 Seleccionar estándares de desarrollo para garantizar el éxito del sistema de acuerdo al análisis de las necesidades del cliente.

 Probar sistemas de información para el funcionamiento adecuado del mismo, mediante el uso de métodos de prueba.

 Evaluar funcionamiento de sistemas de

información para garantizar el

funcionamiento óptimo del diseño propuesto a través de métodos de prueba.

l

Estimación de tiempo (horas) necesario para transmitir el aprendizaje al alumno, por Unidad de

Aprendizaje:

Unidades de aprendizaje

HORAS TEORÍA HORAS PRÁCTICA

Presencial No presencial Presencial No presencial 1.Introducción a la ingeniería de software 4 0 1 2 2.Gestión de proyectos de software 6 0 2 2 3.Requerimientos del sistema 15 0 5 5 4.Diseño y construcción 13 0 4 4 5.Validación del Software 7 0 3 2

Total de horas por

cuatrimestre: 75

Total de horas por

semana: 5

(10)

Nombre de la asignatura: Principios de Ingeniería de Software Nombre de la Unidad de

Aprendizaje: 1. Introducción a la ingeniería de software

Nombre de la práctica o

proyecto: Proceso de software y modelos del proceso de software.

Número: 1 Duración (horas) : 1 hr.

Resultado de aprendizaje:

Seleccionar el modelo del proceso de software para un proyecto de desarrollo de acuerdo a sus características.

Requerimientos (Material

o equipo): Equipo de cómputo y cañón.

Actividades a desarrollar en la práctica:

 El profesor:

o Diseñará y utilizará diagramas, ilustraciones y esquemas para guiar las prácticas de los alumnos para la selección del modelo del proceso de software para un proyecto de desarrollo de acuerdo a sus características.

 El alumno:

o Realizará práctica mediante la acción para:

 Reforzar los conceptos sobre Proceso de software y Modelos del Proceso de Desarrollo de Software.

 Elegir el modelo de proceso de software para el proyecto de desarrollo que el profesor le indique o el proyecto final de la asignatura.

Se sugieren las siguientes actividades para la práctica del alumno: 1. Lea el documento2 que el profesor le entregue y realice lo siguiente :

a. Identifique las principales etapas del proceso de desarrollo de software y cuál sería el producto principal de cada etapa.

b. Elabore un cuadro sinóptico sobre las etapas del proceso de software.

2. Explique brevemente las cuatro “P’s” de la Ingeniería de Software (Proceso, Proyecto, Producto y Personas).

3. Forme equipo con tres compañeros y discutan cuál de los cuatro elementos principales de la ingeniería de software es el más importante, cada uno debe tomar partido por uno de los elementos (4 P’s). Comenten sus conclusiones con el resto del grupo.

2Documentos sugeridos: Del libro Ingeniería de Software, Una perspectiva Orientada a Objetos, de Eric J. Braude, (2003), la Introducción, págs. 1-7 y el capítulo 1”El Proceso”, págs. 16-33.

(11)

4. Realice un cuadro sinóptico de las características de los modelos de proceso genéricos para el desarrollo de software.

5. Resuelva el siguiente ejercicio3:

a. Sugiera el modelo de proceso de software genérico que podría utilizarse para gestionar el desarrollo de los siguientes sistemas, dando algunas razones basadas en el tipo de sistema a desarrollar:

i. Un sistema de control antibloqueo de frenos de un automóvil.

ii. Un sistema de realidad virtual para ayudar al mantenimiento del software. iii. Un sistema de contabilidad universitaria que reemplace el existente.

iv. Un sistema interactivo que permita a los pasajeros encontrar los horarios de los trenes a partir de las terminales instaladas en las estaciones.

6. Seleccione el modelo de proceso de software que aplicará para el desarrollo del proyecto que el profesor le sugiera o para el proyecto final de la materia y explique sus razones para la selección. 7. Anexe a su reporte de práctica las conclusiones del punto número 3 y los resultados de los puntos

5 y 6.

Evidencias a las que contribuye el desarrollo de la práctica:

EP1: Elabora reporte de práctica "Proceso de software y modelos del proceso de software".

3 Ejercicio 4.1 del libro: Summerville, Ian; Ingeniería del Software, Séptima edición, Madrid, 2005, Pearson Educacion, S. A., pág. 83.

(12)

INSTRUMENTOS

DE

(13)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Tema:

Fundamentos de la ingeniería de software y modelos del proceso de software.

Unidad de Aprendizaje: Introducción a la ingeniería de software

Fecha:

Asignatura: Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Estimado usuario:

 Usted tiene en las manos un instrumento de evaluación que permitirá fundamentar las actividades que ha demostrado a través de su desempeño o en la entrega de sus productos.

 Conteste los siguientes planteamientos de manera clara.

Le recordamos tomar el tiempo necesario para contestar y desarrollar su contenido.

ASPECTO

1. Conteste lo que se le pide:

a. Dé su definición de ingeniería de software.

b. ¿Qué características debe cubrir un producto de software terminado?

c. Existen diferentes modelos del proceso de desarrollo de software y cada uno presenta diferentes fases, ¿Cuáles son las 4 fases en las que se pueden agrupar de manera genérica los procesos de la ingeniería de software?

d. ¿Por qué es importante la ingeniería de software? e. ¿Qué es la ingeniería de sistemas?

f. Mencione 3 modelos de procesos de desarrollo de software, explique brevemente sus fases y mencione sus principales características.

g. ¿A todos los proyectos de desarrollo se les puede aplicar el mismo modelo de procesos de desarrollo?

h. ¿Qué se debe considerar en un proyecto de desarrollo para la elección del modelo de procesos de desarrollo?

i. Con respecto a los costos de un proyecto de desarrollo ¿cómo se distribuyen las erogaciones a lo CUESTIONARIO SOBRE FUNDAMENTOS DE LA INGENIERÍA DE SOFTWARE Y

MODELOS DEL PROCESO DE SOFTWARE U1, EC1

(14)

largo del proceso?

j. ¿Qué son los sistemas heredados? ¿Cómo se deben de manejar los sistemas heredados al momento de realizar un análisis de sistemas para la mejora de los procesos de una organización? k. ¿Qué es la ingeniería de requerimientos?

l. Explique cómo afectan las modificaciones a los requerimientos en las diferentes etapas del proceso de desarrollo.

m. ¿Qué es la administración de la configuración del software?

n. ¿Qué son las herramientas CASE? Presente una clasificación de las mismas. o. Explique brevemente el modelo RUP (Rational Unified Process).

(15)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. El reporte cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje técnico apropiado.

25%

Contenido. El reporte contiene todos los elementos solicitados en las especificaciones para un reporte de práctica (Número mínimo de cuartillas, introducción, desarrollo, indicadores de resultados, conclusiones, fuentes bibliográficas, entrega de archivos en caso de así solicitarlo la práctica, etc.).

10%

Introducción y Objetivo. La introducción y el objetivo dan una idea clara del contenido del reporte, motivando al lector a continuar con su lectura y revisión.

10% Sustento Teórico. Presenta un panorama general del tema a desarrollar y lo sustenta con referencias bibliográficas.

20%

Desarrollo. Sigue una metodología y sustenta todos los pasos que se realizaron al aplicar los conocimientos obtenidos, es analítico y bien ordenado.

LISTA DE COTEJO PARA REPORTE DE PRÁCTICA U1, EP1

(16)

15% Resultados. Cumplió totalmente con el objetivo esperado. 5% Conclusiones. Las conclusiones son claras y acordes con el objetivo esperado.

5% Responsabilidad. Entregó el reporte en la fecha y hora señalada.

(17)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. El documento cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje técnico apropiado.

 Número mínimo de cuartillas

 Portada

40%

Contenido. El documento contiene todos los elementos solicitados en las especificaciones del proyecto: *Índice

*Introducción *Desarrollo:

 Propuesta de la solución informática a desarrollar o Antecedentes

o Definición del problema (Plantea el problema a resolver de manera clara)

o Descripción de la solución planteada (Presenta los elementos generales de la solución de manera clara y establece los límites de la misma) o Justificación (Justifica el desarrollo del proyecto

sustentando teóricamente su planteamiento) o Ámbito (Define claramente los datos a procesar, el

control requerido, la funcionalidad, el rendimiento, las restricciones, las interfaces y la fiabilidad del

LISTA DE COTEJO PARA EL PLAN DE TRABAJO DE UN PROYECTO DE

DESARROLLO DE SOFTWARE U2, EP1

(18)

sistema)

o Estudio de viabilidad (Está debidamente

justificado el proyecto en las cuatro dimensiones: Tecnológica, Financiera, Tiempo y Recurso) o Requerimientos de recursos (HW SW) o Estimación de costos y tiempos

 Plan del proyecto

o Organización del equipo de trabajo (gente involucrada y roles ; conforma el equipo de desarrollo considerando las características del proyecto y de las personas)

o Programa del proyecto (calendarización, utiliza gráfica de Gantt, los tiempos son razonables y los recursos están distribuidos eficientemente) o Análisis de riesgos y plan de reducción,

supervisión y gestión del riesgo (Define los riesgos claramente y las acciones para su control son viables).

o Mecanismos de supervisión (establece

mecanismos claros y útiles para el seguimiento del plan del proyecto)

* Conclusiones

* Fuentes bibliográficas

10%

Introducción y Objetivo. La introducción y el objetivo dan una idea clara del contenido del trabajo, motivando al lector a continuar con su lectura y revisión.

15%

Desarrollo. Sigue una metodología y sustenta todos los pasos que se realizaron al aplicar los conocimientos obtenidos, es analítico y bien ordenado.

15% Resultados. Cumplió totalmente con el objetivo esperado. 5% Conclusiones. Las conclusiones son claras y acordes con el objetivo esperado.

5% Responsabilidad. Entregó el documento en la fecha y hora señalada.

(19)

UNIVERSIDAD POLITÉCNICA DE __________________________ NOMBRE DE LA ASIGNATURA _____________________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Tema a Exponer: Fecha: Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

5% Puntualidad para iniciar y concluir la exposición. 5% Esquema de diapositiva. Colores y tamaño de letra

apropiada. Sin saturar las diapositivas de texto. 5%

Portada: Nombre de la escuela (logotipo), Carrera, Asignatura, Profesor, Alumnos, Matricula, Grupo, Lugar y fecha de entrega.

5% Ortografía (cero errores ortográficos).

5% Exposición

a. Utiliza las diapositivas como apoyo, no lectura total 5% b. Desarrollo del tema fundamentado y con una secuencia

estructurada 40%

c. Contenido (ver nota): Tipos de requerimientos Documento de requerimientos Fases de la ingeniería de requisitos:

GUIA DE OBSERVACIÓN PARA EXPOSICIÓN INDIVIDUALES/EQUIPO DE LA PRESENTACIÓN DE CONCEPTOS DE REQUERIMIENTOS DEL SISTEMA

(20)

 Estudio de viabilidad.

 Identificación u obtención de requerimientos y análisis.

 Especificación de requerimientos.

 Modelado del sistema.

 Validación de requerimientos.

 Gestión de requerimientos.

5% d. Organización de los integrantes del equipo 5% e. Expresión no verbal (gestos, miradas y lenguaje

corporal).

15% Preparación de la exposición. Dominio del tema. Habla con seguridad.

5% Presentación y limpieza

100% CALIFICACIÓN

Nota: El contenido de la exposición se puede distribuir entre diferentes equipos y evaluar la

parte que corresponda a cada equipo.

(21)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. El documento cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje técnico apropiado.

 Número mínimo de cuartillas

 Portada

40%

Contenido. El documento contiene todos los elementos solicitados en las especificaciones del proyecto: *Índice

*Introducción

*Objetivos del trabajo *Desarrollo:

 Análisis de requerimientos: o Contexto del sistema o Modelo de procesos

o Definición de los requisitos funcionales y no funcionales del cliente para el sistema. o Descripción de los escenarios o casos de uso. o Identificación de Clases y objetos del sistema. o Tarjetas CRC

(Clases-Responsabilidades-Colaboraciones)

o Identificación de atributos y operaciones para

LISTA DE COTEJO PARA EL DOCUMENTO DE ESPECIFICACIÓN DE

REQUERIMIENTOS DE UN PROYECTO DE DESARROLLO DE SOFTWARE U3, EP1

(22)

cada objeto del sistema.

 Modelos del Análisis

o Especificación de jerarquía de clases

(Especialización-Generalización y Agregación) o Modelo de casos de uso del problema a resolver o Modelo objeto-relación (Diagrama de clases). o Modelo de datos (Diagrama de clases simplificado

y Diccionario de datos)

o Modelo objeto-comportamiento (Flujo de datos, secuencia, colaboración, estados, actividad)*. o Validación de los modelos

* Conclusiones

* Fuentes bibliográficas

* Pueden ser uno o dos de los modelos objeto mencionados más el flujo de datos si el problema lo requiere.

10%

Introducción y Objetivo. La introducción y el objetivo dan una idea clara del contenido del trabajo, motivando al lector a continuar con su lectura y revisión.

15%

Desarrollo. Sigue una metodología y sustenta todos los pasos que se realizaron al aplicar los conocimientos obtenidos, es analítico y bien ordenado.

15% Resultados. Cumplió totalmente con el objetivo esperado. 5% Conclusiones. Las conclusiones son claras y acordes con el objetivo esperado.

5% Responsabilidad. Entregó el documento en la fecha y hora señalada.

(23)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. El documento cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje técnico apropiado.

 Número mínimo de cuartillas

 Portada

40%

Contenido. El documento contiene todos los elementos solicitados en las especificaciones del proyecto: *Índice

*Introducción

*Objetivos del trabajo *Desarrollo:

 Diseño del software o Contexto del software

 Modelo estático (asociaciones de

subsistemas) y dinámico (casos de uso de la interacción de los subsistemas)

o Diseño Arquitectónico (Arquitectura del software):

 Modelo estructural de los subsistemas

 Modelo de organización de subsistemas

 Modelo de descomposición de subsistemas

 Modelo de control

LISTA DE COTEJO PARA EL DOCUMENTO DE ESPECIFICACIÓN DEL DISEÑO

DE SOFTWARE DE UN PROYECTO DE DESARROLLO DE SOFTWARE U4, EP1

(24)

o Descripción del conjunto de subsistemas del software

 Diagramas de casos de uso de la solución

 Descripción de casos de uso o Diseño de objetos

 Identificación de objetos y asignación de clases a subsistemas

 Descripción de clases

 Asignación de tareas.

 Identificación de responsabilidades y colaboraciones

 Diseño de los atributos y operaciones.

 Modelo objeto-relación (Diagrama de clases detallado).

 Modelo objeto-comportamiento detallado (Flujo de datos, secuencia, colaboración, actividad)

 Modelo de paso de mensajes o Comunicación entre subsistemas

o Diseño de la interfaz de usuario (prototipo) o Estrategia de gestión de datos (basada en el

Modelo de datos del análisis y en los objetos diseñados.

o Mecanismo para Control de concurrencia (en caso de existir)

 Diseño del componente de gestión de tareas (en caso de concurrencia).

o Mecanismos de control para el acceso a recursos o Diseño de algoritmos y estructuras de datos * Conclusiones

* Fuentes bibliográficas

10% Introducción y Objetivo. La introducción y el objetivo dan una idea clara del contenido del trabajo, motivando al lector a continuar con su lectura y revisión.

15%

Desarrollo. Sigue una metodología y sustenta todos los pasos que se realizaron al aplicar los conocimientos obtenidos, es analítico y bien ordenado.

15% Resultados. Cumplió totalmente con el objetivo esperado. 5% Conclusiones. Las conclusiones son claras y acordes con el objetivo esperado.

5% Responsabilidad. Entregó el documento en la fecha y hora señalada.

(25)

UNIVERSIDAD POLITÉCNICA DE __________________________ NOMBRE DE LA ASIGNATURA _____________________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Tema a Exponer: Fecha: Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

5% Puntualidad para iniciar y concluir la exposición. 5% Esquema de diapositiva. Colores y tamaño de letra

apropiada. Sin saturar las diapositivas de texto. 5%

Portada: Nombre de la escuela (logotipo), Carrera, Asignatura, Profesor, Alumnos, Matricula, Grupo, Lugar y fecha de entrega.

5% Ortografía (cero errores ortográficos).

5% Exposición

a. Utiliza las diapositivas como apoyo, no lectura total 5% b. Desarrollo del tema fundamentado y con una secuencia

estructurada 40%

c. Contenido:

 Técnica o método de programación a utilizar (características).

 Motivos de la selección de la técnica o método de

GUIA DE OBSERVACIÓN PARA EXPOSICIÓN INDIVIDUALES/EQUIPO DE MOTIVOS DE LA SELECCIÓN DE LA TÉCNICA DE PROGRAMACIÓN Y EL

LENGUAJE DE PROGRAMACIÓN A UTILIZAR EN UN PROYECTO DE DESARROLLO

(26)

programación a utilizar.

 Lenguaje de programación a utilizar (características).

 Motivos de la selección del lenguaje de programación a utilizar.

5% d. Organización de los integrantes del equipo. 5% e. Expresión no verbal (gestos, miradas y lenguaje

corporal).

15% Preparación de la exposición. Dominio del tema. Habla con seguridad.

5% Presentación y limpieza.

(27)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. El plan cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje técnico apropiado.

 Número mínimo de cuartillas

 Portada

40%

Contenido. El documento contiene todos los elementos solicitados en las especificaciones del plan:

*Índice *Introducción

*Objetivos del trabajo *Desarrollo:

 Pruebas del software

o Selección de la Prueba de unidad (PE) o de clase (POO), (verificación al azar, partición, etc.)

 Especificar la prueba a utilizar y explicar el porqué de la selección (No diseñar las pruebas).

o Selección de la Prueba de integración (top down, bottom-up, en PE) y pruebas basadas en el hilo, pruebas basadas en el uso, pruebas de

agrupamiento (POO)

LISTA DE COTEJO PARA EL PLAN DE PRUEBAS PARA EL SOFTWARE DE UN PROYECTO DE DESARROLLO DE SOFTWARE

(28)

 Especificar la prueba a utilizar y explicar el porqué de la selección (No diseñar las pruebas).

o Diseño de la Prueba de validación (Método de la caja negra para ambos paradigmas)

 Diseñar y aplicar una prueba alfa para el software generado

 Diseñar y aplicar una prueba beta para el software generado

 Reporte de resultados

o Generar un reporte de resultados de las pruebas del software.

* Conclusiones

* Fuentes bibliográficas

10%

Introducción y Objetivo. La introducción y el objetivo dan una idea clara del contenido del trabajo, motivando al lector a continuar con su lectura y revisión.

15%

Desarrollo. Sigue una metodología y sustenta todos los pasos que se realizaron al aplicar los conocimientos obtenidos, es analítico y bien ordenado.

15% Resultados. Cumplió totalmente con el objetivo esperado. 5%

Conclusiones. Las conclusiones son claras y acordes con el objetivo esperado.

5% Responsabilidad. Entregó el plan en la fecha y hora señalada.

(29)

GLOSARIO

Artefacto:

Cualquier tipo de datos, código fuente o información producida o usada por un

desarrollador durante el proceso de desarrollo; se usa en particular al describir el proceso

de desarrollo de software unificado (Unified Software Development Process).

Aplicación

:

Cualquier programa que corra en un sistema operativo y que haga una función

específica para un usuario. Por ejemplo, procesadores de palabras, bases de datos,

agendas electrónicas, etc.

Código fuente: Conjunto de instrucciones que componen un programa, escrito en cualquier

lenguaje. En inglés se dice "source code". Hay programas de código abierto y "de código

cerrado" como por ejemplo Windows, Photoshop, y la mayoría de los programas comerciales,

en donde el código es inaccesible y por lo tanto no se puede alterar la estructura del

programa.

Construcción del sistema

:

Proceso de compilar los componentes o unidades que forman un

sistema y enlazarlos con otros componentes para crear un programa ejecutable. La

construcción del sistema está normalmente automatizada de modo que se minimiza la

re-compilación. Ésta automatización puede ser incorporada a un sistema de procesamiento de

lenguajes (como en Java) o puede implicar herramientas CASE para apoyar la construcción

del sistema.

Hardware. Representa los componentes físicos que constituyen la computadora, es decir,

todos los elementos materiales.

Herramientas CASE: Herramienta software, como un editor del diseño o un depurador de

programas, utilizada para apoyar una actividad en el proceso de desarrollo del software.

Ingeniería de Software. La ingeniería del software es el establecimiento y uso de principios

robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que

funcione eficientemente sobre máquinas reales.

Método: Modo de decir o hacer con orden.

Metodología: Conjunto de métodos que se siguen en una investigación científica o en una

exposición doctrinal.

Métrica: Especificación para cómo medir un artefacto de ingeniería de software. Por ejemplo

líneas de código es una medición para el código fuente.

Modelo: Esquema teórico, generalmente en forma matemática, de un sistema o de una

realidad compleja, que se elabora para facilitar su comprensión y el estudio de su

comportamiento.

(30)

Proceso: Conjunto de las fases sucesivas de un fenómeno natural o de una operación

artificia.

Proceso de software. Es el orden en que se realizan las actividades de desarrollo de

software.

Requerimientos del sistema: En la ingeniería de sistemas, un requerimiento es una

necesidad documentada sobre el contenido, forma o funcionalidad de un producto o

servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de

software. En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la

etapa de diseño del producto. Establecen “qué” debe hacer el sistema, pero “no cómo”

hacerlo.

Sistema

:

Conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a

determinado objeto.

Software. Programas de computadoras, son las instrucciones responsables de que el

hardware (la máquina) realice su tarea.

Validación: Proceso de verificar que un sistema cumple las necesidades y expectativas del

cliente.

4

4 El glosario se construyó a partir de las siguientes referencias: Diccionario de la Real Academia Española, Dicccionario recuperado de http://www.rae.es/.

(31)

BIBLIOGRAFÍA

Básica

1.

Ingeniería de Software – Un Enfoque Práctico

PRESSMAN, Roger S.

2010

Mc Graw Hill Interamericana

Séptima edición; México; 2010

ISBN 9786071503145

2.

UML

PODESWA, Howard

2010

Anaya Multimedia-Anaya Interactiva

España; 2010

ISBN 9788441527195

3.

Ingeniería del Software

SOMMERVILLE, Ian

2011

Pearson Addison-Wesley

Novena edición; México; 2011

ISBN 9786073206037

Complementaria

1.

Sistemas de Información Gerencial – Administración de la Empresa Digital

LAUDON, Kenneth C., LAUDON, Jane P.

2008

Pearson – Prentice Hall

Décima edición; México; 2008

ISBN 970-26-1191-1

(32)

2.

Programación en C/C++, JAVA Y UML

JOYANES, Luis

2009

McGraw-Hill Interamericana

México; 2009

ISBN: 9789701069493

3.

Software Engineering: Theory and Practice

PFLEEGER, Shari Lawrence

2009

Prentice Hall

Cuarta edición; USA; 2009

ISBN 013-60-6169-9

(33)

ANEXOS

ANEXO 1 LINEAMIENTOS PARA PRESENTAR TRABAJOS O REPORTES ESCRITOS

UNIVERSIDAD POLITÉCNICA DE AGUASCALIENTES

LINEAMIENTOS PARA PRESENTAR TRABAJOS O REPORTES ESCRITOS

Los trabajos que se presenten deberán tener las siguientes partes:

A. PARTES DEL TRABAJO

1.

PORTADA (ver características al final)

2.

ÍNDICE

3.

INTRODUCCIÓN

4.

DESARROLLO DEL TEMA

5.

CONCLUSIÓN U OPINIÓN PERSONAL

6.

GLOSARIO DE TÉRMINOS CON SU SIGNIFICADO (las 10 palabras claves del tema, por

lo menos)

7.

BIBLIOGRAFÍA

(Mínimo 3 referencias distintas, deberá basarse al menos en un libro, si realizó búsqueda en

internet poner las ligas a los documentos consultados).

B. MÁRGENES

PARTE SUPERIOR E INFERIOR DE LA HOJA:

3 CM

PARTE DERECHA E IZQUIERDA:

2.5 CM

ESPACIO ENTRE CARACTERES:

Normal

INTERLINEADO:

Normal

C. TIPO DE LETRA Y TAMAÑO

TIPO DE LETRA:

Arial

TAMAÑO TEXTO:

11

TíTULOS DE TEMAS:

14

(34)

D. INTERLINEADO Y ESPACIOS

INTERLINEADO:

Sencillo

ESPACIO:

Normal

CARACTERISTICAS DEL LA PORTADA

PARTE SUPERIOR:

(de manera centrada)

Nombre y logo de la Universidad Politécnica de Aguascalientes

Nombre de la carrera a la que pertenece.

PARTE CENTRAL:

(de manera centrada)

El título del trabajo

PARTE INFERIOR:

(izquierda)

Materia

Nombre del profesor que imparte la materia

Nombre del alumno que presenta el trabajo

Grupo al que pertenece

(35)

ANEXO 2 PROPUESTA DE PROYECTO FINAL Y LISTA DE COTEJO PARA EL MISMO

Nombre de la asignatura: Principios de Ingeniería de Software Nombre de la Unidad de

Aprendizaje:

Nombre de la práctica o

proyecto: Proyecto Final de Principios de Ingeniería de Software

Número: Duración (horas) : Desarrollo a lo largo del

curso Resultado de

aprendizaje: Integra los conocimientos y habilidades desarrolladas en la materia

Requerimientos (Material o equipo):

Equipo de cómputo con herramientas de modelado y desarrollo de software instaladas

Actividades a desarrollar en la práctica:

Implementación de un Proyecto de Desarrollo de Software que resuelva una problemática real, siguiendo los métodos y técnicas de la ingeniería de software, para el análisis, diseño, desarrollo e implementación del software, así como para la gestión del proyecto de desarrollo.

Puntos a evaluar:

 Carta de permiso de la empresa para realizar el proyecto.

 Carta de satisfacción del proyecto por parte de la empresa.

 Diseño (de acuerdo a las necesidades de la empresa).

 Ergonomía de la interfaz (facilidad de uso).

 Funcionalidad de acuerdo a los requisitos del usuario.

 Ortografía en todos los reportes generados.

 Puntualidad en la entrega de los artefactos generados. Documentación:

 Una Propuesta inicial del proyecto, la cual debe incluir los siguientes puntos en base al formato del archivo “Trabajos escritos”:

o Portada o Índice o Introducción  Breve Introducción  Antecedentes de la Empresa  Datos generales  Detección de necesidades

(36)

 Situación Observada

 Situación Deseada

 Definición del Problema

 Solución propuesta a la Problemática

o Desarrollo

 Definición del proyecto  Justificación

 Objetivo general y especifico del proyecto  Ámbito del sistema

 Estudio de viabilidad

 Requerimientos de recursos (HW SW)  Estimación de costos y tiempos

o Conclusión de la propuesta presentada

o Glosario

o Bibliografía

 Plan del proyecto:

o Organización del equipo de trabajo

o Programa del proyecto (calendarización

o Análisis de riesgos y plan de reducción, supervisión y gestión del riesgo

o Mecanismos de supervisión del plan

 Análisis de requerimientos:

o Contexto del sistema (Dominio)

o Modelo de procesos de la problemática a resolver

o Definición de los requisitos funcionales y no funcionales del cliente para el sistema.

o Descripción de los escenarios o casos de uso.

o Identificación de clases y objetos del sistema.

o Tarjetas CRC (Clases-Responsabilidades-Colaboraciones)

o Atributos y operaciones para cada objeto del sistema.

o Modelos del Análisis

 Especificación de jerarquía de clases (Especialización-Generalización y Agregación)

 Modelo de casos de uso

 Modelo objeto-relación (diagrama de clases).

 Modelo de datos (diagrama de clases simplificado y Diccionario de datos)  Modelo objeto-comportamiento (flujo de datos, secuencia, colaboración,

estados, actividad).

 Diseño del software:

o Contexto del software

 Modelo estático (asociaciones de subsistemas) y dinámico (casos de uso de la interacción de los subsistemas)

o Diseño Arquitectónico (Arquitectura del software):  Modelo estructural de los subsistemas  Modelo de organización de subsistemas  Modelo de descomposición de subsistemas  Modelo de control

(37)

 Diagramas de casos de uso de la solución  Descripción de casos de uso

o Diseño de objetos

 Objetos del sistema y asignación de clases a subsistemas  Descripción de clases

 Asignación de tareas a las clases.  Responsabilidades y colaboraciones  Diseño de los atributos y operaciones.

 Modelo objeto-relación (Diagrama de clases detallado).

 Modelo objeto-comportamiento detallado (Flujo de datos, secuencia, colaboración, actividad)

 Modelo de paso de mensajes

o Comunicación entre subsistemas

o Diseño de la interfaz de usuario (prototipo)

o Estrategia de gestión de datos (basada en el Modelo de datos del análisis y en los objetos diseñados.

o Mecanismo para Control de concurrencia (en caso de existir)

 Diseño del componente de gestión de tareas (en caso de concurrencia).

o Mecanismos de control para el acceso a recursos

o Diseño de algoritmos y estructuras de datos

 Pruebas del sistema

o Diseño de pruebas de caja negra (validación, alfa y beta)

o Resultados de las pruebas.

Nota: Ver lista de cotejo para evaluación del Proyecto final.

Todos los documentos generados deberán de entregarse con: Portada, índice, introducción, desarrollo (aquí se incluye el plan o análisis o diseño, etc.), conclusiones y fuentes bibliográficas.

(38)

UNIVERSIDAD POLITÉCNICA DE __________________________

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s): Matrícula: Firma del alumno(s):

Producto: Nombre del Proyecto: Fecha:

Asignatura Periodo cuatrimestral:

Nombre del docente: Firma del docente:

INSTRUCCIONES

Revisar las actividades que se solicitan y marque en los apartados “SI” cuando la evidencia se cumple; en caso contrario marque “NO”. En la columna “OBSERVACIONES” indicaciones que puedan ayudar al alumno a saber cuáles son las condiciones no cumplidas, si fuese necesario.

Valor del

reactivo Característica a cumplir (Reactivo)

CUMPLE

OBSERVACIONES

SI NO

10%

Presentación. La página cumple con los requisitos de:

 Buena presentación

 No tiene faltas de ortografía

 Maneja el lenguaje apropiado.

20% Diseño. La página cumple con las características de diseño de acuerdo a las necesidades del usuario 10% Ergonomía. Facilidad de uso

40%

Contenido. Cumple con las especificaciones del usuario (verificar con los requisitos del usuario):

 Elaborar lista de requisitos de acuerdo al proyecto de cada alumno/equipo.

5% Actitud. Al trabajar en equipo

10% Resultados. Cumplió totalmente con el objetivo esperado. 5% Responsabilidad. Entregó el producto en la fecha y hora señalada.

100% CALIFICACIÓN

LISTA DE COTEJO PARA EVALUACIÓN DE PROYECTO INTEGRADOR

(SOFTWARE GENERADO)

Referencias

Documento similar

[r]

SVP, EXECUTIVE CREATIVE DIRECTOR JACK MORTON

Social Media, Email Marketing, Workflows, Smart CTA’s, Video Marketing. Blog, Social Media, SEO, SEM, Mobile Marketing,

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

Para denegación hegeliana del mal: «Así como no existe lo fal- so, no existe el mal, es objetada primero por Sade y luego por la subjetividad romántica: en la mé- dula de la

Debido a que este proyecto pertenece al polo de Bioinformática y es un estándar o paradigma del polo el desarrollo de software libre utilizando el sistema operativo Linux, además

 Para recibir todos los números de referencia en un solo correo electrónico, es necesario que las solicitudes estén cumplimentadas y sean todos los datos válidos, incluido el

Este servicio es útil para los grupos y empresas desarrolladoras de software, ya que facilita la comunicación entre los clientes y la empresa e incrementa la calidad de los