Act 1 Corte 2-Software Pra Ingenieros

ADMINISTRACION II
PREGRADO INGENIERIA CIVIL

ESCUELA DE INGENIEROS MILITARES
ESCUELA DE INGENIEROS MILITARES ESING

PREGRADO INGENIERA CIVIL VIRTUAL
Asignatura:
SOFTWARE PARA INGENIEROS
Docente:
JUAN CARLOS FRANCO RODRIGUEZ
COLOMBIA
2017
1
ADMINISTRACION II
ESCUELA DE INGENIEROS MILITARES ESING

PREGRADO INGENIERA CIVIL VIRTUAL
INTEGRANTE:
Mauricio Alberto pardo (Cod.0120142031)
Asignatura:
SOFTWARE PARA INGENIEROS
Docente:
JUAN CARLOS FRANCO RODRIGUEZ
COLOMBIA
2017
2
ADMINISTRACION II
TABLA DE CONTENIDO
1 INTRODUCCION.............................................................................................................4
2 OBJETIVOS.....................................................................................................................5
2.1. GENERALES........................................................................................................5
2.2. ESPECIFICOS.....................................................................................................5
1. MODELO EN CASCADA......................................................................................6
2.1 EL PROCESO UNIFICADO...............................................................................14
2.1.1 Modelos de proceso Personal y de equipo.....................................................15
2.1.2 Proceso personal del software........................................................................15
2.1.3 Proceso del equipo de software.....................................................................16
3. EL PROCESO UNIFICADO DE DESARROLLO (RUP)........................................................17
3.2 El Proceso Unificado est centrado en la arquitectura..................................19
3.3 El Proceso Unificado es Iterativo e Incremental.............................................20
4. METODOLOGAS GILES... 20
4.1 PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP) .21
4.2 OTRAS METODOLOGAS GILES ..22
6. BIBLIOGRAFIA..............................................................................................................26
7. CONCLUCIONES...........................................................................................................27
3
ADMINISTRACION II
1 INTRODUCCION
Los diferentes modelos para la elaboracin de proyectos e implementacin de las

mismas son una herramienta que permite a las personas utilizarlas de una manera
til, en el cual puede cumplir con las expectativas de trabajo y ms hoy en da que
los mercados mundiales piden soluciones inmediatas y de excelente calidad, son
estos modelos que permiten cumplir dichos requerimientos en la ejecucin de
proyectos para los diferentes rea productivas, en el caso de la ingeniera civil
son herramientas eficientes para los proyecto de construccin ya que estos
permite bajar costos y reducir los tiempo de entrega es ah donde nosotros
debemos empezar a utilizar dichas herramientas para el buen desempeo como
ingenieros.
4
ADMINISTRACION II
2 OBJETIVOS
2.1. GENERALES
Identificar los diferentes modelos que se pueden implementar en la ejecucin de

proyectos que nos permita poder desarrollar de una manera gil y eficiente el
desarrollo de las mismas.
2.2. ESPECIFICOS
Conocer los mdelos de Cascada, Modelos de Procesos Incrementales

(Modelo Incremental. Modelo RAD), Modelos de Procesos Evolutivos,
Modelos de Procesos Especializados, Proceso Unificado, Modelos giles y
E-project.
Identificar la importancia de cada uno de los modelos a implementar en

elaboracin de proyectos
5
ADMINISTRACION II
3 MODELO EN CASCADA
El Modelo en Cascada o tambin conocido como Ciclo de Vida del software da las
pautas que permiten la organizacin en el desarrollo del software a travs de la
implementacin de sus caractersticas etapas, esto quiere decir que cuando se
este llevando a cabo todas las tareas pertinentes dentro de esa etapa, no se podr
avanzar a la siguiente etapa hasta no concluir con todas las tareas.
Figura 1
A continuacin una breve descripcin de cada proceso que constituye este
modelo:
Fuente: http://ingenexescom.blogspot.com.co/2012/02/modelo-en-cascada.html
1. Planificacin: Realiza un estudio de factibilidad del software as como

contemplar los posibles costos que pueden surgir mediante su
implementacin.
2. Anlisis y Diseo de Requirimientos: Involucra la identificacin de las

