Redefina la innovación de software con herramientas y metodologías de IBM.
Comience con DevOps
Es la disciplina de identificar la configuración de un sistema en distintos puntos en el tiempo, con el propósito de controlar sistemáticamente cambios en la configuración del software y mantener la integridad y la rastreabilidad de la configuración a través del ciclo de vida del sistema. Esta área del conocimiento incluye seis sub niveles:
La administración del proceso de SCM. Cubre los tópicos del contexto de la organización para SCM, las restricciones y las guías para SCM, planeando para SCM, el plan mismo del SCM y la vigilancia del SCM.
La identificación de la configuración del software, la cual identifica los elementos que se controlarán, establece esquemas de identificación para los elementos y sus versiones, y establece las herramientas y las técnicas que se utilizarán en la adquisición y manejo de los artículos controlados.
Es el control de la configuración del software, que es la administración de cambios durante el ciclo de vida del software. Los asuntos son, primero, solicitando, evaluando y aprobando los cambios al software, segundo, implementar los cambios al software, y tercero, desviaciones y renuncias.
Es contabilización del estado de la configuración del software. Sus tópicos son información de estado de la configuración del software y reportes de estado.
Revisión de la configuración del software.
Que consiste en revisión de la configuración funcional del software, revisión de la configuración física del software y de revisiones en proceso de una línea base del software.
Administración de versiones y entrega, que cubre la construcción de software y la administración de versiones.
Es la aplicación del enfoque de sistemas para la administración de tareas tecnológicas complejas o de proyectos cuyos objetivos se establecen explícita mente en términos de tiempo, costos y parámetros de realización, por tanto, es la forma de planear, organizar, dirigir y controlar una serie de actividades realizadas por un grupo de personas que tienen un objetivo específico.
Se basa en proveer de una adecuada visibilidad a la administración sobre la situación del proyecto, para identificar oportunamente cualquier desviación sobre lo planificado con el objetivo de tomar decisiones oportunas para corregirlas, siendo lo ideal preverlas, para actuar antes de que ocurran y así evitarlas o aminorarlas antes de que acontezcan; mantiene especial atención en los siguientes aspectos:
Hace referencia a la actitud del líder, de cara a estar siempre enterado de cómo va el proyecto y las posibles desviaciones de los parámetros establecidos como metas y de los correctivos reguladores de la situación a futuro.
Si hay desviaciones, se deben cuantificar, en función del tiempo, dinero, talentos y recursos, además se debe cuantificar el grado de desviación, para determinar si es posible volver al camino correcto y cómo se lograría y cuánto costaría y se demoraría.
Cuanto más rápido se identifique una deficiencia en el proyecto más fácil será enmendarla, por eso se recomiendan análisis y revisiones semanales, para conocer y evaluar el estado del proyecto y regularlo continuamente
Después de ver en que se falla hay que tomar decisiones, para solventar el problema o desafío, se debe tener cuidado en la identificación de las causas de retraso y/o exceso en costos, pues a veces se esconden detrás de otros: no confundir causas con efectos ni medios con fines.
Las herramientas más usadas son evaluaciones, reuniones de petición y rendición de cuentas, revisiones crítico-constructivas afectuosas, reportes, software para planificación, simulación y control, sesiones de tormenta de ideas, etc. Conviene que todo el equipo envíe semanalmente reportes del grado de avance de sus tareas y actividades, de la manera más sencilla y eficaz de entender
Una de las principales causas para el fracaso de un proyecto de software es la mala (o ausencia de) administración de requerimientos. Los principales problemas de un mal manejo de requerimientos son:
·Incapacidad para manejar los cambios en los requerimientos durante el desarrollo.
·Falta de especificación detallada de los requerimientos.
·Mala organización y control de requerimientos.
·Requerimientos mal entendidos.
La administración de requerimientos comprende las actividades relacionadas con la definición, clasificación, asignación, seguimiento y control de los requerimientos durante todo el ciclo de vida de desarrollo de software.
Es una metodología indispensable para el aseguramiento de la calidad de los productos, así como para el control y seguimiento de los proyectos. El Rational Unified Process© describe cómo definir, organizar y documentar las especificaciones funcionales
y sus limitantes; dar seguimiento y documentar decisiones y alternativas tomadas; y capturar y comunicar con facilidad los requerimientos del negocio. Las nociones de "casos de uso" y escenarios utilizados en el proceso de desarrollo han mostrado ser una excelente forma para capturar los requerimientos funcionales y asegurar que éstos sean el punto único de partida.
Los requerimientos deben dirigir el diseño, la implementación y las pruebas de la aplicación, garantizando que el sistema final cumpla con las necesidades del usuario. Los requerimientos son el vínculo coherente y rastreable que une a todo el ciclo de desarrollo. Rational RequisitePro© y Requirement Composer© es la herramienta que permite automatizar la administración de requerimientos y permite un control del avance del proyecto. Así mismo, tiene una integración transparente con los diferentes flujos y herramientas del ciclo de vida del desarrollo como son: modelado visual, ingeniería de pruebas y control de cambios.
Las metodologías de desarrollo de software han estado presentes durante mucho tiempo y no se han distinguido precisamente por ser muy exitosas para proyectos de equipos pequeños, la crítica más frecuente a estas metodologías es que son burocráticas y que hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retrasa.
Como una reacción a estas metodologías, un nuevo grupo de metodologías ha surgido en los últimos años, durante algún tiempo se conocían como las metodologías ligeras, pero el término aceptado ahora es metodologías ágiles. Para mucha gente el encanto de estas metodologías ágiles es su reacción a la burocracia de las metodologías tradicionales. Estos nuevos métodos buscan un justo medio entre ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
En Simple-Wire contamos con la experiencia y el conocimiento de varias de estas metodologías para ser aplicadas en sus proyectos de desarrollo, brindando así otra alternativa a sus posibilidades.
El análisis es la descomposición de un problema en sus partes integrales, es el proceso de especificaciones de necesidades del usuario, y de las estructuras del sistema, independientemente de los medios de realización o de la descomposición física en módulos o componentes; se centra en la investigación del problema, no en la manera de definir la solución
El diseño es el que produce los detalles que establecen la forma en la que el sistema va a cumplir con los requerimientos identificados durante la fase de análisis; en el diseño de un sistema se indican los datos de entrada, los que serán calculados y los que se almacenarán, así como la descripción con todos los detalles de los procedimientos de cálculos y los datos individuales.
El diseño debe ser modelado como una gráfica dirigida, hecha de entidades con atributos, los cuales participan en relaciones, el sistema debe estar descrito a distintos niveles de abstracción; Por tanto, el Análisis y diseño son un proceso creativo ya que es necesario capturar los objetos del mundo real en términos de abstracciones con el fin de definir el problema y la solución de la manera más general posible.
La Arquitectura de software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución.
El objetivo principal de la arquitectura del software es aportar elementos que ayuden a la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común que permitan la comunicación entre los equipos que participen en un proyecto, para conseguirlo construye abstracciones, materializándolas en forma de diagramas comentados.
Dichos diagramas, según el Rational Unified Process© (RUP) deberían cubrir el modelo de 4+1 capas, dichas capas son las siguientes:
El análisis es la descomposición de un problema en sus partes integrales, es el proceso de especificaciones de necesidades del usuario, y de las estructuras del sistema, independientemente de los medios de realización o de la descomposición física en módulos o componentes; se centra en la investigación del problema, no en la manera de definir la solución.
El diseño es el que produce los detalles que establecen la forma en la que el sistema va a cumplir con los requerimientos identificados durante la fase de análisis; en el diseño de un sistema se indican los datos de entrada, los que serán calculados y los que se almacenarán, así como la descripción con todos los detalles de los procedimientos de cálculos y los datos individuales.
El diseño debe ser modelado como una gráfica dirigida, hecha de entidades con atributos, los cuales participan en relaciones, el sistema debe estar descrito a distintos niveles de abstracción; Por tanto, el Análisis y diseño son un proceso creativo ya que es necesario capturar los objetos del mundo real en términos de abstracciones con el fin de definir el problema y la solución de la manera más general posible.
