Upload
usac
View
0
Download
0
Embed Size (px)
Citation preview
Universidad de San Carlos de Guatemala Facultad de Ingeniería Escuela de Ciencias y Sistemas Análisis y Diseño de Sistemas 1 Ing. Ricardo Morales
Proyecto “FASE 1”
Nombre Carnet
Sergio Amilcar Cuxil Chalí 2009-15366
José Alberto Velásquez Orozco 2007-30448
Robin Amilcar Rosales Marroquín 2010-20470
Francisco de Borja Tobar Palacios 2009-15306
Emanuel de Jesús Canel Vasquez 2008-15429
INTRODUCCION El desarrollo de software hoy en día está en constante evolución, y los cambios son cada vez más rápidos, por esta razón el ingeniero de software tiene que actualizarse y conocer estos avances y nuevas formas de agilizar su trabajo para alcanzar todos los estándares profesionales posibles. La entrega exitosa de un software se basa en la calidad dentro del presupuesto y a tiempo, por tal razón es necesario aplicar metodologías de trabajo en equipo, Las cuales aplicaremos en el siguiente proyecto, para demostrar y llevar a cabo la finalización del mismo, evitando las fallas comunes como: no alcanzar los requerimientos establecidos, calidad muy baja entre otros.
METODOLOGÍAS METODOLOGÍA SCRUM
Scrum es un marco de trabajo iterativo e incremental que está enfocado a la gestión de procesos de
desarrollo, equipos de mantenimiento de software, o en una aproximación de gestión de programas.
Como la metodología es de tipo iterativo se realizan entregas parciales y regulares del producto final, las
fases están priorizadas por el beneficio que aportan al receptor del proyecto.
Scrum es un modelo en la que se define un conjunto de prácticas y roles, estos pueden tomarse como
punto de referencia para definir el proceso de desarrollo que se ejecutará durante un proyecto. Entre los
principales roles que scrum define están:
Scrum Master: Mantiene los procesos y trabaja de forma similar al director de proyecto. Su trabajo
primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum
Master no es el líder del equipo, sino que actúa como una protección entre el equipo y cualquier influencia
que le distraiga.
Product Owner: Representa a los stakeholders (interesados externos o internos). Dicho de otra manera,
representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la
perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el
Product Backlog.
Team: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo con las habilidades
transversales necesarias para realizar el trabajo, acá están incluidos los desarrolladores.
Stakeholders: Son un grupo de personas que hacen posible el proyecto y para quienes el proyecto
producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las
revisiones del sprint.
Managers: Son las personas que establecen el ambiente para el desarrollo del producto.
Los sprint tienen periodos por el equipo (normalmente suele ser entre una y cuatro semanas) en ese
tiempo el equipo crea una versión del software que es potencialmente la final. El Product Backlog tiene
como función dar el conjunto de características para cada sprint.
El Product Backlog es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.
Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de
Sprint Planning. Durante esta reunión, el Dueño del producto identifica los elementos del Product
Backlog que quiere ver completados y se los transmite al equipo que determina la cantidad de ese trabajo
que puede comprometerse a completar durante el sprint de se está definiendo. Mientras dure el sprint,
nadie puede cambiar el Sprint Backlog (los requisitos e hitos marcados para el Sprint) o lo que es lo mismo,
los requisitos quedan congelados durante el sprint.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar
de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos
impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto,
Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente
entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y
responder a requisitos emergentes.
METODOLOGÍA XP
XP es una metodología de desarrollo de la ingeniería de software, formulada por Kent Beck, que
considera que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos.
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en
desarrollo de 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 realimentación continua entre el
cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
técnico.
Entre las características de XP están:
Simplicidad: Se simplifica todo lo que se puede para agilizar el desarrollo y facilitar el mantenimiento.
Comunicación: El código es entendido mejor cuanto más simple sea. Comentar dentro del código en una
buena práctica de comunicación.
Retroalimentación o Reutilización del código: El cliente es parte fundamental del equipo y su opinión se
conoce en tiempo real. Esto minimiza el tener que rehacer partes que no cumplen con los requisitos y
ayuda a los programadores a centrarse en lo que es más importante.
Necesidades Actuales: El diseño es para hoy, no para el mañana. Esto simplifica el código y se convierte
en requerimientos de tiempo menores y eso hace sentir a los programadores más cómodos, pero
también hay que tener en cuenta que se tendrá que reconstruir el código cuando sea necesario.
Respeto: No realizar cambios que hagan que las pruebas existentes fallen o demore el trabajo de los
demás.
Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del programador. Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
METODOLOGÍA KANBAN
Kanban es una palabra japonesa que significa “tarjetas visuales”, fue desarrollado en las fábricas de
Toyota para controlar el proceso en las líneas de producción. Esta metodología está basada en el principio
del Kaizen (significa "mejora continua y continuada”).
Kanban no es una técnica específica del desarrollo software, su objetivo es gestionar de manera general
cómo se van completando tareas, pero en los últimos años se ha utilizado en la gestión de proyectos de
desarrollo software, a menudo con Scrum.
Objetivos del método Kanban:
1. Regular internamente las fluctuaciones de la demanda y el volumen de producción en cada
sección como manera de evitarse la transmisión e ampliación de dichas fluctuaciones.
2. Disminuir las fluctuaciones de los stocks de producto terminado con el objetivo de reducir los
costes de almacenamiento.
3. Descentralizar la gestión de la fábrica, creando condiciones para que las jefaturas directas
puedan desempeñar un papel de gestión efectiva de la producción y de los stocks;
4. Producir al momento las cantidades solicitadas.
Principios de Kanban:
1. Calidad garantizada. Todo lo que se hace debe salir bien a la primera, no hay margen de error.
De aquí a que en Kanban no se premie la rapidez, sino la calidad final de las tareas realizadas.
Esto se basa en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien a la
primera.
2. Reducción del desperdicio. Kanban se basa en hacer solamente lo justo y necesario, pero hacerlo
bien. Esto supone la reducción de todo aquello que es superficial o secundario.
3. Mejora continua. Kanban no es simplemente un método de gestión, sino también un sistema de
mejora en el desarrollo de proyectos, según los objetivos a alcanzar.
4. Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas),
pudiéndose priorizar aquellas tareas entrantes según las necesidades del momento.
Reglas de Kanban:
1. Visualizar el trabajo y las fases del ciclo de producción o flujo de trabajo
2. Determinar el límite de “trabajo en curso” (Work In Progress)
3. Medir el tiempo en completar una tarea (lead time).
Visualizar el trabajo en Kanban y las fases del ciclo de producción.
Kanban se basa en el desarrollo incremental, dividiendo el trabajo en partes. Una de las principales
aportaciones es que utiliza técnicas visuales para ver la situación de cada tarea, y que quizás habrás visto
representado pizarras llenas de post-it.
El trabajo se divide en partes, normalmente cada una de esas partes se escribe en un post-it y se pega en
una pizarra. Los post-it suelen tener información variada, si bien, aparte de la descripción, debieran tener
la estimación de la duración de la tarea.
La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de
ser desarrollada, en análisis, en diseño, etc.). Abajo dejo una figura con un ejemplo de tablero Kanban.
El objetivo de esta visualización es que quede claro el trabajo a realizar, en qué está trabajando cada
persona, que todo el mundo tenga algo que hacer y el tener clara la prioridad de las tareas.
Determinar el límite de “Trabajo en curso”
Quizás una de las principales ideas del Kanban es que el trabajo en curso (Work In Progress o WIP) debería
estar limitado, es decir, que el número máximo de tareas que se pueden realizar en cada fase debe ser
algo conocido. La idea es: concentrarse en cerrar tareas y no en comenzar tareas.
Medir el tiempo en completar una tarea
El tiempo que se tarda en terminar cada tarea se debe medir, a ese tiempo se le llama “lead time”. Este
cuenta desde que se hace una petición hasta que se hace la entrega.
Aunque la métrica más conocida del Kanban es el “lead time”, normalmente se suele utilizar también
otra métrica importante: el “cycle time”. El “cycle time” mide desde que el trabajo sobre una tarea
comienza hasta que termina. Si con el “lead time” se mide lo que ven los clientes, lo que esperan, y con
el “cycle time” se mide más el rendimiento del proceso.
HERRAMIENTAS PLANIFICACIÓN Y REQUERIMIENTOS
Se utilizara Trello el cual es una herramienta que simula una metodología de planeación en la cual en un
pizarrón se agregan post-it por cada tarea a realizar y requerimiento que esta conlleve. Se pueden crear
varios proyectos a los cuales los miembros del equipo pueden acceder.
Se decidió utilizar esta herramienta ya que tiene versión online y para dispositivos móviles, por lo cual se
puede tener acceso en cualquier lugar para verifica las tareas pendientes y el progreso de cada una de
ellas. La interacción con la herramienta es muy sencilla y fácil de entender. La herramienta es gratuita.
Se tomó en cuenta que cualquiera puede tener acceso a esta información de manera rápida para verificar
la fecha de entrega de cada tarea y poder tomar sus precauciones para poder realizarlo de manera
adecuada y sin estar corriendo. Ya que la mayoría tiene acceso a un teléfono inteligente se nos facilitara
poder estar al tanto del desarrollo del proyecto al alcance de un click.
DISEÑO
Las herramientas que se utilizaran para el diseño de la aplicación son los controles Windows Form que
posee Visual Studio, se eligieron estos controles porque permiten realizar un diseño agradable, el tipo de
Aplicación será de Escritorio, dicha aplicación contendrá su instalador para poder ser instalados en las
maquinas que se requieran llevar el control.
DESARROLLO
Para el desarrollo de la aplicación se utilizara como lenguaje de programación C# y para el
almacenamiento de la información será SQL Server http://www.microsoft.com/es-xl/server-
cloud/products/sql-server/, utilizando como IDE Visual Studio https://www.visualstudio.com/, el
ambiente de la aplicación es el sistema operativo Windows (XP, Windows 7 y Windows 8).
CONTROL DE VERSIONES
Utilizaremos Gitexstensions el cual es una herramienta con una interfaz gráfica que nos permite llevar el
control de cada cambio o actualización que se le hace al software de manera más ordenada y sencilla ya
que nos evita utilizar líneas de comando por la facilidad de la interfaz gráfica. Tenemos la facilidad de
realizar cualquier cambio en el proyecto y poder sincronizarlo hasta que estemos completamente
satisfechos sin afectar nada de lo que se ha realizado previamente.
Se tomó la decisión de utilizar este software ya que el proyecto está en la nube, y al momento de querer
hacer algún cambio solo se debe de conectar al servidor el cual descarga el proyecto a nuestro IDE. Nos
da facilidad y variedad de herramientas para simplificarnos el modo de actualización ya que al momento
de sincronizar nos deja seleccionar que archivos queremos reemplazar o añadir. La herramienta es
gratuita.
Tomamos en cuenta que nuestro proyecto no va a ser muy pesado por lo que no ocupara mucho espacio
en la nube, además ya que no todos tenemos el tiempo necesario para juntarnos y programar en el mismo
lugar esto nos facilita el poder hacer cada quien desde un lugar distinto y solo sincronizarlo, pudiendo
estar todos trabajando en el mismo proyecto de manera paralela y remota. Nos dará ventaja al trabajar
programando en parejas.
PRUEBAS
Las pruebas son necesarias realizar porque se verifica el buen funcionamiento de nuestra aplicación y así
asegurar que la calidad del producto que se entregue sea la mejor, esto debería ser siempre de prioridad
en el desarrollo de la aplicación. Para el proyecto se utilizar la herramienta Unit Test Generator para
Visual Studio, esto ayuda a aumentar la productividad de los desarrolladores al disminuir el trabajo de
configuración involucrados en la creación de nuevas pruebas unitarias, además ofrece la capacidad de
generar y configurar un proyecto de prueba, clase de prueba.
TECNOLOGÍA Y ARQUITECTURA TECNOLOGÍA Y ARQUITECTURA
La infraestructura que se manejara para el desarrollo de la aplicación será de Escritorio contando con su
instalador, la información se almacenara en una base de datos, eligiendo SQL Server, se utilizarán dicha
tecnología porque son herramientas muy competitivas para el desarrollo de software. Los proyectos
serán desarrollados sobre una arquitectura Presentación/Lógica de Negocio/Acceso a datos.
Para explicar el proceso de desarrollo de una aplicación desarrollada en C#, se diseñó un pequeño
ejemplo para apreciar el proceso de dicha aplicación a continuación se muestra la arquitectura de la
misma con el propósito de facilitar y entender los elementos que lo componen:
La aplicación requiere de componentes que permitan otorgar al usuario la funcionalidad requerida. En
este sentido, la aplicación requiere de un componente que permita por un lado manejar la interacción
con el usuario (Formularios), un componente que permita por otro lado manejar el acceso a la base de
datos (Bibliotecas de clases para la conexión a la base de datos), así como un componente que permita
manejar las reglas y políticas del negocio; por último, es necesario un componente que permita
implementar las entidades del negocio.
PROYECTOS PROYECTO 1
La primera propuesta de proyecto es una herramienta para llevar el control de parqueos en la
universidad. El sistema llevara el control de ingreso y salida de vehículos, cupos disponibles, control de
tarifas por hora, día y mes, tanto para estudiantes y particulares, formas de pago (tarjeta o efectivo),
también un control de pagos, donde el pago se podrá hacer por mes o semestre. Este control se llevara
a cabo por facultad, teniendo un control de administradores y área de reportería.
Razón de elección de proyecto 1:
Como estudiantes y usuarios del control de parqueos en la facultad de Ingeniería, observamos que el
método que utilizan para llevar del control del mismo, no es del todo eficiente, más cuando se satura.
Esto nos llevó a la decisión de realizar este proyecto y expandirlo a todas las facultades. En el cual
tendrán un mejor control, tanto en la administración (personal y fondos) y el flujo de vehículos.
Además, porque también sería un gran aporte a la universidad para modernizar sus procesos y que
mejor, que el aporte sea de parte de la facultad de ingeniería.
Historias
Login de administradores
Mantenimiento de administradores
o Ingreso, consulta, modificación y eliminación.
Mantenimiento de facultades
o Ingreso, consulta, modificación y eliminación.
Mantenimiento de estudiantes/docentes
o Ingreso, consulta, modificación y eliminación.
o Nota: Este control se llevara solo para las personas que realicen pagos mensuales o por
semestre.
Mantenimiento de Tarifas
o Tarifas para estudiantes por hora, día y mes. También para particulares.
Control de registro
o Ingreso y salida de vehículos por fecha y hora.
o Cupo.
Control de cobros
o Cobros por día, mes o por hora.
o Forma de pago
Reportes (por facultad)
o Por fecha de ingreso y salida de vehículos
o Por vehículo, por estudiante.
o Reporte de administradores.
o Reporte de pagos.
PROYECTO 2
La propuesta número 2 es un sistema de apoyo estudiantil, y el objetivo de esta aplicación es realizar una
herramienta que el estudiante de Ingeniera tenga el acceso a material de apoyo de cursos del área de
Ciencias y Sistemas, en esta herramienta los usuario podrán ingresar y consultar material de apoyo,
ejemplos, ejercicios entre otra información, esto para los curos propios de esta carrera (Estructuras,
Archivos etc.), el usuario podrá ingresar sus credenciales e ingresar al sistema, al momento de ingresar el
usuario podría acceder o ingresar dicha información, el tipo de aplicación es web para que pueda ser
accedido fácilmente por los estudiantes.
Razón de elección de proyecto 2:
Se propuso el proyecto del sistema Apoyo Estudiantil, ya que como su nombre lo dice es de apoyo hacia
el estudiante de Ingeniería, debido a la demanda que hay para buscar información y esto hará más fácil
encontrar en un solo lugar la información o material de apoyo que nosotros como estudiantes
necesitamos, así como compartir nuestros conocimientos y ayudar a otros y esto hará que nuestro
conocimiento acerca de la carrera sea enriquecido.
Historias
Login de Usuarios
o Validación de Credenciales.
Mantenimiento de Usuarios
o Ingreso, consulta, modificación y eliminación.
Mantenimiento de Cursos
o Ingreso, consulta, modificación y eliminación.
Mantenimiento de Semestre
o Ingreso, consulta, modificación y eliminación.
Mantenimiento de Categoría de Cursos
o Ingreso, consulta, modificación y eliminación.
REFERENCIAS http://www.etnassoft.com/biblioteca/scrummanager-gestion-de-proyectos/
http://www.cognos-capacitacion.com/mailings/2009/noviembre/scrum/curso-scrum.html
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php
https://prezi.com/ijrbyl_qrvjc/pogramacion-extrema-xp/
http://www.javiergarzas.com/2011/11/kanban.html