7 de abril de 2016

Notas 07-04-2016

Proyeccion o estimacion del riesgo

Intenta calificar cada riesgo en dos formas:
  • La posibilidad o probabilidad de que el riesgo sea real y
  • Las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra

Paso de proyeccion de riesgo
  • Establecer una escala que relfleje la probabilidad percibida de un riesgo
  • Deliner las consecuencia del riesgo
  • Estimar el impacto del riesgo sobre el proyecto y el producto
  • Valorar la precision global de la proyeccion del riesgo de mdo que no habra malos entendidos
Tecnica simple 

Una tecnica simple para la proyeccion de riesgo es realizar una tabla dfe riesgos con las colmnas: nombre del riesgo, clasificacion, probabilidad de ocurrencia, valoracion de impacto. Luego, se ordena la tabla por mayor probabilidad e impacto (paso 5)



 Riesgo
Clasificacion
Probabilidad
Impacto
MMMR
 Menor reuso que el planificado
 ps
 70%
2
 Mayor numero de usuarios que el planeado
 ps
 30%
 3

 Oerdida de fondos
 cu
40%
 1




  •  Los promotores de riesgo pueden valorarse sobre una escala de probabilidad cualitativa que tenga los valores: imposible, improbable, probable y frecuente

Exposicion al riesgo global     ER=PxC donde:
  • P=probbilidad de ocurrencia de un riesgo
  • C=Costo para el proyecto si ocurre el riesgo 


 

5 de abril de 2016

3.5.2 Identificacion , impacto y proyeccion del riesgo

Identificacion de riesgos: Es un intento sistematico por especificar amenzasa al plan del proyecto.

Tipos de riesgo:
  • Riesgos genericos: Son una amenaza potencial a todo proyecto de software
  • Riesgos especificos del producto. pueden identificarse solamente por quienes tienen  clara comprension de la tecnologia, el personal y el entorno especifico del software que se contruye.
  • Para identificart los riegos hay que cobntestar la pregunta:
¿Qué caracteristicas especiales de este producto pueden amenzara el plan del proyecto?

 METODO PARA IDENTIFICAR RIESGOS

  • Crear una lista de verificacion item de riesgo (paso 1)
Subcategorias de riesgos conocidos:
  • Tamaño del producto: riesgos asociados con el tamaño global del software que se va a construir o a modificar.
  • Impacto empresarial: Riesgo asociados con restricciones impuestas por la administración o por el mercado.
  • Características de los participantes: Riesgos asociados con la sofisticacion de los participantes y con la habilidad de los desarrolladores para comunicarse con los participantes en forma oportuna. 
 Categorías
  • Definición del proceso: riesgos asociados con el grado en el que se definió el proceso de software y la manera como se sigue por parte de la organizacion desarrolladora.
  • Entorno de desarrollo: riesgo asociados con la disponibilidad y calidad de las herramientas por usar para construir el producto.
  • Tecnologías por construir: riesgos asociados con la complejidad del sistema que se va a construir y con lo novedoso de la tecnología que se incluye en el sistema
  • Tamaño u experiencia del personal: riesgos asociado con la experiencia técnica y de proyecto global de los ingenieros de software que harán el trabajo. 
  • Formato para un riesgo: (paso 2)
 condicion-transicion-consecuencia
Ejemplo:
  • Dado que  (condicion) entonces hay preocupacion porque (posiblemente)(consecuencia).
  • Dado que todos los componentes de software reutilizables deben apegarse a estandares de diseño especifico y dado que algunos no se apegan, entonces existe preocupacion de que posiblemente solo 70 po ciento de los modulos reutilizables planeados puedan realmente integrarse en el sistema que se va construir, lo que da como resultado la necesidad de ingenieria a la medida del restante 30 por ciento de los componentes. 
IMPACTO
Luego, se hacen preguntas relevantes a cada tema del proyecto y las respuestas a dichas preguntas permiten estimar el impacto del riesgo. (paso 3)

  • ¿Los gerentes de software y de cliente se reunieron formalmente para apoyar el proyecto?
  • ¿Los usuarios finales se comprometen de manera entuasiasta con el proyecto y con el sistema/producto que se va a construir?
  • ¿El equioi de ingenieria del software y sus clientes  entiended por completo los requisitos?
  • ¿Los clietntes se invlolucraron plenamente en la definicion de los requisitos?
  • ¡Los usuarios finales tienen expectativas realistas?
  • ¿El ambito del proyecto es estable? 
  • ¿El equipo de ingenieria del software tiene la mezcla correcta de habilidades?
  • ¿Los requisitos del proyecto son estables?
  • ¿El equipo de proyecto tiene expreciencia con la tecnologia que se va a implementar?
  • ¿El numero de personas que hay en el equipo del proyecto es adecuado para hacer el trabajo?
  • ¿Todas las divisiones de cliente/usuario estan de acuerdo en la importancia del proyecto y en los requisitos para el sistema/producto que se va a construir?
