Metodologia de Desarrollo de Software Seguro SCS V 2.0

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 34

SCS

CONTENIDO
1. OBJETIVOS ........................................................................................................................................................................................ 4

2. ALCANCE ........................................................................................................................................................................................... 4

3. DEFINICIONES Y ESTÁNDARES...................................................................................................................................................... 4

4. MARCO TEÓRICO ............................................................................................................................................................................. 5

5. RESPONSABLES ............................................................................................................................................................................. 10

6. ESTRUCTURA ORGANIZACIONAL PROPUESTA ......................................................................................................................... 10

7. METODOLOGÍA DE DESARROLLO................................................................................................................................................ 12

7.1 ETAPAS DE LA METODOLOGÍA ........................................................................................................................................... 12

7.2 ACTIVIDADES QUE SOPORTA LA METODOLOGÍA ............................................................................................................ 13

7.2.1 Desarrollos Internos ..................................................................................................................................................... 13

7.2.1.1 Falla y/o incidente................................................................................................................................................... 13

7.2.1.2 Nuevo desarrollo o Mejora ..................................................................................................................................... 13

7.2.2 Desarrollos Externos ................................................................................................................................................... 14

8. DESCRIPCIÓN DE LAS ETAPAS DE LA METODOLOGÍA DE DESARROLLO ............................................................................. 15

8.1 ESPECIFICACIÓN DE REQUERIMIENTOS .......................................................................................................................... 15

8.1.1 Objetivo ........................................................................................................................................................................ 15

8.1.2 Roles de los participantes ............................................................................................................................................ 15

8.1.3 Recepción de documentos .......................................................................................................................................... 15

8.1.4 Documentos generados en la etapa de especificación de requerimientos ................................................................. 16

8.1.4.1 Documento de especificación de requerimientos ................................................................................................... 16

8.1.4.2 Documento Matriz de Validación ............................................................................................................................ 16

8.1.4.3 Documento de Diseño de Reportes ....................................................................................................................... 16

8.1.4.4 Documento Manual de Usuario .............................................................................................................................. 17

8.1.5 Productos de la Etapa ................................................................................................................................................. 17

8.1.6 ORGANIZACIÓN Y PLANEACIÓN ............................................................................................................................. 18

8.1.7 Objetivo ........................................................................................................................................................................ 18

8.1.8 Roles de los participantes ............................................................................................................................................ 18

8.1.9 Documentos generados en la etapa de Organización y Planeación ........................................................................... 18

8.1.9.1 Documento de organización y planeación.............................................................................................................. 18

8.1.9.2 Reunión para evaluación del requerimiento ........................................................................................................... 18

8.1.10 Productos de la Etapa ................................................................................................................................................. 19

8.2 ANÁLISIS DE REQUERIMIENTOS ........................................................................................................................................ 19

8.2.1 Objetivo ........................................................................................................................................................................ 19

8.2.2 Roles de los participantes ............................................................................................................................................ 19

8.2.3 Documentos generados en la etapa de análisis de requerimientos ............................................................................ 19

8.2.3.1 Diagrama de casos de uso ..................................................................................................................................... 19

8.2.3.2 Casos de uso extendido ......................................................................................................................................... 19

8.2.4 Aprobación del documento de Análisis ........................................................................................................................ 20

8.2.5 Productos de la etapa .................................................................................................................................................. 20

8.3 DISEÑO DE SOFTWARE ....................................................................................................................................................... 21

8.3.1 Objetivo ........................................................................................................................................................................ 21

8.3.2 Roles de los participantes ............................................................................................................................................ 21

Ing: Gonzalo Andrés Rojas

2
SCS

8.3.3 Documentos generados en la etapa de Desarrollo de software .................................................................................. 21

8.3.3.1 Herramientas incluidas en el proyecto ................................................................................................................... 21

8.3.3.2 Arquitectura del sistema ......................................................................................................................................... 21

8.3.3.3 Diagrama Entidad relación ..................................................................................................................................... 22

8.3.3.4 Diccionario de datos ............................................................................................................................................... 22

8.3.3.5 Glosario de términos .............................................................................................................................................. 22

8.3.4 Aprobación del documento de Diseño ......................................................................................................................... 23

8.3.5 Productos de la etapa .................................................................................................................................................. 23

8.4 CONSTRUCCIÓN DE SOFTWARE ...................................................................................... ¡ERROR! MARCADOR NO DEFINIDO.

8.4.1 Objetivo ........................................................................................................................................................................ 24

8.4.2 Roles de los participantes ............................................................................................................................................ 24

8.4.3 Documentos generados en la etapa de Construcción de software ............................................................................. 24

8.4.3.1 Elaboración del Plan de desarrollo ......................................................................................................................... 24

8.4.3.2 Elaboración del Manual Técnico ............................................................................................................................ 24

8.4.4 Descripción de la etapa ............................................................................................................................................... 24

8.4.5 Productos de la etapa .................................................................................................................................................. 24

8.5 PRUEBAS DEL SISTEMA ...................................................................................................................................................... 25

8.5.1 Objetivo ........................................................................................................................................................................ 25

8.5.2 Roles de los participantes ............................................................................................................................................ 25

8.5.3 Documentos generados en la etapa de Pruebas de software ..................................................................................... 25

8.5.3.1 Elaboración del Plan de Pruebas ........................................................................................................................... 25

8.5.3.2 Mantenimiento del manual de usuario.................................................................................................................... 25

8.5.4 Ejecución de las Pruebas ............................................................................................................................................ 25

8.5.4.1 Requisitos para la Ejecución de las Pruebas ......................................................................................................... 25

8.5.4.2 Preparación para las pruebas ................................................................................................................................ 26

8.5.4.3 Ejecución ................................................................................................................................................................ 26

8.5.4.4 Ejecución de las mejoras, nuevos requerimientos y corrección de fallas .............................................................. 26

8.5.5 Productos de la etapa .................................................................................................................................................. 26

8.6 IMPLANTACIÓN DE SOFTWARE ......................................................................................................................................... 27

8.6.1 Objetivo ........................................................................................................................................................................ 27

8.6.2 Roles de los participantes ............................................................................................................................................ 27

8.6.3 Documentos generados en la etapa de Implantación de software .............................................................................. 27

8.6.3.1 Elaboración del Plan de Implantación .................................................................................................................... 27

8.6.4 Productos de la etapa .................................................................................................................................................. 27

8.7 MANTENIMIENTO DE SOFTWARE ...................................................................................................................................... 28

8.7.1 Objetivo ........................................................................................................................................................................ 28

8.7.2 Roles de los participantes ............................................................................................................................................ 28

8.7.3 Documentos generados en la etapa de Mantenimiento de software........................................................................... 28

8.7.3.1 Elaboración del Documento de Mantenimiento de software .................................................................................. 28

8.7.4 Etapas del Mantenimiento de Software ....................................................................................................................... 29

8.7.5 Productos de la etapa .................................................................................................................................................. 29

