Vous êtes sur la page 1sur 26

CARRERA DE INGENIERÍA DE

SISTEMAS - UPS INGENIERÍA DE


SOFTWARE - 2016

CAPÍTULO 06: CONSTRUCCIÓN DE SOFTWARE


ING. MAURICIO ORTIZ OCHOA
MORTIZO@UPS.EDU.EC
CONSTRUCCIÓN

 Es la creación de software productivo y significativo a través de los procesos de:


 Codificación
 Verificación
 Pruebas unitarias
 Pruebas de integración
 Depuración de errores.
 La facilidad con la que se pueden realizar proyectos de software enfocándose solo en los aspectos de
la construcción pueden afectar la calidad.

SOFTWARE CONSTRUCTION 2
ACTIVIDADES DE LA CONSTRUCCIÓN

SOFTWARE CONSTRUCTION 3
CONSTRUCCIÓN Y GESTIÓN DE PROYECTOS
 Ya que la Construcción genera la mayor parte
de artefactos configurables se necesita manejar
un proyecto de software: Alcance, Presupuesto,
Cronograma
 Herramientas
 Jira
 PMD
 SubversionEdge
 BitBucket

SOFTWARE CONSTRUCTION 4
SOFTWARE CONSTRUCTION 5
IMPORTANCIA DE LA CONSTRUCCIÓN

 Es la etapa más larga del proceso de desarrollo de software.


 Es la actividad central del proceso de desarrollo de software.
 Con un enfoque en la construcción, la productividad del programador individual puede mejorar
enormemente.
 El código fuente, es a menudo la única descripción exacta del software.
 Construction is the only activity that’s guaranteed to be done.
 La construcción es la única actividad que debe garantizarse.
 La calidad de la construcción afecta considerablemente a la calidad del producto de software

SOFTWARE CONSTRUCTION 6
 "By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more
advanced problems, and in effect increases the mental power of the race. Before the introduction of the
Arabic notation, multiplication was difficult, and the division even of integers called into play the highest
mathematical faculties.... Our modern power of easy reckoning with decimal fractions is the almost
miraculous result of the gradual discovery of a perfect notation”
 Alfred North Whitehead

SOFTWARE CONSTRUCTION 7
TIPOS DE SISTEMAS I

 Sistemas de Negocios
 Sitios de Internet
 Sitios de Intranet
 Gestión de Inventarios
 Sistemas de Gestión de Información
 Sistemas de Nómina

SOFTWARE CONSTRUCTION 8
TIPOS DE SISTEMAS II

 Sistemas Dedicados
 Juegos
 Herramientas de software
 Servicios web
 Sistemas Críticos
 Software aeronáutico / automotriz
 Software médico
 Sistemas Operativos
 Paquetes de software

SOFTWARE CONSTRUCTION 9
DECISIONES CLAVES EN LA CONSTRUCCIÓN

 Elección del lenguaje de programación


 Convenciones de codificación
 Localización en la onda tecnológica
 Selección de las mejores practicas de construcción

SOFTWARE CONSTRUCTION 10
ELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN I
 Ada
 (Jean Ichbiah, 1980) Militar, Espacio, Aeronaútica
 Assembly
 Lenguaje de bajo nivel, Específico del procesador
 C
 (Dennis M. Ritchie, 1972) Ventaja de portabilidad
 C++
 ( Bjarne Stroustrup, 1980) Objetos
 C#
 (Microsoft, 2000) .NET
 Cobol
 (CODASYL, 1959) COmmon Business-Oriented Language
 Fortran
 (IBM, 1957) Formula Translating System
 Java
 (James Gosling & Sun Microsystems, 1995)

SOFTWARE CONSTRUCTION 11
ELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN II

 JavaScript
 (Netscape, 1995) Interpretado
 Pascal
 (Niklaus Wirth, 1970) Programación estructurada
 Perl
 (Larry Wall , 1987) Multiparadigma
 PHP
 (Rasmus Lerdorf, 1995) contenido web dinámico
 Phyton
 (Guido van Rossum, 1991) Multiparadigma
 Sql
 (Donald D. Chamberlin & Raymond F. Boyce, 1970) Consultas
 Visual Basic
 (Alan Cooper, 1993) Eventos

SOFTWARE CONSTRUCTION 12
Tipo de Programa Recomendado No recomendado
Línea de Comandos Cobol, Fortran, SQL -
Desarrollo Java, Perl, Python Assembler, C#,Visual
multiplataforma Basic
Manipulación de SQL, Visual Basic Assembler, C
Base de Datos
Fácil mantenimiento C++, Java,Visual Assembler, Perl
Basic
Ejecución rápida Assembler, C, C++, JavaScript, Perl,
Visual Basic Python

Tiempo real C, C++, Assembler C#, Java, Python, Perl,


Visual
Basic
Programas Seguros C#, Java C, C++

Desarrollo Web C#, Java, JavaScript, Assembler, C


PHP,Visual Basic
SOFTWARE CONSTRUCTION 13
ÍNDICE TIOBE

SOFTWARE CONSTRUCTION 14
CONVENCIONES DE PROGRAMACIÓN

 Calidad es la relación entre la integridad conceptual de la arquitectura y su implementación a bajo nivel.


 El nivel interno son los identificadores de: variables, nombres de clases, nombres de rutinas,