caractersticas que nos guan para determinar las funcionalidades del
6
ADMINISTRACION II
software de acuerdo al medio donde se pretende implementar, es muy

importante notar que trata de responder a las preguntas Quienes
intervienen en el uso del Software?,Qu restricciones tendr el software?.
3. Diseo: Se identifica y describe las abstracciones del software y

cumplir con los requirimientos plasmando todas esas caractersticas en un
diseo que permite visualizar y contemplar adicionalmente situaciones no
previstas.
4. Implementacin: Realizar las pruebas pertinentes y verificar que se

cumplen con las caractersticas identificadas.
5. Operacin y Mantenimiento: Se instala dentro del ambiente,

depender que pasar a partir de ah, ya que esta etapa an puede
considerar nuevamente la existencia de caractersticas que no han sido
contempladas y/o caractersticas innecesarias, implicando la modificacin
del software para la adaptacin de estas anomalas.
6. Crecimiento y cambio: Se evalua el software de modo que se

determina si se puede emplear dentro de la nueva tecnologa no afectando
la integridad del mismo, de modo que si no es posible que exista una
adaptacin a lo nuevo, el proceso de diseo del software nuevamente se
repite desde el principio.
Lamentablemente el uso de este modelo del desarrollo del software pone en jaque
la integridad mientras se construye el sistema, ya que si se falla en una etapa, se
ve obligado a reiniciar practicamente el proceso de construccin, otra de las
situaciones que pueden llevar al fracaso es precisamente una de sus
caracteristicas esenciales, avanzar hasta que se concluya la etapa anterior,
vindolo de este modo, puede atrasar de manera significativa el proceso de
desarrollo de software, quiz tome mucho ms tiempo del que realmente necesite,
otra desventaja es el mantenimiento del software, ya que se involucra la
repeticin de sus pasos que se llevaron a cabo para la constitucin del software
volviendo este mtodo muy tedioso, es recomendable utilizar este modelo siempre
y cuando se conozca los requerimientos.
1.2 MODELO INCREMENTAL
El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el

enfoque incremental de desarrollocomo una forma de reducir la repeticin del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
7
ADMINISTRACION II
decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo

se conoce tambin bajo las siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la

filosofa interactiva de Construccin de Prototipos. el modelo incremental aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario. Cada secuencia lineal produce un incremento del software. El primer
incremento generalmente es un producto esencial denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:
Anlisis
Diseo
Cdigo
Prueba
Figura 2.
Fuente: https://procesosoftware.wikispaces.com/Modelo+Incremental
Sin embargo, para la produccin del Software, se usa el principio de trabajo en

cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte
mejor a sus necesidades reales. El proceso se repite hasta que se elabora el
producto completo.
8
ADMINISTRACION II
El Modelo Incremental es de naturaleza interactiva brindando al final de cada

incremento la entrega de un producto completamente operacional. Este modelo es
particularmente til cuando no se cuenta con una dotacin de personal suficiente.
Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se aadir personal, de ser necesario. Por otro lado los incrementos
se pueden planear para gestionar riesgos tcnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al

final terminar siendo la solucin completa requerida por el cliente, pero stas
partes no se pueden realizar en cualquier orden, sino que dependen de lo que el
cliente este necesitando con ms urgencia, de los puntos ms importantes del
proyecto, los requerimientos ms bsicos, difciles y con mayor grado de riesgo,
ya que estos se deben hacer al comienzo, de manera que se disminuya la
dificultad y el riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que
podr ser entregada al cliente para que ste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efecte para
hacer mejoras en el producto. Estas nuevas mejoras debern esperar a ser
integradas en la siguiente versin junto con los dems requerimientos que no
fueron tomados en cuenta en la versin anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa

del sistema, seguido de sucesivos incrementos funcionales. Cada incremento
tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad
ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre
el mismo, sino nicamente correccin de errores. Dado que la arquitectura
completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos
completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de
requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son ms importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se indica
un subconjunto de funcionalidades que el sistema entregar. La asignacin de
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento.
Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra ms.
9
ADMINISTRACION II
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a

operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.
Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se
implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana

de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

reduciendo sus desventajas slo al mbito de cada incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
Desventajas:
El modelo incremental no es recomendable para casos de sistemas de tiempo
real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de
riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.
1.3 MODELOS EVOLUTIVOS
Qu es un modelo de desarrollo?
Un modelo de desarrollo es una representacin abstracta de un proceso de

