Metodologías para el Análisis y Diseño de Sistemas

1. Análisis y diseño de sistemas
Integrante:
Oblitas Christian
C.I.20350155

2. Introducción
Todas las organizaciones son sistemas que actúan recíprocamente con
su medio ambiente recibiendo entradas y produciendo salidas. Los sistemas,
que pueden estar formados por otros sistemas más pequeños denominados
subsistemas, funcionan para alcanzar fines específicos.
En la actualidad para muchas organizaciones, los sistemas de
información basados en software y equipos computarizados son parte
fundamental en el desarrollo de las actividades cotidianas y son parte
fundamental en la toma de decisiones dentro de la organización, sus sistemas
de información son fundamentales a la hora de planificar el ingreso o no en
nuevos mercados o cuando planean la respuesta que darán a la competencia.
Al establecer los sistemas de información se debe tener la certeza de que
se logren dos objetivos principales: que sea un sistema correcto y que este
correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será
completamente útil para la organización además de tener un valor único si
funciona en forma adecuada.
Los informes y las salidas producidas por el sistema deben ser precisos,
confiables y completos. La función del Análisis puede ser dar soporte a las
actividades de un negocio, o desarrollar un producto que pueda venderse para
generar beneficios.
Es el Proceso de gestión para la creación de un Sistema o software, la cual
encierra un conjunto de actividades, una de las cuales es la estimación, estimar
es echar un vistazo al futuro y aceptamos resignados cierto grado de
incertidumbre.
Aunque la estimación, es más un arte que una Ciencia, es una actividad
importante que no debe llevarse a cabo de forma descuidada.
Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la
estimación es la base de todas las demás actividades
de planificación del proyecto y sirve como guía para una
buena Ingeniería Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en
el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El
Tamaño del proyecto es otro factor importante que puede afectar la precisión
de las estimaciones.
A medida que el tamaño aumenta, crece rápidamente la interdependencia
entre varios elementos del Software. La disponibilidad de información Histórica
es otro elemento que determina el riesgo de la estimación Sin embargo, los
propósitos o metas se alcanzan sólo cuando se mantienen el control de la
información dentro de la organización.

3. 1. Definición de:
1.1. Método: Modo ordenado y sistemático de proceder para llegar a un
resultado o fin determinado.
1.2. Metodología: Conjunto de métodos que se siguen en una investigación
científica, un estudio o una exposición doctrinal.
2. Metodologías para el Análisis y Diseño de Sistemas (Explicar Etapas, Fases
y Actividades).
2.1. Lenguaje Unificado de Modelado (UML) (Diagramas): Lenguaje
Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG (Object
Management Group). Es un lenguaje gráfico para visualizar, especificar,
construir y documentar un sistema. UML ofrece un estándar para describir
un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales
como procesos de negocio, funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programación, esquemas de bases de
datos y compuestos reciclados.
Las fases de este sistema son:
Análisis de requerimientos: UML tiene casos de uso (use-cases) para
capturar los requerimientos del cliente a través del modelado de casos de
uso, los actores externos que tienen interés en el sistema son modelados
con la funcionalidad que ellos requieren del sistema (los casos de uso). los
actores y los casos de uso son modelados con relaciones y tienen
asociaciones entre ellos o éstas son divididas en jerarquías los actores y
casos de uso son descritos en un diagrama use-case cada use-case es
descrito en texto y especifica los requerimientos del cliente: lo que él (o ella)
espera del sistema sin considerar la funcionalidad que se implementará un
análisis de requerimientos puede ser realizado también para procesos de
negocios, no solamente para sistemas de software.
Análisis: La fase de análisis abarca las abstracciones primarias (clases y
objetos) y mecanismos que están presentes en el dominio del problema las
clases que se modelan son identificadas, con sus relaciones y descritas en
un diagrama de clases las colaboraciones entre las clases para ejecutar los
casos de uso también se consideran en esta fase a través de los modelos
dinámicos en uml es importante notar que sólo se consideran clases que
están en el dominio del problema (conceptos del mundo real) y todavía no
se consideran clases que definen detalles y soluciones en el sistema de
software, tales como clases para interfaces de usuario, bases de datos,
comunicaciones, concurrencia, etc.

