En la actualidad, la utilización de metodologías para el desarrollo de aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la ordenada elaboración de las aplicaciones, por lo tanto, seguir metodologías y estándares nos llevan a estar en competitividad en todo momento.

1. Escuela Profesional : Ingeniería
Carrera Profesional : Ingeniería de Sistemas
Curso : Ingenieria de Software II
Tema : Las metodologías usadas en el
Desarrollo de SW en el Perú.
Ciclo académico : 2013 - II
Centro ULADECH Católica : Huaraz
Docente Titular : Ing. Ancajima Miñán Victor Angel
Docente Tutor : Ing. Mendoza Corpus Carlos
Estudiante :
2013

2. INTRODUCCION
En la actualidad, la utilización de metodologías para el desarrollo de aplicaciones es casi
imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo
desarrollo, y para la ordenada elaboración de las aplicaciones, por lo tanto, seguir
metodologías y estándares nos llevan a estar en competitividad en todo momento.
Es de suma importancia conocer el modo como se interrelacionan metodologías con
estándares y herramientas siguiendo un único propósito, el cual consiste en la elaboración de
aplicaciones de manera eficiente, ordenada y con el menor número de defectos.
El modelo SPICE describe los procesos que una organización puede realizar para comprar,
suministrar, desarrollar, operar, mantener y soportar el software, así como los atributos que
caracterizan la capacidad de estos procesos.

3. LAS METODOLOGÍAS USADAS EN EL DESARROLLO DE SW EN EL PERÚ
Todos en algún momento nos hemos hecho esta pregunta, cuando hemos tenido que
desarrollar un software. Y de hecho esta pregunta se torna muy importante, pues como
arquitectos de Software, debemos tener un plano en que apoyarnos.
Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una
metodología de por medio, lo que obtenemos es clientes insatisfechos con el resultado y
desarrolladores aún más insatisfechos.
Sin embargo, muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre
todo cuando se trata de proyectos pequeños de dos o tres meses. Lo que se hace con este tipo
de proyectos es separar rápidamente el aplicativo en procesos, cada proceso en funciones, y
por cada función determinar un tiempo aproximado de desarrollo.
Cuando los proyectos que se van a desarrollar son de mayor envergadura, ahí si toma sentido
el basarnos en una metodología de desarrollo, y empezamos a buscar cual sería la más
apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la más adecuada
y terminamos por hacer o diseñar nuestra propia metodología, algo que por supuesto no esta
mal, siempre y cuando cumpla con el objetivo.
Muchas veces realizamos el diseño de nuestro software de manera rígida, con los
requerimientos que el cliente nos solicitó, de tal manera que cuando el cliente en la etapa
final (etapa de prueba), solicita un cambio se nos hace muy difícil realizarlo, pues si lo
hacemos, altera muchas cosas que no habíamos previsto, y es justo éste, uno de los factores
que ocasiona un atraso en el proyecto y por tanto la incomodidad del desarrollador por no
cumplir con el cambio solicitado y el malestar por parte del cliente por no tomar en cuenta
su pedido. Obviamente para evitar estos incidentes debemos haber llegado a un acuerdo
formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o modificación
no perjudique al desarrollo del mismo.
Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de
mencionar, recién en la etapa final del proyecto, pese a que se les mostró un prototipo del
software en la etapa inicial del proyecto.
Los proyectos en problemas son los que salen del presupuesto, tienen importantes retrasos, o
simplemente no cumplen con las expectativas del cliente.
Para dar una idea de qué metodología podemos utilizar y cual se adapta más a nuestro medio,
mencionaré tres de ellas de las que considero las más importantes, tal como: RUP, XP y MSF.
RATIONAL UNIFIED PROCESS (RUP)
La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide
en 4 fases el desarrollo del software:
1. INICIO, El Objetivo en esta etapa es determinar la visión del proyecto.
2. ELABORACIÓN, En esta etapa el objetivo es determinar la arquitectura óptima.

