Primeras 2-3 palabras del Ttulo

MODELOS DE PROCESOS

Modelos de Procesos
Meyker Widmen Mayta Perca

2011 119015.

Poleth Katerine Alanoca Ramrez

2011 119006.

Jos Bryan Velasco Charca

2011 119018.

Primeras 2-3 palabras del Ttulo

Resea
El modelado de procesos debe ser entendido, a saber, por dos cuestiones importantes: el
modelado y los procesos. Frecuentemente los sistemas (conjuntos de procesos y subprocesos
integrados en una organizacin) son difciles de comprender, amplios, complejos y confusos; con
mltiples puntos de contacto entre s y con un buen nmero de reas funcionales, departamentos
y puestos implicados. Un modelo puede dar la oportunidad de organizar y documentar la
informacin sobre un sistema.

Primeras 2-3 palabras del Ttulo

CONTENIDO

Primeras 2-3 palabras del Ttulo

CAPITULO I
En realidad, la elaboracin de software de computadora es un proceso reiterativo de aprendizaje
social, y el resultado, algo que Baetjer llamara capital de software, es la reunin de
conocimiento recabado, depurado y organizado a medida que se realiza el proceso. [1]

1. Un Modelo General de Proceso

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a
crearse algn producto del trabajo.

Una actividad busca lograr un objetivo amplio (por ejemplo, comunicacin con los
participantes) y se desarrolla sin importar el dominio de la aplicacin, tamao del proyecto,
complejidad del esfuerzo o grado de rigor con el que se usar la ingeniera de software. Una
accin (diseo de la arquitectura) es un conjunto de tareas que producen un producto importante
del trabajo (por ejemplo, un modelo del diseo de la arquitectura). Una tarea se centra en un
objetivo pequeo pero bien definido (por ejemplo, realizar una prueba unitaria) que produce un
resultado tangible.

En el contexto de la ingeniera de software, un proceso no es una prescripcin rgida de

cmo elaborar software de cmputo. Por el contrario, es un enfoque adaptable que permite que
las personas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado
de acciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna y
con calidad suficiente para satisfacer a quienes patrocinaron su creacin y a aquellos que lo
usarn.

Primeras 2-3 palabras del Ttulo

Ilustracin 1.
Estructura del Proceso
2. Actividad Estructural
Una estructura de proceso general para la ingeniera consta de cinco actividades:
i.

Comunicacin
Antes de que se empiece cualquier trabajo tcnico, tiene importancia crtica
comunicarse y colaborar con el cliente (y con otros participantes). Se busca
entender los objetivos de los participantes respecto del proyecto, y reunir los
requerimientos que ayuden a definir las caractersticas y funciones del software.

ii.

Planeacin

Primeras 2-3 palabras del Ttulo

Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto de

software es un viaje complicado, y la actividad de planeacin crea un "mapa" que
gua al equipo mientras viaja. El mapa (llamado plan del proyecto de software)
define el trabajo de ingeniera de software al describir las tareas tcnicas por
realizar, los riesgos probables, los recursos que se requieren, los productos del
trabajo que se obtendrn y una propagacin de las actividades.

iii.

Modelado
Si eres diseador de paisaje, constructor de puentes, ingeniero aeronutico,
carpintero o arquitecto, a diario trabajas con modelos. Se crea un "bosquejo" del
objeto por hacer a fin de entender el panorama general (cmo se ver
arquitectnicamente, cmo ajustan entre s las partes constituyentes y muchas
caractersticas ms). Si se requiere, refina el bosquejo con ms y ms detalles en un
esfuerzo por comprender mejor el problema y cmo resolverlo. Un ingeniero de
software hace lo mismo al crear modelos a fin de entender mejor los requerimientos
del software y el diseo que los satisfar.

iv.

Construccin
Esta actividad mezcla la generacin de cdigo (ya sea manual o automatizada)
y las pruebas que se requieren para descubrir errores en ste.

v.

Despliegue

Primeras 2-3 palabras del Ttulo

El software (como entidad completa o como un incremento parcialmente

terminado) se entrega al consumidor que lo evala y que le da retroalimentacin,
misma que se basa en dicha evaluacin.