4. Diseño: En la fase de diseño, el resultado del análisis es expandido a una
solución técnica se agregan nuevas clases que proveen de la
infraestructura técnica: interfaces de usuario, manejo de bases de datos
para almacenar objetos en una base de datos, comunicaciones con otros
sistemas, etc. las clases de dominio del problema del análisis son
agregadas en esta fase el diseño resulta en especificaciones detalladas
para la fase de programación.
Programación: En esta fase las clases del diseño son convertidas a código
en un lenguaje de programación orientado a objetos cuando se crean los
modelos de análisis y diseño en UML, lo más aconsejable es trasladar
mentalmente esos modelos a código.
Pruebas: Normalmente, un sistema es tratado en pruebas de unidades,
pruebas de integración, pruebas de sistema, pruebas de aceptación, etc las
pruebas de unidades se realizan a clases individuales o a un grupo de
clases y son típicamente ejecutadas por el programador las pruebas de
integración integran componentes y clases en orden para verificar que se
ejecutan como se especificó las pruebas de sistema ven al sistema como
una "caja negra" y validan que el sistema tenga la funcionalidad final que le
usuario final espera las pruebas de aceptación conducidas por el cliente
verifican que el sistema satisface los requerimientos y son similares a las
pruebas de sistema.
2.2. Metodología del Ciclo de Vida de un Sistema de James Martín: Esta
metodología de desarrollo de Software es mejor conocida como
Metodología RAD (Rapid Application Development) o Desarrollo rápido de
Aplicaciones, y fue creada por el gurú de computación James Martin en
1991. Está orientada a disminuir radicalmente el tiempo necesario para
diseñar e implementar Sistemas de Información, el RAD cuenta con una
participación intensa del usuario, sesiones JAD, prototipaje, herramientas
CSE integradas y generadores de código. El Rad requiere cuatro
ingredientes esenciales: gerencia, gente, metodologías y herramientas.
Etapas:
Etapa de Planificación de Requisitos: Esta etapa requiere que los
usuarios con un vasto conocimiento de los procesos de la compañía
determinen cuáles serán las funciones del sistema. Debe darse una
discusión estructurada sobre los problemas de la compañía que necesitan
solución.
Etapa de Diseño: Esta consiste de un análisis detallado de las actividades
de la compañía en relación al sistema propuesto. Los usuarios participan
activamente en talleres bajo la tutela de los profesionales de la informática.
En ellos descomponen funciones y definen entidades asociadas con el

5. sistema. Una vez se completa el análisis se crean los diagramas que
definen las alteraciones entre los procesos y la data.
Construcción: En la etapa de construcción el equipo de desarrolladores
trabajando de cerca con los usuarios finalizan el diseño y la construcción del
sistema. La construcción de la aplicación consiste de una serie de pasos
donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar
los resultados.
Implementación: Esta etapa envuelve la implementación del nuevo
producto y el manejo de cambio del viejo al nuevo sistema. Se hacen
pruebas comprensivas y se adiestran los usuarios.
2.3. Metodología del Proceso Unificado de Desarrollo de Software: Es
una metodología de desarrollo de software que está basado en
componentes e interfaces bien definidas, y junto con el Lenguaje Unificado
de Modelado (UML), constituye la metodología estándar más utilizada para
el análisis, implementación y documentación de sistemas orientados a
objetos.
Fase de Inicio:
 Es la fase más pequeña del proyecto e, idealmente, debe realizarse
también en un periodo de tiempo pequeño (una única iteración).
 El hecho de llevar a cabo una fase de inicio muy larga indica que se esta
realizando una especificación previa excesiva, lo que responde más a un
modelo en cascada.
Fase de Elaboración:
 Durante esta fase se capturan la mayoría de los requisitos del sistema.
 Los objetivos principales de esta fase serán la identificación de riesgos y
establecer y validar la arquitectura del sistema.
 Base de Arquitectura Ejecutable:
 Al final de la fase se elabora un plan para la fase de construcción.
 El hito arquitectura del ciclo de vida marca el final de la fase.
Fase de construcción:
 Es la fase más larga de proyecto.
 El sistema es construido en base a lo especificado en la fase de
elaboración.
 Las características del sistema se implementan en una serie de
iteraciones cortas y limitadas en el tiempo.
 El resultado de cada iteración es una versión ejecutable de software.
 El hito de capacidad operativa inicial marca el final de la fase.
