You are on page 1of 42

[ E s c r i b a l a d i r e c c i n d e l a c o m p a a ]

[Ttulo]
Richard Parker
[Escriba aqu una descripcin breve del documento. Normalmente, una descripcin breve es
un resumen corto del contenido del documento.]
Fall
16
Introduccin a la ingeniera del software y sistemas de informacin

1.1. Conceptos de Ingeniera del Software: mitos, paradigma, ingeniera de software,
calidad, proceso, mtodo, herramienta, espectro de gestin.
1.2. La importancia de la ingeniera del software.
1.3. Historia de la Ingeniera del Software.
1.4. Los sistemas de informacin: concepto, caractersticas, estructuras, procesos,
clasificacin, ERPs, CRM, SCM.

Modelos de la ingeniera del software

2.1. Modelo de capacidad de madurez.
2.2. Marco de trabajo para el proceso.
2.3. Modelos de la ingeniera del software: modelo de cascada, modelo de prototipos,
modelo de espiral, modelo de Proceso Unificado Racional (RUP).
2.4. Tendencias modernas de modelos de la ingeniera del software.

Planificacin del proyecto de software

3.1. Aplicacin de herramientas para estimacin de tiempos y costos de desarrollo de
software: GANTT, PERT/CPM, uso de software para la estimacin de tiempos y costos.
3.2. mbito del software: recursos humanos, recursos de software reutilizables, recursos
del entorno.
3.3. Anlisis y gestin del riesgo: estrategias, identificacin, proyeccin, refinamiento,
reduccin, supervisin y gestin del riesgo.

Anlisis del proyecto de software

4.1. Modelado: anlisis, diseo, documentacin.
4.2. Construccin: codificacin, pruebas y evaluacin, manual del usuario, manual tcnico.
4.3. Medida, mtrica e indicador.
4.4. Tipos de mtricas: mtricas de proceso, mtricas de proyecto, mtricas orientadas a
punto de funcin, mtricas orientadas al tamao, mtricas para la calidad del software.
4.5. Implementacin y mantenimiento: entrega, retroalimentacin del cliente.

Calidad del software

5.1. Definicin de calidad y calidad del software.
5.2. Importancia de la calidad.
5.3. La calidad y la globalizacin.
5.4. Aseguramiento de la calidad del software (SQA): definicin y propsito del SQA,
problemas que resuelve el SQA, roles y responsabilidades de los equipos de desarrollo,
habilidades y capacidades del personal del SQA, Actividades del SQA.
5.5. Derecho informtico aplicado al software: piratera y falsificacin, autora y creacin,
contratos y licencias.

Introduccin a la ingeniera del software
y sistemas de informacin

1.1. Conceptos de Ingeniera del Software: mitos, paradigma,
ingeniera de software, calidad, proceso, mtodo, herramienta,
espectro de gestin.

La ingeniera de software es una disciplina formada por un conjunto de mtodos,
herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos
(software).

Esta disciplina trasciende la actividad de programacin, que es la actividad principal a la
hora de crear un software. El ingeniero de software se encarga de toda la gestin del
proyecto para que ste se pueda desarrollar en un plazo determinado y con el
presupuesto previsto.

La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el diseo
del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementacin del sistema.

Los Ingenieros de Software deben:

- Adoptar un enfoque sistemtico para llevar a cabo su trabajo.
- Utilizar las herramientas y tcnicas apropiadas para resolver el problema
planteado, de acuerdo a las restricciones de desarrollo y a los recursos
disponibles.




MITO

Mito del cliente:
Mito.- Una declaracin superficial de los objetivos es suficiente para empezar a escribir
los programas.
Realidad.- La mala definicin inicial es la principal causa de baja calidad.Se requiere un
conocimiento formal y detallado de los hechos y procesos y amplia comunicacion con el
cliente.

Mitos de los Desarrolladores.
Mito.- Lo nico que se entrega al terminar el proyecto es el programa funcionando.
Realidad.- El software funcionando es solo una parte de una CONFIGURACION DE
SOFTWARE.

La documentacin es la base de un buen desarrollo y guis para las tareas de
mantenimiento.

Paradigma: La ingeniera de software surge de la ingeniera de sistemas y de hardware.
Abarca un conjunto de tres elementos que facilitan el control sobre el proceso de
desarrollo de software y suministran las bases para construir software de calidad de una
forma productiva:
- Mtodos
- Herramientas
- Procedimientos

Mtodos que indican cmo construir el software tcnicamente e incluyen un amplio
espectro de mtodos para la planificacin, la estimacin, el anlisis, el diseo,
codificacin, prueba y mantenimiento.
Herramientas automticas y semiautomticas que apoyan a la aplicacin de los mtodos.

Cuando se integran las herramientas de forma que la informacin creada por una
herramienta puede ser usada por otra, se establece un sistema para el soporte del
desarrollo de software, llamado Ingeniera de Software Asistida por Computadora ( CASE
).

Procedimientos que definen la secuencia en la que se aplican los mtodos, las entregas,
los controles de calidad y guas para evaluacin del progreso.


Ingeniera
Es la profesin en la que el conocimiento de las ciencias naturales y matemticas
obtenidos con el estudio, la prctica y la experiencia se aplica con juicio para desarrollar
formas de utilizar de modo econmico, los materiales y fuerzas de la naturaleza para
beneficio de la humanidad

Software
Es el conjunto de todos los programas que existen dentro de una computadora. Es el
producto del desarrollo que realizan los ingenieros de software resultado de
requerimientos de informacin.

La Ingeniera de Software
Es una disciplina de la Ingeniera que comprende todos los aspectos de la produccin del
software desde las etapas iniciales de la especificacin del sistema hasta el
mantenimiento de ste despus de que se libera.

La Ingeniera de Software incluye:
- Personas (quin lo hace)
- proceso (la manera en que se hace)
- proyecto (la realizacin)
- producto (la aplicacin de artefactos)

Calidad: Algunas caractersticas de calidad fundamentales en todo producto de
programacin son : utilidad, claridad, confiabilidad, eficiencia y economa.

Proceso: Conjunto de actividades que conducen a la creacion de un producto de
software. Depende de personas que toman desiciones y juicios.

- No existe proceso ideal
- Para los sistemas criticos se requiere un proceso de desarrollo muy estructurado
- Para los sistemas de negocio con requerimientos rapidamente cambiantes,un
proceso flexible y agil probablemente sea mas efectivo.

