Ciclo de vida del SW empresarial

Dr. Hugo A. Banda Gamboa
CORDICYT
2014

 Un proceso para el desarrollo de software, también
denominado ciclo de vida del desarrollo es una estructura
aplicada a la construcción de un producto de software.
 Hay varios modelos a seguir para el establecimiento de
un proceso para el desarrollo de software, cada uno de los
cuales describe un enfoque diferente para diferentes
actividades que tienen lugar durante el proceso.
 Algunos autores consideran un modelo de ciclo de vida
un término más general que un determinado proceso para
el desarrollo de software.
 El estándar internacional que regula el método de
selección, implementación y monitoreo del ciclo de vida
del software es la norma ISO 12207.
© Dr. Hugo A. Banda Gamboa - 2014 2

 El Ciclo de Vida del Software
 Procesos Principales
 Procesos de Apoyo
 Procesos Organizativos
 Arquitectura del Software
 Ingeniería del Software
 Conclusión
 Referencias

 Esta norma establece un marco de referencia para
los procesos del ciclo de vida del software.
 Contiene procesos, actividades y tareas para
aplicar durante la adquisición de un sistema que
contiene software, un producto software o un
servicio software y durante el suministro,
desarrollo, operación y mantenimiento de
productos software.
 Incluye un proceso que se puede emplear para
definir, controlar y mejorar los procesos del ciclo
de vida del software.

 La norma ISO/IEC 12207 agrupa actividades
que se pueden llevar a cabo durante el ciclo de
vida del software en 5 procesos principales, 8
procesos de apoyo y 4 procesos organizativos.
 Cada proceso está subdividido en actividades y
cada actividad se subdivide en tareas.
 El siguiente gráfico presenta los procesos
numerados de acuerdo con la sección en la que
la norma hace referencia a las definiciones,
actividades y tareas.

 Proceso de Adquisición
 Define las actividades del adquiriente, la organización
que adquiere un sistema, producto o servicio software.
 Proceso de Suministro
 Define las actividades del proveedor, organización que
proporciona un sistema, producto o servicio software al
adquiriente.

 Proceso de Desarrollo
 Define las actividades del desarrollador,
organización que define y desarrolla el producto
software.

 Proceso de Operación
 Define las actividades del operador, organización que
proporciona el servicio de operar un sistema informático en
su entorno real, para sus usuarios.
 Proceso de Mantenimiento
 Define las actividades del responsable de mantenimiento,
organización que proporciona el servicio de mantenimiento
del producto software.

 Proceso de Documentación
 Define las actividades para el registro de la información producida por un
procesos del ciclo de vida.
 Proceso de Gestión de la Configuración
 Define las actividades para identificar, definir y establecer la línea base de los
elementos SW de un sistema; controlar modificaciones y versiones de los
elementos.
 Proceso de Aseguramiento de la Calidad
 Define las actividades para asegurar que los productos SW y los procesos son
conformes a sus requerimientos y se ajustan a sus planes establecidos.
 Proceso de Verificación
 Define las actividades (para el adquiriente, proveedor o una parte independiente)
para verificar hasta un nivel de detalle dependiente del proyecto SW, los
productos SW.
 Proceso de Validación
 Define las actividades (para el adquiriente, proveedor o una parte independiente)
para validar los productos SW del proyecto SW.
 Proceso de Revisión Conjunta
 Define las actividades para evaluar el estado y productos de una actividad.
 Proceso de Auditoría
 Define las actividades para determinar la conformidad con los requerimientos,
planes y contrato.
 Proceso de Solución de Problemas
 Define las actividades para analizar y eliminar los problemas (incluyendo las no
conformidades) que sean descubiertos durante la ejecución del proceso de
desarrollo, operación, mantenimiento y otros.

 Proceso de Gestión
 Define las actividades básicas de gestión, incluyendo la gestión de proyectos,
durante un proceso del ciclo de vida.
 Proceso de Infraestructura
 Define las actividades básicas para establecer la infraestructura de un proceso del