BIBLIOGRAFÍA ........................................................................................................................................................................................... 33

Ing: Gonzalo Andrés Rojas

3
SCS

Definir una metodología de desarrollo de software seguro en donde se establezcan las etapas, las
actividades y técnicas necesarias para la construcción y mantenimiento de un proyecto de desarrollo
de software, garantizando la obtención de productos de calidad y seguridad. Existen en la actualidad
varias metodologías de desarrollo de software seguro. Entre ellas se encuentran: Correctness by
Construction (CbyC), Common Criteria, Comprehensive, Security Development Lifecycle (SDL),
Cigital Touchpoints y Lightweight Application Security Process (CLASP). También OWASP, PCI DSS
e ISO 27001:2013 ofrecen una serie de recomendaciones para mejorar la seguridad durante el ciclo
de desarrollo.

Figura No. 1. Desarrollo seguro.

La metodología de desarrollo de software seguro define las etapas y actividades que se deben seguir
para la implementación de nuevos desarrollos, mejoras, desarrollos externos y para dar solución a
fallos en el software, garantizando que estos procesos se realicen de forma eficiente, siguiendo las
políticas y procedimientos establecidos.

SP 800-12: Este documento del NIST provee una introducción a la seguridad de los computadores y
provee guías de seguridad para el hardware, software, y los activos de información.

SP 800-14: Provee a una línea base que las organizaciones pueden utilizar para revisar su programa
de seguridad de la información.

FALLA: Una Falla o Incidente se presenta cuando el sistema en producción se comporta de manera
inesperada.

DESARROLLO EXTERNO: Contratación del proceso de construcción de software que puede incluir
las etapas de especificación de requerimientos, organización y planeación, análisis de
requerimientos, diseño y mantenimiento de software.

Ing: Gonzalo Andrés Rojas

4
SCS

DESARROLLO INTERNO: Consiste en la elaboración o mantenimiento del software por el personal


del Área de Tecnología de la organización.

COMITÉ DE DESARROLLO: Grupo conformado por Jefe, Coordinador y analista de desarrollo e


invitados, quienes están encargados de la organización, planeación y control de cada uno de los
nuevos desarrollos, fallas, desarrollos externos y mejoras.

COMITÉ DE PRODUCTO: Grupo conformado por los dueños de proceso o negocio de la institución
responsable de evaluar, definir y planear la implementación de nuevos productos o servicios.

CLIENTE INTERNO: Un cliente interno es cada uno de los funcionarios de la entidad a quienes se les
presta un servicio.

Con el fin de poder desarrollar software que sea inmune a fallas y posibles amenazas, es importante
incorporar los conceptos de seguridad desde la fase de requerimientos hasta la fase final de
mantenimiento del ciclo SDLC (Software Development Life Cycle). Los conceptos de seguridad se
deben considerar a lo largo de todo el ciclo de desarrollo y deben ser direccionados en cada fase. Si
en alguna de las fases no se prestara atención suficiente a la seguridad de la información esto podría
redundar en la disminución de los esfuerzos prestados a las fases previas.

Algunos de los conceptos más importantes para implementar la seguridad de la información en el


desarrollo de software son:

Confidencialidad Integridad Disponibilidad

Autenticación Autorización Registros y auditoría

Figura No. 2. Premisas de seguridad.

DISPONIBILIDAD:

Propiedad que determina que la información sea accesible y utilizable por solicitud de una entidad
autorizada. La disponibilidad de la información se debe garantizar por medio de los planes de
continuidad del negocio o planes para la recuperación ante desastres. Se trata de poder acceder a las
aplicaciones y a la información que ellas manejan cuando sea requerido y se cuenta con la respectiva
autorización.

Ing: Gonzalo Andrés Rojas

5
SCS

Los acuerdos de servicio (Service level Agreement-SLA) es uno de los ejemplos que pueden citarse
para explícitamente estipular los requerimientos para las aplicaciones que soportan los diferentes
servicios de una determinada organización. El balanceo de cargas y la replicación de información
críticos son otros dos mecanismos que ayudan a mejorar la disponibilidad de la información.

CONFIDENCIALIDAD:

Propiedad que determina la condición de que la información no esté disponible ni sea revelada a
individuos, entidades o procesos no autorizados. La confidencialidad protege contra posibles ataques
en que la información pueda ser sometida al escrutinio público. Hoy en día muchos ataques tienen en
mente el robo de información, por ejemplo, en el caso de la información que está en las tarjetas de
crédito que puede ser fácilmente utilizada para generar robo de dinero y de ahí el interés y el
creciente aumento de estos eventos.

INTEGRIDAD:

Propiedad de salvaguardar la exactitud y estado completo de los activos. Se considera que aplicación
posee resiliencia si cumple el papel de proteger la información contra alteraciones de datos no
autorizadas. Cuando se realiza una operación financiera uno esperaría que la cantidad de dinero
transferido sea igual a la cantidad de dinero que es descontada de la cuenta. En otras palabras,
esperamos que las aplicaciones sean consistentes en el uso de información. Se requiere que la
información que sea transmitida, procesada y almacenada se mantenga consistente según la
intención del que realiza la transacción.

AUTENTICACIÓN: Las aplicaciones en la gran mayoría de organizaciones procesan información


sensible, por esta razón es importante que su acceso esté debidamente controlado y solamente
aquellas personas o entidades estén debidamente autorizadas. La autenticación responde a la
pregunta sobre si lo que se dice ser es verdadero. En otras palabras, durante el proceso de
autenticación se realiza una validación de la identidad de la entidad que solicita el acceso a la
aplicación. La autenticación cubre tres aspectos:

Conocimiento

Característica Propiedad

Figura No. 3. Autenticación

Ing: Gonzalo Andrés Rojas

6
SCS

Conocimiento: En este aspecto de los tres considerados durante el proceso de autenticación se


busca validar solicitando un conocimiento que este usuario, si es quien dice ser, debería poseer.
Ejemplos de este tipo de conocimiento están los nombres de usuario, las contraseñas y los
números de identificación personal (PIN).

Propiedad: El proceso de identificación en este aspecto se surte por medio de la presentación ante
el sistema que identifica de algo que nosotros poseemos y en teoría nadie más posee. Ejemplos de
este tipo autenticación son los tokens o smart cards.

Características: La identificación de la información provista en este aspecto o mecanismo es algo


que uno es de manera intrínseca. El ejemplo más difundido es el uso de biométricos. El caso de la
huella del dedo y el iris del ojo son características que pueden ser utilizadas para la identificación
individualizada.

AUTORIZACIÓN: Por el hecho de que las credenciales de identidad hayan sido validadas no quiere
decir esto que se le daba dar acceso a todos los recursos que se soliciten. Por ejemplo, puede darse
el caso que a alguien se le pueda dar acceso al software de contabilidad, no obstante, es posible que
el acceso a los datos de salarios deba ser bloqueados a él por su nivel de confidencialidad. La
autorización es el concepto dentro de la seguridad de la información en que los accesos a los
diferentes objetos son controlados y está basado en los derechos y privilegios que son otorgados a
los usuarios de acuerdo a las políticas y a los dueños de la información.