Estas cinco actividades estructurales genricas se usan durante el desarrollo de programas

pequeos y sencillos, en la creacin de aplicaciones web grandes y en la ingeniera de sistemas
enormes y complejos basados en computadoras. Los detalles del proceso de software sern
distintos en cada caso, pero las actividades estructurales son las mismas.
Flujo del proceso y se describe la manera en que estn organizadas las actividades
estructurales y las acciones y tareas que ocurren dentro de cada una con respecto de la secuencia
y el tiempo.
Un flujo de proceso lineal ejecuta cada una de las cinco actividades estructurales en
secuencia, comenzando por la comunicacin y terminando con el despliegue. Un flujo de
proceso iterativo repite una o ms de las actividades antes de pasar a la siguiente. Un flujo de
proceso evolutivo realiza las actividades en forma circular. A travs de las cinco actividades,
cada circuito lleva a una versin ms completa del software. Un flujo de proceso paralelo ejecuta
una o ms actividades en paralelo con otras (por ejemplo, el modelado de un aspecto del
software tal vez se ejecute en paralelo con la construccin de otro aspecto del software).

Primeras 2-3 palabras del Ttulo

Ilustracin 2
Flujo de Proceso
Si el proyecto fuera considerablemente ms complejo, con muchos participantes y cada uno
con un distinto conjunto de requerimientos (a veces en conflicto), la actividad de comunicacin
puede tener seis acciones distintas: concepcin, indagacin, elaboracin, negociacin,
especificacin y validacin. Cada una de estas acciones de la ingeniera del software tendr
muchas tareas de trabajo y un nmero grande de diferentes productos finales.

Primeras 2-3 palabras del Ttulo

3. Patrones de proceso
Cada equipo de software se enfrenta a problemas conforme avanza en el proceso del
software.
Si se demostrara que existen soluciones fciles para dichos problemas, sera til para el
equipo abordarlos y resolverlos rpidamente. Un patrn del proceso describe un problema
relacionado con el proceso que se encuentra durante el trabajo de ingeniera de software,
identifica el ambiente en el que surge el problema y sugiere una o ms soluciones para el mismo.
Dicho de manera general, un patrn de proceso da un formato: un mtodo consistente para
describir soluciones del problema en el contexto del proceso del software.

Nombre del patrn

Propsito
Tipo
Contexto inicial
Problema
Solucion
Contexto resultante
Patrones relacionados
Usos conocidos/Ejemplos

Primeras 2-3 palabras del Ttulo

10

CAPITULO 2
1. Evaluacin y Mejora del Proceso
En las ltimas dcadas se han propuesto numerosos enfoques para la evaluacin y mejora
de un proceso del software:

i.

Mtodo de evaluacin del estndar CMMI para el proceso de mejora (SCAMPI, por
sus siglas en ingls)
La evaluacin SCAMPI determina el nivel, de madurez o capacidad, que ha
alcanzado una organizacin que aplica CMMI en sus procesos. Su objetivo
principal es determinar las fortalezas y oportunidades de mejora de los procesos de
la organizacin, respecto a las prcticas descritas en el modelo de referencia.

SCAMPI proviene de las siglas en ingls de Mtodo Estndar de Evaluacin CMMI

para mejora de procesos (Standard CMMI Appraisal Method for Process
Improvement) y existen tres clases de evaluaciones.

SCAMPI Clase A: El mtodo ms amplio, con mayor cobertura del modelo y es el

nico que puede proporcionar un nivel de madurez o perfil de capacidad. Es
liderado por un SCAMPI Lead Appraiser autorizado por el SEI.

SCAMPI Clase B: Es menos amplio y detallado que el clase A y eventualmente

ms econmico. Se utiliza como evaluacin inicial o parcial, enfocado en las reas
que requieren atencin. En este caso no requiere de un Lead Appraiser para ser
realizado.

Primeras 2-3 palabras del Ttulo

11

SCAMPI Clase C: Es el ms sencillo, econmico y requiere una capacitacin

menor. Se enfoca en reas de inters o de mayor riesgo en la organizacin.

