Guía Ing - SW I EAD - 2009

UNIVERSIDAD TECNOLGICA SAN ANTONIO DE MACHALA
ESCUELA DE INFORMTICA
MODALIDAD DE EDUCACIN SEMIPRESENCIAL Y A DISTANCIA

GUA DE ESTUDIO
INGENIERA DE SOFTWARE I
QUINTO SEMESTRE
ING. BERTHA MAZN 2009 EL ORO ECUADOR
TABLA DE CONTENIDO
Introduccin. . Informacin Problema, . objeto, general.... objetivos.. 2 5 6 7 9 11 13 14
Sistema de contenidos. .. Bibliografa Estrategias Metodolgicas. de
Sistema Evaluacin... Actividades de ..
Aprendizaje.....
UTSAM-Modalidad Semipresencial y a Distancia
INTRODUCCIN
Con la perseverancia se obtiene la fortaleza y esto nos permite, no dejarnos llevar por lo fcil y lo cmodo . Bertha Mazn 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 inciales. Estudiar una profesin como sistemas en modalidad semipresencial o a distancia no es fcil, tus propsitos deben mantenerse firmes, debes levantarte al caer y gozar del triunfo que acompaa al trabajo terminado. Vamos a iniciar el estudio de INGENIERA DE SOFTWARE I, cuyo requisito es Bases de Datos I y Programacin 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 podrs desarrollar software para empresas y/u organizaciones, logrando alcanzar el nivel que en nuestra Institucin exigimos a los futuros ingenieros de sistemas. El objetivo de esta asignatura es desarrollar software de calidad que resuelvan problemas de todo tipo, aplicando mtodos, tcnicas y herramientas del proceso de ingeniera de software como anlisis, diseo e implementacin y los conocimientos adquiridos de programacin, sistemas operativos, bases de datos y redes de computadoras, para lo cual dividiremos el contenido temtico en cuatro temas que son: TEMA I: INTRODUCCIN A LA INGENIERA DE SOFTWARE. Nos permitir caracterizar los conceptos, elementos y procesos de la Ingeniera de Software. TEMA II: INGENIERA DE REQUISITOS. Con este tema te preparars para realizar la especificacin de los requisitos de software del problema planteado.
UTSAM-Modalidad Semipresencial y a Distancia 3
TEMA III: GESTIN DE PROYECTOS DE SOFTWARE. Aprenders a desarrollar la gestin del proyecto de software mediante la elaboracin de la planificacin del proyecto, el anlisis de riesgos, la configuracin del software y el control de calidad que permita desarrollar un producto que satisfaga las necesidades del cliente. TEMA IV: ANLISIS DEL SOFTWARE: Con este tema sers capaz de elaborar el modelado del software segn el enfoque estructurado mediante el estudio y anlisis 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 utilizars herramientas como: Microsoft Project, Erwin y Visual CASE. Recordemos la misin y visin de nuestra institucin en esta modalidad: Misin A travs 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 crtico y reflexivo, capaces de participar activamente en el fortalecimiento de las capacidad es productivas y de servicio. Visin Brindar el acceso del sector a los procesos de educacin superior, generando una nueva orientacin de su vinculacin con la comunidad local, regional y nacional, demostrando la apertura de la Institucin de servir a la comunidad. Recibe pues, un fuerte abrazo de bienvenida y los deseos ms sinceros de ayuda de tal manera que pueda aportar con un granito de arena a tu formacin profesional. Bienvenido.a estudiar Ingeniera de Software!!!!!!!!!!!
Bertha Mazn.
INFORMACIN GENERAL
DATOS GENERALES Escuela Especialidad Asignatura Nmero de crditos Total Horas Docente : : : : : : INFORMTICA. Ingeniera en Sistemas. Ingeniera de Software I. 7 112 Hrs.
Telfono
E-mail
:
:
.
.
Las fechas de las jornadas presenciales confrmelas en su centro universitario, Coordinacin de Educacin a distancia (UTSAM-EAD) Le recomendamos que desde el momento en el que disponga del material bibliogrfico inicie el desarrollo de las actividades propuestas en esta Gua de estudio. FUNDAMENTACIN 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 fcil de modificar o incluso es ms fcil de utilizar, puede cambiar todas las cosas y de hecho las cambia para mejorar. Para tener xito al disear y construir un software se necesita disciplina. Es decir, se necesita un enfoque de ingeniera La Ingeniera de software es un rea de informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelve problemas de todo tipo. Hoy en da es cada vez ms frecuente la consideracin de la Ingeniera de Software como una nueva rea de la ingeniera y es una profesin implantada en el mundo laboral nacional e internacional. Es por esta razn que esta materia pasa hacer troncal o fundamental para los estudiantes de la carrera de Ingeniera en Sistemas de la Escuela de Informtica de la UTSAM, la misma que permitir desarrollar habilidades y destrezas en el anlisis, diseo e implementacin de software resolviendo todo tipo de problema.
PROBLEMA, OBJETO, OBJETIVO

PROBLEMA La necesidad de aplicar los procesos de ingeniera de software para el desarrollo de soluciones informticas de calidad que resuelvan problemas de todo tipo en empresas e instituciones
OBJETO El proceso de ingeniera 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 mtodos, tcnicas y herramientas del proceso de ingeniera de software como anlisis, diseo e implementacin para la obtencin de un sistema informtico de calidad y la satisfaccin del usuario.
EDUCATIVO Fomentar en los estudiantes la prctica de valores como la responsabilidad, honestidad, criticidad, equidad y compaerismo, en el desarrollo de sistemas informticos para empresas e instituciones considerando su realidad socioeconmica y los avances tecnolgicos.
COMPETENCIA Desarrollo de software de calidad considerando mtodos, tcnicas y herramientas del proceso de ingeniera de software como anlisis, diseo e implementacin, con actitud profesional y mentalidad positiva.
SISTEMA DE CONTENIDOS
TEMA I: OBJETIVO: COMPETENCIA: DURACIN: INTRODUCCIN A LA INGENIERA DE SOFTWARE (ISW) Conceptualizar terminologa y modelos de Ingeniera de Software. Conceptualiza terminologa y describe modelos de la ISW . (16 horas) SISTEMA DE SISTEMA DE CONOCIMIENTOS SISTEMA DE HABILIDADES VALORES Conceptos: software, Conceptualizar Responsabilidad ingeniera de software, terminologa referente a la Criticidad producto, proceso, mtodo, ingeniera del software. Honestidad tcnica, metodologa, Caracterizar los Compaerismo herramienta, paradigma modelos (paradigmas o ciclos (modelo o ciclo de vida). de vida) de desarrollo del Actividades genricas software. de la ingeniera de software Diferenciar el Modelos de la producto y el proceso ingeniera del software Describir la evolucin Evolucin de la de la ingeniera del software y ingeniera de software la crisis del software Crisis del software Describir las Principales principales organizaciones de organizaciones de estandarizacin y los estandarizacin de la ingeniera estndares que se promueven del software Principales estndares de la ingeniera del software. TEMA II: OBJETIVO: INGENIERA DE REQUISITOS Realizar la especificacin de los requisitos de software del problema planteado. COMPETENCIA: Redacta documentos de especificacin del software. DURACIN: (32 horas) SISTEMA DE SISTEMA DE SISTEMA DE CONOCIMIENTOS HABILIDADES VALORES Conceptos de Ingeniera de Identificar y Responsabilidad Requisitos recolectar requisitos Criticidad Descripcin de las actividades del Validar y Honestidad proceso de la IR gestionar requisitos Obtencin de requisitos Elaborar los Anlisis de requisitos requisitos del software Especificacin de Requisitos segn el estndar de IEEE 830
Validacin de requisitos Gestin de requisitos
TEMA III: GESTIN DE PROYECTOS DE SOFTWARE OBJETIVO: Gestionar el proyecto de software mediante planificacin, seguimiento y control del proceso de desarrollo de software y la realizacin de actividades de soporte como: anlisis de riesgos, configuracin del software y control de calidad que permita la construccin de un producto que satisfaga las necesidades del cliente. COMPETENCIA: Gestiona proyectos de software. DURACIN: (48 horas) SISTEMA DE SISTEMA DE SISTEMA DE CONOCIMIENTOS HABILIDADES VALORES CONCEPTOS SOBRE GESTIN DE Gestionar el Responsabilidad PROYECTOS DE SOFTWARE personal, el proceso y el Compaerismo El espectro de gestin, el problema durante el Honestidad personal, el producto, el proceso, el proyecto de software proyecto PLANIFICACIN DEL PROYECTO DE Identificar y Responsabilidad SOFTWARE generar equipos de Compaerismo Objetivos de la planificacin software, estimaciones Honestidad del proyecto fiables del esfuerzo, mbito del software, recursos costes y duracin del Estimacin del proyecto de proyecto software o Tcnicas de puntos de funcin o Modelos empricos de estimacin La decisin desarrollarcomprar PLANIFICACIN TEMPORAL Y Desarrollar la Responsabilidad SEGUIMIENTO DEL PROYECTO planificacin temporal de Compaerismo Conceptos bsicos, la relacin proyecto Honestidad entre las personas y el esfuerzo Definicin de un conjunto de tareas para el proyecto de software. Seleccin de las tareas de Ing. SW Refinamiento de las tareas principales Definir una red de tareas ANLISIS DE RIEGOS Identificar y Responsabilidad Estrategias de riesgos utilizar las tcnicas para Compaerismo Riesgos del software la evaluacin de los Honestidad Identificacin y proyeccin del riesgos que pueden riesgo tener impacto en el xito
Reduccin, supervisin y gestin del riesgo Riesgos y peligros para la seguridad PLAN DE GARANTA DE CALIDAD Introduccin Documentacin Revisiones y auditorias Gestin de Configuracin PLAN DE GESTIN DE CONFIGURACIN Introduccin Actividades de GCS Programacin TEMA IV: OBJETIVO:
del proyecto.
Definir y controlar la calidad de un proyecto Identificar y realizar la forma de gestionar los cambios durante el desarrollo de software y despus de entregar al cliente
Responsabilidad Compaerismo Honestidad Responsabilidad Compaerismo Honestidad
MODELADO DE ANLISIS DEL SOFTWARE Elaborar el modelado del software mediante el estudio y anlisis de los requisitos del software, las metodologas de anlisis y la elaboracin del prototipo que permita la obtencin de modelos fsicos y lgicos para el diseo del software. COMPETENCIA: Crea modelos conceptuales del software. DURACIN: (16 horas) SISTEMA DE SISTEMA DE CONOCIMIENTOS SISTEMA DE HABILIDADES VALORES INTRODUCCIN AL MODELADO Comprender la Responsabilidad Conceptos de modelado, importancia del modelado Criticidad utilidad, abstraccin, ventajas de software Honestidad Compaerismo ANLISIS ESTRUCTURADO Obtener una Responsabilidad Breve historia, representacin general del Criticidad caractersticas software a construir a partir Honestidad Elementos del modelo del de la especificacin de los Compaerismo anlisis requisitos. Modelado funcional o de procesos y flujo de informacin(DFDs), su notacin y diccionario de datos Modelado de datos (ER) y su diccionario de datos HERRAMIENTAS CASE (TI) Identificar los tipos Responsabilidad Que es CASE de CASE Criticidad Objetivos de las CASE Utilizar las Honestidad Elementos de las CASE herramientas CASE apara Compaerismo Tipos de CASE el desarrollo del software Ejemplos de CASE
10
BIBLIOGRAFA
TEXTO BSICO: Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005
BIBLIOGRAFA COMPLEMENTARIA: Kendall & Kendall, Anlisis y Diseo de software Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2002 Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Cuarta Edicin. Mc-Graw-Hill/Interamerica de Espaa 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 Durn Toro, Beatriz Bernrdez Jimnez, Metodologa para el anlisis de Requisitos de Sistemas Software. Versin 2.1 Informe Tcnico. Departamento de Lenguajes y Sistemas Informticos Facultad de Informtica y Estadstica Sevilla, 2001 S. L. Pfleeger, "Software Engineering: Theory and Practice," Second ed: PrenticeHall, 2001. Palacios, Juan. Compendio de Ingeniera de SW I. ltima revisin: Junio 2006. Documento Electrnico: CIS I 04.PPT.
REVISTAS TCNICAS Revista PC WORLD Revista PC MAGAZINE (Ingles, Espaol) URLs: "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
11
Con toda esta referencia bibliogrfica t puedes ampliar tus conocimientos acerca de la temtica propuesta.
12
ESTRATEGIAS METODOLGICAS
Para el desarrollo de las actividades propuestas se recomienda lo siguiente: 1. Tener una actitud positiva, voluntad, motivacin e inters. 2. Lee reflexivamente la bibliografa bsica, 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 mnimo, los textos bsicos o guas expuestos en la bibliografa y reforzar con algunos textos complementarios. 4. Cuando hayas hecho esta primera lectura comprensiva, procede a desarrollar las actividades poniendo en prctica tu actitud crtica y reflexiva, tu capacidad de sntesis y tu creatividad. 5. Para estudiar debes elegir siempre un lugar tranquilo, cmodo con buena iluminacin, y tener sobre la mesa la bibliografa bsica, diccionario, papel. Esfero, etc. 6. Planifica el tiempo dedicado al sueo y a las comidas, casi todos necesitamos de 8 horas de sueo. 7. Dedica una hora por la maana que se distribuye para: gimnasia matinal, aseo personal, vestirse desayunar. 8. Toma en cuenta las horas que son dedicadas a tu trabajo u ocupacin 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 planificacin y un horario si no eres constante. 10. Utiliza fichas de trabajo o algn cuaderno de resmenes. 11. Si algn tema o problema no est claro, no dudes en llamar o ponerte en contacto con tu profesor gua a fin de solucionar las inquietudes. Favor no quedarse con stas porque irn formando lagunas en su aprendizaje que luego son difciles de corregir. 12. Para los encuentros con el profesor gua revisa la ltima tarea realizada y a continuacin lee detenidamente las instrucciones dadas en la gua 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 mnimo 512MB Instaladores de EasyEclipse Desktop Java 1.2.2., Microsoft Office, Mysql, Sqlyog Enterprise, herramientas de anlisis y diseo de SW (CASE): Visual Case, Erwin, Micrososft Project. Todos tus trabajos debes entregarlos en CD. Lee reflexivamente el texto gua, 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.
13
Para realizar las actividades, adems de la lectura puedes ayudarte con la tcnica del subrayado, mapas conceptuales, cuadros sinpticos, etc. Presente el trabajo desarrollado en computadora con el formato siguiente. o Papel INEN A4, utilice sangra, mrgenes, ortografa o Margen Superior : 3 cm o Margen Inferior : 2.5 cm. o Margen Izquierdo : 3.5 cm. o Margen Derecho : 2.5 cm. Incorporamos en esta gua los siguientes grficos para un mejor desarrollo Actividad Propuesta (tarea). Te presento una serie de ejercicios que permitirn reforzar los conocimientos adquiridos motivando a la investigacin bibliogrfica.
Referencia bibliogrfica: Bibliografa recomendada segn texto bsico propuesto, los captulos y pginas donde encontrars informacin relacionada con el tema a tratar. Autoevaluacin Un instrumento que te permitir medir el avance acadmico.
Tiempo estimado de estudio: Tiempo en horas de 60 minutos necesarias para la asimilacin del conocimiento. Nota importante: Aspectos a los que debes poner atencin y que considero clave para el desarrollo de la asignatura. Tutora programada Recordatorio a tu derecho de consulta al tutor, en el momento necesario y a la hora establecida para las tutoras.
Recuerde
EL TRABAJO ES PERSONAL, NO SE ACEPTARAN COPIAS NI TRABAJOS IGUALES!
14
SISTEMA DE EVALUACIN
La evaluacin ser continua durante el desarrollo de las temticas programadas y se la realizar con base en los siguientes criterios: Aplicacin de conocimientos tericos, capacidad de anlisis y sntesis Creatividad en la resolucin de problemas Capacidad para seleccionar las opciones u alternativas ms adecuadas en la resolucin de problemas Originalidad y cientificidad, calidad de presentacin de los trabajos (limpieza, orden etc.) Puntualidad
De acuerdo al sistema de crditos de la UTSAM: Trabajos de encuentros presenciales (TE) Trabajos de la gua de estudios(TG) Evaluacin (E) Nota final del crdito: Suma (TE, TG, E)