Fase de transición:

6.  En esta fase el sistema es desplegado para los usuarios finales.
 La retroalimentación recibida permite incorporar refinamientos al sistema
en las sucesivas iteraciones.
 Esta iteración también cubre el entrenamiento de los usuarios para la
utilización del sistema.
 El hito de lanzamiento del producto marca el final de la fase.
2.4. Metodología de Kendall y Kendall: El ciclo de vida del desarrollo de
sistemas (SDLC, Systems Development life cycle) es un enfoque por fases
para el análisis y el diseño cuya premisa principal consiste en que los
sistemas se desarrollan mejor utilizando un ciclo especifico de actividades
del analista y el usuario.
FASE I: Identificación de problemas, oportunidades y objetivos.
 Observación directa del entorno.
 Aplicación de entrevista para recolectar información.
 Sintetizar la información recolectada para construir objetivos.
 Estimar el alcance del proyecto.
 Identificar si existe una necesidad, problema u oportunidad
argumentada. Documentar resultados.
 Estudiar los riesgos del proyecto.
 Presentar un informe de vialidad.
FASE II: Determinación de los requerimientos de información.
 Revisión de los objetivos.
 Identificar el dominio.
 Investigar la razón por la cual se implementa el sistema actual.
 Recolectar información sobre los procedimientos y operaciones que se
desempeñan actualmente.
FASE III: Análisis de las necesidades.
 Evaluar las dos fases anteriores.
 Modelar las entradas, los procesos y las salidas de las funciones ya
identificadas.
 Elaborar diccionario de datos y sus especificaciones.
 Elaborar diagramas de procesos de cada función.
 Elaborar propuesta del sistema con todos los diagramas de operaciones
y de procesos.

7.  Realizar el análisis del riesgo sobre el realizado en las fases anteriores,
tomando en cuenta el aspecto económico, técnico y operacional (estudio
de factibilidad)
 Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el
sistema.
FASE IV: Diseño del sistema recomendado.
 Evaluar las tres fases anteriores.
 Realizar el diseño lógico de todo el sistema.
 Elaborar procedimientos precisos para la captura de los datos que van a
ingresar al sistema de información.
 Elaborar el diseño de la base de datos.
 Diseñar las diferentes interfaces de usuarios de cada operación,
procedimiento y/o función.
 Diseñar controles y procedimientos de respaldos que protejan al sistema
y a los datos.
 Producir los paquetes específicos de programas para los
programadores.
 Elaborar una lista de las funciones genéricas y de las que será
obligatorio crear.
FASE V: Desarrollo y documentación del software.
 Evaluar los procedimientos que va a ser desarrollados por el
programador.
 Mostrar y explicar cada procedimiento, función y operación al
programador.
 Elaborar manuales de procedimientos internos del sistema.
 Elaborar manuales externos de ayuda a los usuarios del sistema.
 Elaborar demostraciones para los usuarios y la interacción con distintas
interfaces.
 Elaborar actualizaciones para los diferentes procedimientos. Elaborar un
informe con el tiempo que se llevó construir cada procedimiento.
FASE VI: Prueba y mantenimiento del sistema.
 Realizar la programación de las pruebas del sistema. Realizar un
instrumento para evaluar el sistema de información.
 El programador deberá elaborar un resumen de las pruebas del
sistema.
 El analista deberá realizar un informe de sus pruebas y discutirlo con el
programador.

8.  Elaborar la planificación de las horas del mantenimiento del sistema.
Elaborar la lista de las operaciones que pudieran sufrir modificaciones
de códigos.
FASE VII: Implementación y evaluación del sistema.
 Planificar gradualmente la conversión del sistema anterior.
 Instalar los equipos de hardware necesarios para el funcionamiento del
software creado.
 Capacitar por medio de talleres a los usuarios en el manejo de equipos y
software creados.
 Evaluar la adaptabilidad de los usuarios al sistema.