Metodo: Estructurado para el desarrollo de software,facilita la produccion de software de
alta calidad de una forma costeable.No existe un metodo ideal.

Herramienta: En los cursos de ingeniera de software se utilizan varias herramientas de
desarrollo y gestin para mejorar la produccin de software. Estas cubren distintas
actividades del ciclo de desarrollo: requerimientos, diseo, construccin, pruebas, SQA,
SCM.

Cuando se integran las herramientas de forma que la informacin creada por una
herramienta puede ser usada por otra, se establece un sistema para el soporte del
desarrollo de software, llamado Ingeniera de Software Asistida por Computadora (CASE).

1.2. La importancia de la ingeniera del software.

Producir software costeable es esencial para el funcionamiento de la economa nacional e
internacional.
Este es abstracto e intangible. No esta restringido por materiales, o gobernado por leyes
fsicas o por procesos de manufactura. Esto simplifica la ingeniera de software ya que no
existen limitaciones fsicas del potencial del software.

Sin embargo, esta falta de restricciones naturales significa que el software puede llegar a
ser extremadamente complejo.

Hemos desarrollado mtodos efectivos de especificacin, diseo e implementacin del
software. Las nuevas notaciones y herramientas reducen el esfuerzo requerido para
producir sistemas grandes y complejos.
Los ingenieros de software pueden estar orgullosos de sus logros. Sin software complejo
no habramos explorado el espacio, no tendramos Internet y Telecomunicaciones
modernas, y todas las formas de viajar serian ms peligrosas y caras. Dicha ingeniera ha
hecho enormes contribuciones en su corto periodo de vida.

1.3. Historia de la Ingeniera del Software.

Desde sus inicios en la dcada de 1940, escribir software ha evolucionado hasta
convertirse en una profesin que se ocupa de cmo crear software y maximizar su
calidad. Surgimiento como una profesin: A principios de los 1980, la ingeniera del
software ya haban surgido como una genuina profesin, para estar al lado de las ciencias
de la computacin y la ingeniera tradicional.

El papel de la mujer: en las dcada de los aos 1940, 1950 y 1960, a menudo los
hombres llenaron los roles ms prestigiosos y mejor pagados en la ingeniera de
hardware, pero a menudo delegaron la escritura de software a las mujeres. Grace Murray
Hopper, Jamie Fenton y muchas otras mujeres annimas llenaban muchos trabajos de
programacin durante las primeras dcadas de la ingeniera de software.
Costo de hardware: el costo relativo del software versus el hardware ha cambiado
sustancialmente en los ltimos 50 aos. Cuando los mainframes eran costosos y
requeran una gran cantidad de personal se soporte, las pocas organizaciones que los
compraban tambin tuvieron los recursos para financiar proyectos de ingeniera de
software a la medida, grandes y costosos.
El mercado ms grande puede soportar grandes proyectos para crear software
comercialmente, como los hechos por empresas como Microsoft. Las mquinas baratas
permiten a cada programador tener un terminal capaz de una compilacin bastante
rpida.

1.4. Los sistemas de informacin: concepto, caractersticas,
estructuras, procesos, clasificacin, ERPs, CRM, SCM.

Concepto: Un sistema de informacin es un conjunto de recursos humanos, materiales,
financieros, tecnolgicos, normativos y metodolgicos, organizado para brindar, a quienes
operan y a quienes adoptan decisiones en una organizacin, la informacin que requieren
para desarrollar sus respectivas funciones.

Un sistema de informacin no requiere necesariamente el uso de la tecnologa de
computacin. Ha habido sistemas de informacin antes de que se crearan las
computadoras.

Caracteristicas:
- Variedad en la presentacion,disponibilidad de informacion,
- informacion selectiva,
- tiempo de respuesta,
- generalidad,
- seguridad,
- exactitud.
- flexibilidad,
- Amigabilidad.

Estructuras: Usando esta orientacin de producto, un sistema de informacin se puede
representar como una estructura jerrquica de cuatro niveles:

- NIVEL 1 representacin general del sistema (el producto).
- NIVEL 2 representa los subsistemas contenidos dentro del sistema. Cada
subsistema es un proceso del negocio para recoger, almacenar y recuperar datos
dentro de un perodo de tiempo especfico (por demanda).
- NIVEL 3 representa los procedimientos necesarios para implementar cada
subsistema
- NIVEL 4 representa los pasos necesarios para poner cada procedimiento en
ejecucin.

Procesos: Conjunto estructurado de actividades requeridas para desarrollar un sistema
de software.
Especificacin- que debe hacer el software y cuales son sus especificaciones de
desarrollo.
Desarrollo produccion del sistema de software.

Validacin verificar que el software hace lo que el cliente pide.

Evolucin cambiar/adaptar el software a las demandas.

Confiable: Los errores del proceso son descubiertos antes de que se conviertan en
errores del producto

Robusto: Puede continuar el proceso a pesar de problemas inesperados

Mantenible: Puede el proceso evolucionar para cumplir con los objetivos
organizacionales

Rapidez: Que tan rpido puede producirse el sistema ?.

Entendible: Se encuentra el proceso bien definido y es entendible ?.

Visible: El proceso es visible al exterior ?.

Soportable: Puede el proceso ser soportado por herramientas CASE ?.

Aceptable: El proceso es aceptado por aquellos involucrados en el ?.

Clasificacion: Esta funcin consiste en identificar los datos, agruparlos en conjuntos
homogneos, y ordenarlos teniendo en cuenta la manera en que ser necesario
recuperarlos.

El almacenamiento de datos en archivos computadorizados dispone de tcnicas que han
permitido alcanzar un elevado nivel de refinamiento en este sentido.

ERP: corresponden a Enterprise Resource Planning (Planificacin de Recursos
Empresariales) constan de una serie de mdulos que se pueden adquirir o no, en funcin
de las necesidades exactas que tengamos en nuestra organizacin.

Suele ser habitual que estos mdulos estn personalizados por sector productivo.

Excepto en el caso en que optemos por un desarrollo a medida interno del ERP (que no
suele ser muy frecuente), el ERP ser un producto estndar cuya adaptacin a cada
organizacin se realizar en un proceso conocido como parametrizacin.

CRM:Las siglas CRM, se trata de la gestin de las relaciones con los clientes,Customer
Relationship Management . Todo proceso de una empresa debera estar enfocado a la
venta de un determinado producto.