10% 10 % 30% 50%
Trabajos de encuentros presenciales: Defensa de trabajos de investigacin, desarrollo de ejercicios en clase, talleres, debates, Exposiciones de consultas, otros Trabajos de la gua de estudios: consultas, desarrollo de ejercicios, resmenes, autoevaluaciones, otros El promedio de todos los crditos (PC) corresponder al 50% de la nota final El estudiante deber desarrollar un PROYECTO FINAL (PF) que integre las temticas tratadas en la asignatura y se evaluar sobre el 50%. La nota final se obtiene sumando el promedio de los crditos y la nota del examen (PC+PF)
Reflexiona:
Slo el estudio libera al hombre de las ataduras de su ignorancia!
15
16
INTRODUCCIN A LA INGENIERA DE SOFTWARE (ISW)
SISTEMA DE CONOCIMIENTOS Conceptos: software, ingeniera de software, producto, proceso, mtodo, tcnica, metodologa, herramienta, paradigma (modelo o ciclo de vida). Actividades genricas de la ingeniera de software Modelos de la ingeniera del software Evolucin de la ingeniera de software Crisis del software Principales organizaciones de estandarizacin de la ingeniera del software Principales estndares de la ingeniera del software. -
SISTEMA DE HABILIDADES Conceptualizar terminologa referente a la ingeniera del software. Caracterizar los modelos (paradigmas o ciclos de vida) de desarrollo del software. Diferenciar el producto y el proceso Describir la evolucin de la ingeniera del software y la crisis del software Describir las principales organizaciones de estandarizacin y los estndares que se promueven
SISTEMA DE VALORES Responsabilidad Criticidad Honestidad Compaerismo
TIEMPO ESTIMADO DE ESTUDIO

Horas presenciales: Horas de investigacin: Total horas mnimas requeridas del tema: Horas de actividades laborales: Total de Horas de estudio del tema: 8 8 16 8 24
INTRODUCCIN INTRODUCCIN
En la actualidad, el software de computador es la tecnologa ms importante en el mbito mundial, las economas de los pases desarrollados dependen en gran parte del software,
ms y ms sistemas son actualmente controlados por software. El software es el producto que los ingenieros de software construyen y despus mantienen en el largo plazo. Incluye los programas que se ejecutan dentro de una computadora de cualquier tamao y arquitectura. La Ingeniera de Software concierne a teoras, mtodos y herramientas para el desarrollo profesional de software.
OBJETIVO
Conceptualizar terminologa y modelos de Ingeniera de Software.
ESQUEMA ESQUEMADEL DELTEMA TEMAI I
21
ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAI I

Para el estudio del Tema I necesitas revisar la siguiente bibliografa:
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1, 2, 3, 4; Pginas:1-99. Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1 y 2; Pginas: 3-33. Palacios, Juan. Compendio de Ingeniera de SW I. ltima revisin: Junio 2006. Documento Electrnico: CIS I 04.PPT. Captulos 1 y 2, Diapositivas: 1- 53.
1. CONCEPTOS DE INGENIERA DE SOFTWARE
En este tema se realiza una introduccin a la Ingeniera del software. Se revisan conceptos como: software, ingeniera de software, producto, proceso, actividad, tarea, paradigma, metodologa, tcnica, herramientas, estndares, entre otros. Principales conceptos a tener en cuenta en la ingeniera de software
Mtodo Mtodo
Proceso a seguir para resolver una situacin o Proceso a seguir para resolver una situacin o problema con un orden y objetivos establecidos. problema con un orden y objetivos establecidos. Proceso {actividades} {tareas} Proceso {actividades} {tareas} Estrategia para desarrollar una actividad de un Estrategia para desarrollar una actividad de un mtodo mtodo Mtodo + tcnicas + soporte documental Mtodo + tcnicas + soporte documental
Tcnica Tcnica Metodologa Metodologa Herramienta Herramienta Producto Producto
Soporte automatizado, Ejm. CASE, CARE Soporte automatizado, Ejm. CASE, CARE Resultado de cada etapa o actividad, denominado Resultado de cada etapa o actividad, denominado tambin entregable tambin entregable
El software se ha convertido en el elemento clave de la evolucin de los sistemas y productos informticos. El software considerado como el producto se compone de
programas, datos y documentos. Cada uno de estos elementos componen una configuracin que se crea como parte del proceso de la ingeniera del software. Qu es la ingeniera de software? Hay diferentes autores que conceptualizan la ingeniera de software desde sus propias perspectivas, sin embargo todos guardan relacin. A continuacin se presentan algunos conceptos de diferentes autores: Por ejemplo la definicin que propuso Fritz Bauer en una conferencia mundial en 1968: La ingeniera de software es el establecimiento y uso de principios de la ingeniera para obtener econmicamente un software confiable y que funcione eficiente en mquinas reales Ingeniera del Software es la aplicacin practica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin 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). Ingeniera al software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin (funcionamiento) y mantenimiento del software (IEEE, 1993). La ingeniera de software es una disciplina que integra al proceso, los mtodos y las herramientas para el desarrollo del software de computadora. Se ha propuesto un gran nmero de modelos para la ingeniera de software, pero todos definen un conjunto de actividades del marco de trabajo, una coleccin de tareas conducidas para realizar cada actividad, productos de trabajo generados como consecuencia de las tareas y un conjunto de actividades de soporte que acompaan el proceso entero. Un objetivo de dcadas ha sido el encontrar procesos o metodologas 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 aos 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 genricas del marco de trabajo: comunicacin, planeacin, modelado, construccin y despliegue.
2. ACTIVIDADES GENRICAS DE LA INGENIERA DE SOFTWARE
Comunicacin Esta actividad del marco de trabajo implica una intensa colaboracin y comunicacin con los clientes; adems abarca la investigacin de requisitos y otras actividades relacionadas. Planeacin Esta actividad establece un plan para el trabajo de la ingeniera del software. Describe las tareas tcnicas que deben realizarse, los riesgos probables, los recursos que sern requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado Esta actividad abarca la creacin de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseo que lograr satisfacerlos.
Construccin Esta actividad combina la generacin del cdigo y la realizacin de pruebas necesarias para descubrir errores en el cdigo. Despliegue El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quin evala el producto recibido y proporciona informacin basada en su evaluacin. Segn el estndar ISO 12207, los procesos de la ingeniera de software se organizan en: proceso primario (Actividades: adquisicin, suministro, desarrollo, operacin y mantenimiento), proceso de soporte (Actividades: documentacin, gestin de la configuracin, control de calidad, verificacin, validacin, reuniones, auditora, resolucin de problemas) y proceso organizacional (Actividades: gestin, infraestructura, mejora y formacin). Tambin, se identifican como actividades genricas del la ingeniera del software a las siguientes:
Anlisis Anlisis
Implementaci Implementaci n n
Gestin Gestin del del Proyect Proyect o o
Planeaci Planeaci n n
Pruebas Pruebas
Desarroll Desarroll o o
3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERA DEL SOFTWARE
La ingeniera de software tiene varios modelos considerados tambin paradigmas o ciclos de vida de desarrollo en los cuales se puede apoyar para la realizacin de software, de los cuales podemos destacar algunos por ser los ms utilizados y los ms completos: el modelo de cascada o ciclo de vida clsico, los modelos incrementales, el DRA (Desarrollo Rpido de Apicaciones), los procesos evolutivos como la construccin de prototipos y el espiral, el modelo basado en componentes, los mtodos formales (CMM, CMMI), el orientado a aspectos, el proceso unificado UML, los mtodos giles.
4. EVOLUCIN DE LA INGENIERA DE SOFTWARE
La ingeniera de software es una disciplina muy joven, a finales de la dcada de los 60 comenzaron a establecer algunos principios bsicos, sin embargo se ha producido una preocupante crisis del software de la cual an no se logra salir. A continuacin se presenta una breve evolucin:
(< 1968) Dominios sencillos El software era diseado a medida Carencia de mtodos sistemticos La programacin del software se consideraba como un arte. (1968) Fritz Bauer, utiliza por primera vez el trmino Ingeniera 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 Separacin desarrollador cliente Exigencias de calidad Desarrollo en grupos Crisis del software Se evidencia una preocupacin de las universidades y organismos de estandarizacin (SEI, IEEE, ISO) por el desarrollo de estndares, metodologas, tcnicas y herramientas para la ingeniera de software.
5. CRISIS DEL SOFTWARE
El trmino 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 adems 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 ms sencillos hasta los de misin crtica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos das, las aplicaciones tpicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software. A continuacin se citan algunas causas de la crisis del software: Imprecisin en la planificacin del proyecto y estimacin de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseo poco estructurado, etc. Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra. Tambin se requiere una serie de caractersticas como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc
25
Comparativa de proyectos para el desarrollo de sistemas de software

Fracaso 2004 2000 1998 1995 1994 31% 19% 23% 28% 40% Problemtico 53% 49% 46% 33% 53% xito 29% 28% 26% 27% 16%
Proyecto no terminado, nunca se llega a utilizar Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionales Proyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey
(http://www.standishgroup.com/)
6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIN DE LA INGENIERA DE SOFTWARE
Desde la identificacin del fenmeno crisis del software, han sido muchas las organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores garantas de xito. Han sido muchos los departamentos de universidades, organismos de normalizacin o investigacin nacionales o internacionales, sociedades de profesionales, departamentos de defensa, departamentos de calidad y procesos de empresas los que han ido generando normas y estndares. Se considera como entidades de mayor reconocimiento internacional, por sus trabajos y esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a: ISO, SEI e IEEE- Computer Society. ISO. Organizacin Internacional para la Estandarizacin, fundada en 1947. Son miembros 87 pases. En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin
Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y equipos. Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software: ISO/IEC 12207 ISO/IEC TR 15504 SEI. Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la Universidad Carnegie Mellon. La aportacin ms significativa de este Instituto son los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi 15 aos de implantacin efectiva en entornos de produccin de software han demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de resultados previsibles de una organizacin de software. IEEE Computer Society IEEE Es el Instituto de Ingenieros en Electricidad y Electrnica (Institute of Electrical and Electronics Engineers). Su misin es preservar, investigar y promover la informacin de las tecnologas elctricas y electrnicas. Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) 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 ms de 100.000 miembros en todo el mundo. Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares. IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software son: IEEE Std. 830 Prcticas recomendadas para las especificaciones de software. IEEE Std. 1362 Gua para la especificacin del documento de requisitos ConOps IEEE Std. 1063 Estndar para la documentacin de usuario de software. IEEE Std. 1012 Estndar para la verificacin y validacin de software. IEEE Std. 1219 Estndar para el mantenimiento del software
27
7. PRINCIPALES ESTNDARES Y MODELOS DE LA INGENIERA DE SOFTWARE

La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse Definirse a a s s misma misma:: Cules Cules son son las las reas reas de de conocimiento conocimiento que que la la comprenden? comprenden? SWEBOK: Software Engineering Body of knowledge http://www.swebok.org Definir Definir los los procesos procesos que que intervienen intervienen en en el el desarrollo, desarrollo, mantenimiento mantenimiento y y operacin operacin del del software software ISO/IEC 12207: Procesos del ciclo de vida del software De De las las mejores mejores prcticas, prcticas, extraer extraer modelos modelos de de cmo cmo ejecutar ejecutar esos esos procesos procesos para para evitar evitar los los problemas problemas de de la la crisis crisis del del software software CMM / CMMI ISO/IEC TR 15504 Definir Definir estndares estndares menores menores para para dibujar dibujar criterios criterios unificadores unificadores en en requisitos, requisitos, pruebas, pruebas, gestin gestin de de la la configuracin, configuracin, etc. etc. IEEE 830 - IEEE 1362 - ISO/IEC 14764
Los estndares son tiles porque: Agrupan lo mejor y ms apropiado de las buenas prcticas 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.
28
TAREAS TAREASDEL DELCRDITO CRDITO11