4. 3. CONSTRUCCIÓN, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
4. TRANSMISIÓN, El objetivo es llegar a obtener el release del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos
disciplinas:
✓ Disciplina de Desarrollo
✓ Ingeniería de Negocios: Entendiendo las necesidades del negocio.
✓ Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
✓ Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de
software.
✓ Implementación: Creando software que se ajuste a la arquitectura y que tenga el
comportamiento deseado.
✓ Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo el
solicitado está presente.
DISCIPLINA DE SOPORTE
✓ Configuración y administración del cambio: Guardando todas las versiones del
proyecto.
✓ Administrando el proyecto: Administrando horarios y recursos.
✓ Ambiente: Administrando el ambiente de desarrollo.
✓ Distribución: Hacer todo lo necesario para la salida del proyecto
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su
prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como
beneficio la retroalimentación que se tendría en cada entregable o en cada iteración.
Los elementos del RUP son:
✓ ACTIVIDADES, Son los procesos que se llegan a determinar en cada iteración.
✓ TRABAJADORES, Vienen hacer las personas o entes involucrados en cada proceso.
✓ ARTEFACTOS, Un artefacto puede ser un documento, un modelo, o un elemento
de modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente
el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para
alcanzar un grado de certificación en el desarrollo del software.

5. EXTREME PROGRAMING (XP)
Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas
para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología
consiste en una programación rápida o extrema, cuya particularidad es tener como parte del
equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.
CARACTERÍSTICAS DE XP, LA METODOLOGÍA SE BASA EN:
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera
que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran
ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
REFABRICACIÓN: se basa en la reutilización de código, para lo cual se crean patrones o
modelos estándares, siendo más flexible al cambio.
Programación en pares: una particularidad de esta metodología es que propone la
programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto
en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está
haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro
consulta el mapa.

6. ¿QUÉ ES LO QUE PROPONE XP?
✓ Empieza en pequeño y añade funcionalidad con retroalimentación continua
✓ El manejo del cambio se convierte en parte sustantiva del proceso
✓ El costo del cambio no depende de la fase o etapa
✓ No introduce funcionalidades antes que sean necesarias
✓ El cliente o el usuario se convierte en miembro del equipo
DERECHOS DEL CLIENTE
✓ Decidir que se implementa
✓ Saber el estado real y el progreso del proyecto
✓ Añadir, cambiar o quitar requerimientos en cualquier momento
✓ Obtener lo máximo de cada semana de trabajo
✓ Obtener un sistema funcionando cada 3 o 4 meses
✓ DERECHOS DEL DESARROLLADOR
✓ Decidir como se implementan los procesos
✓ Crear el sistema con la mejor calidad posible
✓ Pedir al cliente en cualquier momento aclaraciones de los requerimientos
✓ Estimar el esfuerzo para implementar el sistema
✓ Cambiar los requerimientos en base a nuevos descubrimientos
LO FUNDAMENTAL EN ESTE TIPO DE METODOLOGÍA ES:
✓ La comunicación, entre los usuarios y los desarrolladores
✓ La simplicidad, al desarrollar y codificar los módulos del sistema
✓ La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los
usuarios finales

7. MICROSOFT SOLUTION FRAMEWORK (MSF)
Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y
prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos
tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo
plano las elecciones tecnológicas.
TIENE LAS SIGUIENTES CARACTERÍSTICAS:
ADAPTABLE: Es parecido a un compás, usado en cualquier parte como un mapa, del cual
su uso es limitado a un específico lugar.
ESCALABLE: Puede organizar equipos tan pequeños entre 3 o 4 personas, así como
también, proyectos que requieren 50 personas a más.
FLEXIBLE: Es utilizada en el ambiente de desarrollo de cualquier cliente.
TECNOLOGÍA AGNÓSTICA: porque puede ser usada para desarrollar soluciones
basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas
en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo,
Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y
finalmente el modelo de Aplicación.
Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de
vida. Este modelo define las pautas para construir proyectos empresariales a través del
lanzamiento de versiones.
MODELO DE EQUIPO: Este modelo ha sido diseñado para mejorar el rendimiento del
equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un
proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas
disponibles.
MODELO DE PROCESO: Diseñado para mejorar el control del proyecto, minimizando el
riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de
pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la
liberación de versiones y explicando su relación con el Modelo de equipo.
MODELO DE GESTIÓN DEL RIESGO: Diseñado para ayudar al equipo a identificar las
prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que
puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones
y acciones valorando los riesgos que puedan provocar.