De esta forma, el concepto CRM define una estrategia de organizacin enfocada a la
satisfaccin de las necesidades del cliente.

SCM:Software Configuration Management (SCM) Gestin de configuracin de software
es una especializacin de la Gestin de configuracin a todas las actividades en el sector
del desarrollo de software.

Conjunto de actividades tendientes a :
Identificar un cambio.
Controlar un cambio.
Asegurar la correcta implementacin.
Comunicar los cambios realizados.
Por que es necesario usar SCM? :
Cambios en el negocio dictan cambios en requisitos.
Nuevas necesidades de informacin para funcionalidades existentes.
Reduccin o ampliacin del negocio provoca cambios en prioridades o integrantes
del proyecto.
Cambios presupuestarios imponen redefinir en producto/proyecto.
Se puede clasificar en:
Cdigo fuente
Datos
Documentacin

Debe proporcionar informacin sobre:
Tipo de elemento
Proyecto al que pertenece
Versin
Cdigo fuente
Datos
Documentacin

Lneas de base:

Punto de inicio para la evolucin controlada del software.
Solo se incorporan productos del trabajo luego de la revisin y aprobacin de los
mismos.
Puede cambiarse solamente a travs de procedimientos formales.
Generalmente constituye un milestone.
La Planificacin de SCM Define:
Marco de desarrollo del proceso.
Alcance.
Actores.
Responsabilidades.
Estndares.
Herramientas.

Proceso SCM, define tareas con objetivos concretos:

Identificar elementos de la configuracin.
Controlar los cambios.
Controlar las versiones.


Modelos de la ingeniera del software

2.1. Modelo de capacidad de madurez.

ste corresponde a uno de los modelos ms conocidos creado por el SEI (Software
Engineering Institute) de la Carnegie Mellon University. El CMM pretende conseguir
mejorar la calidad del software mejorando la calidad de los procesos utilizados en su
desarrollo. "Las herramientas y las plataformas cambian de forma continua. Pero siempre
podemos usar el mismo proceso si ste est bien definido y se sabe utilizar de forma
adecuada."
Niveles de madurez:

El primer nivel (Caos) se produce cuando en la empresa no existe ningn modelo y que
todo se hace sobre la marcha es decir no se emplea ningn proceso definido.

En el segundo nivel (Repetible) se encuentran las empresas en las que existe
planificacin y seguimiento de proyectos y est implementada la gestin de los mismos.

El tercer nivel (Definido) documenta y normaliza los procesos a nivel organizativo. Las
claves de este nivel son la gestin de los requisitos, planificacin de proyectos y su
seguimiento a travs de toda la organizacin

El cuarto nivel (Medible) pone nfasis en la calidad del proceso y del producto. Lo tienen
las empresas capaces de medir el estado de un proyecto y utilizar esta informacin para
que los jefes introduzcan los cambios y correcciones necesarias. Una vez adquirido este
nivel en la gestin de los proyectos se pueden establecer objetivos.

El quinto nivel (Mejora continua) se conoce como proceso continuo de mejora. Las
reas clave del proceso incluyen prevencin de defectos, administracin de cambios
tecnolgicos y gestin de cambios en los procesos


Metodos de evaluacion:

Para conseguir la certificacin CMM, es necesario contactar con algn evaluador
acreditado por el SEI. stos utilizan distintos mtodos para determinar en las
organizaciones el nivel de madurez en el que se encuentra el proceso utilizado en el
desarrollo de software.

Entre estos mtodos destaca el SCE consiste en una auditora y el CBA-IPI utiliza
entrevistas y otros procedimientos encaminados a ayudar a la mejora de los procesos
seguidos en la organizacin.
2.2. Marco de trabajo para el proceso.

Base para el proceso de software completo.
Es como un libro de recetas de cocina.
La adaptacion es especial
Aplicable a lo largo del proceso de software.
Su objetivo la gestion,el ratreo y el control del proyecto,
Garantiza la calidad del software.

Actividades del marco de trabajo:
Aplicable a todos los proyectos
Comunicacin
Planeacion
Modelado
Construccion
Despliegue

Conjunto de tareas:
Actividades que hacen que el marco de trabajo se adapte a las caracteristicas particulares
de cada proyecto.Define el trabajo real a cumplirse:

Tareas
Hitos,entregas.
Puntos SQA

2.3. Modelos de la ingeniera del software: modelo de cascada,
modelo de prototipos, modelo de espiral, modelo de Proceso
Unificado Racional (RUP).

Modelo cascada:

Es un modelo sencillo para explicar al cliente.
Tambien llamado ciclo de vida clasico sugiere un enfoque sistematico. secuencial
en el desarrollo del software.
Requiere que los requerimientos esten bien definidos y estables en forma
razonable.
Es el paradigma mas antiguo para la Ingenieria del Software.







Fases:

Ingenieria y Analisis del Sistema: Debido a que el software siempre es parte de un
sistema mayor el trabajo comienza estableciendo los requerimientos de todos los
elementos del sistema y luego asignando algun subconjunto de estos requisitos al
software.
Analisis de los requerimientos del software: El proceso de recopilacion de los
requerimientos se centra e intensifica especialmente en el software.El ingeniero
del software debe comprender el ambito de la informacion del software asi como la
funcion del rendimiento y las interfaces requeridas.
Diseo: Se enfoca en cuatro atributos distintos del programa la estructura de los
datos,la arquitectura del software,el detalle procedimental y la caracterizacion de la
interfaz.
Codificacion : Debe traducirse en una forma legible para la maquina.
Prueba: Se centra en la logica interna del software y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requiere.
Mantenimiento: El software sufriria cambios despues de que se entrega al cliente
ocurren debido a que hayan encontrado errores que el software deba adaptarse a
cambios del entorno externo o que el cliente requiera aplicaciones funcionales o
del rendimiento.

Caractersticas:

Es el mas utilizado.
Es una vision del proceso de desarrollo de software como una sucesion de etapas
que producen productos intermedios.
Para que el proyecto tenga xito deben desarrolllarse todas las fases.
Las fases continuan hasta que los objetivos se han cumplido.
Si se cambia el orden de las fases, el producto final sera de inferior calidad.

Ventajas:

La planificacion es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco calificado.

Deventajas:

No refleja realmente el proceso de desarrollo del software.
Se tarda mucho tiempo en pasar por todo el ciclo.
El mantenimiento se realiza en el codigo fuente.
Las revisiones de proyectos de gran complejidad son muy dificiles.