Realice las siguientes actividades para fortalecer el aprendizaje del tema: Realice las siguientes actividades para fortalecer el aprendizaje del tema:
Investigue los conceptos de los siguientes trminos: Investigue los conceptos de los siguientes trminos: Ingeniera Ingeniera Ingeniera de sistemas Ingeniera de sistemas Sistema y Software Sistema y Software Ingeniera de software Ingeniera de software Producto, proceso y personas(Recurso Humano) en el desarrollo de software Producto, proceso y personas(Recurso Humano) en el desarrollo de software Mtodos, paradigmas o ciclos de vida Mtodos, paradigmas o ciclos de vida Metodologa, tcnicas, tecnologa y herramientas Metodologa, tcnicas, tecnologa y herramientas Realice un cuadro donde se resuma las caractersticas, ventajas y desventajas de los Realice un cuadro donde se resuma las caractersticas, ventajas y desventajas de los paradigmas de desarrollo de software paradigmas de desarrollo de software Explique las causas de la crisis del software Explique las causas de la crisis del software Grafique y explique el proceso genrico de la ingeniera del software Grafique y explique el proceso genrico de la ingeniera del software Describa las principales organizaciones de estandarizacin de la ingeniera de software Describa las principales organizaciones de estandarizacin de la ingeniera de software Describa los principales estndares y modelos de ingeniera de software. Describa los principales estndares y modelos de ingeniera de software. Realice el primer avance del proyecto final. Revise las orientaciones que se explican a Realice el primer avance del proyecto final. Revise las orientaciones que se explican a continuacin continuacin
ORIENTACIONES ORIENTACIONESPARA PARAEL ELPROYECTO PROYECTOFINAL FINAL
Realizar una pre-investigacin de una empresa o institucin donde se va a desarrollar el proyecto de software de fin de asignatura, y como resultado de esa investigacin, elaborar el documento del estudio preliminar en el cual se describir brevemente el problema a dar solucin. El Estudio preliminar debe contener el siguiente formato: Cartula (Primera pgina): Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso Estudio Preliminar) Versin del Documento
A todas las pginas del documento colocar:

29
Encabezado de pgina: Cdigo y nombre del documento, nmero de pgina, versin, Nombre del Proyecto Pie de pgina: Autor y fecha de creacin
Control de Cambios (Segunda Pgina): Es una matriz que incluye los siguientes campos: fecha de cambio, descripcin del cambio, responsable, versin ndice (Tercera pgina)
1. Introduccin (Hacer un breve resumen del documento) 1.1. Propsito (del documento del estudio preliminar) 1.2. Definiciones, acrnimos y abreviaturas 1.3. Referencias 2. Datos de la empresa o institucin donde se desarrollar el proyecto de software: nombre de la empresa o institucin, direccin, telfonos, ciudad 3. Fuentes de informacin (las personas de la empresa o posibles usuarios directos e indirectos del software) 4. Descripcin de la institucin o empresa (Realizar una breve descripcin histrica, misin y visin en caso de tener) 4.1. Objetivos de la institucin (general y especficos) 4.2. Orgnico funcional (organigrama funcional) 4.3. Orgnico de procesos (funciones de cada uno de los cargos) 4.4. Funcionamiento actual de la empresa, 4.5. Identificacin de problemas, causas y posibles efectos 5. Alternativa(s) de solucin y objetivos de la empresa con el software a desarrollar) 6. Anexos
AUTOEVALUACIN AUTOEVALUACINTEMA TEMAI I

1. Conteste con una (V) si es verdadero o con una (F) si es falso: a. ( ) El producto en ingeniera de SW es considerado como el resultado de ejecutar una actividad o tarea. b. ( ) El proceso es un conjunto de entregables. c. ( ) La tcnica es la estrategia que se aplica para ejecutar una actividad de un mtodo d. ( ) El software es considerado como el conjunto de programas. 2. Complete: a. Con sus propias palabras defina el trmino Ingeniera de Software: .................................................................................................................... .................................................................................................................... b. Mtodo en ingeniera de software........................................................... .................................................................................................................... ....................................................................................................................
c. Tcnicas: .................................................................................................................... .................................................................................................................... d. CASE: .................................................................................................................... .................................................................................................................... Principales organizaciones de estandarizacin: .... .................................................................................................................... .................................................................................................................... Proceso: .... .................................................................................................................... .................................................................................................................... 3. Elabore un cuadro resumen de las caractersticas de los diferentes paradigmas de desarrollo de software
4. Describa las etapas de un proceso de Ingeniera de SW Genrico
5. Describa brevemente los principales estndares de la ingeniera de software
TUTORAS TUTORASPROGRAMADAS PROGRAMADAS

Consulte en su centro de informacin o a su tutor el horario de los encuentros presenciales, y/o virtuales (Chat) o las consultas por telfono. Anote a continuacin para que lo tenga en cuenta en el desarrollo de este tema: Fecha Hora Actividad
31
INGENIERA DE REQUISITOS
NGENIERA DE SOFTWARE I
SISTEMA DE SISTEMA DE HABILIDADES VALORES Conceptos de Ingeniera de Identificar y Responsabilidad Requisitos recolectar requisitos Criticidad Descripcin de las actividades del Validar y gestionar Honestidad proceso de la IR requisitos Obtencin de requisitos Elaborar los Anlisis de requisitos requisitos del software Especificacin de Requisitos segn el estndar de IEEE 830 Validacin de requisitos Gestin de requisitos SISTEMA DE CONOCIMIENTOS
TIEMPO TIEMPOESTIMADO ESTIMADODE DEESTUDIO ESTUDIO

Los requisitos constituyen un insumo determinante en el desarrollo del software; los usuarios o clientes juegan un papel de proveedores de informacin y los desarrolladores deben interactuar con ellos para la obtencin de requisitos. La fase de requisitos del software se puede describir como un proceso ingenieril (por esta razn algunos autores lo consideran como Ingeniera de Requisitos (IR)) que consta de una serie de actividades que dan lugar, fundamentalmente, a una especificacin del producto software que se ha decidido construir. En concreto todas ellas se organizarn por actividades de educcin u obtencin de informacin, de especificacin, de validacin y de gestin. En los ltimos aos han surgido grandes cambios en el campo de la Ingeniera de Requisitos. As, en primer lugar, se ha establecido un reconocimiento general de la importancia de la Ingeniera 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
35
especificacin de requisitos o la gestin de requisitos del usuario, son algunas de las consideradas ms crticas en el desarrollo y la produccin del software. Pero, en segundo lugar, y como consecuencia de la asuncin de esta problemtica situacin por parte de los implicados en la industria del software, se ha llegado a introducir explcitamente la Ingeniera de Requisitos en modelos de Mejora del Proceso Software. O, por la misma razn, se han desarrollado guas e interpretaciones que permiten el estudio de la conformidad de procesos y productos de la Ingeniera de Requisitos a estndares internacionales de Calidad que buscan garantizar la satisfaccin del cliente. Este tema trata la implicacin entre aspectos de calidad del producto final con las prcticas relacionadas con la Ingeniera de Requisitos.
OBJETIVO
Realizar la especificacin de los requisitos de software del problema planteado
ESQUEMA ESQUEMADEL DELTEMA TEMAIIII
36
ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAIIII
Para el estudio del Tema II necesitas revisar la siguiente bibliografa: Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1, 2, 3, 4; Pginas: 1-99. Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1 y 2; Pginas: 3-33. Palacios, Juan. Compendio de Ingeniera de SW I). ltima revisin: Junio 2006. Documento Electrnico: CIS I 04.PPT. Captulo 3, Diapositivas: 54- 117. P. Loucopoulos, V. Karakostas; System Requirements Engineering; McGraw-Hill International series in Software Engineering, 1995. Kendall & Kendall, Anlisis y Diseo de software. Captulos 4-8, Pginas: 79-213
37
1. CONCEPTOS DE INGENIERA DE REQUISITOS
Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseado 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. Ingeniera del Software Mc Graw Hill 1995). En este tema se tratar el proceso de la Ingeniera de Requisitos y su importancia como etapa fundamental en el desarrollo de SW. El documento de Especificacin de Requisitos (ERS en espaol o SRS en ingls) es un producto importante que servir de base para procesos subsiguientes de ingeniera de software como planificacin, anlisis, diseo, construccin, pruebas y validacin con los usuarios. Importancia de los Requisitos Los requisitos indudablemente son importantes porque constituyen la base para los dems 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 ms difcil en la construccin de sistemas software es decidir precisamente qu construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con humanos, mquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto el resultado final si se realiza de forma errnea. Ninguna otra parte es tan difcil de rectificar posteriormente (Frederick P. Brooks J., 1987. Es autor del libro The mythical Man-Month, un clsico de la Ingeniera del Software escrito en 1975 y reeditado 20 aos despus y que an 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 slo el 16% de los proyectos de software se realizan con xito. El estudio identific como principales causas de los problemas: Falta de informacin por parte de los usuarios Requisitos deficientes (incompletos y cambiantes) La planificacin de agendas y estimaciones de costes no se realizaron en base a los requisitos Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto Los criterios de xito de un proyecto son: Implicacin de los usuarios Apoyo de los directivos
38
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 Segn Boehm (1975), 45% de los errores tienen su origen en los requisitos y en el diseo preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto SW, se deben a una mala especificacin 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 tamao medio consumen 150% ms de tiempo Alrededor de 3/4 partes de sistemas grandes no funcionan como se quera o no se utilizan para nada. El 55 % de los proyectos cost ms de lo esperado El 68% incumpli plazos previstos. El 88% tuvo que redisearse El 34% se termin y no se utiliz por cambio de tecnologa Algunos casos reales de fracasos de SW: Un sensor mal programado por Francia, destruy el supe cohete europeo Ariane 5 (El Pas, 23 de junio de 1996) 2 Billones de dlares 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. Proyeccin de errores Los errores que no se logren identificar en la fase de requisitos provocarn 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. Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar algo que no se conoce. Planificacin: No se puede confiar en la planificacin para el desarrollo de algo que no se sabe bien como es. Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en restricciones o futuras evoluciones, producen arquitecturas que ms tarde se confirmarn como errneas y sern modificadas. Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y error que derrochan horas y paciencia de programacin sobre patrones de re codificacin continua y programacin heroica.
39
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen errores de bulto, o peor an, no estn reflejadas en una especificacin de requisitos, no ser posible validar el producto con el cliente.
50-200X Coste de la correccin 50-200X
Fase en la que se detecta el fallo Requisitos Arquitectura Diseo detallado Construccin Requisitos Arquitectura Diseo detallado construccin Produccin 1X 1X
Fase en la que se soluciona el fallo
Los defectos comunes en los requisitos y sus consecuencias
40
Implicacin insuficiente del cliente Requisitos crecientes y cambiantes Requisitos ambiguos Requisitos innecesarios Requisitos insuficientes Requisitos insuficientes Omisin de las necesidades de grupos de usuarios
Problemas en la validacin del producto obtenido Degradacin de la estructura y arquitectura del producto Prdida de tiempo en re-codificacin Trabajo innecesario Problemas en la validacin del producto obtenido Error en la estimacin y planificacin Usuarios insatisfechos
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 peda. Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su validacin. Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su peticin no est documentada y validada por l. Base objetiva para la estimacin de recursos (coste, personal en nmero 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 clculos de probabilidad que siempre implican un margen de error; por esta razn disponer de la mayor informacin posible reduce el error. Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.). Ms 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.
41
Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de partes ya desarrolladas, etc.
Qu son los requisitos? Los requisitos del sistema son La descripcin de los servicios y restricciones. IEEE define Requisito como: Condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo. Condicin o facilidad que debe proporcionar un sistema o algunos de sus subsistemas para satisfacer un contrato, norma, especificacin o cualquier otra condicin impuesta formalmente a travs de un documento. Una representacin documentada de una condicin o facilidad.
Requisito segn Norma MIL-STD STD-498. Caracterstica del sistema que es una condicin para su aceptacin. Requisito segn Goguen. Propiedad que un sistema debera tener para tener xito en el entorno en el que se usar. Un requisito define: Qu hace el sistema? Y no Cmo lo hace? mbitos de los requisitos
Sistema Sistema mbitos mbitos Software Software Requisitos Requisitos del del software software SRS SRS Descripcin Descripcin del del sistema sistema ConOps ConOps
Descripcin del sistema. Documento, tambin denominado ConOps y normalizado en el estndar IEEE Std. 1362-1998. Definicin de ConOps: Documento dirigido a los usuarios, que describe las caractersticas de un sistema propuesto, desde el punto de vista del usuario. La Descripcin del Sistema es el medio de comunicacin que recoge la visin general, cualitativa y cuantitativa de las caractersticas del sistema; compartido por la parte cliente y desarrolladora. Especificacin de requisitos del software (SRS o ERS). Un documento SRS es la especificacin de las funciones que realiza un determinado producto de software, programa o conjunto de programas en un determinado entorno.
42
A travs de los SRS se determina qu funcionalidades deben realizarse, qu datos deben generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe centrarse en los servicios que se realizarn, pero, en general, no debe especificar elementos de diseo o de proyecto. Deben centrarse nicamente en el punto de vista externo del sistema, y no en el funcionamiento interno. El documento de especificacin de requisitos puede elaborarlo el personal representativo de la parte suministradora (desarrollador), o de la parte cliente; si bien es aconsejable la intervencin de ambas partes. QU ES INGENIERA DE REQUISITOS? La Ingeniera de Requisitos comprende las actividades de desarrollo de software (y Sistemas de Informacin) relacionadas con la gestin y definicin de necesidades, restricciones y atributos de calidad para sistemas nuevos o actuales. La IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemtica y repetible. IEEE define la IR como: Proceso de estudio de necesidades de los usuarios con el objeto de llegar a una definicin del sistema HW/SW. Segn el profesor Loucopoulos: La IR consiste en un trabajo sistemtico de desarrollo de requisitos, a travs de un proceso iterativo y cooperativo de anlisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido. Proceso de la Ingeniera de Requisitos
Obtener informacin Clasificarla, localizar inconsistencias, dar prioridades, pasar a requisitos Registro y contrastacin Comprobar que son formalmente correctos y lo que el cliente quiere Controlar las modificaciones Registrar cambios, estudiar su impacto, actualizar documentacin
Obtener informacin
Escribir los requisitos
OBTENCIN
ANLISIS
ESPECIFIC ACIN
VERIFICACIN & VALIDACIN
GESTIN
1. Obtencin (elicitacin). El primer paso consiste en conocer y comprender las necesidades y problemas del cliente. En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y, en funcin de las caractersticas del entorno y del proyecto se emplean las tcnicas ms apropiadas para la identificacin de las necesidades que deben satisfacerse.
43
2. Anlisis. Una vez obtenida la informacin 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 lmites del sistema y definir su interaccin con el entorno. 3. Especificacin. 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 establecern tanto la gua desarrollo como los criterios de validacin del producto final. Documentar los requisitos es la condicin ms importante para gestionarlos correctamente. 4. Verificacin y validacin. Los requisitos deben ser formal y tcnicamente correctos (verificacin), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validacin). El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico que los diferencia es que verificacin 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 validacin comprende la adecuacin en el entorno de produccin, en el caso de la documentacin de requisitos, la conformidad por parte del cliente de que reflejan lo que l quiere. 5. Gestin. Los requisitos cambiarn 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 modificacin implica en la planificacin del proyecto.