2. Proceso de evaluacin SCAMPI

El mtodo SCAMPI se basa en un enfoque colaborativo, donde todo el equipo contribuye y
participa en alcanzar los objetivos de la evaluacin. Requiere tomar como referencia un modelo
de procesos y apegarse a reglas estrictas de confidencialidad que garanticen la obtencin de
resultados de manera objetiva y sin interferencias. El compromiso y patrocinio de la direccin en
la organizacin es fundamental para cumplimentar el proceso.
Durante el SCAMPI se evala el estado actual de las prcticas de la organizacin para
identificar fortalezas y oportunidades de mejora, as como las prioridades para las acciones de
mejora. De cierta manera se determina el grado de cumplimiento con respecto al modelo de
referencia, segn la clase de SCAMPI que se realiza.
En trminos generales se ejecuta en tres fases fundamentales:

Planificacin y preparacin para la evaluacin, donde se: analizan los requisitos, evalan
los planes de desempeo, preparacin y seleccin del equipo y obtienen y analizan las
evidencias.
Ejecucin de la evaluacin, que incluye la: preparacin de los participantes, examen,
documentacin y verificacin de la evidencia, validacin y evaluacin de los resultados.
Reporte de resultados, donde se generan los documentos de resultados y se prepara el
envo y entrega de los documentos al SEI.

Primeras 2-3 palabras del Ttulo

12

3. Evaluacin basada en CMM para la mejora del proceso interno

CMMI (Modelo de Madurez de Capacidad Integrado) pertenece a la familia de modelos
desarrollados por el SEI (Software Engineering Institute) para evaluar las capacidades de las
organizaciones de ingeniera de sistemas, ingeniera de software, adems del desarrollo
integrado del producto y del proceso.
CMMI es un modelo descriptivo que detalla los atributos esenciales que deberan
caracterizar a una organizacin en un determinado nivel de maduracin.

Ilustracin 3
Niveles de CMMI
Es un modelo normativo donde las prcticas detalladas caracterizan los tipos normales de
comportamiento esperables en una organizacin que ejecuta proyectos a gran escala. La mejora
continua de los procesos se basa en muchos pasos pequeos y evolutivos en vez de innovaciones
revolucionarias.

CMMI proporciona un marco para organizar estos pasos evolutivos dentro de cinco niveles
de maduracin que sientan fundamentos sucesivos para la mejora continua del proceso.

Primeras 2-3 palabras del Ttulo

13

4. Niveles del CMM

CMM define cinco niveles de madurez para una organizacin y proporciona un marco para
moverse a partir de un nivel al siguiente. Las guas CMM contienen actividades diseadas para
ayudar a una organizacin para mejorar sus procesos con la meta de alcanzar capacidad de
repeticin, y control de los mismos. El CMM ha ganado considerable credibilidad en las
industrias intensivas en el uso de conocimientos. La implantacin del CMM ha permitido
mejoras considerables en la calidad de los productos y bajado perceptiblemente el costo del
desarrollo dentro de grandes compaas.
Las organizaciones han probado que mejorando sus procesos de desarrollo, CMM del nivel
1 al nivel 3, puede bajar su costo por hasta 50-60%. An ms, quienes han estado en el negocio
de la productividad del desarrollo del software por aos, sostienen que la rentabilidad resultada
de mejoras en productividad y reduccin en tiempo de llegada al mercado.

Los niveles del CMM son:

1 Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el
desarrollo y mantenimiento de software. Aunque se utilicen tcnicas correctas de ingeniera, los
esfuerzos se ven minados por falta de planificacin. El xito de los proyectos se basa la mayora
de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre
retrasos y sobre costes. El resultado de los proyectos es impredecible.
2 Repetible. En este nivel las organizaciones disponen de unas prcticas
institucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un razonable

Primeras 2-3 palabras del Ttulo

14

seguimiento de la calidad. La relacin con subcontratistas y clientes est gestionada