Modelo de prototipos:

Es una vision preliminar del modelo futuro.
Es un modelo operable.
Facilmente ampliable y modificable.
Tiene todas las caracteristicas propuestas pero realmente es un modelo basico
que tiene que ser mejorado

Ventajas:

La posibilidad de cambiar el modelo.
La oportunidad para suspender el modelo del desarrllo del modelo sino es
funcional.
La oportunidad de crear un nuevo modelo que se ajuste a mejor a las necesidades
y expectativas de los usuarios.

Relaciones de usuario:
Las sugerencias obtenidas de los usuarios lleven al analista hacia adecuaciones o
cambios que se ajustan mejor a las necesidades de los usuarios y que no habian sido
pensadas antes de la interaccion del usuario con el prototipo.

Debe ser construido en poco tiempo ,
no debe de utilizarse mucho dinero,
cuando este sea aprobado podemos iniciar el verdadero desarrollo del software.
Prodra ser construido si con el software es posible experimentar.

Desventajas:

Debido a que el usuario ve que funciona piensa que este es el producto terminado
y no entienden que recin se va a desarrollar el software .
Debe ir acompaado de otro modelo para su desarrollo.

Tipo de modelo de prototipo:
Desechable.: Nos sive para eliminar dudas sobre las que realmente quiere al
cliente ademas para desarrrollar la interfaz que mas le convenga al cliente.
Evolucionario.: Es parcialmente construido que puede pasar de ser prototipo a ser
software pero no tiene una buena documentacion y calidad.

A favor:

Utiles cuando los requerimientos son cambiantes.
Cuando nose conoce bien la aplicacin.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnologia.
Cuando se requiere rapidez en el desarrollo.

En contra:

No se conoce cuando se tendra un producto aceptable.
No se sabe cuantas interacciones seran necesarias.
Da una falsa ilusion al usuario sobre la velocidad del desarrolllo.
Se puede volver al producto aun y cuando no este en los estandares.

Modelo en espiral:

Las actividades se conforman en un espiral en la que cada bucle o interaccion representa
un conjunto de actividades, no estan fijadas a prioridad sino que las siguientes se eligen
en funcion de analisis de riesgo comenzando por el bucle interior.

Caracteristicas:

Encada giro se construye un nuevo modelo del sistema completo.
Este modelo puede combinarse con otros modelos de proceso de desarrollo .
Mejo ir modelo para desarrollo de grandes sistemas.
El analisis de riesgo requiere la participacion del personal con alta calificacion.
No hay numero definido de interacciones ,deben de decidirlas el equipo de gestion de
proyecto.

Ventajas:

Modelo espiral de cuatro regiones o modelo original de Boehm.
Modelo espiral de seis regiones.
Modelo espiral WINWIN.

Modelo espiral de cuatro regiones o modelo original de Boehm.



Modelo de seis regiones:



Modelo espiral WINWIN:

WINWIN(Victoria) sugiere una actividad del marco de trabajo que aborda la comunicacin
con el cliente.El objetivo de esta actividad es mostrar los requisitos del cliente.En un
contexto ideal del desarrollador simplemente pregunta al cliente lo que se necesita y
proporciona detalles suficientes para continuar.


Ventajas:

El modelo en espiral es un enfoque realista del desarrollo de sistemas.
Modelo de proceso adaptable.
El modelo en espiral puede s aplicarse a lo largo de la vida del software.
El desarrollador y el cliente comprenden y reaccionan mejor ante riegos en cada
uno de los niveles evolutivos.
Permite a quien lo desarrolla aplicar el enfoque de construccion de prototipos en
cualquier etapa de evolucion del producto.
Demanda una consideracion directa de los riesgos tecnicos en todas las etapas
del proyecto y si se aplicada adecuadamente debe reducir los riesgos antes de
que se conviertan en problemas.
Modelos evolutivos como el espral son apropiados oarticularmente parael
desarrollo de Sistemas OO.
Trata de mejorar los ciclos de vida de clasicos y prototipos.
Permite acomodar otros modelos.
Incorpora objetivos de calidad y gestion de riesgos.
Elimina errores y alternativas no atractivas al comienzo.

Desventajas:

Resulta dificil convencer a grandes clientes de que el enfoque evolutivo es
controlable.
Es nuevo y no se a utilizado tanto como otros modelo de ciclo de vida.
Requiere una considerable habilidad para la evaluacion del riesgo y cuenta con
esta habilidad para el xito.
Si un riesgo es importante no es detectado y gestionado a tiempo indudablemente
surgiran problemas.

Hitos del modelo WIN-WIN:

Introduce tres hitos son los procesos llamados puntos de fijacion que ayudan a establecer
la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisin antes de
continuar el proyecto de software.
Los puntos de fijacion representan tres visiones diferentes del progreso mientras que el
proyecto recorre la espiral.

2.4. Tendencias modernas de modelos de la ingeniera del
software.

XP:Programacion extrema:

De todas las metodologias habiles esta recibe mas atencion.

Valores :
Retroalimentacin.
Comunicacin.
Simplicidad .
Coraje.
Contruye un proceso de diseo evolutivo.
Refactora un sistema simple en cada iteraccion que se centra en la iteraccion
actual
no se hace nada anticipadamente.
Combina la disiplina con la adaptabilidad.

La familia de cristal de Cockburn:

Tipos diferentes de proyectos requieren tipos diferentes de metodologia.

Costituye: el numero de personas de un proyecto y las consecuencias de los
errores.Alistar requiere que las personas sigan un proceso diciplinado,explora a
metodologia menos disiplinada que aun pueda tener xito intercambiando productividad.El
cristal es menos productivo que la XP maas personas seran capaces de seguirlo.

Codigo abierto: Es un estilo de software,en particular su proceso se engrana a equipos
fisicamente distribuidos,la mayoria de los procesos adaptables exigen procesos locales.La
mayoria tiene uno mas mantenedores.Un mantenedor es la unica persona a la que se
permite hacer cambioen el almacen de codigo fuente,otras personas tambien pueden
hacer cambios pero necesitan madarlas a mantenedor para que las revise aplique.

El desarrollo de software adaptable de Highsmith:

Trabajando con metodologas predictivas. l las desarroll, instal, ense, y concluy
que son defectuosas: particularmente para los negocios modernos. En ASD hay tres
fases, no lineales: especulacin, colaboracin, y aprendizaje. En un ambiente adaptable,
aprender desafa a todos - desarrolladores y sus clientes - a examinar sus asunciones y
usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.