Realiza las siguientes actividades con el propsito de reforzar conocimientos en IR: Realiza las siguientes actividades con el propsito de reforzar conocimientos en IR:
Cules son los factores de xito y de fracaso de los proyectos de software? Cules son los factores de xito y de fracaso de los proyectos de software? Qu tragedias ha causado el desarrollo de software con defectos? Qu tragedias ha causado el desarrollo de software con defectos? Qu es la Ingeniera de Requisitos (IR)? Qu es la Ingeniera de Requisitos (IR)? Cul es la importancia de la Ingeniera de Requisitos? Cul es la importancia de la Ingeniera de Requisitos? A quienes dirigirnos para recolectar requisitos? A quienes dirigirnos para recolectar requisitos? Qu son los requisitos? Qu son los requisitos? Cul es la clasificacin de los requisitos? Cul es la clasificacin de los requisitos? Describa las etapas del proceso de la IR Describa las etapas del proceso de la IR Investigue las tcnicas de especificacin de requisitos Investigue las tcnicas de especificacin de requisitos Cmo se clasifican los requisitos? Cmo se clasifican los requisitos? Describa el estndar IEEE 830 -1998 para documentar requisitos. Describa el estndar IEEE 830 -1998 para documentar requisitos.
44
2. DESCRIPCIN DE LAS ACTIVIDADES DEL PROCESO DE LA IR
A. OBTENCIN DE REQUISITOS. Este proceso tambin es considerado como: elicitacin, educcin, formulacin, identificacin o extraccin. La especificacin de requisitos se refiere a la captura y descubrimiento de los requisitos. Es una actividad ms humana que tcnica. Se identifica a los interesados (clientes y usuarios) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo.
A quin (es) se dirigen los requisitos? El proceso de obtencin 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 debern ser mucho ms especficas. Fuentes de los requerimientos Identificar los objetivos del proyecto y eventualmente realizar un estudio de viabilidad de los mismos. mbito de aplicacin o dominio de conocimiento del proyecto (permitir resolver conflictos entre actores) Identificar a todos los actores del proyecto para poder disear un sistema que recoja diferentes puntos de vista de manera consensuada y sea fcil de usar por todos ellos Identificar el entorno operacional para poder establecer las restricciones del proyecto y los costes. Entorno organizativo: identificacin de los condicionantes que la estructura, la cultura y la poltica interna de la organizacin puedan imponer o sobre-entender. Tcnicas de obtencin de los requerimientos Entrevistas con los actores (clientes y/o usuarios): cerradas / abiertas
45
Encuestas aplicando cuestionarios con preguntas concretas y respuestas cerradas / abiertas Escenarios. Los requisitos se sitan en el contexto de uso (casos de uso). Permiten contextualizar y preguntarse sobre Qu pasara si ... ? Cmo 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 travs de entrevistas individuales y aflorar puntos de vista contrapuestos. Es necesario gestionarlas correctamente para evitar conflictos o puntos de vista dominantes. Observacin de los sistemas actuales y medida de distintos parmetros de los mismos a travs de la inmersin 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, investigacin externa, jornadas profesionales, ferias Presentaciones comerciales, estudio de productos SW ya existentes.
B. ANLISIS DE REQUISITOS. Consiste en detectar y resolver conflictos entre requisitos. Se precisan los lmites del sistema y la interaccin con su entorno. Se trasladan los requisitos de usuario a requisitos del software (implementables). Se realizan tres tareas fundamentales: Clasificacin, Modelizacin y Negociacin.
Clasificacin de Requisitos. La clasificacin ms tpica de los requisitos es la que se presenta a continuacin:

Capacidades FUNCIONALES Restricciones
TIPOS DE REQUISITOS
NO FUNCIONALES
Restricciones
DE INTERFAZ
Sin embargo, algunos autores presentan otras formas de clasificacin de requisitos: Por prioridades Por coste de implementacin Por niveles (alto nivel, bajo nivel) Segn su volatilidad/estabilidad
46
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 ambigedad, 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. Caractersticas de usabilidad. Facilidad de mantenimiento. etc. Requitos de Interfaz. Definen las interacciones del sistema con su entorno. Interfaces de Usuarios o con otros sistemas. Modelizacin de Requisitos: La meta es entender mejor el problema, ms que iniciar el diseo de la solucin (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 notacin Tradicionalmente se entenda que el anlisis se reduca a modelizar (DFDs, modelos de objetos, etc), pero el anlisis de requisitos NO es exclusivamente un proceso de modelizacin. Por otro lado, no existe la mejor forma de modelar requisitos. En realidad, no hay evidencia emprica que demuestre, en general, la superioridad de unas notaciones de modelizacin frente a otras. Negociacin de Requisitos: Tambin denominada resolucin 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 prestacin de servicios, debe dejarse traza del por qu de la decisin tomada.
47
Podra incorporarse como parte de la Validacin de requerimientos. La mejor tcnica es la de las reuniones con los involucrados , previamente preparadas y documentadas para conocer el impacto de los conflictos y sus posibles soluciones. Otras tcnicas son: correo electrnico, boletines electrnicos, bases de datos compartidas tipo Lotus Notes con la documentacin de los requerimientos y sus conflictos. No estn excesivamente probadas y su utilidad puede ser dudosa si se genera una actitud de desinters. C. ESPECIFICACIN DE REQUISITOS. Para la especificacin de los requisitos o documentacin es necesario utilizar algn estndar, as encontramos a los siguientes: IEEE Std. 830-1998 PSS-05 de la Agencia Espacial Europea (ESA)
El estndar IEEE std. 830 1998 contiene la siguiente estructura: 1. Introduccin 2.1. Propsito 2.2. Alcance 2.3. Definiciones 2.4. Referencias 2.5. Visin General 3. Descripcin General 3.1. Perspectiva del producto 3.2. Funciones del producto 3.3. Caractersticas del usuario 3.4. Restricciones 3.5. Suposiciones 4. Requisitos Especficos 5. Apndices 6. ndice
Fuente: (http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor-html/index.html )
Los aspectos bsicos que una descripcin de requisitos debe cubrir son: Funcionalidad. Descripcin de lo que el software debe hacer. Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de hardware, o con otros sistemas (software y hardware). Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta, tiempos de recuperacin, tiempos de determinadas funciones. Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad, etc. Restricciones de diseo en la implementacin . Indicacin de las restricciones que puedan afectar por la necesidad de sometimiento a estndares, lenguajes,
48
polticas de integridad de bases de datos, lmites 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 precisin necesario. Completo, que no falten requisitos y que todas las respuestas del sistema a entradas tanto vlidas como invlidas estn especificadas. Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de nivel superior y con una terminologa nica. Verificable, que pueda comprobarse que el sistema final cumple los requisitos mediante un proceso finito y de coste razonable. Fcilmente modificable, organizada, con los requisitos identificados y con control de configuracin. Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrs y hacia delante. Priorizada, indicando la importancia de los requisitos. Anotada con estabilidad, para conocer posibles fuentes de cambios durante el desarrollo. Independiente del diseo y la implementacin, para evitar complejidades innecesarias y no limitar a los diseadores.
D. VALIDACIN DE REQUISITOS La validacin de requisitos consiste en descubrir problemas en el documento de requisitos antes de comprometer recursos en la implementacin del software. El documento debe revisarse para: Descubrir omisiones Conflictos Ambigedades Comprobar la calidad del documento y su grado de de adhesin a estndares Para revisar el documento de los requisitos es aconsejable conformar una comisin de revisin que incluya desarrolladores y usuarios. Esta comisin debe encargarse de: Buscar problemas en el documento de los ERS. Convocar a reuniones y establecer acuerdos. Algunas tcnicas para identificar problemas habituales: Listas de comprobacin checklists Prototipado. Permite descubrir con rapidez si el usuario se encuentra satisfecho o no con los requisitos Validacin de Modelos. Cuando los requisitos son expresado en base a modelos como: Casos de Uso, DFDs u otros.
49
Validacin de su testeabilidad. El equipo de pruebas debe revisar los requisitos.
E. GESTIN La gestin de requisitos debe realizarse durante todo el proceso de desarrollo del software. Es parte de la Gestin de la Configuracin del Software y se realizan algunas actividades: Definir procedimientos de cambios: definen los pasos y los anlisis que se realizarn antes de aceptar los cambios propuestos. Cambiar los atributos de los requisitos afectados. Mantener la trazabilidad: hacia atrs, hacia delante y entre requisitos. Control de versiones del documento de requisitos
TAREAS DEL CRDITO 3

1. Para desarrollar habilidades en la aplicacin del proceso de Ingeniera de Requisitos, verifica si los siguientes requisitos estn bien redactados, disctelo con tu profesor gua. Identifica en cada requisito los siguientes elementos: proceso a automatizar, archivo(s) lgico(s), los datos a utilizar, y las restricciones u observaciones. Gestin de Doctores Req (11) Registrar nuevo doctor, con los siguientes datos: cdigo del doctor, nombre del doctor, apellido del doctor, especialidad del doctor, estado del doctor, telfono del doctor, direccin del doctor. Req (12) Se permitir buscar por cdigo 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 cdigo 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 eliminacin lgica por medio del (Req12). Este proceso no implica una eliminacin definitiva de la base de datos. 2. Como actividad del crdito 3 debe realizar el SEGUNDO AVANCE DE SU PROYECTO FINAL. Revisa las orientaciones que se indican a continuacin.
50
Como actividad laboral de avance del proyecto final, en este tema se deber elaborar el documento de ESPECIFICACIN DE REQUISITOS DEL SOFTWARE (ERS) . Para lo cual es necesario realizar las siguientes tareas: Recolectar los requisitos del software a desarrollar, es necesario ejecutar tcnicas de recoleccin de informacin como entrevistas, encuestas, observacin, revisin 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 estndar IEEE 830-1998 Refinar (depurar) el documento de requisitos realizando reuniones formales con los usuarios. Gestionar los requisitos.
El ESPECIFICACIN DE REQUISITOS DEL SOFTWARE (ERS) debe contener el siguiente formato: Cartula (Primera pgina): Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso ESPECIFICACIN DE REQUISITOS DEL SOFTWARE (ERS)) Versin del Documento
A todas las pginas del documento colocar: Encabezado de pgina: Cdigo y nombre del documento, nmero de pgina, versin, Nombre del Proyecto Pie de pgina: Autor y fecha de creacin
1. Introduccin (Hacer un breve resumen del documento) 1.1. Propsito (del documento) 1.2. mbito del Sitema 1.3. Definiciones, acrnimos y abreviaturas 1.4. Referencias 1.5. Visin general 2. Descripcin General 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Caractersticas de los usuarios 2.4. Restricciones 2.5. Dependencias
51
3. Requisitos Especficos 3.1. Requisitos Funcionales 3.2. Requisitos de interfaces externos 3.2.1. Interfaces de Usuario 3.2.2. Interfaces Hardware 3.2.3. Interfaces Software 3.2.4. Interfaces de Comunicacin 3.3. Requisitos de Rendimiento 3.4. Requisitos de desarrollo 3.5. Requisitos Tecnolgicos 3.6. Atributos 3.7. Seguridad 4. Apndices (Anexos) 4.1. Entrada de datos 4.2. Salida de datos
AUTOEVALUACIN AUTOEVALUACINTEMA TEMAIIII
1. Complete: a. b. c. Requisito: .................................................................................................................... .................................................................................................................... IEEE 830........................................................... .................................................................................................................... .................................................................................................................... Cul es la parte ms difcil en la construccin de un software? .................................................................................................................... .................................................................................................................... .................................................................................................................... Tcnicas usadas en el proceso de validacin de requisitos: .................................................................................................................... .................................................................................................................... .................................................................................................................... Cmo se comportan los errores en los requisitos en las dems fases del proceso de ingeniera del software?: .. .. .. .................................................................................................................... .................................................................................................................... Cul es el mbito de los requistos?: .................................................................................................................... .................................................................................................................... ....................................................................................................................
d.
e.
f.
52
2. Elabore un cuadro resumen de las tcnicas para recolectar requisitos del software
3. Qu es la Ingeniera de Requisitos
4. Realice un ensayo sobre los procesos de la Ingeniera de Requisitos

