Guia Ingenieria Del Software i

UNIVERSIDAD TECNOLÓGICA “SAN ANTONIO DE MACHALA”

ESCUELA DE INFORMÁTICA

MODALIDAD DE EDUCACIÓN SEMIPRESENCIAL Y A DISTANCIA

GUÍA DE ESTUDIO

INGENIERÍA DE SOFTWARE I

QUINTO SEMESTRE

ING. BERTHA MAZÓN

2009

EL ORO – ECUADOR


TABLA DE CONTENIDO

Introducción………………………………………………….……………………………….

2

Información general……...………………………………………….………………………

5

Problema, objeto, objetivos……………………………………………………..………….

6

Sistema de contenidos………………………………………………………………….…..

7

Bibliografía……………………………………………………………………………………

9

Estrategias Metodológicas.…………………………………………………………………

11

Sistema de Evaluación……………………………………………………………………...

13

Actividades de Aprendizaje…………….……....…………………………………………..

14

UTSAM-Modalidad Semipresencial y a Distancia


Con la perseverancia se obtiene la fortaleza y esto nos permite, no dejarnos llevar por lo fácil y lo cómodo.

Bertha Mazón

Querido estudiante….!

Empezar una nueva asignatura representa reafirmar el compromiso que al principio te propusiste, y al igual que muchos que iniciaron esta modalidad, te encuentras entre aquellos que lograron las metas iníciales.

Estudiar una profesión como sistemas en modalidad semipresencial o a distancia no es fácil, tus propósitos deben mantenerse firmes, debes levantarte al caer y gozar del triunfo que acompaña al trabajo terminado.

Vamos a iniciar el estudio de INGENIERÍA DE SOFTWARE I, cuyo requisito es Bases de Datos I y Programación Visual I. En esta asignatura iniciamos con el aprendizaje y el desarrollo de habilidades concernientes al desarrollo de un proyecto de software.

Ahora, con tus aprendizajes podrás desarrollar software para empresas y/u organizaciones, logrando alcanzar el nivel que en nuestra Institución exigimos a los futuros ingenieros de sistemas.

El objetivo de esta asignatura es desarrollar software de calidad que resuelvan problemas de todo tipo, aplicando métodos, técnicas y herramientas del proceso de ingeniería de software como análisis, diseño e implementación y los conocimientos adquiridos de programación, sistemas operativos, bases de datos y redes de computadoras, para lo cual dividiremos el contenido temático en cuatro temas que son:TEMA I: INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE. Nos permitirá caracterizar los conceptos, elementos y procesos de la Ingeniería de Software.

TEMA II: INGENIERÍA DE REQUISITOS. Con este tema te prepararás para realizar la especificación de los requisitos de software del problema planteado.

UTSAM-Modalidad Semipresencial y a Distancia 3

INTRODUCCIÓN


TEMA III: GESTIÓN DE PROYECTOS DE SOFTWARE. Aprenderás a desarrollar la gestión del proyecto de software mediante la elaboración de la planificación del proyecto, el análisis de riesgos, la configuración del software y el control de calidad que permita desarrollar un producto que satisfaga las necesidades del cliente.

TEMA IV: ANÁLISIS DEL SOFTWARE: Con este tema serás capaz de elaborar el modelado del software según el enfoque estructurado mediante el estudio y análisis de los requisitos del usuario.

Así querido amigo, lograremos alcanzar el 90% de una de las principales habilidades del ingeniero de sistemas, el desarrollo, por lo que te pido considerar las sugerencias y sobretodo asistir con puntualidad a los encuentros programados.

En este curso utilizarás herramientas como: Microsoft Project, Erwin y Visual CASE.

Recordemos la misión y visión de nuestra institución en esta modalidad:

MisiónA través de la modalidad semiprensencial y a distancia la Universidad tiene el compromiso de formar profesionales e investigadores, competitivos, creativos y humanistas, con capacidad de liderazgo, pensamiento crítico y reflexivo, capaces de participar activamente en el fortalecimiento de las capacidad es productivas y de servicio.

VisiónBrindar el acceso del sector a los procesos de educación superior, generando una nueva orientación de su vinculación con la comunidad local, regional y nacional, demostrando la apertura de la Institución de servir a la comunidad.

Recibe pues, un fuerte abrazo de bienvenida y los deseos más sinceros de ayuda de tal manera que pueda aportar con un granito de arena a tu formación profesional.

Bienvenido….a estudiar Ingeniería de Software…!!!!!!!!!!!



Bertha Mazón.



DATOS GENERALES Escuela : INFORMÁTICA. Especialidad : Ingeniería en Sistemas. Asignatura : Ingeniería de Software I. Número de créditos : 7 Total Horas : 112 Hrs.

Docente : …………………………………………… Teléfono : ………………………. E-mail : …………………………………………….

Las fechas de las jornadas presenciales confírmelas en su centro universitario, Coordinación de Educación a distancia (UTSAM-EAD)

Le recomendamos que desde el momento en el que disponga del material bibliográfico inicie el desarrollo de las actividades propuestas en esta Guía de estudio.

FUNDAMENTACIÓN DE LA ASIGNATURA

Cuando un software de computadora se desarrolla con éxito, satisface las necesidades de las personas que lo utilizan, funciona impecablemente durante mucho tiempo, es fácil de modificar o incluso es más fácil de utilizar, puede cambiar todas las cosas y de hecho las cambia para mejorar. Para tener éxito al diseñar y construir un software se necesita disciplina. Es decir, se necesita un enfoque de ingeniería

La Ingeniería de software es un área de informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelve problemas de todo tipo. Hoy en día es cada vez más frecuente la consideración de la Ingeniería de Software como una nueva área de la ingeniería y es una profesión implantada en el mundo laboral nacional e internacional.

Es por esta razón que esta materia pasa hacer troncal o fundamental para los estudiantes de la carrera de Ingeniería en Sistemas de la Escuela de Informática de la UTSAM, la misma que permitirá desarrollar habilidades y destrezas en el análisis, diseño e implementación de software resolviendo todo tipo de problema.


INFORMACIÓN GENERAL


PROBLEMA

La necesidad de aplicar los procesos de ingeniería de software para el desarrollo de soluciones informáticas de calidad que resuelvan problemas de todo tipo en empresas e instituciones

OBJETO

El proceso de ingeniería de software

OBJETIVOS

INSTRUCTIVO

Al terminar el estudio de la asignatura el estudiante estará en capacidad de:

Desarrollar software de calidad que resuelvan problemas reales de organizaciones, aplicando métodos, técnicas y herramientas del proceso de ingeniería de software como análisis, diseño e implementación para la obtención de un sistema informático de calidad y la satisfacción del usuario.

EDUCATIVO

Fomentar en los estudiantes la práctica de valores como la responsabilidad, honestidad, criticidad, equidad y compañerismo, en el desarrollo de sistemas informáticos para empresas e instituciones considerando su realidad socio-económica y los avances tecnológicos.

COMPETENCIA

Desarrollo de software de calidad considerando métodos, técnicas y herramientas del proceso de ingeniería de software como análisis, diseño e implementación, con actitud profesional y mentalidad positiva.


PROBLEMA, OBJETO, OBJETIVO

SISTEMA DE CONTENIDOS


TEMA I: INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE (ISW)OBJETIVO: Conceptualizar terminología y modelos de Ingeniería de Software.COMPETENCIA: Conceptualiza terminología y describe modelos de la ISW .DURACIÓN: (16 horas)

SISTEMA DE CONOCIMIENTOS SISTEMA DE HABILIDADES SISTEMA DE VALORES

- Conceptos: software, ingeniería de software, producto, proceso, método, técnica, metodología, herramienta, paradigma (modelo o ciclo de vida).

- Actividades genéricas de la ingeniería de software

- Modelos de la ingeniería del software

- Evolución de la ingeniería de software

- Crisis del software- Principales

organizaciones de estandarización de la ingeniería del software

- Principales estándares de la ingeniería del software.

- Conceptualizar terminología referente a la ingeniería del software.

- Caracterizar los modelos (paradigmas o ciclos de vida) de desarrollo del software.

- Diferenciar el producto y el proceso

- Describir la evolución de la ingeniería del software y la crisis del software

- Describir las principales organizaciones de estandarización y los estándares que se promueven

ResponsabilidadCriticidadHonestidadCompañerismo

TEMA II: INGENIERÍA DE REQUISITOSOBJETIVO: Realizar la especificación de los requisitos de software del problema

planteado.COMPETENCIA: Redacta documentos de especificación del software.DURACIÓN: (32 horas)

SISTEMA DE CONOCIMIENTOS SISTEMA DE HABILIDADES

SISTEMA DE VALORES

Conceptos de Ingeniería de RequisitosDescripción de las actividades del proceso de la IR- Obtención de requisitos- Análisis de requisitos - Especificación de Requisitos

según el estándar de IEEE 830

- Identificar y recolectar requisitos

- Validar y gestionar requisitos

- Elaborar los requisitos del software

ResponsabilidadCriticidadHonestidad



- Validación de requisitos- Gestión de requisitos

TEMA III: GESTIÓN DE PROYECTOS DE SOFTWAREOBJETIVO: Gestionar el proyecto de software mediante planificación, seguimiento y

control del proceso de desarrollo de software y la realización de actividades de soporte como: análisis de riesgos, configuración del software y control de calidad que permita la construcción de un producto que satisfaga las necesidades del cliente.

COMPETENCIA: Gestiona proyectos de software. DURACIÓN: (48 horas)


SISTEMA DE VALORES

CONCEPTOS SOBRE GESTIÓN DE PROYECTOS DE SOFTWARE- El espectro de gestión, el

personal, el producto, el proceso, el proyecto

- Gestionar el personal, el proceso y el problema durante el proyecto de software

ResponsabilidadCompañerismoHonestidad

PLANIFICACIÓN DEL PROYECTO DE SOFTWARE- Objetivos de la planificación

del proyecto- Ámbito del software, recursos- Estimación del proyecto de

softwareo Técnicas de puntos de

funcióno Modelos empíricos de

estimación - La decisión desarrollar-

comprar

- Identificar y generar equipos de software, estimaciones fiables del esfuerzo, costes y duración del proyecto


PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO- Conceptos básicos, la relación

entre las personas y el esfuerzo- Definición de un conjunto de

tareas para el proyecto de software.- Selección de las tareas de Ing.

SW- Refinamiento de las tareas

principales- Definir una red de tareas

- Desarrollar la planificación temporal de proyecto


ANÁLISIS DE RIEGOS- Estrategias de riesgos- Riesgos del software- Identificación y proyección del

riesgo- Reducción, supervisión y

gestión del riesgo- Riesgos y peligros para la

- Identificar y utilizar las técnicas para la evaluación de los riesgos que pueden tener impacto en el éxito del proyecto.



BIBLIOGRAFÍA


seguridadPLAN DE GARANTÍA DE CALIDAD- Introducción- Documentación- Revisiones y auditorias- Gestión de Configuración

- Definir y controlar la calidad de un proyecto


PLAN DE GESTIÓN DE CONFIGURACIÓN- Introducción- Actividades de GCS- Programación

- Identificar y realizar la forma de gestionar los cambios durante el desarrollo de software y después de entregar al cliente


TEMA IV: MODELADO DE ANÁLISIS DEL SOFTWAREOBJETIVO: Elaborar el modelado del software mediante el estudio y análisis de

los requisitos del software, las metodologías de análisis y la elaboración del prototipo que permita la obtención de modelos físicos y lógicos para el diseño del software.

COMPETENCIA: Crea modelos conceptuales del software.DURACIÓN: (16 horas)


INTRODUCCIÓN AL MODELADO- Conceptos de modelado,

utilidad, abstracción, ventajas

- Comprender la importancia del modelado de software


ANÁLISIS ESTRUCTURADO- Breve historia,

características- Elementos del modelo del

análisis- Modelado funcional o de

procesos y flujo de información(DFD’s), su notación y diccionario de datos

- Modelado de datos (ER) y su diccionario de datos

- Obtener una representación general del software a construir a partir de la especificación de los requisitos.


HERRAMIENTAS CASE (TI)- Que es CASE- Objetivos de las CASE- Elementos de las CASE- Tipos de CASE- Ejemplos de CASE

- Identificar los tipos de CASE

- Utilizar las herramientas CASE apara el desarrollo del software




TEXTO BÁSICO: Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-

Graw-Hill/Interamerica de España S.A.U. 2005

BIBLIOGRAFÍA COMPLEMENTARIA: Kendall & Kendall, Análisis y Diseño de software Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Quinta Edición.

Mc-Graw-Hill/Interamerica de España S.A.U. 2002 Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Cuarta Edición.

Mc-Graw-Hill/Interamerica de España S.A.U. 1998 Sommerville, I., "Software Engineering. 6th edition". Addison Wesley. 2000 IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements

Specifications: IEEE, 1998. Jacobson, I., Booch, G. y Rumbaugh, J., "El proceso unificado de modelado",

Addison Wesley, 2000. Rolland C. Praskash, N. “From conceptual modeling to requirement engineering”,

Annals of software engineering 10 (2000) 151-176 Amador Durán Toro, Beatriz Bernárdez Jiménez, “Metodología para el análisis de

Requisitos de Sistemas Software. Versión 2.1” Informe Técnico. Departamento de Lenguajes y Sistemas Informáticos Facultad de Informática y Estadística Sevilla, 2001

S. L. Pfleeger, "Software Engineering: Theory and Practice," Second ed: Prentice-Hall, 2001.

Palacios, Juan. Compendio de Ingeniería de SW I. Última revisión: Junio 2006. Documento Electrónico: CIS I 04.PPT.

REVISTAS TÉCNICAS Revista PC WORLD Revista PC MAGAZINE (Ingles, Español)URL’s: "SWEBOK, Software Engineering Body of Knowledge". 2004. www.swebok.org Rational. http://www.rational.com Navegapolis.net. http://www.navegapolis.net Vico.org. http://www.vico.org http://www.uag.mx/66/contenido.htm http://www.inf.udec.cl/~ingsoft/transparenciasmvc.html http://148.202.148.5/cursos/cc321/fundamentos/unidad6/tema6_4.html

Con toda esta referencia bibliográfica tú puedes ampliar tus conocimientos acerca de la temática propuesta.


http://148.202.148.5/cursos/cc321/fundamentos/unidad6/tema6_4.html

http://www.inf.udec.cl/~ingsoft/transparenciasmvc.html

http://www.uag.mx/66/contenido.htm

http://www.vico.org/

http://www.navegapolis.net/

http://www.rational.com/

http://www.swebok.org/

ESTRATEGIAS METODOLÓGICAS


Para el desarrollo de las actividades propuestas se recomienda lo siguiente:

1. Tener una actitud positiva, voluntad, motivación e interés.2. Lee reflexivamente la bibliografía básica, en ella se encuentran todos los temas de las

actividades planteadas.3. Para aprender cualquier asignatura se necesita tener una fuente de consulta a mano, por

lo tanto se recomienda leer, como mínimo, los textos básicos o guías expuestos en la bibliografía y reforzar con algunos textos complementarios.