software, cada modelo representa el proceso de desarrollo de software de una
manera en particular. A pesar de estar definidos claramente, no representan
necesariamente la realidad de cmo se debe desarrollar el software, sino que
establece un enfoque comn. Un modelo puede ser modificado y adaptado de
acuerdo a las necesidades del software en desarrollo.
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:
1. El modelo en cascada. Considera las actividades fundamentales del proceso de

especificacin, desarrollo, validacin y evolucin, y los representa como fases
10
ADMINISTRACION II
separadas del proceso, tales como la especificacin de requerimientos, el diseo

del software, la implementacin, las pruebas, etctera.
2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacin,

desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de
especificaciones abstractas. ste se refina basndose en las peticiones del cliente
para producir un sistema que satisfaga sus necesidades.
3. Ingeniera del software basada en componentes. Este enfoque se basa en la

existencia de un nmero significativo de componentes reutilizables. El proceso de
desarrollo del sistema se enfoca en integrar estos componentes en el sistema ms
que en desarrollarlos desde cero.
Aunque existen muchos tipos de modelos de desarrollo, de forma genrica la

mayora est clasificada en una de estas 3 categoras, y estos a pesar de ser
diferentes a veces son usados de manera simultneamente especialmente en
sistemas grandes.
1.3.1 Desarrollo Evolutivo
El desarrollo evolutivo consta del desarrollo de una versin inicial que luego de
exponerse se va refinando de acuerdo de los comentarios o nuevos
requerimientos por parte del cliente o del usuario final. Las fases de
especificacin, desarrollo y validacin se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente

para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza
con las partes del sistema que se comprenden mejor. El sistema evoluciona
agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es

comprender los requerimientos del cliente y entonces desarrollar una definicin
mejorada de los requerimientos para el sistema. El prototipo se centra en
experimentar con los requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer

ms ventajas en comparacin con un enfoque en cascada ya que el sistema se va
ajustando a las necesidades del cliente, a la vez que l mismo entiende mejor sus
propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva
de ingeniera y gestin suele tener dos grandes problemas:
1. El proceso no es visible. Los administradores tienen que hacer entregas

regulares para medir el progreso. Si los sistemas se desarrollan rpidamente, no
es rentable producir documentos que reflejen cada versin del sistema.
11
ADMINISTRACION II
2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos
tienden a corromper la estructura del software. Incorporar cambios en l se
convierte cada vez ms en una tarea difcil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado

para sistemas pequeos y medianos. En los sistemas grandes, los constantes
cambios en el desarrollo solo dificultan la estabilidad y la integracin de los
avances de los distintos grupos de trabajo que puedan existir. La mayora de las
empresas que desarrollan grandes sistemas usan un modelo mixto que usa las
mayores fortalezas de los enfoques evolutivos y de cascada.
1.3.2 Modelo Espiral
Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza

prototipos como apoyo. La forma de espiral representa una iteracin (repeticin)
de procesos que, a medida que se van entregando prototipos y stos son
revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar
la prxima versin es cada vez mayor. Cada divisin recibe el nombre de regin
de tareas.
Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el

clculo de los riesgos puede ser muy complicado y no es tan usado en la realidad.
1.3.3 Modelo Espiral WINWIN (gana & gana)
Una variante interesante del Modelo Espiral es el Modelo espiral Win-Win. El