Scrum:

Scrum divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das.
Antes de que comience una carrera se define la funcionalidad requerida para esa carrera
y entonces se deja al equipo para que la entregue. el punto es estabilizar los requisitos
durante la carrera.
Todos los das el equipo sostiene una junta corta (quince minutos), llamada scrum, dnde
el equipo discurre lo que har al da siguiente. la literatura de scrum se enfoca
principalmente en la planeacin iterativa y el seguimiento del proceso.

Desarrollo manejado por rasgo:

Fue desarrollado por Jeff de Luca y Peter Coad. Las iteraciones duran dos semanas.
Tiene cinco procesos. los primeros tres se hacen al principio del proyecto.

desarrollar un modelo global
construir una lista de los rasgos
planear por rasgo
disear por rasgo
construir por rasgo

Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en tareas y se da un
criterio de comprobacin.
Los desarrolladores entran en dos tipos: dueos de clases y programadores jefe.

DSDM (MTODO DE DESARROLLO DE SISTEMA DINMICO)

Empieza con un estudio de viabilidad y negocio. Viabilidad considera si DSDM es
apropiado para el proyecto. Negocio es una serie corta de talleres para entender el rea
de negocio dnde tiene lugar el desarrollo. Tambin propone arquitecturas de esbozos del
sistema y un plan del proyecto.

El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce
documentacin de anlisis y prototipos, el ciclo de diseo del modelo disea el sistema
para uso operacional, y el ciclo de implantacin se ocupa del despliegue al uso
operacional.

Planificacin del proyecto de software

3.1. Aplicacin de herramientas para estimacin de tiempos y
costos de desarrollo de software: GANTT, PERT/CPM, uso de
software para la estimacin de tiempos y costos.

La planeacin efectiva de un proyecto de software depende de la planeacin detallada de
su avance, anticipando problemas que puedan surgir y preparando con anticipacin
soluciones tentativas a ellos. Se supondr que el administrador del proyecto es
responsable de la planeacin desde la definicin de requisitos hasta la entrega del
sistema terminado.

Panorama, plan de fases, plan de organizacin, plan de pruebas, plan de control de
modificaciones, plan de documentacion, plan de capacitacion, plan de revisin e informes,
plan de instalacin y operacin, plan de recursos de entregas,indice,plan de
mantenimiento.

El objetivo de la planificacin del proyecto de software es proporcionar un marco de
trabajo que permite al gestor de planificacin hacer estimaciones razonables de recursos,
costos y planificacin temporal

Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un
proyecto de software, y deberan actualizarse regularmente a medida que progresa el
proyecto.

Las estimaciones deberan definir los escenario del mejor caso, y peor caso de modo que
los resultados del proyecto pueden limitarse. El objetivo de la planificacin se logra
mediante un proceso de descubrimiento de la informacin que lleve a estimaciones
razonables.

ESTIMACION DEL PROYECTO DE SOFTWARE.

En el principio el costo del software constitua un pequeo porcentaje del costo total de los
sistemas basados en computadoras. Hoy en da el software es el elemento mas caro de la
mayora de los sistemas informticos. Es una pequea planeacin sobre que es lo que va
a ser mi proyecto. Una de las actividades cruciales del proceso de gestin del proyecto
del software es la planificacin.

Cuando se planifica un proyecto de software ese tiene que obtener estimaciones de
esfuerzo humano requerido, de la duracin cronolgica del proyecto y del costo. Pero en
muchos de los casos las estimaciones se hacen valindose de la experiencia pasada
como nica gua. Si un proyecto es bastante similar en tamao y funciona un proyecto
pasado es probable que el nuevo requiera aproximadamente la misma cantidad de
esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Si el proyecto es
distinto entonces puede que las experiencias obtenidas no sean suficientes.

Diagrama de Gantt:

Herramienta grfica que muestra el tiempo de dedicacin previsto para diferentes tareas o
actividades a lo largo de un tiempo total determinado, en principio, no indica las relaciones
existentes entre actividades, la posicin de cada tarea a lo largo del tiempo hace que se
puedan identificar dichas relaciones e interdependencias, para la planificacin del
desarrollo de proyectos complejos se requiere el uso de tcnicas basadas en redes de
precedencia como CPM o los grafos PERT.

Estas redes relacionan las actividades de manera que se puede visualizar el camino
crtico del proyecto y permiten reflejar una escala de tiempos para facilitar la asignacin
de recursos y la determinacin del presupuesto. El diagrama de Gantt, sin embargo,
resulta til para la relacin entre tiempo y carga de trabajo.

Metodo Pert:

Se utiliza en todo mtodo espacial .El mtodo CPM busca el control y la optimizacin de
los costos de operacin mediante la planeacin adecuada de las actividades
componentes del proyecto. Ambos mtodos aportaron los elementos administrativos
necesarios para formar el mtodo del camino crtico actual, utilizando el control de los
tiempos de ejecucin y los costos de operacin, para buscar que el proyecto total sea
ejecutado en el menor tiempo y al menor costo posible.

DIFERENCIAS ENTRE LOS METODOS PERT Y CPM:

La principal diferencia entre los mtodos es la manera en que se realizan los estimativos
de tiempo.
PERT:

Probabilstico.
Considera que la variable de tiempo es una variable desconocida de la cual solo
se tienen datos estimativos.
El tiempo esperado de finalizacin de un proyecto es la suma de todos los
tiempos esperados de las actividades sobre la ruta crtica.
Suponiendo que las distribuciones de los tiempos de las actividades son
independientes, la varianza del proyecto es la suma de las varianzas de las
actividades en la ruta crtica.

Considera tres estimativos de tiempos: el ms probable, tiempo optimista, tiempo
pesimista. CPM:

Determinativo. Ya que considera que los tiempos de las actividades se conocen y
se pueden variar cambiando el nivel de recursos utilizados.
A medida que el proyecto avanza, estos estimados se utilizan para controlar y
monitorear el progreso.
Si ocurre algn retardo en el proyecto, se hacen esfuerzos por lograr que el
proyecto quede de nuevo en programa cambiando la asignacin de recursos.
Considera que las actividades son continuas e interdependientes, siguen un
orden cronolgico y ofrece parmetros del momento oportuno del inicio de la
actividad.
Considera tiempos normales y acelerados de una determinada actividad, segn
la cantidad de recursos aplicados en la misma.


Usos:

El campo de accin de este mtodo es muy amplio, dada su gran flexibilidad y
adaptabilidad Para obtener los mejores resultados debe aplicarse a los proyectos que
posean las siguientes caractersticas:

1. Que el proyecto sea nico, no repetitivo, en algunas partes o en su totalidad.

2. Que se deba ejecutar todo el proyecto o parte de el, en un tiempo mnimo, sin
variaciones.

3. Que se desee el costo de operacin ms bajo posible dentro de un tiempo
disponible. Dentro del mbito aplicacin, el mtodo se ha estado usando para la
planeacin y control de diversas actividades


Ventajas de PERT y CPM:

1. Ensea una disciplina lgica para planificar y organizar un programa detallado de
largo alcance.
2. Proporciona una metodologa Standard de comunicar los planes del proyecto
mediante un cuadro de tiempo, personal, costo.
3. Identifica los segmentos ms crticos del plan, en que problemas potenciales
puedan perjudicar el cumplimiento del programa propuesto.
4. Ofrece la posibilidad de simular los efectos de las decisiones alternativas o
situaciones imprevistas y una oportunidad .
5. Aporta la probabilidad de cumplir exitosamente los plazos propuestos.



3.2. mbito del software: recursos humanos, recursos de software
reutilizables, recursos del entorno.

Describe el control y los datos a procesar, la funcin, el rendimiento, las restricciones, las
interfaces y la fiabilidad. Se evalan las funciones descoritasen la declaracin del mbito,
y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin.

Comprende la estimacin de los recursos necesarios para emprender el desarrollo del
software. Los recursos de desarrollo son:

Recursos Humanos:

Se debe establecer las habilidades que se necesitan para llevar a cabo el desarrollo del
proyecto. Hay que especificar tanto la posicin dentro de la organizacin como la
especialidad. El nmero de personas requerido para un proyecto de software se
determina despus de hacer una estimacin del esfuerzo de desarrollo.
-Gestor
-Ingeniero de software
-Analista de sistemas

Recursos del software reutilizable;

Creacin y de bloques de construccin de software. Se deben tener encuentra a
medida que se avanza con la planificacin:
Componentes ya desarrollados: componentes que ya han sido validados
totalmente se pueden utilizar e implementar en el desarrollo del proyecto actual.
Componentes ya experimentados: se puede utilizar Especie ficaciones,diseos,
cdigo o datos de prueba existentes que ya han sido desarrollados para proyectos
anteriores.
Componentes con experiencia parcial: se puede utilizar especificaciones,diseos,
cdigo o datos de prueba existeantes que ya han sido desarrollados para
proyectos anteriores y que requieren una modificacin sustancial.
Componentes nuevos: componentes que el equipo de software requiere construir
especficamente para el proyecto.
3.3. Anlisis y gestin del riesgo: estrategias, identificacin,
proyeccin, refinamiento, reduccin, supervisin y gestin del
riesgo.

Proyeccin:

La estimacin del riesgo mide: La probabilidad de que el riesgo sea real. Las
consecuencias de los problemas asociados con el riesgo, si ocurriera.

Actividades de proyeccin del riesgo:

1. 1.Establecer una escala que refleje la probabilidad percibida del riesgo
2. 2.Definir las consecuencias del riesgo
3. 3.Estimar el impacto del riesgo en el proyecto y en el producto
4. 4.Apuntar la exactitud general de la proyeccin del riesgo de manera que no haya
confusiones.

Por medio del uso de la siguiente tabla se facilita una proyeccin del riesgo.

Riesgos Categoria Probabilidad Imapacto
Mayor numero de
usuarios previstos
TP

30%

3


1.En la columna: Riesgo, se registran todos los riesgos
2.En la columna: Categora, cada riesgo se categoriza as:

Tamao del producto (TP)
Ingeniera del Software
Impacto en la organizacin (IO)
Tipo de cliente (TC)
Proceso de produccin (PP)
Entorno de desarrollo (ED)
Tecnologa (T)

Experiencia tcnica (ET) se pueden utilizar las iniciales que se encuentran entre
parntesis o puede asignar unas especficas.

3.-En la columna probabilidad, se registra la probabilidad de aparicin de cada riesgo.
4.En la columna impacto, Se valora y se registra el impacto de cada riesgo as:

1. Catastrfico
2. Crtico
3. Marginal
4. Despreciable

Por ltimo la tabla es ordenada por probabilidad y por impacto.

Aquellos riesgos que presentan alta probabilidad y alto impacto pasan al inicio de la tabla
y los que presentan baja probabilidad e impacto pasan al final de la tabla. Una vez la tabla
ha sido ordenada, el encargado del proyecto debe traza runa lnea de corte donde los
riesgos que se encuentren por encima de sta lnea se les prestara una mayor atencin.

El objetivo es evitar y tratar un riesgo. Desarrolle un plan de reduccin del riesgo. Este
plan de reduccin del riesgo involucra para cada riesgo una serie de pasos y acciones
que debe tomar e implementar el equipo de desarrollo del software.

El plan RSGR

Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de software o
se podran organizar los pasos de gestin del riesgo en un plan diferente de reduccin,
supervisin y gestin del riesgo (Plan RSGR). Todos los documentos del plan RSGR se
llevan a cabo como parte del anlisis de riesgo y son empleados por el jefe del proyecto.

Se expone un esquema del Plan RSGR:
I. Introduccin
1. Alcance y propsito del documento
2. Visin general de los riesgos principales
3. Responsabilidades. Gestin. Personal tcnico
II. Tabla de riesgo del proyecto.
1. Descripcin de todos los riesgos por encima de la lnea de corte
2. Factores que influyen en la probabilidad e impacto
III. Reduccin, supervisin y gestin del riesgo. Riesgo. Reduccin. Estrategia
general. Pasos especficos
.b. Supervisin
Factores a supervisar
Enfoque de supervisin
Gestin
Plan de contingencia. Consideraciones especiales.
IV. Planificacin temporal de revisin del Plan RSGRV

Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los
procedimientos de reduccin y supervisin del riesgo.

La reduccin del riesgo es una actividad para evitar problemas.
La supervisin del riesgo es una actividad de seguimiento del proyecto centres objetivos
principales:
1. Valorar cuando un riesgo previsto ocurre de hecho.
2. Asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo
en cuestin se estn aplicando apropiadamente.
3. Recoger informacin que pueda emplearse en el futuro para analizar
4. Tambin intentar determinar el "origen" a lo largo de todo el proyecto.


Anlisis del proyecto de software

4.1. Modelado: anlisis, diseo, documentacin.

Analisis:

Pressman establece que la tarea del analisis de requisitos es un proceso de
descubrimiento,refinamiento,modelado y especificacion.Se refina en detalle el ambito del
software y se crean modelos de los requisitos datos,flujo de informacion y control y del
comportamiento operativo.Se realizan soluciones alternativas y se asignan a diferentes
elementos del software.

El analisis de requisitos permite al desarrollador o desarrolladores especificar la funcion y
el rendimiento del software,indica la interfaz del software con otros elementos del sistema
y establece las restricciones que debe cumplir el software.Puede dividirse en cinco areas
de esfuerzo que son:
Reconocimiento del problema
Evaluacion y sintesis
Modelado
Especificacion
Revision

Diseo:

Es cuando se traducen los requerimientos funcionales y no funcionales en una
representacion de software.El diseo es el primer paso en la fase de desarrollo o cualquer
producto o sistema de ingenieria.
De acuerdo con Pressman el objetivo del diseo es producir un modelo o representacion
de una entidad que va a construir posteriormente.

De acuerdo con McGlaughlin hay tres caracteristicas que sirven como parametros
generales para la evaluacion de un buen diseo:
El diseo debe implementar todos los requerimientos explicados obtenidos en la etapa de
analisis.
El objetivo debe ser una guia que puedan leer y entender los que construyenel codigo y
los prueban y mantienen el software.
El diseo debe proporcionar una idea completa de lo que es el software.

Documentacion:

Se presenta en base a los metodos orientados a objetos propuestos por Martin y Odell.Se
utilizan las siguientes tecnicas para documentar los componentes mas relevantes de la
herramienta de software:
Diagramas de eventos:Para ilustrar la manera en que el usuario del software interactua
con los eventos virtuales.
Diagramas de contexto:Para ubicar el campo de accion que abarca el software.
Tarjetas CRC:Utilizadas para representar todas las clases dentro de un diseo.



4.2. Construccin: codificacin, pruebas y evaluacin, manual del usuario, manual tcnico.

Construccion:

Es la creacion detallada de software operativo.

Lenguajes de construccion pueden ser varias clases:

De configuracion.
De Toolkits.
De programacion.

Los principios fundamentales de la construccion de software son:

Minimizar la complejidad
Anticipar los cambios
Pensar en la verificacion posterior
Aplicar estandares

Coodificacion:

La escritura del codigo fuente es el principal esfuerzo de costruccion de software:
Aplicar tecnicas para crear codigo fuente comprensible
Manejar condiciones de error
Prevenir brechas de seguridad a nivel de codigo
Uso eficiente de recursos escasos
Organizar el codigo fuente
Documentar el codigo

Pruebas:

Frecuentemente realizadas por los mismos que escriben el codigo.El proposito de estas
pruebas es reducir el tiempo entre el momento en el que los fallos se insertan en el codigo
y el momento en el que son detectados

Implica la ejecucion del programa permite:

Evaluar la calidad de un producto.
Mejorarlo identificando defectos y problemas.

El ambito o destino de las pruebas de software pueden variar en tres niveles:

Modulo unico:Pruebas unitarias
Grupo de modulos:Pruebas de integracion
Sistema completo:Pruebas del sistema

Tecnicas de prueba:
Principio basico:Intentar ser lo mas sistematico posible en identificar un conjunto
representativo de comportamiento de programa.
Objetivo:romper el programa,encontrar el mayor de fallos posibles.Existen 2 enfoques
diferentes:
Caja negra:Funcional:Se basan en el comportamiento de entrada y salida.
Caja blanca:Estructural:Informacion del software que a sido diseada o codificada.

Evaluacion:

Evaluacin de Proyectos es un proceso que permite emitir un juicio sobre la conveniencia
del proyecto. Este criterio est presente en cada etapa del Ciclo de proyecto:

1 Etapa: Pre-inversin
2 Etapa: Inversin

Al igual que en las etapas, en cada fase se realiza una evaluacin de acuerdo a sus
caractersticas.

La etapa de Pre-inversin consta de las siguientes fases

1 Etapa 1 Fase Concepcin de la idea
1 Etapa 2 Fase Perfil
1 Etapa 3 Fase Pre-factibilidad (Estudio de Alternativas)
1 Etapa 4 Fase Factibilidad (Ante- proyecto definitivo)

En la etapa de Inversin tambin se realiza el proceso de evaluar en cada una de sus
fases.

La etapa de Inversin consta de las siguientes fases:
2 Etapa Diseo definitivo
2 Etapa Montaje y Operacin

Como se puede apreciar, el trabajo de evaluacin se encuentra en todo momento, cada
etapa tiene su forma de evaluar. En la etapa de Pre-inversin, la evaluacin es realizada
en las distintas fases, comenzando por la concepcin de la idea y terminando en la
factibilidad del proyecto. En esta etapa la Evaluacin suele ser llamada Evaluacin Ex-
Ante.

En la etapa de Inversin la Evaluacin se da tanto en el Diseo definitivo como en el
Montaje y Operacin del proyecto. En esta etapa la Evaluacin suele ser llamada
Evaluacin Ex-Post.

El camino al xito de nuestros proyectos, solo se conseguir siendo imparciales a los
datos o resultados que otorgue la Evaluacin correspondiente, adicionalmente se necesita
cambiar algunos paradigmas tradicionales y desarrollar un sistema de control adecuado,
de este modo se conseguir el xito.

La Evaluacin de Proyectos es "un instrumento o herramienta que genera informacin,
permitiendo emitir un juicio sobre la conveniencia y confiabilidad de la estimacin
preliminar del beneficio que genera el Proyecto en estudio".

Manual de usuario:

Un manual de usuario se trata de una gua que ayuda a entender el funcionamiento de
algo. Es un documento de comunicacin tcnica que busca brindar asistencia a los
sujetos que usan un sistema o servicio.

Elaboracin del Manual De Usuario.

Pasos del manual del usuario:

1. Portada: De que se trata el documento y quin lo elaboro?
2. Introduccin: Describe el uso del documento (para qu sirve?) y de qu habla?
3. Anlisis y requerimientos del sistema (que se ocupa para poder instalarlo y usarlo?)
3. Explicacin del funcionamiento: Debes de poner paso a paso y con pantallas bien
explicadas cmo funciona el programa
4. Glosario

Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor
dificultad posible.
Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el
programa.
Especificar los alcances y las limitaciones que tiene el programa.
Un buen punto de partida para un manual de usuario, es hacer de cuenta que las
personas que lo van a leer no tienen el ms mnimo conocimiento sobre computadores.

