1. reporte estadia cdgs

INFORME DEL PROYECTO DE ESTADA

Soporte Tcnico

DESARROLLADO EN LA EMPRESA

Secretara General de Gobierno, Direccin de Informtica y Modernizacin

POR EL ALUMNO

Carolina Dianey Garca Snchez

PARA OBTENER EL TTULO DE

Tcnico Superior Universitario en Tecnologas de la Informacin y Comunicacin

rea Sistemas Informticos

ASESOR ACADEMICO

Lic. Juan Carlos Medina del Alto

ASESOR EMPRESARIAL

Encargada de Soporte Tcnico. Nohem Marn Garca

Rincn de Romos, Ags. Agosto de 2013

DEDICATORIAS

A Dios por haberme permitido llegar hasta este punto y dado salud para lograr

mis objetivos, adems de su infinita bondad y amor.

A mis padres Vctor Manuel Garca Romero y Mara de Lourdes Snchez

Rodrguez por darme la vida, quererme mucho, creer en m, por ser el pilar

fundamental en todo lo que soy, en toda mi educacin, tanto acadmica, como de

la vida, por su incondicional apoyo perfectamente mantenido a travs del tiempo,

por sus consejos, sus valores, por la motivacin constante que me ha permitido

ser una persona de bien, por el ejemplo de perseverancia y constancia que los

caracteriza y que me han inculcado siempre, por el valor mostrado para salir

adelante y ms que nada por su amor, por darme una carrera para mi futuro, todo

esto se los debo a ustedes, gracias.

A mi hermano Jonathan Olaf Garca Snchez para que vea en m un ejemplo a

seguir, porque l para mi es mi motivacin para salir adelante, y as l vea la

importancia que tiene el estudio actualmente, para que sea alguien en la vida y

luche por sus ideales.

AGRADECIMIENTOS

A mi asesor acadmico. Lic. Juan Carlos Medina del Alto por su gran motivacin

para la culminacin de mis estudios profesionales y para la elaboracin de este

reporte por su apoyo ofrecido en este trabajo; por su tiempo compartido y por

impulsar el desarrollo de mi formacin acadmica.

A mis amigos. Que nos apoyamos mutuamente en nuestra formacin acadmica y

que hasta ahora, seguimos siendo amigos: Ruth Araceli Luvano de la Rosa, Erika

Rodrguez Rodrguez, Claudia Alejandra Esparza Loera, Ana Judith Herrera

Duron, Diana Sandoval Araujo y Perla Pasillas Guerrero.

A mi asesor empresarial. Nohem Marn Garca por su valiosa asesora, por todas

las facilidades que me otorgo durante el proceso de investigacin y por su

paciencia y consejos en el mbito de lo que es el soporte tcnico, en el transcurso

de lo que es la realizacin de la estada.

A mis maestros de la Universidad Tecnolgica del Norte De Aguascalientes de la

carrera de TIC-SI que siempre nos brindaron sus conocimientos y nos orientaron

durante todo este tiempo. Todo este trabajo ha sido posible gracias a ellos.

INTRODUCCIN

En el presente reporte se muestra el trabajo realizado durante las prcticas

acadmicas en el proyecto enfocado al Soporte Tcnico el cual consiste en

realizar el mantenimiento preventivo y correctivo de los equipos y dispositivos que

se encuentran en las diferentes dependencias de la institucin.

El reporte abarca cinco captulos de los cuales el primero trata acerca de la

Secretara de Gobierno y los dems captulos de las actividades en las que se

particip.

El primer captulo muestra los antecedentes de la Secretara de Gobierno y acerca

de su perfil, caracterizacin de la empresa, estructura organizacional y el anlisis

foda.

El segundo captulo trata de la descripcin de los problemas que surgen en la

Secretaria de Gobierno, plan de accin, objetivo, alcance del proyecto y

metodologa.

El tercer captulo consiste en desarrollar la teora que va a fundamentar el

proyecto con base al planteamiento del problema que se ha realizado, esto se

refiere al marco terico.

El cuarto captulo se toma en cuenta los requerimientos del proyecto as como la

metodologa a usarse dentro del mismo, tomando en cuenta las tcnicas

existentes para su realizacin, adems del soporte realizado tanto preventivo

como correctivo a los diferentes equipos y dispositivos.

Y por ltimo el quinto captulo trata de resultados obtenidos se divide en

evaluacin de resultados, recomendaciones y conclusiones.

NDICE

Introduccin ndice Captulo 1 Marco referencial Introduccin 2

1.1 Perfil de la empresa 3

1.2 Antecedentes histricos 4

1.3 Caractersticas de la empresa 5

1.4 Estructura organizacional (organigrama) 6

1.5 Anlisis FODA 7

Captulo 2 Descripcin del proyecto Introduccin 9

2.1 Planteamiento del problema 10

2.2 Objetivo del proyecto 11

2.3 Cronograma de trabajo 12

2.4 Plan de accin 15

2.5 Metodologa 20

2.6 Alcances y limitaciones 22

Captulo 3 Marco Terico Introduccin 24

3.1 Metodologa espiral 25

3.2 Metodologa de desarrollo en espiral 32

3.3 Mantenimiento preventivo y correctivo 34

3.4 Ciclo del proyecto 36

3.5 Espiral 39

3.6 El modelo en espiral 41

3.7 El modelo en espiral II 44

3.8 Planificacin de un proyecto de ingeniera de software 46

Captulo 4 Desarrollo del proyecto Introduccin 51

4.1 Fase de anlisis 52

4.2 Fase de diseo 58

4.3 Fase de implementacin 80

4.4 Fase de pruebas 83

Captulo 5 Resultados obtenidos Introduccin 88

5.1 Evaluacin de resultados 89

5.2 Recomendaciones 90

5.3 Conclusiones 91

Glosario Bibliografa

Universidad Tecnolgica del Norte de Aguascalientes Tecnologas de la Informacin y Comunicacin rea Sistemas Informticos

1

Captulo 1

Marco referencial


2

INTRODUCCIN

El siguiente anlisis se ha centrado en el estudio de la SEGOB (Secretara

General de Gobierno), la relevancia del proyecto se debe a que consideramos que

requiere el entendimiento de los diversos factores que constituyen las diferentes

reas, para ello es necesario hacer el anlisis para comprobar los requerimientos

y el funcionamiento establecido.


3

1.1 PERFIL DE LA EMPRESA

Nombre o razn social:

Secretaria General del Gobierno del Estado de Aguascalientes, Direccin de

Informtica y Modernizacin

Giro

Servicios pblicos.

Domicilio

Daz de Len #102, Zona Centro C.P. 20000.Aguascalientes, Ags.

Telfono(s)

(449) 9182289 Ext. 3520

(449) 9102015 Ext. 3520

Correo electrnico

[email protected]

Pgina web

http://www.aguascalientes.gob.mx/segob/


4

1.2 ANTECEDENTES HISTRICOS

La Secretara de Gobierno es una dependencia de la administracin pblica

centralizada, y es la encargada de auxiliar al titular del Poder Ejecutivo en la

conduccin de la poltica interna y procurar la legalidad y la gobernabilidad

democrtica del Estado. De la misma forma intervenimos en la instrumentacin

jurdica de sus decisiones, as como en la coordinacin funcional de las reas

relativas al trabajo, la mediacin, la atencin a migrantes, la proteccin civil, el

Registro Pblico de la Propiedad, el Registro Civil, la Visitadura de Notaras, los

Archivos del Estado entre otras reas, con las funciones y atribuciones que nos

confiere expresamente la Ley Orgnica de la Administracin Pblica del Estado de

Aguascalientes, as como la normatividad aplicable.

Nuestro impulso nace con base en la poltica de gobierno instrumentada en una

administracin basada en la tica y el profesionalismo, que trabaja con

honestidad, probidad, eficiencia y transparencia, que se retroalimenta y enriquece

del dilogo con nuestro eje principal: la ciudadana.


5

1.3 CARACTERSTICAS DE LA EMPRESA

Misin

Impulsar una cultura poltica incluyente que garantice la gobernabilidad del Estado

de Aguascalientes brindando certeza y seguridad jurdica, que abarque a todos los

sectores y actores de la sociedad en un marco de respeto, legalidad,

transparencia, equidad y participacin, que propicie el desarrollo armnico del

Estado.

Visin

La Secretara de Gobierno ser lder a nivel nacional en todos los mbitos de su

competencia, con la participacin activa de la sociedad, los sectores y poderes,

que le permitan establecer la plataforma necesaria que le brinde seguridad jurdica

al estado y lo proyecte en el logro de su desarrollo integral.