53
GESTIN DE PROYECTOS DE SOFTWARE
SISTEMA DE HABILIDADES CONCEPTOS SOBRE GESTIN DE Gestionar el PROYECTOS DE SOFTWARE personal, el proceso y el El espectro de gestin, el problema durante el personal, el producto, el proceso, el proyecto de software proyecto PLANIFICACIN DEL PROYECTO DE Identificar y SOFTWARE generar equipos de Objetivos de la planificacin del software, estimaciones proyecto fiables del esfuerzo, mbito del software, recursos costes y duracin del Estimacin del proyecto de proyecto software o Tcnicas de puntos de funcin o Modelos empricos de estimacin La decisin desarrollar-comprar PLANIFICACIN TEMPORAL Y Desarrollar la SEGUIMIENTO DEL PROYECTO planificacin temporal de Conceptos bsicos, la relacin proyecto entre las personas y el esfuerzo Definicin de un conjunto de tareas para el proyecto de software. Seleccin de las tareas de Ing. SW Refinamiento de las tareas principales Definir una red de tareas ANLISIS DE RIEGOS Identificar y Estrategias de riesgos utilizar las tcnicas para Riesgos del software la evaluacin de los Identificacin y proyeccin del riesgos que pueden tener riesgo impacto en el xito del Reduccin, supervisin y proyecto. gestin del riesgo Riesgos y peligros para la seguridad PLAN DE GARANTA DE CALIDAD Definir y Introduccin controlar la calidad de un Documentacin proyecto Revisiones y auditorias Gestin de Configuracin PLAN DE GESTIN DE Identificar y CONFIGURACIN realizar la forma de SISTEMA DE CONOCIMIENTOS
SISTEMA DE VALORES Responsabilidad Compaerismo Honestidad Responsabilidad Compaerismo Honestidad
Responsabilidad Compaerismo Honestidad
Responsabilidad Compaerismo Honestidad
Responsabilidad Compaerismo Honestidad Responsabilidad Compaerismo
57
Introduccin Actividades de GCS Programacin
gestionar los cambios durante el desarrollo de software y despus de entregar al cliente
Honestidad
58

En este tema se estudiar los conceptos clave que conducen a una gestin efectiva de proyectos de software. Comenzaremos con los conceptos bsicos de gestin de proyectos de software, se analizarn algunas tcnicas para la estimacin, elaboracin de un cronograma realista, revisin de algunas tcnicas de gestin que conducen a una efectiva supervisin, reduccin y gestin del riesgo, finalmente, se considerarn tcnicas para asegurar la calidad conforme un proyecto se lleva a cabo y se gestionan los cambios a lo largo de la vida de una aplicacin.
OBJETIVO
Gestionar el proyecto de software mediante planificacin, seguimiento y control del proceso de desarrollo de software y la realizacin de actividades de soporte como: anlisis de riesgos, configuracin del software y control de calidad que permita la construccin de un producto que satisfaga las necesidades del cliente.
59
ESQUEMA ESQUEMADEL DELTEMA TEMAIII III
60
ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAIII III

