Software Design

Software design is the process of defining software methods, functions, objects, and the overall structure and interaction of your code so that the resulting functionality will satisfy your users requirements.

The final goal of any engineering activity is to create some kind of documentation. When a design effort is complete, the design documentation is given to the manufacturing team. This is a different set of people with a different set of skills from those of the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build much of the product without further assistance from the designers. After reviewing the software development life cycle today, it appears that the only software documentation that actually seems to satisfy the criteria of an engineering design are the source code listings.

What are the ramifications?

Software runs on computers. It is a sequence of ones and zeros. Software is not a program listing.
A program listing is a document that represents a software design. Compilers, linkers, and interpreters actually build (manufacture) software.
Software is very cheap to build. You just press a button.
Software is expensive to design because it is complicated and all phases of the development cycle are part of the design process.
Programming is a design activity; a good software design process recognizes this and does not hesitate to code when coding makes sense.
Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for more design effort. The earlier this happens, the better.
Testing and debugging are design activities – they are the equivalents of design validation and refinement in other engineering disciplines. They can not be short changed.
Formal

Continue reading "Software Design" →

El día de la exposición (Class Diary)

El día de hoy, des afortunadamente llegué un poco tarde a la clase debido a un problema que tuve por la mañana, es por eso que no tuve la oportunidad de ver las exposiciones de mis demás compañeros, salvo de tres.

De nuestra parte, expusimos nuestro prototipo del sistema de admisiones que planeamos implementar en nuestro proyecto, y además, el sitio web que estamos desarrollando para la escuela en la que estamos trabajando para nuestro proyecto final.

Creo, que la presentación fue buena, cubrimos todos los puntos y al parecer no hubo ninguna duda de parte de nuestros compañeros, a los que nos dejó satisfechos al pensar que hasta ahorita estamos realizando un buen trabajo mi compañero Héctor y yo.

En lo que resta de la semana, esperamos seguir avanzando en el desarrollo del sitio, y poder brindar una navegación cada vez más amigable y funcional a lo que será el usuario final.

UML (Unified Modeling Language)

Models help us by letting us work at a higher level of abstraction. A model may do this by hiding or masking details, bringing out the big picture, or by focusing on different aspects of the prototype.

Modeling is an Essential Part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper.

UML (Unified Modeling Language) is a standard notation for the modeling of real-world objects as a first step in developing an object-oriented design methodology. Its notation is derived from and unifies the notations of three object-oriented design and analysis methodologies:

Grady Booch’s methodology for describing a set of objects and their relationships
James Rumbaugh’s Object-Modeling Technique (OMT)
Ivar Jacobson’s approach which includes a use case methodology

What is SRS?

SRS, or Software Requirements Specification is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.

An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost.

What should the SRS address?

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

El día de exposición, que no expusimos

En esta clase, se suponía que cada equipo iba a exponer el prototipo y el bosquejo de su proyecto, sin embargo, la clase la utilizamos para refinar y terminar detalles de estos.

Prácticamente toda la clase la utilizamos para terminar esta tarea, por lo cual la exposición tuvo que ser re-agendada a dos semanas después, debido que la próxima sesión sería el examen parcial.

Nosotros, como ya teníamos el bosquejo totalmente terminado, y el prototipo a medias, utilizamos la sesión para poder terminar completamente el prototipo, y aventajarle en la entrega final del proyecto.

Class Diary

El día 5 de octubre, después del pequeño receso que nos regaló la semana i, volvimos a nuestras actividades normales en la clase de fundamentos de diseño interactivo.

Para comenzar la clase, el profesor nos dejó una actividad para poder crear un presupuesto aproximado del proyecto que estamos desarrollando, en el cual, fue bastante gracioso ver como varios de nosotros cobrábamos precios exorbitantes por el trabajo que planeamos realizar.

Sin embargo, nosotros nos basamos en un sitio web llamado codecollege.ca, donde nos daba una pequeña herramienta para poder hacer la cotización de nuestro proyecto.

También el profesor nos dejó que investigáramos sobre Balsamiq y Proto.io, para poder empezar a realizar nuestros bosquejos y el prototipo de la solución de nuestro proyecto.

Code Of Ethics

Originally posted in Juanca’s Blog. Made this work with him.

Juanca's Blog

code-of-ethics-seal

The Association for Computing Machinery is an organization that cares a lot about the Software Engineering community. Among the many things they do, one of the most important things is that they try to unify the professional ethic principles that conceptualize the ideal work on a System’s Engineer.

The ACM Code of Ethics identifies the elements of every member’s commitment to ethical professional conduct. It outlines fundamental considerations that contribute to society and human well-being and those that specifically relate to professional responsibilities, organizational imperatives, and compliance with the code.

There are eight main principles that ACM suggests following:

1.- Public: This principles is about caring for others, trying to take in consideration everyone’s wishes and capabilities without trying to pursue an individual desire.

2.- Client and Employer: This is about transparency. It is crucial to be honest with your client and to do what you say you’ll do, always…

View original post 228 more words

Agile software development

Publicación hecha entre Sandra Amezcua y Alfonso Iraí

Sandra Alcaraz

Manifiesto por el Desarrollo Ágil de Software:

Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como

ayudando a terceros. A través de este trabajo hemos

aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.

http://agilemanifesto.org/iso/es/manifesto.html

Esta técnica nos habla de cómo trabajar juntos con el usuario para llegar al objetivo en común.

Para llegar al objetivo tenemos que seguir los siguientes pasos:

1.- Planificación del programa:

2.- Diseño del programa: Se tienen que definir los procesos.

2.- Construir el programa.

3.- Probar el programa.

4.- Revisar el programa.

5.- Lanzar al mercado.

Beneficios de agile:

Satisfacción del cliente por la rapidez de entrega y por las mejoras continuas que se…

View original post 230 more words

Functional and non functional req.. Does it really matter?

What is a functional requirement?

Refers mainly to the expected function of the product. Product or system features, or what the program does is what the functional requirements are. Definitely it is easier to determine the functional requirements than the non-functional because they are almost obvious.

What is a non-functional requirement?

These requirements refer mainly to the attributes that include performance, security, usability, etc. Developers usually miss these requirements because they focus mainly on the functional requirements. When addressing incorrectly these non-functional requirements, the system actually fails. For example, the lack of usability or performance can lead to frustration or system problems. This is why non-functional requirements are so important for a system to succeed.

Waterfall Method

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

Waterfall model is the earliest SDLC approach that was used for software development .

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In “The Waterfall” approach, the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

Following is a diagrammatic representation of different phases of waterfall model.

Advantage

The advantage of waterfall development is that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

Disadvantage

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

More info: Here!