VERSION DESARROLLO 1.0.0

Proyecto de Administracion de Bienes Informaticos para la Secretaria de Turismo del Estado de Aguascalientes

Para el desarrollo estamos usando el siguiente Stack:

• Linux(Ubuntu 14.04 LTS) y Windows 8
• XAMPP 5.5
• phpMyAdmin 4.4.3 (PHP 5.5 ,Apache 2.4 ,MySQL 5.6)
• Framework Codeigniter 2.1.3
• Bootstrap 3.2
• HTML5
• JQuery 1.11
• Git 1.9.1
• Sublime Text 2
• Todos los Navegadores son compatibles. Para que el usuario tener una mejor experiencia use (Mozilla Firefox y Chrome)
• Aplicaciones de colaboración en línea:
  • Github.com
  • Slack.com
  • StoriesonBoard.com

#Metodologias y Patrones que se utilizan

• Agil SCRUM
• MVC (Model View Controller)
• UML

#Cultura de Desarrollo en SECTUREAGS La cultura de desarrollo en SECTUREAGS busca continuamente estar alineada con la filosofía de una gestión ágil de proyectos de desarrollo de aplicaciones web y fomentamos lo siguiente:

• El trabajo en equipo y la colaboración entre todas las personas implicadas en un proyecto.
• Equipos autogestionados a los que se ha delegado la responsabilidad y autoridad para hacer su trabajo.
• En lugar del jefe de proyecto existe la figura del Facilitador.
• La creatividad del equipo.
• La transparencia y la mejora continua.

SECTUREAGS sistematiza la identificación de obstáculos que pueden impedir el correcto progreso del proyecto. Los problemas previamente existentes en la organización (procesos, personas, herramientas, etc.) y que atentan contra la productividad se harán más evidentes y será necesario irlos solucionando.

#Compromiso del equipo

SECTUREAGS se basa en el compromiso conjunto y la colaboración entre los miembros del equipo. La transparencia entre todos es fundamental para poder inspeccionar la situación real del proyecto y así poder hacer las mejores adaptaciones que permitan conseguir el objetivo común. Por ello, será difícil trabajar con personas que: *No confían en los demás, no permiten que otras personas puedan aportar ideas sobre el qué y el cómo, no son capaces de colaborar en la resolución de problemas ni de delegar tareas. *No son transparentes respecto a su trabajo personal, sea por que defienden a toda costa su parcela de responsabilidad o por inseguridad para comunicarse o colaborar, cosa que no permite que sean ayudados. *Su modo de relación se basa en la generación de conflicto o bien evitan entrar en conflictos sanos en que ambas partes ganen (ganar/ganar), con lo que los problemas realmente no se resuelven sino que crean conversaciones veladas, de manera que estas personas no acaban de adquirir un compromiso real con el equipo. *Priorizan su ego, sus intereses personales o de carrera, por encima de los intereses del equipo y proyecto. *No son capaces de cambiar sus hábitos y salir de su zona de confort, tienen miedo al cambio, prefieren que se les diga qué tienen que hacer o quieren decir a los demás qué tienen que hacer. *Quieren seguir siendo los héroes que solucionan los proyectos.

#Relación entre el equipo y SECTUREAGS

El proyecto esta basado en el principio de ganar – ganar. En lugar de estar ligados por un contrato férreo de alcance, tiempo y coste, las dos partes asumen que habrá cambios para que SECTUREAGS pueda obtener lo que realmente necesita, no lo que está escrito en un documento inicial o seguir un plan inicial que vaya perdiendo su sentido. La relación se aproxima en meses, donde SECTUREAGS dirige mes a mes los resultados que el proyecto debe ir proporcionando. Debe existir transparencia en la ejecución del proyecto para facilitar esta relación. Esta transparencia la facilita de manera regular el propio proceso de desarrollo, especialmente en la actividad de demostración de los requisitos completados al final de cada iteración.

#Facilidad para realizar cambios en el proyecto

Los requisitos y los cambios nuevos se van incorporando de manera incremental en el producto del proyecto y realizar cambios de forma controlada sin un coste prohibitivo para SECTUREAGS. Para ello es necesario: *Disponer de técnicas y herramientas que faciliten el crecimiento incremental y la introducción de cambios. *Mantener la simplicidad y calidad interna del producto que se está creando. *Para cubrir los requisitos actuales de proyecto no hay que realizar más esfuerzo del que sea necesario y, a la vez, se debe vigilar no hacer nada en contra de futuros requisitos.

Dado que los requisitos se desarrollan priorizados por su valor, es más improbable que ocurran cambios sustanciales en los primeros requisitos desarrollados, cuando se construye la base del producto. Se fomenta que los cambios que suelen aparecen cuando el proyecto ya está avanzado se realicen sobre requisitos que no son tan importantes.

La arquitectura emerge conforme se va necesitando, iteración a iteración, con lo que se asegura que todo lo que se diseña se utiliza y se prueba.