desarrollo unidad2

28
º DESARROLLO DE PROYECTOS INFORMÁTICOS Guía para el estudiante Elaborado por el formador: VERÓNICA FABIANA RINCÓN CANTOR INSTITUTO COLOMBIANO DE APRENDIZAJE 1

Upload: veronica-rincon

Post on 10-Mar-2016

244 views

Category:

Documents


0 download

DESCRIPTION

Unidad 2 del modulo desarrollo de software

TRANSCRIPT

Page 1: desarrollo unidad2

º

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 Sistemas1

Page 2: desarrollo unidad2

Desarrollo de Proyectos InformáticosInstituto Colombiano de AprendizajeElaborado por:Verónica Fabiana Rincón Cantor

Editado por: Instituto Colombiano de Aprendizaje INCAPAvenida Caracas No. 63-66

© Prohibida la reproducción parcial o total bajo cualquier forma(Art. 125 Ley 23 de 1982)

Bogotá – ColombiaVersión 01 - Julio 2010

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”.

Page 3: desarrollo unidad2

CONTENIDO

PRESENTACIÓN 5GUÍA METODOLÓGICA 6UNIDAD UNOCICLO DE VIDA DEL SOFTWARE 10ETAPAS DEL CICLO DE VIDA DEL SOFTWARE 11

MODELOS DEL CICLO DE VIDA DEL SOFTWARE 14Modelo en cascadaE

15Modelo en Espiral 16Modelo Incremental 18Modelo Evolutivo 20Modelo Concurrente 21METODOLOGÍAS 22Metodología CMMI 23Metodología ISO 25Metodología SCRUM 25TÉCNICAS DE RECOLECCION DE DATOS 26Introspección 27Entrevista Abierta 28Cuestionario 30Grupos de Discusión 30Tormenta de Ideas 31Entrevistas 32Observación 33FICHA PARA ENTREVISTAS 33ESPECIFICACION DE REQUERIMIENTOS 37FORMATO IEEE830 REQUERIMIENTOS 47UNIDAD DOSUML 51DIAGRAMAS DE CASO DE USO 52DIAGRAMAS DE SECUENCIA 55HERRAMIENTAS CASE 59MODELO ENTIDAD RELACION 60CRONOGRAMAS 61

Page 4: desarrollo unidad2

BIBLIOGRAFIA 63

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 EVIDENCIASBIBLIOGRAFÍA

Page 5: desarrollo unidad2

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

P R E S E N T A C I Ó N

Page 6: desarrollo unidad2

alguna parte del nuevo sistema y entre más estén involucradas

mejor para cubrir con todos los requerimientos del sistema.

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.

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

Page 7: desarrollo unidad2

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_______________________________________________

Page 8: desarrollo unidad2

Diseño de Requerimientos

T E M A S

1. UML2. Diagramas de Caso de Uso3. Diagramas de Secuencia4. MER5. 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

Unidad Dos 2

Page 9: desarrollo unidad2

requerimientos.

Indicadores de Logro Conceptos de UML

Elabora informe de diseño proponiendo alternativas de solución

Elaboración de cronogramas, casos de uso, secuencia y MER

Evidencia deConocimiento

Producto

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,

Page 10: desarrollo unidad2

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

Page 11: desarrollo unidad2

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

Page 12: desarrollo unidad2

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.

Page 13: desarrollo unidad2

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

Page 14: desarrollo unidad2

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:

Page 15: desarrollo unidad2

• 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.

Page 16: desarrollo unidad2

• 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, es como no

debe hacerse.

Page 17: desarrollo unidad2

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

Page 18: desarrollo unidad2

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

Page 19: desarrollo unidad2

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).

EntidadSe 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.

AtributoSe 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.

RelacionesSe 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.

CRONOGRAMASConsiste 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

Page 21: desarrollo unidad2

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

Page 22: desarrollo unidad2

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