4. Cuando hayas hecho esta primera lectura comprensiva, procede a desarrollar las actividades poniendo en práctica tu actitud crítica y reflexiva, tu capacidad de síntesis y tu creatividad.

5. Para estudiar debes elegir siempre un lugar tranquilo, cómodo con buena iluminación, y tener sobre la mesa la bibliografía básica, diccionario, papel. Esfero, etc.

6. Planifica el tiempo dedicado al sueño y a las comidas, casi todos necesitamos de 8 horas de sueño.

7. Dedica una hora por la mañana que se distribuye para: gimnasia matinal, aseo personal, vestirse desayunar.

8. Toma en cuenta las horas que son dedicadas a tu trabajo u ocupación personal. Lo importante es saber determinar el tiempo que necesitas para tus estudios.

9. Es importante que en todo este proceso cultives el valor de la constancia porque no sirve de nada tener una excelente planificación y un horario si no eres constante.

10. Utiliza fichas de trabajo o algún cuaderno de resúmenes.11. Si algún tema o problema no está claro, no dudes en llamar o ponerte en contacto con tu

profesor guía a fin de solucionar las inquietudes. Favor no quedarse con éstas porque irán formando lagunas en su aprendizaje que luego son difíciles de corregir.

12. Para los encuentros con el profesor guía revisa la última tarea realizada y a continuación lee detenidamente las instrucciones dadas en la guía de estudios, analiza y sintetiza los temas y conceptos, realiza las tareas propuestas.

Para el desarrollo de asignatura se sugiere lo siguiente:

Un cuaderno de apuntes, y un computador Pentium IV, 160 GB de disco duro y memoria RAM de mínimo 512MB

Instaladores de EasyEclipse Desktop Java 1.2.2., Microsoft Office, Mysql, Sqlyog Enterprise, herramientas de análisis y diseño de SW (CASE): Visual Case, Erwin, Micrososft Project.

Todos tus trabajos debes entregarlos en CD. Lee reflexivamente el texto guía, ahí constan todos los temas a los que corresponden

las actividades planteadas. Cuando hayas realizado ésta lectura comprensiva, procede a desarrollar las

actividades. No hagas una copia textual, sino contesta con tus propias palabras. Para realizar las actividades, además de la lectura puedes ayudarte con la técnica del

subrayado, mapas conceptuales, cuadros sinópticos, etc.



Presente el trabajo desarrollado en computadora con el formato siguiente.o Papel INEN A4, utilice sangría, márgenes, ortografíao Margen Superior : 3 cmo Margen Inferior : 2.5 cm.o Margen Izquierdo : 3.5 cm.o Margen Derecho : 2.5 cm.

Incorporamos en esta guía los siguientes gráficos para un mejor desarrollo

Orientaciones de TareaLas especificaciones para los trabajos a desarrollar como parte del proceso de aprendizaje

Resumen:Sintesis de los temas desarrollados

Nota importante:Aspectos a los que debes poner atención y que considero clave para el desarrollo de la asignatura.

Recuerde


EL TRABAJO ES PERSONAL, NO SE ACEPTARAN COPIAS NI TRABAJOS IGUALES…!

SISTEMA DE EVALUACIÓN


La evaluación será continua durante el desarrollo de las temáticas programadas y se la realizará con base en los siguientes criterios:

Aplicación de conocimientos teóricos, capacidad de análisis y síntesis Creatividad en la resolución de problemas Capacidad para seleccionar las opciones u alternativas más adecuadas en la

resolución de problemas Originalidad y cientificidad, calidad de presentación de los trabajos (limpieza, orden

etc.) Puntualidad

De acuerdo al sistema de créditos de la UTSAM:

Trabajos de encuentros presenciales (TE) 10%Trabajos de la guía de estudios(TG) 10 %Evaluación (E) 30%Nota final del crédito: Suma (TE, TG, E) 50%

Trabajos de encuentros presenciales: Defensa de trabajos de investigación, desarrollo de ejercicios en clase, talleres, debates, Exposiciones de consultas, otros

Trabajos de la guía de estudios: consultas, desarrollo de ejercicios, resúmenes, autoevaluaciones, otros

El promedio de todos los créditos (PC) corresponderá al 50% de la nota final El estudiante deberá desarrollar un PROYECTO FINAL (PF) que integre las temáticas

tratadas en la asignatura y se evaluará sobre el 50%. La nota final se obtiene sumando el promedio de los créditos y la nota del examen

(PC+PF)

Reflexiona:


¡Sólo el estudio libera al hombre de las ataduras de su

ignorancia!

INTRODUCCIÓN A LAINTRODUCCIÓN A LAINGENIERÍA DE SOFTWARE (ISW)INGENIERÍA DE SOFTWARE (ISW)

TIEMPO ESTIMADO DE ESTUDIO

INTRODUCCIÓN


SISTEMA DE CONTENIDOSSISTEMA DE CONTENIDOS


- Conceptos: software, ingeniería de software, producto, proceso, método, técnica, metodología, herramienta, paradigma (modelo o ciclo de vida).

- Actividades genéricas de la ingeniería de software

- Modelos de la ingeniería del software

- Evolución de la ingeniería de software

- Crisis del software- Principales

organizaciones de estandarización de la ingeniería del software

- Principales estándares de la ingeniería del software.

- Conceptualizar terminología referente a la ingeniería del software.

- Caracterizar los modelos (paradigmas o ciclos de vida) de desarrollo del software.

- Diferenciar el producto y el proceso

- Describir la evolución de la ingeniería del software y la crisis del software

- Describir las principales organizaciones de estandarización y los estándares que se promueven


Horas presenciales: 8Horas de investigación: 8Total horas mínimas requeridas del tema: 16Horas de actividades laborales: 8Total de Horas de estudio del tema: 24

En la actualidad, el software de computador es la tecnología más importante en el ámbito mundial, las economías de los países desarrollados dependen en gran parte del software,


ESQUEMA DEL TEMA I


más y más sistemas son actualmente controlados por software. El software es el producto que los ingenieros de software construyen y después mantienen en el largo plazo. Incluye los programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura.

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de software.

OBJETIVO

Conceptualizar terminología y modelos de Ingeniería de Software.


Para el estudio del Tema I necesitas revisar la siguiente bibliografía: Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulos: 1, 2, 3, 4; Páginas:1-99.Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Quinta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulos: 1 y 2; Páginas: 3-33.Palacios, Juan. Compendio de Ingeniería de SW I. Última revisión: Junio 2006. Documento Electrónico: CIS I 04.PPT. Capítulos 1 y 2, Diapositivas: 1- 53.

ACTIVIDADES DE APRENDIZAJE TEMA I


1.CONCEPTOS DE INGENIERÍA DE SOFTWARE

En este tema se realiza una introducción a la Ingeniería del software. Se revisan conceptos como: software, ingeniería de software, producto, proceso, actividad, tarea, paradigma, metodología, técnica, herramientas, estándares, entre otros.

Principales conceptos a tener en cuenta en la ingeniería de software

El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos. El software considerado como el producto se compone de


MétodoMétodo

TécnicaTécnica

Proceso a seguir para resolver una situación o problema con un orden y objetivos establecidos.Proceso {actividades} {tareas}

Estrategia para desarrollar una actividad de un método

MetodologíaMetodología Método + técnicas + soporte documental

HerramientaHerramienta Soporte automatizado, Ejm. CASE, CARE

ProductoProductoResultado de cada etapa o actividad, denominado también entregable


programas, datos y documentos. Cada uno de estos elementos componen una configuración que se crea como parte del proceso de la ingeniería del software.

¿Qué es la ingeniería de software? Hay diferentes autores que conceptualizan la ingeniería de software desde sus propias perspectivas, sin embargo todos guardan relación. A continuación se presentan algunos conceptos de diferentes autores:

Por ejemplo la definición que propuso Fritz Bauer en una conferencia mundial en 1968: “La ingeniería de software es el establecimiento y uso de principios de la ingeniería para obtener económicamente un software confiable y que funcione eficiente en máquinas reales”

Ingeniería del Software es la aplicación practica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación necesaria requerida para desarrollar, operar (funcionar) y mantenerlos (Bohem, 1976).

Disciplina para producir software de calidad desarrollado sobre las agendas y costes previstos y satisfaciendo los requisitos (S. Schach 1990, Software Engineering).

Ingeniería al software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software (IEEE, 1993).

La ingeniería de software es una disciplina que integra al proceso, los métodos y las herramientas para el desarrollo del software de computadora. Se ha propuesto un gran número de modelos para la ingeniería de software, pero todos definen un conjunto de actividades del marco de trabajo, una colección de tareas conducidas para realizar cada actividad, productos de trabajo generados como consecuencia de las tareas y un conjunto de actividades de soporte que acompañan el proceso entero.

Un objetivo de décadas ha sido el encontrar procesos o metodologías predecibles y repetibles que mejoren la productividad y la calidad. Los modelos prescriptitos (paradigmas o ciclos de vida) del proceso de software se han aplicado durante muchos años en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos modelos convencionales sugiere un flujo de proceso o ciclo de vida que de alguna forma es diferente, pero todos realizan un conjunto de actividades genéricas del marco de trabajo: comunicación, planeación, modelado, construcción y despliegue.

2. ACTIVIDADES GENÉRICAS DE LA INGENIERÍA DE SOFTWARE

ComunicaciónEsta actividad del marco de trabajo implica una intensa colaboración y comunicación con los clientes; además abarca la investigación de requisitos y otras actividades relacionadas.

PlaneaciónEsta actividad establece un plan para el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo.

ModeladoEsta actividad abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos.



ConstrucciónEsta actividad combina la generación del código y la realización de pruebas necesarias para descubrir errores en el código.

DespliegueEl software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quién evalúa el producto recibido y proporciona información basada en su evaluación.

Según el estándar ISO 12207, los procesos de la ingeniería de software se organizan en: proceso primario (Actividades: adquisición, suministro, desarrollo, operación y mantenimiento), proceso de soporte (Actividades: documentación, gestión de la configuración, control de calidad, verificación, validación, reuniones, auditoría, resolución de problemas) y proceso organizacional (Actividades: gestión, infraestructura, mejora y formación). También, se identifican como actividades genéricas del la ingeniería del software a las siguientes:

3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERÍA DEL SOFTWARE

La ingeniería de software tiene varios modelos considerados también paradigmas o ciclos de vida de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar algunos por ser los más utilizados y los más completos: el modelo de cascada o ciclo de vida clásico, los modelos incrementales, el DRA (Desarrollo Rápido de Apicaciones), los procesos evolutivos como la construcción de prototipos y el espiral, el modelo basado en componentes, los métodos formales (CMM, CMMI), el orientado a aspectos, el proceso unificado UML, los métodos ágiles.

4. EVOLUCIÓN DE LA INGENIERÍA DE SOFTWARE

La ingeniería de software es una disciplina muy joven, a finales de la década de los 60 comenzaron a establecer algunos principios básicos, sin embargo se ha producido una preocupante crisis del software de la cual aún no se logra salir. A continuación se presenta una breve evolución:


Análisis

Planeación

Implementación

Desarrollo

Pruebas

Gestión del

Proyecto


(< 1968) Dominios sencillosEl software era diseñado a medidaCarencia de métodos sistemáticos La programación del software se consideraba como un “arte”.

(1968) Fritz Bauer, utiliza por primera vez el término “Ingeniería del Software”, en la 1era. Conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania.

(>1968)Dominios complejos Aplicaciones variadas y complejas Separación desarrollador – clienteExigencias de calidadDesarrollo en gruposCrisis del softwareSe evidencia una preocupación de las universidades y organismos de estandarización (SEI, IEEE, ISO) por el desarrollo de estándares, metodologías, técnicas y herramientas para la ingeniería de software.

5. CRISIS DEL SOFTWARE

El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software.

La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda. La complejidad del software producido y demandado se incrementa constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más sencillos hasta los de misión crítica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.

A continuación se citan algunas causas de la crisis del software: Imprecisión en la planificación del proyecto y estimación de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseño poco estructurado, etc. Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en

la compra. También se requiere una serie de características como fiabilidad, facilidad de

mantenimiento y de uso, eficiencia, etc



Comparativa de proyectos para el desarrollo de sistemas de software

6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIÓN DE LA INGENIERÍA DE SOFTWARE

Desde la identificación del fenómeno “crisis del software”, han sido muchas las organizaciones que han abordado, con mayor o menor rigor, el análisis de problemas en el desarrollo de sistemas de software. Sus trabajos se han encaminado a la localización de las causas; y a la exposición en textos didácticos, normativos o estándares de procesos o prácticas necesarias para abordar el desarrollo, mantenimiento y operación con las mayores garantías de éxito.

Han sido muchos los departamentos de universidades, organismos de normalización o investigación nacionales o internacionales, sociedades de profesionales, departamentos de defensa, departamentos de calidad y procesos de empresas los que han ido generando normas y estándares.

Se considera como entidades de mayor reconocimiento internacional, por sus trabajos y esfuerzos realizados para la normalización, y reconocimiento de la Ingeniería del software a: ISO, SEI e IEEE- Computer Society.

ISO. Organización Internacional para la Estandarización, fundada en 1947.

Son miembros 87 países. En 1987 la Organización Internacional para la Estandarización (ISO) y la Comisión Internacional Electrotécnica (IEC), establecieron un Comité


Proyecto no terminado, nunca se llega a utilizar

Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionalesProyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.

2000

1998

1995

1994

28%23% 49%

26%28% 46%

27%40% 33%

16%31% 53%

ÉxitoProblemáticoFracaso

2004 29%19% 53%