8. MODELO DE DISEÑO DEL PROCESO: Diseñado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario
para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de
diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de
roles: los usuarios, el equipo y los desarrolladores.
MODELO DE APLICACIÓN: Diseñado para mejorar el desarrollo, el mantenimiento y el
soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones
software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un
solo ordenador o incluso en varios servidores.
LAS EMPRESAS DESARROLLADORES DE SW EN EL PERÚ Y LA FORMA DE
GESTIONAR SUS PROYECTOS
Las empresas que sobrevivan en el mercado del siglo XXI deben implementar el software
como un elemento que permita generar estrategias de diferenciación en sus procesos de
negocio. Con el objetivo de ser más competitivos, algunas organizaciones del software están
implantando la dirección disciplinada de los procesos usados para el desarrollo y
mantenimiento del software. A través de la mejora de sus procesos, estas organizaciones han
estado obteniendo la mejora necesaria de la calidad de sus productos y resultados buenos en

9. sus negocios. Una de las mayores dificultades con las que se enfrentan aquellos que
comienzan y trabajan en proyectos IT es la gran diversidad de conceptos que resulta
necesario incorporar para adentrarse en el tema y el hecho de que coexisten a su vez un gran
número propuestas. Este libro permite implementar en una organización una estrategia
global de desarrollo de proyectos de IT enfocada a los paradigmas necesarios, gestión del
recurso humano, métricas, SQA, medición y estimación de costos. Este libro se presenta en
forma clara y concreta los elementos necesarios para llevar a una organización a un nivel
superior sus procesos de software. Sin duda permitirá a los interesados en la ingeniería de
software aumentar en bases sólidas los conocimientos sobre las técnicas y metodologías
necesarias para tener éxito en sus proyectos IT.
El avance tecnológico diariamente remece a la sociedad, ya que este implica un cambio
fundamental en la manera de operar en todo orden de actividades dentro de la organización,
ya sea en el área estratégica u operacional. Hoy en día importa que el crecimiento del mercado
sea mayor que la disminución de los precios
El desafío está en cómo ser competitivo en un mundo en el cual la tecnología es virtualmente
gratis. Es necesario hacer una nueva definición de los valores económicos. El valor hoy en
día está en establecer una relación de largo plazo con el cliente, aún cuando esto signifique
esfuerzos por parte de la empresa, como por ejemplo: regalar la primera generación de
productos.
Para la definición de proyectos informáticos se ha hecho un esfuerzo en identificar y
estandarizar las etapas que lo conforman. Basándose en metodologías bien definidas, se han
desarrollado herramientas computacionales que permiten asistir su gestión en forma
automatizada.
En el Estudio Sectorial de Software de la entidad promotora, se detalla que el 63% de
empresas son micro, 27% pequeñas, 6% medianas y 4% grandes.
El documento señala que el sector cuenta con una industria con 17 años de existencia, con
más de 300 empresas debidamente formalizadas y con 30,000 programadores de sistemas.
Asimismo, genera 8,000 puestos de trabajo directo altamente calificado y 12,000 indirectos
(venta de computadoras, instalaciones, cableado, etc.).
Cabe señalar que la oferta peruana de sector está conformada por software genérico,
consultoría informática, desarrollo a medida, software específico, servicios de Internet, e-
business, servicios outsourcing, integrador de sistemas, mantenimiento y soporte de equipo.
Los indicadores económicos que viene registrando el Perú en los últimos años abren una serie
de posibilidades para la exportación de servicios, principalmente para el software.
Aquí algunas empresa en desarrollo de software:
ABI SISTEMAS: Pagina web: http://www.abi.s5.com
ADEYSNET: Pagina web: http://www.adesynet.com