sistemticamente.
3 Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones
disponen de correctos procedimientos de coordinacin entre grupos, formacin del personal,
tcnicas de ingeniera ms detalladas y un nivel ms avanzado de mtricas en los procesos. Se
implementan tcnicas de revisin por pares (peer reviews).
4 Gestionado. Se caracteriza por que las organizaciones disponen de un conjunto de
mtricas significativas de calidad y productividad, que se usan de modo sistemtico para la toma
de decisiones y la gestin de riesgos. El software resultante es de alta calidad.
5 Optimizado. La organizacin completa est volcada en la mejora continua de los
procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.

5. Beneficios de la implantacin del modelo CMM

Mayor efectividad en la deteccin de errores a lo largo del ciclo de vida del

desarrollo del software, reduciendo drsticamente el nmero de defectos.

Reduccin de las desviaciones en plazo de los proyectos.

Mayor tolerancia al cambio e incremento de la capacidad de adopcin y adaptacin

de nuevas Tecnologas.

Mejora en la rapidez y efectividad de respuesta ante exigencias del negocio.

Mejora en la colaboracin y comunicacin.

Mitigacin de Riesgo.

Reduccin de los costes del proyectos.

Primeras 2-3 palabras del Ttulo

15

6. SPICE (ISO/IEC 15504)

Este servicio permite instaurar una poltica de trabajo comn en el departamento de

desarrollo software de su empresa.
La norma ISO/IEC 15504 define un modelo de evaluacin de procesos. Se trata de una
estndar internacional que permite evaluar la capacidad y madurez de los procesos software de
una organizacin.
Los procesos de desarrollo software evaluados con la ISO 15504 se encuentran recogidos
en la norma ISO/IEC 12207. Esta norma contiene un conjunto de procesos que abarcan el ciclo
completo de un proyecto software, desde la definicin de un proyecto hasta la entrega y cierre
del mismo.

La certificacin se basa en 6 niveles de madurez. Cada nivel obliga a cumplir una serie de
requisitos sobre un grupo de procesos determinado. Por ejemplo, el nivel 2 de madurez
contempla 10 procesos y el nivel 3 contempla 21 procesos de ISO 12207.
Entre los principales beneficios de una implantacin de SPICE, podemos destacar los
siguientes:

Reconocimiento en el mercado, siendo un factor diferenciador ante su competencia.

Aumenta la satisfaccin de sus clientes.

Mejora interna de su empresa:

Implantacin de una metodologa comn a todas las reas.

Primeras 2-3 palabras del Ttulo

Control de todas las fases y reas de gestin de un proyecto software.

Detectar y corregir posibles fallos en cada etapa de un proyecto.

Aumento de los beneficios del proyecto.

16

En resumen, la implantacin de SPICE en su empresa le permitir abordar cualquier tipo de

proyecto software siguiendo unas directrices comunes en todos ellos.

Forma de trabajo:

El objetivo principal de Audisec para sus proyectos de implantacin es aportar valor. Por
ello, la filosofa de nuestros proyectos es la siguiente:

Enfoque prctico y didctico de los proyectos. Los procesos deben ser asimilados y
comprendidos.

No a la "consultora intrusiva": primero se analizan las necesidades de la organizacin

y despus se decide cul es la solucin que mejor puede encajar.

Los procedimientos fciles de usar se utilizan y aprovechan.

Cumplimiento con la norma.

Las fases de las que consta el proyecto de SPICE son:

Evaluacin inicial.

Desarrollo de procesos

Aplicacin de los procesos en proyectos software de su empresa.

Primeras 2-3 palabras del Ttulo

Evaluacin final.

Certificacin.

17

Recuerde tambin que podemos alinear SPICE con las Normas ISO 27001, ISO 2000, ISO
22301, ISO 9001, ISO 14001, etc.

ISO9001:2000 para software

ISO 9001:2000 es una norma internacional aceptada por innumerables organizaciones y

empresas que define los requisitos mnimos que debe cumplir un sistema de gestin de calidad
para ser certificado.
La anterior versin de la norma ISO 9000 de 1994 se compona de una serie de tres normas
cuyos cdigos eran ISO 9001:94, ISO 9002:94 y ISO 9003:94, destinadas a empresas
industriales que, respectivamente, contemplasen la totalidad de operaciones, incluidas las de
diseo, que solamente tuviesen en cuenta la fabricacin, o que basasen su sistema de calidad
nicamente en el anlisis y los ensayos finales de sus productos.