ciclo de vida.
 Proceso de Mejora de Procesos
 Define las actividades básicas que una organización (adquiriente, proveedor,
desarrollador, operador, responsable de mantenimiento o gestor de otro proceso)
debe llevar a cabo para establecer, medir, controlar y mejorar sus procesos del ciclo
de vida.
 Proceso de Recursos Humanos
 Define las actividades básicas para conseguir personal adecuadamente capacitado.

 La ingeniería de requerimientos es un proceso que comprende
todas las actividades para crear y mantener los requerimientos
de un sistema, contando con la activa participación de los
interesados:
 Los interesados a menudo sólo conocen lo que desean en términos muy
generales.
 Los interesados expresan los requerimientos con sus propios términos
y con un conocimiento implícito de su propio trabajo.
 Diferente interesados tienen requerimientos distintos y los expresan de
varias formas.
 Influencia de factores políticos.
 El entorno es dinámico, la importancia de los requerimientos puede
cambiar, nuevos requerimientos pueden surgir.
 Comprende cuatro actividades de alto nivel:
 Estudio de factibilidad
 Obtención y análisis de requerimientos
 Validación de requerimientos
 Administración de requerimientos

 ISO / IEC / IEEE 29148:2011 contiene disposiciones relativas a
los procesos y productos relacionados con la ingeniería de
requerimientos de los sistemas y productos de software y
servicios en todo el ciclo de vida.
 Define la construcción de requisitos, proporciona los atributos y
características de los requisitos, y se analiza la aplicación
iterativa y recursiva de los procesos de requisitos durante todo
el ciclo de vida.
 ISO / IEC / IEEE 29148:2011 proporciona orientación adicional
para la aplicación de los procesos de requisitos de ingeniería y
de gestión de las actividades relacionadas con los requisitos de
la norma ISO / IEC 12207:2008 e ISO / IEC 15288:2008.
 El contenido de la norma ISO / IEC / IEEE 29148:2011 se puede
añadir al conjunto existente de los procesos del ciclo de vida
relacionados con los requisitos definidos por la norma ISO /
IEC 12207:2008 o ISO / IEC 15288:2008, o se puede utilizar de
forma independiente.

 Una de las principales preocupaciones en el
desarrollo de sistemas de software es la calidad.
 Durante los últimos años, la Arquitectura de
Software se ha convertido en el concepto
adecuado para lograr calidad en el software
desarrollado.
 Esto se debe a que las comunidades científicas e
industriales han reconocido que la arquitectura de
software establece los límites para las cualidades
del software del sistema resultante.

 IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems
 Esta recomendación práctica se ocupa de las
actividades de la creación, análisis, mantenimiento
de las arquitecturas de sistemas intensivos en
software, y el registro de las descripciones
arquitectónicas.
 Establece un marco conceptual para la descripción
arquitectónica del software y la definición de su
contenido.
 Los anexos proporcionan el fundamento de los
conceptos clave y la terminología, las relaciones
con otros estándares y ejemplos de uso.

 La arquitectura de
software es la
especificación de la
estructura de una
solución, el
comportamiento de
los elementos
estructurales, que se
estiman y se
especifican para
cumplir con los
objetivos estratégicos
del negocio.
IEEE Std 1471-2000

 El objetivo del análisis de la arquitectura de
un sistema de software es predecir la calidad
de un sistema antes de que sea construido.
No trata de establecer estimaciones precisas,
sino los principales efectos de una
arquitectura.
 El propósito de la evaluación es analizar la
arquitectura de SW para identificar los
riesgos potenciales y verificar que los
requisitos de calidad que se han abordado en
el diseño.

SAAM: Scenario-based Architecture Analysis Method SAAMCS: SAAM Founded on Complex Scenarios
ESAAMI: Extending SAAM by Integration in the Domain SAAMER: Software Architecture Analysis Method for Evolution and Reusability

