SISTEMAS DE INFORMACION

UNIVERSIDAD DE HUNUCO FACULTAD: INGENIERIA EAP: DE ING. DE SISTEMAS E INFORMATICA

OBJETIVO: Visin de los Sistemas de Informacin

CONTENIDO: Consideraciones al desarrollar un S.I Insatisfaccin de usuarios en el desarrollo de un S.I Problemas tpicos en el desarrollo de un S.I

Consideraciones en el desarrollo de un Sistema de Informacin

No se trata de algo nuevo.

Los seres humanos transformamos la realidad que nos rodea con nuestras manos e ingenio.
Desde la antigedad, vimos que para ser ms productivos necesitbamos organizarnos ante los objetivos que pretendamos alcanzar. En la actualidad las empresas tienen aprendida la leccin.

Las legiones romanas,..., diferan de sus contrincantes en:

la tecnologa que utilizaban era mejor

(bronce,

hierro,..), y

la planificacin y seguimiento estaba mas elaborada, es decir:

tenan

los objetivos ms claros, tenan mejor preparada la estrategia a seguir, estaban mejor organizados, informaban rpidamente a sus compaeros, para que estos pudieran corregir cualquier desviacin (Maratn).

Que es un proyecto?
Final carrera (PFC) Planos y especificaciones Forma de organizar el trabajo

Un proyecto es un esfuerzo temporal acometido para crear un nico servicio o producto PMI.
5

Caractersticas de un proyecto
Existe un objetivo claro. Se puede identificar un conjunto de tareas. Necesaria la intervencin de especialistas. Existen limitaciones en los recursos. Tiene principio y fin en el tiempo. Se requiere un nivel de calidad. Se requiere una planificacin.

El proyecto, una forma de organizar el trabajo. 6

Que es la Gestin?

Planificar Organizar Controlar Dirigir

Gestin de proyectos es: Articular el mtodo para alcanzar un objetivo nico y no repetitivo en un plazo con principio y fin claros utilizando las tcnicas que nos proporciona la gestin

Fases de un proyecto.

Planeacin.

Definicin del problema. Planificacin del proyecto. Puesta en marcha. Fase productiva. Conclusin del proyecto.

Ejecucin del proyecto.

El proyecto, una forma de organizar el trabajo.

Definicin del problema.

Origen suele ser difuso:

Problema, Necesidad, oportunidad.

Hay que responder a:

Cual es el problema? Donde esta la oportunidad?

Requiere poco tiempo, pero es fundamental.

9

Planificacin del proyecto.

Identificar todo lo necesario para poder alcanzar el objetivo marcado. Se ponen los cimientos del proyecto:

Calidad Coste econmico Duracin del proyecto

Calidad

Duracin

Coste
10

Ejecucin del proyecto.

Aqu se lleva a cabo el plan previo, es crucial que la planificacin sea buena. Planificaciones malas llevan a:

Posible

cancelacin del proyecto, antes de comenzar. Mal clima en los trabajadores.

Las subfases son:

Puesta

en marcha. Fase productiva. Conclusin del proyecto.

11

Puesta en marcha.

Organizar el equipo del proyecto:

Seleccionar

al personal, Establecer la estructura organizativa, Definir responsabilidades y autoridad, Organizar el lugar de trabajo, Poner en marcha el equipo. Informar de los estndares de trabajo y sistemas de informes.

12

Conclusin del proyecto.

Hacer entrega definitiva del producto al cliente, Revisar las desviaciones del proyecto, identificar causas e indicar formas diferentes de actuacin en futuros proyectos. Reasignar el personal a los nuevos proyectos o reintegrarlos en los departamentos de partida. Es interesante documentar las relaciones entre los empleados para futuros proyectos.

13

Insatisfaccin de usuarios en el desarrollo de un Sistema de Informacin.

Al comenzar cualquier anlisis sobre un SI en desarrollo o en operacin, es frecuente encontrar insatisfaccin tanto en administradores y usuarios, como en analistas de sistemas y encargados de proyectos.

Los problemas y errores comunes.

Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clsicos es una de las razones de que esos errores se cometan tan a menudo.

Personas

Motivacin dbil.

Estudio tras estudio ha mostrado que la motivacin probablemente tiene mayor efecto sobre la productividad y la calidad que ningn otro factor (Boehm 1981).

Personal mediocre.
Despus de la motivacin, la capacidad individual de los miembros del equipo, as como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm, 1981; Lakhanpal, 1993).

Empleados problemticos incontrolados.

Un fallo al tratar con personal problemtico tambin amenaza la velocidad de desarrollo. Un fallo al tomar una decisin cuando se trata con un empleado problemtico es una de las quejas ms comunes que tienen los miembros del equipo respecto de sus responsabilidades (Larson y La fasto, 1989).

Hazaas.
Algunos desarrolladores de software ponen un gran nfasis en la realizacin de hazaas en los proyectos (Bach, 1995).

Aadir ms personal a un proyecto retrasado.

Este es quizs el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir ms gente puede quitar ms productividad a los miembros del equipo existente de la que aaden los nuevos miembros. Fred Brooks compara aadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975).

Oficinas repletas y ruidosas. La mayora de los desarrolladores consideran sus condiciones de

trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (DeMarco y Lister, 1987).

Fricciones entre los clientes y los desarrolladores.

Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes pueden parecerles que los desarrolladores no cooperan cuando rehsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en los requerimientos despus de que stos hayan sido fijados.

Falta de un promotor efectivo del proyecto.