REGISTRO Y AUDITORÍA: La creación de registros de los diferentes componentes es importante


para que en caso de un incidente de seguridad se pueda contar con la información respectiva que
permita realizar la investigación de todos los eventos sucedidos.

A continuación, expondremos los conceptos de seguridad que deben ser considerados cuando se
trate de diseñar la arquitectura de software seguro:

Separación de Defensa en
Menor privilegio Falla segura
tareas profundidad

Economía de Mediación Mecanismos


Diseño abierto
mecanismos completa mínimos comunes

Aceptabilidad Igualando los


Enlace débil
psicológica componentes

Ing: Gonzalo Andrés Rojas

7
SCS

Figura No. 4. Principios de seguridad.

MENOR PRIVILEGIO: Un principio dentro de la seguridad de la información en que a un proceso o


usuario se le es dado solamente el nivel mínimo de derechos de acceso que son necesarios para que
completen una determinada actividad u operación. Este derecho o permiso debe ser concedido
solamente por el tiempo requerido para realizar esta actividad.

SEPARACIÓN DE TAREAS: Conocido también como el principio de compartimentación o separación


de privilegios, es un principio de seguridad que establece que para realizar una determinada tarea
requiere de dos o más condiciones que deben cumplirse sin lo cual no se podría realizar esta tarea.

DEFENSA EN PROFUNDIDAD: También conocido como defensa por niveles, este es un principio de
seguridad en donde el compromiso de alguno de los niveles de la defensa no implica que otros
niveles sean susceptibles de ataque.

FALLA SEGURA: Este principio de seguridad tiene como objetivos preservar la confidencialidad,
integridad y disponibilidad de la información durante una falla del software, de tal manera que el
estado en el que se estabilice, estos pilares de la seguridad de la información, sean mantenidos.

ECONOMÍA DE MECANISMOS: A este principio de seguridad subyace la concepción que entre más
simple sea el diseño de un componente o sistema la probabilidad de contar con vulnerabilidades
potenciales decrece en proporción a esta simplicidad. Si se mantiene el diseño del software dentro de
un nivel de simplicidad razonable, la superficie de ataque será reducida.

MEDIACIÓN COMPLETA: Este principio de seguridad establece que cuando un determinado sujeto
requiera acceder a un objeto este evento debe ser autorizado y en algunos casos supervisado. Todo
acceso siempre debe ser mediado (autorizado) cada vez que se solicite este recurso, es decir, no
debe haber excepciones dentro de la gestión del control de acceso.

DISEÑO ABIERTO: En este principio de seguridad para el desarrollo de software se trata de


independizar el diseño del software de las técnicas de seguridad que se encuentran implementadas
para su defensa, de tal manera que si por alguna razón se hiciera una revisión del diseño general del
software las estrategias de seguridad no deben ser comprometidas.

MECANISMOS MÍNIMOS COMUNES: Se evita con este principio que se compartan mecanismos que
son comunes a uno o más usuarios o procesos si el usuario y el proceso poseen diferentes niveles de
privilegios.

ACEPTABILIDAD PSICOLÓGICA: En este principio se busca que las funciones de seguridad que se
implementen en el software sean de fácil uso y lo más transparentemente posible para el usuario
final.

ENLACE DÉBIL: Se propone con este principio que la seguridad de un sistema es tan fuerte como su
punto más débil. Sea este elemento el código, una interface o servicio.

Ing: Gonzalo Andrés Rojas

8
SCS

IGUALANDO LOS COMPONENTES: En este principio se estipula que la superficie de ataque no se


incrementa y nuevas vulnerabilidades no son introducidas por el hecho de promover la reutilización
de componentes del software, código y funcionalidad.

Ing: Gonzalo Andrés Rojas

9
SCS

A continuación, se mencionan los que deberían ser responsables de la socialización, implementación


y control de cambios de la metodología de desarrollo:

CARGO/ROL RESPONSABILIDADES

Implementar, socializar y mantener actualizada la metodología de desarrollo de desarrollo


Jefe de
seguro para que sea utilizada en todos los desarrollos que se emprendan dentro de la
Desarrollo
organización y sean exigidos a los proveedores externos tambien.

Comité de Realizar revisiones periódicas a la metodología con el fin de mantener actualizadas las
Desarrollo técnicas implementadas de acuerdo a los objetivos propuestos.

Realizar controles y aplicar las acciones necesarias para la correcta aplicación de la


Comité de TI
metodología.

Figura No. 5. Roles.

El Área de Desarrollo está normalmente conformada por ingenieros, técnicos y tecnólogos


encargados de elaborar, mejorar y mantener el software, utilizando como herramienta la metodología
de desarrollo y los recursos tecnológicos.

En esta dependencia se llevará a cabo los siguientes actividades:

1. Desarrollo de software a la medida con recursos propios


2. Desarrollo de software contratado con terceros
3. Mejora de los sistemas actualmente instalados
4. Corrección a fallas en los aplicativos

A continuación se presenta gráficamente la estructura del área de desarrollo y se menciona las


funciones que desempeñara cada uno de los roles encargados de la administración, coordinación,
elaboración y mantenimiento del software:

Gerente de Comite de
Proyectos Desarrollo

Jefe de
Proyectos

Coordinador de
Proyectos

Analista de Analista de Analista de


Proyectos Proyectos Proyectos

Ing: Gonzalo Andrés Rojas

10
SCS

Figura No. 6. Organigrama.

GERENTE DE PROTECTOS

1. Liderar los proyectos de desarrollo de software con énfasis en la seguridad de la información.


2. Verificar la viabilidad técnica de los proyectos.
3. Velar por la seguridad de la información durante todo el ciclo de desarrollo.

COMITÉ DE DESARROLLO

1. Identificar posibles riesgos al proyecto en cuanto la protección de la información.


2. Evaluar el contenido de la especificación de requerimientos.
3. Organizar, planear y priorizar los proyectos de desarrollo.
4. Realizar seguimiento, evaluaciones periódicas y aplicar medidas correctivas a los
requerimientos siempre que sea necesario.
5. Proponer metodologías de desarrollo seguro que sean adaptables a los requerimientos de la
organización.

JEFE DE PROYECTOS:

1. Dirigir los proyectos de desarrollo.


2. Planear, administrar y supervisar los proyectos de desarrollo de software de nuevos aplicativos
y/o mejoras a los sistemas de información existentes.
3. Interpretar las necesidades de los usuarios y diseñar las alternativas de solución para su
análisis.
4. Supervisar los proyectos de desarrollo y velar por la implementación de controles de seguridad
de la información.

COORDINADOR DE PROYECTOS:

1. Monitorizar todos los desarrollos en curso.


2. Coordinar las pruebas preliminares de aplicativos.
3. Actualizar su conocimiento para comprender mejor los riesgos de seguridad de la información.

ANALISTA DE PROYECTOS:

1. Generar el análisis y diseño detallado del sistema, basándose en los artefactos propuestos en
la metodología y considerando posibles riesgos de seguridad de la información.
2. Realizar la codificación y las pruebas preliminares al software.
3. Documentar los procedimientos que se encuentren bajo su responsabilidad

Ing: Gonzalo Andrés Rojas

11
SCS

El área de desarrollo debe contar con una metodología para el desarrollo de software seguro que
soporte y apoya los procesos de atención a incidencias, la construcción de nuevos desarrollos, la
ejecución de mejoras y desarrollos externos.

El uso de una metodología de desarrollo de software seguro permite asegurar la producción de


software de alta calidad y seguridad, que cumpla las necesidades de sus usuarios finales y que sea
realizado de acuerdo a los compromisos adquiridos.

La metodología recomendada por este documento es la siguiente:

Ing: Gonzalo Andrés Rojas

12
SCS

Especificación de
Requerimientos

Organización y
Planeación

Análisis de Seguridad
Requerimientos

Diseño de
Software

Construcción

Las Pruebas

Implantación de
Software

Mantenimiento
de Software

Figura No. 7. Desarrollo seguro.

El proceso de desarrollo está dividido en 8 fases, cada una con un propósito específico que
dependiendo del requerimiento deberán ser elaborados, la duración de cada fase depende del
personal involucrado en el proyecto y del producto a generar. En todas las fases del desarrollo se
tiene en cuenta la seguridad de la información.

La metodología de desarrollo seguro debe soportar tanto los desarrollos internos como los externos
requeridos, para cada uno de estos procesos se ejecutarán las fases o actividades necesarias, que
permitan construir nuevas aplicaciones seguras o mejorar el software en producción.

7.2.1 DESARROLLOS INTERNOS

7.2.1.1 FALLA Y/O INCIDENTE

Las fallas o incidentes se presentan por problemas en el código fuente de la aplicación los cuales
son clasificados por la mesa de ayuda y asignados para su solución al área de desarrollo.

7.2.1.2 NUEVO DESARROLLO O MEJORA

1. Nuevo desarrollo: Consiste en el proceso de crear o de implementar un nuevo producto o


servicio. Posteriormente se realiza un estudio del alcance, recursos para determinar su

Ing: Gonzalo Andrés Rojas

13
SCS

viabilidad, luego de ser aprobado por los directivos, se realiza la especificación de


requerimientos para realizar las actividades de desarrollo de software seguro.

2. Mejora: Es un cambio en la funcionalidad o adaptación del sistema, que permite ampliar la


capacidad u optimizar el funcionamiento del servicio prestado. Las mejoras son autorizadas
por los clientes internos de acuerdo a la política de autorización. La seguridad de la
información debe ser considerada en estas mejoras.

7.2.2 DESARROLLOS EXTERNOS

Dentro del desarrollo de los proyectos de tecnología se puede determinar la viabilidad de los
desarrollos externos o subcontratados con terceros para el logro de los objetivos de manera eficaz o
eficiente, de igual manera estos desarrollos deben cumplir con las especificaciones de la metodología
diseñadas para este propósito.

Responsabilidad del
Responsabilidad interna
Tercero
Etapas de la Metodología
Etapas Cumplimiento Etapas Cumplimiento

Opcional Opcional
1. Especificación de requerimientos

2. Organización y planeación Opcional Opcional

3. Análisis de requerimientos Opcional Opcional

4. Diseño de software Opcional Opcional

5. Construcción Obligatorio No aplica

6. Pruebas No aplica Obligatorio

7. Implantación No aplica Obligatorio

8. Mantenimiento Opcional Opcional

Figura No. 8. Desarrollo seguro externos.

Las casillas que se encuentran activas hacen referencia a las etapas de la metodología que
dependiendo de la necesidad y del tipo de cumplimiento serán ejecutadas.

Cumplimiento

1. Obligatorio: La ejecución de cada una de las etapas debe cumplirse ya que es necesario
para la correcta ejecución del proceso.

2. Opcional: Tanto el proveedor como la Entidad pueden participar en la elaboración de los


artefactos de cada una de las etapas donde el cumplimiento es opcional.

3. No aplica: Tanto el proveedor como la Entidad no intervienen en la etapa.

Ing: Gonzalo Andrés Rojas

14
SCS

La Metodología de desarrollo de software consta de ocho etapas: Especificación de Requerimientos,


Análisis, Diseño, Construcción, Pruebas, Implantación y Mantenimiento cada una se compone de
objetivos, roles de los participantes, artefactos y productos a generar. En cada etapa se realizan un
conjunto de acciones encaminadas a obtener determinados productos, como: especificaciones,
diagramas, código, plan de pruebas y documentos de soporte, etc. En todas las fases debe ser
considerado los riesgos sobre la información.

8.1.1 OBJETIVO

Identificar, describir y documentar el conocimiento necesario para producir un modelo de


especificación de requerimientos acorde a las expectativas del producto y las políticas del negocio.

8.1.2 ROLES DE LOS PARTICIPANTES

Cliente Interno:

1. Definir y especificar la necesidad o requerimiento del negocio.

Grupo de Organización y Métodos OyM

1. Apoyar en la documentación del requerimiento y garantizar la integridad con los demás


procesos del negocio.
2. Asesorar al Cliente Interno en la elaboración de los documentos para la especificación de
requerimientos.

Comité de Producto:

1. Evaluar, aprobar o rechazar los requerimientos presentados.


2. Ayudar a especificar las necesidades del requerimiento interdisciplinariamente.

Comité de Desarrollo:

1. Analiza la especificación de requerimientos.


2. Evaluar que las especificaciones se encuentren claras y completas.
3. Definir la viabilidad del desarrollo.

8.1.3 RECEPCIÓN DE DOCUMENTOS

El área de soporte y calidad atenderá la solicitud de requerimientos para elaboración de nuevos


productos, servicios, mejoras y desarrollos externos, además realizará el registro de las fallas:

Cuando se trate de un requerimiento de un nuevo producto, mejora y desarrollo externo, se deberán


recepcionar, clasificar y radicar los documentos elaborados por el Cliente Interno. Una vez sean
registrados en el sistema se entregaran al Comité de Desarrollo para su respectiva evaluación.

En la siguiente grafica se describe el proceso que conlleva la recepción de una falla, mejora, o un
nuevo requerimiento (Nuevo desarrollo o desarrollo externo) por el área de soporte y calidad.

Ing: Gonzalo Andrés Rojas

15
SCS

Usuario Tipo de Requerimiento Tipo de Recepción Responsable Area Soporte Responsable Area Desarrollo

Falla Mesa de Servicios Analista

Usuario

Mejora

Nuevo Mesa de Servicios


Desarrollo Comité Desarrollo
E.R

Cliente Interno

Desarrollo
Externo

Figura No. 9. Documentos.

8.1.4 DOCUMENTOS GENERADOS EN LA ETAPA DE ESPECIFICACIÓN DE


REQUERIMIENTOS

8.1.4.1 DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS

Para especificar los requerimientos se debe establecer un documento estándar que contenga la
descripción del requerimiento, modelo del proceso u operaciones, el diseño de las pantallas, los
formatos de impresión (reportes, información), las restricciones del sistema, la dinámica contable y los
diagramas de flujo de cada uno de los procesos identificados (Interacción del sistema).

8.1.4.2 DOCUMENTO MATRIZ DE VALIDACIÓN

La Matriz de validación contendrá las acciones de prueba a ejecutar, los resultados esperados y los
resultados obtenidos del sistema tanto a nivel operativo como a nivel contable. Los casos de prueba
permiten validar que el aplicativo desarrollado realice las funciones para las que ha sido creado en
base a los requerimientos del Cliente interno y mantenga la seguridad de la información.

8.1.4.3 DOCUMENTO DE DISEÑO DE REPORTES

La elaboración de los reportes será solicitada por el Cliente interno por medio del formato de diseño
de reportes, el documento contendrá información acerca de los campos, filtros, niveles de agrupación,
periodicidad, tipo de presentación y los perfiles que tendrán acceso a los reportes. Su función es dar

Ing: Gonzalo Andrés Rojas

16
SCS

a conocer al personal de desarrollo cuales son los datos, el orden, el formato que el Cliente interno
desea aplicar en el reporte, etc.

8.1.4.4 DOCUMENTO MANUAL DE USUARIO

El manual de usuario va anexo al documento de especificación de requerimientos, en él se detallan


todas y cada una de las características que tienen las interfaces, la forma de acceder al aplicativo y
reúne la información, normas y documentación necesaria para que el usuario utilice adecuadamente
el sistema.

8.1.5 PRODUCTOS DE LA ETAPA

1. Especificación de requerimientos
2. Matriz de evaluación
3. Diseño de reportes
4. Manual de usuario
5. Actas

Ing: Gonzalo Andrés Rojas

17
SCS

8.1.6 ORGANIZACIÓN Y PLANEACIÓN

8.1.7 OBJETIVO

Proporcionar los elementos necesarios que ayuden a soportar el desarrollo del proyecto, asegurando
que puede ser llevado a cabo bajo en el tiempo estimado y con los recursos disponibles.

Objetivos Específicos

1. Delimitar el requerimiento
2. Identificar los riesgos a la seguridad de la información
3. Estimar los costos y recursos

8.1.8 ROLES DE LOS PARTICIPANTES

Comité de Desarrollo:

1. Realizar una adecuada planeación y programación de recursos, tiempo y responsabilidades.

2. Organizar y priorizar los requerimientos que llegan al Área de Desarrollo.

3. Considerar la protección de la información y velar porque en todo el proceso de desarrollo se


mantenga la seguridad de la información.

4. Elabora el documento de organización y planeación, en él se analizará la viabilidad, el


alcance, el impacto, se incluirá la estimación de costos, recursos, se anexará el cronograma
de actividades.

5. Tendrá la responsabilidad de medir y evaluar el desempeño de las actividades propuestas en


el cronograma de actividades.

6. Asigna el requerimiento al Analista

Organización y Métodos

Analizar y ajustar los procedimientos y adelantar la misión cultural del proyecto.

DOCUMENTOS GENERADOS EN LA ETAPA DE ORGANIZACIÓN Y


PLANEACIÓN

8.1.9.1 DOCUMENTO DE ORGANIZACIÓN Y PLANEACIÓN

Establece las estrategias, la organización y los procedimientos requeridos para la implementación de


requerimientos en el área de desarrollo. Contiene el análisis donde se comprueba la viabilidad técnica
de la solución, la planificación donde se elabora el cronograma de actividades y el control de avance
donde se mide y evalúa el desempeño de las actividades planteadas para dar solución al
requerimiento.

8.1.9.2 REUNIÓN PARA EVALUACIÓN DEL REQUERIMIENTO

El comité de desarrollo es el encargado de revisar y aprobar el contenido del documento de


requerimientos, teniendo en cuenta variables como el alcance, la viabilidad, el impacto, seguridad de
la información entre otros aspectos.. El comité también tendrá la responsabilidad de analizar y

Ing: Gonzalo Andrés Rojas

18
SCS

aprobar la matriz de validaciones, el manual de usuario y el documento de diseño de reportes. Si


durante la revisión se encuentran correcciones por realizar, estos serán devueltos al usuario para que
el realice las correspondientes modificaciones, con el objetivo de obtener una información clara y
concisa.

8.1.10 PRODUCTOS DE LA ETAPA

1. Organización y planeación
2. Análisis del requerimiento
3. Alternativa de desarrollo
4. Estimación de recursos
5. Cronograma de actividades
6. Control de avance

8.2.1 OBJETIVO

Identificar y comprender cuál es el problema a resolver, verificado el entorno en el cual se encuentra


el requerimiento, de tal manera que se obtenga la información necesaria y suficiente para darle
solución.

8.2.2 ROLES DE LOS PARTICIPANTES

Comité Desarrollo: Evalúa, coordina, sugiere, aprueba o rechaza el análisis presentado por el
analista de desarrollo, como posible solución al requerimiento asignado.

Organización y métodos: Liderar y trabajar en forma conjunta con el grupo técnico en el análisis de
los métodos de trabajo existentes y en la implantación de las modificaciones que permitan obtener la
mayor eficiencia en el uso de los recursos tanto humanos como materiales con que están dotadas las
unidades operativas o funcionales.

Analista de desarrollo: Realiza el análisis (documento de análisis de requerimientos) para el nuevo


desarrollo, mejora o falla solicitada

8.2.3 DOCUMENTOS GENERADOS EN LA ETAPA DE ANÁLISIS DE


REQUERIMIENTOS

8.2.3.1 DIAGRAMA DE CASOS DE USO

El analista realizará el diagrama de casos de uso para describir las funciones que deberán realizar los
usuarios del sistema, cada caso de uso especifica la interacción entre el actor y la aplicación. La
razón de ser de este tipo de diagrama se concentra en lo que hará el sistema, no como lo hace.

Los diagramas de caso de uso se elaboran generalmente en la etapa de análisis de software, son
creados para facilitar la comunicación entre los programadores y el personal involucrado en los
proyectos desde etapas iniciales del ciclo de vida.

8.2.3.2 CASOS DE USO EXTENDIDO

Explican el comportamiento paso a paso de un caso de uso, los casos de uso extendidos describen el
modo en el que interactúa un usuario con el sistema desde que inicia, realiza los procesos y finaliza la
sesión. Al describir un caso de uso se debe tener en cuenta toda la secuencia de acciones necesarias

Ing: Gonzalo Andrés Rojas

19
SCS

para cumplir la funcionalidad que este requiere. Este punto se debe realizar en el caso de que los
requerimientos lleguen sin especificación de requerimientos.

8.2.4 APROBACIÓN DEL DOCUMENTO DE ANÁLISIS

El comité de desarrollo deberá verificar que la estructura del documento de análisis se encuentre
acorde al contenido de la plantilla elaborada para esta etapa y que los requerimientos y los casos de
uso describan la funcionalidad requerida por el usuario. Cuando el documento sea aprobado el
analista podrá continuar con la etapa de diseño.

8.2.5 PRODUCTOS DE LA ETAPA

ü Análisis de requerimientos
ü Diagrama de casos de uso
ü Especificación de los casos de uso

Ing: Gonzalo Andrés Rojas

20
SCS

8.3.1 OBJETIVO

Aplicar las distintas técnicas y principios para establecer la forma en la que el sistema dará solución
a los requerimientos identificados en la etapa de análisis. Durante el desarrollo de esta etapa se
elaborará el esquema físico de la base de datos, se elegirá el lenguaje de programación, se diseñara
la arquitectura a utilizar y se elaborará el diccionario de datos.

8.3.2 ROLES DE LOS PARTICIPANTES

Comité de desarrollo: Evaluar, Coordinar, aprobar o rechazar el diseño presentado por el analista
de desarrollo, como posible solución al requerimiento asignado

Analista de desarrollo:

1. Realizar el Diseño de software a los diferentes requerimientos


2. Mantener actualizada toda la documentación relacionada con el requerimiento en desarrollo

8.3.3 DOCUMENTOS GENERADOS EN LA ETAPA DE DESARROLLO DE


SOFTWARE

8.3.3.1 HERRAMIENTAS INCLUIDAS EN EL PROYECTO

En este ítem se deberá anexar una descripción explicativa de las herramientas empleadas o a
emplear durante el análisis, diseño, implementación y pruebas de los diferentes requerimientos a
desarrollar.

Para realizar la descripción de la herramienta se deberán definir las siguientes características:

Definir las características del software como:

§ Proveedor
§ Tipo de licenciamiento
§ Versión.

8.3.3.2 ARQUITECTURA DEL SISTEMA

La Arquitectura del Software es el diseño de más alto nivel de la estructura de una aplicación, nos
permite identificar los elementos, las relaciones y la forma de como interactúa el sistema con su
entorno.

El analista deberá diseñar el bosquejo de la arquitectura solamente cuando la aplicación requiera el


diseño de una estructura nueva, o la existente interactúe con sistemas externos, requiera interfaces
adicionales o dependa de otros procesos para su ejecución.

La arquitectura debe detallar la estructura del sistema, las relaciones que tienen sus elementos con sí
mismos y con los que hacen parte de su entorno. Cuando se elabore el bosquejo, se deberá
especificar el punto exacto donde ocurre la interacción con los sistemas, interfaces, bases de datos o
procesos externos.

El siguiente ejemplo presenta el diseño de una aplicación que adopta una arquitectura en capas
donde el objetivo primordial es la separación de la lógica de presentación de la lógica de negocios y

Ing: Gonzalo Andrés Rojas

21
SCS

la lógica de negocios de la lógica de acceso a datos, además se presenta la estructura de un web


service y la interacción de este con la aplicación. La aplicación hace uso de la funcionalidad
proporcionada por un servicio externo (Web service) para desarrollar operaciones propias del
sistema.

Arquitectura de la aplicación

Web Service
Usuarios

Lógica de Presentación

Web Lógica de Negocios


Service

Lógica de Negocios
Lógica Acceso Datos

Lógica Acceso Datos


SGBD

SGBD

Figura No. 10. Arquitectura.

8.3.3.3 DIAGRAMA ENTIDAD RELACIÓN

Es un modelo de datos de alto nivel donde se representa gráficamente las entidades (nombre de
objetos del mundo real), las propiedades y relaciones que hay entre cada uno de los objetos, este
diagrama es elaborado con el objetivo de representar la estructura lógica general de la base de datos.

8.3.3.4 DICCIONARIO DE DATOS

El diccionario de datos es un documento en el que se especifica la naturaleza y descripción de toda la


información que deberá ser almacenada en una base de datos, este artefacto es acompañado del
Diagrama Entidad Relación.

El objetivo del diccionario de datos es dar precisión sobre los metadatos evitando así malas
interpretaciones y/o ambigüedades en etapas posteriores. En el diccionario se detalla la estructura de
las Entidades, sus campos, tipos de datos, llaves primarias, foráneas, índices, etc.

8.3.3.5 GLOSARIO DE TÉRMINOS

Se define como la lista de términos que los posibles lectores del documento pueden desconocer.

El glosario debe ser elaborado de acuerdo con las siguientes recomendaciones:

Ing: Gonzalo Andrés Rojas

22
SCS

§ Presentar alfabéticamente las palabras o términos básicos y compuestos utilizados en el


documento.
§ Incluir el significado de cada una de las palabras haciendo referencia al tema tratado en el
documento.

8.3.4 APROBACIÓN DEL DOCUMENTO DE DISEÑO

El comité de desarrollo deberá verificar que la estructura del documento de diseño se encuentre
acorde al contenido de la plantilla elaborada para esta etapa, que el diagrama Entidad relación
contenga las Entidades relevantes (con sus interrelaciones y atributos) para el sistema y el diccionario
de datos describa las características de la información que deberá ser almacenada en una base de
datos.

8.3.5 PRODUCTOS DE LA ETAPA

1. Documento de diseño de software


2. Herramientas a utilizar
3. Arquitectura del sistema
4. Diagrama entidad relación
5. Diccionario de datos

Ing: Gonzalo Andrés Rojas

23
SCS

8.3.6 OBJETIVO

Codificar en un lenguaje de programación adecuado las especificaciones que se realizaron en diseño


del sistema. Durante esta fase todos los componentes, características y requisitos deben ser
implementados, integrados y probados, obteniendo una versión aceptable del producto.

8.3.7 ROLES DE LOS PARTICIPANTES

Analista de Desarrollo:

1. Convertir el análisis y diseño del software en código fuente.


2. Documentar la solución
3. Realizar las pruebas preliminares a los desarrollos.

Coordinador de desarrollo
ü Coordinar y evaluar el desarrollo o la mejora elaborada por el analista

8.3.8 DOCUMENTOS GENERADOS EN LA ETAPA DE CONSTRUCCIÓN DE


SOFTWARE

8.3.8.1 ELABORACIÓN DEL PLAN DE DESARROLLO

El Plan de Desarrollo del Software es elaborado con el fin de proveer una visión global del enfoque de
desarrollo propuesto por el programador, busca proporcionar de manera oportuna la información
necesaria para evaluar y controlar la implementación de todo requerimiento o nueva funcionalidad.

8.3.8.2 ELABORACIÓN DEL MANUAL TÉCNICO

El manual técnico incluye la descripción detallada de los módulos y programas que constituyen el
sistema, las funciones o procedimientos que se utilizan y los parámetros que se requieren, así como
la estructura de las tablas de la base de datos, etc. El analista de desarrollo deberá elaborar el
manual técnico por cada uno de los desarrollos a su cargo.

8.3.9 DESCRIPCIÓN DE LA ETAPA

El proceso de construcción consiste en traducir el diseño lógico de un sistema a código fuente; para
ello, se utilizará un lenguaje de alto nivel elegido en anteriores etapas teniendo en cuenta el propósito
del requerimiento. Para cada uno de los lenguajes de programación existen documentos o estándares
para que el proceso se realice de manera adecuada. Durante la programación es de gran importancia
documentar todos los objetos elaborados con la finalidad de realizar el mantenimiento del software en
posteriores etapas y además se deberán realizar las pruebas preliminares las cuales buscan detectar
posibles errores en la aplicación antes de pasar el desarrollo hacia otras etapas.

8.3.10 PRODUCTOS DE LA ETAPA

1. Plan de desarrollo
2. Manual técnico
3. Formato de paso
4. Archivos de código fuente

Ing: Gonzalo Andrés Rojas

24
SCS

8.4.1 OBJETIVO

Garantizar el adecuado funcionamiento del sistema a través de la ejecución de diferentes tipos de


prueba a realizar sobre el software elaborado.

8.4.2 ROLES DE LOS PARTICIPANTES

Coordinador de Desarrollo:

Evaluar, aprobar o rechazar el plan de pruebas presentado por el analista.

Analista de desarrollo

1. Elaborar el plan de pruebas


2. Complementar la matriz de validaciones en caso de ser requerido.
3. Definir la estrategia y tipos de pruebas a realizar dependiendo de las características del
desarrollo.

8.4.3 DOCUMENTOS GENERADOS EN LA ETAPA DE PRUEBAS DE SOFTWARE

8.4.3.1 ELABORACIÓN DEL PLAN DE PRUEBAS

El analista a partir de la matriz de validaciones elaborada por el Cliente Interno debe diseñar un plan
de pruebas preliminares detallado definiendo el alcance, los requerimientos hardware o software,
personal, estrategias de las pruebas detalladas por perfil, entre otras.

El documento es requisito esencial para el paso a pruebas del requerimiento. El Plan pruebas ofrece
un resumen de los elementos de prueba, este resumen debe incluir información sobre los objetivos, el
enfoque general, y los casos de prueba a realizar, etc.

8.4.3.2 MANTENIMIENTO DEL MANUAL DE USUARIO

El responsable de las pruebas debe actualizar el manual usuario una vez hayan culminado
satisfactoriamente las pruebas generales del software.

8.4.4 EJECUCIÓN DE LAS PRUEBAS

Con el fin de garantizar que el sistema ha sido desarrollado correctamente, el responsable de las
pruebas debe realizar las debidas pruebas funcionales, de sistema, de integridad, confiabilidad, de
confidencialidad y de rendimiento, que garanticen el correcto desempeño del sistema bajo el mayor
número de situaciones posibles a las que se pueda enfrentar.

8.4.4.1 REQUISITOS PARA LA EJECUCIÓN DE LAS PRUEBAS

Cuando el sistema esté listo y se haya elaborado el plan de pruebas, el desarrollador debe diligenciar
el formato de paso que contiene la información del proceso a realizar, los objetos y su ubicación,
descripción de la solución, responsables del desarrollo, aprobación y paso a producción. Una vez
diligenciado debe entregarlo al área de soporte y calidad quienes tienen la responsabilidad de
ejecutar esta tarea.

El área de soporte y calidad debe elegir el o los usuarios idóneos para realizar este proceso
teniendo en cuenta que: debe tener amplios conocimientos sobre la aplicación desarrollada, así se

Ing: Gonzalo Andrés Rojas

25
SCS

garantiza que se cubran la mayor cantidad de casos de prueba y se verifica que el producto cumpla
satisfactoriamente con los requerimientos iniciales. Además, se debe definir la organización del
Equipo de Pruebas teniendo en cuenta los siguientes ítems:

1. Identificar, definir roles y responsabilidades


2. Seleccionar e instruir a los responsables de la prueba

8.4.4.2 PREPARACIÓN PARA LAS PRUEBAS

Se debe establecer el ambiente adecuado para la ejecución de las pruebas teniendo en cuenta las
siguientes actividades:

1. Trasladar e impactar el software al ambiente de pruebas


2. Preparar los datos de prueba
3. Tener en cuenta las consideraciones iniciales incluidas en el plan

8.4.4.3 EJECUCIÓN

En caso de encontrar fallas en la funcionalidad o errores en los resultados es responsabilidad del


personal a cargo clasificarlas y registrarlas en un documento que será analizado y evaluado por el
comité de pruebas quienes las resumirán e incluirán en el informe de reportes de pruebas.

El reporte será enviado al comité de desarrollo quien valorara cada una de las observaciones y
elaborará un acta con los cambios a realizar por el área y las devolverá al comité de pruebas para su
conocimiento.

Si los cambios a realizar implican una modificación o una adición a los requerimientos iniciales el
Cliente Interno debe elaborar un acta donde especifique el propósito del requerimiento.

Una vez finalicen las pruebas al software, el responsable de las pruebas debe diligenciar el formato
de paso con los cambios realizados en la presente etapa y con las firmas de aprobación
correspondientes para el paso a producción del software.

8.4.4.4 EJECUCIÓN DE LAS MEJORAS, NUEVOS REQUERIMIENTOS Y CORRECCIÓN


DE FALLAS

El analista debe realizar las correcciones, implementar los nuevos requerimientos y las mejoras al
software apoyándose en las etapas de la metodología de desarrollo según el análisis que se realice
para cada una de las tareas definidas.

8.4.5 PRODUCTOS DE LA ETAPA

1. Formato de paso
2. Plan de pruebas
3. Actualización de documentos

Ing: Gonzalo Andrés Rojas

26
SCS

8.5.1 OBJETIVO

Asegurar que el paso del desarrollo se lleve a cabo de acuerdo a los pasos descritos en el plan de
implantación, con el propósito de disminuir los problemas que se presentan durante la ejecución de
esta actividad.

8.5.2 ROLES DE LOS PARTICIPANTES

Responsable área de producción:

1. Realiza el paso del desarrollo a pruebas.


2. Determinar la documentación, entregables y artefactos requeridos para el paso.
3. Colocar en producción todos los objetos requeridos.
4. Informar sobre los inconvenientes encontrados en el paso y de ser necesario solicitar los
objetos para la restauración del sistema al estado anterior.

Administrador de Base de datos:

1. Administrar la estructura de la Base de Datos.


2. Definir procedimientos de respaldo y de recuperación de la BD.
3. Supervisar el desempeño de las nuevas aplicaciones sobre la base de datos.

Organización y Métodos: Participar en la implantación del sistema soportando las recomendaciones


de cambios funcionales, coordinando o dirigiendo la producción de los nuevos formularios y
capacitando a los clientes en el manejo de los nuevos procedimientos.

8.5.3 DOCUMENTOS GENERADOS EN LA ETAPA DE IMPLANTACIÓN DE


SOFTWARE

8.5.3.1 ELABORACIÓN DEL PLAN DE IMPLANTACIÓN

El plan de implantación contiene los requerimientos, lineamientos y responsables dispuestos para


ejecutar cada una de las actividades descritas en el documento. Este plan tiene el objetivo de
disminuir los fallos a la hora de impactar los diferentes objetos y archivos al sistema en producción.

La implantación se clasifica en cuatro categorías, que se deben identificar para determinar el tipo, el
impacto y complejidad del plan a ejecutar:

Método Directo: el objetivo de este método es abandonar el sistema anterior y adoptar directamente
el nuevo sistema.

Método Paralelo: el objetivo de este método es poner en funcionamiento el nuevo sistema en paralelo
con el antiguo, esto para hacer un seguimiento de la eficiencia y eficacia del nuevo sistema.

Método piloto: en este método el nuevo sistema se pone en funcionamiento en una parte de
organización, si no genera eventualidades o fallas será implantado en el resto de las áreas.

Método en Fases: en este método el sistema se divide en partes o fases y no se puede pasar a la
siguiente fase sin haber finalizado en su totalidad la fase actual.

8.5.4 PRODUCTOS DE LA ETAPA

Ing: Gonzalo Andrés Rojas

27
SCS

1. Plan de implantación

8.6.1 OBJETIVO

Garantizar el funcionamiento de un sistema en producción, mejorándolo, adaptándolo o corrigiendo


problemas que sean detectados durante su operación. En la fase de mantenimiento es importante
considerar los posibles riesgos a la información.

8.6.2 ROLES DE LOS PARTICIPANTES

Comité de TI

1. Crear una solicitud de cambio


2. Evaluar, aprobar, rechazar o sugerir la modificación, actualización o adaptación del software
que se encuentra en el ambiente de producción.

Cliente Interno

1. Crear una solicitud de cambio

Analista de proyectos

1. Implementar el cambio, actualización o adaptación solicitada cumpliendo con la metodología


y estandartes establecidos por el área de desarrollo.

8.6.3 DOCUMENTOS GENERADOS EN LA ETAPA DE MANTENIMIENTO DE


SOFTWARE

8.6.3.1 ELABORACIÓN DEL DOCUMENTO DE MANTENIMIENTO DE SOFTWARE

El comité de desarrollo, comité de pruebas, comité de soporte, comité de TI o el dueño del negocio
definirán durante las reuniones que realizaran periódicamente cuales son las mejoras, cambios o
adaptaciones a realizar sobre el software de la Entidad teniendo en cuenta los siguientes tipos de
mantenimiento:

ü Mantenimiento Correctivo

El objetivo del mantenimiento correctivo es identificar y eliminar los posibles defectos o fallas
del sistema en producción.

ü Mantenimiento Preventivo

Surge cuando se realizan modificaciones al software para mejorar sus propiedades o añadir
características adicionales sin alterar su funcionamiento.

El mantenimiento de software se documentará en el formato de mantenimiento de software que


contiene los pasos o actividades que se deben seguir para la implementación de cambios,
adaptaciones y corrección de fallas de los aplicativos en producción, de tal manera que se garantice
que estos se hagan de la forma más eficiente y segura posible, cumpliendo con las fases de la
metodología de desarrollo y asegurando la calidad de los sistemas en producción.

Ing: Gonzalo Andrés Rojas

28
SCS

8.6.4 ETAPAS DEL MANTENIMIENTO DE SOFTWARE

La fase de mantenimiento de software involucra cambios al software para corregir defectos


encontrados durante su uso o la adición de nueva funcionalidad mejorando la usabilidad del software,
para ello se ejecutaran las siguientes etapas:

Mantenimiento
de Software

Análisis de
Requerimientos

Seguridad
Diseño de
Software

Construcción

Pruebas

Implantación de
Software

Figura No. 11. Desarrollo seguro.

8.6.5 PRODUCTOS DE LA ETAPA

ü Documento de mantenimiento de software

Ing: Gonzalo Andrés Rojas

29
SCS

Ing: Gonzalo Andrés Rojas

30
SCS

ANEXOS

Anexo No. 1 Etapas de la metodología de desarrollo seguro.

Mesa Ayuda Comite Producción Analista de Desarrollo Personal Pruebas Personal Producción

especificación Requerimientos
Soporte

Matriz Validación Diseño Reportes

Manual Usuario

Analisis Requerimientos

Acta Aprobación Diseño Software

Calidad y Control Interno


Desarrollo

Plan Desarrollo

Organización Planeación Construcción

Manual Técnico

Plan Pruebas Formato Paso

Pruebas
Calidad

Soporte Actualización
Pruebas Manual
Usuario

Formato Paso

Evaluación, Verificación
Indicadores Gestión
Producción

SLA

Acciones:
Preventiva, Correctivas Plan Implantación
y de Mejora

Ing: Gonzalo Andrés Rojas

31
SCS

Anexo No. 2. Riesgos.

Anexo No. 3. ISO 27001:2013 A.14

A.14 ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN Nivel Madurez

A.14.1 Requisitos de seguridad de los sistemas de información


A.14.1.1 Análisis y especificación de los requisitos de seguridad
A.14.1.2 Seguridad de las aplicaciones en redes públicas
A.14.1.3 Protección de aplicaciones con servicios transaccionales
A.14.2 Seguridad en los procesos de desarrollo y soporte
A.14.2.1 Política de desarrollo seguro
A.14.2.2 Procedimientos de control de cambios
A.14.2.3 Revisión tecnica de las aplicasiones despues de los cambios en los sistema de operativos
A.14.2.4 Restricciones en los cambios a los paquetes de software
A.14.2.5 Principios de ingeniería para sistemas seguros
A.14.2.6 Ambientes de desarrollo seguro
A.14.2.7 Desarrollo contratado externamente
A.14.2.8 Pruebas de seguridad de los sistemas
A.14.2.9 Pruebas de aceptación de los sistemas
A.14.3 Datos de prueba
A.14.3.1 Protección de los datos de prueba

Ing: Gonzalo Andrés Rojas

32
SCS

Business Continuity Institute (2013) Good Practice Guidelines: A guide to global good practice in business
continuity, Business Continuity Institute, Caversham.

Disaster Recovery Institute International (DRII) (2012) Professional Practices for Business Continuity
Practitioners, DRII, New York.

ISO 22301 (2012) – Societal security – Business continuity management systems – Requirements

ISO 22301 (2012) – Societal security – Business continuity management systems – Guidance

ISO 22301 (2012) – Societal security – Terminology

ISO 27001:2013 Information security.

www.sans.org

www.nist.org

www.microsoft.com

Ing: Gonzalo Andrés Rojas

33
SCS

Ing: Gonzalo Andrés Rojas

34

También podría gustarte