Por lo tanto, si una organizacin desea certificar su sistema de gestin de calidad, dicho
sistema deber estar redactado de acuerdo con lo que se seala la norma ISO 9001:2000,
enfatizando que se debe documentar bajo una justificacin slida la exclusin de cualquier
requerimiento de la normativa que no aplique a la empresa (las cuales pueden ser actividades de
diseo, instalacin, servicio posventa, producto proporcionado por el cliente, etc.).

Primeras 2-3 palabras del Ttulo

18

En la versin 2000, se hace hincapi en que no se pretende que las organizaciones estn
obligadas a cambiar la estructura de su sistema de gestin de calidad o su documentacin para as
alinearse con la estructura de la norma ISO 9001:2000. La documentacin del sistema de gestin
de calidad de la organizacin debe ser adecuada de la manera que sea apropiada a sus
actividades, mientras an cubra los requisitos de ste estndar internacional.

Segn su definicin, la norma ISO 9001:2000 especifica los requisitos para los sistemas de
gestin de la calidad aplicables a toda organizacin que necesite demostrar su capacidad para
proporcionar productos que cumplan los requisitos de sus clientes y los reglamentarios que le
sean de aplicacin, y su objetivo es aumentar la satisfaccin del cliente.
La norma ISO 9001:2000 define producto como resultado de un proceso, por lo que
lgicamente sera aplicable, tanto a organizaciones que se identifiquen con empresas industriales,
como a las que presten solamente servicios, tanto si se trata de entidades lucrativas como no
lucrativas.
ISO 9001:2000 busca garantizar la eficacia de la organizacin, no su eficiencia. Sin
embargo, para mejorar la eficiencia de la organizacin puede utilizarse, adicionalmente a ISO
9001:2000, la norma ISO 9004:2000, aunque solo la 9001 es certificable.
Las principales mejoras de la nueva versin del 2000 frente a la versin de 1994 son, entre
otras, las siguientes:

Es aplicable a cualquier tipo de producto o servicio, en todos los sectores y a

organizaciones de cualquier tamao.
Se reduce significativamente la cantidad de documentacin necesaria.

Primeras 2-3 palabras del Ttulo

19

Relaciona el sistema de gestin de calidad con los procesos de la organizacin.

Mayor orientacin a la mejora continua y a la satisfaccin del cliente.
Compatibilidad con otras normas como la norma medioambiental ISO 14000.
El concepto del par consistente de ISO 9001 (que cubre los requisitos) e ISO 9004 (que
proporciona una gua para una mejora adicional del desempeo de la organizacin).
Se consideran las necesidades y beneficios de todas las partes interesadas.

CAPITULO III
1. Modelos Prescriptivos del Proceso
Los modelos prescriptivos de software fueron ideados originalmente para ordenar el caos
del desarrollo de software, y la historia nos muestro que el uso de estos han trado tanto un
camino a seguir en el desarrollo de software as como estructuras tiles. aunque el trabajo de
ingeniera de software y el producto resultante siguen estando en un punto entre el orden y el
caos lo cual indica que no se esta en la estructura completa y que puede haber cierta dosis de
creatividad en el desarrollo de software y no se esta en la desorganizacin total de manera que
puede seguirse un camino predecible para el proyecto.

Los modelos prescriptivos de software nos definen un conjunto de tareas, actividades,

productos de trabajo que se requieren para desarrollar productos de calidad que son importantes
para llevar control, estabilidad y organizacin a una actividad que tiende a ser catica, el modelo
prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la

Primeras 2-3 palabras del Ttulo

20

ingeniera de software. Se debe considerar que aun que un proceso sea prescriptivo esto no se
debe asumir como esttico, estos se deben adaptar al personal, al proyecto y al problema.

Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de
proceso asi como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabjo estandar
pero cada uno aplica diferencias a cada una de las actividades y a su flujo de trabajo.

i.