Objetivos estratgicos

Optimizar los procesos de conciliacin, tramitacin y resolucin pronta y expedita

de los conflictos laborales en el Estado de Aguascalientes. Lograr el

reconocimiento, por parte del sector a quien se dirige nuestro trabajo, de la

eficiente, eficaz y transparente atencin y resolucin de los conflictos laborales.

Poltica de calidad

La Secretara de Gobierno se compromete a impulsar una poltica incluyente que

garantice la gobernabilidad del Estado de Aguascalientes, brindando certeza y

seguridad jurdica a todos los sectores y actores de la sociedad en un marco de

calidad y liderazgo, procurando la mejora continua en su actuacin, de manera

que establezca la plataforma necesaria que la sociedad espera, actuando con

respeto, legalidad, transparencia, equidad y participacin.


6

1.4 ESTRUCTURA ORGANIZACIONAL

SEGOB


7

1.5 ANLISIS FODA.

Fortalezas

F1. Cuenta con personal capacitado en atencin a los usuarios de las diferentes

dependencias.

F2. Est ubicado en un lugar estratgico.

F3. Posee un nmero de inventario para el manejo de los equipos de cmputo.

F4. Cuenta con un dominio propio.

F5. Usabilidad de los materiales y equipos utilizados.

Debilidades

D1. Algunas veces la red se encuentra ocupada.

D2. No posee equipos con tecnologa acorde a las necesidades actuales.

D3. Presupuesto limitado para adquirir dispositivos requeridos.

Oportunidades

O1. Calidad en el servicio soporte tcnico a usuarios.

O2. Incursin de nuevos sistemas y tecnologas, adems de equipos e

infraestructura.

O3. Las necesidades en instalacin, mantenimiento, diagnstico y evaluacin del

rendimiento de los equipos de las dependencias para la realizacin de su trabajo.

Amenazas

A1. Sistemas y equipos obsoletos.

A2. Utilizacin de servicios de TI contratados a terceros, ejemplo HP, lo que hace

que no sea necesario tener una oficina de soporte.


8

Captulo 2

Descripcin del proyecto


9

INTRODUCCIN

En este captulo se tomaran en cuenta los requerimientos del proyecto, as como

las tcnicas utilizadas para determinar los estndares que tendrn los formatos o

checklist, tomando en cuenta la metodologa existente para su realizacin,

guindonos del plan de accin para saber cmo se ir desarrollando.


10

2.1 PLANTEAMIENTO DEL PROBLEMA

El rea de soporte tcnico de la secretaria general del gobierno realiza el

mantenimiento preventivo y correctivo nicamente al presentar el usuario de

alguna de las dependencias el problema que se le est presentando tanto con su

equipo o algn dispositivo que utiliza para realizar su trabajo, el encargado del

departamento asigna a alguno de los compaeros para que le vaya a corregir el

problema, una vez enviado, l compaero asignado tiene que llevar un control de

los soportes auxiliados, se realiza por medio de un sistema el cual se trata de

realizar reportes del problema y lo que fue la solucin; cuenta con personal

capacitado en atencin a los usuarios de las diferentes dependencias, est

ubicado en un lugar estratgico, posee un nmero de inventario para el manejo de

los equipos de cmputo, cuenta con un dominio propio, usabilidad de los

materiales y equipos utilizados, calidad en el servicio soporte tcnico a usuarios,

incursin de nuevos sistemas y tecnologas, adems de equipos e infraestructura,

las necesidades en instalacin, mantenimiento, diagnstico y evaluacin del

rendimiento de los equipos de las dependencias para la realizacin de su trabajo.

Es muy comn encontrarse en escenarios como el de prdida de informacin y/o

de hardware, la instalacin de software no completada, los equipos de cmputo

con fallas constantes como: su funcionamiento lento, reinicindose

constantemente, llegando al grado de no encender; los usuarios eliminan archivos

por accidente, falla de la impresora, falla de la red gubernamental, el aumento de

equipos en la red que no estn contemplados, algunas veces la red se encuentra

ocupada, no posee equipos con tecnologa acorde a las necesidades actuales,

presupuesto limitado para adquirir dispositivos requeridos, sistemas y equipos

obsoletos, utilizacin de servicios de TI contratados a terceros, ejemplo HP, lo que

hace que no sea necesario tener una oficina de soporte y mal funcionamiento de

un dispositivo o equipo a prestar esto debido a que no se tienen establecidos

criterios para la realizacin del mantenimiento preventivo y correctivo.


11

2.2 OBJETIVO DEL PROYECTO

Actualmente en la Secretaria General de Gobierno del Estado de Aguascalientes

no se cuenta con procesos estandarizados que permitan el aseguramiento del

buen funcionamiento de los equipos de cmputo asignados a esta dependencia.

Es muy comn encontrarse en escenarios como el de prdida de informacin y/o

prdida de hardware esto debido a que no se tienen establecidos criterios para la

realizacin del mantenimiento preventivo y correctivo.

Objetivo General

Disear un manual de operacin o de soporte tcnico que contenga mtodos

estandarizados a travs de formatos checklist que nos permitan en todo

momento asegurarnos que los equipos de cmputo funcionen eficientemente y as

conscientes del valor agregado que hoy en da es la informacin. Evitar prdidas

de hardware y software.

Objetivos Especficos

Aumentar la productividad del personal responsable de elaborar.

Reducir los tiempos de entrega del trabajo diario a los usuarios.

Optimizar el funcionamiento de los equipos de cmputo, establecer acceso a

internet bsico y abierto, sistemas operativos instalados correctamente,

paquetera correspondiente instalada, antivirus instalado y actualizado.

Minimizar perdidas de software y hardware que representen un retraso en el

trabajo diario de la Secretaria General de Gobierno del Estado de

Aguascalientes.


12

2.3 CRONOGRAMA DE TRABAJO

No. ACTIVIDAD P/R SEMANA

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 Identificacin de las

necesidades

P

R

2 Diseo de una

propuesta de solucin

P

R

3 Desarrollo de proyecto P

R

4 Realizacin del

proyecto

P

R

5 Implementacin P

R

6 Pruebas P

R

7 Control de proyectos P

R

8 Mantenimiento P

R

9 Terminacin P

R


13

IDENTIFICACIN DE LAS NECESIDADES: Se inicia con el reconocimiento de

una necesidad, un problema o una oportunidad y termina con la emisin de una

solicitud de propuesta, con la finalidad de mejorar la condicin existente,

realizando respectivas actividades mencionadas en el plan de accin.

DISEO DE UNA PROPUESTA DE SOLUCIN: Esta etapa comienza una vez

identificada la necesidad, en la que se lleva a cabo un proceso de preparacin de

propuestas y los elementos que podran ser incluidos en esta misma para poder

llegar a un acuerdo con el cliente.

DESARROLLO DEL PROYECTO: Esta fase se conforma por dos partes, siendo la

primera la planeacin detallada y por ltimo, hay que ponerlo en prctica; la

planeacin debe mostrar cmo se realizaran las tareas dentro del presupuesto y

en el tiempo sealado, en s, la planeacin determina lo que se necesita hacer,

quien lo har, cunto tiempo se necesitara y cuanto costara.

REALIZACIN DEL PROYECTO: Una vez realizada la planificacin del proyecto

se puede poner en prctica las actividades programadas en este, el cual,

aumentara el trabajo conforme se vayan incluyendo ms recursos o tareas al

proyecto.

IMPLEMENTACION: En la etapa de implementacin se realiza todo lo que sea

necesario para que la nueva solucin pueda ser realidad en las condiciones para

las cuales fue diseada. Se dice fcil, por lo que se subestima en muchas

ocasiones. La realidad es que por muy buena y simple que sea una solucin

nueva siempre se requiere un proceso mediante el cual se logra hacerla funcionar.


14

PRUEBAS: Durante este proceso se debern de implementar todas las estrategias

posibles para garantizar que el uso inicial de los checklist se encuentren libres de

problemas lo cual se puede descubrir durante este proceso y llevar a cabo las

correcciones de lugar para su buen funcionamiento.

CONTROL DE PROYECTOS: Esta etapa tiene la funcin de supervisar los

avances del plan conforme se vayan realizando, es decir, medir el progreso real y

as poderlo comparar con lo establecido en la planeacin del proyecto; esto debe

ser de manera peridica y oportuna.

MANTENIMIENTO: Esta fase es la penltima que se aplica al ciclo de vida del

desarrollo del proyecto.

TERMINACIN DEL PROYECTO: El propsito de terminar apropiadamente un

proyecto es aprender de la experiencia ganada, con la finalidad de mejorar el