Fuente: Standish Group Survey (http://www.standishgroup.com/)


Internacional (JTC1) para las Tecnologías de la Información. La misión del JTC1 es la “estandarización en el campo de los sistemas de tecnologías de la información, incluyendo microprocesadores y equipos”.

Los estándares o instrucciones técnicas más importantes para la Ingeniería del Software: ISO/IEC 12207 ISO/IEC TR 15504

SEI. Instituto de Ingeniería del software. (SEI http://www.sei.cmu.edu/). Integrado en la Universidad Carnegie Mellon.

La aportación más significativa de este Instituto son los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi 15 años de implantación efectiva en entornos de producción de software han

demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos, y como criterio de evaluación para determinar la madurez, y por tanto fiabilidad de resultados previsibles de una organización de software.

IEEE Computer Society

IEEE Es el Instituto de Ingenieros en Electricidad y Electrónica (Institute of Electrical and Electronics Engineers).

Su misión es preservar, investigar y promover la información de las tecnologías eléctricas y electrónicas.

Surgió en 1963 con la fusión del AIEE (Instituto Americano de Ingenieros Eléctricos) y el Instituto de Ingenieros de Radio (IRE).

La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en la actualidad por más de 100.000 miembros en todo el mundo.Su finalidad es avanzar en la teoría, práctica y aplicación de las tecnologías de la información. Realiza conferencias, publicaciones, cursos de formación, y desarrolla estándares.

IEEE ha desarrollado estándares para todas las áreas de Ingeniería del Software. Algunos de ellos, correspondientes a las principales áreas específicas de la Ingeniería del Software son:

IEEE Std. 830 Prácticas recomendadas para las especificaciones de software. IEEE Std. 1362 Guía para la especificación del documento de requisitos “ConOps” IEEE Std. 1063 Estándar para la documentación de usuario de software. IEEE Std. 1012 Estándar para la verificación y validación de software. IEEE Std. 1219 Estándar para el mantenimiento del software



7. PRINCIPALES ESTÁNDARES Y MODELOS DE LA INGENIERÍA DE SOFTWARE

Los estándares son útiles porque: Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de

software. Engloban los “conocimientos”. Proporcionan un marco para implementar procedimientos de aseguramiento de la

calidad. Proporcionan continuidad y entendimiento entre el trabajo de personas y

organizaciones distintas.


Definirse a sí misma: ¿Cuáles son las áreas de conocimiento que la comprenden?

Definir los procesos que intervienen en el desarrollo, mantenimiento y operación del software

De las mejores prácticas, extraer modelos de cómo ejecutar esos procesos para evitar los problemas de la “crisis del software”

Definir estándares menores para dibujar criterios unificadores en requisitos, pruebas, gestión de la configuración, etc.

SWEBOK: Software Engineering Body of knowledge http://www.swebok.org

ISO/IEC 12207: Procesos del ciclo de vida del software

CMM / CMMIISO/IEC TR 15504

IEEE 830 - IEEE 1362 - ISO/IEC 14764 …

La Ingeniería del Software es una ingeniería muy joven que necesitaba:

http://www.swebok.org/

TAREAS DEL CRÉDITO 1Realice las siguientes actividades para fortalecer el aprendizaje del tema:

Investigue los conceptos de los siguientes términos:IngenieríaIngeniería de sistemasSistema y SoftwareIngeniería de softwareProducto, proceso y personas(Recurso Humano) en el desarrollo de softwareMétodos, paradigmas o ciclos de vidaMetodología, técnicas, tecnología y herramientas

Realice un cuadro donde se resuma las características, ventajas y desventajas de los paradigmas de desarrollo de software

Explique las causas de la crisis del software

Grafique y explique el proceso genérico de la ingeniería del software

Describa las principales organizaciones de estandarización de la ingeniería de software

Describa los principales estándares y modelos de ingeniería de software.

Realice el primer avance del proyecto final. Revise las orientaciones que se explican a continuación

ORIENTACIONES PARA EL PROYECTO FINAL


Realizar una pre-investigación de una empresa o institución donde se va a desarrollar el proyecto de software de fin de asignatura, y como resultado de esa investigación, elaborar el documento del estudio preliminar en el cual se describirá brevemente el problema a dar solución.

El Estudio preliminar debe contener el siguiente formato:

Carátula (Primera página):

Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso “Estudio Preliminar”) Versión del Documento

A todas las páginas del documento colocar:


AUTOEVALUACIÓN TEMA I


Encabezado de página: Código y nombre del documento, número de página, versión, Nombre del Proyecto

Pie de página: Autor y fecha de creación

Control de Cambios (Segunda Página): Es una matriz que incluye los siguientes campos: fecha de cambio, descripción del cambio, responsable, versión

Índice (Tercera página)

1. Introducción (Hacer un breve resumen del documento)1.1. Propósito (del documento del estudio preliminar)1.2. Definiciones, acrónimos y abreviaturas1.3. Referencias

2. Datos de la empresa o institución donde se desarrollará el proyecto de software: nombre de la empresa o institución, dirección, teléfonos, ciudad

3. Fuentes de información (las personas de la empresa o posibles usuarios directos e indirectos del software)

4. Descripción de la institución o empresa (Realizar una breve descripción histórica, misión y visión en caso de tener)4.1. Objetivos de la institución (general y específicos)4.2. Orgánico funcional (organigrama funcional)4.3. Orgánico de procesos (funciones de cada uno de los cargos)4.4. Funcionamiento actual de la empresa, 4.5. Identificación de problemas, causas y posibles efectos

5. Alternativa(s) de solución y objetivos de la empresa con el software a desarrollar)

6. Anexos

1. Conteste con una (V) si es verdadero o con una (F) si es falso:a. ( ) El producto en ingeniería de SW es considerado como el resultado de ejecutar

una actividad o tarea.b. ( ) El proceso es un conjunto de entregables.c. ( ) La técnica es la estrategia que se aplica para ejecutar una actividad de un

métodod. ( ) El software es considerado como el conjunto de programas.

2. Complete:

a. Con sus propias palabras defina el término Ingeniería de Software: ………………....................................................................................................................………………....................................................................................................................

b. Método en ingeniería de software…………………...........................................................………………....................................................................................................................………………....................................................................................................................


TUTORÍAS PROGRAMADAS


c. Técnicas:………………………………………………………………………....................................................................................................................………………....................................................................................................................

d. CASE:…………………………………………………………………………………………....................................................................................................................………………....................................................................................................................Principales organizaciones de estandarización: …………..…………………………….. ………………....................................................................................................................………………....................................................................................................................

Proceso: …………..…………………………….. ………………....................................................................................................................………………....................................................................................................................

3. Elabore un cuadro resumen de las características de los diferentes paradigmas de desarrollo de software

4. Describa las etapas de un proceso de Ingeniería de SW Genérico

5. Describa brevemente los principales estándares de la ingeniería de software

Consulte en su centro de información o a su tutor el horario de los encuentros presenciales, y/o virtuales (Chat) o las consultas por teléfono. Anote a continuación para que lo tenga en cuenta en el desarrollo de este tema:

Fecha Hora Actividad


INGENIERÍA DEINGENIERÍA DE REQUISITOSREQUISITOS

INTRODUCCIÓN


NGENIERÍA DE SOFTWARE I



SISTEMA DE VALORES

Conceptos de Ingeniería de RequisitosDescripción de las actividades del proceso de la IR- Obtención de requisitos- Análisis de requisitos - Especificación de Requisitos

según el estándar de IEEE 830- Validación de requisitos- Gestión de requisitos

- Identificar y recolectar requisitos

- Validar y gestionar requisitos

- Elaborar los requisitos del software

ResponsabilidadCriticidadHonestidad


Los requisitos constituyen un insumo determinante en el desarrollo del software; los usuarios o clientes juegan un papel de proveedores de información y los desarrolladores deben interactuar con ellos para la obtención de requisitos. La fase de requisitos del software se puede describir como un proceso ingenieril (por esta razón algunos autores lo consideran como Ingeniería de Requisitos (IR)) que consta de una serie de actividades que dan lugar, fundamentalmente, a una especificación del producto software que se ha decidido construir. En concreto todas ellas se organizarán por actividades de educción u obtención de información, de especificación, de validación y de gestión.

En los últimos años han surgido grandes cambios en el campo de la Ingeniería de Requisitos. Así, en primer lugar, se ha establecido un reconocimiento general de la importancia de la Ingeniería de Requisitos y de los riesgos en que se incurren si ésta se realiza de forma incorrecta o insuficiente. Actividades propias de esta área, como la


ESQUEMA DEL TEMA II


especificación de requisitos o la gestión de requisitos del usuario, son algunas de las consideradas más críticas en el desarrollo y la producción del software.

Pero, en segundo lugar, y como consecuencia de la asunción de esta problemática situación por parte de los implicados en la industria del software, se ha llegado a introducir explícitamente la Ingeniería de Requisitos en modelos de Mejora del Proceso Software. O, por la misma razón, se han desarrollado guías e interpretaciones que permiten el estudio de la conformidad de procesos y productos de la Ingeniería de Requisitos a estándares internacionales de Calidad que buscan garantizar la satisfacción del cliente. Este tema trata la implicación entre aspectos de calidad del producto final con las prácticas relacionadas con la Ingeniería de Requisitos.

OBJETIVO

Realizar la especificación de los requisitos de software del problema planteado


Para el estudio del Tema II necesitas revisar la siguiente bibliografía: Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulos: 1, 2, 3, 4; Páginas: 1-99.Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Quinta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulos: 1 y 2; Páginas: 3-33.Palacios, Juan. Compendio de Ingeniería de SW I). Última revisión: Junio 2006. Documento Electrónico: CIS I 04.PPT. Capítulo 3, Diapositivas: 54- 117.P. Loucopoulos, V. Karakostas; System Requirements Engineering; McGraw-Hill International series in Software Engineering, 1995.Kendall & Kendall, Análisis y Diseño de software. Capítulos 4-8, Páginas: 79-213

ACTIVIDADES DE APRENDIZAJE TEMA II




1. CONCEPTOS DE INGENIERÍA DE REQUISITOS

Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado (Roger S. Pressman. Ingeniería del Software Mc Graw Hill 1995).

En este tema se tratará el proceso de la Ingeniería de Requisitos y su importancia como etapa fundamental en el desarrollo de SW. El documento de Especificación de Requisitos (ERS en español o SRS en inglés) es un producto importante que servirá de base para procesos subsiguientes de ingeniería de software como planificación, análisis, diseño, construcción, pruebas y validación con los usuarios.

Importancia de los Requisitos

Los requisitos indudablemente son importantes porque constituyen la base para los demás procesos de desarrollo del software. Diferentes autores mencionan lo complejo de este proceso, los posibles errores y sus repercusiones en el producto de SW y sus usuarios.

La parte más difícil en la construcción de sistemas software es decidir precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con humanos, máquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto el resultado final si se realiza de forma errónea. Ninguna otra parte es tan difícil de rectificar posteriormente (Frederick P. Brooks J., 1987. Es autor del libro “The mythical Man-Month”, un clásico de la Ingeniería del Software escrito en 1975 y reeditado 20 años después y que aún sigue vigente).

¿Qué porcentaje de proyectos concluyen con éxito? Un estudio realizado por Standish Group analizó el desarrollo de 8000 proyectos de software, realizados por 350 empresas diferentes y concluyó que sólo el 16% de los proyectos de software se realizan con éxito.

El estudio identificó como principales causas de los problemas: Falta de información por parte de los usuarios Requisitos deficientes (incompletos y cambiantes) La planificación de agendas y estimaciones de costes no se realizaron en base a los

requisitos Deficiencias en la aplicación de procesos y desconocimiento del ciclo de vida del

proyecto

Los criterios de éxito de un proyecto son: Implicación de los usuarios Apoyo de los directivos Enunciado claro de los requisitos



No desviarse de las fechas previstas. No desviarse de los costes estimados. Que el producto final cubra las expectativas y necesidades del cliente. Que funcione correctamente.

Errores en los requisitos

Según Boehm (1975), 45% de los errores tienen su origen en los requisitos y en el diseño preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto SW, se deben a una mala especificación de requisitos.

Tragedias ocurridas por defectos en el SW De 6 nuevos proyectos que entran en servicio 2 quedan cancelados. Los proyectos de sistemas de tamaño medio consumen 150% más de tiempo Alrededor de 3/4 partes de sistemas grandes no funcionan como se quería o no se

utilizan para nada. El 55 % de los proyectos costó más de lo esperado El 68% incumplió plazos previstos. El 88% tuvo que rediseñarse El 34% se terminó y no se utilizó por cambio de tecnologíaAlgunos casos reales de fracasos de SW: Un sensor mal programado por Francia, destruyó el supe cohete europeo Ariane

5 (El País, 23 de junio de 1996) 2 Billones de dólares perdidos al no poder poner en marcha el aeropuerto de

Denver (USA) por culpa del software de control del sistema de traslado de equipajes (fecha prevista apertura 1-noviembre-93; abrió el 28-febrero-95, retraso de 16 meses). Computer, Febrero, 1995.

Proyección de errores

Los errores que no se logren identificar en la fase de requisitos provocarán errores mayores en las siguientes fases de desarrollo del software. Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute en todas las fases del proyecto. Estimación: No es posible estimar con rigor costes y recursos necesarios para

desarrollar algo que no se conoce. Planificación: No se puede confiar en la planificación para el desarrollo de algo que no

se sabe bien como es. Diseño: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en

restricciones o futuras evoluciones, producen arquitecturas que más tarde se confirmarán como erróneas y serán modificadas.

Construcción: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y error que derrochan horas y paciencia de programación sobre patrones de “re codificación continua” y “programación heroica”.

Validación y verificación: Terminado el desarrollo del sistema, si las especificaciones tienen errores de bulto, o peor aún, no están reflejadas en una especificación de requisitos, no será posible validar el producto con el cliente.



Los defectos comunes en los requisitos y sus consecuencias


Fase en la que se detecta el fallo

Coste de la corrección

Requisitos

Arquitectura

Diseño detallado

Construcción

Requisitos Arquitectura Diseño detallado

construcción Producción

50-200X

1X

Fase en la que se soluciona el fallo

50-200X

1X

Implicación insuficientedel cliente

Requisitos crecientesy cambiantes

Requisitos ambiguos

Requisitosinnecesarios

Requisitos insuficientes

Requisitos insuficientes

Omisión de las necesidadesde grupos de usuarios

Problemas en la validacióndel producto obtenido

Degradación de la estructuray arquitectura del producto

Pérdida de tiempo enre-codificación

Trabajo innecesario

Problemas en la validacióndel producto obtenido

Error en la estimacióny planificación

Usuarios insatisfechos

39


Beneficios de los buenos requisitos

Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse. Requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el proyecto que el sistema no era lo que se pedía.

Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearán para su validación. Resulta muy difícil demostrar al cliente que el producto desarrollado hace lo que el pidió si su petición no está documentada y validada por él.

Base objetiva para la estimación de recursos (coste, personal en número y competencias, equipos y tiempo). Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el fondo son cálculos de probabilidad que siempre implican un margen de error; por esta razón disponer de la mayor información posible reduce el error.

Concreción de los atributos de calidad (ergonomía, mantenibilidad, etc.). Más allá de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento.

Eficiencia en el consumo de recursos: reducción de la re-codificación, reducción de omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repetición de partes ya desarrolladas, etc.

¿Qué son los requisitos?

Los requisitos del sistema son La descripción de los servicios y restricciones.

IEEE define “Requisito” como:

Condición o aptitud necesaria para resolver un problema o alcanzar un objetivo. Condición o facilidad que debe proporcionar un sistema o algunos de sus

subsistemas para satisfacer un contrato, norma, especificación o cualquier otra condición impuesta formalmente a través de un documento.

Una representación documentada de una condición o facilidad.

Requisito según Norma MIL-STD STD-498. Característica del sistema que es una condición para su aceptación.

Requisito según Goguen. Propiedad que un sistema debería tener para tener éxito en el entorno en el que se usará.

Un requisito define: ¿Qué hace el sistema? Y no ¿Cómo lo hace?

Ámbitos de los requisitos



Descripción del sistema. Documento, también denominado ConOps y normalizado en el estándar IEEE Std. 1362-1998.

Definición de ConOps: Documento dirigido a los usuarios, que describe las características de un sistema propuesto, desde el punto de vista del usuario. La Descripción del Sistema es el medio de comunicación que recoge la visión general, cualitativa y cuantitativa de las características del sistema; compartido por la parte cliente y desarrolladora.

Especificación de requisitos del software (SRS o ERS). Un documento SRS es la especificación de las funciones que realiza un determinado producto de software, programa o conjunto de programas en un determinado entorno.