Modelo Espiral previo (clsico) sugiere la comunicacin con el cliente para fijar los
requisitos, en que simplemente se pregunta al cliente qu necesita y l
proporciona la informacin para continuar, sin embargo, esta es una situacin que
rara vez ocurre. Normalmente el cliente y desarrollador entran en una negociacin,
se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
Las mejores negociaciones se fuerzan en obtener Victoria & Victoria (Win &
Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el
desarrollador tambin gane consiguiendo presupuesto y fecha de entrega realista.
Evidentemente, este modelo requiere fuertes habilidades de negociacin.
1.3.4 Modelo de desarrollo concurrente
Es un modelo de tipo de red donde todas las personas actan simultneamente o

al mismo tiempo.
Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas

veces ingeniera concurrente, de la siguiente forma:
12
ADMINISTRACION II
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que
se refiere a las fases importantes [del ciclo de vida clsico] no tiene ideal del
estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos
extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este
en la fase de codificacin, hay personal de ese proyecto implicado en actividades
asociadas generalmente a muchas fases de desarrollo simultneamente. Por
ejemplo,...el personal est escribiendo requisitos diseando, codificando, haciendo
pruebas y probando la integracin (todo al mismo tiempo). Los modelos de
proceso de ingeniera del software de Humphrey y Kellner han mostrado la
concurrencia que existe para actividades que ocurren para cualquier fase. El
trabajo ms reciente de Kellner utiliza diagramas de estado para representar la
relacin concurrente que existe entre actividades asociadas a un acontecimiento
especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas
las actividades del desarrollo y de gestin del software en mi proyecto...La
mayora de los modelos de procesos de desarrollo del software son dirigido por el
tiempo; cuanto ms tarde sea, ms atrs se encontrara en el proceso de
desarrollo. (Un modelo de proceso concurrente) est dirigido por las necesidades
del usuario, las decisiones de la gestin y los resultados de las revisiones.
1.3.5 Modelo Incremental
El modelo incremental es una unin de las mejores funcionalidades del modelo de

cascada y del modelo de prototipos. A medida que se presenta un prototipo se
produce un incremento, que es una iteracin del proceso anterior pero aplicando
las experiencias aprendidas del proceso anterior. A diferencia del modelo de
prototipos, los prototipos de este modelo estn orientados a ser operacionales en
cada incremento y no ser solo una previa de cmo sera el sistema en su versin
final.
4 MODELOS DE PROCESO ESPECIALIZADOS
Los modelos de proceso especializado tienen muchas de las caractersticas de

uno o ms de los modelos tradicionales que se presentaron en las secciones
anteriores. Sin embargo, dichos modelos tienden a aplicarse cuando se elige un
enfoque de ingeniera de software especializado o definido muy especficamente.
Los modelos de proceso especializados son los siguientes:
Figura 3: Modelos de proceso especializados
13
ADMINISTRACION II
Fuente: https://ingsotfwarekarlacevallos.wordpress.com/2015/04/29/modelos-de-procesos-
especializado/
4.1 EL PROCESO UNIFICADO.
El proceso unificado es un intento por obtener los mejores rasgos y caractersticas

de los modelos tradicionales del proceso del software, pero en forma que
implemente muchos de los mejores principios del desarrollo gil de software. El
proceso unificado reconoce la importancia de la comunicacin con el cliente y los
mtodos directos para describir su punto de vista respecto de un sistema. Sugiere
un flujo del proceso iterativo e incremental, lo que da la sensacin evolutiva que
resulta esencial en el desarrollo moderno del software.
Figura 4: Modelos de proceso Unificado
14
ADMINISTRACION II
Fuente: https://ingsotfwarekarlacevallos.wordpress.com/2015/04/29/modelos-de-procesos-
especializado/
La fase de concepcin del PU agrupa actividades tanto de comunicacin con el

cliente como de planeacin. Al colaborar con los participantes, se identifican los
requerimientos del negocio, se propone una arquitectura aproximada para el
sistema y se desarrolla un plan para la naturaleza iterativa e incremental del
proyecto en cuestin.
4.1.1 Modelos de proceso Personal y de equipo
El mejor proceso del software es el que est cerca de las personas que harn el
trabajo. Si un modelo del proceso del software se ha desarrollado en un nivel
corporativo u organizacional, ser eficaz slo si acepta una adaptacin
significativa para que cubra las necesidades del equipo de proyecto que en
realidad hace el trabajo de ingeniera de software.
4.1.2 Proceso personal del software

El proceso personal del software (PPS) pone el nfasis en la medicin personal
tanto del producto del trabajo que se genera como de su calidad. Adems, el PPS
responsabiliza al profesional acerca de la planeacin del proyecto (por ejemplo,
estimacin y programacin de actividades) y delega en el practicante el poder de
controlar la calidad de todos los productos del trabajo de software que se
desarrollen. El modelo del PPS define cinco actividades estructurales:
Figura 5: Modelos de proceso Personal
15
ADMINISTRACION II
Fuente: https://ingsotfwarekarlacevallos.wordpress.com/2015/04/29/modelos-de-
procesos-especializado/
4.1.3 Proceso del equipo de software
El objetivo de ste es construir un equipo autodirigido para el proyecto, que se

organice para producir software de alta calidad.
Los objetivos que se definen para el proceso del equipo de software son los
siguientes:
Formar equipos autodirigidos que planeen y den seguimiento a su trabajo,
que establezcan metas y que sean dueos de sus procesos y planes.
Mostrar a los gerentes cmo dirigir y motivar a sus equipos y cmo
ayudarlos a mantener un rendimiento mximo.
Acelerar la mejora del proceso del software, haciendo del modelo de
madurez de la capacidad, CMM,23 nivel 5, el comportamiento normal y
esperado.
Brindar a las organizaciones muy maduras una gua para la mejora.
16
ADMINISTRACION II
Facilitar la enseanza universitaria de aptitudes de equipo con grado

industrial.
El PES define las siguientes actividades estructurales: inicio del proyecto,

diseo de alto nivel, implementacin, integracin y pruebas, y post
mrtem. Como sus contrapartes del PPS (observe que la terminologa es algo
diferente), estas actividades permiten que el equipo planee, disee y construya
software en forma disciplinada, al mismo tiempo que mide cuantitativamente el
proceso y el producto. La etapa post mrtem es el escenario de las mejoras del
proceso.
5 EL PROCESO UNIFICADO DE DESARROLLO (RUP)
El Proceso Unificado es un proceso de software genrico que puede ser utilizado

para una gran cantidad de tipos de sistemas de software, para diferentes reas de
aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y
diferentes tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y resposabilidades
dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de
software de muy alta calidad que satisfaga las necesidades de los usuarios finales,
dentro de un calendario y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones (Figura 6):
Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo
de vida del proceso a lo largo de su desenvolvimiento
Un eje vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lgica de acuerdo a su naturaleza.
La primera dimensin representa el aspecto dinmico del proceso conforme
se va desarrollando, se expresa en trminos de fases, iteraciones e hitos
(milestones).
La segunda dimensin representa el aspecto esttico del proceso: cmo es
descrito en trminos de componentes del proceso, disciplinas, actividades, flujos
de trabajo, artefactos y roles.
Figura 6
17
ADMINISTRACION II
Fuente: http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
El Proceso Unificado se basa en componentes (component-based), lo que

significa que el sistema en construccin est hecho de componentes de software
interconectados por medio de interfaces bien definidas (well-defined interfaces).
El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la
preparacin de todos los planos del sistema. De hecho, UML es una parte integral
del Proceso Unificado, fueron desarrollados a la par.
Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos
clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura
(architecture-centric), iterativo e incremental. Esto es lo que hace nico al Proceso
Unificado.
3.1. El Proceso Unificado es dirigido por casos de uso.
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para
construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan
los usuarios prospectos.
El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros

sistemas. En este contexto, el trmino usuario representa algo o alguien que
interacta con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario

un resultado de valor. Los casos de uso capturan los requerimientos funcionales.
Todos los casos de uso juntos constituyen el modelo de casos de uso el cual
describe la funcionalidad completa del sistema. Este modelo reemplaza la
tradicional especificacin funcional del sistema. Una especificacin funcional
tradicional se concentra en responder la pregunta: Qu se supone que el sistema
18
ADMINISTRACION II
debe hacer? La estrategia de casos de uso puede ser definida agregando tres
palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una
implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y
no solamente en trminos de las funciones que sera bueno que tuviera. Sin
embargo, los casos de uso no son solamente una herramienta para especificar los
requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas,
esto es, dirigen el proceso de desarrollo.
An y cuando los casos de uso dirigen el proceso, no son elegidos de manera
aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los
casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema
influencia la eleccin de los casos de uso. Por lo tanto, al arquitectura del sistema
y los casos de uso maduran conforme avanza el ciclo de vida.
1.4 El Proceso Unificado est centrado en la arquitectura
El papel del arquitecto de sistemas es similar en naturaleza al papel que el

arquitecto desempea en la construccin de edificios. El edificio se mira desde
diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le
permite al constructor ver una radiografa completa antes de empezar a construir.
Similarmente, la arquitectura en un sistema de software es descrita como
diferentes vistas del sistema que est siendo construido.
El concepto de arquitectura de software involucra los aspectos estticos y
dinmicos ms significativos del sistema. La arquitectura surge de las necesidades
de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y
como estn reflejadas en los casos de uso. Sin embargo, tambin est
influenciada por muchos otros factores, tales como la plataforma de software en la
que se ejecutar, la disponiblidad de componentes reutilizables, consideraciones
de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo,
confiabilidad). La arquitectura es la vista del diseo completo con las
caractersticas ms importantes hechas ms visibles y dejando los detalles de
lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con
la experiencia, el valor de la arquitectura depende del personal asignado a esta
tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas
correctas, tales como claridad (understandability), flexibilidad en los cambios
futuros (resilience) y reuso.
Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene
funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben
estar balanceadas para obtener un producto exitoso. En este caso funcin
corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de
intercalar entre casos de uso y arquitectura. Es un problema del huevo y la
gallina. Por una parte, los casos de uso deben, cuando son realizados,
acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer
19
ADMINISTRACION II
espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la

realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.
1.5 El Proceso Unificado es Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que puede

continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos
pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un
incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los
incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las
iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a
cabo de una manera planeada.
Los desarrolladores basan su seleccin de qu van a implementar en una iteracin
en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en
conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los
riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del
desarrollo a partir del estado en el que fueron dejados en la iteracin anterior.
En cada iteracin, los desarrolladores identifican y especifican los casos de uso
relevantes, crean el diseo usando la arquitectura como gua, implementan el
diseo en componentes y verifican que los componentes satisfacen los casos de
uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo
contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas,
los desarrolladores deben revisar sus decisiones previas y probar un nuevo
enfoque.
2. METODOLOGAS GILES
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino

gil aplicado al desarrollo de software. En esta reunin participan un grupo de
17 expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de metodologas de software. Su objetivo fue esbozar los valores y
principios que deberan permitir a los equipos desarrollar software rpidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que
se genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance3, una organizacin, sin nimo de
lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de
software y ayudar a las organizaciones para que adopten dichos conceptos. El
20
ADMINISTRACION II
punto de partida es fue el Manifiesto gil, un documento que resume la filosofa

gil.
4.1 PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)
XP es una metodologa gil centrada en potenciar las relaciones interpersonales

como clave para el xito en desarrollo de software, promoviendo el trabajo en
equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un
buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el
equipo de desarrollo, comunicacin 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 tcnico.
Tabla 1. Diferencias entre metodologas giles y no giles
Fuente: http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf
2.2 OTRAS METODOLOGAS GILES