desempeo de los usuarios.


15

2.4 PLAN DE ACCIN

1. IDENTIFICACIN DE LAS NECESIDADES

1.1 Se realizara una reunin inicial del proyecto: Consiste en presentar el

proyecto a los miembros del rea de Soporte Tcnico, incluyendo objetivos y

responsabilidades.

Actividades:

1) Se presentara en lo que consistir el proyecto a los integrantes del rea de

Soporte Tcnico.

2) Se presentara los objetivos del proyecto.

3) Se planteara las responsabilidades en las que consiste el proyecto.

El responsable ser el alumno y los encargados del rea de soporte tcnico, con

una duracin de un da, en la dependencia de informtica y modernizacin.

1.2 Se realizara una investigacin preliminar: Tiene como finalidad buscar la

informacin suficiente para determinar si se debe continuar con el ciclo de vida del

desarrollo del proyecto.

Actividades:

1) Se aclara y comprender lo solicitado del proyecto.

2) Se definir el alcance y las restricciones o limitaciones del proyecto.

3) Se identificaran los beneficios que se obtendrn si los checklist propuestos

estn completos.

4) Se presentara un informe al rea de soporte tcnico de lo establecido.


una duracin de catorce das, en las diferentes dependencias de la secretaria de

gobernacin y en especial en la dependencia de informtica y modernizacin.


16

2 DISEO DE UNA PROPUESTA DE SOLUCIN

2.1 Se realizara el levantamiento de la informacin: Es el proceso mediante el

cual el analista recopila datos e informacin de la situacin, con el propsito de

identificar problemas y oportunidades de mejoras.

Actividades:

1) Se realizaran las entrevistas correspondientes al personal del rea de soporte

tcnico.

2) Se Identificaran problemas de requerimientos del proyecto.

3) Se obtendrn mejoras para el proyecto.

El responsable ser el alumno, con una duracin de tres das en las diferentes

dependencias de la secretaria de gobernacin y en especial en la dependencia de

informtica y modernizacin.

2.2 Se realizara la obtencin de requerimientos: Estos especifican lo que el

encargado de soporte necesita para basarse de la informacin para saber que

deber hacer o cuales pasos sigue para la solucin.

Actividades:

1) Se identificaran los requerimientos.

2) Se obtendrn los requerimientos funcionales y no funcionales.

El responsable ser el alumno, con una duracin de cinco das, en el rea de

soporte y redes.


17

2.3 Se realizara la lista de riesgos: Se analizan los principales riesgos del proyecto.

Actividades:

1) Se identificaran los riesgos potenciales del proyecto.

2) Se discutir sobre su impacto en el proyecto.

3) Se priorizan los riesgos.

4) Se categorizan los riesgos.

El responsable ser el alumno, con una duracin de tres das, en el rea de

soporte y redes.

3 DESAROLLO DEL PROYECTO

3.1 Se realizara la validacin de requerimientos: Se realizara la documentacin

de los requerimientos del proyecto.

Actividades:

1) Se verificaran los requerimientos establecidos.


una duracin de seis das, en el rea de soporte y redes.

4 REALIZACIN DEL PROYECTO

4.1 Se realizara el anlisis para desarrollar los checklist: Trata bsicamente de

determinar los objetivos y lmites del proyecto objeto de anlisis, caracterizar su

estructura y funcionamiento, marcar las directrices que permitan alcanzar los

objetivos propuestos y evaluar sus consecuencias.

Actividades:

1) Se realizara el examen de supervivencia.

2) Se realizara el acta de proyecto.

El responsable ser el alumno, con una duracin de trece das en el rea de

soporte y redes.


18

4.2 Se realizara el diseo de los checklist: El diseo del formato checklist se

define con el proceso de aplicar ciertas tcnicas y principios con el propsito de

definir un proceso, con suficientes detalles como para permitir su interpretacin y

realizacin fsica.

Actividades:

1) Se mantendr la precisin de los requerimientos del cliente.

El responsable ser el alumno, con una duracin de trece das en el rea de

soporte y redes.

5 IMPLEMENTACION

5.1 Se realizara la implementacin de los checklist segn la falla de software o

prdida de hardware: Al implementar el checklist lo primero que debemos de tener

en cuenta es que debemos de elegir el adecuado ya que no es el mismo para

cada situacin que se presente y al igual van surgiendo ms cotidianamente.

Actividades:

1) Se determinara la situacin que se presente.

2) Se tomara el formato correspondiente.

3) Se seguirn los pasos en curso hasta finalizar.

El responsable ser el alumno, con una duracin de treinta das en el rea de

soporte y redes.

6 PRUEBAS

6.1 Se realizara el plan para verificar si funcionan de la manera planeada: Se

realizara la verificacin y validacin del proyecto.

Actividades:

1) Se realizara las pruebas establecidas.

El responsable ser el alumno, con una duracin de quince das, en el rea de

soporte y redes.


19

7 CONTROL DE PROYECTOS

7.1 Se realizara la validacin del checklist: Se realizara la verificacin y

validacin del software del proyecto.

Actividades:

1) Se realizara una reunin con los encargados del rea de soporte tcnico para

determinar si el funcionamiento es correcto.


una duracin de quince das, en el rea de soporte y redes.

7.2 Se describirn los cambios realizados: Se realizara la documentacin de los

cambios realizados en el formato segn los encargados del rea de soporte

tcnico.

Actividades:

1) Se sealara los defectos encontrados.

2) Se describirn los cambios realizados.

3) Se realizara un reporte de lo ya antes mencionado.

El responsable ser el alumno, con una duracin de cinco das, en el rea de

soporte y redes.

8 MANTENIMIENTO

8.1 Se realizara el mantenimiento de los checklist: Mantener y mejorar el

formato para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar

ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda

la ingeniera de software tiene que ver con dar mantenimiento. Es el proceso de

control, mejora y optimacin del desarrollo, que tambin incluye depuracin de

errores y defectos que puedan haberse filtrado de la fase de pruebas de control.

El responsable ser el alumno, con una duracin de tres das, en el rea de

soporte y redes.


20

9 TERMINACIN DEL PROYECTO

9.1 Se realizara la presentacin de los checklist desarrollados: Se realizara la

presentacin del proyecto realizado.

El responsable ser el alumno y asesores, con una duracin de un da, en el rea

de soporte y redes.


21

2.5 METODOLOGA

En el transcurso de este proyecto la metodologa que se utilizara es la

metodologa en espiral ya que la atencin se centra en la evaluacin y reduccin

del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y

proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como

ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de

la continuacin del proyecto durante todo el ciclo de vida, considerando que cada

viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos:

1. Determinar objetivos, alternativas, y desencadenantes de la iteracin:

Fijar tambin los productos definidos a obtener: requerimientos, especificacin,

manual de operaciones de soporte tcnico.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial.

2. Evaluar alternativas; Identificar y resolver los riesgos:

Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos

con las fases siguientes y planificamos la prxima actividad.


22

3. Desarrollar y verificar los resultados de la iteracin:

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin y resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo

para el desarrollo, el que puede ser cualquiera de los otros existentes, como

formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz

de usuario son dominantes, un modelo de desarrollo apropiado podra ser la

construccin de prototipos evolutivos. Si lo riesgos de proteccin son la

principal consideracin, un desarrollo basado en transformaciones formales

podra ser el ms apropiado.

4. Plan de la prxima iteracin, cabe mencionar que cada ciclo comienza con

la identificacin de los interesados y sus condiciones de ganancia, y termina con la

revisin y examinacin:

Se lleva a cabo el estudio de las causas de las posibles amenazas, probables

eventos no deseados, los daos y consecuencias que stas puedan producir.


23

2.6 ALCANCES Y LIMITACIONES

Limitaciones

Instalar software no contemplado.

Falta de licencias del software a instalar.

No contemplar en la red con el aumento del nmero de equipos a usar.

Cambio por el usuario la conexin establecida para el uso de internet.

Mal funcionamiento no contemplado de algn dispositivo a utiliza.

Falta de recursos.

Tiempo de desarrollo del proyecto.

Alcances

Se optimizara el uso de los equipos de cmputo de cada dependencia que lo

requiera.

Se mantendrn actualizados los equipos de cmputo.

Habr acceso a internet en cada equipo con los servicios especficos para

cada departamento como lo es internet bsico y normal.

Los usuarios de las diferentes dependencias podrn desarrollar sus actividades

con mayor rapidez y sin interrupciones.

Se dar un buen uso a la red y no se saturara al no poder indagar a otros sitios

no requeridos para su trabajo.

Equipos de cmputo en perfectas condiciones sin error en el sistema y