A través de los SRS se determina qué funcionalidades deben realizarse, qué datos deben generarse en cada resultado, en qué lugar y quién los debe producir. La SRS debe centrarse en los servicios que se realizarán, pero, en general, no debe especificar elementos de diseño o de proyecto. Deben centrarse únicamente en el punto de vista externo del sistema, y no en el funcionamiento interno.

El documento de especificación de requisitos puede elaborarlo el personal representativo de la parte suministradora (desarrollador), o de la parte cliente; si bien es aconsejable la intervención de ambas partes.

¿QUÉ ES INGENIERÍA DE REQUISITOS?

La Ingeniería de Requisitos comprende las actividades de desarrollo de software (y Sistemas de Información) relacionadas con la gestión y definición de necesidades, restricciones y atributos de calidad para sistemas nuevos o actuales.

La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.

IEEE define la IR como: Proceso de estudio de necesidades de los usuarios con el objeto de llegar a una definición del sistema HW/SW.

Según el profesor Loucopoulos: La IR consiste en un trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido.


Ámbitos

Sistema

Software

Descripción del sistemaConOps

Requisitos del softwareSRS


Proceso de la Ingeniería de Requisitos

1. Obtención (elicitación). El primer paso consiste en conocer y comprender las necesidades y problemas del cliente.

En la obtención se identifican todas las fuentes de requisitos implicadas en el sistema y, en función de las características del entorno y del proyecto se emplean las técnicas más apropiadas para la identificación de las necesidades que deben satisfacerse.

2. Análisis. Una vez obtenida la información necesaria del entorno, es necesario sintetizarla, darle prioridades, analizar posibles contradicciones o conflictos, descomponer el sistema y distribuir las necesidades de cada parte, delimitar los límites del sistema y definir su interacción con el entorno.

3. Especificación. Cuando ya se conoce el entorno del cliente y sus necesidades, es necesario plasmarlas en forma de requisitos en los documentos que sirven de base de entendimiento y acuerdo entre cliente y desarrollador, y que establecerán tanto la guía desarrollo como los criterios de validación del producto final.Documentar los requisitos es la condición más importante para gestionarlos correctamente.

4. Verificación y validación. Los requisitos deben ser formal y técnicamente correctos (verificación), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validación).

El significado de estos dos términos genera confusiones habitualmente. El criterio básico que los diferencia es que verificación se refiere a la calidad formal, en este caso de los documentos de requisitos (no son ambiguos, no son incompletos, son posibles, verificables, etc.) y validación comprende la adecuación en el entorno de producción, en el caso de la documentación de requisitos, la conformidad por parte del cliente de que reflejan lo que él quiere.

5. Gestión. Los requisitos cambiarán durante el desarrollo del sistema, y es necesario poder trazar en cada cambio todas las partes afectadas, así como poder medir el impacto que cada modificación implica en la planificación del proyecto.


OBTENCIÓN

Obtener información

ANÁLISIS ESPECIFICACIÓN

VERIFICACIÓN&

VALIDACIÓNGESTIÓN

Clasificarla, localizar inconsistencias, dar prioridades, pasar a

requisitos

Escribir los requisitos

Comprobar que son formalmente correctos y lo que el cliente quiere

Registrar cambios, estudiar

su impacto, actualizar

documentación

Obtener información Registro y contrastación Controlar las modificaciones

TAREAS DEL CRÉDITO 2Realiza las siguientes actividades con el propósito de reforzar conocimientos en IR:

¿Cuáles son los factores de éxito y de fracaso de los proyectos de software?¿Qué tragedias ha causado el desarrollo de software con defectos?¿Qué es la Ingeniería de Requisitos (IR)?¿Cuál es la importancia de la Ingeniería de Requisitos?¿A quienes dirigirnos para recolectar requisitos?¿Qué son los requisitos?¿Cuál es la clasificación de los requisitos?Describa las etapas del proceso de la IRInvestigue las técnicas de especificación de requisitos¿Cómo se clasifican los requisitos?Describa el estándar IEEE 830 -1998 para documentar requisitos.


2. DESCRIPCIÓN DE LAS ACTIVIDADES DEL PROCESO DE LA IR

A. OBTENCIÓN DE REQUISITOS.

Este proceso también es considerado como: elicitación, educción, formulación, identificación o extracción.

La especificación de requisitos se refiere a la captura y descubrimiento de los requisitos.

Es una actividad más “humana” que técnica. Se identifica a los interesados (clientes y usuarios) y se establecen las primeras

relaciones entre ellos y el equipo de desarrollo.

¿A quién (es) se dirigen los requisitos?

El proceso de obtención de requisitos se dirige a:

Usuarios potenciales o clientes Productores de software o sistemas



Cada uno de estos dos escenarios lleva a situaciones totalmente diferentes: En el primer caso, se definen las necesidades (puede servir como base para el pliego de condiciones) y será muy general para permitir distintas soluciones. En el segundo caso, las especificaciones suponen un paso inicial para el desarrollo de software y deberán ser mucho más específicas.

Fuentes de los requerimientos Identificar los objetivos del proyecto y eventualmente realizar un estudio de

viabilidad de los mismos. Ámbito de aplicación o dominio de conocimiento del proyecto (permitirá resolver

conflictos entre actores) Identificar a todos los actores del proyecto para poder diseñar un sistema que

recoja diferentes puntos de vista de manera consensuada y sea fácil de usar por todos ellos

Identificar el entorno operacional para poder establecer las restricciones del proyecto y los costes.

Entorno organizativo: identificación de los condicionantes que la estructura, la cultura y la política interna de la organización puedan imponer o sobre-entender.

Técnicas de obtención de los requerimientos

Entrevistas con los actores (clientes y/o usuarios): cerradas / abiertas Encuestas aplicando cuestionarios con preguntas concretas y respuestas

cerradas / abiertas Escenarios. Los requisitos se sitúan en el contexto de uso (casos de uso).

Permiten contextualizar y preguntarse sobre ‘¿Qué pasaría si ... ?’ ‘¿Cómo se hace ésto ?’

Prototipos: permiten clarificar y precisar requerimientos. Útiles cuando la incertidumbre es total acerca del futuro sistema.

Reuniones de grupo (normales o ‘brainstorming’): permiten aportar mayores puntos de vista que a través de entrevistas individuales y aflorar puntos de vista contrapuestos. Es necesario gestionarlas correctamente para evitar conflictos o puntos de vista dominantes.

Observación de los sistemas actuales y medida de distintos parámetros de los mismos a través de la inmersión operacional. Ilustra acerca de las tareas y ciertos procesos complejos o sobreentendidos que raramente se explicitan.

Estudio de los documentos y formularios existentes. Visitas a otras instalaciones, investigación externa, jornadas profesionales, ferias Presentaciones comerciales, estudio de productos SW ya existentes.

B. ANÁLISIS DE REQUISITOS.

Consiste en detectar y resolver conflictos entre requisitos. Se precisan los límites del sistema y la interacción con su entorno. Se trasladan los requisitos de usuario a requisitos del software (implementables). Se realizan tres tareas fundamentales: Clasificación, Modelización y

Negociación.

Clasificación de Requisitos.



La clasificación más típica de los requisitos es la que se presenta a continuación:

Sin embargo, algunos autores presentan otras formas de clasificación de requisitos: Por prioridades Por coste de implementación Por niveles (alto nivel, bajo nivel) Según su volatilidad/estabilidad Si son requisitos sobre el proceso o sobre el producto

Requisitos Funcionales: Definen el comportamiento del sistema. Describen los servicios o funciones del sistema Describen las tareas que el sistema debe realizar. Al definir un requisito funcional es importante mantener el equilibrio entre la

excesiva generalidad, insuficiencia de detalle o ambigüedad, y el exceso de detalle con precisiones o descripciones innecesarias o redundantes.

Requisitos No funcionales: Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:

Tiempos de respuesta. Características de usabilidad. Facilidad de mantenimiento. etc.

Requitos de Interfaz. Definen las interacciones del sistema con su entorno. Interfaces de Usuarios o con otros sistemas.

Modelización de Requisitos:

La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente)

El tipo de modelo elegido depende de: La naturaleza del problema La experiencia del modelizador La disponibilidad de herramientas Por decreto. El cliente impone una notación


TIPOS DE REQUISITOS

FUNCIONALESCapacidades

Restricciones

NO FUNCIONALES

DE INTERFAZ

Restricciones


Tradicionalmente se entendía que “el análisis” se reducía a modelizar (DFDs, modelos de objetos, etc), pero el análisis de requisitos NO es exclusivamente un proceso de modelización. Por otro lado, no existe “la mejor” forma de modelar requisitos. En realidad, no hay evidencia empírica que demuestre, en general, la superioridad de unas notaciones de modelización frente a otras.

Negociación de Requisitos:

También denominada resolución de conflictos entre: Requerimientos incompatibles Actores que demandan requerimientos incompatibles Recursos disponibles y requerimientos solicitados Requerimientos funcionales y restricciones

Frecuentemente el analista no tiene capacidad para decidir, por lo que debe favorecer el consenso, y si hay un contrato de prestación de servicios, debe dejarse traza del por qué de la decisión tomada.

Podría incorporarse como parte de la Validación de requerimientos. La mejor técnica es la de las reuniones con los involucrados, previamente preparadas y documentadas para conocer el impacto de los conflictos y sus posibles soluciones.

Otras técnicas son: correo electrónico, boletines electrónicos, bases de datos compartidas tipo Lotus Notes con la documentación de los requerimientos y sus conflictos. No están excesivamente probadas y su utilidad puede ser dudosa si se genera una actitud de desinterés. C. ESPECIFICACIÓN DE REQUISITOS.

Para la especificación de los requisitos o documentación es necesario utilizar algún estándar, así encontramos a los siguientes:

IEEE Std. 830-1998 PSS-05 de la Agencia Espacial Europea (ESA)

El estándar IEEE std. 830 – 1998 contiene la siguiente estructura:

1. Introducción2.1. Propósito2.2. Alcance2.3. Definiciones2.4. Referencias2.5. Visión General

3. Descripción General3.1. Perspectiva del producto3.2. Funciones del producto3.3. Características del usuario3.4. Restricciones



3.5. Suposiciones4. Requisitos Específicos5. Apéndices6. Índice

Fuente: (http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor-html/index.html )

Los aspectos básicos que una descripción de requisitos debe cubrir son: Funcionalidad. Descripción de lo que el software debe hacer. Interfaces externos. Cómo debe interactuar el software con las personas, el

sistema de hardware, o con otros sistemas (software y hardware). Rendimiento. Indicación de la velocidad, disponibilidad, tiempos de respuesta,

tiempos de recuperación, tiempos de determinadas funciones. Atributos. Consideraciones de portabilidad, corrección, mantenibilidad, seguridad,

etc. Restricciones de diseño en la implementación. Indicación de las restricciones

que puedan afectar por la necesidad de sometimiento a estándares, lenguajes, políticas de integridad de bases de datos, límites de recursos disponibles para el desarrollo, sistema operativo, etc.

Propiedades deseables de los requisitos.

Comprensible por clientes, usuarios y desarrolladores. Correcto, sin requisitos innecesarios o redundantes. No ambiguo y con el nivel de precisión necesario. Completo, que no falten requisitos y que todas las respuestas del sistema a entradas

tanto válidas como inválidas estén especificadas. Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de

nivel superior y con una terminología única. Verificable, que pueda comprobarse que el sistema final cumple los requisitos

mediante un proceso finito y de coste razonable. Fácilmente modificable, organizada, con los requisitos identificados y con control de

configuración. Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrás

y hacia delante. Priorizada, indicando la importancia de los requisitos. Anotada con estabilidad, para conocer posibles fuentes de cambios durante el

desarrollo. Independiente del diseño y la implementación, para evitar complejidades innecesarias

y no limitar a los diseñadores.

D. VALIDACIÓN DE REQUISITOS

La validación de requisitos consiste en descubrir problemas en el documento de requisitos antes de comprometer recursos en la implementación del software.

El documento debe revisarse para: Descubrir omisiones Conflictos


http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor-html/x15.html

TAREAS DEL CRÉDITO 31. Para desarrollar habilidades en la aplicación del proceso de Ingeniería de Requisitos, verifica

si los siguientes requisitos están bien redactados, discútelo con tu profesor guía. Identifica en cada requisito los siguientes elementos: proceso a automatizar, archivo(s) lógico(s), los datos a utilizar, y las restricciones u observaciones.

Gestión de DoctoresReq (11) Registrar nuevo doctor, con los siguientes datos: código del doctor, nombre del

doctor, apellido del doctor, especialidad del doctor, estado del doctor, teléfono del doctor,

dirección del doctor.

Req (12) Se permitirá buscar por código o nombres del doctor, pidiendo que ingrese el dato

que desea buscar.

Req (13) Se podrá modificar datos del doctor cumpliendo con el (Req 12) y no se podrá

cambiar el código del doctor. En caso de no constar los datos del doctor en la base de datos

se procederá a cumplir el (Req 11).

Req (14) Genera una consulta que muestre en pantalla un listado de todos los doctores con

sus respectivos datos, previamente cumpliendo con el (Req 12).

Req (15) Dar de baja a los datos de un Doctor, aplicando un criterio de eliminación lógica por

medio del (Req12). Este proceso no implica una eliminación definitiva de la base de datos.

2. Como actividad del crédito 3 debe realizar el SEGUNDO AVANCE DE SU PROYECTO FINAL. Revisa las orientaciones que se indican a continuación.


Ambigüedades Comprobar la calidad del documento y su grado de de adhesión a estándares

Para revisar el documento de los requisitos es aconsejable conformar una comisión de revisión que incluya desarrolladores y usuarios. Esta comisión debe encargarse de:

Buscar problemas en el documento de los ERS. Convocar a reuniones y establecer acuerdos.

Algunas técnicas para identificar problemas habituales: Listas de comprobación “checklists” Prototipado. Permite descubrir con rapidez si el usuario se encuentra satisfecho o

no con los requisitos Validación de Modelos. Cuando los requisitos son expresado en base a modelos

como: Casos de Uso, DFD’s u otros. Validación de su testeabilidad. El equipo de pruebas debe revisar los requisitos.

E. GESTIÓN

La gestión de requisitos debe realizarse durante todo el proceso de desarrollo del software. Es parte de la Gestión de la Configuración del Software y se realizan algunas actividades:

Definir procedimientos de cambios: definen los pasos y los análisis que se realizarán antes de aceptar los cambios propuestos.

Cambiar los atributos de los requisitos afectados. Mantener la trazabilidad: hacia atrás, hacia delante y entre requisitos. Control de versiones del documento de requisitos




Como actividad laboral de avance del proyecto final, en este tema se deberá elaborar el documento de ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE (ERS). Para lo cual es necesario realizar las siguientes tareas:

Recolectar los requisitos del software a desarrollar, es necesario ejecutar técnicas de recolección de información como entrevistas, encuestas, observación, revisión de archivos y documentos, monitoreo de tareas, efectuar reuniones formales. Para esta actividad se debe involucrar a todos los usuarios directos o indirectos del software a desarrollar.