Aunque los creadores e impulsores de las metodologas giles ms populares han
suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente,
cada metodologa tiene caractersticas propias y hace hincapi en algunos
21
ADMINISTRACION II
aspectos ms especficos. A continuacin se resumen otras metodologas giles.

La mayora de ellas ya estaban siendo utilizadas con xito en proyectos reales
pero les faltaba una mayor difusin y reconocimiento.
2.2.1 SCRUM
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco
para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10
aos.
Est especialmente indicada para proyectos con un rpido cambio de requisitos.
Sus principales caractersticas se pueden resumir en dos. El desarrollo de
software se realiza mediante iteraciones, denominadas sprints, con una duracin
de 30 das. El resultado de cada sprint es un incremento ejecutable que se
muestra al cliente. La segunda caracterstica importante son las reuniones a lo
largo proyecto, entre ellas destaca la reunin diaria de 15 minutos del equipo de
desarrollo para coordinacin e integracin.
2.2.2 Crystal Methodologies

Se trata de un conjunto de metodologas para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo y la
reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas
por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo
de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de
desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus
habilidades y destrezas, as como tener polticas de trabajo en equipo definidas.
Estas polticas dependern del tamao del equipo, establecindose una
clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal
Orange (25 a 50 miembros).
2.2.3 Dynamic Systems Development Method (DSDM)