totalmente limpios.

Sistemas operativos instalados correctamente.

Paquetera correspondiente instalada.

Antivirus instalado y actualizado.

Estandarizacin en los procesos de mantenimiento correctivo y preventivo.

Minimizar perdidas de hardware y software.

Funcionamiento ptimo de los equipos de cmputo de la dependencia.


24

Captulo 3

Marco terico


25

INTRODUCCIN

Es importante mencionar la metodologa que hacen referencia al proyecto. En el

siguiente apartado se definen cada uno de los trminos relacionados con el

proyecto de estada, est compuesto de lo siguiente se encuentra informacin

terica del proyecto, continua con la descripcin de la metodologa y termina con

investigaciones pasadas realizadas con la misma metodologa en este caso la

metodologa en espiral.


26

3.1 METODOLOGA ESPIRAL

De acuerdo con Grupo espiral php (8 de agosto del 2009); Boehm, ide y

promulg un modelo desde un enfoque distinto al tradicional en Cascada: El

Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta

fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se

comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo

ms asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo

mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y

riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en

el que el producto software desarrollado sea aceptado y no necesite seguir

mejorndose con otro nuevo ciclo.

HISTORIA

El creador del modelo en espiral fue Barry Boehm quien recibi su grado de B.A.

de Harvard en 1957, y sus grados de M.S. y de PhD. de UCLA en 1961 y 1964,

todo en matemticas.

Barry Boehm era un Programador-Analista en General Dynamics entre 1955 y

1959, sus intereses actuales de la investigacin incluyen modelar de proceso del

software, ingeniera de requisitos del software, las arquitecturas del software,

mtrica del software y los modelos del coste, los ambientes de la tecnologa de

dotacin lgica, y tecnologa de dotacin lgica basada en el conocimiento. Sus

contribuciones al campo incluyen el modelo constructivo del coste (COCOMO), el

modelo espiral del proceso del software, el acercamiento de la teora W (ganar-

gane) a la determinacin de la gerencia y de los requisitos del software y a dos

ambientes avanzados de la tecnologa de dotacin lgica: el sistema y el quantum

de la productividad del software de TRW saltan el ambiente.


27

DEFINICION

El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un

modelo de proceso de software evolutivo donde se conjuga la naturaleza de

construccin de prototipos con los aspectos controlados y sistemticos del

MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo

rpido de versiones incrementales del software que no se basa en fases

claramente definidas y separadas para crear un sistema.

EL modelo en espiral se divide en un nmero de actividades de marco de trabajo,

tambin llamadas REGIONES DE TAREAS , cada una de las regiones estn

compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE

TAREAS que se adaptan a las caractersticas del proyecto que va a emprenderse

en todos los casos se aplican actividades de proteccin.

TIPOS

El modelo espiral tuvo varias modificaciones que son:

Modelo Original de Boehm.

Modelo Tipico de Seis Regiones.

Modelo WINWIN.

MODELO ORIGINAL DE BOEHM

No hay un nmero definido de iteraciones. Las iteraciones debe decidirlas el

equipo de gestin de proyecto.


28

Cada vuelta se divide en 4 sectores:

Planeacin: determinacin de los objetivos, alternativas y restricciones.

Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de

riesgos.

Ingeniera: desarrollo del producto hasta "el siguiente nivel".

Evaluacin: valoracin por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteracin su amplitud radial, indica

que cada vez se van construyendo versiones sucesivas del software, cada vez

ms completas.

Uno de los puntos ms interesantes del modelo, es la introduccin al proceso de

desarrollo a las actividades de anlisis de los riesgos asociados al desarrollo y a la

evaluacin por parte del cliente de los resultados del software.

3.1 Modelo espiral original de Boehm


29

MODELO TIPICO DE SEIS REGIONES

A diferencia del modelo de proceso clsico que termina cuando se entrega el

software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del

software de computadora. Una visin alternativa del modelo en espiral puede ser

considerada examinando el eje de punto de entrada en el proyecto.

Las regiones de tareas que componen este modelo son:

Comunicacin con el cliente: las tareas requeridas para establecer

comunicacin entre el desarrollador y el cliente.

Planificacin: las tareas requeridas para definir recursos, el tiempo y otras

informaciones relacionadas con el proyecto. Son todos los requerimientos.

Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras

informaciones relacionadas con el proyecto.

Ingeniera: las tareas requeridas para construir una o ms representaciones de

la aplicacin.

Construccin y adaptacin: las tareas requeridas para construir, probar, instalar

y proporcionar soporte al usuario.

Evaluacin del cliente: las tareas requeridas para obtener la reaccin del

cliente segn la evaluacin de las representaciones del software creadas

durante la etapa de ingeniera e implementacin durante la etapa de

instalacin.


30

MODELO WINWIN

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de

negociacin al principio de cada paso alrededor de la espiral. Ms que una simple

actividad de comunicacin con el cliente se definen las siguientes actividades:

Identificacin del sistema o subsistemas claves de los directivos.

Determinacin de las condiciones de victoria de los directivos.

Negociacin de las condiciones de victoria de los directivos para reunirlas