Para el estudio del Tema III necesitas revisar la siguiente bibliografa: Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005. Conceptos de Gestin de proyectos. Pgina 640 Mtricas de proceso y proyecto. Pgina 663 Estimacin para proyectos de SW. Pgina 690 Calendarizacin de proyectos de SW. Pgina 724 Gestin de riesgo. Pgina 747 Gestin de calidad. Pgina 767 Gestin del cambio. Pgina 796 Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005. Gestin del Proyecto de SW. Pginas: 37 - 52. Mtricas del SW. Pginas: 53 - 76. Planificacin del proyecto de SW. Pginas: 77 96 Anlisis de Riesgos. Pginas: 97- 110 Plan Temporal y seguimiento. Pginas: 111 - 130. Calidad del SW. Pginas. 131 - 150. Gestin de la Configuracin del Software. Pginas: 151- 164 Kendall & Kendall, Anlisis y Diseo de software. Estudio de Factibilidad: Pginas: 47- 53 Planificacin del proyecto: Pginas: 54-74 Calidad del Software: Pginas: 745-765
61
1. CONCEPTOS SOBRE GESTIN 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 gestin de proyectos involucra la planificacin, supervisin y control del personal, el proceso y los eventos que ocurren durante la ejecucin del proyecto desde un concepto preliminar hasta una implementacin operativa. Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres grandes etapas: Fase de planificacin. Se trata de establecer cmo el equipo de trabajo deber satisfacer las restricciones de prestaciones, planificacin temporal y coste. Una planificacin detallada da consistencia al proyecto y evita sorpresas que nunca son bien recibidas. Fase de ejecucin. Representa el conjunto de tareas y actividades que suponen la realizacin propiamente dicha del proyecto, la ejecucin de la obra de que se trate. Responde, ante todo, a las caractersticas tcnicas especficas de cada tipo de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestin. Cada tipo de proyecto responde en este punto a su tecnologa propia, que es generalmente bien conocida por los tcnicos 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 tambin muy importante no slo por representar la culminacin de la operacin sino por las dificultades que suele presentar en la prctica, alargndose excesivamente y provocando retrasos y costes imprevistos. A estas tres grandes etapas es conveniente aadir 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 bsicas para el desarrollo del proyecto: Fase de iniciacin. Definicin de los objetivos del proyecto y de los recursos necesarios para su ejecucin. Las caractersticas del proyecto implican la necesidad de una fase o etapa previa destinada a la preparacin 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 planificacin, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto.
62
Fase de control. Monitorizacin del trabajo realizado analizando cmo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye tambin 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 gestin. La gestin eficaz de proyectos de software se enfoca sobre las cuatro P: personal, producto, proceso y proyecto. El orden no es arbitrario.
PRODUCTO PRODUCTO
PROYECTO PROYECTO
PERSONAL PERSONAL
PROCESO PROCESO
EL PERSONAL. La formacin de personal de software motivado y altamente calificado se ha debatido desde los aos 60. De hecho, el factor humano es considerado como el ms importante en el proyecto, debido a que el desarrollo del software es un trabajo ms intelectual que fsico. En los modelos formales como el CMM (Modelo de Madurez de Capacidades), define en su proceso de gestin de personal, las siguientes reas: reclutamiento, seleccin, gestin del desempeo, entrenamiento, retribucin, desarrollo de la carrera, desarrollo de la organizacin y el trabajo, y desarrollo de la cultura de equipo.
M.M.C.G.P
Reclutamiento Gestin de rendimiento
Seleccin Desarrollo Diseo / organizacin
Entrenamiento Retribucin
Desarrollo cultural
Los participantes. Se pueden clasificar en 5 categoras: Gestores Superiores Gestores tcnicos del proyecto Profesionales Clientes Usuarios Finales
63
Los jefes de equipo. Los Jefes de equipo deben poseer ciertas capacidades, as, el modelo MOI considera las siguientes: Motivacin.- Habilidad para motivar con un <<tira y afloja>> Organizacin.- Moldear procesos existentes Ideas o innovacin.- Motivar al personal para crear y sentirse creativos El equipo de software La mejor estructura d equipo depende del estilo de gestin de una organizacin. Mantei, sugiere tres organigramas de equipos genricos.
No tiene jefe permanente Las decisiones se hacen por consensos La comunicacin entre los miembros es horizontal Tiene jefe definido, coordina tareas Jefes secundarios, para subtareas Comunicacin vertical El jefe se encarga de la solucin de problemas La comunicacin entre el jefe y los miembros del equipo es vertical.
DESCENTRALIZADO DEMOCRTICO
DESCENTRALIZADO CONTROLADO
CENTRALIZADO CONTROLADO
La gestin exitosa de proyectos, independientemente de la estructura organizativa, es slo tan buena como lo sean los individuos y lderes que gestionen las funciones bsicas (Kerzner, 1998) EL PRODUCTO. Antes de planear un proyecto se deberan establecer los objetivos y el mbito del producto, considerar soluciones alternativas e identificar las restricciones tcnicas y de gestin. Sin esta informacin es imposible definir estimaciones razonables del costo, valoraciones efectivas del riesgo, una divisin realista de las tareas del proyecto o un calendario del proyecto que ofrezca una indicacin 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 ingeniera del sistema o de la ingeniera del proceso de negocio y contina como primer paso en la ingeniera de requisitos del SW. EL PROCESO. Un proceso de software proporciona el marco de trabajo desde el PROCESO cual se puede establecer un plan detallado para el desarrollo del software. ACTIVIDAD 1 ACTIVIDAD n Generalmente est guiado por la metodologa (mtodo o ciclo de vida + tcnicas + soporte documental) que se TAREA 1 TAREA X TAREA 1 haya seleccionado para llevar a cabo el proyecto de software. El proceso se descompone en actividades y a su vez las actividades en tareas.
64
EL PROYECTO. Un proyecto es una accin en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo nico. En este trabajo, dadas unas especificaciones y dentro de unos lmites 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 gestin.
2. PLANIFICACIN DEL PROYECTO DE SOFTWARE.
El proceso de produccin 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 estndares especficos de calidad. Por lo tanto, las claves del xito en la gestin del desarrollo de software son: una adecuada gestin del proyecto de desarrollo de software y una adecuada gestin del proceso de software. El nmero de tareas identificables a realizar por un director de proyectos, dentro del rea de la gestin de proyectos son varias. Sin embargo, hay tres que son crticas y que deben ser desarrolladas correctamente si se desea que el proyecto termine bien. Estas tareas son: a. Estimacin de duracin, coste y esfuerzo necesarios para construir el producto. b. Planificacin de tareas a realizar, asignacin de personas, tiempos, etc. para construir el producto. c. Seguimiento, durante la realizacin 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 planificacin del Proyecto de Software, es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables. MBITO DEL SOFTWARE. Es la primera actividad que se lleva a cabo durante la planificacin del proyecto de Software. Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los lmites 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 estimacin y existen algunos elementos que se debe tomar en cuenta como es:
65
a. La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo. b. Viabilidad. Una vez identificada la informacin 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: Tcnico. Econmico Legal Operativo Anlisis costo/beneficio Estudio de viabilidad Tcnico. Consiste en identificar el recurso hardware, software, de comunicacin y recurso humano especializado. Se debe concluir indicando si es factible o no desarrollar tcnicamente el proyecto. Estudio de viabilidad Econmico. Determinar propuestas de costos de los recursos tcnicos, humanos y materiales tanto para el desarrollo como para la implantacin (puesta en produccin) del Sw. Adems, comprende anlisis de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado, es decir un anlisis costo/beneficio. Se debe concluir indicando si es econmicamente factible el desarrollo del proyecto. Anlisis coste/beneficio Costes: Personal Informtico Consultora 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 informtico para que el proceso resulte ms rpido 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 adaptacin (slo 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 ahorrara un 50% de tiempo de las 2 personas dedicadas a contabilidad si el sistema fuese automtico. Se considera que la vida del sistema es de 4 aos. La formacin 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.
Anlisis coste/beneficio del caso de estudio:

66
Estudio de viabilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema. Se debe indagar las disposiciones legales de la propia empresa o externos, que los desarrolladores deben considerar en la construccin 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, adems, contrariedades de los usuarios, posibles oponencias a la automatizacin del software. Se debe concluir indicando si es operativamente factible el desarrollo del proyecto. RECURSOS. La segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables. Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro caractersticas: Descripcin del recurso. Informes de disponibilidad. Fecha cronolgica en la que se requiere el recurso. Tiempo durante el que ser aplicado el recurso.
Recursos Humanos.
67
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempear cada profesional. Recursos o componentes de software reutilizables. Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software. Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin. El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se avanza con la planificacin: 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 Ingeniera 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 Ingeniera del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software. ESTIMACIN DEL PROYECTO DE SOFTWARE Al principio, el costo del software constitua un pequeo porcentaje del costo total de los sistemas basados en computadoras. Hoy en da el Software es el elemento ms caro de la mayora de los sistemas informticos. Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, 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 especificacin de requisitos.
68
Estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es mas un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes y de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software. Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software. La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin. Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles: Deje la estimacin para ms adelante (obviamente podemos realizar una estimacin al cien por cien fiable despus de haber terminado el proyecto). Base las estimaciones en proyectos similares ya terminados. Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
Desdichadamente la primera opcin, aunque atractiva no es prctica. La Segunda opcin 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 mtodos viables para la estimacin del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas como comprobacin de las otras. Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir y generar una estimacin de su tamao. Tamao del software. Puede estimarse utilizando: Una medida directa. LDC (Lneas de Cdigo fuente) Una medida indirecta. Puntos de Puncin (PF). Tcnicas de descomposicin: Descomposicin del problema Descomposicin del proceso Estimacin basada en el problema. Las Lneas de Cdigo LDC y los Puntos de Puncin PF son medidas utilizadas para la estimacin. Estimacin basada en el Proceso. Se basa la estimacin en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea.
69
Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso comienza en una delineacin 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 funcin y la actividad del proceso de software. Los Modelos Empricos de estimacin. Donde los datos que soportan la mayora de los modelos de estimacin obtienen una muestra limitada de proyectos. Por esta razn, el modelo de estimacin 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 clsico sobre economa de la Ingeniera del Software, introduce una jerarqua de modelos de estimacin 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 estimacin ms completo llamado COCOMO II, consta de una jerarqua de modelos de estimacin que tratan las siguientes reas: Modelo de composicin de aplicacin. Utilizado durante las primeras etapas de la ingeniera de software, donde el prototipado de las interfaces de usuario, la interfaz del sistema y del software, la evaluacin del rendimiento, la evaluacin de la madurez de la tecnologa son de suma importancia. Modelo de fase de diseo previo. Utilizado una vez que se han establecido los requisitos y la arquitectura bsica del software. Modelo de fase posterior a la arquitectura. Utilizado durante la construccin del software. Herramientas Automticas de Estimacin. Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales y todas requieren de una o ms clases de datos. A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la planificacin 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. Adems el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.
70
La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin. Ejemplo de software de estimacin: ESTICMACS PLANMACS COCOMOII CA-SUPERPROJECT TCNICA DE PUNTOS DE FUNCIN Esta tcnica permite medir el tamao (funcionalidad proporcionada por el usuario), por lo que es necesario contar con un buen documento de Especificacin de Requisitos del Software (ERS SRS). Es la base para la estimacin de costos, esfuerzo, personas y tiempo. En el caso de subsistemas diseados independientemente los Puntos de Funcin se calcularn para cada uno de ellos, y luego se sumarn. 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 diseado independientemente los dos subsistemas que proporcionan cada funcionalidad. Los objetivos de los Puntos de Funcin son: Medir lo que el usuario pide y lo que el usuario recibe. Medir independientemente de la tecnologa utilizada en la implantacin del sistema. Proporcionar una mtrica de tamao que d soporte al anlisis de la calidad y la productividad. Proporcionar un medio para la estimacin del software. Proporcionar un factor de normalizacin para la comparacin de distintos software. Adems de estos objetivos, el proceso de contabilizar los Puntos de Funcin debera ser: Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida. Conciso en sus resultados.
El anlisis de los Puntos de Funcin se desarrolla considerando cinco parmetros bsicos externos del Sistema: Entradas (EI, del ingls External Input). Salidas (EO, del ingls External Output). Consultas (EQ, del ingls External Query). Grupos de datos lgicos internos (ILF, del ingls Internal Logic File). Grupos de datos lgicos externos (EIF, del ingls External Interface File).
Con estos parmetros, se determinan los puntos de funcin sin ajustar.
71
A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobre la aplicacin y su entorno. Es decir las caractersticas 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 Lgicos Internos y Ficheros de Interfaces Externos. Ficheros Lgicos Internos (ILF) Un Fichero Lgico Interno es un grupo de datos lgicamente relacionados identificables por los usuarios o informacin de control mantenidos y utilizados dentro de los lmites de la aplicacin. Ejemplos de ILF son: Ficheros maestros Aplicaciones de Seguridad de Datos Datos de Auditora Actualizados por la aplicacin Mensajes de Error Actualizados por la aplicacin Ficheros Internos Lgicos mantenidos por ms de una aplicacin Ficheros Interfase Externos (EIF) Representan un grupo de datos relacionados lgicamente identificables por el usuario o informacin de control utilizada por la aplicacin de solo lectura, pero mantenida por otra aplicacin. Funciones de Transaccin Comprende tres tipos de funcin: Entradas externas (EI): mantiene datos almacenados internamente. Salidas externas (EO): datos de salida de la aplicacin. Consultas externas (EQ): Combinacin de una entrada (pregunta) y de una salida (respuesta). Entradas Externas (EI. External Input)
72
Las Entradas Externas son datos o informacin de control que se introducen en la aplicacin desde fuera de sus lmites. Comprende el mantenimiento de un Fichero Lgico Interno (ILF), es decir: altas, bajas y eliminaciones. Ejemplos de este tipo de funcin 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 informacin de control que sale de los lmites de la aplicacin. Esta salida debe ser considerada nica si tiene un formato nico o si el diseo lgico requiere un proceso lgico distinto de otras salidas del mismo formato. Toda salida ha de requerir un proceso de clculo de la informacin que se proporciona. Ejemplos Transferencia de datos a otras aplicaciones (vista lgica de un archivo fsico, vista lgica de 2 o ms archivos fsicos) Los grficos estadsticos y datos estadsticos en formato tabla Los generadores de informes No se deben contar como Salidas: Las ayudas Las distintas formas de invocar la misma salida lgica Los mensajes de error/confirmacin distintos a salidas externas Los informes Ad Hoc: Cuando el usuario dirige y es responsable de la creacin mediante la utilizacin de lenguajes como SQL de un nmero indefinido de informes, no se cuentan como salidas. Consultas Externas (EQ. External Query) Las consultas representan los requisitos de informacin a la aplicacin en una combinacin nica de entrada/salida que se obtiene de una bsqueda de datos, no actualiza un Fichero Lgico 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 diseo lgico requiere ediciones distintas a las de otras consultas. Se entiende por datos derivados aqullos que requieren un proceso distinto a la bsqueda directa, edicin o clasificacin de informacin de Ficheros Lgicos Internos o Ficheros Interfases Externos. Ejemplos: La bsqueda inmediata de datos. Las consultas no explcitas. Las pantallas de modificacin/borrado que proporcionan capacidad de bsqueda de datos Pantallas de conexin. Las pantallas de logon que proporcionaran seguridad se cuentan como una consulta
73
Los mens con consultas implcitas: Las pantallas de men que proporcionan una seleccin de pantallas y entradas para la bsqueda 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 aplicacin 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 formacin de usuarios debera contarse como un sistema distinto.
No se consideran como Consultas: Los mensajes de Error/Confirmacin. La utilizacin de distintos mtodos de llamada a la misma consulta. Valoracin de la Complejidad Para cada uno de los parmetros externos se ha de indicar su complejidad como Baja, Media o Alta. Para las entradas, salidas y consultas, se puede evaluar su complejidad en funcin del nmero de campos que contengan y del nmero de ficheros a los que hagan referencia. Para los ficheros, por el contrario, su complejidad vendr dada en funcin del nmero de registros y de campos que tengan. Valoracin de la complejidad de los tipos de funcin datos A cada ILF y EIF identificado se le asigna una complejidad funcional que es funcin del nmero de tipos de elementos datos (DETs) y el nmero de tipos de elementos registros (RETs) de los que estn compuestos, y que vienen expresada mediante las tablas de contribucin y complejidad. Elementos datos (DETs). Un tipo de elemento dato es un campo nico y no recursivo sobre un tipo de funcin datos y que es reconocible por el usuario. Normalmente se corresponden con los atributos de las entidades lgicas 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 funcin datos. Los subgrupos son de dos tipos; opcionales y mandatorios. Los grupos opcionales son aquellos que el usuario tiene la opcin de incluir o no mediante un proceso elemental que aada o cree una instancia dentro un tipo de funcin datos. Los grupos mandatorios son aquellos en los que el usuario debe incluir cuando se crea o aade una instancia.
RET DET 1 a 19 1 2 a 5 6 ms Baja Baja o Media 20 a 50 Baja Media Alta 51 o ms Media Alta Alta
74
Valoracin de la complejidad de los tipos de funcin transaccin Para este tipo de valoracin, adems de los DETs, se requiere del nmero de tipos fichero referenciados (FTRs). Valoracin de la complejidad de las entradas externas EI A cada El se le asigna una complejidad funcional que es funcin del nmero de tipos de elementos datos (DETs) que procese el procedimiento elemental, y el nmero de tipos ficheros referenciados (FTRs)) a los que acceda tal proceso. Viene expresada mediante las tablas de contribucin y complejidad. FTR 0 a 1 2 3 o m s DET 1 a 4 B a ja B a ja M ed ia
5 a 15 B aja M e d ia A lta
16 o m s M e d ia A lta A lta
Valoracin de la complejidad de las salidas externas EO A cada EO identificada, asignarle una complejidad funcional basada en el nmero de tipos ficheros referenciados (FTRs) por el proceso elemental de dicha EO y el nmero de tipos elemento de datos (DETs) que la forman. Viene expresada mediante las tablas de contribucin y complejidad.
FTR 0 a 1 2 a 3 4 o ms D ET 1 a 5 B aj a B aj a M e dia 6 a 19 B aj a M e dia A lt a 20 o ms M e di a A lta A lta
Valoracin de la complejidad de las consultas externas EQ A cada EQ que ha sido identificada, asignarle una complejidad funcional basada en el nmero 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 ms alta entre la de la entrada y la de la salida, y traducirla a nmero de puntos de funcin sin ajustar segn las tablas de contribucin y complejidad. A continuacin se llena los parmetros determinados de complejidad de ILF, EIF, EI, EO, EQ, en la tabla que se presenta a continuacin. Se obtendr el total de puntos de funcin sin ajustar. PARAMETRO COMPLEJIDAD NUMERO X PESO TOTAL
75
ILF
EIF
EI
EO
EQ
ALTA MEDIA BAJA ALTA MEDIA BAJA ALTA MEDIA BAJA ALTA MEDIA BAJA ALTA MEDIA BAJA
X X X X X X X X X X X X X X X
15 10 7 10 7 5 6 4 3 7 5 4 6 4 3
Utilizando la herramienta CASE COCOMO II se calcula los puntos de funcin y las LDC:
76
2
1. 2. 3. 4. 5.
Valor costo/mes que debe ingresarse Tamao del software en LDC Esfuerzo hombre/mes Costo total del software # de personas
DECISIN DE DESARROLLAR-COMPRAR.
TAREAS CRDITO 4 En muchas reas de aplicacin del software,DEL a menudo es ms rentable adquirir el software de computadora que desarrollarlo. En una empresa antes de desarrollar adquirir Realiza las siguientes actividades con el propsito de desarrollar habilidades en el o proceso de un Realiza las siguientes actividades condiferentes el propsito de desarrollar habilidades en el proceso de software, recomienda analizar las posibilidades: gestin delse proyecto de software:
gestin del proyecto de software:
TAREAS DEL CRDITO 4
Construir ellos software desde el inicio Conceptualice siguientes trminos: Conceptualice los siguientes trminos: Gestin Reutilizar los componentes de otro SW para construir el nuevo Gestin Estimacin Estimacin Comprar o adquirir un software disponible y adaptarlo a las necesidades Proyecto Proyecto Contratar el desarrollo del software a un vendedor externo. Proyecto de software Proyecto de software COCOMO Subcontratacin (outsourcing). Las actividades de ingeniera de software se contratan a COCOMO Mediante un grfico explique las etapas de la gestin de proyectos un tercero,un quien hace el trabajo a bajo costoasegurando una alta calidad. El trabajo de Mediante grfico explique las etapas de la gestin de proyectos Realice un ensayo de mnimo 150 palabras sobre los elementos para desarrollar una software dentro de la compaa se reduce una actividad para de gestin de contratos. Realice llevado un ensayo de mnimo 150 palabras sobrealos elementos desarrollar una gestin eficaz de un proyecto de software. gestin eficaz de un proyecto de software. Cmo organizar un equipo para el desarrollo de software? Cmo organizar un equipo para el desarrollo de software? Cules son las tareas identificables a realizar por un director de proyectos, dentro del Cules son las tareas identificables a realizar por un director de proyectos, dentro del rea de la gestin de proyectos? rea de la gestin de proyectos? Cules son los objetivos de la planificacin del proyecto de software? Cules son los objetivos de la planificacin del proyecto de software? Qu es el mbito del software? Qu es el mbito del software? En que consiste el estudio de factibilidad? En que consiste el estudio de factibilidad? Describa el proceso de estimacin del software mediante la tcnica de los puntos de Describa el proceso de estimacin del software mediante la tcnica de los puntos de 77 UTSAM-Modalidad Semipresencial y a Distancia funcin funcin Realice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Realice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Planificacin General del proyecto de software incluido el proceso de Estimacin y la Planificacin General del proyecto de software incluido el proceso de Estimacin y la organizacin del equipo de trabajo. organizacin del equipo de trabajo.
3. PLANIFICACIN TEMPORAL Y SEGUIMIENTO DEL PROYECTO
La planificacin temporal y el seguimiento del proyecto tienen como objetivo primordial evitar los retrasos en las entregas del software. Causas de los retrasos: Fechas lmite de entrega poco realistas. Cambio de los requisitos que no se reflejan en la planificacin temporal Subestimacin honesta del esfuerzo y/o recursos. Riesgos predecibles e impredecibles no considerados. Dificultades tcnicas y humanas Falta de comunicacin entre la plantilla. Falta de reconocimiento del retraso en un proyecto. Falta de medidas para corregir el problema.
Las fechas lmite poco realistas son bastante frecuente en el desarrollo de software, jams 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. Solucin:
78
Realizar una estimacin detallada (productividad>25%). Utilizar un modelo incremental que implemente la funcionalidad crtica mnima para la fecha lmite impuesto. Reunirse con los clientes y explicar la situacin.
Cmo se retrasan las planificaciones temporales en los proyectos? diariamente [Fred Brooks] Cmo se cumplen las planificaciones temporales en los proyectos? diariamente [Antonio Navarro] Planificacin temporal Es la culminacin de una actividad de planificacin, componente primordial de la direccin de proyectos de software. Cuando se combinan mtodos de estimacin y anlisis de riesgos, la planificacin temporal se convierte en un mapa de carreteras a seguir por el gestor de proyectos. La planificacin temporal empieza con la descomposicin del proceso. Las caractersticas 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 ingeniera, sus dependencias con otras tareas y sus duraciones previstas. La red de tareas ( PERT) se usa para calcular el camino crtico del proyecto, un grfico de tiempo e informacin diversa del proyecto ( GANTT). El gestor del proyecto puede seguir y controlar todos los procesos de software usando la planificacin temporal como directriz. Construccin 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 ms habitual CC (de Comienzo a Comienzo) FF (de Fin a Fin) CF (de Comienzo a Fin) suele ser problemtica
Ejemplo:
79
Diseo Diseo Web Web Anlisis Anlisis Diseo Diseo Admin Admin Desarrollo Desarrollo Admin Admin Desarrollo Desarrollo Web Web Integracin Integracin ImplanImplantacin tacin
Asignacin de recursos y personas a las tareas
Optimizacin. Conceptos clave para la optimizacin del proyecto: Paso adelante Paso atrs Ruta crtica Reasignacin de recursos Paso adelante Estimar la fecha ms temprana para comenzar y terminar cada tarea Comenzando por la fecha de inicio del proyecto Estima la fecha de fin ms optimista
80
Paso atrs 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 lmite para comenzar el proyecto
Demora total Diferencia entre las fechas calculadas con paso adelante y paso atrs para cada tarea Retraso mximo 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.
81
Demora permisible. Tiempo que puede retrasarse una tarea sin afectar a la agenda del proyecto
Algunos programas como MS Project pueden hacer los clculos de forma
82
Ruta crtica. Es la ruta ms larga en el plan del proyecto, y delimita la fecha de entrega ms temprana posible
Actividades crticas. Actividades que estn en la ruta crtica y que no tienen demora permisible. Sus retrasos afectan al proyecto.
Optimizacin de agenda 1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crtica 2.- Revisar la asignacin de personas
3.- Modificar la asignacin de recursos 4.- Redistribuir a las personas Recomendaciones Duplicar la asignacin 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 comn
83
SEGUIMIENTO DE LA PLANIFICACIN El seguimiento es un factor clave en la planificacin temporal. Hay distintas formas de implementarlo: Realizando reuniones peridicas. 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 anlisis del valor ganado. La comparacin de las fechas reales y de inicio puede hacerse: Mediante tablas. Utilizando diagramas Gantt de seguimiento.
GE S T I N
R I E S G O S D E
4. GESTIN DE RIESGOS
IDENTIFICACIN
ANLISIS
TRATAMIENTO
Plan de gestin de riesgos IEEE Std P1540-2001
El riesgo. Se halla de forma implcita asociado a toda actividad:

84
Todo suceso se ve marcado por las acciones del pasado, Se puede, por tanto, actuar ahora para crear oportunidades en el futuro? El riesgo acompaa a todo cambio El riesgo implica eleccin e incertidumbre.
Estrategias reactivas. Consiste en tomar acciones una vez ocurrido el riesgo. Los mtodos que se pueden aplicar comprenden: la evaluacin 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 prevencin de los riesgos. Como mtodo de prevencin se pueden ejecutar las siguientes actividades: evaluacin previa y sistemtica de riesgos, evaluacin de consecuencias, plan de evitacin y minimalizacin de consecuencias, plan de contingencias. Algunas posibles consecuencias son la evasin del riesgo, menor tiempo de reaccin, justificacin frente a los superiores. Riesgo del software. Implica dos caractersticas: Incertidumbre (probabilidad de que ocurra) y prdida, si el riesgo se convierte en realidad. Categoras de los riesgos: Riesgos del proyecto: implica incremento en costes y desbordamiento organizativo Riesgos tcnicos Riesgos del negocio: De mercado De estrategia De ventas De gestin De presupuesto IDENTIFICACIN DE RIESGOS. La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan de proyecto (estimaciones, planificacin temporal, carga de recursos, etc.). Existen dos tipos de riesgos para cada categora presentada anteriormente: Genricos: Son comunes a todos los proyectos Especficos: Implican un conocimiento profundo del proyecto Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de riesgo basado en las siguientes subcategoras: Relacionados con el tamao del producto Con el impacto en la organizacin Con el tipo de cliente Con la definicin del proceso de produccin Con el entorno de desarrollo Con la tecnologa Con la experiencia y tamao del equipo
85
Componentes del riesgo. Los componentes de riesgo se definen de la siguiente manera: Rendimiento Coste Mantenibilidad Planificacin El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categoras de impacto: despreciable, marginal, crtico y catastrfico. ESTIMACIN DE RIESGOS. Denominado tambin proyeccin 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 proyeccin 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 proyeccin del riesgo de manera que no haya confusin. Creacin de una tabla de riesgos:
Ordenacin y filtrado Ordenacin 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: cun serio y cunto del proyecto se ve afectado
86
Temporalizacin de los efectos, cundo y por cunto tiempo
Cundo desistir y finalizar el proyecto Se debe definir un punto de referencia Se debe marcar la relacin entre cada factor de riesgo enumerado y el punto de referencia Definir el rea de incertidumbre, donde ser tan vlido continuar como interrumpir el trabajo Predecir cmo la combinacin de riesgos afectar a los niveles de referencia Gestin, Monitorizacin y Mitigacin 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 Evitacin del riesgo Definir las estrategias necesarias para evitar que el riesgo no se produzca Tomar las medidas encaminadas para que, an cuando se produzca, se minimecen sus efectos Monitorizacin del riesgo Definir los indicadores que influyen en la probabilidad de que el riesgo se produzca Monitorizar peridicamente dichos factores Monitorizar la efectividad real de las acciones encaminadas a evitar el riesgo Gestin del riesgo y plan de contingencia Se asume que la evitacin y la monitorizacin 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 fsicos. 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 validacin de calidad del producto PLAN RMMM
87
Introduccin mbito y propsito del documento Descripcin de los riesgos principales Responsabilidades Gestores Personal tcnico Tabla de evaluacin de riesgos Descripcin de todos los riesgos considerados Factores que influyen en la probabilidad e impacto
RMMM Riesgo X Evitacin Estrategia general Pasos para mitigar el riesgo Monitorizacin Factores a monitorizar Modo de monitorizacin Gestin Plan de contingencias Consideraciones especiales Planificacin

Realiza las siguientes actividades con el propsito de desarrollar habilidades en el proceso de Realiza las siguientes actividades con el propsito de desarrollar habilidades en el proceso de gestin del proyecto de software: gestin del proyecto de software:
Conceptualice los siguientes trminos: Conceptualice los siguientes trminos: Planificacin temporal Planificacin temporal GANTT GANTT Riesgo Riesgo Cul es el objetivo de la planificacin temporal y el seguimiento del proyecto? Cul es el objetivo de la planificacin temporal y el seguimiento del proyecto? Describa algunas causas por las que se retrasa un proyecto. Describa algunas causas por las que se retrasa un proyecto. Cmo se retrasan las planificaciones temporales en los proyectos? Cmo se retrasan las planificaciones temporales en los proyectos? Describa los tipos de dependencias entre tareas Describa los tipos de dependencias entre tareas Qu es una ruta crtica? Qu es una ruta crtica? En qu consiste el seguimiento de la planificacin? En qu consiste el seguimiento de la planificacin? Elabore un resumen mediante un organizador grfico de la Gestin de Riesgos Elabore un resumen mediante un organizador grfico de la Gestin de Riesgos Realice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Realice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la Planificacin General del proyecto de software incluido el proceso de Estimacin y la Planificacin General del proyecto de software incluido el proceso de Estimacin y la organizacin del equipo de trabajo. organizacin del equipo de trabajo.
5. GESTIN DE LA CALIDAD DEL SOFTWARE
Conceptos (ISO 8402) Calidad: Conjunto de propiedades y caractersticas de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explcitas o implcitas Control de calidad: Conjunto de tcnicas y actividades de carcter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio.
88
Garanta de calidad: Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad. Gestin de la calidad: Aspecto de la funcin de gestin que determina y aplica la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la calidad. La gestin de la calidad es responsabilidad de todos los niveles ejecutivos, pero debe estar guiada por la alta direccin. Su realizacin involucra a todos los miembros de la organizacin. En la gestin de la calidad, se tienen en cuenta tambin criterios de rentabilidad. Sistema de gestin de la calidad (QS): Conjunto de la estructura de la organizacin, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a trmino la gestin de calidad. El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad. El QS de una organizacin est fundamentalmente previsto para satisfacer las necesidades internas de la organizacin. Es ms amplio que los requerimientos de un cliente concreto que nicamente valor el QS que le interesa (directamente). Para finalidades contractuales o vinculantes en la valoracin de la calidad, se puede exigir que se ponga de manifiesto la realizacin 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 explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos 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): Caractersticas operativas Capacidad de soportar los cambios Adaptabilidad a nuevos entornos Satisfaccin del usuario PRODUCTO SATISFACTORIO + BUENA CALIDAD + ENTREGA EN PRESUPUESTO + ENTREGA EN TIEMPO ESTABLECIDO
SATISFACCIN DEL USUARIO =
89
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 medicin Proceso manual, automtico o semiautomtico Aseguramiento de la calidad de software (SQA) SQA engloba: Un enfoque de gestin de calidad Tecnologa de Ingeniera de Software efectiva Revisiones tcnicas formales (RTF) que se aplican durante el proceso del software Una estrategia de prueba multiescalada Un control de la documentacin del software y de los cambios realizados Un procedimiento que asegure un ajuste a los estndares de desarrollo de software Mecanismos de medicin y de generacin de informes Calidad del proceso y del producto DEL PROCESO Atributos de tcnicas, herramientas, personal, organizacin, facilidades DEL PRODUCTO Atributos de documentacin de desarrollo y mantenimiento, cdigo, pruebas Productividad y calidad PRODUCTIVIDAD: LDC/mes-persona INCREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD Mejor calidad, menor trabajo (+/- 50% de ahorro) Disminuyen las pruebas Localizacin temprana de errores a menor costo DECREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD Mejor calidad requiere inversin que se recupera en la entrega La revisin de los productos de desarrollo mejora la calidad pero disminuye la productividad Las tcnicas de calidad insisten en detalles que pueden constituirse en obstculos para el trabajo
PLAN DE GARANTA DE LA CALIDAD Introduccin Propsito Definiciones, acrnimos y abreviaturas Referencias Especificaciones de gestin Organizacin Responsables Grupo de garanta de la calidad del software Documentacin Revisin de la gestin
90
Revisin de los requisitos del software Revisin de diseo Revisin del producto Revisin de operacin. Gestin de configuracin Gestin de problemas y acciones correctivas
6. GESTIN DE CONFIGURACIN 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 ingeniera del software. Las actividades de GCS sirven para: 1. 2. 3. 4. 5. 6. Identificar el cambio. Controlar el cambio. Estado. Auditora y revisin. Garantizar que el cambio se implementa correctamente. Informar del cambio a todos aquellos que se vean afectados.
Elementos de Configuracin del software (ECS) Al aplicarse el proceso de ingeniera del software se genera una informacin que se puede dividir en tres clases: 1. Programas de ordenador (ejecutables y cdigo fuente). 2. Documentos descriptivos de las aplicaciones (tanto tcnicos como de usuario). 3. Datos (datos internos del programa o externos a l). Todos los elementos que componen la fuente de informacin producida como resultado del proceso de ingeniera se conocen como ELEMENTOS DE CONFIGURACIN DEL SOFTWARE. Lneas base En el contexto de la ingeniera del software, definimos una lnea base como un punto de referencia en el desarrollo del software que queda marcado por la revisin, evaluacin y aprobacin de unos elementos software relacionados. Las tareas de ingeniera del software producen una o ms ECS. Una vez que un ECS se ha revisado y aprobado, se coloca en una base de datos del proyecto (biblioteca del proyecto o depsito de software), se convierten en lnea base.
91
Cuando un miembro del equipo de ingeniera del software quiere hacer modificaciones en un ECS de lnea 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 gestin de configuracin del software. Versin Una versin es una instancia de un elemento de configuracin. El trmino se utiliza indicar un elemento de configuracin que tiene un conjunto de caractersticas funcionales. Revisin Se define revisin como una versin que se construye sobre otra versin anterior. Variante Es una versin alternativa a otra versin. Las variantes permiten a un elemento de configuracin satisfacer elementos en conflicto. Una variante en una nueva versin de un elemento que ser aadida sin reemplazar a la versin anterior. Proceso de GCS El proceso de GCS se divide en 5 tareas: Identificacin Se puede tener dos tipos de objetos: objetos bsicos y objetos compuestos. Un objeto bsico es una unidad de texto creado por un ingeniero del software durante el anlisis, diseo, codificacin o pruebas. Un objeto compuesto es un grupo de objetos bsicos o de otros compuestos. Cada objeto tiene una coleccin de atributos que le identifican unvocamente. Control de versiones Identificacin. Control de versiones. Control de cambios. Auditorias de configuracin. Generacin de informes.
92
El control de versiones est formado por procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creadas durante el proceso de ingeniera del software. Para representar las diferentes versiones se puede utilizar un grafo de evolucin 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.
Se reconoce la necesidad del cambio El usuario suscribe la peticin del cambio El desarrollador la evala Se genera un informe de cambios La autoridad de control de cambios decide La peticin queda pendiente de actuacin, se genera la OCI (orden de cambio de ingeniera) Asignacin personalizada los objetos de configuracin Dar de baja objetos (elementos) de configuracin Realizacin del cambio Revisin de cambio (auditora) Los elementos de configuracin que han cambiado son dados de alta Establecimiento de una lnea base para la prueba Realizacin de actividades de garanta de calidad y de prueba Promocin de los cambios para ser incluidos en la siguiente versin (revisin) Reconstruccin de la versin adecuada del software Revisin (auditora) de los cambios en todos los elementos de configuracin. Cambios incluidos en la nueva versin Distribucin de la nueva versin Peticin de cambio denegada Informacin al usuario
Proceso de Control de Cambios Control de acceso y de sincronizacin
93
Objeto de configuracin (versin modificada) Inf. de auditora
Alta
Desbloqueo
Objeto de configuracin (versin de lnea base)
Ingeniero de software
Control de acceso
Info. de pertenencia
Base de datos del proyecto
Objeto de configuracin (versin extrada)
Bloqueo Objeto de configuracin
Baja
(versin de lnea base)
Auditora de configuracin La auditora 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 revisin tcnica formal para evaluar la correccin tcnica? 3. Se ha aplicado los estndares de ingeniera 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 configuracin? 5. Se han seguido procedimientos del GCS para sealar el cambio, registrarlo y divulgarlo? 6. Se han actualizado adecuadamente todos los ECS relacionados? Informes de Estado De la generacin de informes de estado de la configuracin (contabilidad de estado) se encarga la gestin de configuracin del software, la cual responde a las siguientes preguntas: 1. Qu sucedi? 2. Quin fue el autor? 3. En qu fecha ocurri? 4. Cuntos elementos se vieron afectados? Plan de Gestin de la Configuracin Introduccin Propsito del plan Alcance Definiciones y acrnimos Referencias Especificaciones de gestin Organizacin Responsabilidades Actividades de gestin de la configuracin
94
Jerarqua preliminar del producto Seleccin de los elementos de configuracin Esquema de identificacin de los ecs Esquema de identificacin de versiones y revisiones Definicin de relaciones Relacin de equivalencia Relacin de composicin Definicin y establecimiento de lneas base Definicin y establecimiento de bibliotecas de software Control de cambios Anexos Anexo 1: solicitud de cambio Anexo 2: certificacin del cambio Anexo 3: contabilidad del estado de la configuracin

Realiza las siguientes actividades con el propsito de desarrollar habilidades en el proceso de Realiza las siguientes actividades con el propsito de desarrollar habilidades en el proceso de gestin del proyecto de software: gestin del proyecto de software:
Conceptualice los siguientes trminos: Conceptualice los siguientes trminos: Calidad Calidad Control de calidad Control de calidad Garanta de calidad Garanta de calidad Gestin de la calidad Gestin de la calidad Sistema de gestin de la calidad Sistema de gestin de la calidad Calidad del software Calidad del software Satisfaccin del software Satisfaccin del software ECS ECS Qu actividades comprende el aseguramiento de la calidad de software? Qu actividades comprende el aseguramiento de la calidad de software? Enumere las actividades de la gestin de la configuracin del software Enumere las actividades de la gestin de la configuracin del software Elabore un resumen mediante un organizador grfico de calidad y gestin de la Elabore un resumen mediante un organizador grfico de calidad y gestin de la configuracin del software configuracin del software Realice el CUARTO AVANCE DE SU PROYECTO FINAL que involucra el Plan de Realice el CUARTO AVANCE DE SU PROYECTO FINAL que involucra el Plan de Calidad del Software y el Plan de la Gestin de Calidad del Software. Calidad del Software y el Plan de la Gestin de Calidad del Software.
AUTOEVALUACIN AUTOEVALUACINTEMA TEMAIII III