2.5. Metodología de Administración de Relaciones (RMM): La
metodología RMM permite hacer explícita la navegación al hacer el análisis,
lo que permite, teóricamente, obtener una navegación más estructurada e
intuitiva, y lo hace de una forma muy sencilla, como es añadir unas
primitivas a un modelo entidad-relación tradicional.
Fase 1. Diseño Entidad Relación. Representar los objetos del dominio con la
ayuda del modelo Entidad-Relación ampliado con relaciones asociativas
(aquéllas que permiten representar caminos de navegación entre entidades
puestos en evidencia en la fase de análisis).
Fase 2. Realizar los diseños de slice. Para cada entidad detectada en la fase
anterior, se define un diagrama de slices ya que esta es la manera en que se
presentara los atributos de la entidad al usuario, al culminar se debe alcanzar
un modelo compuesto por slices y enlaces.
Fase 3. Diseñar la navegación. Definir los caminos de navegación inducidos
por las relaciones asociativas del esquema E-R. A continuación, es posible
definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar
a la aplicación de accesos jerárquicos a niveles diferentes de los trozos de
información. El esquema RMDM resultante se obtiene añadiendo al esquema
E-R+ las agrupaciones y caminos de navegación definidos en esta etapa.
Fase 4. Definir el protocolo de conversión. En esta fase se lleva el modelo
RMDM a la plataforma en concreto es decir, se busca pasar del modelo RMDM
a la elaboración de la aplicación, para las cuales son se estima ninguna técnica
en concreto.
Fase 5. Diseñar la interfaz. Se desarrollan las pantallas del sistema, las
mismas deben corresponder con los slice antes seleccionados.
Fase 6. Implementar la aplicación. Se realiza la implementación según los
protocolos de conversión establecidos en la fase 4.