convenciones de formato y convenciones documentación.
 Cualquier gran programa requiere una estructura de control que unifique sus detalles de programación.

SOFTWARE CONSTRUCTION 15
SOFTWARE CONSTRUCTION 16
TENDENCIAS DE GARTNER

SOFTWARE CONSTRUCTION 17
SOFTWARE CONSTRUCTION 18
FUNDAMENTOS DE CONSTRUCCIÓN

SOFTWARE CONSTRUCTION 19
SELECCIÓN DE LAS MEJORES PRACTICAS DE CONSTRUCCIÓN

 Codificación
 Se ha definido convenciones?
 Se ha definido prácticas implícitas de arquitectura, condiciones de errors, seguridad, etc.?
 Se ha identificado su situación en la ola tecnológica?
 Se ha visto la manera de extender el lenguaje en lugar de limitarse a lo que el lenguaje nos brinda?
 Equipo de Trabajo
 Se ha definido un procedimiento de integración de Código. Es decir, se ha definido los pasos específicos que
debe realizer un programador antes de verificar el código en las fuentes principals?
 Los programadores trabajaran en pares, individualmente o en combinación?

SOFTWARE CONSTRUCTION 20
SELECCIÓN DE LAS MEJORES PRACTICAS DE CONSTRUCCIÓN

 Aseguramiento de la Calidad
 Los programadores escriben los casos de prueba antes de construir el código?
 Los programadores inspeccionan el código de otros?
 Herramientas
 Se ha selecionado una herramienta de control de versiones?
 Ha seleccionado lenguaje y versiones de lenguajes, compiladores, librerías, etc.?
 Se ha decidido o no utilizer características del lenguaje en versions no estándares?
 Ha identificado y definido herramientas para de edición de programas, refactorización, depurador, test
framework, comprobador de sintaxis, etc.

SOFTWARE CONSTRUCTION 21
CALIDAD DE LAS CLASES I

 Abstracción
 Dispone de datos Abstractos
 Tiene la clase un propósito central y su nombre lo demuestra?
 Se puede tratar a la clase como una caja negra?
 Los servicios de la clase son lo suficientemente completos para que otras clases no tengan que inmiscuirse con sus
datos internos?
 Se ha podido trasladar información relacionada fuera de la clase?
 Se ha pensado en la subdivisión de la clase?
 Encapsulamiento
 La clase evitar exponer datos de los miembros?
 Se esconde los detalles de la implementación de otras clases tanto como lo permita el lenguaje de programación?
 Es la clase independiente de las otras clases? Baja cohesión?

SOFTWARE CONSTRUCTION 22
CALIDAD DE LAS CLASES II

 Herencia
 La herencia es usada ​sólo para modelar relaciones?
 La documentación de la clase describe la estrategia de herencia?
 Las interfaces comunes, los datos y el comportamiento se encuentra lo más alto posible en el árbol de herencia?
 Todos los miembros de datos de la clase base privada en lugar de protegerse?
 Otras cuestiones de aplicación
 Contiene la clase siete atributos de datos o menos?
 La clase tiende a minimizar las llamadas de métodos a otras clases?
 Colabora la clase con otras clases sólo en la medida en que sea absolutamente necesario?
 Todos los datos miembro se inicializan en el constructor?
 Cuestiones específicas del lenguaje
 ¿Ha investigado las cuestiones específicas del lenguaje en lo concerniente a las clases?

SOFTWARE CONSTRUCTION 23
CALIDAD EN LAS RUTINAS (PROCEDIMIENTOS, MÉTODOS,
FUNCIONES) I

 Cuestiones principales
 Es suficiente la razón para la creación de la rutina?
 Todas las partes de la rutina interactúan solo en el entorno de la misma?
 El nombre de la rutina es descriptivo en concordancia con un verbo o el valor de retorno?
 ¿Se han establecido convenios de denominación para las operaciones comunes?
 ¿La rutina tiene una fuerte cohesión interna?
 Es la longitud de la rutina determinada por su función y la lógica?

SOFTWARE CONSTRUCTION 24
CALIDAD EN LAS RUTINAS (PROCEDIMIENTOS, MÉTODOS,
FUNCIONES) II

 Cuestiones de paso de parámetros


 La lista de parámetros de la rutina, tomada en su conjunto, una abstracción de interfaz consistente?
 El orden de los parámetros coincide con rutinas similares?
 Se documentan los supuestos de la interfaz?
 La rutina tiene siete o menos parámetros?
 Se utiliza cada parámetro de entrada?
 Se utiliza cada parámetro de salida?
 La rutina evita utilizar parámetros de entrada como variables de trabajo?

SOFTWARE CONSTRUCTION 25
REFERENCIAS

 S. McConnell, Code Complete: A Practical Handbook of Software Construction, Microsoft Press,


second ed., 2004.
 The Software Engineering Body of Knowledge (SWEBOK) Software Engineering Coordinating
Committee , IEEE Computer Society.

SOFTWARE CONSTRUCTION 26

Vous aimerez peut-être aussi