1) Los proyectos de software enfrentan problemas como la creciente complejidad de los productos, plazos demorados y exigencias de mayor productividad y calidad en menos tiempo, así como escasez de personal calificado.
2) Las causas comunes del fracaso de proyectos de software incluyen planificación irrealista, mala calidad del trabajo debido a prácticas deficientes, personal inadecuado y falta de control de cambios.
3) Para mejorar el proceso de desarrollo de software, las organizaciones deben adoptar una disciplina de ingenier
La presentación Fundamentos de Calidad del Software - Modelos y Estándares, contiene elementos que permiten hacerse a una idea del contexto en el que se mueve el aseguramiento de la calidad del software en sus dos manifestaciones (procesos y producto) y en sus dimensiones de gestión y desarrollo.
Luis Eduardo Peláez Valencia
luiseduardo.pelaez@gmail.com
Keywords: SQA, Aseguramiento de la calidad del software, Calidad del software, Modelos y Estándares.
La presentación Fundamentos de Calidad del Software - Modelos y Estándares, contiene elementos que permiten hacerse a una idea del contexto en el que se mueve el aseguramiento de la calidad del software en sus dos manifestaciones (procesos y producto) y en sus dimensiones de gestión y desarrollo.
Luis Eduardo Peláez Valencia
luiseduardo.pelaez@gmail.com
Keywords: SQA, Aseguramiento de la calidad del software, Calidad del software, Modelos y Estándares.
A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assuran...dheimann5
The IEEE is in the process of updating and adding significant content to its IEEE-730-2002 standard on Software Quality Assurance (SQA). The new version will coordinate with the four process areas and sixteen SQA tasks in the IEEE-12207-2008 standard “Systems and Software Engineering: Software Life Cycle Processes”, providing detailed elaborations for these areas and tasks.
The presentation provides a brief overview of these areas and tasks, discuss the difference between SQA and testing, and cover the annexes in IEEE 730 that provide industry-specific information as well as the relationships with software process approaches such as CMMI, Agile, SPICE, CSQE, PMBOK, and VSEs.
Hoy en dia es importante conocer como evoluciona la ingenieria del software, cuales son sus caracteristicas y cual es su objetivo dentro del desarrollo de proyectos, para lo cual ponemos a disposicion la siguente presentacio.
AUTORES:
Fabricio Sanchez
Patricia Flores
En este documento encontraremos los aspectos básicos que se deben tener en cuenta al momento de implementar un modelo SQA en el desarrollo de Software.
Presentación del taller sobre la Metodología de la Red Nacional de Integración y Desarrollo de Software Libre (MeRinde), realizada en el Sexto Congreso Nacional de Software Libre, en fecha 16 de Abril de 2010, instalaciones de la Universidad Bolivariana de Venezuela,
MeRinde más comunitaria que nunca
Cuando uno es mochilero busca diferentes maneras de ahorrar.
Llegar a Maccu Picchu casi si dinero fue el desafío más increíble que he vivido y hoy les comparto lo aprendido.
A disfrutar!!
No se olviden de visitar:
ValorCreativo.blogspot.com
En este informe, se busca mostrar como reconocer una buena película a partir de números, ideal para saber cuando ir al cine o no.
ValorCreativo.blogspot.com
En este informe, se busca mostrar como reconocer una buena película a partir de números, ideal para saber cuando ir al cine o no.
ValorCreativo.blogspot.com
Una revista de la zona de Mar del Plata, Argentina que busca ser de interés general y encontrar la manera de comunicar la historia, servicios y promociones de los comercios a los clientes.
Una revista de la zona de Mar del Plata, Argentina que busca ser de interés general y encontrar la manera de comunicar la historia, servicios y promociones de los comercios a los clientes.
1. Problemas de la Industria de Software en la
actualidad
1 Tendencia al crecimiento del
volumen y complejidad de
los productos.
2 Proyectos excesivamente tardes y se
exige mayor productividad y calidad
en menos tiempo.
3 Insuficiente personal calificado.
2. ¿ Por qué fallan los Proyectos
? de Software?
1 Planificación Irreal
2 Mala Calidad del Trabajo
3 Personal Inapropiado
4 No Controlar los Cambios
2
3. Planificación Irreal 1
“El sistema es para hoy y con costo 0”
Los ingenieros no son capaces de
enfrentar un plan porque:
• NO están entrenados para usar
métodos de planificación.
• Frecuentemente, las estimaciones NO
se basan en datos reales.
3
4. 2
Mala Calidad del Trabajo
CAUSAS
•Prácticas pobres de ingeniería
•Carencia de métricas de calidad
•Inadecuado entrenamiento en
calidad
•Decisiones de los directivos guiadas
4
5. 2
Mala Calidad del Trabajo
CONSECUENCIAS
• Tiempos de pruebas impredecibles
• Productos con muchos defectos
• Demoras en la aceptación de los usuarios
• Extensa garantía de servicio y reparaciones
“Una pobre calidad afecta la
planificación y torna ineficente el
proceso de prueba”
5
6. 3
Personal Inapropiado
• Demora del personal
PROBLEMAS • Escaso personal
COMUNES • Miembros del equipo a tiempo parcial
• Personal con conocimientos
inapropiados
• El trabajo se demora o descuida
CONSECUENCIAS • Trabajo ineficiente
• Sufre la moral del equipo
Con independencia del plan, los
proyectos deben comenzar en tiempo y
con todo el personal.
6
7. Cambios NO controlados 4
HECHOS a RECORDAR:
• Siempre ocurren cambios en los requerimientos.
• Los planes del proyecto se basan en el alcance
del trabajo conocido.
• Los cambios siempre requieren más trabajo.
• Sin planes detallados, los equipos no pueden
estimar el efecto o magnitud de los cambios.
• Si los equipos no controlan cada cambio, se
pierde gradualmente el control del plan del
proyecto
7
8. ? ¿Cómo enfrentarla?
Las organizaciones requieren:
1 Desarrollar o adquirir una disciplina
en el desarrollo del software.
2 Controlar que los ingenieros usen de
forma consistente los nuevos
métodos.
8
9. Cómo?
¿Qué debe hacer una
empresa para obtener
software de buena
calidad?
Mejorar el proceso de
desarrollo de software
10. Cualquier modelo de calidad para
mejorar el Proceso de Desarrollo de
Software, IMPLICA utilizar los
métodos y procedimientos de
INGENIERIA Y GESTION DE
SOFTWARE
10
11. ¿Qué es la Ingeniería de Software (IS)?
“...la aplicación de un enfoque
sistémico, disciplinado y
cuantificable hacia el desarrollo,
funcionamiento y mantenimiento
de software, es decir la aplicación
de ingeniería al software”
IEEE,1993
11
12. IS es una tecnología multicapa
Indican cómo construir
técnicamente el Sw.
Soporte automático o
semiautomático para el
proceso y los métodos.
Es el fundamento de la
IS. Es la unión que
mantiene juntas las
capas de la tecnología.
12
13. Síntomas - Causas
Síntomas Diagnóstico Causas
• necesidades usuarios • requerimientos insuficientes
• requerimientos cambiantes • comunicación ambigua
• módulos no calzan • arquitecturas frágiles
• poco mantenible • complejidad excesiva
• tardía detección • inconsistencias no detectadas
• baja calidad • prueba pobre
• baja performance • evaluación subjetiva
• versiones y cambios • desarrollo en cascada
• liberación y distribución • cambios no controlados
• automatización insuficiente
...tratar los Síntomas no resuelve el problema 13
14. Las Mejores Prácticas de la IS
atacan las causas
Desarrolle Iterativamente
Administre Use Verique
Requerimientos arquitectura Modele Calidad
de Visualmente
componentes
Controle Cambios
14
15. Mejores Prácticas de Software
Son propuestas de desarrollo probadas
comercialmente, que usadas en forma
combinada atacan la raíz de las causas de
las fallas, eliminando los síntomas y
permitiendo el desarrollo y mantenimiento de
software de calidad de manera predictiva y
reiterativa.
15
16. Mejores Prácticas: Equipos de Alto
Rendimiento
Resultado
• Proyectos más exitosos
Ing. de
porque están en plazo, en Performance
presupuesto y satisfacen Analisis
las necesidades del
usuario Jefe de
Develop Iteratively Proyecto
Desarrollador
Use Model
Manage Component Visually Verify
Requiremen Architectures Quality Probador
ts
Control Changes
Liberación y Distribución
16
17. Enfrentando las Causas se eliminan los Síntomas
SÍNTOMAS CAUSAS MEJORES PRÁCTICAS
Requerimientos desarrolle iterativamente
necesidades usuarios
insuficientes
requerimientos adm. requerimientos
Comunicación ambigua
cambiantes use arquitectura de
arquitecturas frágiles componetes
módulos no calzan
complejidad excesiva modele el software
poco mentenible
inconsistencias no visualmente
tardía detección
detectadas verifique calidad
baja calidad
testing pobre controle cambios
baja performance
evaluación subjetiva
versiones y cambios
desarrollo en cascada
liberación y distribución
cambios no controlados
automatización insuficiente
17
18. Mejores Prácticas se refuerzan entre si
Asegura participación del usuario Administre
mientrás evolucionan requerimientos Requerimientos
Valida tempranamente Use
Arquitecturas
las decisiones arquitectónicas
de Componentes
Desarrolle Pemite manejar la complejidad Modele
Iterativamente Visualmente
de diseñar incrementalmente
Mide la calidad en forma oportuna Verique
y frecuente Calidad
Evoluciona la línea base Controle
incrementalmente Cambios
18