Define el marco para desarrollar un proceso de produccin de software. Nace en
1994 con el objetivo de crear una metodologa RAD unificada. Sus principales
caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo
y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del
negocio, modelado funcional, diseo y construccin, y finalmente implementacin.
Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases.
22
ADMINISTRACION II
2.2.4 Adaptive Software Development (ASD)

Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo,
orientado a los componentes software ms que a las tareas y tolerante a los
cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin,
colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se
planifican las caractersticas del software; en la segunda desarrollan las
caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al
cliente. La revisin de los componentes sirve para aprender de los errores y volver
a iniciar el ciclo de desarrollo.
2.2.5 Feature -Driven Development (FDD)

Define un proceso iterativo que consta de 5 pasos.
Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e
implementacin del sistema partiendo de una lista de caractersticas que debe
reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.
2.2.6 Lean Development10 (LD).

Definida por Bob Charettes a partir de su experiencia en proyectos con la industria
japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de
telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si
se manejan adecuadamente se pueden convertir en oportunidades que mejoren la
productividad del cliente. Su principal caracterstica es introducir un mecanismo
para implementar dichos cambios.
2.2.7 Extreme Programming (de ahora en adelante, XP).

Es una metodologa de desarrollo de la ingeniera de software formulada por Kent
Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el ms destacado de los procesos giles de
desarrollo de software. Al igual que stos, la programacin extrema se diferencia
de las metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los
cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en
los requisitos.
23
ADMINISTRACION II
Se puede considerar la programacin extrema como la adopcin de las mejores

metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.
3. Modelo E-project
Con Proyect es fcil crear y modificar un grupo de tareas para realizar sus
objetivos. El software de gestin de proyectos es una herramienta inapreciable
para el establecimiento de un plan de proyecto inicial. Adems, Proyect recalcula
rpidamente los planes y le permite ver como los cambios en una parte del
proyecto pueden afectar al plan en Conjunto. Tareas nuevas, tareas absoletas,
fechas intermedias que afectan a otras tareas, o la disponibilidad irregular de un
recurso podran pasar inadvertidas; pero con Microsoft Proyect puede mantenerlo
todo bajo control. Adems, permite generar informacin para mantener a todos los
que tienen que estar informados en forma rpida y efectiva.
5.1 Identificacin de las fases del proyecto.
Un proyecto se gestiona en fases que progresan a medida que avanza el mismo.

Antes de comenzar la primera tarea del proyecto, se crea una programacin. Una
vez que el proyecto esta en marcha, se puede gestionar las tareas a medida que
vayan llegando y hacer ajustes en la programacin. Al realizar los ajustes, es
necesario comunicar los resultados y modificaciones a personas implicadas en el
proyecto. La lista siguiente identifica las fases del proyecto y describe como se
puede usar Proyect en su implementacin.
Crear un plan realista de proyecto.
Cuando establezca por primera vez las tareas, registros y recursos de un

proyecto. Proyect le ayuda ofreciendole asistente de planificacin, los cuales
mantienen un registr de las decisiones que realice. Facilita tambin el proceso
de lluvias de ideas que suelen acompaar la creacin del plan de proyecto.
Gestionar el proyecto y ajustarse a los cambios.
Gestionar un proyecto implica un seguimiento del estado de las tareas y la

determinacin de si las tareas estn realizndose como se planearon. Si una tarea
se retrasa, necesita determinar si seguir siendo capaz de alcanzar su objetivo y si
es necesario un ajuste del plan. Adems, siempre se debe contar con lo
inesperado en un proyecto, como un recurso deja de estar disponible de repente,
un recorte presupuestario, la compra de equipos nuevos y mas rpidos o la
contratacin de un nuevo empleado.
24
ADMINISTRACION II
Comunicacin de los resultados y el progreso.
Generalmente un proyecto implica a ms de una persona. Para que todos puedan

trabajar efectivamente, es importante comunicar los planes y expectativas del
proyecto. Mediante el uso de una amplia variedad de informes, puede coordinar
efectivamente el proyecto.
Adems, cuando la directiva requiere informacin sobre el desarrollo del proyecto,

debe asegurarse de presentar la informacin del proyecto de un modo conciso.
Evaluar el rendimiento del proyecto una vez finalizado.
A medida que progresa un proyecto. Proyect recopila y almacena toda la

informacin relativa a tareas, recursos y costos. Al final del proyecto, esta
informacin puede ser utilizada para evaluar la efectividad del plan original y hacer
recomendaciones sobre como mejorar la planificacin y el desarrollo de proyectos
futuros.
6 BIBLIOGRAFIA
http://tema3isoftware.blogspot.com.co/p/modelos-de-desarrollo-tecnicas-y.html
25
ADMINISTRACION II
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
https://procesosoftware.wikispaces.com/Modelo+Incremental
http://ingenexescom.blogspot.com.co/2012/02/modelo-en-cascada.html
https://ingsotfwarekarlacevallos.wordpress.com/2015/04/29/modelos-de-procesos-
especializado/
http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf
7 CONCLUCIONES
26
ADMINISTRACION II
Un modelo incremental traslada las ideas a un proceso modular en el cual otorgan

productos parciales de software al sistema llamados incrementos. En el cual se
tomadas en referencia a la prelacin determinada.
El modelo permite ampliar o mejorar cada adicin que se requerir para as dar
oportunidad de mejorar la funcionalidad con la finalidad de darle mejor calidad al
producto software.
Los modelos especializados han permitido cambiar los procesos tradicionales con
caractersticas nicas que eficientes los sistemas en el desarrollo de software con
adaptaciones nicas para su funcionamiento.
27

Act 1 Corte 2-Software Pra Ingenieros

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Act 1 Corte 2-Software Pra Ingenieros

Загружено:

Авторское право:

Доступные форматы

ADMINISTRACION II

PREGRADO INGENIERIA CIVIL

ESCUELA DE INGENIEROS MILITARES ESING

ESCUELA DE INGENIEROS MILITARES ESING

4.2 OTRAS METODOLOGAS GILES ..22

Los diferentes modelos para la elaboracin de proyectos e implementacin de las

Identificar los diferentes modelos que se pueden implementar en la ejecucin de

Conocer los mdelos de Cascada, Modelos de Procesos Incrementales

Identificar la importancia de cada uno de los modelos a implementar en

1. Planificacin: Realiza un estudio de factibilidad del software as como

2. Anlisis y Diseo de Requirimientos: Involucra la identificacin de las

software de acuerdo al medio donde se pretende implementar, es muy

3. Diseo: Se identifica y describe las abstracciones del software y

4. Implementacin: Realizar las pruebas pertinentes y verificar que se

5. Operacin y Mantenimiento: Se instala dentro del ambiente,

6. Crecimiento y cambio: Se evalua el software de modo que se

1.2 MODELO INCREMENTAL

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el

decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo

Mtodo de las comparaciones limitadas sucesivas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la

En una visin genrica, el proceso se divide en 4 partes:

Sin embargo, para la produccin del Software, se usa el principio de trabajo en

El Modelo Incremental es de naturaleza interactiva brindando al final de cada

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa

El usuario se involucra ms.

Difcil de evaluar el costo total.

Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a

Requiere gestores experimentados.

Los errores en los requisitos se detectan tarde.

El resultado puede ser positivo.

Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana

El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

1.3 MODELOS EVOLUTIVOS

Un modelo de desarrollo es una representacin abstracta de un proceso de

En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

1. El modelo en cascada. Considera las actividades fundamentales del proceso de

separadas del proceso, tales como la especificacin de requerimientos, el diseo

2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacin,

3. Ingeniera del software basada en componentes. Este enfoque se basa en la

Aunque existen muchos tipos de modelos de desarrollo, de forma genrica la

1.3.1 Desarrollo Evolutivo

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer

1. El proceso no es visible. Los administradores tienen que hacer entregas

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado

1.3.2 Modelo Espiral

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza

Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el

1.3.3 Modelo Espiral WINWIN (gana & gana)

Una variante interesante del Modelo Espiral es el Modelo espiral Win-Win. El

1.3.4 Modelo de desarrollo concurrente

Es un modelo de tipo de red donde todas las personas actan simultneamente o

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas

1.3.5 Modelo Incremental

El modelo incremental es una unin de las mejores funcionalidades del modelo de

4 MODELOS DE PROCESO ESPECIALIZADOS

Los modelos de proceso especializado tienen muchas de las caractersticas de

Los modelos de proceso especializados son los siguientes:

Figura 3: Modelos de proceso especializados

4.1 EL PROCESO UNIFICADO.