Documentar los requisitos aplicando el estándar IEEE 830-1998 Refinar (depurar) el documento de requisitos realizando reuniones formales con

los usuarios. Gestionar los requisitos.

El ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE (ERS) debe contener el siguiente formato:


Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso “ESPECIFICACIÓN DE

REQUISITOS DEL SOFTWARE (ERS)”) Versión del Documento







AUTOEVALUACIÓN TEMA II


1. Introducción (Hacer un breve resumen del documento)1.1. Propósito (del documento)1.2. Ámbito del Sitema1.3. Definiciones, acrónimos y abreviaturas1.4. Referencias1.5. Visión general

2. Descripción General2.1. Perspectiva del producto2.2. Funciones del producto2.3. Características de los usuarios2.4. Restricciones2.5. Dependencias

3. Requisitos Específicos3.1. Requisitos Funcionales3.2. Requisitos de interfaces externos

3.2.1. Interfaces de Usuario3.2.2. Interfaces Hardware3.2.3. Interfaces Software3.2.4. Interfaces de Comunicación

3.3. Requisitos de Rendimiento3.4. Requisitos de desarrollo3.5. Requisitos Tecnológicos3.6. Atributos3.7. Seguridad

4. Apéndices (Anexos) 4.1. Entrada de datos4.2. Salida de datos

1. Complete:

a. Requisito: ………………....................................................................................................................………………....................................................................................................................

b. IEEE 830…………………...........................................................………………....................................................................................................................………………....................................................................................................................

c. ¿Cuál es la parte más difícil en la construcción de un software? ………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

d. Técnicas usadas en el proceso de validación de requisitos:………………....................................................................................................................………………....................................................................................................................




………………....................................................................................................................e. ¿Cómo se comportan los errores en los requisitos en las demás fases del

proceso de ingeniería del software?: ………………………….. …………..……………………………..………………....................................................................................................................………………....................................................................................................................

f. ¿Cuál es el ámbito de los requistos?: ………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

2. Elabore un cuadro resumen de las técnicas para recolectar requisitos del software

3. ¿Qué es la Ingeniería de Requisitos

4. Realice un ensayo sobre los procesos de la Ingeniería de Requisitos




GESTIÓN DE PROYECTOS DEGESTIÓN DE PROYECTOS DE SOFTWARESOFTWARE




SISTEMA DE VALORES

CONCEPTOS SOBRE GESTIÓN DE PROYECTOS DE SOFTWARE- El espectro de gestión, el

personal, el producto, el proceso, el proyecto

- Gestionar el personal, el proceso y el problema durante el proyecto de software


PLANIFICACIÓN DEL PROYECTO DE SOFTWARE- Objetivos de la planificación del

proyecto- Ámbito del software, recursos- Estimación del proyecto de

softwareo Técnicas de puntos de

funcióno Modelos empíricos de

estimación - La decisión desarrollar-comprar

- Identificar y generar equipos de software, estimaciones fiables del esfuerzo, costes y duración del proyecto


PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO- Conceptos básicos, la relación

entre las personas y el esfuerzo- Definición de un conjunto de

tareas para el proyecto de software.- Selección de las tareas de Ing.

SW- Refinamiento de las tareas

principales- Definir una red de tareas

- Desarrollar la planificación temporal de proyecto


ANÁLISIS DE RIEGOS- Estrategias de riesgos- Riesgos del software- Identificación y proyección del

riesgo- Reducción, supervisión y

gestión del riesgo- Riesgos y peligros para la

seguridad

- Identificar y utilizar las técnicas para la evaluación de los riesgos que pueden tener impacto en el éxito del proyecto.


PLAN DE GARANTÍA DE CALIDAD- Introducción- Documentación- Revisiones y auditorias- Gestión de Configuración

- Definir y controlar la calidad de un proyecto


PLAN DE GESTIÓN DE CONFIGURACIÓN

- Identificar y realizar la forma de

ResponsabilidadCompañerismo



- Introducción- Actividades de GCS- Programación

gestionar los cambios durante el desarrollo de software y después de entregar al cliente

Honestidad



INTRODUCCIÓN



En este tema se estudiará los conceptos clave que conducen a una gestión efectiva de proyectos de software. Comenzaremos con los conceptos básicos de gestión de proyectos de software, se analizarán algunas técnicas para la estimación, elaboración de un cronograma realista, revisión de algunas técnicas de gestión que conducen a una efectiva supervisión, reducción y gestión del riesgo, finalmente, se considerarán técnicas para asegurar la calidad conforme un proyecto se lleva a cabo y se gestionan los cambios a lo largo de la vida de una aplicación.

OBJETIVO

Gestionar el proyecto de software mediante planificación, seguimiento y control del proceso de desarrollo de software y la realización de actividades de soporte como: análisis de riesgos, configuración del software y control de calidad que permita la construcción de un producto que satisfaga las necesidades del cliente.


ESQUEMA DEL TEMA III



ACTIVIDADES DE APRENDIZAJE TEMA III

Para el estudio del Tema III necesitas revisar la siguiente bibliografía:

Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005.

Conceptos de Gestión de proyectos. Página 640Métricas de proceso y proyecto. Página 663Estimación para proyectos de SW. Página 690Calendarización de proyectos de SW. Página 724Gestión de riesgo. Página 747Gestión de calidad. Página 767Gestión del cambio. Página 796

Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005.

Gestión del Proyecto de SW. Páginas: 37 - 52.Métricas del SW. Páginas: 53 - 76.Planificación del proyecto de SW. Páginas: 77 – 96Análisis de Riesgos. Páginas: 97- 110Plan Temporal y seguimiento. Páginas: 111 - 130.Calidad del SW. Páginas. 131 - 150.Gestión de la Configuración del Software. Páginas: 151- 164

Kendall & Kendall, Análisis y Diseño de software. Estudio de Factibilidad: Páginas: 47- 53Planificación del proyecto: Páginas: 54-74Calidad del Software: Páginas: 745-765




1. CONCEPTOS SOBRE GESTIÓN DE PROYECTOS DE SOFTWARE

¿Qué es gestionar? Un concepto general de gestionar es coordinar todos los recursos disponibles para conseguir determinados objetivos, implica amplias y fuertes interacciones fundamentalmente entre el entorno, las estructuras, el proceso y los productos que se deseen obtener.

La gestión de proyectos involucra la planificación, supervisión y control del personal, el proceso y los eventos que ocurren durante la ejecución del proyecto desde un concepto preliminar hasta una implementación operativa.

Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres grandes etapas:

Fase de planificación. Se trata de establecer cómo el equipo de trabajo deberá satisfacer las restricciones de prestaciones, planificación temporal y coste. Una planificación detallada da consistencia al proyecto y evita sorpresas que nunca son bien recibidas. Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realización propiamente dicha del proyecto, la ejecución de la obra de que se trate. Responde, ante todo, a las características técnicas específicas de cada tipo de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestión. Cada tipo de proyecto responde en este punto a su tecnología propia, que es generalmente bien conocida por los técnicos en la materia. Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto está destinado a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es también muy importante no sólo por representar la culminación de la operación sino por las dificultades que suele presentar en la práctica, alargándose excesivamente y provocando retrasos y costes imprevistos. A estas tres grandes etapas es conveniente añadir otras dos que, si bien pueden incluirse en las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un conjunto de actividades que resultan básicas para el desarrollo del proyecto:

Fase de iniciación. Definición de los objetivos del proyecto y de los recursos necesarios para su ejecución. Las características del proyecto implican la necesidad de una fase o etapa previa destinada a la preparación del mismo, fase que tienen una gran trascendencia para la buena marcha del proyecto y que deberá ser especialmente cuidada. Una gran parte del éxito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una buena etapa de planificación, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto. Fase de control. Monitorización del trabajo realizado analizando cómo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye también el



liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.

El espectro de gestión. La gestión eficaz de proyectos de software se enfoca sobre las cuatro P: personal, producto, proceso y proyecto. El orden no es arbitrario.

EL PERSONAL. La formación de personal de software motivado y altamente calificado se ha debatido desde los años 60. De hecho, el factor humano es considerado como el más importante en el proyecto, debido a que el desarrollo del software es un trabajo más intelectual que físico. En los modelos formales como el CMM (Modelo de Madurez de Capacidades), define en su proceso de gestión de personal, las siguientes áreas: reclutamiento, selección, gestión del desempeño, entrenamiento, retribución, desarrollo de la carrera, desarrollo de la organización y el trabajo, y desarrollo de la cultura de equipo.

Los participantes. Se pueden clasificar en 5 categorías:• Gestores Superiores• Gestores técnicos del proyecto• Profesionales• Clientes • Usuarios Finales

Los jefes de equipo. Los Jefes de equipo deben poseer ciertas capacidades, así, el modelo MOI considera las siguientes:

Motivación.- Habilidad para motivar con un <<tira y afloja>>


M.M.C.G.P

Reclutamiento

Gestión de rendimiento

Entrenamiento

Retribución Desarrollo cultural

Diseño / organización

Desarrollo

Selección

61

PROCESO

PRODUCTO

PERSONAL

PROYECTO


Organización.- Moldear procesos existentes Ideas o innovación.- Motivar al personal para crear y sentirse creativos

El equipo de softwareLa mejor estructura d equipo depende del estilo de gestión de una organización. Mantei, sugiere tres organigramas de equipos genéricos.

“La gestión exitosa de proyectos, independientemente de la estructura organizativa, es sólo tan buena como lo sean los individuos y líderes que gestionen las funciones básicas”(Kerzner, 1998)

EL PRODUCTO. Antes de planear un proyecto se deberían establecer los objetivos y el ámbito del producto, considerar soluciones alternativas e identificar las restricciones técnicas y de gestión. Sin esta información es imposible definir estimaciones razonables del costo, valoraciones efectivas del riesgo, una división realista de las tareas del proyecto o un calendario del proyecto que ofrezca una indicación fiable del progreso.

El desarrollador del software y el cliente se deben reunir para definir los objetivos y el ámbito del producto. En muchos casos, esta actividad comienza como parte de la ingeniería del sistema o de la ingeniería del proceso de negocio y continúa como primer paso en la ingeniería de requisitos del SW.

EL PROCESO. Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Generalmente está guiado por la metodología (método o ciclo de vida + técnicas + soporte documental) que se haya seleccionado para llevar a cabo el proyecto de software. El proceso se descompone en actividades y a su vez las actividades en tareas.

EL PROYECTO. Un proyecto es una acción en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo único. En este


DESCENTRALIZADO DEMOCRÁTICO

DESCENTRALIZADO CONTROLADO

CENTRALIZADO CONTROLADO

No tiene jefe permanente Las decisiones se hacen por consensos La comunicación entre los miembros es horizontal

Tiene jefe definido, coordina tareas Jefes secundarios, para subtareas Comunicación vertical

El jefe se encarga de la solución de problemas La comunicación entre el jefe y los miembros del equipo es vertical.

62

ACTIVIDAD 1

TAREA 1TAREA 1 TAREA X• • •

PROCESO

ACTIVIDAD n• • •


trabajo, dadas unas especificaciones y dentro de unos límites de costes y tiempo, se intenta conseguir un cambio beneficioso dirigido por unos objetivos cualitativos y cuantitativos. Estos elementos implican que un proyecto lleva una incertidumbre considerable y riesgo, y por lo tanto su éxito dependerá en gran medida de una adecuada gestión.

2. PLANIFICACIÓN DEL PROYECTO DE SOFTWARE.

El proceso de producción del software tiene que ser gestionado y dirigido de una manera extremadamente rigurosa y cuantitativa. De este modo se podrá verificar que el trabajo correspondiente a cada fase se ha realizado completamente dentro de los plazos de tiempo y coste establecidos y de acuerdo con estándares específicos de calidad. Por lo tanto, las claves del éxito en la gestión del desarrollo de software son: una adecuada gestión del proyecto de desarrollo de software y una adecuada gestión del proceso de software.

El número de tareas identificables a realizar por un director de proyectos, dentro del área de la gestión de proyectos son varias. Sin embargo, hay tres que son críticas y que deben ser desarrolladas correctamente si se desea que el proyecto termine bien.

Estas tareas son:a. Estimación de duración, coste y esfuerzo necesarios para construir el producto.b. Planificación de tareas a realizar, asignación de personas, tiempos, etc. para construir el

producto.c. Seguimiento, durante la realización del trabajo, para asegurar el cumplimiento de lo

planificado en cuanto a costes, fechas, etc. En caso de desviaciones del plan, se deben tomar las medidas pertinentes.

LOS OBJETIVOS de la planificación del Proyecto de Software, es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

ÁMBITO DEL SOFTWARE. Es la primera actividad que se lleva a cabo durante la planificación del proyecto de Software. Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:



a. La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.

b. Viabilidad. Una vez identificada la información necesaria para el software, es razonable preguntarse ¿Podemos construir el SW de acuerdo a ese ámbito? ¿Es factible el proyecto?

Estudio de viabilidad. El estudio de viabilidad comprende: Técnico. Económico Legal Operativo Análisis costo/beneficio

Estudio de viabilidad Técnico. Consiste en identificar el recurso hardware, software, de comunicación y recurso humano especializado. Se debe concluir indicando si es factible o no desarrollar técnicamente el proyecto.

Estudio de viabilidad Económico. Determinar propuestas de costos de los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación (puesta en producción) del Sw. Además, comprende análisis de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado, es decir un análisis costo/beneficio. Se debe concluir indicando si es económicamente factible el desarrollo del proyecto.

Análisis coste/beneficioCostes: Personal Informático Consultoría Software adicional Hardware Infraestructura Debidos al usuario

Caso de estudio:Supongamos una empresa que lleva la contabilidad de forma manual y decide implantar un sistema informático para que el proceso resulte más rápido y fiable. Actualmente dispone de 2 personas dedicadas a la contabilidad, cuyo coste (sueldo bruto + SS a cargo de la empresa) es de 5.200.000 cada uno. Se decide comprar un paquete de contabilidad cuyo precio es de 3.000.000 y el coste de mantenimiento un 15% de éste, y que requerirá una adaptación (sólo inicialmente) valorada en 44 jornadas de trabajo de un analista programador cuya hora se presupuesta en 4.500 pts. El ordenador que requiere se presupuesta en 500.000 pts, con un coste de mantenimiento de un 10% anual. El departamento de contabilidad estima que se ahorraría un 50% de tiempo de las 2 personas dedicadas a contabilidad si el sistema fuese automático. Se considera que la vida del sistema es de 4 años. La formación para su manejo requiere una semana y se hace con los propios manuales del paquete. Se considera que el sistema está plenamente operativo en 3 meses.

Análisis coste/beneficio del caso de estudio:



Estudio de viabilidad Legal. Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al desarrollar el Sistema. Se debe indagar las disposiciones legales de la propia empresa o externos, que los desarrolladores deben considerar en la construcción del software. Se debe concluir indicando si es legalmente factible el desarrollo del proyecto.

Estudio de viabilidad Operativo. Consiste en indagar a todos los usuarios que se requiere involucrar en el proyecto, además, contrariedades de los usuarios, posibles oponencias a la automatización del software. Se debe concluir indicando si es operativamente factible el desarrollo del proyecto.

