desarrollo de sw

5/26/2018 Desarrollo de Sw

1/11

SOFTENG Agile

Con el objetivo de minimizar riesgos, gestionar cambios de forma eficaz, y ofrecer un servicio de

calidad que cumpla con las expectativas de nuestros clientes, SOFTENG utiliza un probado marco

metodolgico orientado a procesos. Mediante el mismo, conseguimos alinear a todos los partcipes

del proyecto hacia un objetivo comn y claramente definido, por lo que su ejecucin se realiza

segn los plazos y costes previstos.

Las fases en las que dividimos un proyecto son las siguientes:

Estudio estratgico

Se establece las bases y el alcance del proyecto, as como los recursos necesarios, timing y costes.

Trabajamos para comprender el valor que quiere obtener y/o proporcionar a sus clientes, y le

ayudamos a descubrir nuevas oportunidades para incrementarlo.

Diseo y ar quitectura

Consiste en clarificar los objetivos delroyecto, plantear la estrategia ms

adecuada para el desarrollo del mismo,

as como describir la funcionalidad a

implementar definiendo su alcance.Etapas:

Anlisis funcional :Definicin de los

objetivos a alcanzar, y descripcin

modular detallada de los

requerimientos del proyecto.

Anlisis tecnolgico:Seleccin de la

tecnologa a aplicar, arquitectura,

diagrama de objetos, modelo

conceptual y lgico de la BD, y

definicin de procesos.

Maqueta:Definicin de la lnea


2/11

rfica de interfaz.

Planificacin:Plan detallado del

royecto, asignacin de recursos y

definicin de entregables.

Produccin

Consiste en el desarrollo del proyecto organizado en hitos y entregables y as facilitar a los clientes

la posibilidad de revisar la aplicacin a medida que se va construyendo. Etapas: Prototipo, Diseo de

interfaz, creacin de la Base de datos, Implementacin, Integracin y pruebas-testeo. Se trata de un

proceso que se lleva a cabo mediante ciclos iterativos hasta que el cliente nos da su conformidad.

Control de calidad

Una vez la aplicacin ha sido desarrollada y testeada con xito, pasar por una etapa final de

control de calidad previa a la aceptacin del cliente. De esta forma, el software finalizado se entregaal equipo interno de calidad para un profundo testeo, tanto funcional (comparndolo con la

documentacin de requerimientos), como tcnico (especialmente de carga y stress, simulando

conexiones de usuarios que la usan).

Puesta en marcha

Finalizado el control de calidad y con la aceptacin del cliente, se lleva a cabo la fase de despliegue

y puesta en marcha, que a su vez se divide en cinco etapas cuyo orden y mbito depender del

proyecto en cuestin:

Instalacin del hardware:En caso de que sea necesario, se realizar la instalacin del servidor oclster de servidores.

Instalacin del software:Se instalar y configurar el software y, en general, los requerimientos

necesarios en servidor para el funcionamiento correcto de la aplicacin.

Instalacin de la aplicacin:Migracin desde el servidor de pruebas al servidor definitivo.

Migracin de datos:En caso necesario, se migrar la informacin desde el antiguo gestor de base de

datos de la organizacin al nuevo servidor.

Formacin:El responsable del proyecto prepara la documentacin necesaria, y se encarga de formar

a los futuros usuarios para el uso de la aplicacin o para la gestin de contenidos en el caso de

proyectos Web. Fase de cierre, inicio de la mejora continua y soporte: Se da por finalizado el proyecto al haberse

alcanzado los objetivos consensuados con el cliente, y entra en vigor la garanta. Durante este periodo

se pueden analizar ampliaciones funcionales que aporten ms valor aadido al proyecto, o nuevas

oportunidades de negocio que desemboquen en futuras colaboraciones. Al finalizar la garanta,

entrar en vigor el periodo de soporte y mejora continua.


3/11

Gestin del proyecto

Esta fase se realiza en paralelo junto a las dems, y consiste en todas la actividades de gestin

necesarias para llevar a buen trmino el proyecto y lograr los objetivos marcados. Estas actividades

las lleva a cabo el jefe de proyecto asignado, y consisten principalmente en el control y

coordinacin de recursos, costes, tiempos, planificacin, entregables y calidad.

http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/softeng-agile.html

http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf

Gestin de Proyectos y Metodologa de

Desarrollo de SoftwarePublicada el31/01/2012porDharma Consulting

2

Panorama General

