Date post: | 12-Apr-2017 |
Category: |
Engineering |
Upload: | hugo-banda |
View: | 249 times |
Download: | 0 times |
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
© Dr. Hugo A. Banda Gamboa - 2014 3
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.
© Dr. Hugo A. Banda Gamboa - 2014 5
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.
© Dr. Hugo A. Banda Gamboa - 2014 6
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.
© Dr. Hugo A. Banda Gamboa - 2014 8
Proceso de Desarrollo
Define las actividades del desarrollador, organización que define y desarrolla el producto software.
© Dr. Hugo A. Banda Gamboa - 2014 9
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.
© Dr. Hugo A. Banda Gamboa - 2014 10
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.
© Dr. Hugo A. Banda Gamboa - 2014 11
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.
© Dr. Hugo A. Banda Gamboa - 2014 12
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
© Dr. Hugo A. Banda Gamboa - 2014 13
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.
© Dr. Hugo A. Banda Gamboa - 2014 14
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.
© Dr. Hugo A. Banda Gamboa - 2014 16
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.
© Dr. Hugo A. Banda Gamboa - 2014 17
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.
© Dr. Hugo A. Banda Gamboa - 2014 18
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.
© Dr. Hugo A. Banda Gamboa - 2014 19
© Dr. Hugo A. Banda Gamboa - 2014 20
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
© Dr. Hugo A. Banda Gamboa - 2014 21
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.
© Dr. Hugo A. Banda Gamboa - 2014 23
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.
© Dr. Hugo A. Banda Gamboa - 2014 25
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.
© Dr. Hugo A. Banda Gamboa - 2014 26
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.
© Dr. Hugo A. Banda Gamboa - 2014 27
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.
© Dr. Hugo A. Banda Gamboa - 2014 28
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.
© Dr. Hugo A. Banda Gamboa - 2014 29
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
© Dr. Hugo A. Banda Gamboa - 2014 30
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
© Dr. Hugo A. Banda Gamboa - 2014 34
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.
© Dr. Hugo A. Banda Gamboa - 2014 35
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.
© Dr. Hugo A. Banda Gamboa - 2014 36
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.
© Dr. Hugo A. Banda Gamboa - 2014 37
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
© Dr. Hugo A. Banda Gamboa - 2014 39
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.
© Dr. Hugo A. Banda Gamboa - 2014 40