RECURSOS. La segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.

Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro características:

Descripción del recurso. Informes de disponibilidad. Fecha cronológica en la que se requiere el recurso. Tiempo durante el que será aplicado el recurso.

Recursos Humanos.



La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñará cada profesional.

Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación y la reutilización de bloques de construcción de Software.

Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración.

El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:

Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos.

Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software.

El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

ESTIMACIÓN DEL PROYECTO DE SOFTWARE

Al principio, el costo del software constituía un pequeño porcentaje del costo total de los sistemas basados en computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

¿Qué es estimar?

Es predecir valores subjetivos pero no muy alejados de la realidad. Se basa en la especificación de requisitos.

Estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una ciencia, es una actividad importante que no



debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes y de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.

La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:

Deje la estimación para más adelante (obviamente podemos realizar una estimación al cien por cien fiable después de haber terminado el proyecto).

Base las estimaciones en proyectos similares ya terminados. Utilice técnicas de descomposición relativamente sencillas para generar las

estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo empírico para él cálculo de costos y esfuerzos del Software.

Desdichadamente la primera opción, aunque atractiva no es práctica.

La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras.

Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño.

Tamaño del software. Puede estimarse utilizando: Una medida directa. LDC (Líneas de Código fuente) Una medida indirecta. Puntos de Punción (PF).

Técnicas de descomposición: Descomposición del problema Descomposición del proceso

Estimación basada en el problema. Las Líneas de Código LDC y los Puntos de Punción PF son medidas utilizadas para la estimación.

Estimación basada en el Proceso. Se basa la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea.

Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del



proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.

Los Modelos Empíricos de estimación.

Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.

El Modelo COCOMO

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. El modelo ha evolucionado a un modelo de estimación más completo llamado COCOMO II, consta de una jerarquía de modelos de estimación que tratan las siguientes áreas:

Modelo de composición de aplicación. Utilizado durante las primeras etapas de la ingeniería de software, donde el prototipado de las interfaces de usuario, la interfaz del sistema y del software, la evaluación del rendimiento, la evaluación de la madurez de la tecnología son de suma importancia.

Modelo de fase de diseño previo. Utilizado una vez que se han establecido los requisitos y la arquitectura básica del software.

Modelo de fase posterior a la arquitectura. Utilizado durante la construcción del software.

Herramientas Automáticas de Estimación.

Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos.

A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.

La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación.



Ejemplo de software de estimación: ESTICMACS PLANMACS COCOMOII CA-SUPERPROJECT

TÉCNICA DE PUNTOS DE FUNCIÓN

Esta técnica permite medir el tamaño (funcionalidad proporcionada por el usuario), por lo que es necesario contar con un buen documento de Especificación de Requisitos del Software (ERS ó SRS). Es la base para la estimación de costos, esfuerzo, personas y tiempo.

En el caso de subsistemas diseñados independientemente los Puntos de Función se calcularán para cada uno de ellos, y luego se sumarán. Por ejemplo, cuando un sistema que proporcione por un lado una funcionalidad on-line y por otro lado una funcionalidad batch, y por tanto, se han diseñado independientemente los dos subsistemas que proporcionan cada funcionalidad.

Los objetivos de los Puntos de Función son: Medir lo que el usuario pide y lo que el usuario recibe. Medir independientemente de la tecnología utilizada en la implantación del sistema. Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la

productividad. Proporcionar un medio para la estimación del software. Proporcionar un factor de normalización para la comparación de distintos software.

Además de estos objetivos, el proceso de contabilizar los Puntos de Función debería ser:

Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida.

Conciso en sus resultados.

El análisis de los Puntos de Función se desarrolla considerando cinco parámetros básicos externos del Sistema:

Entradas (EI, del inglés External Input). Salidas (EO, del inglés External Output). Consultas (EQ, del inglés External Query). Grupos de datos lógicos internos (ILF, del inglés Internal Logic File). Grupos de datos lógicos externos (EIF, del inglés External Interface File).

Con estos parámetros, se determinan los puntos de función sin ajustar.

A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobre la aplicación y su entorno. Es decir las características generales del sistema.

Tipos de funciones: Datos y



Transacciones

Funciones de Datos

Representan la funcionalidad proporcionada a los usuarios para cumplir con sus requisitos de datos internos y externos.

Son de dos tipos: Ficheros Lógicos Internos y Ficheros de Interfaces Externos.

Ficheros Lógicos Internos (ILF)

Un Fichero Lógico Interno es un grupo de datos lógicamente relacionados identificables por los usuarios o información de control mantenidos y utilizados dentro de los límites de la aplicación.

Ejemplos de ILF son: Ficheros maestros Aplicaciones de Seguridad de Datos Datos de Auditoría Actualizados por la aplicación Mensajes de Error Actualizados por la aplicación Ficheros Internos Lógicos mantenidos por más de una aplicación

Ficheros Interfase Externos (EIF)

Representan un grupo de datos relacionados lógicamente identificables por el usuario o información de control utilizada por la aplicación de solo lectura, pero mantenida por otra aplicación.

Funciones de Transacción

Comprende tres tipos de función:

Entradas externas (EI): mantiene datos almacenados internamente. Salidas externas (EO): datos de salida de la aplicación. Consultas externas (EQ): Combinación de una entrada (pregunta) y de una salida

(respuesta).Entradas Externas (EI. External Input)

Las Entradas Externas son datos o información de control que se introducen en la aplicación desde fuera de sus límites. Comprende el mantenimiento de un Fichero Lógico Interno (ILF), es decir: altas, bajas y eliminaciones.

Ejemplos de este tipo de función son: Las pantallas de entrada. Las entradas por lotes. Las entradas externas duplicadas (banco)

Salidas Externas (EO. External Output)



Las Salidas Externas son datos o información de control que sale de los límites de la aplicación. Esta salida debe ser considerada única si tiene un formato único o si el diseño lógico requiere un proceso lógico distinto de otras salidas del mismo formato. Toda salida ha de requerir un proceso de cálculo de la información que se proporciona.

Ejemplos Transferencia de datos a otras aplicaciones (vista lógica de un archivo físico, vista lógica

de 2 o más archivos físicos) Los gráficos estadísticos y datos estadísticos en formato tabla Los generadores de informes

No se deben contar como Salidas: Las ayudas Las distintas formas de invocar la misma salida lógica Los mensajes de error/confirmación distintos a salidas externas Los informes Ad Hoc: Cuando el usuario dirige y es responsable de la creación mediante

la utilización de lenguajes como SQL de un número indefinido de informes, no se cuentan como salidas.

Consultas Externas (EQ. External Query)

Las consultas representan los requisitos de información a la aplicación en una combinación única de entrada/salida que se obtiene de una búsqueda de datos, no actualiza un Fichero Lógico Interno y no contiene datos derivados. Una consulta se considera única si tiene un formato distinto de otras consultas, ya sea en entrada o salida, o si el diseño lógico requiere ediciones distintas a las de otras consultas.

Se entiende por datos derivados aquéllos que requieren un proceso distinto a la búsqueda directa, edición o clasificación de información de Ficheros Lógicos Internos o Ficheros Interfases Externos.

Ejemplos: La búsqueda inmediata de datos. Las consultas no explícitas. Las pantallas de modificación/borrado que proporcionan

capacidad de búsqueda de datos Pantallas de conexión. Las pantallas de logon que proporcionarían seguridad se cuentan

como una consulta Los menús con consultas implícitas: Las pantallas de menú que proporcionan una

selección de pantallas y entradas para la búsqueda de datos para la pantalla llamada, se cuenta como una Consulta.

Las ayudas: Son una consulta donde la entrada y la salida (texto) son únicas. Un texto que puede ser accedido o mostrado en pantalla mediante distintas peticiones o diferentes áreas de una aplicación se cuenta como una consulta.

Las salidas duplicadas: Consultas iguales que producen una salida en diferentes soportes, como consecuencia de especificaciones del usuario, se cuentan como consultas distintas.

Tutoriales: Los sistemas de software relativos a la formación de usuarios debería contarse como un sistema distinto.



No se consideran como Consultas: Los mensajes de Error/Confirmación. La utilización de distintos métodos de llamada a la misma consulta.

Valoración de la Complejidad

Para cada uno de los parámetros externos se ha de indicar su complejidad como Baja, Media o Alta. Para las entradas, salidas y consultas, se puede evaluar su complejidad en función del número de campos que contengan y del número de ficheros a los que hagan referencia. Para los ficheros, por el contrario, su complejidad vendrá dada en función del número de registros y de campos que tengan.

Valoración de la complejidad de los tipos de función datosA cada ILF y EIF identificado se le asigna una complejidad funcional que es función del número de tipos de elementos datos (DETs) y el número de tipos de elementos registros (RETs) de los que estén compuestos, y que vienen expresada mediante las tablas de contribución y complejidad.

Elementos datos (DETs). Un tipo de elemento dato es un campo único y no recursivo sobre un tipo de función datos y que es reconocible por el usuario. Normalmente se corresponden con los atributos de las entidades lógicas de usuario.

Elementos registros (RETs). Un tipo de elemento registro es un subgrupo de datos elementales reconocibles por el usuario dentro de un tipo de función datos. Los subgrupos son de dos tipos; opcionales y mandatorios. Los grupos opcionales son aquellos que el usuario tiene la opción de incluir o no mediante un proceso elemental que añada o cree una instancia dentro un tipo de función datos. Los grupos mandatorios son aquellos en los que el usuario debe incluir cuando se crea o añade una instancia.

Valoración de la complejidad de los tipos de función transacción

Para este tipo de valoración, además de los DETs, se requiere del número de tipos fichero referenciados (FTRs).

Valoración de la complejidad de las entradas externas EI

A cada El se le asigna una complejidad funcional que es función del número de tipos de elementos datos (DETs) que procese el procedimiento elemental, y el número de tipos



ficheros referenciados (FTRs)) a los que acceda tal proceso. Viene expresada mediante las tablas de contribución y complejidad.

Valoración de la complejidad de las salidas externas EO

A cada EO identificada, asignarle una complejidad funcional basada en el número de tipos ficheros referenciados (FTRs) por el proceso elemental de dicha EO y el número de tipos elemento de datos (DETs) que la forman. Viene expresada mediante las tablas de contribución y complejidad.

Valoración de la complejidad de las consultas externas EQ

A cada EQ que ha sido identificada, asignarle una complejidad funcional basada en el número de tipos fichero referenciados (FTRs) y de tipos elemento de datos (DETS) que intervienen en el proceso de la componente de entrada y de la componente de salida respectivamente. Una vez calculada ambas complejidades, escoger la más alta entre la de la entrada y la de la salida, y traducirla a número de puntos de función sin ajustar según las tablas de contribución y complejidad.

A continuación se llena los parámetros determinados de complejidad de ILF, EIF, EI, EO, EQ, en la tabla que se presenta a continuación. Se obtendrá el total de puntos de función sin ajustar.

PARAMETRO COMPLEJIDAD NUMERO X PESO TOTALILF ALTA X 15 MEDIA X 10 BAJA X 7 EIF ALTA X 10 MEDIA X 7 BAJA X 5 EI ALTA X 6 MEDIA X 4 BAJA X 3 EO ALTA X 7 MEDIA X 5



BAJA X 4 EQ ALTA X 6 MEDIA X 4 BAJA X 3

Utilizando la herramienta CASE COCOMO II se calcula los puntos de función y las LDC:


TAREAS DEL CRÉDITO 4Realiza las siguientes actividades con el propósito de desarrollar habilidades en el proceso de gestión del proyecto de software:

Conceptualice los siguientes términos:GestiónEstimaciónProyectoProyecto de softwareCOCOMOMediante un gráfico explique las etapas de la gestión de proyectos Realice un ensayo de mínimo 150 palabras sobre los elementos para desarrollar una gestión eficaz de un proyecto de software.¿Cómo organizar un equipo para el desarrollo de software?¿Cuáles son las tareas identificables a realizar por un director de proyectos, dentro del área de la gestión de proyectos?¿Cuáles son los objetivos de la planificación del proyecto de software?¿Qué es el ámbito del software?¿En que consiste el estudio de factibilidad?Describa el proceso de estimación del software mediante la técnica de los puntos de funciónRealice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Planificación General del proyecto de software incluido el proceso de Estimación y la organización del equipo de trabajo.


1. Valor costo/mes que debe ingresarse2. Tamaño del software en LDC3. Esfuerzo hombre/mes4. Costo total del software5. # de personas

DECISIÓN DE DESARROLLAR-COMPRAR.

En muchas áreas de aplicación del software, a menudo es más rentable adquirir el software de computadora que desarrollarlo. En una empresa antes de desarrollar o adquirir un software, se recomienda analizar las diferentes posibilidades:

Construir el software desde el inicio Reutilizar los componentes de otro SW para construir el nuevo Comprar o adquirir un software disponible y adaptarlo a las necesidades Contratar el desarrollo del software a un vendedor externo.

Subcontratación (outsourcing). Las actividades de ingeniería de software se contratan a un tercero, quien hace el trabajo a bajo costoasegurando una alta calidad. El trabajo de software llevado dentro de la compañía se reduce a una actividad de gestión de contratos.


3 3 4 52

1


3. PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO

La planificación temporal y el seguimiento del proyecto tienen como objetivo primordial evitar los retrasos en las entregas del software.

Causas de los retrasos:

Fechas límite de entrega poco realistas. Cambio de los requisitos que no se reflejan en la planificación temporal Subestimación honesta del esfuerzo y/o recursos. Riesgos predecibles e impredecibles no considerados. Dificultades técnicas y humanas Falta de comunicación entre la plantilla. Falta de reconocimiento del retraso en un proyecto. Falta de medidas para corregir el problema.

Las fechas límite poco realistas son bastante frecuente en el desarrollo de software, jamás debemos empezar un proyecto sabiendo que la fecha impuesta es imposible de alcanzar. Tampoco es factible cambiar la fecha, pues por lo general, está impuesta por la ley del mercado.

Solución:

Realizar una estimación detallada (productividad>25%). Utilizar un modelo incremental que implemente la funcionalidad crítica mínima para la

fecha límite impuesto.



Reunirse con los clientes y explicar la situación.

¿Cómo se retrasan las planificaciones temporales en los proyectos? diariamente [Fred Brooks]

¿Cómo se cumplen las planificaciones temporales en los proyectos?diariamente [Antonio Navarro]

Planificación temporal

Es la culminación de una actividad de planificación, componente primordial de la dirección de proyectos de software. Cuando se combinan métodos de estimación y análisis de riesgos, la planificación temporal se convierte en un mapa de carreteras a seguir por el gestor de proyectos.

La planificación temporal empieza con la descomposición del proceso. Las características del proyecto se emplean para adaptar un conjunto de tareas apropiado al trabajo a realizar. Una red de tareas muestra todas las tareas de la ingeniería, sus dependencias con otras tareas y sus duraciones previstas. La red de tareas (PERT) se usa para calcular el camino crítico del proyecto, un gráfico de tiempo e información diversa del proyecto (GANTT). El gestor del proyecto puede seguir y controlar todos los procesos de software usando la planificación temporal como directriz.

