10
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

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

  • 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