Download - 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
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”.
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
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
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
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
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_______________________________________________
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
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,
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, es como no
debe hacerse.
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).
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
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