Download pdf - Ciclo de vida del SW empresarial

Dr. Hugo A. Banda GamboaCORDICYT

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 ScenariosESAAMI: 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 ReengineeringALPSM: 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

Áre

as

de E

nfo

qu

e

Á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.