10. APESOFT : Pagina web: http://www.apesoft.org
APOLLO SYSTEMS S.A.C. : Pagina web: http://www.apollosystemsperu.com
APV EBUSINESS SAC : Pagina web: http://www.orgempres.com/
BITOOL.COM: Pagina web: http://www.bitool.com
BLACKSA : Pagina web: http://www.blacksa.com
LOS ELEMENTOS QUE SE TOMAN AL REALIZAR UN PROYECTO
Según la definición de proyectos, es posible representarlo en el eje del tiempo con la duración
requerida para lograr el objetivo establecido, comenzando en un instante hasta finalizar en el
momento T, donde el período T representa la duración esperada del proyecto. Al definir un
proyecto es necesario tener claridad sobre los puntos que se definen a continuación:
✓ CLIENTE: Persona a quien va dirigido el resultado del proyecto, generalmente ellos
presentan un problema que requiere solución.
✓ USUARIOS: Persona que utilizará el sistema o parte de él.
✓ Inicio: Momento en que es expresada la necesidad específica en el cliente.
✓ TÉRMINO: Momento en que se cumple el resultado definido tanto en costo,
oportunidad, calidad o desempeño técnico.
✓ COSTO: Recurso o insumo entrante al proyecto, expresado generalmente en dinero.
✓ TIEMPO: Recurso que origina una secuencia y luego un programa, es transformable
en costo. Se incorpora al proyecto en dos dimensiones: la duración del esfuerzo y el
momento en que éste se realiza.
✓ DESEMPEÑO TÉCNICO: Característica de los resultados expresados a través de
un prototipo, gráfico, índices y funcionamiento fiable en términos de los objetivos
intermedios y del objetivo final.
✓ JEFE DEL PROYECTO: Persona responsable del proyecto. Encargado de la
dirección del proyecto, su planificación y el control de todos los costos, recursos,
programas y de la satisfacción del cliente.
LA GESTIÓN DE PROYECTOS EN EL PERU
La gestión de proyectos es un proceso continuo. Este proceso requiere de una estrategia
global, apoyada por herramientas de trabajo que incrementen la productividad. El propósito
de planificar y controlar es proveer una propuesta uniforme para el desarrollo y la
administración de los proyectos. Los planes deben apoyar los niveles estratégicos, tácticos
y operacionales de las organizaciones con el fin de alcanzar las metas corporativas de largo,
mediano y corto plazo.
A través del ciclo de vida de un proyecto, se conforman dos categorías de actividades a
realizar y que se encuentran directamente relacionadas: las actividades de gestión y las
actividades de desarrollo del sistema. Las actividades de gestión son aquellas relacionadas
con la administración de las organizaciones, personas, sistemas y procedimientos
comprometidos en el proceso de planificación y construcción del sistema. La planificación

11. del proyecto, junto con las actividades de control, es iterada para cada fase del proyecto y
proveen de la estrategia de administración con la cual las actividades de desarrollo del
sistema son estimadas, programadas y ejecutadas.
Las actividades de desarrollo del sistema se centran en el desarrollo mismo. Las metodologías
de desarrollo están típicamente organizadas en distintas fases, agrupadas en áreas funcionales
de estudio, diseño y construcción, basadas en una estructura de partición del trabajo. La
administración y planificación de proyectos requiere de la integración de dos modelos
implícitos de trabajo, usualmente no reconocidos: el modelo de administración y el modelo
de desarrollo.
MODELO DE CALIDAD SPICE (Software Process Improvement Capability
dEtermination)

12. CARACTERISTICAS DEL MODELO DE CALIDAD SPICE
✓ Marco de referencia para determinar las fortalezas y debilidades de los procesos. Es
aplicable a cualquier organización o empresa que quiera mejorar la capacidad de
cualquiera de sus procesos de software. El modelo de referencia de SPICE describe
los procesos que una organización puede realizar para comprar, suministrar,
desarrollar, operar, mantener y soportar el software, así como los atributos que
caracterizan la capacidad de estos procesos.
✓ Marco de referencia para los que adquieren un sistema para evaluar la capacidad de
los proveedores de sistemas y determinar los riesgos de negocio para una empresa
que considera desarrollar un nuevo producto de software o servicio.
PROPÓSITO
✓ Estándar de evaluación de procesos de software para:
✓ Mejora continua
✓ Evaluación de la capacidad
✓ Como base para el comercio internacional de software
ALCANCE
Ejecutar, planificar, gestionar, controlar y mejorar los procesos de:
✓ Adquisición
✓ Suministro
✓ Desarrollo
✓ Operación
✓ Soporte
✓ Evaluación y mejora de procesos software.
✓ Inicio del proyecto 1.993