Manual Tcnico.

Este documento contiene toda la informacin sobre los recursos utilizados por el proyecto,
llevan una descripcin muy bien detallada sobre las caractersticas fsicas y tcnicas de
cada elemento. Por ejemplo: caractersticas de procesadores, velocidad, dimensiones del
equipo, garantas, soporte, proveedores y equipo adicional.
Su extensin depende de la cantidad de recursos y equipo utilizado y generalmente se
presenta en forma de fichas tcnicas en donde se describe en cada una las
caractersticas de cada recurso.

Elaboracin del Manual Tcnico.

Un manual tcnico es aquel que va dirigido a un pblico con conocimientos tcnicos sobre
algn rea, mientras que, por ejemplo, un manual de usuario va dirigido a un pblico ms
general, el cual no necesariamente debe tener conocimientos especficos en el rea de
inters.

En este caso el manual tcnico, debe incluir:
Paradigma de programacin seleccionado y sus beneficios.
Lenguaje de programacin seleccionado y sus beneficios frente a otros lenguajes.
Estandarizacin de cdigo utilizada.
Diseo del sistema.




4.3. Medida, mtrica e indicador.

Medida:

Proporciona una indicacin cuantitativa de la cantidad, dimensiones o tamao de algunos
atributos de un producto.


Se debe medir el software para:

Indicar la calidad del producto.
Evaluar la productividad del agente que desarrolla el producto.
Evaluar los beneficios en trminos de productividad y calidad mediante el uso de nuevos
mtodos y herramientas de ingeniera de software.
Establecer una lnea de base para la estimacin.
Ayudar a justificar el uso de nuevas herramientas o de formacin adicional.

Las mtricas

Son medidas cuantitativas que permiten obtener una visin de la eficacia del proceso de
software y los proyectos que se llevan a cabo utilizando ese proceso como marco de
trabajo.

Permiten valorar el estado de un proyecto en curso, as como tambin rastrear los riesgos
potenciales y descubrir las areas problema antes que se vuelvan criticas, tambin
permite ajustar el flujo de trabajo o las tareas y evaluar la habilidad del equipo del
proyecto. Las mtricas del proyecto se usan con fines tcticos

Indicador:

Son datos esencialmente cuantitativos, que nos permiten darnos cuanta de cmo se
encuentran las cosas en relacin con algn aspecto de la realidad que nos interesa
conocer.
Los Indicadores pueden ser medidas, nmeros, hechos, opiniones o percepciones que
sealen condiciones o situaciones especficas.

4.4. Tipos de mtricas: mtricas de proceso, mtricas de proyecto, mtricas orientadas a
punto de funcin, mtricas orientadas al tamao, mtricas para la calidad del software.

Metricas de proceso:

Permiten obtener un conjunto de indicadores de proceso que conduzcan a la mejora de
los procesos de software a largo plazo, las cuales se usan con fines estratgicos

Metricas de proyecto:

Permiten valorar el estado de un proyecto en curso, as como tambin rastrear los riesgos
potenciales y descubrir las areas problema antes que se vuelvan criticas, tambin
permite ajustar el flujo de trabajo o las tareas y evaluar la habilidad del equipo del
proyecto. Las mtricas del proyecto se usan con fines tcticos

Metricas orientadas a punto de funcion:

Son medidas indirectas del software y del proceso. Se centran en la funcionalidad o
utilidad del programa. Emplean como un valor de normalizacin una medida de la
funcionalidad que entrega la aplicacin. La mtrica orientada a la funcin utilizada con
mayor amplitud es el punto de funcin (PF)

Metricas orientadas al tamao:

Son medidas directas del software y del proceso por el cual se desarrolla. Se obtiene
considerando las medidas de productividad y normalizndolas por el tamao del cdigo,
es decir las lneas de cdigo LDC.

Se lista cada proyecto de desarrollo de software de los ltimos aos y los
correspondientes datos orientados al tamao de cada uno, se basan en a utilizacin de
registros sencillos para las medidas ms relevantes al desarrollo de nuestro proyecto.

Metricas para calidad del software:

Existen medidas de la calidad del software como: la correccin, la facilidad de
mantenimiento, la integridad y la facilidad de uso ofrecen indicadores utilices para el
equipo del proyecto, Gilb[GIL88]sugiere definiciones y mediciones para cada una de ellas:
Correccin: es el grado en que el software desempea la funcionara la que fue creado y
se mide en defectos por KLOC.
Facilidad de Mantenimiento:es la sencillez con que un programa puede corregirse si se
encuentra unerror; al adaptarse si su entorno cambia o mejorar si el cliente cambia los
requisitos y se mide en forma indirecta en TMC (tiempo medio de cambio).
Integridad: es la habilidad de un sistema para resistir ataques que requiere la definicin de
amenaza y seguridad y se calcula:
integridad = 1 (amenaza x (1 - seguridad))


4.5. Implementacin y mantenimiento: entrega, retroalimentacin del cliente.

Implementacion:Es la actividad durante la cul los desarrolladores traducen el diseo a
codigo.

Mantenimiento:Es el proceso de mejora y optimizacion del software asi como tambien
correccion de los defectos.

Entrega:Proporciona el conjunto de actividades necesarias para llevar a cabo las entregas
software y de documentacin asociada a un proyecto, desde la formalizacin de la
entrega hasta la revisin y validacin de la misma, con la finalidad de homogeneizar todas
las entregas software y facilitar su revisin y tratamiento.

Retroalimentacion del cliente:

El proceso de retroalimentacin del cliente es una parte crtica del sistema de gestin de
la calidad, y por lo tanto debe recibir una atencin adecuada durante una auditora de
tercera parte. La retroalimentacin del cliente es uno de los indicadores primarios de
desempeo que puede ser utilizado para juzgar la eficacia general del SGC. Por lo tanto,
es importante para el auditor verificar que:
a) Las entradas a este proceso incluya datos relevantes, representativos y confiables.
b) Estos datos se analizan eficazmente.
c) La salida de este proceso proporciona informacin til para la revisin por la direccin y
otros procesos del SGC, para aumentar la satisfaccin del cliente y llevar hacia la mejora
continua

You might also like