95
1. a.
Complete:
Gestin: .................................................................................................................... .................................................................................................................... b. Personas .................................................................................................................... .................................................................................................................... .................................................................................................................... .................................................................................................................... .................................................................................................................... c. Calidad .................................................................................................................... .................................................................................................................... .................................................................................................................... d. Riesgo: .................................................................................................................... .................................................................................................................... .................................................................................................................... e. Cronograma: .. .. .. .................................................................................................................... .................................................................................................................... f. Qu son puntos de funcin?: .................................................................................................................... .................................................................................................................... .................................................................................................................... 2. Cmo se realiza la valoracin de los tipos de funcin en la tcnica de los PF
3. Qu son los ECS y qu aspectos se considera ECS?
96
4. Realice un ensayo sobre el proceso de gestin de riesgos

97
MODELADO DE ANLISIS DEL SOFTWARE
SISTEMA DE CONOCIMIENTOS INTRODUCCIN AL MODELADO Conceptos de modelado, utilidad, abstraccin, ventajas ANLISIS ESTRUCTURADO Breve historia, caractersticas Elementos del modelo del anlisis Modelado funcional o de procesos y flujo de informacin(DFDs), su notacin y diccionario de datos Modelado de datos (ER) y su diccionario de datos HERRAMIENTAS CASE (TI) Que es CASE Objetivos de las CASE Elementos de las CASE Tipos de CASE Ejemplos de CASE SISTEMA DE HABILIDADES Comprender la importancia del modelado de software Obtener una representacin general del software a construir a partir de la especificacin de los requisitos. SISTEMA DE VALORES Responsabilidad Criticidad Honestidad Compaerismo Responsabilidad Criticidad Honestidad Compaerismo
Identificar los tipos de CASE Utilizar las herramientas CASE apara el desarrollo del software
Responsabilidad Criticidad Honestidad Compaerismo

101
El Anlisis 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 grficos de datos, lo que permite mejora de la comprensin y validar requisitos. Mediante revisin se logra: correccin, integridad, consistencia de los requisitos.
OBJETIVO
Elaborar el modelado del software mediante el estudio y anlisis de los requisitos del software, las metodologas de anlisis y la elaboracin del prototipo que permita la obtencin de modelos fsicos y lgicos para el diseo del software.
ESQUEMA ESQUEMADEL DELTEMA TEMAIV IV
102
ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAIV IV

Para el estudio del Tema IV necesitas revisar la siguiente bibliografa:
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1, 2, 3, 4; Pginas:1-99. Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulo: 12; Pginas: 199-218. Kendall & Kendall, Anlisis y Diseo de software. Estudio de Factibilidad: Pginas: 47- 53 Planificacin del proyecto: Pginas: 54-74 Calidad del Software: Pginas: 745-765
1. INTRODUCCIN 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 notacin grfica, informacin y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformacin de la informacin empleando una arquitectura del tipo entrada y salida. La base para el modelado de anlisis del software es la Especificacin de los requisitos del software (ERS). Qu es un modelo? Un modelo es una simplificacin de la realidad Un modelo es el resultado de un proceso de abstraccin y ayuda a comprender y razonar sobre una realidad Un modelo de software es una descripcin de un aspecto del sistema, expresada en un lenguaje bien definido. Divisin 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
103
Modelado del Software. Comprende el modelado es el anlisis y diseo de aplicaciones software antes de escribir el cdigo. 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 produccin de software de calidad
Abstraccin - Modelado Visual (MV). El modelado captura las partes esenciales del sistema. Parte del proceso de negocio para representar en un modelo visual la solucin del sistema computacional.
104
Algunas ventajas del modelado visual: Hay estructuras que no son visibles en los programas. Ayuda a razonar sobre el cmo se implementa. Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Generacin de cdigo a partir de modelos Ha surgido un nuevo paradigma de desarrollo de software a partir de los modelos Los modelos: visualizan cmo es o queremos que sea el sistema especifican la estructura y comportamiento del sistema. guan la construccin del sistema. documentan las decisiones.
2. ENFOQUES DE MODELADO DE ANLISIS
105
Existen dos enfoques claramente establecidos: 1. Anlisis Estructurado. Comprende actividades como: Separacin datos y procesos Modelado de Datos Atributos y relaciones Modelado de Procesos Transformacin de datos 2. Anlisis Orientado a Objetos Definicin de clases Colaboracin entre las clases
3. ANLISIS ESTRUCTURADO
Breve Historia Es una tcnica de modelado del flujo, contenido y transformacin de la informacin que fluye por un sistema. Naci como complemento al Diseo Estructurado. El trmino Anlisis Estructurado fue popularizado por DeMarco a fines de los 70, quien present y denomin los smbolos grficos que permitiran al analista crear modelos de flujos de informacin. Yourdon, Gane y Sarson y otros presentaron variaciones a la propuesta original. A mediados de los 80, Ward y Mellor proponen ampliaciones para su aplicacin en sistemas de tiempo real y ms tarde, Hatley y Pirbhai presentan sus aportes a estos mismos sistemas. Caractersticas Descomposicin / Modularizacin Soporte grfico
106
Ausencia de Redundancia Centrado en modelizar el flujo y el contenido de la informacin PROCESOS y DATOS Aproximacin TOP-DOWN
Elementos del Modelo de Anlisis
(DFDs)
Diagramas de Flujo de Datos Diccionario de Datos (DD) Diagramas de EntidadRelacin (ER) Diagramas de Transicin de Estado (DTEs)
EP ED ER DD DFD
DTE EC
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 cmo funciona un negocio
107
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 ms detallado de sus subprocesos.
Notacin:
DICCIONARIO DE DATOS DEL DFD. Es un conjunto de informacin (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 comn el conocimiento.
108
Objetivos del DD: Crear un Glosario de trminos Establecer terminologa estndar Proporcionar referencias cruzadas Proporcionar control centralizado para cambios Ejemplo que permite visualizar la Especificacin de Procesos vs DFD y DD
El diccionario de datos de los DFDs se describe en matrices los procesos, almacenes , entidades y flujos de datos Procesos: Nombre, Descripcin, Nivel, Flujos entrantes, flujos salientes Flujos de Datos: Nombre, Descripcin, Alias (opcional), Origen y Destino Almacenes y entidades: Nombre, Descripcin, Flujos entrantes, flujos salientes DIAGRAMA ENTIDAD RELACIN Se utilizan para definir el modelo de datos Identifican Objetos y sus Relaciones
109
DICCIONARIO DE DATOS DEL DIAGRAMA ENTIDAD RELACIN Entidades: Nombre de entidad, descripcin, atributos y descripcin de atributos Relaciones: ID de relacin, entidad padre, entidad(es) hija(s), tipo de relacin, cardinalidad
4. HERRAMIENTAS CASE.
CASE. Es acrnimo de Computer Aided/Assisted Software/System Engineering. Comprende un conjunto de herramientas y metodologas que prestan soporte a un enfoque de ingeniera en el desarrollo de software o en alguna o en todas las fases de este proceso. La tecnologa CASE supone la informatizacin de la informtica o la automatizacin del desarrollo del software. Objetivos: Permitir la aplicacin prctica de metodologas estructuradas Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones Simplificar el mantenimiento de los programas Mejorar y estandarizar la documentacin Aumentar la portabilidad de las aplicaciones Facilitar la reutilizacin 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 definicin de las tcnicas y metodologas soportadas por la herramienta. Generador de Informes. Herramienta que permite obtener la documentacin sobre el sistema que se est desarrollando. Carga/Descarga de datos. Para intercambiar datos del repositorio con otros sistemas.
110
Comprobacin de errores. Analizar la exactitud, integridad y consistencia de los esquemas. Interfaz de usuario. Soporte grfico para las interacciones del usuario.
Tipos de herramienta CASE Herramientas de Gestin. Encargadas de la estimacin, planificacin y seguimiento del proyecto. Herramientas Tcnica. CASE Frontales o superiores, que abarcan las primeras fases del anlisis y del diseo CASE dorsales o inferiores, que abarcan el diseo detallado y la generacin del cdigo. Herramientas de Soporte. Como el sistema de repositorio/diccionarios, control y configuracin, seguridad Ejemplo de algunas herramientas CASE: Erwing Visual Case Easy Case Power Designer Weilan LCase CASO DE ESTUDIO: Modelar un Sistema de Informacin 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 gestin del sistema de pedidos, se realizan las siguientes funciones: 1. Verificacin de la validez del pedido del cliente 2. Armar los pedidos a los editores 3. Verificar el envo de los editores 4. Asignar libros a pedidos
111
5. Armar entrega a los clientes. DFD de Nivel 1
TAREAS DEL CRDITO 7 Para desarrollar habilidades en el modelado de anlisis del software, realice las siguientes actividades: 1. Ample la investigacin de los DFDs y su diccionario de datos. 2. Profundice la investigacin del MER y su diccionario de datos 3. Elabore un resumen de las herramientas CASE 4. Investigue una herramienta CASE para modelar los DFDs y el MER 5. Como actividad del crdito 7 debe realizar el ltimo AVANCE FINAL DE SU PROYECTO. Este avance involucra la elaboracin de su documento de Anlisis del Software. A continuacin se explican las orientaciones respectivas.
112
Realizar el modelado de anlisis del software segn el enfoque estructurado, del
proyecto final El Documento de Modelado de Anlisis del Software debe contener el siguiente formato: Cartula (Primera pgina): Logotipo del proyecto de desarrollo de software Nombre del Documento (en este caso Modelado de Anlisis del Software) Versin del Documento
A todas las pginas del documento colocar: Encabezado de pgina: Cdigo y nombre del documento, nmero de pgina, versin, Nombre del Proyecto Pie de pgina: Autor y fecha de creacin
1. Introduccin 1.1. Propsito (del documento) 1.2. Definiciones, acrnimos y abreviaturas 1.3. Referencias 2. Modelado de procesos 2.1. DFDs 2.2. Diccionario de datos de los DFDs 3. Modelado de Datos 3.1. Modelo Entidad Relacin (ER) 3.2. Diccionario de datos del modelo ER 4. Anexos
AUTO AUTOEVALUACIN EVALUACIN
113
1. Complete: a. En el contexto de los DFD, qu es proceso? : .................................................................................................................... .................................................................................................................... .................................................................................................................... ....................................................................................................................
e. Ventajas del modelado .................................................................................................................... .................................................................................................................... .................................................................................................................... f. Enfoques del anlisis del software: .................................................................................................................... .................................................................................................................... .................................................................................................................... 2. Describa la notacin de los DFDs
3. Explique el proceso de Modelado de Datos
114
115
ANEXO 1. SOLUCIONES DE AUTOEVALUACIN

SOLUCIONES DE AUTOEVALUACIN AL TEMA I ENUNCIADO 1: a. b. c. d. Verdadero Falso Verdadero Falso, en ingeniera de software, el software no solo a los programas sino tambin los documentos y datos.
116

Guía Ing - SW I EAD - 2009

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guía Ing - SW I EAD - 2009

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD TECNOLGICA SAN ANTONIO DE MACHALA

MODALIDAD DE EDUCACIN SEMIPRESENCIAL Y A DISTANCIA

ING. BERTHA MAZN 2009 EL ORO ECUADOR

Sistema de contenidos. .. Bibliografa Estrategias Metodolgicas. de

Sistema Evaluacin... Actividades de ..

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

PROBLEMA, OBJETO, OBJETIVO

OBJETO El proceso de ingeniera de software

UTSAM-Modalidad Semipresencial y a Distancia

Validacin de requisitos Gestin de requisitos

Responsabilidad Compaerismo Honestidad Responsabilidad Compaerismo Honestidad

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

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

UTSAM-Modalidad Semipresencial y a Distancia

10% 10 % 30% 50%

Slo el estudio libera al hombre de las ataduras de su ignorancia!

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

INTRODUCCIN A LA INGENIERA DE SOFTWARE (ISW)

SISTEMA DE VALORES Responsabilidad Criticidad Honestidad Compaerismo

TIEMPO ESTIMADO DE ESTUDIO

Conceptualizar terminologa y modelos de Ingeniera de Software.

ESQUEMA ESQUEMADEL DELTEMA TEMAI I

UTSAM-Modalidad Semipresencial y a Distancia

ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAI I

Tcnica Tcnica Metodologa Metodologa Herramienta Herramienta Producto Producto

Gestin Gestin del del Proyect Proyect o o

3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERA DEL SOFTWARE

UTSAM-Modalidad Semipresencial y a Distancia

Comparativa de proyectos para el desarrollo de sistemas de software

Fuente: Standish Group Survey

6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIN DE LA INGENIERA DE SOFTWARE

UTSAM-Modalidad Semipresencial y a Distancia

7. PRINCIPALES ESTNDARES Y MODELOS DE LA INGENIERA DE SOFTWARE

UTSAM-Modalidad Semipresencial y a Distancia

TAREAS TAREASDEL DELCRDITO CRDITO11

ORIENTACIONES ORIENTACIONESPARA PARAEL ELPROYECTO PROYECTOFINAL FINAL

A todas las pginas del documento colocar:

UTSAM-Modalidad Semipresencial y a Distancia

AUTOEVALUACIN AUTOEVALUACINTEMA TEMAI I

4. Describa las etapas de un proceso de Ingeniera de SW Genrico

5. Describa brevemente los principales estndares de la ingeniera de software

TUTORAS TUTORASPROGRAMADAS PROGRAMADAS

UTSAM-Modalidad Semipresencial y a Distancia

TIEMPO TIEMPOESTIMADO ESTIMADODE DEESTUDIO ESTUDIO

UTSAM-Modalidad Semipresencial y a Distancia

Realizar la especificacin de los requisitos de software del problema planteado

ESQUEMA ESQUEMADEL DELTEMA TEMAIIII

UTSAM-Modalidad Semipresencial y a Distancia

ACTIVIDADES ACTIVIDADESDE DEAPRENDIZAJE APRENDIZAJETEMA TEMAIIII

UTSAM-Modalidad Semipresencial y a Distancia

1. CONCEPTOS DE INGENIERA DE REQUISITOS

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

Fase en la que se soluciona el fallo

Los defectos comunes en los requisitos y sus consecuencias

UTSAM-Modalidad Semipresencial y a Distancia