9. Fase 7. Probar la aplicación. Una vez implementada la aplicación se procede a
realizar las pruebas del sistema. Para ello es necesario establecer los métodos
de validación que se ajusten al sistema.
2.7. Metodología Orientada a Objetos: La metodología OMT (Object
Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en
1991, mientras James dirigía un equipo de investigación de los laboratorios
General Electric.
OMT es una de las metodologías de análisis y diseño orientada a objetos, más
madura y eficiente que existe en la actualidad. La gran virtud que aporta esta
metodología es su carácter de abierta (no propietaria), que le permite ser de
dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto
facilita su evolución para acoplarse a todas las necesidades actuales y futuras
de la ingeniería de software.
Las fases que conforman a la metodología OMT son:
1. Análisis. El analista construye un modelo del dominio del problema,
mostrando sus propiedades más importantes. El modelo de análisis es una
abstracción resumida y precisa de lo que debe de hacer el sistema deseado y
no de la forma en que se hará. Los elementos del modelo deben ser conceptos
del dominio de aplicación y no conceptos informáticos tales como estructuras
de datos. Un buen modelo debe poder ser entendido y criticado por expertos en
el dominio del problema que no tengan conocimientos informáticos.
2. Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel
sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en
subsistemas basándose tanto en la estructura del análisis como en la
arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
3. Diseño de objetos. El diseñador de objetos construye un modelo de diseño
basándose en el modelo de análisis, pero incorporando detalles de
implementación. El diseño de objetos se centra en las estructuras de datos y
algoritmos que son necesarios para implementar cada clase. OMT describe la
forma en que el diseño puede ser implementado en distintos lenguajes
(orientados y no orientados a objetos, bases de datos, etc.).
4. Implementación. Las clases de objetos y relaciones desarrolladas durante el
análisis de objetos se traducen finalmente a una implementación concreta.
Durante la fase de implementación es importante tener en cuenta los principios
de la ingeniería del software de forma que la correspondencia con el diseño
sea directa y el sistema implementado sea flexible y extensible.

10. 2.8. Metodología de Sistemas Expertos por David Rolston: Un sistema
experto (SE), es básicamente un programa de computadora basado en
conocimientos y raciocinio que lleva a cabo tareas que generalmente solo
realiza un experto humano; es decir, es un programa que imita el
comportamiento humano en el sentido de que utiliza la información que le
es proporcionada para poder dar una opinión sobre un temas en especial.
Se puede decir que los Sistemas Expertos son el primer resultado
operacional de la inteligencia artificial , pues logran resolver problemas a
través del conocimiento y raciocinio de igual forma que lo hace el experto
humano.
2.9. Metodología del software educativo por Álvaro Galvis (ISE)
Es una metodología de desarrollo de software que contempla una serie de fases o
etapas de un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y
ajuste, y por último implementación.
Etapas:
Etapa 1: Análisis
Características de la población objetivo: edad (física y mental), sexo, características
físicas y mentales (si son relevantes), experiencias previas, expectativas, actitudes,
aptitudes, intereses o motivadores por aprender.
Conducta de entrada y campo vital: nivel escolar, desarrollo mental, físico o psicológico,
entorno familiar y escolar, etc.
Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los
mecanismos de análisis de necesidades educativas en. Estos mecanismos usan
entrevistas, análisis de resultados académicos, etc. para detectar los problemas o posibles
necesidades que deben ser atendidas. El problema o necesidad no tiene que estar
necesariamente relacionado con el sistema educativo formal, pueden ser necesidades
sentidas, económicas, sociales, normativas, etc.
Principios pedagógicos y didácticos aplicables: se debe analizar cómo se ha llevado a
cabo el proceso de enseñanza-aprendizaje para establecer cómo debe enfocarse el
ambiente, qué factores tomar en cuenta, qué objetivos debe cumplir.
Justificación de uso de los medios interactivos: Para cada problema o necesidad
encontrada se debe establecer una estrategia de solución contemplando diferentes
posibilidades. El apoyo informático debe ser tomado en cuenta siempre y cuando no exista
un mecanismo mejor para resolver el problema: soluciones administrativas, ver si el

11. problema se soluciona al tomar decisiones de tipo administrativo; soluciones académicas,
cambios en metodologías de clase; mejoras a los medios y materiales de enseñanza
contemplando el uso de medios informáticos. Una vez que se han analizado todas las
alternativas se puede decir por qué el uso de medios informáticos es una buena solución.
La justificación se puede basar en la no existencia de otro medio mejor y en la relación
costo-beneficio para la institución pues puede ser que exista una mejor solución pero que
demande mayor tiempo y esfuerzo o un mayor costo económico, etc.
Diagramas de interacción: Permiten ver secuencias de interacción entre el usuario y la
aplicación, representando lo que se espera del diálogo y dando más detalle a la
descripción textual de la descripción de la aplicación. Los diagramas de interacción son un
formalismo que permite ver la secuencia de acciones entre diferentes partes de la
aplicación involucrada en llevar a cabo determinada actividad. Es importante ver la
secuencia de acciones para cada escenario de interacción. Con base en estos diagramas
se pueden ver cuáles pueden ser las necesidades de información en cada escenario de
interacción y se puede ir pensando en cuáles pueden ser los algoritmos que serán
usados.
Etapa 2: Diseño
Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y
tratamiento que debe ser capaz de apoyar el Sistema Educativo).
Comunicacional (es donde se maneja la interacción entre usuario y máquina, se
denomina interfaz).
Computacional (con base a las necesidades se establece qué funciones es deseable
que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los
estudiantes).
Etapa 3: Desarrollo
En esta fase se implementa la aplicación usando la información obtenida anteriormente.
Tomando en cuenta las restricciones que se tengan.
Etapa 4: Prueba Piloto
En esta etapa se pretende ayudar a la depuración del Sistema Educativo a partir de su
utilización por una muestra representativa de los tipos de destinatarios para los que se hizo
y la consiguiente evaluación formativa. Es imprescindible realizar ciertas validaciones
(efectuadas por expertos) de los prototipos durante las etapas de diseño y prueba en uno a
uno de los módulos desarrollados, a medida que estos están funcionales.
Etapa 5: Prueba de Campo:

12. La prueba de campo de un Sistema Educativo es mucho más que usarlo con toda la
población objeto.
Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de desarrollo
hay que buscar la oportunidad de comprobar, en la vida real, que aquello que a nivel
experimental parecía tener sentido, lo sigue teniendo, es decir, si efectivamente la
aplicación satisface las necesidades y cumple la funcionalidad requerida.
2.9. Metodología de Sistemas Blandos (SSM) de Peter Checkland:
La Metodología de Sistemas Blandos (SSM por sus siglas en inglés) de Peter
Checkland es una técnica cualitativa que se puede utilizar para aplicar los sistemas
estructurados a las situaciones sistémicas. Es una manera de ocuparse de problemas
situacionales en los cuales hay una actividad con un alto componente social, político y
humano. Esto distingue el SSM de otras metodologías que se ocupan de los
problemas DUROS que están a menudo más orientados a la tecnología.
El SSM aplica los sistemas estructurados al mundo actual de las organizaciones
humanas. Pero crucialmente sin asumir que el tema de la investigación es en sí mismo
es un sistema simple. El SSM por lo tanto es una manera útil de acercarse a
situaciones complejas y a las preguntas desordenadas correspondientes.
PASOS DE LA METODOLOGÍA DE SISTEMAS BLANDOS.
Se deben tomar las siguientes medidas (a menudo se requieren variasrepeticiones):
1. Investigue el problema no estructurado.
2. Exprese la situación del problema a través de “gráficas
enriquecidas”. Las gráficas enriquecidas son los medios para
capturar tanta información como sea posible referente a la
situación problemática. Una gráfica enriquecida puede mostrar
límites, la estructura, flujos de información, y los canales de
comunicación. Pero particularmente muestra el sistema humano
detrás dela actividad. Éste es el elemento que no está incluido en modelos
como: diagramas de flujo o modelos de clase.
3. Definiciones de fondo de los sistemas relevantes. ¿De qué divers
as perspectivas podemosobservar esta situaciónproblemática?
Las definiciones de fondo se escriben como oraciones que elaboren una transformación.
Hay seis elementos que definen como bien formulada a una definición de
fondo. Se resumen en las siglas CAPWORA:
 Cliente: Todos los que pueden ganar algún beneficio del sistema son
considerados clientes del sistema. Si el sistema implica sacrificios tales
como despidos, entonces esas víctimas deben también ser contadas como
clientes.
 Actores: Los agentes transforman las entradas en salidas y realizan las
actividades definidas en el sistema.

13.  Proceso de transformación: Este se muestra como la conversión de las
entradas en salidas.
 Weltanschauung: La expresión alemana para la visión del mundo. Esta
visión del mundo hace el proceso de transformaciónsignificativo en el contexto.
 Dueño: Cada sistema tiene algún propietario, que tiene el poder de comenzar y de
cerrar el sistema (poder de veto).
 Restricciones ambientales: Éstos son los elementos externos que deben ser
considerados. Estas restricciones incluyen políticas organizacionales así
como temas legales y éticos.
2.11. Metodología MERINDE: Merinde es un proyecto que propone un
estándar abierto para el proceso de desarrollo de software orientado a
planes que se estructura en dos dimensiones o ejes:
Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos
dinámicos del proceso. Indica las características del ciclo de vida del proceso
expresado en términos de fases, iteraciones e hitos.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el
proceso en términos de componentes de proceso, disciplinas, actividades,
artefactos y roles.
2.12. Metodología SCRUM: método de desarrollo de nuevos productos
realizado con equipos reducidos, multidisciplinares, que trabajan con
comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o
fases secuenciales.
Esta forma de trabajo logra niveles de eficiencia y valor en el producto
superiores a los obtenidos con ingeniería secuencial y producción basada en
procesos.
FASES DE SCRUM
SCRUM comprende las siguientes fases:
1.- Pre-juego
Planificación: Definición de una nueva versión basada en la pila actual, junto
con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta
fase abarca tanto la visión como el análisis. Si se trata de la mejora de un
sistema existente comprende un análisis de alcance más limitado. Arquitectura:
Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye
la modificación de la arquitectura y diseño generales.

14. 2.- Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con
respeto continúo a las variables de tiempo, requisitos, costo y competencia. La
interacción con estas variables define el final de esta fase. El sistema va
evolucionando a través de múltiples iteraciones de desarrollo o sprints.
3.- Post-juego
Preparación para el lanzamiento de la versión, incluyendo la documentación
final y pruebas antes del lanzamiento de la versión.
Pasos de cada fase.
Pasos de la planificación.
 Desarrollo de un backlog completo.
 Determinación de la fecha de entrega y la funcionalidad de una o más
versiones.
 Selección de la versión más adecuada para desarrollo inmediato.
 Trazado de los “paquetes del producto” (objetos) sobre los elementos del
backlog de la versión elegida.
 Selección del equipo o equipos para desarrollar la nueva versión.
 Evaluación y control adecuado de los riesgos.
 Estimación del coste de la versión, incluyendo desarrollo, material,
marketing, formación y despliegue.
 Conformidad de la dirección y financiación del proyecto.
Pasos de diseño y arquitectura.
 Revisión de los elementos del backlog incluidos en la versión.
 Identificación de los cambios necesarios para implementar el backlog.
 Análisis del dominio para incluir los requisitos que incluye el desarrollo