Construcción de un cronograma de actividades. Mediante MS Project

WBS (Work Breakdown Structure): Estructura de las tareas en las que se descompone el proyecto.

Tipos de dependencias entre tareas FC (de Fin a Comienzo) – la más habitual CC (de Comienzo a Comienzo) FF (de Fin a Fin) CF (de Comienzo a Fin) – suele ser

problemática

Ejemplo:


Análisis

Diseño Web

Diseño Admin

Desarrollo Web

Desarrollo Admin

Integración Implan- tación

77


Asignación de recursos y personas a las tareas

Optimización. Conceptos clave para la optimización del proyecto: Paso adelante Paso atrás Ruta crítica Reasignación de recursos

Paso adelante

Estimar la fecha más temprana para comenzar y terminar cada tarea Comenzando por la fecha de inicio del proyecto Estima la fecha de fin más optimista



Paso atrás

Estimar cuales pueden ser las fechas mas retrasadas para el inicio y fin de cada tarea sin causar retrasos en el proyecto.

Se puede estimar con la fecha de entrega calculada por “paso adelante”, o con la fecha de entrega deseada Al calcular con la fecha de entrega por “paso adelante” se debe obtener a la misma

fecha de inicio. Al calcular con la fecha de entrega esperada se obtiene la fecha límite para comenzar

el proyecto

Demora total Diferencia entre las fechas calculadas con “paso adelante” y “paso atrás” para cada tarea Retraso máximo para una tarea sin retrasar sin afectar a la fecha de entrega del proyecto La demora total se comparte entre las tareas en una cadena. Si se emplea en una tarea

ya no queda disponible para otras.

Demora permisible. Tiempo que puede retrasarse una tarea sin afectar a la agenda del proyecto



Algunos programas como MS Project pueden hacer los cálculos de forma

Ruta crítica. Es la ruta más larga en el plan del proyecto, y delimita la fecha de entrega más temprana posible

Actividades críticas. Actividades que están en la ruta crítica y que no tienen demora permisible. Sus retrasos afectan al proyecto.



Optimización de agenda1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crítica2.- Revisar la asignación de personas

3.- Modificar la asignación de recursos4.- Redistribuir a las personas

Recomendaciones Duplicar la asignación de personas no significa “la mitad de tiempo” Menos tiempo de entrega no significa menor presupuesto Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado Usar el sentido común

SEGUIMIENTO DE LA PLANIFICACIÓN

El seguimiento es un factor clave en la planificación temporal. Hay distintas formas de implementarlo: Realizando reuniones periódicas. Evaluando los resultados de las revisiones. Determinando si se han conseguido los hitos. Recavando las opiniones subjetivas del equipo. Comparando la fecha real de inicio con las previstas. Utilizando el análisis del valor ganado.

La comparación de las fechas reales y de inicio puede hacerse: Mediante tablas. Utilizando diagramas Gantt de seguimiento.



4. GESTIÓN DE RIESGOS

El riesgo. Se halla de forma implícita asociado a toda actividad: Todo suceso se ve marcado por las acciones del pasado, ¿Se puede, por tanto,

actuar ahora para crear oportunidades en el futuro? El riesgo acompaña a todo cambio El riesgo implica elección e incertidumbre.

Estrategias reactivas. Consiste en tomar acciones una vez ocurrido el riesgo. Los métodos que se pueden aplicar comprenden: la evaluación de las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Las consecuencias de una estrategia reactiva pueden ser: apagado de incendios, gabinetes de crisis, se pone el proyecto en peligro.

Estrategias proactivas. Antes de que ocurra el riesgo, se analizan y se planifican estrategias de prevención de los riesgos. Como método de prevención se pueden ejecutar las siguientes actividades: evaluación previa y sistemática de riesgos, evaluación de consecuencias, plan de evitación y minimalización de consecuencias, plan de contingencias.


IDENTIFICACIÓN

ANÁLISIS

TRATAMIENTOPlan de gestión

de riesgosGESTIÓN

DE

RIESGOS

IEEE Std P1540-2001

82


Algunas posibles consecuencias son la evasión del riesgo, menor tiempo de reacción, justificación frente a los superiores.

Riesgo del software. Implica dos características: Incertidumbre (probabilidad de que ocurra) y pérdida, si el riesgo se convierte en realidad.

Categorías de los riesgos: Riesgos del proyecto: implica incremento en costes y desbordamiento organizativo Riesgos técnicos Riesgos del negocio:

De mercado De estrategia De ventas De gestión De presupuesto

IDENTIFICACIÓN DE RIESGOS. La identificación del riesgo es un intento sistemático para especificar las amenazas al plan de proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Existen dos tipos de riesgos para cada categoría presentada anteriormente: Genéricos: Son comunes a todos los proyectos Específicos: Implican un conocimiento profundo del proyecto

Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo basado en las siguientes subcategorías: Relacionados con el tamaño del producto Con el impacto en la organización Con el tipo de cliente Con la definición del proceso de producción Con el entorno de desarrollo Con la tecnología Con la experiencia y tamaño del equipo

Componentes del riesgo. Los componentes de riesgo se definen de la siguiente manera: Rendimiento Coste Mantenibilidad Planificación

El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categorías de impacto: despreciable, marginal, crítico y catastrófico.

ESTIMACIÓN DE RIESGOS. Denominado también proyección del riesgo. Intenta medir el riesgo de dos maneras: la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el riesgo, si ocurriera. Se realiza cuatro actividades de proyección del riesgo:

1. Establecer una escala que refleje la probabilidad percibida del riesgo, 2. Definir las consecuencias del riesgo, 3. Estimar el impacto del riesgo en el proyecto y el producto y 4. Apuntar la exactitud general de la proyección del riesgo de manera que no haya

confusión.



Creación de una tabla de riesgos:

Ordenación y filtrado Ordenación por probabilidad y prioridad Despreciar riesgos poco probables y los medianamente probables con poco impacto

Factores que definen el impacto de la ocurrencia de un riesgo Alcance del mismo: cuán serio y cuánto del proyecto se ve afectado Temporalización de los efectos, cuándo y por cuánto tiempo

Cuándo desistir y finalizar el proyecto Se debe definir un punto de referencia Se debe marcar la relación entre cada factor de riesgo enumerado y el punto de

referencia Definir el área de incertidumbre, donde será tan válido continuar como interrumpir el

trabajo Predecir cómo la combinación de riesgos afectará a los niveles de referencia

Gestión, Monitorización y Mitigación de Riesgos (RMMM)

Objetivo: Marcar las estrategias y formas de actuar del equipo de trabajo frente a los riesgos: Como evitarlos Como monitorizarlos Como gestionarlos y plan de contingencia

Evitación del riesgo Definir las estrategias necesarias para evitar que el riesgo no se produzca


Riesgo Categoría Proba-bilidad

Impacto RMMM

Tamaño estimado demasiado pequeño Proyecto 40 % PlanificaciónCrítico

Mas número de usuarios de lo planificado Proyecto 30 % RendimientoMarginal

Cliente cambie los requerimientos Proyecto 80 % CostesCrítico

Falta de experiencia en herramientas EntornoDesarrollo

80 % PlanificaciónMarginal

Rotación demasiado alta Equipo 60 % PlanificaciónCrítica

Riesgo Categoría Proba-bilidad

Impacto RMMM

Cliente cambie los requerimientos Proecto 80 % CríticoFalta de experiencia en herramientas Entorno

Desarrollo80 % Marginal

Rotación demasiado alta Equipo 60 % CríticaTamaño estimado demasiado pequeño Proyecto 40 % CríticoMas número de usuarios de lo planificado Proyecto 30 % Marginal


Conceptualice los siguientes términos:Planificación temporalGANTTRiesgo¿Cuál es el objetivo de la planificación temporal y el seguimiento del proyecto?Describa algunas causas por las que se retrasa un proyecto.¿Cómo se retrasan las planificaciones temporales en los proyectos? Describa los tipos de dependencias entre tareas¿Qué es una ruta crítica?¿En qué consiste el seguimiento de la planificación?Elabore un resumen mediante un organizador gráfico de la Gestión de RiesgosRealice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Planificación General del proyecto de software incluido el proceso de Estimación y la organización del equipo de trabajo.


Tomar las medidas encaminadas para que, aún cuando se produzca, se minimecen sus efectos

Monitorización del riesgo Definir los indicadores que influyen en la probabilidad de que el riesgo se produzca Monitorizar periódicamente dichos factores Monitorizar la efectividad real de las acciones encaminadas a evitar el riesgo

Gestión del riesgo y plan de contingencia Se asume que la evitación y la monitorización han fallado y el riesgo se ha producido Se definen las estrategias y acciones a tomar para evitar que los efectos se minimicen Nunca se podrá reducir a cero el coste del plan de contingencia. Dicho plan puede

implicar unos costes en sí mismo, por lo cual se ha de valorar el beneficio que se espera obtener de éste

Riesgos de seguridad y peligros En general se pueden considerar los riesgos de seguridad y peligros físicos. Generalmente, por su importancia, deben tratarse por separado, teniendo que tratarse

como un requerimiento especial, observado en todas las fases del ciclo de vida Se puede incluir dentro de las actividades de validación de calidad del producto

PLAN RMMM


IntroducciónÁmbito y propósito del documentoDescripción de los riesgos principalesResponsabilidades

GestoresPersonal técnico

Tabla de evaluación de riesgosDescripción de todos los riesgos consideradosFactores que influyen en la probabilidad e impacto

RMMMRiesgo X

EvitaciónEstrategia generalPasos para mitigar el riesgo

MonitorizaciónFactores a monitorizarModo de monitorización

GestiónPlan de contingenciasConsideraciones especiales

Planificación

85


5. GESTIÓN DE LA CALIDAD DEL SOFTWARE

Conceptos (ISO 8402)

Calidad: “Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explícitas o implícitas”

Control de calidad: “Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio”.

Garantía de calidad: “Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfará los requerimientos dados sobre calidad”.

Gestión de la calidad: “Aspecto de la función de gestión que determina y aplica la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad”.

La gestión de la calidad es responsabilidad de todos los niveles ejecutivos, pero debe estar guiada por la alta dirección. Su realización involucra a todos los miembros de la organización.

En la gestión de la calidad, se tienen en cuenta también criterios de rentabilidad.

Sistema de gestión de la calidad (QS): “Conjunto de la estructura de la organización, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad”.• El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad. • El QS de una organización está fundamentalmente previsto para satisfacer las

necesidades internas de la organización. Es más amplio que los requerimientos de un cliente concreto que únicamente valor el QS que le interesa (directamente).

• Para finalidades contractuales o vinculantes en la valoración de la calidad, se puede exigir que se ponga de manifiesto la realización de ciertos elementos del QS.

La calidad del software



“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).

“Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario” (Pressman, 1998)

“Software quality is the degree to which software possesses a desired combination of attributes (e.g., reliability, interoperability).” (IEEE Std. 1061)

Factores que determinan la calidad del software

Se centran en tres aspectos importantes de un producto software (McCall):• Características operativas• Capacidad de soportar los cambios• Adaptabilidad a nuevos entornos

Satisfacción del usuario

Control de Calidad del Software• Conjunto de inspecciones, revisiones y pruebas utilizadas a lo largo del ciclo de

desarrollo para asegurar que el producto cumple con los requisitos• Proceso retroalimentado y de medición• Proceso manual, automático o semiautomático

Aseguramiento de la calidad de software (SQA) SQA engloba:• Un enfoque de gestión de calidad• Tecnología de Ingeniería de Software efectiva • Revisiones técnicas formales (RTF) que se aplican durante el proceso del software• Una estrategia de prueba multiescalada• Un control de la documentación del software y de los cambios realizados• Un procedimiento que asegure un ajuste a los estándares de desarrollo de software• Mecanismos de medición y de generación de informes

Calidad del proceso y del producto• DEL PROCESO

Atributos de técnicas, herramientas, personal, organización, facilidades• DEL PRODUCTO

Atributos de documentación de desarrollo y mantenimiento, código, pruebas

Productividad y calidad


PRODUCTO SATISFACTORIO + BUENA CALIDAD +ENTREGA EN PRESUPUESTO + ENTREGA EN TIEMPO ESTABLECIDO

SATISFACCIÓN DEL USUARIO =


• PRODUCTIVIDAD: LDC/mes-persona• INCREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD

• Mejor calidad, menor trabajo (+/- 50% de ahorro)• Disminuyen las pruebas• Localización temprana de errores a menor costo

• DECREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD• Mejor calidad requiere inversión que se recupera en la entrega• La revisión de los productos de desarrollo mejora la calidad pero disminuye la

productividad• Las técnicas de calidad insisten en detalles que pueden constituirse en obstáculos

para el trabajo

PLAN DE GARANTÍA DE LA CALIDADIntroducción

PropósitoDefiniciones, acrónimos y abreviaturasReferencias

Especificaciones de gestiónOrganizaciónResponsablesGrupo de garantía de la calidad del softwareDocumentaciónRevisión de la gestiónRevisión de los requisitos del softwareRevisión de diseñoRevisión del productoRevisión de operación.

Gestión de configuraciónGestión de problemas y acciones correctivas

6. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE (GCS)

Es la tarea de identificar, organizar y controlar las modificaciones que sufre el software a lo largo de toda su vida útil, es un control de cambios.

La meta a alcanzar es maximizar la productividad minimizando los errores cometidos. Se aplica a lo largo de todo el proceso de ingeniería del software.

Las actividades de GCS sirven para:

1. Identificar el cambio.2. Controlar el cambio.3. Estado.4. Auditoría y revisión.5. Garantizar que el cambio se implementa correctamente.6. Informar del cambio a todos aquellos que se vean afectados.

Elementos de Configuración del software (ECS)



Al aplicarse el proceso de ingeniería del software se genera una información que se puede dividir en tres clases:

1. Programas de ordenador (ejecutables y código fuente).2. Documentos descriptivos de las aplicaciones (tanto técnicos como de usuario).3. Datos (datos internos del programa o externos a él).

Todos los elementos que componen la fuente de información producida como resultado del proceso de ingeniería se conocen como ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE.

Líneas base

En el contexto de la ingeniería del software, definimos una línea base como un punto de referencia en el desarrollo del software que queda marcado por la revisión, evaluación y aprobación de unos elementos software relacionados.

Las tareas de ingeniería del software producen una o más ECS. Una vez que un ECS se ha revisado y aprobado, se coloca en una base de datos del proyecto (biblioteca del proyecto o depósito de software), se convierten en línea base.

Cuando un miembro del equipo de ingeniería del software quiere hacer modificaciones en un ECS de línea base, se copia de la base de datos del proyecto en un área de trabajo privada del ingeniero. Sin embargo este ECS solo se puede modificar siguiendo todas las directrices exigidas en la gestión de configuración del software.

Versión

Una versión es una instancia de un elemento de configuración.

El término se utiliza indicar un elemento de configuración que tiene un conjunto de características funcionales.

Revisión

Se define revisión como una versión que se construye sobre otra versión anterior.

Variante

Es una versión alternativa a otra versión. Las variantes permiten a un elemento de configuración satisfacer elementos en conflicto.