Para soportar muchos de los aspectos del desarrollo rpido es necesario un promotor del proyecto de alto nivel, incluyendo una planificacin realista, el control de cambios y la introduccin de nuevos mtodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. El consultor australiano Rob Thomstt afirma que la falta de un promotor efectivo garantiza virtualmente el fracaso del proyecto (Thomstt, 1995).

Falta de participacin de los implicados.

Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperacin estrecha slo se produce si se han implicado todos los participantes, permitiendo una coordinacin precisa del esfuerzo para el desarrollo rpido, que es imposible conseguir sin una buena

Falta de participacin del usuario.

La inspeccin de Standish Group descubri que la razn nmero uno de que los proyectos de Sistemas de Informacin tuviesen xito es la implicacin del usuario (Standish Group, 1994).

Proceso

Planificacin excesivamente optimista.

Los retos a los que se enfrenta alguien que desarrolla una aplicacin en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicacin que necesita un ao.

Gestin de riesgos insuficiente.

Algunos errores no son lo suficientemente habituales como para considerarlos clsicos. Son los llamados "riesgos". Como con los errores clsicos, si no ejercemos una gestin activa de los riesgos, con qu slo vaya mal una cosa se pasar de tener un proyecto con un desarrollo rpido a uno con un desarrollo lento.

Fallos de los contratistas.

Las compaas a veces contratan la realizacin de partes de un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa.

Planificacin insuficiente.

Si no planificamos para conseguir un desarrollo rpido, no podemos esperar obtenerlo.

Abandono de planificacin bajo presin.

Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificacin (Humphrey, 1989).

Prdida de tiempo en el inicio difuso.

El "inicio difuso" es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto.

Escatimar en las actividades inciales.

Los proyectos se aceleran intentando acortar las actividades "no esenciales", y puesto que el anlisis de requerimientos, la arquitectura y el diseo no producen cdigo directamente, son los candidatos fciles.

Diseo inadecuado.
Un caso especial de escatimar en las actividades inciales es el diseo inadecuado. Proyectos acelerados generan un diseo indeterminado, no asignado suficiente tiempo para l y originado un entorno de alta presin que hace difcil la posibilidad de considerar alternativas en el diseo.

Escatimar en el control de calidad.

En los proyectos que se hacen con prisa se suele cortar por lo sano, eliminando las revisiones del diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales.

Control insuficiente de la directiva.

Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonan cuando el proyecto comienza a tener problemas.

Omitir tareas necesarias en la estimacin.

Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de aadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuchten, 1991).

Planificar ponerse al da ms adelante.

Un tipo de reestimacin es responder inapropiadamente el retraso del plan. Si hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a los dos meses qu hacer?.

Producto

Exceso de requerimientos.
Algunos proyectos tienen ms requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito ms a menudo de lo que es necesario, y puede generar una planificacin del software innecesariamente larga. Los usuarios tienden a interesarse menos en las prestaciones complejas que en las de las secciones de marketing o de desarrollo, y las prestaciones complejas alargan desproporcionadamente el plan de desarrollo.

Desarrolladores meticulosos. Los desarrolladores encuentran

fascinante la nueva tecnologa, y a veces estn ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementacin de una utilidad bonita que han visto en otro producto, la necesite o no su producto. El esfuerzo requerido para disear, implementar, probar, documentar o mantener estas prestaciones innecesarias alarga el plan.

Desarrollo orientado a la investigacin.

Seymour Cray, el diseador de los supercomputadores Cray, dijo que no intentaba sobrepasar los lmites de la ingeniera en ms de dos reas a la vez, porque el riesgo de un fallo es demasiado alto (Gilb, 1988).

TECNOLO GIA

Sndrome de la panacea.
A veces se confa demasiado en las ventajas proclamadas de tecnologas que no se han usado antes (generadores de informes, diseo orientado a objetos y C++) y se tiene poca informacin sobre lo buenas que seran en un entorno de desarrollo concreto. Cuando el equipo del proyecto se aferra slo a una nueva tcnica, una nueva tecnologa o un proceso rgido, y espera resolver con ello sus problemas de planificacin, est inevitablemente equivocado (Jones, 1994).

Sobreestimacin de las ventajas del empleo de nuevas herramientas o mtodos.

Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuntas nuevas herramientas o mtodos empleen o lo bueno que sean. Los beneficios de las nuevas tcnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas tcnicas para aprovecharlas al mximo lleva su tiempo. Las nuevas tcnicas tambin suponen nuevos riesgos, que slo descubriremos usndolas. Ms bien experimentaremos mejoras lentas y continuas en un pequeo porcentaje por proyecto en lugar de grandes saltos.

Cambiar de herramientas a mitad del proyecto.

Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma lnea de productos, de la versin 3 a la 3.1, o incluso a la 4.

15
Personas

10 5 0
0 3 6 9 12 15 18 21 24

Meses de Desarrollo

Estadstica realizada sobre 8 proyectos de Software Estadounidenses.

rea: Sistemas de Defensa en Tiempo Real
Pagado pero no entregado Entregado pero no utilizado abandonado o rechazado Utilizado despus de cambios Utilizado como se entrego

0.5

1.5

2.5

3.5

Millones de dolares
El producto software (EOG tema2) 49

Ingeniera del software

Desarrollo de Software
Analisis Diseo Codificacin Pruebas

Gestin de proyectos
Planificacin Organizacin Reclutamiento Direccin Control

Metricas del software

Mantenimiento de software

Fiabilidad Correccin de Errores Usabilidad Modificaciones Flexibilidad Mantenibilidad Reusabilidad Etc.

50