º
DESARROLLO DE PROYECTOS INFORMÁTICOS Guía para el estudiante
Elaborado por el formador:
VERÓNICA FABIANA RINCÓN CANTOR
INSTITUTO COLOMBIANO DE APRENDIZAJE
INCAP Programa Técnico Laboral en Sistemas
1
EL SIGUIENTE MATERIAL SE PREPARÓ CON FINES ESTRICTAMENTE ACADÉMICOS, DE ACUERDO CON EL ARTÍCULO 32 DE LA LEY 23 DE 1982, CUYO TEXTO ES EL SIGUIENTE:
ARTÍCULO 32: “Es permitido utilizar obras literarias, artísticas o parte de ellas, a título de ilustración en obras destinadas a la enseñanza, por medio de publicaciones, emisiones o radiodifusiones, o grabaciones sonoras o visuales, dentro de los límites justificados por el fin propuesto, o comunicar con propósito de enseñanza la obra radiodifundida para fines escolares, educativos, universitarios y de formación personal sin fines de lucro, con la obligación de mencionar el nombre del autor y el título de las obras utilizadas”.
Desarrollo de Proyectos Informáticos Instituto Colombiano de Aprendizaje Elaborado por: Verónica Fabiana Rincón Cantor
Editado por: Instituto Colombiano de Aprendizaje INCAP Avenida Caracas No. 63-66 © Prohibida la reproducción parcial o total bajo cualquier forma (Art. 125 Ley 23 de 1982) Bogotá – Colombia Versión 01 - Julio 2010
CONTENIDO PRESENTACIÓN GUÍA METODOLÓGICA UNIDAD UNO CICLO DE VIDA DEL SOFTWARE ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
5 6
MODELOS DEL CICLO DE VIDA DEL SOFTWARE Modelo en cascada Modelo en Espiral Modelo Incremental Modelo Evolutivo Modelo Concurrente METODOLOGÍAS Metodología CMMI Metodología ISO Metodología SCRUM TÉCNICAS DE RECOLECCION DE DATOS Introspección Entrevista Abierta Cuestionario Grupos de Discusión Tormenta de Ideas Entrevistas Observación FICHA PARA ENTREVISTAS ESPECIFICACION DE REQUERIMIENTOS FORMATO IEEE830 REQUERIMIENTOS UNIDAD DOS UML DIAGRAMAS DE CASO DE USO DIAGRAMAS DE SECUENCIA HERRAMIENTAS CASE MODELO ENTIDAD RELACION CRONOGRAMAS BIBLIOGRAFIA
1 1 4 1 5 1 6 2 8 2 0 2 1 2 2 2 3 2 5 2 5 2 6 2 7 3 8 3 0 3 0 3 1 3 2 3 3 3 3 4 7
1 1 0
7 5 5 1 5 2 5 5 6 9 6 0 6 1 3
Apreciado estudiante: Usted escogió al INCAP para que lo oriente en el camino de la formación profesional. La institución le proporcionará un formador, quien le ayudará a descubrir sus propios conocimientos y habilidades. El INCAP, le ofrece además, recursos para que usted alcance sus metas, es decir, lo que se haya propuesto y para ello dispondrá de módulos guía, audiovisuales de apoyo, sistemas de evaluación, aula y espacios adecuados para trabajos individuales y de grupo. Éste módulo guía que constituye además un portafolio de evidencias de aprendizaje, está distribuido de la siguiente manera: PRESENTACIÓN: Es la información general sobre los contenidos, la metodología, los alcances la importancia y el propósito del módulo. GUÍA METODOLÓGICA: Orienta la práctica pedagógica en el desarrollo del proceso de formación evaluación y se complementa con el documento de la didáctica para la formación por competencias de manejo del formador. DIAGNÓSTICO DE ESTILO DE APRENDIZAJE: Que le permitirá utilizar la estrategia más adecuada para construir sus propios aprendizajes. AUTOPRUEBA DE AVANCE: Es un cuestionario que tiene como finalidad que usted mismo descubra, qué tanto conoce los contenidos de cada unidad, y le sirve de insumo para la concertación de su formación y el reconocimiento de los aprendizajes previos por parte de su formador (talleres que se encuentran al final de cada unidad). CONTENIDOS: Son el cuerpo de la unidad y están presentados así: • Unidad • Logro de competencia laboral • Indicadores de logro: Evidencias • Didáctica del método inductivo Activo para el desarrollo de las competencias: FDH: Formador Dice y Hace, FDEH: Formador Dice y Estudiante Hace, EDH: Estudiante Dice y Hace. VALORACIÓN DE EVIDENCIAS BIBLIOGRAFÍA
P R E S E N T A C I Ó N SENTACIÓN Desarrollar
un
software
significa
construirlo
simplemente
mediante su descripción. Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se presta
a
la
discusión
del
problema.
En
general
los
desarrolladores se centran en la solución dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución. El presente módulo ofrece al estudiante herramientas para desarrollar un software, donde intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el analista quien es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo e instalarlo al cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar todo lo necesario lo más seguro que le haga falta algún requerimiento o alguna parte del nuevo sistema y entre más estén involucradas mejor para cubrir con todos los requerimientos del sistema.
P R E S E N T A C I Ó N
G U Í A
M E T O D O L Ó G I C A
La estrategia metodológica del INCAP, para la formación técnica del aprendiz mediante competencias laborales, comprende dos caminos: 1. Las clases presenciales dictadas por el Formador haciendo uso del método inductivo – activo 2. El trabajo práctico de los estudiantes dirigido y evaluado por el Formador, a través de talleres, desarrollo de casos, lecturas y consultas de los temas de clase etc. Con esto se busca fomentar en el estudiante el análisis, el uso de herramientas tecnológicas y la responsabilidad. Los módulos guía utilizados por el INCAP, para desarrollar cada uno de los cursos, se elaboran teniendo en cuenta ésta metodología. Sus características y recomendaciones de uso son: A cada unidad de aprendizaje le corresponde un logro de competencia laboral el cual viene definido antes de desarrollar su contenido. Seguidamente se definen los indicadores de logro o sea las evidencias de aprendizaje requeridas que evaluará el Formador. Glosario: Definición de términos o palabras utilizadas en la unidad que son propias del tema a tratar. Desarrollo de la unidad dividida en contenidos breves seguidos por ejercicios, referenciados así:
» FDH (El Formador Dice y Hace): Corresponde a la explicación del contenido y el desarrollo de los ejercicios por parte del Formador.
» FDEH (El Formador Dice y el Estudiante Hace): El estudiante desarrolla los ejercicios propuestos y el Formador supervisa.
» EDH (El estudiante dice y hace): Es el trabajo práctico que desarrollan los estudiantes fuera de la clase, a través de talleres, desarrollo de casos, lecturas y consultas de los temas, los cuales deben ser evaluados por el Formador. Al final de cada unidad se puede presentar un resumen de los contenidos más relevantes y ejercicios generales.
DIAGNÓSTICO INFORMACIÓN GENERAL Regional_____________Programa__________________Módulo____________ Estudiante_________________________Formador_______________________ EVALUACIÓN DIAGNÓSTICA Estilo de aprendizaje_______________________________________________
Unidad Dos
2
Diseño de Requerimientos T E M A S 1. 2. 3. 4. 5.
UML Diagramas de Caso de Uso Diagramas de Secuencia MER Cronograma de Actividades
Logro de Competencia 1. Elaboración de informe de diseño para determinar las necesidades tecnológicas, representar el bosquejo de la solución al problema mediante diagramas de casos de uso, de secuencia, diagramas de flujo y MER apoyado en el análisis de requerimientos.
Indicadores de Logro
Evidencia de
•
Conceptos de UML
Conocimiento
•
Elabora informe de diseño proponiendo alternativas de solución
Producto
•
Elaboración de cronogramas, casos de uso, secuencia y MER
Producto
El Formador Dice y Hace:
UML (Unified Modeling Language)
Lenguaje Unificado de Modelado (LUM) o (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. • Diagramas de Casos de Uso para modelar los procesos ’business’. • Diagramas de Secuencia para modelar el paso de mensajes entre objetos. • Diagramas de Colaboración para modelar interacciones entre objetos. • Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. • Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. • Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. • Diagramas de Componentes para modelar componentes. • Diagramas de Implementación para modelar la distribución del sistema.
DIAGRAMAS DE CASO DE USO
El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema, y el problema que necesitamos solucionar. Describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no. El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione, El objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario diferente en el sistema. Cada escenario muestra una secuencia diferente de interacciones entre actores y el sistema,
Ejemplo:
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad
externa pueden jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.
Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Inclusión (include o use) Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Extensión (Extend) Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión. La extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. Generalización En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea
solida terminada en un triĂĄngulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prĂĄctica puede ser Ăştil factorizar comportamientos comunes,
restricciones al caso
de
uso general,
describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.
DIAGRAMAS DE SECUENCIA
Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML En inglés se pueden encontrar como "sequence diagram" Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Ejemplo:
•
Un evento de un sistema es un hecho externo de entrada que un actor produce en un sistema.
•
Una operación de un sistema es una acción que este ejecuta en respuesta a un evento del sistema. En el Diagrama anterior, el evento “ pasarProducto” inicia una operación del mismo nombre “Pasar Producto”.
Las operaciones se identifican de sus eventos.
Las operaciones se registran listándolas como en la tabla a la
derecha.
La tabla se entiende como: Operaciones del tipo sistema.
COMO ELABORAR UN DIAGRAMA DE SECUENCIA
Para elaborar diagramas de la secuencia de un sistema que describan el curso normal de los eventos en un caso de uso: •
Trace una línea que represente el sistema como una caja negra.
•
Identifique los actores que operan directamente sobre el sistema. Trace una línea por cada uno de ellos.
•
A partir del curso normal de eventos del caso de uso identifique los eventos “Externos” del sistema que son generados por los actores.
Muéstrelos
gráficamente en el diagrama •
A la izquierda del diagrama puede incluir el texto del caso de uso.
•
Los nombres deben comenzar con un verbo (Agregar, introducir, terminar, pasar, etc. )
Ejemplo :
introducirProducto ( ) Es un buen nombre. introducirTeclaOprimida ( ) Es un nombre poco idóneo, debe hacerse.
es
como
no
El Formador Dice y el estudiante Hace: HERRAMIENTAS CASE
Las herramientas CASE (Computer Aided Software Engineering), son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un
diseño
del proyecto,
calculo de costes,
implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras. De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el
proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o más fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided SoftwareEngineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir: • Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos. • Herramientas de diseño para dar apoyo al análisis de datos. • Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico. • Herramientas para desarrollar los prototipos de las aplicaciones. El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos. Cualquier herramienta CASE para desarrollar diagramas, alguna de las siguientes versiones de prueba, disponibles por 30 días, puede utilizarse: - Rational Rose. Disponible en www.ibm.com - Visio. Disponible en www.microsoft.com - Poseidon. Disponible en http://gentleware.com/index.php - Poseidon for UML community edition. Herramienta case UML gratuita sin límite de tiempo de uso disponible en: http://www.gentleware.com/index.php?id=ce
MODELO ENTIDAD-RELACION Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen la información que trata un sistema de información y el software que lo automatiza, pasos a seguir para el diagrama entidad-relación: 1.
Una entidad se relaciona con otra entidad con una línea continua, ya
que no lleva flechas, es solo una dirección continua. 2.
Toda relación debe de llevar una cardinalidad (determina el nivel de
cardinalidad). 3.
Una relación entre dos entidades siempre se va a dar por medio de
un rombo (si tienes una entidad alumno, otra materia, se traza una línea en el medio de la línea se pone un rombo, dentro del rombo se pone "el alumno se inscribe", el nivel seria uno a muchos ya que el alumno se inscribe a varias materias). Entidad Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado, salario etc. Atributo Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Relaciones Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona.
CRONOGRAMAS Consiste en una lista de todos los elementos terminales de un proyecto con sus fechas previstas de comienzo y final. Hay también herramientas libres y de código abierto para la generación de cronogramas de proyecto
disponibles para la mayoría de plataformas, éstas ofrecen la creación de listas de tareas, la asignación de recursos, precedencias y diagramas de Gantt. Otros paquetes de software son: •
Planner
•
dotProject
•
GanttProject
•
KPlato
•
Microsoft Project
•
Open workbench
•
netOffice
•
netOffice Dwins
•
TaskJuggler
•
TUTOS Ejemplos de Cronogramas:
El Estudiante Dice y Hace:
1. Utilizando una herramienta case el estudiante elaborarĂĄ los diagramas de caso de uso, diagramas de secuencia de su proyecto. 2. Elaborar el MER, y diccionario de datos de la base de datos de su proyecto.
BibliografĂa
•
Jacobson, I. 1998. "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en http://www.rational.com/uml como UMLconf.zip
•
Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10.
•
Marilyn Mantei en “The effect of Programming Team Structures on Programming Tasks”, 1981
•
Constantine, L. en “Work Organization: Paradigms for Project Management and Organization, 1993.
•
Rodríguez Diez, Gustavo. Ingeniería de Requerimientos. Notas de la clase de Metodologías de Diseño de Sistemas 2. Instituto Tecnolóico de Estudios Superiores de Monterrey, Campus Monterrey 2001.
•
Richard H. Thayer, Merlin Dorfman. Software Requerements Engineering, IEE 1997
•
Dean Leffingwell, Don Widring. Managing Software Requirements (A Unifiend Approach). Addison Wesley 2000