Una variante en una nueva versión de un elemento que será añadida sin reemplazar a la versión anterior.

Proceso de GCS



El proceso de GCS se divide en 5 tareas:

Identificación. Control de versiones. Control de cambios. Auditorias de configuración. Generación de informes.

Identificación

Se puede tener dos tipos de objetos: objetos básicos y objetos compuestos.Un objeto básico es una unidad de texto creado por un ingeniero del software durante el análisis, diseño, codificación o pruebas.Un objeto compuesto es un grupo de objetos básicos o de otros compuestos.Cada objeto tiene una colección de atributos que le identifican unívocamente.

Control de versiones

El control de versiones está formado por procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.Para representar las diferentes versiones se puede utilizar un grafo de evolución o el fondo de objetos.

Control de cambios

El control de cambios proporciona formas de control humano y herramientas automatizadas para controlar los mecanismos de control de cambio.



Proceso de Control de Cambios

Control de acceso y de sincronización



Auditoría de configuración

La auditoría responde a estos nuevos elementos:

1. ¿Se ha realizado exactamente los cambios especificados en la OCI? ¿Se han incorporado las modificaciones adicionales?

2. ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección técnica?3. ¿Se ha aplicado los estándares de ingeniería del software?4. ¿Se han reflejado lo suficiente los cambios en el ECS? ¿Se ha reflejado la fecha del

cambio y el nombre del autor del cambio? ¿Reflejan los cambios los atributos del objeto de configuración?

5. ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y divulgarlo?

6. ¿Se han actualizado adecuadamente todos los ECS relacionados?

Informes de Estado

De la generación de informes de estado de la configuración (contabilidad de estado) se encarga la gestión de configuración del software, la cual responde a las siguientes preguntas:

1. ¿Qué sucedió?2. ¿Quién fue el autor?3. ¿En qué fecha ocurrió?4. ¿Cuántos elementos se vieron afectados?

Plan de Gestión de la ConfiguraciónIntroducción

Propósito del planAlcanceDefiniciones y acrónimosReferencias

Especificaciones de gestiónOrganización

ResponsabilidadesActividades de gestión de la configuración



Conceptualice los siguientes términos:CalidadControl de calidadGarantía de calidadGestión de la calidadSistema de gestión de la calidadCalidad del softwareSatisfacción del softwareECS¿Qué actividades comprende el aseguramiento de la calidad de software?Enumere las actividades de la gestión de la configuración del softwareElabore un resumen mediante un organizador gráfico de calidad y gestión de la configuración del softwareRealice el CUARTO AVANCE DE SU PROYECTO FINAL que involucra el Plan de Calidad del Software y el Plan de la Gestión de Calidad del Software.

AUTOEVALUACIÓN TEMA III


Jerarquía preliminar del productoSelección de los elementos de configuraciónEsquema de identificación de los ecsEsquema de identificación de versiones y revisionesDefinición de relaciones

Relación de equivalenciaRelación de composición

Definición y establecimiento de líneas baseDefinición y establecimiento de bibliotecas de softwareControl de cambiosAnexos

Anexo 1: solicitud de cambioAnexo 2: certificación del cambioAnexo 3: contabilidad del estado de la configuración



1. Complete:

a. Gestión: ………………....................................................................................................................………………....................................................................................................................

b. Personas………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

c. Calidad ………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

d. Riesgo:………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

e. Cronograma: ………………………….. …………..…………………………………………..………………....................................................................................................................………………....................................................................................................................

f. ¿Qué son puntos de función?: ………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

2. Cómo se realiza la valoración de los tipos de función en la técnica de los PF

3. ¿Qué son los ECS y qué aspectos se considera ECS?




4. Realice un ensayo sobre el proceso de gestión de riesgos




MODELADO DE ANÁLISIS DELMODELADO DE ANÁLISIS DEL SOFTWARESOFTWARE

INTRODUCCIÓN





INTRODUCCIÓN AL MODELADO- Conceptos de modelado,

utilidad, abstracción, ventajas

- Comprender la importancia del modelado de software


ANÁLISIS ESTRUCTURADO- Breve historia,

características- Elementos del modelo del

análisis- Modelado funcional o de

procesos y flujo de información(DFD’s), su notación y diccionario de datos

- Modelado de datos (ER) y su diccionario de datos

- Obtener una representación general del software a construir a partir de la especificación de los requisitos.


HERRAMIENTAS CASE (TI)- Que es CASE- Objetivos de las CASE- Elementos de las CASE- Tipos de CASE- Ejemplos de CASE

- Identificar los tipos de CASE

- Utilizar las herramientas CASE apara el desarrollo del software




ESQUEMA DEL TEMA IV


El Análisis de Sistemas, descompone el software en componentes para estudiarlos: aisladamente e interactuando con el resto. Sirve para identificar requisitos insuficientes, para representar los requisitos funcionales del software en modelos gráficos de datos, lo que permite mejora de la comprensión y validar requisitos. Mediante revisión se logra: corrección, integridad, consistencia de los requisitos.

OBJETIVO

Elaborar el modelado del software mediante el estudio y análisis de los requisitos del software, las metodologías de análisis y la elaboración del prototipo que permita la obtención de modelos físicos y lógicos para el diseño del software.


Para el estudio del Tema IV necesitas revisar la siguiente bibliografía: Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Sexta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulos: 1, 2, 3, 4; Páginas:1-99.Roger S. Pressman. Ingeniería del Software un Enfoque Practico. Quinta Edición. Mc-Graw-Hill/Interamerica de España S.A.U. 2005. Capítulo: 12; Páginas: 199-218.Kendall & Kendall, Análisis y Diseño de software.

Estudio de Factibilidad: Páginas: 47- 53Planificación del proyecto: Páginas: 54-74Calidad del Software: Páginas: 745-765

ACTIVIDADES DE APRENDIZAJE TEMA IV


1. INTRODUCCIÓN AL MODELADO DEL SOFTWARE

El modelado del software representa las funciones y subfunciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notación gráfica, información y comportamiento del Sistema.

Todos los Sistemas basados en computadoras pueden modelarse como transformación de la información empleando una arquitectura del tipo entrada y salida.

La base para el modelado de análisis del software es la Especificación de los requisitos del software (ERS).

¿Qué es un modelo? Un modelo es una simplificación de la realidad Un modelo es el resultado de un proceso de abstracción y ayuda a comprender y

razonar sobre una realidad Un modelo de software es una descripción de un aspecto del sistema, expresada

en un lenguaje bien definido.

División del producto

Se fracciona el producto de modo que cada fragmento lo puede realizar un integrante del equipo de desarrollo.

Ejemplo de un modelo de software



Modelado del Software. Comprende el modelado es el análisis y diseño de aplicaciones software antes de escribir el código. Se crean un conjunto de modelos (“planos del software”) que permiten especificar aspectos del sistema como los requisitos, la estructura y el comportamiento.

Utilidad del modelado. “Una empresa software con éxito es aquella que produce de manera consistente

software de calidad que satisface las necesidades de los usuarios” “El modelado es la parte esencial de todas las actividades que conducen a la

producción de software de calidad”

Abstracción - Modelado Visual (MV). “El modelado captura las partes esenciales del sistema”. Parte del proceso de negocio para representar en un modelo visual la solución del sistema computacional.



Algunas ventajas del modelado visual: Hay estructuras que no son visibles en los programas. Ayuda a razonar sobre el cómo se implementa. Se facilita la comunicación entre el equipo al existir un lenguaje común. Se dispone de documentación que trasciende al proyecto. Generación de código a partir de modelos Ha surgido un nuevo paradigma de desarrollo de software a partir de los modelos Los modelos:

visualizan cómo es o queremos que sea el sistema especifican la estructura y comportamiento del sistema. guían la construcción del sistema. documentan las decisiones.

2. ENFOQUES DE MODELADO DE ANÁLISIS



Existen dos enfoques claramente establecidos:1. Análisis Estructurado. Comprende actividades como:

Separación datos y procesos Modelado de Datos Atributos y relaciones Modelado de Procesos Transformación de datos

2. Análisis Orientado a Objetos Definición de clases Colaboración entre las clases

3. ANÁLISIS ESTRUCTURADO

Breve Historia

Es una técnica de modelado del flujo, contenido y transformación de la información que fluye por un sistema. Nació como complemento al Diseño Estructurado. El término “Análisis Estructurado” fue popularizado por DeMarco a fines de los 70, quien presentó y denominó los símbolos gráficos que permitirían al analista crear modelos de flujos de información.

Yourdon, Gane y Sarson y otros presentaron variaciones a la propuesta original. A mediados de los 80, Ward y Mellor proponen ampliaciones para su aplicación en sistemas de tiempo real y más tarde, Hatley y Pirbhai presentan sus aportes a estos mismos sistemas.

Características

Descomposición / Modularización Soporte gráfico Ausencia de Redundancia Centrado en modelizar el flujo y el contenido de la información PROCESOS y

DATOS Aproximación TOP-DOWN



Elementos del Modelo de Análisis

Diagramas de Flujo de Datos (DFDs)

Diccionario de Datos (DD) Diagramas de Entidad-

Relación (ER) Diagramas de Transición de

Estado (DTEs) Especificaciones de procesos (EP), de Control (EC) y de Datos (ED)

DIAGRAMAS DE FLUJO DE DATOS (DFDS)

Un modelo de proceso es una manera formal de representar cómo funciona un negocio

Los DFD son una herramienta para el modelado de procesos

Es un proceso de modelado TOP-DOWN, es decir se comienza modelando el NIVEL 0 o CONTEXTUAL, luego se procede con un refinamiento más detallado de sus subprocesos.


ER

DTE

DFD

DD

ED

EP

EC


Notación:

DICCIONARIO DE DATOS DEL DFD. “Es un conjunto de información (datos) sobre datos”, es decir es un conjunto de metadatos, que ayuda a describir el modelado de Flujos de Datos y permite organizar de forma común el conocimiento.

Objetivos del DD: Crear un Glosario de términos Establecer terminología estándar Proporcionar referencias cruzadas



Proporcionar control centralizado para cambios

Ejemplo que permite visualizar la Especificación de Procesos vs DFD y DD

El diccionario de datos de los DFD’s se describe en matrices los procesos, almacenes , entidades y flujos de datos

- Procesos: Nombre, Descripción, Nivel, Flujos entrantes, flujos salientes- Flujos de Datos: Nombre, Descripción, Alias (opcional), Origen y Destino- Almacenes y entidades: Nombre, Descripción, Flujos entrantes, flujos

salientes

DIAGRAMA ENTIDAD – RELACIÓN Se utilizan para definir el modelo de datos Identifican Objetos y sus Relaciones

DICCIONARIO DE DATOS DEL DIAGRAMA ENTIDAD RELACIÓN



Entidades: Nombre de entidad, descripción, atributos y descripción de atributosRelaciones: ID de relación, entidad padre, entidad(es) hija(s), tipo de relación, cardinalidad

4. HERRAMIENTAS CASE.

CASE. Es acrónimo de Computer Aided/Assisted Software/System Engineering. Comprende un conjunto de herramientas y metodologías que prestan soporte a un enfoque de ingeniería en el desarrollo de software o en alguna o en todas las fases de este proceso. La tecnología CASE supone la “informatización de la informática” o “la automatización del desarrollo del software”.

Objetivos: Permitir la aplicación práctica de metodologías estructuradas Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones Simplificar el mantenimiento de los programas Mejorar y estandarizar la documentación Aumentar la portabilidad de las aplicaciones Facilitar la reutilización de componentes del software Permitir un desarrollo y un refinamiento visual de las aplicaciones.

Elementos de una herramienta CASE Repositorio (Diccionario). Donde se almacenan los elementos creados por la

herramienta. Metamodelo. Marco para la definición de las técnicas y metodologías soportadas

por la herramienta. Generador de Informes. Herramienta que permite obtener la documentación

sobre el sistema que se está desarrollando. Carga/Descarga de datos. Para intercambiar datos del repositorio con otros

sistemas. Comprobación de errores. Analizar la exactitud, integridad y consistencia de los

esquemas. Interfaz de usuario. Soporte gráfico para las interacciones del usuario.

Tipos de herramienta CASE Herramientas de Gestión. Encargadas de la estimación, planificación y seguimiento

del proyecto. Herramientas Técnica.

CASE Frontales o superiores, que abarcan las primeras fases del análisis y del diseño

CASE dorsales o inferiores, que abarcan el diseño detallado y la generación del código.

Herramientas de Soporte. Como el sistema de repositorio/diccionarios, control y configuración, seguridad

Ejemplo de algunas herramientas CASE: Erwing Visual Case Easy Case



Power Designer Weilan L’Case

CASO DE ESTUDIO:

Modelar un Sistema de Información de compra de libros. El cliente elabora un pedido de libros La empresa elabora pedidos de libros a los distintos proveedores. Los proveedores aportan los libros Se informa a los clientes que sus libros han llegado

Diagrama de Contexto

Se sabe que para la gestión del sistema de pedidos, se realizan las siguientes funciones:1. Verificación de la validez del pedido del cliente2. Armar los pedidos a los editores3. Verificar el envío de los editores4. Asignar libros a pedidos5. Armar entrega a los clientes.

DFD de Nivel 1


TAREAS DEL CRÉDITO 7

Para desarrollar habilidades en el modelado de análisis del software, realice las

siguientes actividades:

1. Amplíe la investigación de los DFD’s y su diccionario de datos.

2. Profundice la investigación del MER y su diccionario de datos

3. Elabore un resumen de las herramientas CASE

4. Investigue una herramienta CASE para modelar los DFD’s y el MER

5. Como actividad del crédito 7 debe realizar el último AVANCE FINAL DE SU PROYECTO. Este avance involucra la elaboración de su documento de Análisis del

Software. A continuación se explican las orientaciones respectivas.



Realizar el modelado de análisis del software según el enfoque estructurado, del

proyecto final

El Documento de Modelado de Análisis del Software debe contener el siguiente formato:


Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso “Modelado de Análisis del

Software”) Versión del Documento





AUTO EVALUACIÓN




1. Introducción 1.1. Propósito (del documento)1.2. Definiciones, acrónimos y abreviaturas1.3. Referencias

2. Modelado de procesos2.1. DFD’s2.2. Diccionario de datos de los DFD’s

3. Modelado de Datos3.1. Modelo Entidad Relación (ER)3.2. Diccionario de datos del modelo ER

4. Anexos

1. Complete:

a. En el contexto de los DFD, ¿qué es proceso? : ………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

e. Ventajas del modelado………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

f. Enfoques del análisis del software:………………………………………………………………………....................................................................................................................………………....................................................................................................................………………....................................................................................................................

2. Describa la notación de los DFD’s




3. Explique el proceso de Modelado de Datos





ANEXO 1. SOLUCIONES DE AUTOEVALUACIÓN

SOLUCIONES DE AUTOEVALUACIÓN AL TEMA I

ENUNCIADO 1:a. Verdadero b. Falsoc. Verdaderod. Falso, en ingeniería de software, el “software” no solo a los programas

sino también los documentos y datos.


Guia Ingenieria Del Software i

Documents

Transcript of Guia Ingenieria Del Software i