en un conjunto de condiciones para todos los afectados (incluyendo el

equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos

de fijacin que ayudan a establecer la completitud de un ciclo alrededor del espiral

y proporcionan hitos de decisin antes de continuar el proyecto de software.

3.2 Modelo espiral tpico de seis regiones.


31

VENTAJAS

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del

software de computadora.

Como el software evoluciona a medida que progresa el proceso, el

desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada

uno de los niveles evolutivos.

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de

construccin de prototipos en cualquier etapa de evolucin del producto.

El modelo en espiral demanda una consideracin directa de los riesgos

tcnicos en todas las etapas del proyecto y si se aplica adecuadamente debe

reducir los riesgos antes de que se conviertan en problemas.

En la utilizacin de grandes sistemas ha doblado la productividad.

3.3 Modelo espiral WinWin


32

DESVENTAJAS

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es

controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos

sistemas.

Genera mucho tiempo en el desarrollo del sistema.

Modelo costoso.

Requiere experiencia en la identificacin de riesgos.


33

3.2 METODOLOGA DE DESARROLLO EN ESPIRAL

La metodologa de desarrollo en espiral es una evolucin de mtodo clsico en

cascada (Waterfall, top-down) y se considera un mtodo de desarrollo incremental.

Este tipo de metodologa equivale al de cascada, pero en l se permite el

solapamiento de varias etapas con el objetivo de flexibilizar, compensar el tiempo

de desarrollo total y alcanzar resultados funcionales en etapas tempranas. Est

considerada como un mtodo de desarrollo rpido y eficiente.

Es adecuada para proyectos en los que se tienen claros los objetivos finales pero

no todos los detalles de implementacin estn solucionados.

La metodologa de desarrollo en espiral permite construir aplicaciones de tamao

medio manteniendo los recursos constantes.

Normalmente el proyecto se divide en mdulos ms pequeos y a cada uno de

ellos se le aplica el siguiente proceso:

Anlisis de requerimientos -Durante esta etapa se estudia detalladamente los

requerimientos que cada objetivo conlleva. Aqu establecen todos los detalles

funcionales deseados.

3.4 Desarrollo en espiral


34

Diseo del sistema - Con los datos de la etapa anterior, se disea el sistema. Se

realizar el diseo de la base de datos (en caso de ser aplicable), interface de

usuario, entorno, etc.

Etapas de construccin - La etapa de construccin comprende bsicamente la

codificacin y test de unidades. Esta etapa es un trabajo de programacin pura.

Test y evaluacin - En esta etapa se realiza un test del mdulo completo as

como su evaluacin frente al estudio de requerimientos. En muchos casos en esta

etapa los usuarios finales participan de manera activa aportando informacin

decisiva para la usabilidad del sistema.

Puntos fuertes

Permite el desarrollo de proyectos en donde los objetivos finales estn

perfectamente definidos pero todos los detalles no pueden ser completamente

establecidos al principio.

Es adaptable: algunos de los requerimientos (que no los objetivos) pueden

cambiar durante el ciclo de desarrollo.

Permite la especializacin de los equipos de trabajo.

Apela a una gestin de proyecto ordenada.

Facilita la distribucin de recursos de desarrollo.

Economa: es posible mantener constantes los recursos de desarrollo.

Permite conseguir funcionalidad en etapas tempranas.

(RIGHTLIGHT IT CONSULTING, S.L).


35

3.3 MANTENIMIENTO PREVENTIVO Y CORRECTIVO

Segn el Sitio web Soportec; El mantenimiento preventivo permite detectar fallos

repetitivos, disminuir los tiempos muertos por paradas, aumentar la vida til de los

equipos, disminuir costos de reparacin, detectar puntos dbiles en la instalacin,

entre una larga lista de ventajas.

En informtica, el mantenimiento preventivo consiste en la revisin peridica de

ciertos aspectos, tanto de hardware como de software en un PC. Estos influyen en

el desempeo fiable del sistema, en la integridad de los datos almacenados y en

un intercambio de informaciones correctas, a la mxima velocidad posible dentro

de la configuracin optima del sistema.

Dentro del mantenimiento preventivo existe software que permite al usuario vigilar

constantemente el estado de su equipo, as como tambin realizar pequeos

ajustes de una manera fcil.

El mantenimiento preventivo en general se ocupa en la determinacin de

condiciones operativas, de durabilidad y de confiabilidad de un equipo, este tipo de

mantenimiento nos ayuda en reducir los tiempos que pueden generarse por

mantenimiento correctivo.

En lo referente al mantenimiento preventivo de un producto software, se diferencia

del resto de tipos de mantenimiento (especialmente del mantenimiento perfectivo)

en que, mientras que el resto (correctivo, evolutivo, perfectivo, adaptativo.) se

produce generalmente tras una peticin, por parte del cliente o del usuario final, el

preventivo se produce tras un estudio de posibilidades de mejora en los diferentes

mdulos del sistema.


36

Aunque el mantenimiento preventivo es considerado valioso para las

organizaciones, existen una serie de fallas en la maquinaria o errores humanos a

la hora de realizar estos procesos de mantenimiento. El mantenimiento preventivo

planificado y la sustitucin planificada son dos de las tres polticas disponibles

para los ingenieros de mantenimiento.

El primer objetivo del mantenimiento es evitar o mitigar las consecuencias de las

fallas del equipo, logrando prevenir las incidencias antes de que estas ocurran.

Las tareas de mantenimiento preventivo incluyen acciones como cambio de piezas

desgastadas, cambios de aceites y lubricantes, etc. El mantenimiento preventivo

debe evitar los fallos en el equipo antes de que estos ocurran.

Mantenimiento preventivo y correctivo de Software.

El mantenimiento de software o mantencin de software es una de las actividades

ms comunes en la ingeniera de software y es el proceso de mejora y

optimizacin del software despus de su entrega al usuario final as como tambin

correccin y prevencin de los defectos. El mantenimiento de software se divide

en dos: prevenir y corregir.

Algunos de los pasos de prevencin son:

Revisin de Instalacin por Setup.

Desfragmentacin del Disco Duro.

Liberacin de espacio en Disco Duro.

Ejecucin de Antivirus.

Copia de Seguridad.


37

3.4 CICLO DEL PROYECTO Segn Nstor Fernndez Rodrguez; El proyecto es un ciclo articulado y

progresivo que va desde la idea inicial y la intencin de intervenir hasta la

valoracin del conjunto de medios, actividades y resultados de los objetivos

perseguidos.

Entendemos por ciclo de un proyecto, el proceso de principio a fin, o contino de

una accin social programada y llevada a cabo dentro de las actuaciones de las

ONGs. El ciclo est constituido por etapas, fases o momentos sucesivos que se

retroalimentan entre s. Estas fases son identificacin, diseo, ejecucin,

seguimiento, y evaluacin. Aunque su denominacin vara segn los diferentes

autores y organizaciones.

El ciclo de un proyecto debe entenderse en forma de espiral, no en crculo cerrado

que vuelve a su principio, por eso el concepto de proceso continuo y progresivo, lo

define mejor.

A la hora de afrontar la realizacin de un proyecto surge la cuestin de Qu

hacer?, para lo cual debemos tener presente lo que es necesario hacer, lo que

deseamos hacer y lo que es posible hacer.

Donde surge un proyecto.

El proyecto medio del que hablamos, surge en espacios sociales y econmicos en

los que el conjunto de necesidades no slo es grande sino que se siente como tal

es decir, existe un cierto nivel de consciencia de ellas, al tiempo que se intuir, al

menos, que es posible solucionarlas.

Hay una base objetiva de carencias, colectividad necesitada, una dimensin

subjetiva consciencia de la necesidad y de la posibilidad de solucionara; junto a la

disposicin de enfrentar esa tarea.


38

Esa colectividad, por algn mecanismo es frecuente que sea un factor externo o el

anlisis comparado con otro colectivo que ya ha vivido una situacin similar

despierta a la idea de que es posible satisfacer un cmulo de necesidades que,

ordinariamente y por la dinmica normal, no podran ser cubiertas. Tambin es

verdad que, en la actualidad, muchos proyectos estn naciendo y reproducindose

en el seno de las ONGs que bien como agentes intermedios o como instancias de

accin directa, han elaborado y ejecutado proyectos, anteriormente, durante los

ltimos aos y continan con esa va de financiacin externa; plantean tanto

proyectos nuevos como ampliaciones, complementos, mejoras o cambios de lo

que vienen realizando, con lo cual se obviara alguna de las etapas del desarrollo

de un proyecto.

Qu haba antes?

Antes del nacimiento del proyecto, objetivamente, existen en bruto todas las

necesidades y problemas que, posteriormente han de ser la base para el proyecto.

Si bien el hecho de que surja la idea del proyecto presupone una cierta capacidad

organizativa, y en ese sentido el proyecto es primeramente intencin y,

seguidamente, tras una cierta idea de posibilidad, el proyecto se convierte en

finalidad; en cuanto tal, el proyecto moviliza a la colectividad y la aglutina en torno

a la idea y su posible realizacin; se es el inicio del cambio.

Cmo y cundo surge?

Es claro que no surge por generacin espontnea. Es fruto de un proceso en el

que, por lo general, existe la influencia directa o indirecta de un factor externo (en

forma de ideas, personas u otro referente) que activa y estimula la "posibilidad de

hacer algo" para solucionar los problemas.


39

El cundo viene marcado por el tiempo que tarda en penetrar la idea en el

conjunto de personas o responsables que tienen autoridad o peso moral para

hacer la propuesta a la comunidad afectada. La importancia de ese tiempo de

difusin de la idea y la metodologa que se use en la explicacin de lo que se

pretende repercutir en el proceso posterior; cuidando el procedimiento e

induciendo un movimiento de toma de conciencia y racionalidad, suele lograrse un

efecto positivo que asegura la continuidad del mismo.

De cualquier forma el cundo y cmo, podemos decir que es fruto de la toma de

conciencia de la posibilidad y de la decisin conjunta de hacer algo colectivamente

que resulte beneficioso para la solucin de las necesidades.


40

3.5 ESPIRAL

El modelo en espiral, desarrollado durante la dcada de los ochenta, es una

extensin del modelo de cascada. A diferencia del modelo en cascada, que es

dirigido por documentos, el modelo de espiral se basa en una estrategia para

reducir el riesgo del proyecto en reas de incertidumbre, como requerimientos

iniciales incompletos e inestables. El modelo enfatiza ciclos de trabajo, cada uno

de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo

comienza con la identificacin de los objetivos, soluciones alternativas,

restricciones asociadas con cada alternativa y, finalmente, se procede a su

evaluacin. Cuando se identifica incertidumbre, se utiliza diversas tcnicas para

reducir el riesgo de las distintas alternativas. Cada ciclo del modelo de espiral

termina con una revisin que discute los logros actuales y los planes para el

siguiente ciclo. La figura 3.5 muestra un diagrama conceptual del modelo de

espiral.

Figura 3.5 Secuencia de actividades para el modelo de espiral


41

Al igual que el modelo evolucionario, el modelo en espiral incorpora una estrategia

de uso de prototipos como parte del manejo del riego.

Las creencias del modelo de espiral son:

Una actividad comienza cuando se entienden los objetivos y riesgos

involucrados.

Basado en la evaluacin de soluciones alternas, se usan las herramientas que

mejor reduzcan los riegos.

Todo el personal relacionado debe de involucrarse en una revisin que

determine cada actividad, planeando y comprometindose con las siguientes

actividades.

El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos

del producto.

Con algunas variantes, este es el modelo de proceso ms importante en la

actualidad.


42

3.6 EL MODELO EN ESPIRAL

El modelo en espiral, que Boehm [BOE88] propuso originalmente, es un modelo

de proceso de software evolutivo que conjuga la naturaleza iterativa de la

construccin de prototipos con los aspectos controlados y sistemticos del modelo

en cascada. Proporciona el material para el desarrollo rpido de versiones

incrementales de software. Boehm [BOE01] describe este modelo de la siguiente

manera:

El modelo de desarrollo en espiral es un generador del modelo de proceso guiado

por el riesgo que se emplea para conducir sistemas intensivos de ingeniera de

software concurrente y con mltiples usuarios. Tiene dos caractersticas distintivas

principales. Una de ellas es un enfoque cclico para el crecimiento incremental del

grado de definicin e implementacin de un sistema, mientras disminuye su grado

de riesgo. La otra es un conjunto de puntos de fijacin para asegurar el

compromiso del usuario con soluciones de sistema que sean factibles y

mutuamente satisfactorios. Cuando se aplica el modelo en espiral, el software se

desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, la

entrega tal vez sea un documento del modelo o un prototipo. Durante las ltimas

iteraciones se producen versiones cada vez ms completas del sistema

desarrollado.

Un proceso en espiral se divide en un conjunto de actividades del marco de

trabajo que define el equipo de ingeniera de software. Para propsitos ilustrativos

se aprovechan las actividades genricas del marco de trabajo expuestas pginas

atrs. Cada una de las actividades del marco de trabajo representa un segmento

de la ruta en espiral que se presenta en la figura 3.6. Cuando comienza este

proceso evolutivo el equipo de software realiza actividades implicadas en un

circuito alrededor de la espiral que tiene una direccin en el sentido del

movimiento de las manecillas del reloj, y que se inicia desde el centro.


43

El riesgo (capitulo 25) es un factor considerado en cada revolucin. Los puntos de

fijacin, una combinacin de productos de trabajo y condiciones incluidas a lo

largo de la ruta de la espiral, se consideran para cada paso evolutivo. El primer

circuito alrededor de la espiral quiz genere el desarrollo de una especificacin del

producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar

para desarrollar un prototipo y despus, en forma progresiva, versiones ms

elaboradas del software. Cada paso a travs de la regin de planeacin resulta en

ajustes al plan de proyecto. Los costos y el itinerario se ajustan con base en la

retroalimentacin derivada de la relacin con el cliente despus de la entrega.

Adems, el administrador del proyecto ajusta el nmero de iteraciones planeado

que se requiere para completar el software.

A diferencia de otros modelos de proceso que termina cuando se entrega el

software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del

software de computadora. Por lo tanto, el primer circuito alrededor de la espiral

podra representar un proyecto de desarrollo del concepto, el cual se inicia en el

centro de la espiral y contina en la siguiente fase de la espiral y comienza un

proyecto de desarrollo de un producto nuevo, el nuevo producto evolucionara a

travs de un nmero de iteraciones alrededor de la espiral. Despus, un circuito

alrededor de la espiral se podra emplear para representar un proyecto de

mejoramiento del producto. En esencia, la espiral, cuando se caracteriza de esta

forma, permanece operativa hasta que el software se retira. En ocasiones el

proceso est inactivo, pero siempre que se inicie un cambio de proceso comienza

en el punto de entrada apropiado (por ejemplo, mejoramiento del producto).


44

El modelo en espiral es un enfoque realista para el desarrollo de software y de

sistemas a gran escala. Como el software evoluciona conforme avanza el proceso,

el desarrollador y el cliente entiende y racionan de mejor manera ante los riesgos

en cada etapa evolutiva. El modelo en espiral emplea la construccin de prototipos

como un mecanismo encaminado a reducir riesgos pero, en forma ms

importante, permite al desarrollador la aplicacin del enfoque de la construccin de

prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque

sistemtico de los pasos que sugiere el ciclo de vida clsico, pero lo incorpora al

marco de trabajo iterativo que refleja de forma ms verdica el mundo real. El

modelo en espiral exige una consideracin directa de los riesgos tcnicos en todas

las etapas del proyecto y, si se aplica en forma apropiada. Debe reducir los

riesgos antes de que se vuelvan problemticos.

Figura 3.6 Un modelo en espiral tpico


45

3.7 EL MODELO EN ESPIRAL II

El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo

de proceso de software evolutivo que acompaa la naturaleza interactiva de

construcciones de prototipos con los aspectos controlados y sistemticos del

modelo lineal secuencial. Se proporciona el potencial para el desarrollo rpido de

versiones incrementales del software. En el modelo espiral, el software se

desarrolla en una serie de versiones incrementales podra ser un modelo en papel

o un prototipo. Durante las ltimas iteraciones, se proceden versiones cada vez

ms completas de ingeniera de software.

El modelo en espiral se divide en un nmero de actividades estructurales, tambin

llamadas regiones de tareas; Generalmente, existen entre tres y seis regiones de

tareas. La figura 2.8 representa un modelo en espiral que contienen seis regiones

de tareas:

Comunicacin con el cliente- las tareas requeridas para establecer

comunicacin entre el desarrollo y el cliente.

Planificacin- las tareas requeridas para definir recursos, el tiempo y otras

informaciones relacionadas con el proyecto.

Anlisis de riesgo- las tareas requeridas para evaluar riesgos tcnicos y de

gestin.

Ingeniera- las tareas requeridas para construir una o ms representaciones de

la aplicacin.

Construccin y adaptacin- las tareas requeridas para construir, probar,

instalar y proporcionar soporte al usuario (por ej.: documentacin y prctica).

Evaluacin del cliente-las tareas requeridas para obtener la reaccin del cliente

segn la evaluacin de las representaciones del software creadas durante la

etapa de ingeniera e implementada durante la etapa de instalacin.


46

Cada una de las regiones estn pobladas por una serie de tareas que se adaptan

a las caractersticas del proyecto que va a emprenderse. Para proyectos

pequeos, el nmero de tareas y su formalidad es bajo. Para proyectos mayores y

ms crticos, cada regin contiene tareas que se definen para lograr un nivel ms

alto de formalidad. En todos los casos, se aplican las actividades de proteccin

(p.ej.: gestin de configuracin de software y garanta de calidad de software)

mencionadas en la seccin 2.2.

Figura 3.7 Un modelo en espiral tpico


47

3.8 PLANIFICACIN DE UN PROYECTO DE INGENIERA DE SOFTWARE.

La planificacin involucra la especificacin de objetivos, metas para un proyecto,

las estrategias, polticas, planes y procedimientos para alcanzarlos.

Todo proyecto de ingeniera de software debe partir con un buen plan. La

planificacin es necesaria por la existencia de incertezas sobre el ambiente del

proyecto software y sobre fuentes externas. La planificacin enfoca su atencin en

las metas del proyecto, riesgos potenciales y problemas que puedan interferir con

el cumplimiento de esas metas.

Los principales problemas en la planificacin de un proyecto de ingeniera de

software incluyen los siguientes:

Requerimientos incorrectos e incompletos.

Muchas especificaciones de requerimientos son inestables y sujetas a cambios

mayores.

La planificacin no se lleva a cabo por la creencia errnea de que es una

prdida de tiempo y los planes cambiarn de todos modos.

La planificacin de costos y plazos no es actualizada y se basa en necesidades

de mercadeo y no de los requerimientos del sistema.

Es difcil estimar el tamao y complejidad del proyecto de software de modo de

realizar una estimacin de costos y plazos realista.

Los costos y plazos no son reestimados cuando los requerimientos del sistema

o el ambiente de desarrollo cambia.

No se manejan factores de riesgo.

La mayora de las organizaciones de desarrollo de software no recolectan

datos de proyectos pasados.

Las compaas no establecen polticas o procesos de desarrollo de software.

Ciclo de Vida del Software.


48

CICLO DE VIDA DEL SOFTWARE

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se

mueve un proyecto de desarrollo de software.

El primer ciclo de vida del software, Cascada, fue definido por Winston Royce a

fines del 70.

Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin

embargo, ya desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a

numerosas crticas, debido a que es restrictivo y rgido, lo cual dificulta el

desarrollo de proyectos de software. En su lugar, muchos modelos nuevos de ciclo

de vida han sido propuestos, incluyendo modelos que pretenden desarrollar

software ms rpidamente, ms incrementalmente o de una forma ms evolutiva,

y precediendo el desarrollo a escala total con algn conjunto de prototipos rpidos.

DEFINICIN DE UN MODELO DE CICLO DE VIDA

Un modelo de ciclo de vida de software es una visin de las actividades que

ocurren durante el desarrollo de software, intenta determinar el orden de las

etapas involucradas y los criterios de transicin asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo.

Provee un espacio de trabajo para la definicin de un detallado proceso de

desarrollo de software.


49

As, los modelos por una parte suministran una gua para los ingenieros de

software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por

otra parte suministran un marco para la administracin del desarrollo y el

mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de

control intermedios, monitorear el avance, etc.

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida.

En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno

completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo

ejecutado, puedes seguir estos cuatros pasos:

1. Determinar qu se quiere lograr.

2. Determinar las rutas alternativas que se pueden tomar para lograr estas metas.

Por cada una, analizar los riesgos, resultados finales y seleccionar la mejor.

3. Seguir la alternativa seleccionada en el paso 2.

4. Establecer qu se tiene terminado.

La dimensin radial en la figura refleja costos acumulativos incurridos en el

proyecto.

Observemos un escenario particular. Digamos que en este proyecto, nosotros

viajaremos a resolver un conjunto particular de problemas del cliente. Durante el

primer viaje alrededor de la espiral, analizamos la situacin y determinamos que

los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis

de las formas alternativas de direccionar esto (por ejemplo, construir un sistema,

esperar lo mejor, escribir una especificacin de requerimientos, esperar que el

cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de

accin es construir un prototipo.


50

Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con

retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la

espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos

nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea

desplegado. Analicemos las rutas alternativas, y decidimos que la mejor

aproximacin es construir un incremento del sistema que satisfaga slo los

requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el

cliente nos provee de retroalimentacin que dir si estamos correctos con esos

requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas

de los clientes. Y el tercer viaje alrededor de la espiral comienza.

El modelo espiral captura algunos principios bsicos:

Decidir qu problema se quiere resolver antes de viajar a resolverlo.

Examinar tus mltiples alternativas de accin y elegir una de las ms

convenientes.

Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer

algo.

No ser tan ingenuo para pensar que el sistema que ests construyendo ser

EL sistema que el cliente necesita, y conocer (comprender) los niveles de

riesgo, que tendrs que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son

completamente compatibles (Marcela Varas c. 2000).


51

Captulo 4

Desarrollo del proyecto


52

INTRODUCCIN

En este captulo se toma en cuenta todo lo referente al diseo del manual de

operacin o del soporte tcnico que contendr los checklist, se podr apreciar el

avance o las modificaciones que se vayan requiriendo dependiendo de las

necesidades del usuario, considerada la necesidad, oportunidad, viabilidad del

proyecto expuesto, y definido del equipo profesional que se ocupar de su puesta

en marcha, se inicia el desarrollo del proyecto; Exponiendo las actividades o

herramientas ms importantes que van a facilitar dicho desarrollo, ya que est

basado en la metodologa en espiral por ello se plasman las cuatro fases de ciclo

de vida de esta metodologa como lo es el Anlisis, Diseo, Implementacin y

Pruebas.


53

4.1 FASE DE ANALISIS

1. IDENTIFICACIN DE LAS NECESIDADES: Se inicia con el reconocimiento

de una necesidad, un problema o una oportunidad y termina con la emisin de una

solicitud de propuesta, con la finalidad de mejorar la condicin existente,

realizando las siguientes actividades:

Plan de accin

Vase en Capitulo II (2.2 PLAN DE ACCION).

Obtencin de requerimientos

Para la obtencin de requerimientos del proyecto se utilizaran dos tcnicas de

obtencin de requerimientos las cuales son la sesin de facilitacin y el prototipo.

SESIN DE FACILICITACION

Se realiz mediante la presentacin del proyecto con sus objetivos establecidos y

con las respectivas responsabilidades en las que consista el mismo, en donde se

obtuvieron los siguientes.


54

Requerimientos:

1. El nombre del proyecto quedo como Soporte Tcnico.

2. El manual de operacin deber ser en digital en formato PDF.

3. Los formatos checklist tomaran el nombre de checklist de soporte tcnico.

4. Los formatos checklist debern de estar ordenados alfabticamente y

acomodados en el manual respecto al mantenimiento correspondiente ya sea

correctivo o preventivo.

5. Los formatos o checklist debern estar presentables y con formalidad por lo

cual se establece que utilicen los logos correspondientes a la SEGOB, con una

fuente arial 12, los ttulos en maysculas y negrita.

6. Los formatos de checklist debern de contener el nombre del rea

responsable, unidad administrativa, usuario, adems de atendido por, y la firma

del usuario de conformidad.

7. Los formatos checklist debern tener un ttulo que los identifique que tipo de

mantenimiento si es correctivo o preventivo.

8. Los formatos checklist deben de contener un folio en blanco ya que

depender del folio del reporte de soporte tcnico.

9. Los formatos debern contener el tipo de solucin a la que se refiere con un

ttulo en arial 12 maysculas y negritas subrayado.

PROTOTIPO

En el transcurso de la sesin de facilitacin se desarrollaron varios formatos a

lpiz para determinar cul sera el ms apropiado, mostrando a continuacin el

transcurso de estos:


55


56


57


58

Riesgos del proyecto

Fuentes de Riesgos

Riesgos asociados al Cliente y/o Usuario

1. Requerimientos (requisitos) confusos / incompletos

2. Cambios frecuentes a los requerimientos (requisitos) del proyecto durante la

ejecucin del mismo.

3. No tener expectativas realistas sobre los resultados del proyecto por parte del

usuario.

Riesgos asociados a los calendarios

1. Estimaciones no precisas del tiempo de desarrollo del proyecto.

2. Tiempo de entrega no establecido.

Riesgos asociados al Proceso de Administracin de Proyectos

1. Cliente inconforme con el diseo.

2. Retraso en el cumplimiento de las actividades a desarrollar.

3. No tener expectativas realistas sobre los resultados del proyecto por parte del

usuario.

4. Mucho tiempo establecido en algunas actividades a desarrollar.

Validacin de riesgos

Los riesgos que se presentaron fueron el de la mala estimacin del tiempo en el

desarrollo del proyecto y el del tiempo de entrega no establecido.


59

4.2 FASE DE DISEO

DISEO DE UNA PROPUESTA DE SOLUCIN: Esta etapa comienza una vez

identificada la necesidad, en la que se lleva a cabo un proceso de preparacin de

propuestas y los elementos que podran ser incluidos en esta misma para poder

llegar a un acuerdo con el cliente, realizando las siguientes actividades:

Anlisis para desarrollar checklist

La obtencin de requerimientos sirvi para determinar que el uso de los checklist

son viables para el rea de soporte tcnico de la SEGOB, porque se logr

implementarlo al reporte de soporte tcnico ya establecido, este una vez que el

usuario solicite el servicio de soporte tcnico es llenado, seguido de el diagnostico

que da el usuario de soporte tcnico, se implementara despus el checklist

obteniendo una solucin ms rpida. Los usuarios del rea de soporte llegaron a

la conclusin de que se repeta informacin en el reporte y checklist por lo que

analice, era verdad llegue a la conclusin de que se tendra que eliminar el

requerimiento de los formatos de checklist debern de contener el nombre del

rea responsable, unidad administrativa y el rea.

Diseo de formato de reporte y checklist de soporte tcnico.


60


61


62

3. DESARROLLO DEL PROYECTO: Esta fase se conforma por dos partes,

siendo la primera la planeacin detallada y por ltimo, hay que ponerlo en prctica;

la planeacin debe mostrar cmo se realizaran las tareas dentro del presupuesto y

en el tiempo sealado, en s, la planeacin determina lo que se necesita hacer,

quien lo har, cunto tiempo se necesitara y cuanto costara, realizando las

siguientes actividades:

Actividades comunes (formatos checklist): a continuacin se muestran los

formatos o checklist ms comunes en el rea de soporte tcnico.

1. Activacin de paquetera de office 2010.

2. Actualizacin de Nod32 v3.

3. Cambiar la memoria RAM del ordenador.

4. Compartir impresora en red.

5. Desactivar el reinicio automtico.

6. Desfragmentar disco fijo o disco duro.

7. Formatear una computadora con xp.

8. Instalacin de antivirus.

9. Instalacin de impresora.

10. Instalacin de Microsoft office 2010.

11. La impresora no imprime y no manda mensaje de error.

12. Liberar espacio de disco.

13. Limpieza de pantalla de laptop.

14. Mantenimiento de laptop.

15. Respaldo de informacin.


63

4.3

CHECKLIST DE SOPORTE

TCNICO

Folio:

ACTIVACION DE PAQUETERIA DE OFFICE PROFESSIONAL PLUS 2010

1. Debes de ejecutar el archivo: "Mini-KMS_Activator_v1.2_Office2010_VL_ENG.exe".Nota: Si usas algn sistema operativo como: Vista o Seven, ejectalo como Administrador.

2. Selecciona Install / Unistall KM servicio, despus en la ventana negra que aparece: *Si sale Install tienen que instalarlo con la tecla Y.*Si sale Remover quiere decir que ya est instalado. Presionar tecla N.

3. Despus selecciona Active Office 2010 VL. Presionar tecla Y hasta que aparezca el mensaje de 180 das. Si aparece error, salir de la ventana CMD y hacer clic en: * REARM Office 2010.

4. Despus nuevamente presiona la tecla Y para restablecer nuestro periodo Trial. Luego intentar de nuevo la opcin 3.

5. Para finalizar seleccionamos Comprobar la activacin (Activacin Check office 2010), ah podremos observar por cuanto tiempo est activado nuestro producto.

Mantenimiento Preventivo

Atendido por: Firma de conformidad del

usuario


64


TCNICO

Folio:

ACTUALIZACION DE NOD32 V3

1. Ingresa a www.for-ever.cn/nod32 esta pgina nos proporciona nombres de usuarios y contraseas vlidos para actualizar nuestro antivirus, esta pgina muestra las validas en color verde y las rojas las ya caducas adems de que se va actualizando las claves diarias.

2. Abrimos nuestro antivirus, una vez abierto apretamos F5 el cual se abrir la ventana de configuraciones de nuestro antivirus.

3. hacemos clic en la opcin que dice actualizacin, debemos de verificar el servidor de actualizacin este seleccionado: "seleccin automtica" y en los campos de nombre de usuario debemos de copiar y pegar de la pgina anterior un nombre de usuario con su respectiva contrasea.

4. ahora hacemos clic en aceptar. nos dirigimos de nuevo a la ventana principal del antivirus, hacemos clic en actualizacin, luego en actualizacin manual de la base de firmas.

5. si todo sali bien el proceso de actualizacin continuara hasta llegar a actualizarse y estar en proteccin completa.



usuario


65


TCNICO

Folio:

CAMBIAR LA MEMORIA RAM DE UN ORDENADOR

1. Debemos de identificar la memoria que utiliza nuestro PC y tras adquirirla.

2. Apagar por completo el ordenador.

3. Desconectar el cable de fuente de alimentacin y pulsar un par de veces el botn de encendido del PC para terminar de descargar la posible corriente que pudiese quedar en la placa base. 4. Localizar los tornillos que sujetan la carcasa de la caja del ordenador. Quitarlos y retirar las carcasas para dejar a la vista el interior del PC.

5. Una vez tenemos visible la placa base, lo primero es localizar dnde est situada la memoria RAM en nuestro PC. 6. Para extraer la memoria de nuestro ordenador simplemente pulsaremos en los extremos del zcalo dnde est montada la memoria y el mdulo saldr del mismo. 7. Colocaremos los nuevos mdulos de memoria teniendo cuidado de hacer coincidir la ranura que posee.

8. Volver a colocar la tapa de la carcasa de la torre.

9. Conectar la corriente de la fuente de alimentacin.

10. Encender el PC y comprobar que todo funciona.* Si todo ha funcionado el ordenador debera hacer un 'bip' al momento de encender (seal de que todo est bien).

Mantenimiento Correctivo

Atendido por: Firma de conformidad del usuario


66


TCNICO

Folio:

COMPARTIR IMPRESORA EN RED

1. Abrir el men inicio y seleccionar la opcin dispositivos e impresoras. 2. Aparecer una lista con todas las impresoras instaladas en el sistema. Slo hay que hacer clic secundario sobre la impresora que se desea compartir y seleccionar la opcin propiedades de impresora. 3. Hacer clic en la pestaa compartir y luego hacer clic en la accin compartir esta impresora. 4. Dar clic en el botn aceptar para guardar los cambios.Desde este momento todos los equipos que pertenezcan a la red sern capaces de ver la impresora compartida y utilizarla desde cualquier aplicacin que permita imprimir documentos.


usuario

Mantenimiento


67


TCNICO

Folio:

DESACTIVAR EL REINICIO AUTOMTICO

Nota: Para que el PC no se reinicie solo, a veces nicamente se necesita una sola accin, pero no siempre es eficaz:

1. Ve al men Inicio, luego Panel de control luego Rendimiento y mantenimiento y finalmente Sistema (o haz clic derecho en Mi PC y selecciona Propiedades).

2. Haz clic en la pestaa Opciones avanzadas.

3. En Inicio y recuperacin Haz clic en Configuracin.

4. Desmarca Reiniciar automticamente.

Nota: Esta operacin siguiente slo es vlida para Windows XP!

1. Haz clic en el botn Inicio.

2. Haz clic en Ejecutar.

3. Escribe "shutdown -a".

4. Haz clic en Aceptar.



usuario


68

DESFRAGMENTAR DISCO FIJO O DISCO DURO

1. Damos clic en la barra de inicio, despus damos clic en todos los programas.

2. Sale un men despus de haber dado clic en todos los programas, damos clic en accesorios y despus en herramientas del sistema.

3. Damos clic donde diga desfragmentar disco.

4. Una vez ya abierto el desfragmentador de disco.

5. Despus damos clic en analizar una vez ya analizado aparecer una ventana en donde te da tres opciones:

1. Presentar informes. 2. Desfragmentar. 3. Cerrar.

6. Damos clic en desfragmentar y empieza a desfragmentar el volumen que elegimos.

1. Sale un dialogo en el que se ha completado la desfragmentacin y salen dos opciones:

1. Presentar informes: En este sale la informacin del volumen desfragmentado.

2. Cerrar: Se cierra la ventana.

Nota: Esto sirve para que se agilice el funcionamiento de la computadora y los archivos y documentos ocupen menos espacio, as funcionando ms rpido el equipo.


Firma de conformidad del usuario

Atendido por:

Folio:


TCNICO


69


TCNICO

Folio:


FORMATEAR UNA COMPUTADORA CON WINDOWS XP

1. Preparacin Previa necesitaremos:* Drivers de la computadora, que se pueden conseguir en la pgina del fabricante (puede usarse algn programa para hacer un respaldo de los drivers antes de formatear, como Driver Magician).*Disco de Instalacin de Windows XP.*Nmero de serie de Windows XP (apuntalo en un papel o mantenlo a la mano).*Tiempo (unas 2 horas).NOTA: No olvides hacer un respaldo de toda tu informacin importante (Tareas, trabajos, msica, etc.) ya que todo se perder.

2. Empezando, con la computadora encendida: Insertamos el cd de Windows XP, y reiniciamos la computadora. * Si es una laptop, nos fijamos en la pantalla mientras sale el logo de la marca de la laptop, y buscamos una opcin similar a: "Seleccionar dispositivo de arranque ese texto nos dir que tecla oprimir (en el caso de una Toshiba es F12), la oprimimos mientras an se pueda ver esa frase, en caso de que se nos pase, esperamos a que inicie Windows y reiniciamos de nuevo.* En el caso de una computadora de escritorio, mientras inicia buscamos el texto "Press XXXX to enter Setup" o algo similar, y presionamos la tecla o combinacin de teclas.* Dentro de la pantalla que va a salir tendremos cuidado de no mover ms que las opciones de arranque, y haremos que iniciar desde CD/DVD est en primer lugar, seguido del disco duro (HDD).

3. Seleccionar Iniciar desde CD/DVD. 4. Presionar una tecla (la que sea) para que empiece a cargar el cd.* Una vez que empieza a cargar el cd saldr una pantalla azul cargando diversos componentes, esperamos a que aparezcan las instrucciones.


70



TCNICO

Folio:

5. Presionamos la tecla Enter para instalar Windows.

6. Presionamos la tecla F8 para aceptar la licencia.

7. Volvemos a presionar la tecla Enter.* La siguiente pantalla es la de las particiones, si es una computadora con el Disco Duro de fbrica, tendr 2 particiones; 1 de recuperacin y otra para Windows y tus datos.* Si quieres restaurar la computadora a como vino de fbrica, ser mejor que consultes el manual, pero si quieres una instalacin limpia, sin tantos programas de prueba y de la marca de tu computadora, sigue adelante.* Borra todas las particiones que no te sean tiles, tal vez desees guardar la de recuperacin o donde tengas tu informacin, pero mnimo hay que borrar la de Windows, usualmente C:

8. Selecciona la particin a borrar y oprime la tecla D y luego la L. 9. Presiona Enter en caso de que te lo indique.* Despus de esto regresaremos a la pantalla con las particiones, repetimos los pasos 8 y 9 en caso de querer eliminar ms particiones.

10. Seleccionamos el espacio no particionado y presionamos C 11. Tecleamos el tamao que queremos para la particin, por defecto escribe todo el tamao disponible, pero podemos modificarlo a nuestro gusto.

12. Presionamos la tecla Enter.*Seleccionamos la particin que acabamos de crear y oprimimos

1. reporte estadia cdgs

Documents