De acuerdo a lo que les había enviado en el correo del pasado 24 de Agosto, el primer parcial lo estaremos llevando a cabo el día de mañana, éste incluye todas las temáticas, lecturas y exposiciones tratadas hasta la fecha y de las cuales se encuentra un registro general en el blog.
martes, 30 de agosto de 2011
miércoles, 24 de agosto de 2011
Primeros Entregables - Proyecto Semestre
El proyecto de semestre deben entregarlo el viernes 2 de septiembre a las 8:00AM (no se recibirán trabajos en una fecha u horario diferente).
Los documentos deben entregarse de forma impresa, cumpliendo con los estándares definidos en las normas ICONTEC para la presentación de trabajos.
El trabajo debe contener:
Descripción: Presenta la idea general del sistema a desarrollar.
Usuarios: Describe uno a uno los usuarios que usarán el sistema (no de forma nombrada sino por roles, por ejemplo: cajero, almacenista, supervisor, etc.), las condiciones que deben tenerse en cuenta y que debe cumplir el sistema cuando se encuentre en operación para satisfacer las necesidades de cada tipo de usuario en particular.
Requerimientos: En principio habíamos solicitado sólo cinco (5) requisitos, en esta oportunidad deben definirse todos los requisitos que por su naturaleza tenga cada proyecto en particular. Los requerimientos deben clasificarse de acuerdo a las definiciones que se dan en el capítulo 6 del libro Ingeniería del Software de Ian Sommerville (Disponible en Biblioteca).
Diagramas de Flujo: Construidos en el sistema DIA, adecuadamente paginados y documentados (sección para análisis de trazabilidad), anexando además aquellos documentos con los cuales tenga relación cada proceso, tales como: actas, facturas, entre otros. Cada diagrama debe seguir el estándar presentado en el ejemplo.
Los documentos deben entregarse de forma impresa, cumpliendo con los estándares definidos en las normas ICONTEC para la presentación de trabajos.
El trabajo debe contener:
Descripción: Presenta la idea general del sistema a desarrollar.
Usuarios: Describe uno a uno los usuarios que usarán el sistema (no de forma nombrada sino por roles, por ejemplo: cajero, almacenista, supervisor, etc.), las condiciones que deben tenerse en cuenta y que debe cumplir el sistema cuando se encuentre en operación para satisfacer las necesidades de cada tipo de usuario en particular.
Requerimientos: En principio habíamos solicitado sólo cinco (5) requisitos, en esta oportunidad deben definirse todos los requisitos que por su naturaleza tenga cada proyecto en particular. Los requerimientos deben clasificarse de acuerdo a las definiciones que se dan en el capítulo 6 del libro Ingeniería del Software de Ian Sommerville (Disponible en Biblioteca).
Diagramas de Flujo: Construidos en el sistema DIA, adecuadamente paginados y documentados (sección para análisis de trazabilidad), anexando además aquellos documentos con los cuales tenga relación cada proceso, tales como: actas, facturas, entre otros. Cada diagrama debe seguir el estándar presentado en el ejemplo.
Diagramas de Flujo
Recomiendo visitar los siguientes enlaces para ampliar información sobre la construcción de diagramas de flujo:
Conceptos Generales
Componentes de un Diagrama de Flujo
A continuación presento un ejemplo de diagrama de flujo, en el trabajo que van a presentar deben usar este formato. Este ejemplo fue construido usando el sistema DIA (Software Libre) y se exportó a PDF para publicarlo en el blog. Ejemplo.
En la parte superior del diagrama se encuentran los actores que intervienen en un proceso específico y en cada columna se colocan los procedimientos que realizan, respectivamente. El diagrama debe nombrarse en principio con un verbo en infinitivo que denota una acción acompañado de cuatro o cinco palabras que den cuenta en términos generales el proceso que se busca representar. El diagrama de ejemplo muestra de forma coherente donde inicia, donde termina, además de los componentes que permiten representar: conexiones, procesos, almacenamientos y condicionales.
En la tarea de recopilar información para desarrollar sistemas (software) es de vital importancia el desarrollo de este tipo de diagramas los cuales ayudan a entender y discernir sí el proceso requiere depurarse para volverlo más eficiente, rentable, seguro, entre otras posibles; o si por el contrario, ya se encuentra listo para llevarse a la práctica, tal como se define. En esta misma tarea, es posible que se generen muchos diagramas (uno por proceso, por esto, en el ejemplo éste hace parte de un grupo de 183 procesos y se encuentra codificado para relacionarlo con mayor facilidad) y finalmente deben socializarse con el interesado en el producto software (contratante). Cada diagrama cuenta con unas líneas generales de documentación que permiten realizar análisis de trazabilidad en cualquier momento.
Conceptos Generales
Componentes de un Diagrama de Flujo
A continuación presento un ejemplo de diagrama de flujo, en el trabajo que van a presentar deben usar este formato. Este ejemplo fue construido usando el sistema DIA (Software Libre) y se exportó a PDF para publicarlo en el blog. Ejemplo.
En la parte superior del diagrama se encuentran los actores que intervienen en un proceso específico y en cada columna se colocan los procedimientos que realizan, respectivamente. El diagrama debe nombrarse en principio con un verbo en infinitivo que denota una acción acompañado de cuatro o cinco palabras que den cuenta en términos generales el proceso que se busca representar. El diagrama de ejemplo muestra de forma coherente donde inicia, donde termina, además de los componentes que permiten representar: conexiones, procesos, almacenamientos y condicionales.
En la tarea de recopilar información para desarrollar sistemas (software) es de vital importancia el desarrollo de este tipo de diagramas los cuales ayudan a entender y discernir sí el proceso requiere depurarse para volverlo más eficiente, rentable, seguro, entre otras posibles; o si por el contrario, ya se encuentra listo para llevarse a la práctica, tal como se define. En esta misma tarea, es posible que se generen muchos diagramas (uno por proceso, por esto, en el ejemplo éste hace parte de un grupo de 183 procesos y se encuentra codificado para relacionarlo con mayor facilidad) y finalmente deben socializarse con el interesado en el producto software (contratante). Cada diagrama cuenta con unas líneas generales de documentación que permiten realizar análisis de trazabilidad en cualquier momento.
Exposiciones
A continuación encontrarán los enlaces a las diapositivas presentadas por los compañeros en sus respectivas exposiciones, estos documentos deben tomarse como apoyo, sin embargo, las fuentes principales de estudio deben ser las relacionadas en la bibliografía del curso:
+ IEEE (Por: Luis Felipe Orozco)
SWEBOK
Requerimientos de Software
+ Definición de Requerimientos de Software (Por: Juan Manuel Angel)
+ Proceso de Requerimientos (Por: Daniel Cardona)
+ Análisis de Requerimientos (Por: Juan Pablo Serna G)
+ Especificación de Requerimientos según el SWEBOK (Por: Oscar Trujillo M)
+ IEEE 830 SRS Software Requirements Specifications (Por: Oscar Trujillo M)
+ Validación de Requerimientos de Software según el SWEBOK (Por: Jhonatan Marin)
Diseño de Software
+ Estructura y Arquitectura de Software según el SWEBOK (Por: Manuel Alejandro Vargas)
CALIDAD
Factores
+ Factores Internos y Externos (Por: Juan Manuel Angel)
Factores Internos
+ Documentación del Código Fuente (Por: Harwin Galvis)
Fuente adicional sobre Doxygen
+ Modularidad (Por: Luis Felipe Orozco)
Factores Externos
+ Corrección (Por: Julián Pescador)
+ Robustez (Por: Jorge Ivan Reyes)
+ Compatibilidad (Por: Jhonier Sierra)
+ Facilidad de Uso (Por: Daniel Cardona)
+ IEEE (Por: Luis Felipe Orozco)
Requerimientos de Software
+ Definición de Requerimientos de Software (Por: Juan Manuel Angel)
+ Proceso de Requerimientos (Por: Daniel Cardona)
+ Análisis de Requerimientos (Por: Juan Pablo Serna G)
+ Especificación de Requerimientos según el SWEBOK (Por: Oscar Trujillo M)
+ IEEE 830 SRS Software Requirements Specifications (Por: Oscar Trujillo M)
+ Validación de Requerimientos de Software según el SWEBOK (Por: Jhonatan Marin)
Diseño de Software
+ Estructura y Arquitectura de Software según el SWEBOK (Por: Manuel Alejandro Vargas)
CALIDAD
Factores
+ Factores Internos y Externos (Por: Juan Manuel Angel)
Factores Internos
+ Documentación del Código Fuente (Por: Harwin Galvis)
Fuente adicional sobre Doxygen
+ Modularidad (Por: Luis Felipe Orozco)
Factores Externos
+ Corrección (Por: Julián Pescador)
+ Robustez (Por: Jorge Ivan Reyes)
+ Compatibilidad (Por: Jhonier Sierra)
+ Facilidad de Uso (Por: Daniel Cardona)
jueves, 18 de agosto de 2011
Referencia Bibliográfica
Título: Construcción de Software Orientada a Objetos
Autor: Bertrand Meyer
Disponible en Biblioteca
Número Topográfico – 005.1 / M612
jueves, 11 de agosto de 2011
Lecturas
Lecturas sobre producto y proceso
Ingeniería del Software. Un enfoque práctico
Roger Pressman
Capítulos 1 y 2
http://es.scribd.com/doc/7978336/Ingenieria-de-Software-Un-Enfoque-Practico-Pressman-5th-Ed
Lectura sobre requerimientos:
Ingeniería del Software
Ian Sommerville
Capítulo 6
(Disponible en biblioteca)
http://books.google.com/books?id=gQWd49zSut4C&pg=PA105&hl=es&source=gbs_toc_r&cad=4#v=onepage&q&f=false
El quiz sobre estos temas será el próximo miércoles 17 de agosto.
Ingeniería del Software. Un enfoque práctico
Roger Pressman
Capítulos 1 y 2
http://es.scribd.com/doc/7978336/Ingenieria-de-Software-Un-Enfoque-Practico-Pressman-5th-Ed
Lectura sobre requerimientos:
Ingeniería del Software
Ian Sommerville
Capítulo 6
(Disponible en biblioteca)
http://books.google.com/books?id=gQWd49zSut4C&pg=PA105&hl=es&source=gbs_toc_r&cad=4#v=onepage&q&f=false
El quiz sobre estos temas será el próximo miércoles 17 de agosto.
miércoles, 3 de agosto de 2011
Clase 03 - Requerimientos
Requerimientos de Software
Requerimientos de Sistema
Procesos
Compromisos académicos:
1. Para el próximo viernes 5 de agosto, los estudiantes presentarán una propuesta de proyecto para trabajar durante el semestre (por grupos), incluyendo: objetivo general, modelo de negocio, 5 requerimientos funcionales, 5 requerimientos no funcionales, 5 requerimientos de software y 5 requerimientos de sistema.
2. Para el próximo viernes 5 de agosto, los estudiantes presentarán el trabajo propuesto en clase sobre procesos, del proceso estudiado, presentará:
Nombre del proceso:
Entradas:
Salidas:
Descripción:
Frecuencia: (corresponde al número de veces en promedio que se realiza el proceso en un día).
Diagrama de flujo:
Para crear el diagrama de flujo se propone usar la herramienta de software libre conocida como DIA
Requerimientos de Sistema
Procesos
Compromisos académicos:
1. Para el próximo viernes 5 de agosto, los estudiantes presentarán una propuesta de proyecto para trabajar durante el semestre (por grupos), incluyendo: objetivo general, modelo de negocio, 5 requerimientos funcionales, 5 requerimientos no funcionales, 5 requerimientos de software y 5 requerimientos de sistema.
2. Para el próximo viernes 5 de agosto, los estudiantes presentarán el trabajo propuesto en clase sobre procesos, del proceso estudiado, presentará:
Nombre del proceso:
Entradas:
Salidas:
Descripción:
Frecuencia: (corresponde al número de veces en promedio que se realiza el proceso en un día).
Diagrama de flujo:
Para crear el diagrama de flujo se propone usar la herramienta de software libre conocida como DIA
Notas del curso
Hola Todos,
Mediante el siguiente enlace podrán acceder permanentemente para conocer las notas que llevan en el curso: notas
Mediante el siguiente enlace podrán acceder permanentemente para conocer las notas que llevan en el curso: notas
Suscribirse a:
Entradas (Atom)