ATAM: The Architecture Trade-Off Analysis Method SBAR: Scenario-Based Architecture Reengineering
ALPSM: Architecture Level Prediction of Software Maintenance SAEM: Software Architecture Evaluation Model

 En resumen, el propósito de la evaluación es analizar la
arquitectura de SW para identificar los riesgos
potenciales, mediante la predicción de la calidad del
sistema antes de que este sea construido.
 En todos los métodos propuestos se distingue, como
objetivo general, la identificación de riesgos potenciales.
 En este sentido, el uso de escenarios de cambio y la
interacción de escenarios revelan áreas de problemas
potenciales en la arquitectura. El grado de modificación
capturado cuando se evalúa la respuesta de un sistema a
un escenario representa un riesgo medido.
 La complejidad de escenarios es también un factor
importante para la evaluación de riesgos.

 Ingeniería de software es la aplicación
práctica del conocimiento científico al diseño
y construcción de programas de computadora
y a la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce
también como desarrollo de software o
producción de software.
 La ingeniería de software aplica diferentes
normas y métodos que permiten obtener
mejores resultados, en cuanto al desarrollo y
uso del software.

 Mejorar el diseño de aplicaciones o productos software de tal
modo que se adapten de mejor forma a las necesidades de las
organizaciones o finalidades para las cuales fueron creadas.
 Promover mayor calidad al desarrollar aplicaciones complejas.
 Reducir los costos de proyectos y cumplir con el tiempo de
desarrollo de los mismos.
 Aumentar la eficiencia de los sistemas al introducir procesos
que permitan medir mediante normas específicas, la calidad del
software desarrollado, buscando siempre la mejor calidad
posible según las necesidades y resultados que se quieran
lograr.
 Organizar los equipos de trabajo, en el área de desarrollo y
mantenimiento de software.
 Detectar a través de pruebas, posibles mejoras para un mejor
funcionamiento del software desarrollado.

 La reutilización sistemática del software es un
enfoque prometedor para reducir el costo y el tiempo
del ciclo de desarrollo, mejorar la calidad del
software y la productividad.
 En este contexto, la noción de la línea de productos de
software ha ganado importancia para la reutilización
sistemática del software a gran escala.
 La línea de productos de software es un conjunto de
sistemas intensivos en software que comparten un
conjunto común y gestionado de características que
especifican las necesidades específicas de un
segmento de mercado y que se desarrollan a partir de
un conjunto común de componentes.

 Standard for Information Technology—System
and Software Life Cycle Processes—Reuse
Processes, IEEE, 2010.
 Esta norma especifica los procesos, actividades y tareas
que deben aplicarse en cada fase del ciclo de vida del
software para permitir que un producto de software sea
construido a partir de activos reutilizables.
 Abarca el concepto de desarrollo basado en la
reutilización y los procesos de construcción para la
reutilización, así como la construcción con la
reutilización.

 Es un paradigma para desarrollar líneas de
productos de software, y como tal, soporta la
reutilización, la productividad y la calidad de los
sistemas.
 A diferencia de los paradigmas del desarrollo de
software convencionales que tienen como objetivo el
desarrollo de sistemas individuales, SPLE considera
el desarrollo de una familia de sistemas de software.
Como tal SPLE adopta un enfoque de ciclo de vida
del software fundamentalmente diferente al
desarrollo de un sistema individual.

 El patrón que configura la hoja de ruta para la
adopción de una estrategia de ingeniería de
línea de productos de software, está basado
en las siguientes dimensiones:
 Fases de adopción
 Áreas de enfoque
 Áreas de práctica
 Salidas
 Roles

Fases de Adopción
ÁreasdeEnfoque
Áreas de Práctica

 La usabilidad es la cualidad de un sistema respecto a:
 Su facilidad de uso: múltiples formas de intercambiar
información entre los involucrados y el sistema
 Su facilidad de aprendizaje para nuevos usuarios que
garantizan interacción efectiva y máximas prestaciones
 La satisfacción del usuario incluyendo el soporte al usuario