Grado de riesgo= respuestas negativas 


El gerente del proyecto debe identificar los promotores de riesgo que afectan los componentes de riesgo de software: rendimiento, costo, apoyo y calendario. Los componentes de riesgo se definen en la forma siguiente:

  • Riesgo de rendimiento: grado de incertibumbre de que el producto satisfaea sus requisitos y se ajustara al uso pretendido.
  • Riesgo de costo: grado de incertidumbre de que el presupuesto del proyecto se matendra
  • Riesgo de apouo: grado de incertidu,bnre de que el softawre resultante sera facil de corregir, adaptar y mejor
  • Riesgo  de calendario: grado de incertidumbre de que el calendario del proyecto se matendra y de que el producto se entregara a tiempo.

  • Impacto de cada promotor de riesgo sobre el componente de riesgo se divide en una de las siguientes categorias de impacto:
despreciable, marginal, critico o catastrofico

  • Potencial consecuencia de errores=1.
  • Fallo para lograr el resultado deseado=2
(paso 4)


17 de marzo de 2016

Notas 17-03-2016

3.4.-Estimacion de Personal Requerido
Primero se especifica la posicion organizacional, luega la especialidad(bases de datos, cliente-servidor, telecomunicaciones, redes, entre otros) y decir cuantas personas por mes se necesitan y cuanto se les va a pagar.