El Modelo Cascada O Ciclo Clsico

Existen ocasiones en las cuales los requisitos de un sistemas se identifican de manera

razonable y estos fluyen de la comunicacin al despliegue de manera casi lineal. Esto

se da cuando se debe hacer adaptaciones o mejoras a un sistema existente por ejemplo
al agregar nuevas regulaciones gubernamentales a un programa existente, puede
utilizarse tambin en proyectos nuevos pero nicamente cuando los requisitos estn
bien definidos y son estables en forma razonable.
Las actividades seguidas por este son las siguientes

Ilustracin 4
El modelo Cascada
El modelo cascada es el paradigma ms antiguo en la ingeniera de software pero al
utilizar este paradigma se han observado lo siguiente.

Primeras 2-3 palabras del Ttulo

21

1. Es muy raro que los problemas reales sigan el flujo lineal secuencial propuesto.

2. Es muy difcil para el cliente establecer todos los requisitos de manera explicita el
modelo cascada lo requiere y enfrenta problemas al proponer cambios.

3. El cliente debe tener paciencia.

En general hoy en da al ser un mundo acelerado y cambiante enfrentamos muchos
problemas al utilizar este paradigma ya que puede provocar estados de bloqueos en los
que no se pueden terminar algunas tareas hasta que otras se hayan concluido, pero de
igual forma pueden presentarse proyectos en los cuales este definido todo de manera
clara y no se tengan cambios para los cuales este modelo puede ser el ideal.

ii.

Modelos de Procesos Incrementales

En muchas ocasiones encontramos proyectos con requisitos bien definidos

razonables pero la propia naturaleza del proyecto nos impide usar un enfoque
puramente lineal, por ejemplo se necesita tener un conjunto limitado de funcionalidad
para luego refinarla y expandirla y esto nos conduce a modelo incremental el cual
combina elementos del modelo en cascada en forma iterativa.

El modelo incremental entrega una serie de lanzamientos llamados incrementos que

proporcionan en forma progresiva ms funcionalidad para los clientes a medida que se
entrega cada uno de los incrementos.

Primeras 2-3 palabras del Ttulo

22

Al utilizar el modelo incremental la primer entrega es un producto esencial que

incluye los requisitos bsicos, los detalles tanto conocidos como no conocidos pueden
incluirse en lanzamientos posteriores, esta primera entrega puede ser evaluado por el
cliente para incluir nueva funcionalidad. Este proceso debe ser repetitivo hasta no
tener un producto final.

El modelo incremental al igual que el modelo de prototipos es por naturaleza

iterativo la gran diferencia entre ambos es que se debe hacer una entrega funcional en
el caso del modelo incremental.

Si el cliente propone una fecha de entrega imposible es conveniente sugerir la

entrega de uno o ms incrementos para dicha fecha de modo que se pueda tener un
producto parcial bsico a las necesidades del cliente para ese momento y entregar el
resto de incrementos adicionales luego.

Ilustracin 5
Modelo de Proceso Incremental

Primeras 2-3 palabras del Ttulo

iii.

23

Modelos Evolutivos

Los modelos evolutivos producen una versin completa en forma incremental en

cada iteracin. y permiten crear versiones mas completas del software en cada
iteracin. y son utilices cuando se tienen requisitos bsicos establecidos pero se deben
definir detalles sobre la extencion del producto o sistema.

2. Construccin de Prototipo
El cliente describe un conjunto de objetivos generales del software pero no identifica los
requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la
efectividad del software.
si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo
no sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y
puede mezclarse con cualquier otro mtodo.

Ilustracin 6
El paradigma de hacer prototipos

Primeras 2-3 palabras del Ttulo

24

El paradigma de construccin de prototipos se inicia con la comunicacin el ingeniero de