Adems de las metodologas comercialmente disponibles como Prince 2 y Rational

Unified Process (RUP), existen muchas metodologas desarrolladas a la medida para

organizaciones individuales. Este artculo trata de proveer un mejor entendimiento de las

metodologas y cmo stas se pueden desarrollar e implementar.

Metodologa de Gestin de Proyectos & Metodologa de Desarrollo de Aplicaciones

Es importante diferenciar entre una metodologa de gestin de proyectos y una metodologa

de desarrollo de aplicaciones o metodologa de desarrollo de software. Una metodologa
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/softeng-agile.htmlhttp://www.softeng.es/es-es/empresa/metodologias-de-trabajo/softeng-agile.htmlhttp://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdfhttp://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdfhttp://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/author/dharma/http://blog.dharmacon.net/author/dharma/http://blog.dharmacon.net/author/dharma/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/author/dharma/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdfhttp://www.softeng.es/es-es/empresa/metodologias-de-trabajo/softeng-agile.html


4/11

de gestin de proyectos cubre todas las cosas que un gerente de proyectos necesita

hacer independientemente de si se trata de un desarrollo de software, una seleccin de paquetes,

o una mudanza de su departamento de proyectos.

La Gua del PMBOK (Project Management Body of Knowledge Biblia del PMI) cubre

nueve reas de la gestin de proyectos, siendo stas las siguientes:

Gestin del Costo

Gestin del Riesgo

Gestin del Alcance

Gestin de los Recursos

Gestin de las Comunicaciones

Gestin de la Calidad

Gestin del Tiempo Gestin de las Adquisiciones

Gestin de la Integracin

Como se podr ver, no se menciona nada acerca de requerimientos, pruebas, o seleccin

de vendedores. Eso es parte de una metodologa de desarrollo de aplicaciones o metodologa

de desarrollo de software.

Diferencias entre Metodologas

Una metodologa de gestin de proyectos dice que los proyectos deben descomponerse enfases y debe existir un plan definido para cada fase antes de que empiecen. Una metodologa de

desarrollo de aplicaciones define que fases sern y que actividades deben de ejecutarse en cada

una.

Una metodologa de gestin de proyectos dice que hay que definir roles y responsabilidades.

Una metodologa de desarrollo de aplicaciones define que roles y responsabilidades habrn en

la fase de desarrollo.

Una metodologa de gestin de proyectos dice que se debe establecer un presupuesto y que

debe ser gestionado adecuadamente. Una metodologa de desarrollo de aplicaciones define

cuales deberan ser los cdigos de cuenta para un desarrollo en su organizacin.

La metodologa de gestin de proyectos es la estructura de trabajo. Una metodologa

de desarrollo de aplicaciones es la carne que colocamos sobre los huesos.


5/11

La prueba autntica para diferenciar una metodologa de gestin de proyectos es hacer la

pregunta:

Podracolocar otra carne sobre los mismos huesos?

Por ejemplo, podra tener una metodologa de seleccin de paquetes que podra encajar a

la perfeccin en una metodologa de gestin de proyectos. La diferencia est en que contiene un

conjunto diferentes de actividades, roles, responsabilidades, riesgos, etc.

Por qu es importante conocer la distincin?

Es importante porque cualquier organizacin debe tener una metodologa de gestin

de proyectos consistente, la cual sea de uso comn para cualquier tipo de proyecto. De

esta manera, el personal puede moverse confortablemente de desarrollo de aplicaciones,

a despliegue de infraestructura, a seleccin de software, o incluso mudanzas a nuevos

edificios, usando la misma metodologa.

Entrenar al personal en gestin de proyectos tiene prioridad antes de que aprendan a desarrollar,

seleccionar software, o incluso antes de hacer algn proyecto que no tenga una metodologa

definida. Las personas necesitan saber que deben administrar el alcance, y deben saber como

hacerlo. Deben saber como elaborar un presupuesto y como gestionarlo. Deben saber como

hacer una evaluacin de riesgos y como gestionar los riesgos.

Una Metodologa no es una Plantilla


6/11

Otra rea de confusin es que las personas entreveran plantillas y metodologas. Cuando

sepregunta a la gente si poseen una metodologa, responden Si, tenemos algunas plantillas.

Una evolucin tpica para una organizacin que no tiene un modo definido de hacer las cosas es

empezar desarrollando plantillas para ganar algo de consistencia en la manera en que

sepresentan las cosas. En esta fase lo que en realidad se est expresando es: Aqu tienes