CLASIFICACIONDE PARTICIPANTES
  • Gestores ejecutivos, que definen los aspectos de negocios o temas empresariales que a menudo tienen una influencia significativa sobre el proyecto.
  • Gestores (tecnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
  • Profesionales, que proporcionan las capacidades tecnicas necesarias para la ingenieria de un producto o aplicacion
  • Clientes
  • Usuarios finales.
 El exito de la organizacion de desarrollo de software esta muy, muy asociada con la habilidad para reclutar buen personal.

Dentro de las evaluaciones que se les hacen a las personas estan: rapidez con que teclea, tiempo que tarda en realizar un programa en x lenguaje.

3.5 Analisi de riegos

Riego.- se refiere a los problemas potenciales que amenazxan el exito de un proyecto. Se relaciona con los términos de incertidumbre y perdida.
El análisis y la administración del riesgo son acciones que ayudan al equipo de software a entender y manejar la incertidumbre.

3.5.1 TIPOS DE RIESGOS

  • Riesgos del proyecto.- Amenazan el plan del proyecto, es decir, si se vuelven reales es probable que el calendario del proyecto cambie y que los costos aumente.
  • Riesgos tecnicos.- Amenazan la calidad y al temporalidad del software que se va a producir. Pueden ser por problemas de diseño o implementacion o mantenimiento. Es cuando el problema es mas dificil de resolver de lo que se creía.
  • Riesgos empresariales.- Amenazan la viabilidad del software que se va a constrouir y con frecuencia ponen en peligro el proyecto o el producto. los principales riesgos empresariales son:
  1. Construir un producto o sistema excelente que realmente no se quiere(riesgo de mercado)
  2. Construir un producto que ya no encaje en la estrategia empresarial global de la compañia(tiesgo estrategico)
  3. Construir un producto que el equipo de ventas no sabe como vender (riesgo de ventas)
  4. Perder el apoyo de losa administradores debiado a un cakbio en el enfoque o en el personal (riego administrativo)
  5. Perder el apoyo presupuestal o de personal (riesgos presupuestales) 
 Otra clasificacion:
  • Riesgos conocidos.- Son aquello que pueden descubrirse despues de una evaluacion cuidadosa del plan del proyecto, del entorno empresarial o tecnico donde se desarrolla el proyecto.
  • Riesgos predecibles.- Salen de la experiencia en proyecto anteriores.
  • Riesgos impredecibles.- Pueden ocurrir pero son extremadamente dificel de identificar por adelantado,

14 de marzo de 2016

Notas 14/03/2016

3.3 Estimaciones de costo

Modelo COCOMO 2

Aborda las areas:

  • Modelo de composición de aplicacion: Se usa durante las primeras etapas de la ingeniería de software.
  • Modelo de etapa temprana de diseño: Se usa una vez estabilizados los requisitos y establecida la arquitectura básica del software.
  • Modelo de etapa postarquitectonica: Se usa durante la construccion del software.
Todos los modelos de estimación para software requieren información sobre dimensionamiento
Las opciones de dimensionamiento son:
  • Puntos de objeto, puntos de función y lineas de código fuente
  • Este modelo usa los puntos de objeto. 
PUNTOS DE OBJETO
El punto de objeto es una medida de software indirecta que se calcula usando conteos del numero de:
  • Pantallas
  • Reportes
  • Componentes que probablemente se requieran para construir la aplicacion. 

EJERCICIO TAREA

Usa el modelo COCOMO 2 para estimar el esfuerzo requerido para construir software para un simple ATM que produce 12 pantallas, 10 reportes y que requerira aproximandamente 80 componentes de software. Supon complejidad promedio y madurez desarrollador/entorno promedio. Usa el modelo de composicion de aplicacion con puntos de objeto.

1 de marzo de 2016

GUIA EXAMEN 2

Guia de dinamica
  • Area de proceso del nivel inicial del PCMM 
  • Fases de aplicacion de PSP
  • En que se centra el PSP
  • Norma Mexicana orientada a empresas de spftware o empresas al desarrollo de software  
  • Que se hace en la reunion 7
  • Que se hace en el segundo dia TSP
  • PSP: Cuando se considera efectiva la fase PSP 3
  • Que significa LFMN
  • De que se encarga un proceso de realizar el aseguramiento de calidad
  • Cual es la arquitectura del PCM
  • Una entrada de planificar la calidad
  • Cual es el objetivo del area gestion de la integracion
  • Para que nivel se debe solicitar una cotizacion
  • Cuanto tiempo dura el proceso de lanzamiento del equipo
  • Cuanto cuesta la verificacion de procesos de la norma del 2011 de nivel 1
  • En que fase se empieza a utilizar la tecnologia PROBE
  • 4 elementos de la estructura SQAP
  • Mencionen 2 cosas que deben cumplir los ingenieros para estar en un equipo efectivo
  • Que se hace en el nivel definido PCMM
  • Niveles de madurez del PCMM
  • Que significa EMA
  • A quien esta dirigido el PSP
  • Que es no conformidad
  • PSP: Cual es el objetivo del PSP
  • Define calidad
  • Objetivo del PCMM
  • Norma orientada al desarrollo de software
  • Quien propuso el TCP
  • Que significa PSP
  • Menciona las vistas de la calidad

22 de febrero de 2016

NOTAS 22-2-2016 GPS

INTEGRACION
ALCANCE
TIEMPO
COSTE
CALIDAD
RIESGOS
COMUNICACIONES
RECIRSOS HUMANOS
ADQUISICIONES

GESTION DE PROYECTOS

  • Gestion de la integracion, cuyo objetyivo es identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de la gestion de proyectos
  • Gestion del alcance, que incluye los procesos y actividades necesarias para garantirzare que el proyecto incluya  el trabajo ruequerido para completarlo de forma exitosa.
  • Gestion del tiempo, que busca asegurar ña realizacion del proyecto dentro de los plazos previstos.
  • Gestion del coste, para asegurar que el proyecto es completado dentro del presupuesto previsto.
  • Gestion de la calidad, que determina las politicas, los objetivos y las responsabilidades relativos a la calidad de modo qeu el proyecto satisfaga las necesidades de calidad por las cuales emprendió.
  • Gestion de los recursos humanos, con el fin de conseguir el uso mas efectivo de las personas que participan en el proyecto mediante la planificacion, adquisicion, desarrollo y gestion del rquipo.
  • Gestuin de las comunicaciones, para asegurar en tiempo y forma adecuados la generacion, recopilacion, determinacion, almacenamiento y locaclizacion final de la informacion del proyecto.
  • Gestion de los riesgos, que busca identificar, analizar y dar respuesta a los riesgos del proyecto tratando de maximizar la probabilidad y consecuencias de eventos positviso y minimizar las de eventos negativos.
  • Gestion de las adquisiciones, que describe los procesos necesarios para la compra o adqiosocion de productos,servicio o resultasdos para la realizacion del proyecto.
Para dar soporte al artea de gestion de la calidad de los proyectos se inclyen:

  • Planificar la calidad: Se encarga de la identificacion de los requisitos de calidad y/o normas para el proyecto y el producto , documentando la manera en que el proyecto demostrara el cumplimiento de los mismo.
  • Realizar el aseguramiento de la calidad: Se encargara de auditar los requisitos de calidad y los resultados obtenidos con las meidicones de control de la calidad con el fin de asegurar que se utilizan los estandares de calidad y las definiciones operacionales adecuadas.
  • Realizar el control de calida: Se hace durante todo el rpyecto, mediante el cual se monitorean y se registran los resultados de la ejecucion de las actividades de gestion de la calidad con el fin de evaluar su rendimiento y recomendar los cambios necesarios. 
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4H1mLVm1TgpU0p-pDwnjTnFR08SW2E4w7QjbJuEDIDlvIh2Q4rmWoOCphstefJc5VvNYi8c3jpifQ5YbobU-L74AzK0Qu2-nAF8Nv_3cirCYxIgLeuPjbeQp_FT3wgOO95-FBO_FqmH0s/s1600/Hands_01+copy.jpg
ESTANDAR IEEE 730-2002
Proporciona un conjunto uniforma y minimo aceptable de los requisitos para la preparacion de Planes de Aseguramiento de la Calidad del Software (SQAP, software quality assuarance pans). Para ello define la estructura que dichos planes deben seguir y facilita la evaluacion de dichos planes.

Estructura del SQAP
  • Proposito
  • Documento de regerencia
  • Gestion 
  • Documentacion
  • Estandares, Practicar, convencione sy metricas
  • Revisiones software
  • Pruebas
  • Informes de problemass y acciones correctivas
  • Herramientas, tecnicas y metodologias
  • Control de medios
  • Control del proveedor
  • Coleccion de registros, mantenimiento y conservacion
  • Formacion
  • Gestion de riesgos
  • Glosario
  • Procedimiento de canvui e gustiruak de SQAP

6 de febrero de 2016

Metodologias de desarrollo de software: Metodologia Cascada y Metodologia Incremental

Para el desarrollo de software se utilizan diferentes metodologías que nos ayudan a generar un proyecto más organizado y metódico, nos dan un orden o en otros casos una forma de cómo y cuándo hacer cada una de las etapas del desarrollo de software, todo esto para poder ser capaces de generar un proyecto final de la forma más óptima y ordenada.


A lo largo de los años se han desarrollado diferentes metodologías para desarrollar proyectos de software, dos de ellas son el modelo de desarrollo incrementa y el modelo de cascada, cada uno tiene sus ventajas y desventajas dependiendo del proyecto al que se aplique, y pueden ser más recomendables para uno que para otro, por eso es necesario que se les conozca bien para poder decidir cuál es el más adecuado para cierto proyecto que se esté desarrollando, o se planee desarrollar en un futuro.






El modelo incremental es una metodología de desarrollo que interpreta el proceso total de un desarrollo de software en forma de etapas o secciones únicas, es decir, que cada etapa en la que esté trabajando es en cierta forma independiente de otras, esto disminuye los errores en el proceso general. Esta metodología se basa principalmente en que entrega periódicamente un avance del proyecto al usuario a medida que va avanzando el tiempo de entrega. Esto último es posible debido a que en cada ciclo que se hace el proceso de desarrollo se trabaja para crear un incremento funcional y no el producto final, y con incremento no se refiere a que entrega un prototipo, sino más bien una porción del código que luego es reutilizada en el siguiente ciclo de codificación, reutilizarlo y reciclaje son conceptos bien comprendidos en esta metodología, claro que siempre pensando en un producto final que incluya todos los incrementos creados previamente.


La metodología surgió en 1980 y fue propuesta por Harlan D. Mills. Harlan D. Mills fue un profesor de ciencias de la computación en el instituto de tecnología de florida, nació en mayo de 1919 y murió en junio de 1996, en su tiempo de vida tuvo grandes aportes a ambiente tecnológico que hasta el día de hoy siguen teniendo sus repercusiones. Fue fundador de la empresa de tecnología de ingeniería de software que también está situada en florida, muchas de las aportaciones que hizo al área de desarrollo de software fueron basadas en ideas ya existentes de la ciencia de la computación. La metodología incremental surgió como una forma de reducir la repetición sin sentido del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones mientras se adquiría experiencia con el sistema desarrollado.

La metodología de desarrollo incremental consiste en básicamente 5 etapas: El análisis de requerimientos del sistema, el análisis de requisitos de software, el diseño, la codificación y la entrega. (Ver figura 01)

En el análisis de requerimientos del sistema se evalúan los posibles requerimientos que se deben cumplir para que el software pueda ejecutarse de manera optima.
En el análisis de requisitos del software se evalúan los requisitos que el software necesita para funcionar adecuadamente.
En el diseño se efectúan las estructuras tanto de interfaz como de código que se requieren. 
La codificación es la etapa en la que se procede a crear el el programa o en la parte en la que se modifica y mejora el código ya existente
Finalmente la entrega es la etapa "final" en la que se proporciona el producto final del ciclo al usuario.
Una vez entregado el producto se evalúan las opiniones del cliente, para tomarlas en cuenta en el siguiente incremento y se regresa a la fase de analisis de requisitos del software para volver a evaluar los requisitos del software actuales, se sigue con las siguientes fases y se vuelve a empezar el ciclo cuantas veces sea necesario para generar un producto final que satisfaga todas las necesidades del cliente.



___________________________________________________
EJEMPLO:
 Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple). 
 En un segundo incremento se le podría agregar edición más sofisticada, y degeneración y mezcla de documentos. 
 En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.
Conclusion
REFERENCIAS
Título: 
Link: 
Autor:
Fecha de publicacion:
Fecha de recuperacion: