Taller de Ingeniería de Software

SEMANA 1
Ingeniería de Software:
Análisis

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 1
ninguna clase.
 2
ESTE DOCUMENTO CONTIENE LA SEMANA 1
ÍNDICE

Ingeniería de Software: Análisis .......................................................................................................... 4

OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4
INTRODUCCIÓN ...................................................................................................................................... 4
1. PLANIFICACIÓN DE ACTIVIDADES ....................................................................................................... 5
1.1. ACTIVIDADES ....................................................................................................................... 5
1.2 REGISTRO DE LA PLANIFICACIÓN DE ACTIVIDADES ............................................................ 7
2. ETAPA DE ANÁLISIS, FASE 1................................................................................................................ 8
2.1. PRESENTACIÓN DE LA PROBLEMÁTICA ............................................................................... 8
2.2. REQUERIMIENTOS FUNCIONALES ....................................................................................... 9
2.3. REQUERIMIENTOS NO FUNCIONALES ............................................................................... 10
3. REGISTRO DE ACTIVIDADES REALIZADAS ........................................................................................... 11
COMENTARIO FINAL.......................................................................................................................... 13
REFERENCIAS........................................................................................................................................ 13

3
ESTE DOCUMENTO CONTIENE LA SEMANA 1
Ingeniería de Software: Análisis

OBJETIVOS ESPECÍFICOS
• Elaborar la Planificación de las actividades vinculadas al desarrollo del software,
considerando las etapas de ciclo de vida.

• Determinar la problemática, los requerimientos funcionales y no funcionales del proyecto

de desarrollo de software abordado.

• Registrar las actividades vinculadas a la planificación y a la etapa de análisis, de acuerdo al

ciclo de vida de software.

INTRODUCCIÓN
“La ingeniería de software es una disciplina de la ingeniería que se interesa por todos los aspectos
de la producción de software, … se enfoca en el sentido práctico del desarrollo y en la distribución
de software” (Sommerville, Ian. 2012).

No se debe olvidar que el objetivo de la ingeniería del software es construir un producto de

calidad y de manera oportuna, es decir, que responda a las necesidades de manera correcta y en
tiempo determinado.

Para cumplir el objetivo es que, mediante las buenas prácticas, se deben cumplir cada una de las
etapas del ciclo de vida del software, además, de contar con una planificación de las actividades
realista y efectiva.

La planificación adecuada de las actividades a realizar para obtener el producto, como ya está
dicho, es fundamental, es la hoja de ruta del proyecto, y es por ello que es la primera actividad a
realizar y debe incluir todas las etapas del ciclo de vida del software, además, como en cada etapa
se genera información, se debe ajustar esta planificación permanentemente de acuerdo a los
nuevos antecedentes.

Las etapas del ciclo de vida clásico del software son:

• Análisis: en la cual se define el producto a obtener en base a la problemática a resolver y

los requisitos a cumplir.

4
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 • Diseño: Se define en detalle el producto o software en base al diseño lógico y físico.

• Desarrollo: Se realiza la programación de las piezas de software o módulos que componen

el producto.

• Pruebas: Se realizan las pruebas a cada módulo programado y la integración de todos ellos

• Implantación y Mantenimiento: Se realiza la Instalación de los módulos en el ambiente

operativo definitivo, se realiza la carga inicial de los datos necesarios para operar y se
define el plan de mantenimiento de los módulos.

1. PLANIFICACIÓN DE ACTIVIDADES
El Objetivo de realizar la planificación de actividades es proporcionar un marco de trabajo u hoja
de ruta que permita hacer estimaciones razonables de recursos y planificación temporal.

La planificación consiste en definir las actividades o tareas que se deben realizar para conseguir el
objetivo, cuando deben iniciar estas tareas, cuando deben terminar, su duración y que actividad se
debe realizar solo cuando se haya finalizado otra.

Existen diversas herramientas para registrar esta planificación, por ejemplo, MS Excel, MS Project,
etc., para este taller se utilizará Excel.

1.1. ACTIVIDADES
Las actividades o tareas a considerar en una planificación dependen de varios factores, por
ejemplo: el problema a resolver, el ámbito donde opera el software, el modelo a aplicar, etc.

Las actividades o tareas típicas del ciclo de vida clásico de un Sistema de Información para una
organización, son las siguientes:

o Presentación problemática.
o Definición Requerimientos Funcionales.
o Definición Requerimientos No
Funcionales.
Etapa de Análisis
o Definición Requerimientos de Usuario.
o Definición Requerimientos de Sistema.
o Validación de Requerimientos.
o Selección de modelo de Desarrollo.

Etapa de Diseño o Diseño Lógico.

5
ESTE DOCUMENTO CONTIENE LA SEMANA 1
  Diagramas de Actividad.
 Diagramas de Casos de Uso.
 Diagramas de Secuencias.
 Diagramas de Estado.
 Diagramas de Clases.
 Elaboración de las
Especificaciones de desarrollo
o Diseño Físico:
 Selección de la Arquitectura del
Software.
 Selección Ambiente Operativo.
 Selección Lenguaje de
Desarrollo.
 Selección Método de
Desarrollo.

o Definición del alcance de la

Capacitación.
o Diseño de Pruebas.
 Pruebas de Sistema.
 Pruebas de Componentes.
 Pruebas de Integración.
o Desarrollo de los componentes del
software.
 Desarrollo Módulo xxx.
Etapa de Desarrollo y Pruebas
 Desarrollo Módulo yyy.
 Desarrollo Módulo zzz.
o Ejecución de Pruebas.
 De Sistema.
 De Componentes.
 De Integración.
o Descripción de resultados.
o Evaluación de resultados de las
pruebas.

o Elaboración del Plan de Capacitación.

o Confección del Manual de Usuario.
o Confección de Plan de Mantenimiento
del Software.
Etapa de Implementación
o Ejecución de la Implantación del
Software.
 Instalación de los módulos.
 Carga inicial de data.

Hito Entrega Formal y Cierre

del Proyecto

6
ESTE DOCUMENTO CONTIENE LA SEMANA 1
1.2 REGISTRO DE LA PLANIFICACIÓN DE ACTIVIDADES
El registro de actividades debe contener, para cada una de ellas, al menos la siguiente
Información:

• Nº de Tarea: Identificación numérica de la tarea o actividad.

• Nombre de la Actividad: Nombre con que identificamos la actividad

• Duración: Cantidad de días que se requiere para realizar la actividad.

• Comienzo: Fecha en la cual debe iniciar la actividad o tarea.

• Fin: Fecha máxima que debe concluir la tarea.

• Predecesoras: Identificación (número) de la o las tareas que deben concluir antes que se
pueda realizar la actividad.

Cuando una tarea está descompuesta en subtareas, se registra la tarea y todas sus subtareas
con la fecha de inicio de la tarea igual a la fecha de inicio de la subtarea que inicia antes, la
fecha de término igual a la fecha de término de la subtarea que termina más tarde y la
duración igual a la duración en que se realizarán todas las subtareas.

Ejemplo de Registro de actividades:

Nº Nombre Duración Comienzo Fin Predecesoras

2 Etapa de Análisis. 14 25/09/2015 08/10/2015
3 Presentación problemática. 2 25/09/2015 26/09/2015
4 Definición Requerimientos Funcionales. 3 27/09/2015 29/09/2015 3
5 Definición Requerimientos No Funcionales. 2 30/09/2015 01/10/2015 4
6 Definición Requerimientos de Usuario. 3 02/10/2015 04/10/2015 5
7 Definición Requerimientos de Sistema. 2 05/10/2015 06/10/2015 6
8 Validación de Requerimientos. 1 07/10/2015 07/10/2015 7
9 Selección de modelo de Desarrollo. 1 08/10/2015 08/10/2015 8

La Tarea Nº 2, Etapa de Análisis, tiene una duración de 14 días que corresponde a la suma de
las duraciones de sus subtareas.

El comienzo de la Etapa de Análisis tiene la misma fecha que la subtarea Presentación

problemática (actividad Nº 3) que es la primera actividad de la etapa y el Fin la misma fecha
que la subtarea Selección del Modelo de Desarrollo (actividad Nº 9) que es la última que se
realiza.

7
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 La subtarea Definición de Requerimientos NO Funcionales (actividad Nº 5) tiene como
predecesora de la subtarea Definición de Requerimientos Funcionales (actividad Nº 4), es
decir, mientras no se termine la actividad Nº 4 no se puede realizar la actividad Nº 5.

2. ETAPA DE ANÁLISIS, FASE 1

En esta Fase de la Etapa de Análisis se debe mostrar lo que el producto a desarrollar debe
solucionar mediante la presentación de la Problemática a Resolver y la Definición de los
Requerimientos Funcionales y NO Funcionales de acuerdo al ciclo de vida clásico de desarrollo de
software.

2.1. PRESENTACIÓN DE LA PROBLEMÁTICA

Para realizar un proyecto de desarrollo de software es necesario conocer y describir cuál es la
necesidad o problema que se va a resolver mediante este desarrollo, se deben describir las
necesidades a cubrir, el entorno en el que se debe desempeñar la solución, los antecedentes de la
organización y/o legales que justifican la necesidad y los actores que intervendrán en la operación
del sistema.

El siguiente es un ejemplo de Presentación de la Problemática:

Sistema de Rendiciones de Proyectos

Se debe realizar el análisis, diseño y construcción del Sistema de Rendiciones

de Proyectos, que operará en la Subgerencia de Finanzas y Gestión de la
Gerencia de Administración y Finanzas que permita llevar el control
financiero de los proyectos que realiza la empresa.
Dado que la realización de los proyectos es de completa responsabilidad de
cada jefe, y es este quien debe realizar los pagos correspondientes a gastos
directos del proyecto y al pago de servicios prestados por terceros. Estos
pagos deben ser rendidos periódicamente para su registro y contabilización.
Para efectos de llevar adecuadamente el control financiero del proyecto y
que es necesario contar con información agregada de cada uno de los
proyectos y de cada Jefe de Proyecto se hace necesario contar con un
sistema que permita tener la información técnica y financiera de cada
proyecto, además, debe permitir identificar quien es el jefe de cada uno de
ellos. El sistema debe ser paramétrico, con control de acceso y diferenciado
a la información; y debe entregar los informes necesarios para la gestión
financiera de la Gerencia de Administración y Finanzas.

Fuente: Proyecto ejemplo elaborado para la asignatura

8
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 2.2. REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales, como su nombre lo sugiere, definen las funcionalidades
específicas que el sistema debe cumplir, es decir, establecen los comportamientos del sistema,
pero además, los requerimientos funcionales también pueden definir lo que el sistema no debe
hacer. Un requerimiento funcional se puede describir como un conjunto de entradas, procesos y
salidas.

La descripción de un requerimiento funcional tiene una carátula que contiene nombre, número de
serie único (para realizar el seguimiento) y un resumen para ayudar a entender la funcionalidad,
además, esta descripción contiene un detalle donde se definen todas las entradas, procesos o
reglas que transforman las entradas y los resultados como salidas.

Ejemplos de Requerimientos funcionales:

“El acceso al módulo debe ser controlado por la función de autenticación

mediante la identificación de usuario y su correspondiente contraseña”.

Descripción del Requerimiento

REQ–01 Acceso mediante autenticación de usuario

Autenticación al sistema mediante la identificación de usuario y su contraseña

Entradas - Nombre Usuario

- Contraseña

Procesos Verificación de la existencia del usuario y su correspondiente

contraseña en la Base de Datos

Salidas Acceso al sistema

“Mantención de tablas del sistema: Esta funcionalidad permite a los actores

internos del sistema, realizar acciones de creación y modificación de datos
paramétricos del sistema”.

Descripción del Requerimiento

REQ–02 Mantención de tablas del sistema

Permite realizar acciones de creación y modificación de datos paramétricos

Entradas - Acción a realizar “Creación o Modificación”

- Información del parámetro a crear o modificar

Procesos Si es creación, se debe validar que el parámetro no exista, si no existe

9
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 crear el parámetro, si existe, informar esta situación al usuario.

Si es Modificación, validar que el parámetro exista, si existe realizar la

modificación, si no existe, informar esta situación al usuario.

Salidas El parámetro modificado

Fuente: Proyecto ejemplo elaborado para la asignatura

2.3. REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales son aquellos requerimientos que no se refieren directamente a
las funciones del sistema, es decir, son restricciones de los servicios o funciones ofrecidos por el
sistema.

Los requerimientos no funcionales se suelen clasificar de acuerdo a las implicaciones que tienen
(Sommerville, Ian. 2012), (Pressman, Roger. 2005).

• Requerimientos del Software: Especifican el comportamiento del software como el

desempeño del sistema, la memoria requerida o su límite; las exigencias de portabilidad y
de usabilidad, entre otros.

• Requerimientos de la organización: Se derivan de las políticas, normas y procedimientos

existentes en la organización por ejemplo los estándares que deben utilizarse, imagen
corporativa, lenguajes y normas de programación, etc.

• Requerimientos externos: Son los factores externos al sistema y de su proceso de

desarrollo tales como requerimientos de interoperabilidad con otros sistemas existentes,
aplicación de condiciones legales que determinan su operación.

Ejemplos de Requerimientos No Funcionales:

“Se han definido las siguientes plataformas tecnológica para el desarrollo del
sistema:
• El sistema debe ser construido en plataforma Web (Microsoft IIS),
para que operen en un ambiente de Intranet.
• La plataforma de Bases de Datos debe ser Microsoft SQL Server 2000
Enterprise.
• La plataforma de desarrollo debe ser Microsoft .NET”.

10
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 Fuente: Proyecto ejemplo elaborado para la asignatura

3. REGISTRO DE ACTIVIDADES REALIZADAS

Para un efectivo control del avance de un proyecto de desarrollo de software es necesario llevar el
registro detallado del tiempo de dedicación a cada una de las actividades del proyecto realizadas,
en cada una de sus etapas, de esta manera podemos conocer la duración real de cada actividad y
eventualmente realizar posteriormente los ajustes necesarios a la planificación, además, de
entregarnos información real para evaluar los tiempos en futuros proyectos.

El registro de la duración de las actividades realizadas está asociada a cada persona trabajando en
el proyecto y se realiza en la Hoja de Registro de Actividades que debe contener la siguiente
Información:

• Proyecto: Nombre del proyecto del cual se registra la actividad realizada, esto es necesario
porque eventualmente una persona puede estar trabajando en más de un proyecto en
forma simultánea.

• Etapa: Nombre de la etapa a la cual corresponde la actividad para poder evaluar los
tiempos por etapa.

• Nombre Actividad: Como su nombre lo dice, el nombre con que hemos identificado la
actividad.

• Fecha: Fecha en que se realiza la actividad.

• Duración: cantidad de horas, aproximadas al entero superior, dedicadas a esa actividad,

en ese día.

Es importante destacar que una misma actividad, del mismo proyecto se puede realizar en
más de un día por lo que esta se repetirá.

Un ejemplo de Hoja de Registro de Actividades es el siguiente:

11
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 Hoja de Registro de Actividades
Realizado por: Juanito de los Palotes
Proyecto Etapa Nombre Actividad Fecha Duración (horas)
Proyecto Ejemplo Análisis Confección de la Planificación 28/09/2015 5
Proyecto Ejemplo Análisis Presentación problemática. 28/09/2015 4
Proyecto Ejemplo Análisis Presentación problemática. 29/09/2015 4
Proyecto Ejemplo Análisis Presentación problemática. 30/09/2015 4
Proyecto Ejemplo Análisis Definición Requerimientos Funcionales. 30/09/2015 4
Proyecto Ejemplo Análisis Definición Requerimientos Funcionales. 01/10/2015 7
Proyecto Ejemplo Análisis Definición Requerimientos No Funcionales. 01/10/2015 1
Proyecto Ejemplo Análisis Definición Requerimientos Funcionales. 02/10/2015 6
Proyecto Ejemplo Análisis Definición Requerimientos No Funcionales. 03/10/2015 7
Proyecto Ejemplo Análisis Definición Requerimientos No Funcionales. 04/10/2015 4

12
ESTE DOCUMENTO CONTIENE LA SEMANA 1
COMENTARIO FINAL
Si bien cada etapa del ciclo de vida del software es importante, la etapa de planificación y análisis
tiene una relevancia que va más allá de la formalidad del proceso, la planificación adecuada y la
definición correcta de los requerimientos, puede asegurar el éxito del proyecto de desarrollo, un
proyecto que NO cumple adecuadamente los requisitos o bien, no se termina en el tiempo
definido, se considera un proyecto fracasado.

Es importante que la planificación sea lo más realista posible, en muchos casos se pide realizar
más de una planificación considerando también el peor de los escenarios antes de decidir la
ejecución del proyecto de desarrollo.

La definición de los requerimientos es fundamental para que el resultado final, es decir, el

software desarrollado, cumpla con las necesidades de la organización, es por ello necesario
prestar mucha atención a aquellos requerimientos que puedan estar ambiguos o que no estén
claramente definidos.

La validación de parte de los usuarios del sistema y de los requerimientos registrados, se torna en
una herramienta indispensable para el éxito del proyecto.

REFERENCIAS
Ian Sommerville (2012). Ingeniería de Software. 9ª Edición. Editorial Pearson. México.

Roger S. Pressman (2005). Ingeniería de Software. 6ª Edición. Editorial MacGraw Hill

Interamericana. México.

13
ESTE DOCUMENTO CONTIENE LA SEMANA 1
 14
ESTE DOCUMENTO CONTIENE LA SEMANA 1