una lista de cosas que necesitas considerar. La siguiente fase es adicionar algunas

instrucciones en la plantilla que expliquen que significa cada seccin. Alternativamente se

puede crear una gua de usuario de la plantilla. Finalmente se podra desarrollar un proceso o

metodologa que indique a las personas como obtener la informacin que termina en la

plantilla.

Existen frecuentes confusiones entre plantillas y procesos:

Un proceso es un modo de hacer las cosas, ejecutando algunas actividades en una cierta

secuencia.

Las plantillas se usan para recolectar las salidas de los procesos.

Solo porque se tenga plantillas, no significa que la gente conozca como recolectar

la informacin que va en ellas. Por ejemplo una plantilla podra tener una seccin con

un encabezado llamado Seguridad. El proceso correspondiente podra ser algo como esto:

Discutir el proyecto con el gerente de seguridad de aplicaciones e identificar que acciones se

requerirn para satisfacer los estndares corporativos.

Revisar cmo el proyecto ser afectado por los nuevos estndares de seguridad a

ser introducidos por la arquitectura. Esto se debe hacer en un taller con las


7/11

siguientespersonas

Conversar con la administracin de redes e identificar cualquier implicacin de seguridad de

la red.

Reunirse con Microsoft y discutir cualquier parche de seguridad que pueda necesitar ser

distribuido con el software.

Etc.

Si slo tenemos disponible una plantilla y no un proceso, la persona que llenar la

plantilla quizs no sepa nada de las actividades mencionadas arriba, y al final la seccin

Seguridadpodra llevar slo la anotacin No aplicable a este proyecto. Esta es la diferencia

entre una plantilla y un proceso o metodologa.

Qu debe de cubrir una metodologa?

Cualquier metodologa debera cubrir los siguientes tpicos:

Usando una Metodologa

Una metodologa no podr ser usada por todos los proyectos que se llevarn a cabo. Habr que


8/11

hacer ajustes por muy buenas razones. Esto no significa que la metodologa variar segn el

antojo de cada equipo. Se necesitar tener guas especficas sobre un enfoque pragmtico

y razonable para cada proyecto.

Una investigacin de Gartner Group encontr que una metodologa aplicada con holgura

podra mejorar la productividad en un 30%. Aplicarla rgidamente mejorara el producto en

solamente 10%. La metodologa debe ser una ayuda para el proyecto, no un obstculo. Si se

desea que nuestra organizacin use una metodologa, se necesitar tener algunos expertos a

quienes puedan recurrir las personas por ayuda.

Objeciones para Usar una Metodologa

A continuacin hay algunas objeciones comunes y la forma en que pueden ser manejadas:

Reprime mi creatividad?

La creatividad no significa Lo har conforme avanzo. Debe significar Poseo

un mecanismo de reconocimiento de problemas y uso mi creatividad para resolverlos. Enun

proyecto la creatividad necesita realizarse dentro un ambiente controlado. A menos que exista

una estructura establecida, los cientos de detalles y problemas no podrn ser controlados.

Poseo mi propia metodologa

Cualquiera de nosotros, que haya trabajado en organizaciones, posee usualmente

una metodologa. La razn para usar la metodologa de la compaa es que alguien ms estaoperando dentro de esa metodologa. Por lo tanto causar confusin a todos si cada uno usa sus

propios procesos.

Mi metodologa es mejor

Una compaa debe tener un rea responsable para revisar y mejorar metodologas.

Ese es el lugar donde se debe promover una nueva metodologa.

La metodologa no es aplicable a mi proyecto

Si no es as Porqu no? Qu componentes son aplicables, y cmo se pueden incluir otros

procesos para unirse a stos. Revise la metodologa de gestin de proyectos, Qu nuevas

actividades, roles, etc. necesitan ser desarrollados?

La metodologa (o plantilla) tiene mucha informacin


9/11

Trtela como un checklist. Si algo no es aplicable, justifique porqu y haga un comentario.

Podra ser una situacin como el tema de seguridad mencionado anteriormente, donde la

persona no entiende el proceso en forma apropiada.

Existe mucho papeleo

Un par de puntos: Primero, pregunt qu informacin est. A veces un pequeo rearreglo de

informacin puede resultar en una solucin tipo refirase al documento X, o a un cortar y

pegar prrafos. Segundo, es ms barato y fcil desechar papel que cdigo. Los programadores

adoran tener sus manos en el teclado, pero es ms eficiente construir algo en papel antes