mejora o actualización.
 Acotar la arquitectura del sistema para apoyar el nuevo contexto y
necesidades.
 Identificar problemas del desarrollo o modificaciones.
 Reunión de revisión de diseño. Cada equipo presenta los cambios para
implementar los elementos del backlog, e identificar posibles
reasignaciones.

15. Pasos del desarrollo (Sprint).
La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el
cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido
también como ingeniería concurrente.
El desarrollo consiste en los siguientes macro-procesos:
 Reunión con los equipos para revisar los planes de lanzamiento de versión.
 Distribución, revisión y ajuste de los estándares de conformidad para el
producto.
 Sprints iterativos hasta que el producto se considera listo para su
distribución.
Un sprint es un conjunto de actividades de desarrollo llevado a cabo durante un
periodo predefinido, por lo general entre unas y cuatro semanas. Duración
basada en la complejidad del producto, evaluación de riesgos y grado de
supervisión deseado. El tiempo determinado para el sprint establece su
velocidad e intensidad. El riesgo se evalúa de forma continua a través de las
respuestas a los controles adecuados establecidos.
Cada sprint consiste en uno o varios equipos realizando:
 Desarrollo: Definición de los cambios necesarios para la implementación
de los requisitos del backlog en módulos, la apertura de los módulos,
análisis del dominio, diseño, desarrollo, implementación, pruebas y
documentación de los cambios. El Desarrollo consiste en el micro proceso
de descubrimiento, invención e implementación.
 Envoltura: Cierre de los módulos, creación de una versión ejecutable con
los cambios que implementas los requisitos del backlog.
 Revisión: Reunión de todos los equipos para presentar el trabajo y revisar
el progreso, identificando y resolviendo posibles cuestiones y añadiendo
nuevos elementos al backlog. Se revisan los riesgos y las respuestas
apropiadas.
 Ajuste: Consolidación de la información de la revisión de los módulos
afectados.
Cada sprint es seguido de una revisión cuyas características son:
 Está presente y participa el equipo al completo.
 La revisión puede incluir a clientes, personal de ventas y otros.
 La revisión cubre los sistemas funcionales y ejecutables abarcados por el
equipo e incluye los cambios que se han realizado para implementar los
elementos del backlog.
 En la revisión se pueden evidenciar cambios en la forma en la que se han
implementado los elementos del backlog.

16.  La revisión también puede introducir elementos nuevos en el backlog,
cambiando de esta forma los contenidos y dirección de las versiones
previstas.
 Se determina la fecha de la siguiente revisión en base al progreso y
complejidad. La duración normal de los sprints es de 1 a 4 semanas.

17. Conclusiones
Un proyecto de desarrollo de un Sistema de Información comprende varios
componentes o pasos llevados a cabo durante la etapa del análisis, el cual
ayuda a traducir las necesidades del cliente en un modelo de Sistema que
utiliza uno mas de los componentes: Software, hardware, personas, base de
datos, documentación y procedimientos.
En una organización o Empresa, el análisis y Diseño de Sistemas, es el
proceso de estudiar su Situación con la finalidad de observar como trabaja y
decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas
tareas es el analista de sistemas. Antes de comenzar con el desarrollo de
cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los
detalles de la situación actual de la empresa. La información reunida con este
estudio sirve como base para crear varias estrategias de Diseño. Los
administradores deciden que estrategias seguir.
Los Gerentes, empleados y otros usuarios finales que se familiarizan cada
vez más con el uso de computadoras están teniendo un papel muy importante
en el desarrollo de sistemas. Todas las organizaciones son Sistemas que
actúan de manera reciproca con su medio ambiente recibiendo entradas y
produciendo salidas. Los Sistemas que pueden estar formados por otros
Sistemas de denominan subsistemas y funcionan para alcanzar los fines de su
Implantación.

18. BIBLIOGRAFIA
 https://www.google.co.ve/webhp?sourceid=chrome-
instant&rlz=1C1AVNC_enVE583VE583&ion=1&espv=2&ie=UTF-
8#q=definicion%20de%20metodo
 http://5tosemestreinganalEisisdesistemas.blogspot.com/p/html
 http://es.slideshare.net/angel20155/analisis-y-diseos-de-sistemas