º
DESARROLLO DE PROYECTOS INFORMÁTICOS Guía para el estudiante
Elaborado por el formador:
VERÓNICA FABIANA RINCÓN CANTOR
INSTITUTO COLOMBIANO DE APRENDIZAJE
INCAP
Programa Técnico Laboral en Sistemas
INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP
DESARROLLO DE PROYECTOS INFORMÁTICOS
EL SIGUIENTE MATERIAL SE PREPARÓ CON FINES ESTRICTAMENTE ACADÉMICOS, DE ACUERDO CON EL ARTÍCULO 32 DE LA LEY 23 DE 1982, CUYO TEXTO ES EL SIGUIENTE:
ARTÍCULO 32: “Es permitido utilizar obras literarias, artísticas o parte de ellas, a título de ilustración en obras destinadas a la enseñanza, por medio de publicaciones, emisiones o radiodifusiones, o grabaciones sonoras o visuales, dentro de los límites justificados por el fin propuesto, o comunicar con propósito de enseñanza la obra radiodifundida para fines escolares, educativos, universitarios y de formación personal sin fines de lucro, con la obligación de mencionar el nombre del autor y el título de las obras utilizadas”.
Desarrollo de Proyectos Informáticos Instituto Colombiano de Aprendizaje Elaborado por: Verónica Fabiana Rincón Cantor
Editado por: Instituto Colombiano de Aprendizaje INCAP Avenida Caracas No. 63-66 © Prohibida la reproducción parcial o total bajo cualquier forma (Art. 125 Ley 23 de 1982) Bogotá – Colombia Versión 01 - Julio 2010
2
DESARROLLO DE PROYECTOS INFORMÁTICOS
CONTENIDO PRESENTACIÓN GUÍA METODOLÓGICA UNIDAD UNO CICLO DE VIDA DEL SOFTWARE ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
5 6
MODELOS DEL CICLO DE VIDA DEL SOFTWARE Modelo en cascada Modelo en Espiral Modelo Incremental Modelo Evolutivo Modelo Concurrente METODOLOGÍAS Metodología CMMI Metodología ISO Metodología SCRUM TÉCNICAS DE RECOLECCION DE DATOS Introspección Entrevista Abierta Cuestionario Grupos de Discusión Tormenta de Ideas Entrevistas Observación FICHA PARA ENTREVISTAS ESPECIFICACION DE REQUERIMIENTOS FORMATO IEEE830 REQUERIMIENTOS UNIDAD DOS UML DIAGRAMAS DE CASO DE USO DIAGRAMAS DE SECUENCIA HERRAMIENTAS CASE MODELO ENTIDAD RELACION CRONOGRAMAS BIBLIOGRAFIA
1 1 4 1 5 1 6 2 8 2 0 2 1 2 2 2 3 2 5 2 5 2 6 2 7 3 8 3 0 3 0 3 1 3 2 3 3 3 3 4 7
1 1 0
7 5 5 1 5 2 5 5 6 9 6 0 6 1 3 3
DESARROLLO DE PROYECTOS INFORMÁTICOS
Apreciado estudiante: Usted escogió al INCAP para que lo oriente en el camino de la formación profesional. La institución le proporcionará un formador, quien le ayudará a descubrir sus propios conocimientos y habilidades. El INCAP, le ofrece además, recursos para que usted alcance sus metas, es decir, lo que se haya propuesto y para ello dispondrá de módulos guía, audiovisuales de apoyo, sistemas de evaluación, aula y espacios adecuados para trabajos individuales y de grupo. Éste módulo guía que constituye además un portafolio de evidencias de aprendizaje, está distribuido de la siguiente manera: PRESENTACIÓN: Es la información general sobre los contenidos, la metodología, los alcances la importancia y el propósito del módulo. GUÍA METODOLÓGICA: Orienta la práctica pedagógica en el desarrollo del proceso de formación evaluación y se complementa con el documento de la didáctica para la formación por competencias de manejo del formador. DIAGNÓSTICO DE ESTILO DE APRENDIZAJE: Que le permitirá utilizar la estrategia más adecuada para construir sus propios aprendizajes. AUTOPRUEBA DE AVANCE: Es un cuestionario que tiene como finalidad que usted mismo descubra, qué tanto conoce los contenidos de cada unidad, y le sirve de insumo para la concertación de su formación y el reconocimiento de los aprendizajes previos por parte de su formador (talleres que se encuentran al final de cada unidad). CONTENIDOS: Son el cuerpo de la unidad y están presentados así: • Unidad • Logro de competencia laboral • Indicadores de logro: Evidencias • Didáctica del método inductivo Activo para el desarrollo de las competencias: FDH: Formador Dice y Hace, FDEH: Formador Dice y Estudiante Hace, EDH: Estudiante Dice y Hace. VALORACIÓN DE EVIDENCIAS BIBLIOGRAFÍA
4
DESARROLLO DE PROYECTOS INFORMÁTICOS
P R E S E N T A C I Ó N
SENTACIÓN Desarrollar
un
software
significa
construirlo
simplemente
mediante su descripción. Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se presta
a
la
discusión
del
problema.
En
general
los
desarrolladores se centran en la solución dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución. El presente módulo ofrece al estudiante herramientas para desarrollar un software, donde intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el analista quien es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo e instalarlo al cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar todo lo necesario lo más seguro que le haga falta algún requerimiento o 5
DESARROLLO DE PROYECTOS INFORMÁTICOS
P R E S E N T A C I Ó N
G U Í A
M E T O D O L Ó G I C A
alguna parte del nuevo sistema y entre más estén involucradas mejor para cubrir con todos los requerimientos del sistema.
La estrategia metodológica del INCAP, para la formación técnica del aprendiz mediante competencias laborales, comprende dos caminos: 1. Las clases presenciales dictadas por el Formador haciendo uso del método inductivo – activo 2. El trabajo práctico de los estudiantes dirigido y evaluado por el Formador, a través de talleres, desarrollo de casos, lecturas y consultas de los temas de clase etc. Con esto se busca fomentar en el estudiante el análisis, el uso de herramientas tecnológicas y la responsabilidad. Los módulos guía utilizados por el INCAP, para desarrollar cada uno de los cursos, se elaboran teniendo en cuenta ésta metodología. Sus características y recomendaciones de uso son: A cada unidad de aprendizaje le corresponde un logro de competencia laboral el cual viene definido antes de desarrollar su contenido. Seguidamente se definen los indicadores de logro o sea las evidencias de aprendizaje requeridas que evaluará el Formador.
6
DESARROLLO DE PROYECTOS INFORMÁTICOS
Glosario: Definición de términos o palabras utilizadas en la unidad que son propias del tema a tratar. Desarrollo de la unidad dividida en contenidos breves seguidos por ejercicios, referenciados así:
» FDH (El Formador Dice y Hace): Corresponde a la explicación del contenido y el desarrollo de los ejercicios por parte del Formador.
» FDEH (El Formador Dice y el Estudiante Hace): El estudiante desarrolla los ejercicios propuestos y el Formador supervisa.
» EDH (El estudiante dice y hace): Es el trabajo práctico que desarrollan los estudiantes fuera de la clase, a través de talleres, desarrollo de casos, lecturas y consultas de los temas, los cuales deben ser evaluados por el Formador. Al final de cada unidad se puede presentar un resumen de los contenidos más relevantes y ejercicios generales.
DIAGNÓSTICO INFORMACIÓN GENERAL Regional_____________Programa__________________Módulo____________ Estudiante_________________________Formador_______________________ EVALUACIÓN DIAGNÓSTICA Estilo de aprendizaje_______________________________________________
7
DESARROLLO DE PROYECTOS INFORMÁTICOS
8
DESARROLLO DE PROYECTOS INFORMÁTICOS
Unidad
Uno
1
Ciclo de Vida y Análisis de requerimientos T E M A S 1. Ciclo de Vida del Software y Metodologías 2. Técnicas de Recolección de Datos 3. Análisis de requerimientos
Logros de Competencia
1. Conocer el ciclo de vida del software y aplicar técnicas de recolección de datos (entrevistas, observación) de acuerdo a los requerimientos del cliente, elaborar informe de especificación de requisitos de software utilizando herramientas informáticas según protocolos y normas.
Indicador de Logro
Evidencia de
1. Conoce el ciclo de vida del software y las metodologías 2. Conoce técnicas de recolección y las diferentes formas de análisis y organización 3. Elabora propuestas de trabajo de acuerdo con las necesidades expuestas en los requerimientos según normas y protocolos
Conocimiento Conocimiento
Producto
9
DESARROLLO DE PROYECTOS INFORMÁTICOS
10
El Formador Dice y Hace: 1. Ciclo de vida del software •
Software: procedimientos y reglas lógicas escritas en la forma de programas y aplicaciones, que definen el modo de operación de la computadora. Es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo.
•
Aplicación: es un tipo de programa informático diseñado como herramienta para permitir a un usuario realizar uno o diversos tipos de trabajo.
Ciertas aplicaciones desarrolladas 'a medida' suelen
ofrecer una gran potencia ya que están exclusivamente diseñadas para resolver un problema específico. •
Desarrollo de Software: es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo”:
•
Ciclo de Vida: Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. Desde la fase inicial hasta la fase final. El propósito es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP
Desarrollo de Proyectos Informáticos
2. ETAPAS DEL CICLO DE VIDA DEL SOFTWARE Necesidades: esta etapa tiene como objetivo la consecución de un primer documento en que queden
reflejados
los
requerimientos
y
funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado
que
normalmente
se
trata
de
necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas clienteproveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). Especificaciones: Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente. Lo más normal será que no resulte posible obtener una buena especificación del sistema a la
primera;
serán
necesarias
sucesivas
versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros
contactos
todo
lo
que
quiere
realmente, y por otra parte pueden surgir cambios
externos
que
supongan
requerimientos nuevos o modificaciones de los ya contemplados). 12
Desarrollo de Proyectos Informáticos
Análisis:
Es
elementos
necesario
intervienen
determinar
en
el
qué
sistema
a
desarrollar, así como su estructura, relaciones, evolución
en
el
funcionalidades,
tiempo, ...
que
detalle van
a
de
sus
dar
una
descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener Diseño: Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cómo va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.). Implementación:
Llegado
este
punto
se
empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos. Pruebas: el objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación.
Es conveniente que sean
planteadas al menos tanto a nivel de cada módulo (aislado del resto), como 13
Desarrollo de Proyectos Informáticos
de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).
Validación: Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple
con
los
requisitos
expresados
inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
Mantenimiento y Evolución: Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento),
así
como
otras
de
mayor
importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas
operaciones
contempladas
para
el
producto).
14
Desarrollo de Proyectos Informáticos
El Formador Dice y el estudiante Hace: 3. MODELOS DEL CICLO DE V IDA DEL SOFTWARE Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas. Un modelo de ciclo de vida del software: •
Describe las fases principales de desarrollo de software.
•
Define las fases primarias esperadas de ser ejecutadas durante esas
fases. •
Ayuda a administrar el progreso del desarrollo, y
•
Provee un espacio de trabajo para la definición de un detallado proceso
de desarrollo de software. Así, los modelos por una parte suministran una guía para los desarrolladores de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
15
Desarrollo de Proyectos Informáticos
3.1. MODELO EN CASCADA
Es un modelo base para los demás modelos. Fue definido por Royce y se trata principalmente de que se debe completar un paso correctamente sin ningún error para pasar al siguiente. Características del modelo cascada Este modelo muestra de una forma básica el desarrollo de software, y representa en fases separadas procesos fundamentales. Dice que se debe probar el software después de construirlo y antes de operarlo. Cada fase tiene como salida documentación. Fases del Modelo Cascada Las fases son: Ingeniería y Análisis del Sistema: establece requisitos de los elementos del sistema. Análisis de los requisitos del software: identifica las funciones del software, el rendimiento, sus interfaces y la información.
16
Desarrollo de Proyectos Informáticos
Diseño: se basa en estructura de datos, arquitectura del software el detalle de los procedimientos y la caracterización de la interfaz. Además escoge las herramientas para la codificación. Codificación: el diseño se traduce en lenguaje de máquina. Pruebas: Aquí se comprueba si existe algún error con el software o si funciona correctamente. Hasta que sea aceptado por el usuario. Mantenimiento: esta fase se da debido a que después de la entrega pudo haber errores en el software, o el software no se adapte al entorno externo o que el cliente requiera ampliaciones funcionales o de rendimiento. VENTAJA Este modelo como es sencillo solo utiliza los pasos intuitivos para desarrollar software, además es fácil de explicarlo al cliente. DESVENTAJAS Los proyectos raramente siguen el flujo secuencial, hay iteraciones El cliente no puede establecer al principio todos los requisitos. El cliente deber tener paciencia pues la versión operativa del producto solo estará disponible en las últimas etapas del proyecto.
3.2. MODELO EN ESPIRAL Es una serie de ciclos los cuales se repiten en forma de espiral, cada vez que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el proyecto. Lo característico de este modelo es que incluye un “análisis de riesgo” es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se basa en que antes de hacer algo debemos analizarlo, también debemos buscar varias opciones de resolución de problemas para de allí escoger la opción más conveniente, y además analizar los riesgos que se pueda tener. Este modelo necesita de otro para poder desarrollarse. Se debe escoger el modelo cascada cuando se pierda el control del
17
Desarrollo de Proyectos Informáticos
presupuesto o
por el calendario; y el de prototipeo cuando tengamos
problemas con la interfaz. El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de la siguiente forma: 1.- Planificación 2.- Análisis de Riesgos 3.- Ingeniería 4.- Evaluación
En cada vuelta o iteración hay que tener en cuenta Los Objetivos: Que necesidad debe cubrir el producto. Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: 1. Características: experiencia del personal, requisitos a cumplir, etc. 2. Formas de gestión del sistema. 3. Riesgo asumido con cada alternativa. 18
Desarrollo de Proyectos Informáticos
VENTAJAS El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. El modelo en espiral demanda una consideración directa de los riesgos técnicos
en
todas
adecuadamente
las
debe
etapas
reducir
del los
proyecto riesgos
y
antes
si de
se
aplica
que
se
conviertan en problemas DESVENTAJAS Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. Genera mucho tiempo en el desarrollo de sistemas.
1.3. MODELO INCREMENTAL
19
Desarrollo de Proyectos Informáticos
El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos. Ventajas: Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. Permite entregar al cliente un producto más rápido en comparación del modelo de cascada. Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos. Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. 20
Desarrollo de Proyectos Informáticos
Desventajas: El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos. Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto.
1.4. MODELO EVOLUTIVO
El modelo de desarrollo evolutivo (algunas veces denominado como prototipado
evolutivo)
construye
una
serie
de
grandes
versiones sucesivas de un producto. El modelo evolutivo asume que, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
21
Desarrollo de Proyectos Informáticos
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación
a
los
desarrolladores.
Basada
en
esta
retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión el producto es desarrollada y desplegada. El proceso se repite indefinidamente Desventajas El proceso no es visible. Se tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente es muy costoso producir documentos que reflejen cada versión Los sistemas tienen una estructura deficiente, tendiendo a dañar la estructura del software Se requieren técnicas y herramientas especiales, permiten un desarrollo rápido pero suelen ser incompatibles con otras herramientas o técnicas 1.5.
MODELO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo. Por ejemplo, el personal está escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). El modelo de proceso 22
Desarrollo de Proyectos Informáticos
concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Orientada a integrar sistemáticamente y en forma simultánea el diseño de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de un producto, desde la concepción inicial hasta su disposición final. Debe otorgar además una organización flexible y bien estructurada, proponer redes de funciones apoyadas por tecnologías apropiadas y arquitecturas comunes de referencia (ej: computadores en red y en bases de datos). Los objetivos globales que se persiguen con la implementación de la IC son: 1.
Acortar los tiempos de desarrollo de los productos.
2.
Elevar la productividad.
3.
Aumentar la flexibilidad.
4.
Mejor utilización de los recursos.
5.
Productos de alta calidad.
6.
Reducción en los costos de desarrollo de los productos.
Ventajas Excelente para proyectos en los que se conforman grupos de trabajo independientes. Proporciona una imagen exacta del estado actual de un proyecto. Desventajas Si
no
se
dan
las
condiciones
señaladas
no
es
aplicable.
Si no existen grupos de trabajo no se puede trabajar en este método
2. METODOLOGÍAS Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software 23
Desarrollo de Proyectos Informáticos
Tarea: actividades elementales en que se dividen los procesos Procedimiento: definición de la forma e ejecutar la tarea Técnica: herramienta utilizada para aplicar un procedimiento Herramienta: para realizar una técnica, podemos apoyarnos en las herramientas software que automatizan sus aplicación. Producto: resultado de cada etapa. METODOLOGÍA VS CICLO DE VIDA Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo. La metodología indica cómo hay que obtener los distintos productos parciales y finales CARACTERÍSTICAS DE UNA METODOLOGÍA ☺ Existencia de reglas predefinidas ☺ Cobertura total del ciclo de desarrollo ☺ Verificaciones intermedias ☺ Planificación y control ☺ Comunicación efectiva ☺ Utilización sobre un abanico amplio de proyectos ☺ Fácil formación ☺ Herramientas CASE ☺ Actividades que mejoren el proceso de desarrollo ☺ Soporte al mantenimiento ☺ Soporte de la reutilización de software METODOLOGÍA CMMI: El modelo CMMI proporciona un marco para la mejora de procesos que pueden ayudar a una organización en la mejora
24
Desarrollo de Proyectos Informáticos
de sus procesos y su habilidad para desarrollar, adquirir y mantener sus productos y servicios. El uso de estas metodologías ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al Ciclo de Vida del Software, estableciendo unas pautas de trabajo que permiten alcanzar los siguientes objetivos: •
Proporcionar o diseñar Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.
•
Dotar a la Organización de Productos Software que satisfagan las necesidades de los usuarios dando una mayor importancia al Análisis de Requisitos.
•
Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del Ciclo de Vida del Proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
•
Se contempla el desarrollo de Sistemas de Información para las distintas tecnologías que actualmente están conviviendo y los aspectos de Gestión de Proyectos que aseguran el cumplimiento de sus objetivos en términos de calidad, coste y plazos
Soluciones: •
Compromiso asegurado
•
Automatizar lo más posible las actividades de control y gestión de los procesos de los proyectos
•
Comenzar a documentar los procesos implícitos, en la medida de lo posible o plantillas en office, implementación de sistemas de gestión
•
Utilización
de
sistemas
libres
para
minimizar
los
costos
de
implementación Problemática: •
Requiere mucho esfuerzo, compromiso de toda la organización
25
Desarrollo de Proyectos Informáticos
•
Comenzar a diseñar y/o documentar procesos, luego desplegarlos y ponerlos en práctica
•
Requiere un mínimo de cantidad de personal (no menos de 10 personas en la práctica)
•
Fuerte inversión económica
METODOLOGIA ISO: Las series de ISO 9000 son un grupo de 5 individuales,
pero
relacionadas,
estándares
internacionales
de
administración de la calidad y aseguramiento de calidad. ISO 9001:2000 – sistemas de Gestión – Requisitos ISO 9004:2000 – Sistemas de Gestión de la Calidad –Guía de mejoras del funcionamiento ISO 9001:2000 es la norma que contiene los requisitos que debe cumplir una organización para la implementación de un Sistema de Gestión. ISO 9000-3: dedicada al proceso de desarrollo con calidad del software. Guía
para
la
aplicación
para
el
desarrollo,
implementación
y
mantenimiento de software. Beneficios de la Norma: •
Mejor documentación de los sistemas
•
Cambio cultural positivo
•
Incremento en la eficiencia y productividad
•
Mayor percepción de calidad
•
Se amplía la satisfacción del cliente
•
Se reducen las auditorías de calidad de los clientes
•
Agiliza el tiempo de desarrollo de un sistema.
ISO 12207 Esta norma esta orientada a los procesos de ciclo de vida del software de la organización ISO. Establece un proceso de ciclo de vida para el software que incluye procesos y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso.
26
Desarrollo de Proyectos Informáticos
METODOLOGIA SCRUM: Esta metodología se basa en una filosofía del desarrollo ágil de software. Lo interesante es que si un integrante del equipo se cae se viene abajo todo el equipo así que deben de estar coordinados para que todos vayan a la misma velocidad. Esta metodología está basada entre muchas bajo estas premisas: a)
Los individuos por encima de los procesos y herramientas
b)
En entregar soluciones por encima de reportes de seguimiento.
c)
A dar respuesta a los cambios en lugar de ceñirse a seguir un plan
Debe de haber una cohesión de equipo fuerte, porque el triunfo de un hito no es el triunfo de un solo jugador sino de todo el equipo, él mismo entrega el resultado. Todos colaboramos para obtener el triunfo y empujamos al que no está caminando como se debe. Se centra en presentar al cliente la solución que él pueda operar y usar, no solamente en entregar un reporte de lo que se ha hecho, de esta forma el cliente ve el progreso y puede decir cuando o no parar. Esto es una fortaleza ya que la mayoría está acostumbrada a un plan y el resultado lo ve al final del proyecto. Con la metodología SCRUM el cliente va viendo el resultado del producto y decide si sigue o termina el producto en ese momento. O inclusive tan radical como se escucha darle un giro completo.
El Estudiante Dice y Hace:
1. El estudiante Investigará información sobre la certificación CMM, organizaciones de software con certificación CMM. Tamaño, Tiempo requerido para lograr la certificación y costo 2. El estudiante elaborara un cuadro comparativo de los modelos de ciclo de vida del software indicando (concepto, ventajas, desventajas y proyectos a utilizar.
27
Desarrollo de Proyectos Informáticos
El Formador Dice y Hace: TÉCNICAS DE RECOLECCION DE DATOS La solución de un problema complejo, normalmente implica satisfacer las necesidades de diversos grupos de interés. Estos grupos pueden ser divididos en clientes y usuarios: Un cliente es una persona que tiene influencia sobre los requerimientos del sistema aunque no vaya a ser un usuario del mismo, mientras que los usuarios son las personas o grupos de personas que van a interactuar directamente con el sistema. Entender las necesidades de clientes y usuarios es una parte fundamental de un proyecto. Para entender las necesidades de estas personas hay que empezar por identificarlos. Algunas preguntas que podemos hacer para ayudarnos en esta labor son: ¿Cuáles serán los diferentes roles organizacionales que usaran el sistema? ¿Quién va a pagar por el sistema? ¿Qué otra persona se verá afectada por las salidas que el sistema produce? ¿Quién es responsable de evaluar y aceptar el sistema cuando se libere? ¿Quién será responsable de darle mantenimiento al sistema? Una vez que hemos identificado a los clientes y usuarios podemos aplicar varias técnicas para identificar cuáles son sus necesidades. La siguiente sección describe esas técnicas y algunas herramientas que ayudan a entender cuáles son las necesidades de los usuarios respecto al sistema que se va a construir.
INTROSPECCIÓN: La introspección es el medio más obvio y comúnmente usado para entender los requerimientos de un sistema. Consiste en estudiar el ambiente del usuario para posteriormente tratar de imaginar qué es lo que me gustaría que hiciera el sistema si yo estuviera a cargo de hacer el trabajo con su ayuda. 28
Desarrollo de Proyectos Informáticos
Esta técnica es útil pero hay que considerar que la experiencia de un analista de sistemas es muy diferente que la experiencia de los usuarios potenciales del software y por lo tanto es difícil que las conclusiones del analista reflejen la experiencia de las personas que hacen la tarea día con día. Esto se hace más evidente en el diseño de la interfaz gráfica del usuario, lo que para un analista es el comportamiento común de un software, puede resultar confuso o frustrante para un usuario. Tradicionalmente, debido a las limitaciones gráficas que anteriormente tenían las computadoras, se creaba una brecha entre el diseño de la aplicación y las necesidades de uso del usuario, sin embargo debido a la evolución de los ambientes gráficos el paradigma está cambiando: La obligación del usuario no es aprender a dominar una tecnología, es la tecnología la que debe ayudar al usuario a hacer su trabajo. La explosión del Internet ha creado nuevas especialidades como “user experience” en las cuales la psicología y la sociología son las principales herramientas científicas. La recomendación, cuando se usa la introspección, es apoyarla con la información previa que generan otras técnicas como por ejemplo la entrevista abierta. En cualquier caso es recomendable validar cualquier duda con un “experto de dominio”. Los expertos de dominio son personas con mucha experiencia en un área particular del negocio que es de interés para el sistema. Por ejemplo, en el caso de una línea de producción, el operador de alguna máquina de la línea puede ser un experto de dominio que aporte valiosa información para la automatización del proceso.
ENTREVISTA ABIERTA
29
Desarrollo de Proyectos Informáticos
Con los objetivos en mente, se saca la lista de datos que quiero conseguir
y
que
proporcionármelos.
fuentes
son
las
mas
adecuadas
para
Según lo anterior decido que instrumento me
conviene. Una de las principales consideraciones a tomar en cuenta en una entrevista es lograr que la predisposición del entrevistador no influya en el resultado de la narrativa capturada. Como proveedores de soluciones, estamos acostumbrados a identificar soluciones al mismo tiempo que escuchamos problemas, cuando hacemos esto, tendemos a influenciar las respuestas del entrevistado, provocando una mala comprensión del problema o una reducción en el grado de libertad de la solución. Una entrevista debe considerar preguntas libres de contexto (Gausse and Weinberg, 1989), es decir, preguntas que no influencien las respuestas de los entrevistados hacia las respuestas que queremos oír. Por ejemplo: ¿Quiénes son los usuarios del sistema? ¿Qué problemas tienen actualmente? ¿Cuáles son sus necesidades respecto a la solución? Algunos consejos que pueden ayudarnos durante una entrevista: No hagas preguntas donde se suponga de antemano que la gente puede describir actividades complejas. En general la gente puede hacer muchas cosas que no puede describir. Cuando necesites entender una actividad compleja separa la pregunta en varias partes o utiliza otra técnica como la investigación de campo. Haz preguntas abiertas que le permitan al usuario extenderse en sus respuestas y a ti comprender mejor su problemática. 30
Desarrollo de Proyectos Informáticos
No hagas preguntas que influencien la respuesta del entrevistado: ¿Usted necesita una pantalla para realizar esta tarea, verdad? No hagas preguntas para controlar la conversación: ¿Podemos regresar a la pregunta anterior? No hagas preguntas que se respondan así mismas: ¿50 elementos en esta lista son suficientes, verdad? Evita preguntas que empiecen con ¿Por qué?. Habitualmente estas preguntas ponen al entrevistado a la defensiva porque aparentan cuestionar la manera en que hace su trabajo. No
esperes
respuestas
sencillas.
Cuando
las
obtengas
sigue
preguntando para descubrir más “ruinas enterradas”. No apures al entrevistado para que responda. Si haces esto probablemente no querrá responder tu próxima pregunta. Por último lo más importante: Escucha con atención.
CUESTIONARIO Consisten en una serie de preguntas que el entrevistador hace de manera secuencial o que se entregan al entrevistado para que él mismo conteste. Los cuestionarios tienen la deficiencia de que no utilizan los elementos de interacción de la entrevista, por lo tanto se corre el riesgo de que, dado que la persona a la que se entrevista tiene diferente historia y por lo tanto diferentes conocimientos y categorías para clasificar los conceptos, algunas preguntas se malinterpreten o resulten irrelevantes y fuera de contexto.
GRUPOS DE DISCUCIÓN
31
Desarrollo de Proyectos Informáticos
Para tener una visión general y rápida de lo que un grupo de personas piensa, puede usar un grupo de discusión. En estos grupos, a manera de plática informal un moderador hace la entrevista para encontrar la información deseada. Consiste en involucrar a los usuarios en el proceso de desarrollo mediante talleres o workshops en los cuales se identifican los requerimientos. En los talleres pueden utilizarse diferentes técnicas para ir descubriendo requerimientos como "Casos de Uso", "Story Boards", "Modelos" o "Prototipos". Los grupos de desarrollo tienen el inconveniente de que no son comunidades naturales, por lo tanto es difícil que los participantes compartan categorías. Otro riesgo en estos talleres es que, dadas las jerarquías que existen dentro de una empresa, alguno de los participantes puede no sentirse libre para expresar su opinión o puede sentirse obligado a dar una opinión sobre un punto que desconoce o en el que él no es experto. Algunas recomendaciones para conducir un grupo de desarrollo son: Da a todos la oportunidad de hablar. Esto es esencial para que el workshop se considere imparcial. Procura que la sesión se mantenga andando. Existe una tendencia natural a que el workshop se convierta en una “sesión de quejas”. Identifica los problemas/requerimientos pero no profundices. Una vez que se ha identificado un problema/requerimiento avanza al siguiente. Permanece alerta para recoger información y hallazgos. Al final, resume la sesión y trabaja en generar conclusiones
TORMENTA DE IDEAS
32
Desarrollo de Proyectos Informáticos
La Tormenta de Ideas consiste en listar todas las ideas sobre un tema que se le ocurren a un auditorio determinado y posteriormente filtrarlas, desarrollarlas y priorizarlas. Una sesión de este tipo comienza con la aclaración del objetivo. El objetivo es muy importante porque permite mantener en foco la sesión, sin embargo no debe de ser limitante para la creatividad de las ideas expresadas, es más las ideas más descabelladas pueden resultar en soluciones innovadoras. Los participantes deben de aportar ideas sin interrupción y tantas como sea posible, para lograr esto, el moderador debe crear un ambiente en el que la creatividad y la apertura de mente tengan un lugar prioritario, por ejemplo evitando críticas o debates durante la aportación de ideas. Cuando las ideas comienzan a repetirse y los participantes empiezan a demorarse mucho tiempo entre idea e idea, es momento de suspender la sesión y pasar a filtrar, combinar, ordenar y priorizar las ideas. Al hacer esto, es necesaria la participación del grupo mediante debates y consensos. El moderador debe de evitar que la discusión se vuelva personal o que los debates se prolonguen demasiado, esto puede lograrse usando rondas de votación con prioridades, en las cuales a los miembros se les da una cantidad de puntos que deben distribuir entre las diferentes opciones, nunca asignado más del 50% de sus puntos a una opción. Al final se suman los puntos y la opción con más puntos resulta ganadora.
ENTREVISTA:
33
Desarrollo de Proyectos Informáticos
Es una serie de preguntas que puede realizarse personalmente, por teléfono, correo o por correo electrónico. Según su diseño estas pueden ser: •
Estructurada: es un cuestionario con preguntas que requieren
selección de una sola respuesta. •
Semi-estructurada: contiene preguntas de selección y preguntas
abiertas.
OBSERVACIÓN
A veces UD preferirá observar la conducta de personas, objetos y sucesos o algún fenómeno de interés, en forma directa. La observación puede hacerse de la siguiente manera: •
Estructurada: se especifica previamente lo que se va a observar y
como se va a registrar la observación 34
Desarrollo de Proyectos Informáticos •
No estructurada: El observador anota todos los aspectos que le
parezcan importantes es más exploratoria.
El Formador Dice y el estudiante Hace: FICHA PARA ENTREVISTAS Información del Proyecto Proyecto:
NOMBRE DEL PROYECTO
Entrevistador(es):
NOMBRE DE LA PERSONA(S)
Entrevistado(s):
NOMBRE DE LA PERSONA(S)
Fecha de la Entrevista: Lugar de la Entrevista: Documentos Relacionados:
FECHA LUGAR Propuesta del Proyecto > Público objetivo y beneficios Glosario de términos
TAREAS: Copie este archivo por cada entrevista hecha. COmplete los detalles. Haga una liga de este archivo a la sección de "Notas de Entrevistas y Lluvias de Ideas" de userneeds.html. Impacto del proceso: La planeación de preguntas para las entrevistas con inversionistas es la clave para un levantamiento de datos efectivo. Los buenos requerimientos son necesarios para construir el sistema correctamente. Estas notas deberán ser guardadas como parte de la documentación en requerimientos del usuario para ser referenciadas cuando la especificación de requerimientos de software sea redactada o actualizada.
Preguntas y Respuestas de la Entrevista TAREAS: Antes de la entrevista, planee las preguntar que va a hacer. Después, escriba las respuestas que recibió y cualquier otra pregunta o respuesta adicional que pueda surgir. ¿Cómo se dio cuenta de la necesidad de este producto? RESPUESTA ¿Qué tipos de usuarios podrían utilizar este producto? RESPUESTA
35
Desarrollo de Proyectos Informáticos
¿Podría dar un ejemplo de cómo un usuario podría utilizar el producto? RESPUESTA ¿Existe algún riesgo por utilizar este producto? RESPUESTA PREGUNTA1 RESPUESTA1 PREGUNTA2 RESPUESTA2 PREGUNTA3 RESPUESTA3 PREGUNTA4 RESPUESTA4 Otras Notas de la Entrevista TAREAS: Anote todo lo demás que haya surgido de la entrevista, ya sea explícita o implícitamente. Recuerde confirmar los datos que recabó implícitamente si tuviera dudas sobre ellos. Por ejemplo, tome notas de que el entrevista utiliza un significado poco usual para cierto término. Añada ligas a cualquier documento que le entregue el entrevistado. • NOTA • NOTA NOTA
•
Lista de Pendientes de la Entrevista •
1.
Antes de la entrevista Decida que objetivos desea cumplir
2.
Prepare una lista de preguntas
Pregunte sobre las cosas que conoce y que desea conocer, basado en su entendimiento actual de los requerimientos
Mantenga las preguntas simples. No utilice preguntas con muchas partes, rompa los temas complejos en preguntas individuales.
Confirme las suposiciones más importantes. Por ejemplo: "Ud. es la persona que utilizará este programa, cierto?" "El total necesita ser impreso y actualizado por cada elemento que se escanea, verdad?"
Evite sugerir o hacer preguntas de muchas partes, porque la respuesta correcta podría ser una que Ud. no conozca todavía. Por ejemplo, INCORRECTO: "Ud. entraría al sistema desde su escritorio aquí o desde su casa?" CORRECTO: "Cuáles son algunos de los lugares de donde entraría al sistema?" "Desde aquí en mi oficina, pero también cuando trabajo con otras personas algunas veces me conecto desde las computadoras en sus oficinas o desde una
36
Desarrollo de Proyectos Informáticos
computadora en el laboratorio o en la sala de juntas... así que no quisiera una cookie guardada aquí."
Trate de encontrar la prioridad para cada requerimiento: esencial, esperado, deseado u opcional.
Escriba más preguntas abiertas para ver si nuevos requerimientos de importancia salen a la luz.
No haga muchas preguntas que parezcan fuera del tema., podría accidentalmente cambiar el enfoque o hacer especulaciones incorrectas. Por ejemplo, "¿Le gustaría que el sistema hiciera también estas otras diez características?" "¡Claro!"
3.
Seleccione a los entrevistados que representen a todos los inversionistas importantes.
4.
Revise sus preguntas. ¿Cree que pueden ser contestadas? ¿Le ayudarán a alcanzar sus objetivos? Si no es así, redáctelas de nuevo.
5.
Decida si desea hacer esta entrevista vía email, teléfono o en persona
6.
Programe una entrevista según la conveniencia del entrevistado. Planee que la entrevista dure no más de una hora.
•
Durante la entrevista
1.
Sea atento, cortés y profesional
2.
Preséntese Ud. mismo y explique por qué está Ud. ahí.
3.
ASegúrese que está entrevistando a la persona que fue a entrevistar. Consiga su información de contacto (por ejemplo, su dirección de email) si aún no la tiene.
4.
Pida permiso para tomar notas. No grabe en cinta o video.
5.
Confirme el tiempo disponible con el que cuentan Ud. y el entrevistado para esta sesión.
6.
Dé una indicación rápida del tipo y número de preguntas que va a hacer
7.
Haga todas las preguntas.
8.
Escuche. Es para eso que esta Ud. ahí.
9.
10.
Si el entrevistado se refiere a documentos existente, sistemas, equipo o personas, asegúrese de entender de el o ella está hablando. Si es importante, pregunte si puede conseguir una copia o una pantalla (pero no solicite nada que pueda ser confidencial), o tome nota de los aspectos importantes de los elementos a los que se refiere. Apunte las URLs de cualquier sitio web público existente que salga en la entrevista.
Intente no responder las preguntas Ud. mismo, o reaccionar a las solicitudes del entrevistado haciendo 37
Desarrollo de Proyectos Informáticos
promesas de resolver sus problemas. La entrevistas son para entender los problemas, no para resolverlos o programar fechas de entrega. 11.
Anote los elementos de los puede obtener más información más tarde. Por ejemplo, si el entrevistado empieza a explicarle con detalle algo que Ud. sabe que puede aprender por su cuenta, o si el entrevistado no conoce la respuesta y empieza a especular, debería intentar seguir con la siguiente pregunta.
12.
Si se da cuenta que ha preparado mal las preguntas, concéntrese en obtener información que le ayudará a preparar las siguientes preguntas correctamente.
13.
Termine puntualmente. Si necesita más tiempo continúe via email o en una reunión posterior.
14.
Resuma los elementos de acción que investigará más tarde
15.
Pregunte si el entrevistado tiene preguntas para Ud., o si hay algo más que desea que Ud. le pregunte.
16.
Asegúrese de dejar sus datos de contacto
17.
Agradezca al entrevistado por su tiempo
Después de la entrevista
•
1.
En las primeras 24 horas, lea sus notas y complete los detalle importantes que fueron mencionados pero que no anotó
2.
Capture sus notas para que las pueda compartir con su equipo y archivadas
3.
Formule cualquier pregunta importante que desee hacer después
4.
Dentro de 2 o 3 días después, envíe un mensaje por email para
Agradecer al entrevistado de nuevo Confirmar que tiene la dirección de correo correcta, y facilitar a sus entrevistados la comunicación con Ud.
Pregunte cualquier pregunta que tenga aún
El Estudiante Dice y Hace: 1.
El estudiante deberá entrevistarse con su cliente y desarrollar la
ficha anterior, realizará como mínimo 3 entrevistas 38
Desarrollo de Proyectos Informáticos
2.
El estudiante realizara un informe indicando que tipos de
recolección de datos realizó y mostrando los resultados de cada uno.
El Formador Dice y Hace: ESPECIFICACION DE REQUERIMIENTOS El correcto manejo de los requerimientos es un factor del que depende el éxito del proyecto. Un requerimiento es una condición o capacidad que el sistema debe cumplir De forma más refinada –
Una capacidad del sistema requerida por el usuario para resolver un problema o alcanzar un objetivo
–
Capacidad que el sistema debe poseer o brindar a fin de satisfacer un contrato, especificación, estándar o alguna otra documentación formalmente impuesta
De manera formal, los requerimientos se documentan en el Documento de Especificación de Requerimientos (SRS), (Software Requirements Specification) El SRS sirve como contrato entre desarrolladores y cliente. Existe una serie de atributos que debe tener una especificación de software: Claridad/Carencia de ambigüedad: Cada uno de los requerimientos tiene una sola interpretación posible. Completa: Todo lo que el software debe hacer está incluido en las especificaciones. Las respuestas a cualquier tipo de datos de entrada en cualquier situación posible están incluidas en las especificaciones. Correcta: Cada uno de los requerimientos representa algo que el sistema requiere. Entendible: Cualquier tipo de lector puede, fácilmente, comprender el significado de todos los requerimientos con una explicación mínima
39
Desarrollo de Proyectos Informáticos
Verificable: Existe alguna técnica finita y costeable que puede ser usada para verificar que cada uno de los requerimientos especificados está incluido en el sistema terminado. Consistente: No existen conflictos entre requerimientos. Factible: Existe por lo menos un diseño y una implementación que satisfacen todos los requerimientos especificados. Rastreable: Está escrita de manera que facilita la referencia de cada requerimiento individual. El origen de cada requerimiento está claro. Concisa: Es lo más corta posible, sin afectar otras cualidades de la especificación. Diseño Independiente: Existe más de un diseño e implementación que satisface correctamente todos los requerimientos del sistema. Modificable: Tiene una estructura y estilo que permiten hacer cambios de una manera fácil, completa y consistente. No redundante: Los requerimientos no están repetidos Precisa: Se usan cantidades numéricas cuando es posible con el apropiado nivel de precisión. En general los siguientes pero se sugiere seleccionar una plantilla del estándar de la IEEE 1.
Enunciado resumen del proyecto
Por ejemplo:. “El propósito de este proyecto es crear una terminal de ventas a ser utilizada en tiendas supermercado” 2.
Cliente o Clientes:
Por ejemplo: “Tiendas Ramírez y Asociados.” 3.
Requerimientos funcionales del sistema: lo que se supone debe
hacer el sistema, como: El sistema debe autorizar créditos OBLIGATORIO IMPORTANTE: Los requerimientos funcionales pueden capturarse en forma de lista o por medio de casos de uso (siguiente tema). Funcionales: Qué va a hacer el sistema Interfaces externas, cómo interactúa el sistema con el hardware, personas, y otros sistemas Desempeño: Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación, etc. 40
Desarrollo de Proyectos Informáticos
Atributos: Portabilidad, mantenimiento, seguridad, etc. 4. Otros requerimientos –
Participantes
–
Grupos afectados
–
Acepciones
–
Riesgos
–
Glosario
Limitaciones: estándares, lenguaje de implementación, políticas de integridad de la base de datos, límite de recursos, sistemas operativos, etc. Correcto –
Los requerimientos reflejan una necesidad real
–
Cada requerimiento es uno que el software deberá implementar
No ambiguo –
Una sola interpretación
–
No usar más de una palabra para un mismo término (pedido u orden, por ejemplo)
–
Glosario si es necesario
PERSONAL Sin duda el elemento más valioso en el desarrollo de proyectos ¿Quiénes participan en un proyecto de software? Programadores Líder de proyecto Arquitectos de software Usuarios Analistas/Diseñadores Clientes Ingenieros de requerimientos Ingenieros de proceso Ingenieros de pruebas ¿Cuáles son las características deseables de un líder de proyecto? 41
Desarrollo de Proyectos Informáticos
Motivador Organizado Innovador Solucionador de Problemas ¿Cómo se organiza el equipo de trabajo? Centralizado Controlado (CC): El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical. Descentralizado Controlado (DC): Un jefe definido que coordina tareas específicas y jefes secundarios con responsabilidades sobre subtareas. La resolución de problemas es una actividad del grupo, la comunicación es horizontal y vertical. Descentralizado Democrático (DD) o “Egoless”: No tiene un jefe permanente, se nombran de acuerdo a la tarea. La solución de problemas se hace por consenso. La comunicación es horizontal. ¿Qué factores se deben considerar cuando se estructura un equipo de software? Complejidad del proyecto (dificultad del problema, tamaño del software) Tiempo de desarrollo. Modularidad. Calidad. Comunicación requerida. Discusión sobre ventajas y desventajas de cada tipo de organización. ¿Cómo creamos un equipo de alto rendimiento? Confianza entre los miembros del equipo. Distribución de habilidades de acuerdo al problema. Los inconformistas deben ser excluidos. ¿Qué factores pueden contaminar el desempeño de un equipo? Atmósfera de trabajo frenética, malgastan energía y se descentran de los objetivos 42
Desarrollo de Proyectos Informáticos
Alta frustración causada por factores tecnológicos, del negocio o personales que provocan fricción entre los miembros del equipo. Procedimientos coordinados pobremente o fragmentados o una definición pobre o impropiamente elegida del modelo de procesos que se convierte en un obstáculo a saltar. Definición confusa de los papeles a desempeñar produciendo una falta de responsabilidad y la acusación correspondiente. Continua y repetida exposición al fallo que conduce a una pérdida de confianza y una caída de la moral.
RIESGOS El
riesgo
siempre
implica
dos
características:
• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad. • Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias
no
deseadas
o
pérdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos. cliente y requisitos y su impacto en un proyecto de software. Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos
técnicos
identifican
problemas
potenciales
de
diseño,
implementación, de interfaz. verificación y de mantenimiento. Además. las ambigüedades de especificaciones, incertidumbre técnica, técnicas 43
Desarrollo de Proyectos Informáticos
anticuadas y las "tecnologías punta" son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos. Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro ei proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son: 1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado), 2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico), 3. Construir un producto que ei departamento de ventas no sabe cómo vender 4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección) 4. Perder presupuesto o personal asignado (riesgos de presupuesto). 5. Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos son simplemente imposibles de predecir. Otra categorización general de los riesgos ha sido propuesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto. del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fíables (p. ej.: fechas de entrega poco realistas. falta de especificación de requisitos o de ámbito del software. o un entorno pobre de desarrollo), los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (ej.: cambio de personal, mala comunicación con el cliente. disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Pueden ocurrir pero son extremadamente difíciles de identificar por adelantado.
44
Desarrollo de Proyectos Informáticos
El Formador Dice y el estudiante Hace: EJEMPLO DOCUMENTO ESPECIFICACION DE REQUERIMIENTOS Especificación de Requerimientos de Software (SRS) Información de la versión Proyecto: NOMBREDELPROYECTO Número Versión:
Interno
de
X.Y.Z
Formas Anexas:
SRS > Conjunto de casos de uso SRS > Conjunto de características
Documentos Relacionados:
Propuesta de proyecto Conjunto de características LIGAS A OTROS ESTÁNDARES RELEVANTES LIGAS A OTROS DOCUMENTOS
Impacto del proceso: Especificación de Requerimientos de Software (SRS) define de forma precisa el producto de software que se va a construir. Las decisiones hechas escribiendo la SRS están basados en información de los documentos de la propuesta del proyecto y requerimientos del usuario. El conjunto de requerimientos de SRS deben ser satisfechos en el diseño del sistema. La SRS es verificada y validada por la actividades marcadas en el plan de QA. Introducción TAREAS: Proveer un breve resumen de esta entrega del producto. Puede copiar el texto de la propuesta del proyecto, pegarla aquí, y resumirlo. PÁRRAFO PÁRRAFO Para más información, vea la propuesta del proyecto. Casos de Uso RESUMEN DE UN PÁRRAFO Detalles: • Los actores son descritos en el documento de requerimientos del usuario. • El conjunto de casos de uso use case suite enumera los casos de uso en una forma organizada. Requerimientos Funcionales RESUMEN DE UN PÁRRAFO Detalles: • El conjunto de características enumera todas las características en una forma organizada. Requerimientos No-Funcionales TAREAS: Describa los requerimientos no funcionales para esta entrega. Abajo se pueden ver algunos ejemplos. ¿Cuáles son los requerimientos de usabilidad? Nuestro principal criterio para hacer el sistema usable es la dificultad de realizar cada caso de uso de alta frecuencia. La dificultad depende de el 45
Desarrollo de Proyectos Informáticos
número de pasos, el conocimiento que el usuario debe tener en cada paso, las decisiones que el usuario debe realizar en cada paso, y la mecánica de cada paso (por ejemplo, escribir el título de un libro de forma exacta es difícil, hacer click en una lista es fácil). La interfaz del usuario deberá ser tan familiar como sea posible a los usuarios que han usado otras aplicaciones web y aplicaciones de escritorio en Windows. Por ejemplo, seguiremos las guías de la UI para nombrar los menus, botones y las cajas de diálogo siempre que sea posible. ¿Cuál es la confiabilidad y los requerimientos de último minuto? PÁRRAFO PÁRRAFO Detalles: • DETALLE • DETALLE • DETALLE ¿Cuáles son los requerimientos de precaución? PÁRRAFO PÁRRAFO Detalles: • DETALLE • DETALLE • DETALLE ¿Cuáles son los requerimientos de seguridad? El acceso será controlado con nombres de usuario y contraseñas. Solo los usuarios con derechos de administrador podrán accesar las funciones administrativas, los usuarios normales no podrán. Detalles: • Las contraseñas deberán tener de 4 a 14 caracteres de longitud • No utilizaremos comunicaciones encriptadas (SSL) para este sitio • DETALLE ¿Cuáles son los requerimientos de desempeño y escalabilidad? PÁRRAFO PÁRRAFO Detalles: • DETALLE • DETALLE • DETALLE ¿Cuáles son los requerimientos de mantenimiento y actualización? La capacidad de mantenimiento es nuestra habilidad para realizar cambios al producto en el tiempo. Necesitamos una capacidad de mantenimiento fuerte para retener a nuestros primeros clientes. Resolveremos esto anticipando varios tipos de cambios y documentando cuidadosamente nuestro diseño y nuestra implementación. La capacidad de actualización es nuestra habilidad para entregar nuevas versiones del producto a bajo costo a los clientes con un mínimo de tiempo de descarga o disrupción. Una característica clave para apoyar este objetivo es la descarga automática de parches o actualizaciones y actualizaciones del equipo del usuario final. También debemos utilizar 46
Desarrollo de Proyectos Informáticos
formatos para archivos de datos que incluyan suficientes meta-datos para permitirnos trasformar con seguridad la información existente del usuario durante una actualización. Detalles: • DETALLE • DETALLE • DETALLE ¿Cuáles son los requerimientos de soportabilidad y operabilidad? La soportabilidad es nuestra habilidad de proveer soporte técnico eficiente y a buen precio. Nuestro objetivo es limitar nuestros costos de soporte a solo 5% de las tarifas de licenciamiento anual. Las características de actualización automática del producto no ayudará a entregar fácilmente parches a los usuarios finales. La guía del usuario y el sitio web del producto incluyen una guía de resolución de problemas y una lista de información que debe tener a la mano antes de contactar a soporte técnico. La operabilidad es nuestra habilidad de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones). Las características del producto deberán ayudarnos a alcanzar nuestros objetivos de 99.9% en línea (con 43 minutos máximo fuera de línea por mes). Las características principales que soporten esto son la capacidad de crear respaldos de datos en tiempo de operación, y el monitoreo de la aplicación. ¿Cuáles son los requerimientos del ciclo de vida del negocio? El ciclo de vida del negocio de un producto incluye todo lo que le pasa a ese producto sobre un periodo de varios años, desde la decisión inicial de compra, a través de importantes pero poco frecuentes casos de uso, hasta el retiro del producto. Los requerimientos principales de del ciclo de vida son listados abajo. Detalles: • Los clientes deberán se capaces de manejar el número de licencias con el que ya cuentan y de hacer decisiones informadas sobre las compras de más licencias cuando sea necesario • el producto deberá soportar operación diaria y nuestra auditoría de fin de año • La información del cliente deberá ser almacenada en un formato que sea accesible incluso después de que la aplicación sea retirada. Requerimientos Ambientales TAREAS: Describa los requerimientos ambientales para esta entrega. Los requerimientos ambientales describen el sistema más grande hardware, software, y los data con el que este producto debe trabajar. Se proveen algunos ejemplos más abajo. ¿Cuáles son los requerimientos de hardware del sistema? PÁRRAFO PÁRRAFO Detalles: • DETALLE • DETALLE ¿Cuáles son los requerimientos de software del sistema? PÁRRAFO 47
Desarrollo de Proyectos Informáticos
PÁRRAFO Detalles: • DETALLE • DETALLE ¿Qué Interfaces de Aplicación del Programa (APIs) deben incluirse? PÁRRAFO PÁRRAFO Detalles: • Debemos implementar esta API estándar. • DETALLE • DETALLE ¿Cuáles son los requerimientos de importación y exportación de datos? PÁRRAFO PÁRRAFO Detalles: • El sistema deberá almacenar todos los datos en una base de datos SQL estándar, donde pueda ser accesado por otros programas. • El sistema podrá almacenar todos los datos en un archivo XML, usando una DTD estándar. • El sistema deberá leer y escribir archivos .XYZ válidos para ser usados por OTRA APLICACIÓN
FORMATO IEEE830 REQUERIMIENTOS
Especificación de requisitos de software Proyecto: [Nombre del proyecto] Revisión [99.99]
48
Desarrollo de Proyectos InformĂĄticos
[Mes de aĂąo]
49
Desarrollo de Proyectos Informáticos
Instrucciones para el uso de este formato Este formato es una plantilla tipo para documentos de requisitos del software. Está basado y es conforme con el estándar IEEE Std 830-1998. Las secciones que no se consideren aplicables al sistema descrito podrán de forma justificada indicarse como no aplicables (NA). Notas: Los textos en color azul son indicaciones que deben eliminarse y, en su caso, sustituirse por los contenidos descritos en cada apartado. Los textos entre corchetes del tipo “[Inserte aquí el texto]” permiten la inclusión directa de texto con el color y estilo adecuado a la sección, al pulsar sobre ellos con el puntero del ratón. Los títulos y subtítulos de cada apartado están definidos como estilos de MS Word, de forma que su numeración consecutiva se genera automáticamente según se trate de estilos “Titulo1, Titulo2 y Titulo3”. La sangría de los textos dentro de cada apartado se genera automáticamente al pulsar Intro al final de la línea de título. (Estilos Normal indentado1, Normal indentado 2 y Normal indentado 3). El índice del documento es una tabla de contenido que MS Word actualiza tomando como criterio los títulos del documento. Una vez terminada su redacción debe indicarse a Word que actualice todo su contenido para reflejar el contenido definitivo.
De la plantilla de formato del documento © & Coloriuris http://www.qualitatis.org 41
Desarrollo de Proyectos Informáticos
Ficha del documento Fecha
Revisión
Autor
Verificado calidad.
[Fecha]
[Rev]
[Descripcion]
[Firma o sello]
dep.
Documento validado por las partes en fecha: [Fecha] Por el cliente
Por la empresa suministradora
Fdo. D./ Dña [Nombre]
Fdo. D./Dña [Nombre]
42
Desarrollo de Proyectos Informáticos
Contenido SENTACIÓN...................................................................................................................................... 5 FICHA DEL DOCUMENTO.............................................................................................................. 42 CONTENIDO.................................................................................................................................... 43 INTRODUCCIÓN.............................................................................................................................. 45 Propósito......................................................................................................................................... 45 Alcance............................................................................................................................................ 45 Personal involucrado..................................................................................................................... 45 Definiciones, acrónimos y abreviaturas.......................................................................................45 Referencias..................................................................................................................................... 45 Resumen......................................................................................................................................... 45 DESCRIPCIÓN GENERAL.............................................................................................................. 46 Perspectiva del producto............................................................................................................... 46 Funcionalidad del producto........................................................................................................... 46 Características de los usuarios..................................................................................................... 46 Restricciones.................................................................................................................................. 46 Suposiciones y dependencias...................................................................................................... 46 Evolución previsible del sistema.................................................................................................. 46 REQUISITOS ESPECÍFICOS.......................................................................................................... 46 Requisitos comunes de los interfaces......................................................................................... 47 Interfaces de usuario.................................................................................................................... 47 Interfaces de hardware................................................................................................................. 47 Interfaces de software.................................................................................................................. 47 Interfaces de comunicación.......................................................................................................... 48 Requisitos funcionales.................................................................................................................. 48 Requisito funcional 1.................................................................................................................... 48 Requisito funcional 2.................................................................................................................... 48 Requisito funcional 3.................................................................................................................... 48 Requisito funcional n.................................................................................................................... 48 Requisitos no funcionales............................................................................................................. 48 Requisitos de rendimiento............................................................................................................ 48
43
Desarrollo de Proyectos Informåticos Seguridad..................................................................................................................................... 48 Fiabilidad...................................................................................................................................... 49 Disponibilidad............................................................................................................................... 49 Mantenibilidad.............................................................................................................................. 49 Portabilidad.................................................................................................................................. 49 Otros requisitos.............................................................................................................................. 49 APÉNDICES..................................................................................................................................... 49
44
Desarrollo de Proyectos Informáticos
Introducción [Inserte aquí el texto] La introducción de la Especificación de requisitos de software (SRS) debe proporcionar una vista general de la SRS. Debe incluir el objetivo, el alcance, las definiciones y acrónimos, las referencias, y la vista general del SRS. Propósito [Inserte aquí el texto] Propósito del documento Audiencia a la que va dirigido Alcance [Inserte aquí el texto] Identificación del producto(s) a desarrollar mediante un nombre Consistencia con definiciones similares de documentos de mayor nivel (ej. Descripción del sistema) que puedan existir Personal involucrado Nombre [Inserte aquí el texto] Rol [Inserte aquí el texto] Categoría [Inserte aquí el texto] profesional Responsabilidades [Inserte aquí el texto] Información de [Inserte aquí el texto] contacto Aprobación [Inserte aquí el texto] Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc. Definiciones, acrónimos y abreviaturas [Inserte aquí el texto] Definición de todos los términos, abreviaturas y acrónimos necesarios para interpretar apropiadamente este documento. En ella se pueden indicar referencias a uno o más apéndices, o a otros documentos. Referencias Fech Referencia Titulo Ruta a Autor [Ref.] [Título] [Ruta] [Fecha] [Autor] Relación completa de todos los documentos relacionados en la especificación de requisitos de software, identificando de cada documento el titulo, referencia (si procede), fecha y organización que lo proporciona. Resumen [Inserte aquí el texto] 45
Desarrollo de Proyectos Informáticos
Descripción del contenido del resto del documento Explicación de la organización del documento Descripción general Perspectiva del producto [Inserte aquí el texto] Indicar si es un producto independiente o parte de un sistema mayor. En el caso de tratarse de un producto que forma parte de un sistema mayor, un diagrama que sitúe el producto dentro del sistema e identifique sus conexiones facilita la comprensión. Funcionalidad del producto [Inserte aquí el texto] Resumen de las funcionalidades principales que el producto debe realizar, sin entrar en información de detalle. En ocasiones la información de esta sección puede tomarse de un documento de especificación del sistema de mayor nivel (ej. Requisitos del sistema). Las funcionalidades deben estar organizadas de manera que el cliente o cualquier interlocutor pueda entenderlo perfectamente. Para ello se pueden utilizar métodos textuales o gráficos. Características de los usuarios Tipo de usuario [Inserte aquí el texto] Formación [Inserte aquí el texto] Habilidades [Inserte aquí el texto] Actividades [Inserte aquí el texto] Descripción de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia técnica. Restricciones [Inserte aquí el texto] Descripción de aquellas limitaciones a tener en cuenta a la hora de diseñar y desarrollar el sistema, tales como el empleo de determinadas metodologías de desarrollo, lenguajes de programación, normas particulares, restricciones de hardware, de sistema operativo etc. Suposiciones y dependencias [Inserte aquí el texto] Descripción de aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo una asunción puede ser que determinado sistema operativo está disponible para el hardware requerido. De hecho, si el sistema operativo no estuviera disponible, la SRS debería modificarse. Evolución previsible del sistema [Inserte aquí el texto] Identificación de futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro. Requisitos específicos Esta es la sección más extensa y más importante del documento.
46
Desarrollo de Proyectos Informáticos
Debe contener una lista detallada y completa de los requisitos que debe cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el suficiente para que el equipo de desarrollo pueda diseñar un sistema que satisfaga los requisitos y los encargados de las pruebas puedan determinar si éstos se satisfacen. Los requisitos se dispondrán en forma de listas numeradas para su identificación, seguimiento, trazabilidad y validación (ej. RF 10, RF 10.1, RF 10.2,...). Para cada requisito debe completarse la siguiente tabla: Número de requisito [Inserte aquí el texto] Nombre de requisito [Inserte aquí el texto] Tipo Requisito Restricción Fuente del requisito [Inserte aquí el texto] Prioridad del requisito Alta/Esencial Media/Deseado
Baja/ Opcional
y realizar la descripción del requisito La distribución de los párrafos que forman este punto puede diferir del propuesto en esta plantilla, si las características del sistema aconsejan otra distribución para ofrecer mayor claridad en la exposición. Requisitos comunes de los interfaces [Inserte aquí el texto] Descripción detallada de todas las entradas y salidas del sistema de software. Interfaces de usuario [Inserte aquí el texto] Describir los requisitos del interfaz de usuario para el producto. Esto puede estar en la forma de descripciones del texto o pantallas del interfaz. Por ejemplo posiblemente el cliente ha especificado el estilo y los colores del producto. Describa exacto cómo el producto aparecerá a su usuario previsto. Interfaces de hardware [Inserte aquí el texto] Especificar las características lógicas para cada interfaz entre el producto y los componentes de hardware del sistema. Se incluirán características de configuración. Interfaces de software [Inserte aquí el texto] Indicar si hay que integrar el producto con otros productos de software. Para cada producto de software debe especificarse lo siguiente: Descripción del producto software utilizado Propósito del interfaz Definición del interfaz: contiendo y formato 47
Desarrollo de Proyectos Informáticos
Interfaces de comunicación [Inserte aquí el texto] Describir los requisitos del interfaces de comunicación si hay comunicaciones con otros sistemas y cuales son las protocolos de comunicación. Requisitos funcionales [Inserte aquí el texto] Definición de acciones fundamentales que debe realizar el software al recibir información, procesarla y producir resultados. En ellas se incluye: Comprobación de validez de las entradas Secuencia exacta de operaciones Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperación de errores) Parámetros Generación de salidas Relaciones entre entradas y salidas (secuencias de entradas y salidas, formulas para la conversión de información) Especificación de los requisitos lógicos para la información que será almacenada en base de datos (tipo de información, requerido) Las requisitos funcionales pueden ser divididos en sub-secciones. Requisito funcional 1 Requisito funcional 2 Requisito funcional 3 Requisito funcional n Requisitos no funcionales Requisitos de rendimiento [Inserte aquí el texto] Especificación de los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que deberá soportar el sistema, etc. Todos estos requisitos deben ser mesurables. Por ejemplo, indicando “el 95% de las transacciones deben realizarse en menos de 1 segundo”, en lugar de “los operadores no deben esperar a que se complete la transacción”. Seguridad [Inserte aquí el texto] Especificación de elementos que protegerán al software de accesos, usos y sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden especificar: Empleo de técnicas criptográficas. Registro de ficheros con “logs” de actividad. Asignación de determinadas funcionalidades a determinados módulos. Restricciones de comunicación entre determinados módulos. 48
Desarrollo de Proyectos Informáticos
Comprobaciones de integridad de información crítica. Fiabilidad [Inserte aquí el texto] Especificación de los factores de fiabilidad necesaria del sistema. Esto se expresa generalmente como el tiempo entre los incidentes permisibles, o el total de incidentes permisible. Disponibilidad [Inserte aquí el texto] Especificación de los factores de disponibilidad final exigidos al sistema. Normalmente expresados en % de tiempo en los que el software tiene que mostrar disponibilidad. Mantenibilidad [Inserte aquí el texto] Identificación del tipo de mantenimiento necesario del sistema. Especificación de quien debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un desarrollador. Especificación de cuando debe realizarse las tareas de mantenimiento. Por ejemplo, generación de estadísticas de acceso semanales y mensuales. Portabilidad [Inserte aquí el texto] Especificación de atributos que debe presentar el software para facilitar su traslado a otras plataformas u entornos. Pueden incluirse: Porcentaje de componentes dependientes del servidor. Porcentaje de código dependiente del servidor. Uso de un determinado lenguaje por su portabilidad. Uso de un determinado compilador o plataforma de desarrollo. Uso de un determinado sistema operativo. Otros requisitos [Inserte aquí el texto] Cualquier otro requisito que no encaje en ninguna de las secciones anteriores.
Por ejemplo: Requisitos culturales y políticos Requisitos Legales Apéndices [Inserte aquí el texto] Pueden contener todo tipo de información relevante para la SRS pero que, propiamente, no forme parte de la SRS.
El Estudiante Dice y Hace: 1. El estudiante elaborara el análisis de requerimientos de la aplicación utilizando el formato IEEE830 49
Desarrollo de Proyectos Informรกticos
50