de hacerlo en cdigo. Tercero, examine cada documento y vea si es realmente necesario. Hice

este ejercicio con un CFO (Chief Financial Officer) quien hizo un comentario acerca de la

cantidad de papel que estbamos generando. Despus de revisar cerca de diez documentos que

tena sobre su escritorio, encontr al menos una razn para recibir cada uno de ellos. Todo sedeba simplemente a que no estaba acostumbrado a ver agendas, actas o reportes semanales.

Implementando una Metodologa

Una metodologa no es una serie de plantillas. Es un proceso que necesita ser adaptado a

la medida de cada situacin. Para esto se necesita de alguien con quien el equipo se

pueda comunicar, el cual ser el mentor de los equipos en el uso de la metodologa.

Una de las implantaciones ms exitosas de una metodologa en la cual he participado, fue lade un departamento de gobierno. Ellos tienen un coordinador de la metodologa a

tiempo completo, quien entrena, trabajaba con los equipos, e integra la retroalimentacin dentro

de la metodologa.

La retroalimentacin es muy importante. La metodologa no permanecer inmvil.

Evolucionar volvindose ms aplicable en la organizacin. En este sentido se necesitar un

mecanismo establecido que se ocupe del aprendizaje a partir de la experiencia.

Proceda de manera gradual. Un cambio radical en el modo en que la gente trabaja no

tendr probablemente tanto xito como un cambio progresivo. Si la meta es tener

personas elaborando un plan para cada fase, lo mejor ser que empiecen por un solo plan

estndar para todo el proyecto. Si decide introducir tres puntos de control para la aprobacin de

recursos, introdzcalos uno a la vez. Probablemente encontrar, despus de haber establecido el

primer punto de control, que tendr que cambiar tan slo ligeramente su proceso para establecer

los otros dos puntos de control.


10/11

La disponibilidad es otro asunto a tratar. Pedir a las personas que lean 400 hojas de un manual,

no funciona. Proporcionarles un entrenamiento de alto nivel, y presentndoles la informacin

en un formato donde puedan encontrar fcilmente la parte que es relevante para la labor que

estn realizando, tiene muchas ms probabilidades de xito.

Una bien estructurada presentacin va Web, es una condicin indispensable. Las

personas necesitan ser capaces de profundizar rpidamente a travs de unos cuantos clicks,

para encontrar lo que es relevante para ellos en ese momento. Entrenarlos en el layout del

website de la metodologa probablemente tendr mayor impacto que entrenarlos en el detalle de

la metodologa.

Resumen

Colocar algunas plantillas es un buen primer paso, pero no es una metodologa. Asegrese

de entender la diferencia entre las plantillas y los procesos. Tambin entienda la diferenciaentre una metodologa de gestin de proyectos y otras metodologas.

Para muchas personas la metodologa es una palabra sucia. Significa burocracia, papeleo,

y restricciones. Se necesita superar esto proveyendo soporte y flexibilidad en la manera

de aplicar la metodologa. Todava no he visto una metodologa que tenga xito con tan

solo presentar a las personas una serie de libros y plantillas.

Finalmente, aprenda a caminar antes de correr. Primero implante pasos simples en

la metodologa, dejando lo ms complicado para el final. Comprenda que est tratandode cambiar el modo de pensar y trabajar de las personas. Hay una resistencia al cambio.

Aborde el asunto lentamente o se encontrar obteniendo pocos resultados o ninguno.

Neville Turbit tiene ms de 15 aos de experiencia como Consultor TI y casi el mismo tiempo

en Negocios. Es el director principal de Project Perfect. Project Perfect es una organizacin de

consultora y entrenamiento localizada en Sydney, Australia. Su foco es proveer soluciones

creativas aunque pragmticas para los problemas dela Gestinde Proyectos.

Project Perfect vende el software Project Administrator, el cual es una herramienta que ayuda

a las organizaciones a gestionar mejor los riesgos del proyecto, problemas, presupuestos,

alcance, documentacin del planeamiento, y programacin de actividades. Tambin ha creado

una tcnica para levantar informacin llamada Method H, y vende software para soportar

dicha tcnica. Para mayor informacin sobre Herramientas para Proyectos o Gestin de

Proyectos visite www.projectperfect.com.au


11/11

http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/
http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/http://blog.dharmacon.net/articulos/gestion-proyectos-metodologia-desarrollo-software/

desarrollo de sw

Documents