para garantizar las metas (robustez)
 Factores que contribuyen a la usabilidad:
 Que sea efectivo
 Que sea eficiente
 Que sea seguro
 Que sea útil
 Que se pueda aprender fácilmente
 Que sea fácil de recordar cómo se usa

 Usabilidad se define en el estándar ISO 9241 como “el
grado en el que un producto puede ser utilizado por
usuarios específicos para conseguir objetivos
específicos con efectividad, eficiencia y satisfacción en
un determinado contexto de uso”, y en el estándar ISO
14598-1 se define calidad de uso de forma análoga.
 El término de Ingeniería de la Usabilidad se refiere a
los conceptos y técnicas para planificar, conseguir y
verificar objetivos de la usabilidad de sistema.
 La idea principal es que los objetivos medibles de
usabilidad deben ser definidos tempranamente, para
después irlos evaluando repetidamente durante el
desarrollo del sistema, para asegurar que se los ha
conseguido.

 Sobre la base de la teoría de la acción razonada, Davis [8]
desarrolló el Modelo de Aceptación de Tecnología que se
ocupa más específicamente con la predicción de la
aceptabilidad de un sistema de información.
 El propósito de este modelo es predecir la aceptabilidad
de una herramienta e identificar las modificaciones que
deben introducirse en el sistema con el fin de hacer que
sea aceptable para los usuarios.
 Este modelo sugiere que la aceptación de un sistema de
información está determinada por dos factores principales:
la utilidad y la facilidad de uso percibidas.

 Un notable refinamiento del modelo TAM es
propuesto por McFarland y Hamilton [9].
 Su modelo supone que 6 variables contextuales
(experiencia previa, el uso de otros, ansiedad,
calidad del sistema, estructura de la tarea, y el
apoyo de la organización) afectan la variable
dependiente del uso del sistema mediante 3
variables mediadoras (eficacia computacional,
facilidad de uso percibida y la utilidad
percibida).
 El modelo también postula una relación directa
entre las variables externas y el uso del sistema.

Cuando comienzas a intentar resolver un
problema, las primeras soluciones que se te
vienen a la cabeza son muy complejas y por
eso la mayor parte de la gente se queda
parada cuando llega a este punto. Pero si
sigues, vives con el problema y pelas más
capas de la cebolla, llegas a menudo a
soluciones muy elegantes y muy simples.
- Steve Jobs

1. ISO/IEC 12207. Tecnología de la Información. Procesos del Ciclo de Vida del
Software. 2006.
2. ISO / IEC / IEEE 29148:2011. Systems and software engineering —Life cycle
processes — Requirements engineering. 2011.
3. IEEE Std 1471-2000. IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems. IEEE-SA Standards Board, September 2000.
4. Liliana Dobrica and Eila Niemela. A Survey on Software Architecture Analysis
Methods. IEEE Transactions on Software Engineering, Vol. 28, No. 7, July 2002
5. Benet Campderrich Falgueras. Ingeniería del Software. Editorial UOC, Abril 2003.
6. IEEE Std. 1517-2010. Standard for Information Technology—System and
Software Life Cycle Processes—Reuse Processes. IEEE, 2010.
7. Linda M. Northrop. Software Product Line Adoption Roadmap. TECHNICAL
REPORT, CMU/SEI-2004-TR-022. September 2004.
8. F. Davis; R. Bagozzi and R. Warshaw. User Acceptance of Computer Technology:
A Comparison of two Theoretical Models. Management Science, Volume 35, 1989,
pp. 982-1003.
9. D. McFarland & D. Hamilton. Adding contextual specificity to the technology
acceptance model. Computers in Human Behavior, 22(3), 2006, 427-447.

Ciclo de vida del SW empresarial

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (15)

Similar a Ciclo de vida del SW empresarial

Similar a Ciclo de vida del SW empresarial (20)

Más de Hugo Banda

Más de Hugo Banda (14)

Último

Último (20)

Ciclo de vida del SW empresarial