software y el cliente encuentran y definen los requisitos bsicos y conocidos, entonces se plantea
con rapidez una iteracin de construccin de prototipos y se presenta un diseo rpido y este se
centra en aspectos visibles al cliente y al usuario final, se construye el prototipo y este se somete
a una evaluacin por parte del cliente/usuario para y con la retroalimentacin producida se
reajustan los requisitos del software que se desarrollara. De tal forma que el prototipo sirve como
un mecanismo para identificar los requisitos del software.
Es recomendable idealmente desechar un prototipo y debe resistirse la presin de
entregarlo como un producto ya que la calidad se ver diezmada y por lo tanto debe de definirse
las reglas del juego con el cliente indicndosele que el prototipo sirve para tomar requisitos y
ajustarlos y luego debe desecharse al menos en parte para luego desarrollar un software de alta
calidad.

3. El Modelo Espiral
El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa
de la construccin de prototipos con los aspectos controlados y sistemticos del modelo cascada,
el modelo cascada se puede adaptar y aplicar a travs del ciclo de vida completo de una
aplicacin desde el desarrollo del concepto hasta el mantenimiento.

Cuando se aplica el modelo espiral se desarrolla una serie de entregas evolutivas iniciando
desde posiblemente documentacin y prototipos, hasta llegar versiones cada ves mejores del
sistema.

Primeras 2-3 palabras del Ttulo

25

Ilustracin 7
Modelo Espiral Comn
El desarrollo espiral es un enfoque realista para el desarrollo de sistemas a gran escala.
Como el software evoluciona el desarrollador y el cliente adquieren mayor experiencia y
reaccionan mejor ante riesgos en cada etapa. si se aplica en forma apropiada el se deben reducir
riesgos antes que estos sean un problema.

entre los problemas de este modelo podemos ver que es dificil convencer al cliente que el
enfoque evolutivo es controlable, si un riesgo importante no se descubre y administra surgirn
problemas.

4. Modelo de Desarrollo Concurrente

El modelo de procesos concurrentes define una serie de eventos que se disparan
transiciones de estado a estado para cada una de las actividades, acciones, o tareas de ingeniera
de software.

Primeras 2-3 palabras del Ttulo

26

Se aplica a todos los tipos de desarrollo de software y proporciona una visin exacta del
estado del proyecto es apropiado cuando se encuentran involucrados varios equipos de
ingeniera.
Un ejemplo de una actividad concurrente es el siguiente

Ilustracin 8
Un ejemplo de proceso concurrente
El software de computadora modero es cambiante y los tiempos de entrega reducidos y es
importante si se pierde tiempo el mismo software puede perder significado y los procesos
evolutivos pueden ayudarnos, los problemas de estos pueden ser que no sabemos cuntas
iteraciones necesitamos para construir un producto y las tcnicas de estimacin se basan en
mtodos lineales los cuales no se ajustan, no se establece la velocidad mxima de evolucin.

5. Modelos de Procesos Especializados

Primeras 2-3 palabras del Ttulo

27

Los modelos de proceso especializado tienen muchas de las caractersticas de uno o ms de

los modelos tradicionales que se representaron en las secciones anteriores. Sin embargo, dichos
modelos tienden a aplicarse cuando se elige un enfoque de ingeniera de software especializado o
definido muy especialmente.

i.

Desarrollo Basado En Componentes

Incorpora muchas de las caractersticas del modelo espiral es evolutivo por
naturaleza. el modelo configura aplicaciones a partir de software empaquetado en
forma previa.
El modelado y construccin inician por identificar los componentes candidatos
estos pueden ser diseados como mdulos de software convencionales o como
clases o paquetes de clases orientados a objetos.

ii.

Modelo de Mtodos Formales

Comprende un conjunto de actividades que conducen a la especificacin
matemtica del software de computadora y proporcionan un mecanismo para
eliminar problemas difciles a travs de un anlisis matemtico.

el problema principal es el tiempo y los recursos que consume son grandes, no

hay gente suficiente capacitada para aplicar estos mtodos y es muy difcil
comunicarse con el cliente por medio de las notaciones especficas.

iii.

Desarrollo de Software Orientado a Aspectos

Primeras 2-3 palabras del Ttulo

28

Es un paradigma de ingeniera de software que proporciona un proceso y

enfoque metodolgico para definir, especificar, disear y construir aspectos.
mecanismos mas alla de subrutinas y legados para localizar la expresin del
inters general es posible que el proceso adopte caractersticas del proceso espiral
y concurrente .

Primeras 2-3 palabras del Ttulo

29

Los subttulos tienen formato en cursiva y estn alineados a la izquierda.

Citas
El material de referencia se debe documentar en el texto principal del artculo, citando a los
autores y fechas de las referencias. La cita completa de la referencia aparecer en la lista de
referencias que sigue al texto principal del artculo. Cuando los nombres de los autores de una
referencia son parte de la estructura formal de la oracin, el ao de publicacin aparece entre
parntesis a continuacin de la identificacin de los autores, por ejemplo: Smith (2001). Cuando
los autores de una referencia no son parte de la estructura formal de la oracin, tanto los autores
como los aos de publicacin aparecen entre parntesis, separados por punto y coma, por
ejemplo: (Smith and Jones, 2001; Anderson, Charles, & Johnson, 2003). Cuando se cita una
referencia que tiene tres, cuatro o cinco autores, todos los autores se incluyen la primera vez que
se cita la referencia. Cuando sta se vuelve a citar, se usa el apellido del primer autor seguido de
"et al.". Consulte el ejemplo en el prrafo siguiente.

Primeras 2-3 palabras del Ttulo

30

El uso de este estilo APA estndar causar una impresin favorable en su instructor"
(Smith, 2001). Esto fue nuevamente confirmado en el ao 2003 por el profesor Anderson
(Anderson, Charles & Johnson, 2003).
Cuando se cita una referencia que tiene dos autores, ambos autores se citan siempre. Si hay
seis o ms autores para citar, se usa el apellido del primer autor seguido de et al. la primera vez
que se cita y todas las veces subsiguientes. Cuando se usa una cita directa, siempre se debe
incluir el autor, ao y nmero de pgina como parte de la cita. Una cita con menos de 40
palabras se debe encerrar entre comillas e incorporarse a la estructura formal de la oracin. Una
cita con ms de 40 palabras debe aparecer (sin comillas) en formato de bloque con sangra de
cinco espacios a partir del margen izquierdo en cada lnea.1

Primeras 2-3 palabras del Ttulo

31

Referencias
[1] Ingeniera del Software, un enfoque prctico, sptima edicin por Roger S. Pressman pgina
26
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]

Anderson, Charles & Johnson (2003). The impressive psychology paper. Chicago: Lucerne
Publishing.
Smith, M. (2001). Writing a successful paper. The Trey Research Monthly, 53, 149-150.
Las entradas se organizan alfabticamente por apellidos de los primeros autores y
contienen un formato con sangra francesa. La mayora de las entradas de referencia tienen tres
componentes:

Primeras 2-3 palabras del Ttulo

1. Autores: los autores se indican en el mismo orden especificado en la referencia,
mediante apellidos e iniciales. Todos los autores se separan con comas. Cuando haya
siete autores o ms, indicar los primeros seis y, a continuacin, usar "et al." para el
resto. Si no hay autores identificados, la referencia comienza con el ttulo del
documento.
2. Ao de publicacin: entre parntesis, a continuacin de los autores, con un punto
siguiente al parntesis de cierre. Si no se identifica una fecha de publicacin, usar s.
d. entre parntesis a continuacin de los autores.
3. Bibliografa: incluye ttulo, diario, volumen, pginas (para el artculo de un diario) o
ttulo, ciudad de publicacin, editor (para un libro).

32

Primeras 2-3 palabras del Ttulo

Apndice
Cada apndice aparece en su propia pgina.

33

Primeras 2-3 palabras del Ttulo

34

Notas al pie
1

La informacin completa del formato de estilos de APA se puede encontrar en el Manual

de publicacin.

Primeras 2-3 palabras del Ttulo

Tabla 1
Escribir aqu en cursiva el texto de la tabla; para cada tabla, comenzar una nueva pgina
[Insertar tabla aqu]

35

Primeras 2-3 palabras del Ttulo

Ttulos de ilustraciones
Figura 1. Ttulo de ilustracin

36

[Ilustraciones tener en cuenta que esta pgina no contiene el encabezado del manuscrito ni
el nmero de pgina]