You are on page 1of 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 .

Presupuesto. Cronograma  Herramientas  Jira  PMD  SubversionEdge  BitBucket SOFTWARE CONSTRUCTION 4 . 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.

SOFTWARE CONSTRUCTION 5 .

 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 .  Con un enfoque en la construcción. es a menudo la única descripción exacta del software.  El código fuente.  Es la actividad central del proceso de desarrollo de software. la productividad del programador individual puede mejorar enormemente. IMPORTANCIA DE LA CONSTRUCCIÓN  Es la etapa más larga del proceso de desarrollo de software.  Construction is the only activity that’s guaranteed to be done.

and in effect increases the mental power of the race. "By relieving the brain of all unnecessary work... 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 . multiplication was difficult. Before the introduction of the Arabic notation. and the division even of integers called into play the highest mathematical faculties.. a good notation sets it free to concentrate on more advanced problems.

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. 1957) Formula Translating System  Java  (James Gosling & Sun Microsystems. Aeronaútica  Assembly  Lenguaje de bajo nivel. Espacio. 1972) Ventaja de portabilidad  C++  ( Bjarne Stroustrup. 1959) COmmon Business-Oriented Language  Fortran  (IBM.NET  Cobol  (CODASYL. Ritchie. Específico del procesador  C  (Dennis M. 1980) Militar. 2000) . 1995) SOFTWARE CONSTRUCTION 11 . 1980) Objetos  C#  (Microsoft.

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

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

Í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.  Cualquier gran programa requiere una estructura de control que unifique sus detalles de programación. nombres de rutinas.  SOFTWARE CONSTRUCTION 15 .  El nivel interno son los identificadores de: variables. convenciones de formato y convenciones documentación. nombres de clases.

SOFTWARE CONSTRUCTION 16 .

TENDENCIAS DE GARTNER SOFTWARE CONSTRUCTION 17 .

SOFTWARE CONSTRUCTION 18 .

FUNDAMENTOS DE CONSTRUCCIÓN SOFTWARE CONSTRUCTION 19 .

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.SELECCIÓN DE LAS MEJORES PRACTICAS DE CONSTRUCCIÓN  Codificación  Se ha definido convenciones?  Se ha definido prácticas implícitas de arquitectura. individualmente o en combinación? SOFTWARE CONSTRUCTION 20 . seguridad. condiciones de errors. Es decir.?  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. etc.

depurador. etc. librerías. SOFTWARE CONSTRUCTION 21 . compiladores. test framework.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. refactorización.?  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. etc. comprobador de sintaxis.

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 .

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.

CALIDAD EN LAS RUTINAS (PROCEDIMIENTOS. MÉTODOS. 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 . FUNCIONES) II  Cuestiones de paso de parámetros  La lista de parámetros de la rutina. tomada en su conjunto.

Code Complete: A Practical Handbook of Software Construction. REFERENCIAS  S. 2004. IEEE Computer Society.  The Software Engineering Body of Knowledge (SWEBOK) Software Engineering Coordinating Committee . second ed. McConnell.. Microsoft Press. SOFTWARE CONSTRUCTION 26 .