VIDEO EN EQUIPO:
Metodologías_De_Desarrollo_De_Software
https://www.youtube.com/watch?v=5k4EOHPFYXs&feature=youtu.be
martes, 9 de abril de 2019
domingo, 7 de abril de 2019
Metodologías de Desarrollo tradicionales: cascada, modelo en V y espiral.
Metodologías de Desarrollo tradicionales
El Método-V es una
representación gráfica del ciclo de vida del desarrollo del sistema. Resume los
pasos principales que hay que tomar en conjunción con las correspondientes
entregas de los sistemas de validación.
La parte izquierda de
la V representa la corriente donde se definen las especificaciones
del sistema. La parte derecha de la V representa la corriente donde se
comprueba el sistema (contra las especificaciones definidas en la parte
izquierda). La parte de abajo, donde se encuentran ambas partes, representa la
corriente de desarrollo.
La
corriente de especificación consiste principalmente de:
- · Especificaciones de requerimiento de usuario
- · Especificaciones funcionales
- · Especificaciones de diseño
La
corriente de pruebas, por su parte, suele consistir de:
- · Calificación de instalación
- · Calificación operacional
- · Calificación de rendimiento
Modelo en Cascada
El modelo en
cascada es un enfoque clásico en el desarrollo de software que
describe un método de desarrollo lineal y secuencial. Consta de cinco a siete
fases, cada fase está definida por diferentes tareas y objetivos, por lo que la
totalidad de las fases describe el ciclo de vida del software hasta su entrega.
Una vez finalizada una fase, sigue el siguiente paso de desarrollo y los
resultados de la fase anterior pasan a la siguiente fase.
Modelo Espiral
El modelo en
espiral, es un modelo de proceso de software evolutivo donde se conjuga la
naturaleza de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal y secuencial. Proporciona el potencial para el
desarrollo rápido de versiones incrementales del software que no se basa en
fases claramente definidas y separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas , cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado conjunto de tareas que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.
Metodologías de desarrollo ágiles.
Es un
modelo de desarrollo ágil caracterizado por:
1.-
Aportar una estrategia de desarrollo incremental, en lugar de la planificación
y ejecución completa del producto.
2.- La calidad del resultado se basa principalmente en el conocimiento
innato de las personas en equipos auto organizados, antes que en la
calidad de los procesos empleados.
3.-
Solapamiento de las diferentes fases de desarrollo.
4.- Seguir los pasos del desarrollo ágil: Desde el concepto o
visión general de la necesidad del cliente, construcción del producto de forma
incremental a través de iteraciones. Estas iteraciones (En scrum se
llaman Sprint) se repiten de forma continua hasta que el cliente da por
cerrada la evolución del producto.
PROGRAMACIÓN EXTREMA (XP)
Metodología ágil centrada en
potenciar las relaciones interpersonales como clave para el éxito en desarrollo
del software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores y propiciando un buen clima de trabajo.
XP se basa en retroalimentación
continua entre cliente y el equipo de desarrollo. XP es especialmente adecuada
para proyectos con requisitos imprecisos y muy cambiantes.
Metodologías de desarrollo Web.
Un Método se compone de
diversos aspectos que nos permitirán conseguir una meta o lograr un objetivo.
Se define más claramente como un conjunto de herramientas, las cuales
utilizadas mediante las técnicas correctas, permiten la ejecución de procesos
que nos llevarán a cumplir los objetivos que buscamos. En pocas palabras y
aunque esto lo puedes encontrar como tal en internet, es un conjunto de
herramientas, técnicas y procesos que facilitan la obtención de un objetivo.
sábado, 9 de marzo de 2019
domingo, 3 de marzo de 2019
Modelado de Negocio
Modelado de negocio
El modelado de negocios se define como un
proceso de representación de uno o más aspectos o elementos de una empresa como
el propósito, su estructura, funcionalidad, dinámica, lógica de negocios y
componentes como fines, procesos, reglas, objetos, actores y unidades
organizativas entre otras.
Método de modelado de negocios orientado al
desarrollo de sistemas de información empresarial se fundamenta en: la noción
de sistema de negocios (Montilva, 2002), el método EKD EKD-CMM CMM (Barrios
& Nurcan, 2004:1) y el Método WATCH (Montilva & Barrios, 2004:2) para
desarrollo de software empresarial.
Modelo del producto. Descripción genérica del producto que produce
el método: El modelo de negocios.
Modelo de proceso.
Representación gráfica de las fases, pasos, actividades o tareas que el método
propone para modelar el negocio.
Modelo del grupo. Describe
la estructura y los roles del personal que participa en el proyecto de
modelado.
Diagrama De Contexto
Un Diagrama de Contexto de Sistema (DCS) en Ingeniería de software e Ingeniería de sistemas es un diagrama que define los límites entre el sistema, o parte del sistema, y su ambiente, mostrando las
entidades que interactúan con él. Este
diagrama es una vista de alto nivel de un sistema. Es similar al Diagrama de bloques.
Bloques de construcción
Diagramas
de contexto pueden ser desarrollados con el uso de dos tipos de bloques de
construcción:
•
Entidades
(Actores): cuadros
etiquetados; uno en el centro representando el sistema, y varios cuadros
alrededor para los factores externos.
•
Relaciones: líneas etiquetadas entre las
entidades y el sistema.
jueves, 7 de febrero de 2019
Videos
VIDEOS
Aqui les presento los videos de las unidades 1 y 2.
Unidad 1. Ingeniería de requerimientos de software
lunes, 4 de febrero de 2019
Modelado UML
Modelado UML
El Lenguaje de Modelado Unificado
(UML:Unified Modeling Language) es la sucesión de una serie de métodos de
análisis y diseño orientadas a objetos que aparecen a fines de los 80's y
principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los
métodos consisten de ambos de un lenguaje de modelado y de un proceso.
Semántica y Notación
Una de las metas principales de
UML es avanzar en el estado de la integración institucional proporcionando
herramientas de interoperabilidad para el modelado visual de objetos. Sin
embargo para lograr un intercambio exitoso de modelos de información entre
herramientas, se requirió definir a UML una semántica y una notación.
El lenguaje está dotado de
múltiples herramientas para lograr la especificación determinante del modelo,
pero en nuestro caso se trabaja en forma simplificada sobre:
- Modelamiento de Clases
- Casos de Uso
- Diagrama de Interacción
Tipos de arquitecturas.
Tipos de arquitecturas.
Arquitectura Orientada a Servicios (SOA)
Arquitectura De Micro Servicios
Una arquitectura de micro servicios consta de una colección
de servicios autónomos y pequeños. Los servicios son independientes entre sí y
cada uno debe implementar una funcionalidad de negocio individual.
Arquitectura Monolítica
Las aplicaciones monolíticas son aquellas en las que el
software se estructura en grupos
funcionales muy acoplados, involucrando los aspectos referidos a la
presentación, procesamiento y almacenamiento de la información. Son
implementadas dentro de un solo componente de software.
Arquitectura de Sistemas Distribuidos
Los sistemas distribuidos son comúnmente piezas
complejas de software cuyos componentes están dispersos en máquinas múltiples.
Si se desea tener control sobre esta complejidad, es crucial que estos sistemas
estén apropiadamente organizados.
Arquitectura en Capas
Es la vista conceptual de la estructura de la arquitectura de una
aplicación. Toda aplicación contiene código de presentación,
código de procesamiento de datos y código de almacenamiento de datos. La
arquitectura de las aplicaciones difiere según como está distribuido este
código.
Especificación de requisitos de software
Especificación de requisitos de software
La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
Prácticas
recomendadas para una buena ERS
Las características de una buena ERS son definidas por el
estándar IEEE 830-1998. Una buena ERS debe ser:
·Completa.
Todos los requerimientos deben estar reflejados en ella y todas
las referencias deben estar definidas.
·Consistente. Debe ser coherente con los
propios requerimientos y también con otros documentos de especificación.
·Inequívoca. La redacción debe ser clara de
modo que no se pueda mal interpretar.
·Correcta. El software debe cumplir con
los requisitos de la especificación.
·Trazable. Se refiere a la posibilidad de
verificar la historia, ubicación o aplicación de un ítem a través de su
identificación almacenada y documentada.
·Priorizable. Los requisitos deben poder
organizarse jerárquicamente según su relevancia para el negocio y
clasificándolos en esenciales, condicionales y opcionales.
·Modificable.
Aunque todo requerimiento es modificable, se refiere a que debe
ser fácilmente modificable.
·Verificable. Debe existir un método finito
sin costo para poder probarlo.
Tipos de requisitos
1.
Requisitos de Usuarios: Necesidades que los usuarios expresan
verbalmente
2.
Requisitos del Sistema: Son los componentes que el sistema debe
tener para realizar determinadas tareas.
3.
Requisitos Funcionales: Servicios que el sistema debe
proporcionar al finalizar el sistema.
Restricciones de Diseño
Todo aquello que restrinja las decisiones relativas al diseño de
la aplicación: Restricciones de otros estándares, limitaciones del hardware,
etc.
Análisis Y Sintesis De Información
Análisis Y Sintesis De Información
¿Qué es una síntesis?
Una
síntesis es un escrito donde se exponen las ideas principales de un texto tras
su análisis y comprensión. Estas ideas se corresponden con la opinión del autor
y ayuda a una mejor comprensión del mismo para facilitar su entendimiento o
estudio, por lo que son expresadas con las palabras de la persona que redacta
la síntesis.
En una síntesis analizamos estas ideas y las expresamos desde
nuestro punto de vista, aunque también deban corresponderse con la opinión del
autor. Es decir, debemos de comprender el texto, analizarlo, agrupar sus ideas
y luego escribirlas pasadas por nuestro propio filtro.
Cómo hacer una síntesis
Para
redactar una síntesis sobre un ensayo o texto leído debemos de seguir los
siguientes pasos:
1)
Leer el texto con atención una primera vez.
2)
Releer el texto, pero esta vez subrayando las ideas principales
3)
Asegúrese de haber entendido correctamente estas ideas y asimila
los conceptos.
4)
Redacte un texto dónde con palabras propias, exprese estas ideas
tal como las has entendido de modo que faciliten el estudio del texto y su
total comprensión.
5)
Exprese una sola idea por párrafo para facilitar la claridad de
la misma.
¿Qué es un análisis?
El análisis es la identificación y separación de
los elementos fundamentales. Se descomponen, se desintegran las ideas.
¿Cómo se hace?
Cuando se trata de un texto corto, como
un artículo, un reportaje, un fragmento, etc., se realiza separando la idea de
cada párrafo. Si es un texto largo, una conferencia, un folleto, un libro, etc.,
se separan las ideas centrales de los subtemas.
Obtención de Requerimientos. Técnicas y Estrategia
Obtención de Requerimientos. Técnicas y Estrategia
El proceso de obtención de requisitos, cuya
finalidad es llevar a la luz los requisitos, no solo es un proceso técnico,
sino también un proceso social que envuelve a diferentes personas, lo que
conlleva dificultades añadidas a su realización.
Entrevistas
La entrevista es de gran utilidad para obtener
información cualitativa como opiniones, o descripciones subjetivas de
actividades. Es una técnica muy utilizada, y requiere una mayor preparación y
experiencia por parte del analista.
Desarrollo Conjunto de Aplicaciones (JAD)
Es una técnica que se utiliza para promover la
cooperación y el trabajo en equipo entre usuarios y analistas. Consiste en
realizar sesiones en las que participan usuarios expertos del dominio junto a
analistas de software.
Desarrollo de Prototipos
Los prototipos suelen consistir en versiones
reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de
la aplicación pedida. Esta técnica es particularmente útil cuando:
- El área de la aplicación no está bien definida (posiblemente por
ser algo muy novedoso).
- El costo del rechazo de la aplicación por los usuarios es muy alto.
- Es necesario evaluar previamente el impacto del sistema en los
usuarios y en la organización.
Observación
Por medio de esta técnica el analista obtiene
información de primera mano sobre la forma en que se efectúan las actividades.
Este método permite observar la forma en que se llevan a cabo los procesos y,
por otro, verificar que realmente se sigan todos los pasos especificados.
Estudio de documentación
Varios tipos de documentación, como manuales y
reportes, pueden proporcionar al analista información valiosa con respecto a
las organizaciones y a sus operaciones. La documentación difícilmente refleja
la forma en que realmente se desarrollan las actividades, o donde se encuentra
el poder de la toma de decisiones.
Tormenta de ideas (Brainstorming)
Consiste en reuniones con cuatro a diez personas
donde como primer paso sugieren toda clase de ideas sin juzgar su validez –por
muy disparatadas que parezcan–, y después de recopilar todas las ideas se
realiza un análisis detallado de cada propuesta.
Puntos de Vista
Cualquier sistema de software no trivial debe
satisfacer las necesidades de un grupo diverso de interesados (stakeholders).
Cada uno de estos puede tener intereses diferentes en el sistema de software, y
por lo tanto sus necesidades pueden generar requerimientos que tengan conflicto
entre sí, o incluso se contradigan.
Escenarios
Estos se utilizan para documentar el
comportamiento del sistema cuando se le presentan eventos específicos. Cada
evento de interacción distinto, o la selección de un servicio del sistema, se
documentan como un escenario de eventos distinto.
Checklist. Lista de verificación
Una lista de verificación, en inglés: checklist, es una
herramienta que se utiliza en diversos ámbitos de la gestión de las
organizaciones para extraer una serie de propiedades de aquello que se somete a
estudio.
martes, 22 de enero de 2019
SEGUNDO CUATRIMESTRE
SEGUNDO CUATRIMESTRE
TI02SM-18
METODOLOGÍAS Y MODELADO DE DESARROLLO DE SOFTWARE
Suscribirse a:
Entradas (Atom)