13. ABARCA:
✓ Evaluación de procesos
✓ Mejora de procesos.
✓ La calidad del todos los componentes integrados en el proceso de desarrollo del
software NO mejora necesariamente por el simple hecho de adoptar un estándar
✓ Es necesario que el proceso de adopción conlleve una gestión del cambio adecuada.
✓ Es necesario tener un estándar como objetivo y referencia del proceso de desarrollo
del software.
✓ El modelo seleccionado no es tan importante como el compromiso de mejora
✓ Determinación de capacidad.
✓ Contiene los procesos que se han de evaluar. Se corresponden con los procesos del
ciclo de vida del software, definidos al estándar ISO 12207:1995. Se agrupan en
categorías, en función del tipo de actividad al cual se aplican:
o CUS: Cliente-Proveedor.
o ENG: Ingeniería.
o SUP: Soporte.
o MAN: Gestión.
o ORG: Organización
CATEGORIAS:
✓ Procesos cliente- proveedor: Esta categoría consiste en los procesos que directamente
impactan al cliente, al soporte de desarrollo y a la transición del software al cliente:
o Adquisición
o Suministro
✓ Procesos de ingeniería: Esta categoría consiste, a los procesos que directamente
especifican, implementa, y mantienen un sistema, un producto de software y la
documentación del usuario.
✓ Procesos de Operación: Esta categoría consiste en los procesos establecidos dentro
del proyecto, coordinación y administración de los recursos para producir un producto
o proveer un servicio para satisfacer al cliente.
✓ Procesos de soporte: Esta categoría consiste en los procedimientos que establecen y
soportan el desempeño de los otros procesos del proyecto.
o Mejora de Procesos
o Recursos e Infraestructura
✓ Procesos de Administración: Esta categoría consiste en los procesos que establecen
las metas de negocio de la organización, los procesos de desarrollo y recursos que
ayudan a la organización alcanzar dichas metas.
o Procesos de Reutilización

14. ARQUITECTURA MODELO DE CALIDAD SPICE
La arquitectura se basa en: Prácticas base: Son las actividades esenciales de un proceso
especifico, agrupado por categorías de procedimientos y procesos de acuerdo al tipo de
actividad que direccionan.
Prácticas genéricas: Aplicables a cualquier proceso, que representa las actividades
necesarias para administrar el "proceso" y mejorar su potencialidad.

15. CONCLUSIONES
Lo más importante antes de elegir la metodología que usarás para la implementación de tu
software, es determinar el alcance que tendrá y luego de ahí ver cuál es la que más se acomoda
en tu aplicación
La calidad del todos los componentes integrados en el proceso de desarrollo del software NO
mejora necesariamente por el simple hecho de adoptar un estándar
Es necesario que el proceso de adopción conlleve una gestión del cambio adecuada
Es necesario tener un estándar como objetivo y referencia del proceso de desarrollo del
software
El modelo seleccionado no es tan importante como el compromiso de mejora de los procesos
dentro de una organización.
Se puede reducir el tiempo de desarrollo de un Sistema de Software, aplicando la
metodología RUP y UML ya que permite lograr de una manera fiable y rápida el desarrollo
del Sistema deseado.
Colocando componentes en los distintos servidores que conformen el sistema a desarrollar,
se cuenta de una manera automática con todos los servicios prestados por dichos
componentes, es decir, se ponen a disposición de los desarrollador es un gran número de
herramientas que se pueden aprovechar en la realización del Sistema de Software de una
manera mucho más eficaz.
El tener todo el procedimiento de desarrollo de un Sistema de Software, es una herramienta
necesaria y efectiva para administrarlo; y así contar con una visión unificada de todo el
proceso, con lo que se facilita la implementación del mismo.

16. BIBLIOGRAFIA
Software UFPS Blog
http://software-ufps.blogspot.com/2011/07/modelo-de-calidad-spice.html
Pagin web Persona JFernandez
http://www.uv.mx/personal/jfernandez/files/2010/07/8_Calidad.pdf
Peru Services Ummit
http://www.peruservicesummit.com/principal/noticias/noticia/4/en-el-peru-90-de-empresas-
desarrolladoras-de-software-son-micro-y-pequenas
Radio RPP
http://www.rpp.com.pe/2011-08-09-el-90-de-empresas-desarrolladoras-de-software-son-
micro-y-pequenas-noticia_392626.html
Informatizate
http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_07062004
.html
Wikipedia
http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_el_desarrollo_de_
software