Software Design Patterns

Software Design Patterns are commonly used on object-oriented software development, they are previously defined methods to design and code programs, used commonly by experts and corporations that benefit from structured and unified ways to develop and execute. They serve as a common framework for developers and promote good coding practices.

Source


They were not developed intentionally, they were instead created by trial and error and the prevalent ones are the ones that, by natural selection, were proven to be the best ones.
The Gang of Four, are the ones that wrote a book and set the SDP principles down, the book is called "Design Patterns - Elements of Reusable Object-Oriented Software". The two main principles are:

  • Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
  • Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.
There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:
  • Creational: Create objects on the go as they are being used.
  • Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
  • Behavioral: Communication between objects is prioritized.
  • J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Design Patterns

Software Design Patterns are commonly used on object-oriented software development, they are previously defined methods to design and code programs, used commonly by experts and corporations that benefit from structured and unified ways to develop and execute. They serve as a common framework for developers and promote good coding practices.

Source


They were not developed intentionally, they were instead created by trial and error and the prevalent ones are the ones that, by natural selection, were proven to be the best ones.
The Gang of Four, are the ones that wrote a book and set the SDP principles down, the book is called "Design Patterns - Elements of Reusable Object-Oriented Software". The two main principles are:

  • Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
  • Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.
There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:
  • Creational: Create objects on the go as they are being used.
  • Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
  • Behavioral: Communication between objects is prioritized.
  • J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Requirements

In order to define what a piece of software can do, you have to define clearly the functions and requirements that it must contain for the customer to be satisfied and your team to know what to do and how.

The goal is to arrive at a Software Requirements Specification (SRS) Document, a spec sheet that details what the software can do.
Photo by Nathanael Coyne on Flickr. CC BY-NC-ND
Requirement Engineering is a discipline that aims towards understanding client's requirements and translating them into technical and detailed specifications for the developers, it consists of four basic steps:

  1. Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
  2. Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
  3. Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
  4. Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION
It is an organized process to gather requirements for the software, it has four steps.

Requirement elicitation process

First the developer gets the requirements from the client, then they are prioritized and categorized, next they are reviewed with the stakeholders to remove any ambiguity or doubts about the requirements, finally, they are documented correctly for the next phases of development.

One or more of these methods can be Continue reading "Software Requirements"

Software Requirements

In order to define what a piece of software can do, you have to define clearly the functions and requirements that it must contain for the customer to be satisfied and your team to know what to do and how.

The goal is to arrive at a Software Requirements Specification (SRS) Document, a spec sheet that details what the software can do.
Photo by Nathanael Coyne on Flickr. CC BY-NC-ND
Requirement Engineering is a discipline that aims towards understanding client's requirements and translating them into technical and detailed specifications for the developers, it consists of four basic steps:

  1. Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
  2. Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
  3. Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
  4. Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION
It is an organized process to gather requirements for the software, it has four steps.

Requirement elicitation process

First the developer gets the requirements from the client, then they are prioritized and categorized, next they are reviewed with the stakeholders to remove any ambiguity or doubts about the requirements, finally, they are documented correctly for the next phases of development.

One or more of these methods can be Continue reading "Software Requirements"

Waterfall method

The waterfall model is a sequential design process, often used in software development processes, where progress is seen as flowing steadily downwards (like a waterfall).

forest-trees-waterfall

Waterfall projects value:

  • Processes and tools over Individuals and interactions;
  • Comprehensive documentation over working products;
  • Contract negotiation over customer collaboration;
  • Following a plan over responding to change.
large
Diagram made by BBC Bitesize

The Waterfall method does have certain advantages, including:

  • Design errors are captured before any software is written saving time during the implementation phase.
  • Excellent technical documentation is part of the deliverables and it is easier for new programmers to get up to speed during the maintenance phase.
  • The approach is very structured and it is easier to measure progress by reference to clearly defined milestones.

Unfortunately, the Waterfall method carries with it quite a few disadvantages, such as:

  • Clients will often find it difficult to state their requirements at the abstract level of a functional specification and will only fully appreciate what is needed when the application is delivered.  It then becomes very difficult (and expensive) to re-engineer the application.
  • The model does not cater for the possibility of requirements changing during the development cycle.
References:

What the hell is SCM?

At first, I didn't really know what it was or anything about it, but with some google-fu and midnight reading I will share with you my findings about SCM.

SCM stands for Software Configuration Management, sometimes called Software Control Management, it is a framework for organizations to manage software and its changes, updates, errors, versions, tests, and code; all of this in a clean and organized manner.

SCM is the process that defines how to control and manage change.
It is needed with software that involves large organizations and a lot of programmers, it defines who is allowed to make changes, how they make them, and when they can. Software configuration management benefits all the stakeholders in a software project, making their jobs easier. Among the beneficiaries are: developers, testers, support, management, and investors.

Source

SCM consists of four Configuration stages:

  1. Identification
    • Made up of configurable items (CI), that is, the programs that make up the SW project.
    • Baselines are contemplated, they are the status of the CIs at a given point, a version.
    • A baseline must have a complete documentation that includes the capabilities of the software, bugs and testing, and a unique footprint.
    • On each baseline, the CIs are at an specific version-controlled stage.
  2. Control
    • Implementing the approved changes to the CIs.
    • Process to get to a new baseline.
  3. Status Accounting
    • Tracking the changes made from the old baseline to the new one.
    • Describes the current version and how it came to be.
    • The "what's new" section that you see when updating an app in your cell phone, only more detailed.
  4. Authentication
    • Making sure that the previous processes are complete and correct.
    • Testing the software.
    • If the tests are passed, then comes the release.

Source
I think, on the grand scale, that's about it. SCM seems like Continue reading "What the hell is SCM?"

What the hell is SCM?

At first, I didn't really know what it was or anything about it, but with some google-fu and midnight reading I will share with you my findings about SCM.

SCM stands for Software Configuration Management, sometimes called Software Control Management, it is a framework for organizations to manage software and its changes, updates, errors, versions, tests, and code; all of this in a clean and organized manner.

SCM is the process that defines how to control and manage change.
It is needed with software that involves large organizations and a lot of programmers, it defines who is allowed to make changes, how they make them, and when they can. Software configuration management benefits all the stakeholders in a software project, making their jobs easier. Among the beneficiaries are: developers, testers, support, management, and investors.

Source

SCM consists of four Configuration stages:

  1. Identification
    • Made up of configurable items (CI), that is, the programs that make up the SW project.
    • Baselines are contemplated, they are the status of the CIs at a given point, a version.
    • A baseline must have a complete documentation that includes the capabilities of the software, bugs and testing, and a unique footprint.
    • On each baseline, the CIs are at an specific version-controlled stage.
  2. Control
    • Implementing the approved changes to the CIs.
    • Process to get to a new baseline.
  3. Status Accounting
    • Tracking the changes made from the old baseline to the new one.
    • Describes the current version and how it came to be.
    • The "what's new" section that you see when updating an app in your cell phone, only more detailed.
  4. Authentication
    • Making sure that the previous processes are complete and correct.
    • Testing the software.
    • If the tests are passed, then comes the release.

Source
I think, on the grand scale, that's about it. SCM seems like Continue reading "What the hell is SCM?"

Agile Development

In 2001, 17 software developers met at Utah to put together ideas they had on lightweight development methods. They agreed on 12 Principles that turned into “The Agile Manifesto”.

Agile software development is about doing things based in short term plans instead of spending a lot of time planning a big strategy. According to the Agile Manifesto individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.

Scrum is the most common approach to agile development. It’s an alternative to the traditional waterfall method, as each process isn’t dependant on its previous process. All processes happen at the same time, quickly and in an interconnected, multifunctional matter. Then, after all processes are done, analysis and conclusions are reached and a whole set of new interactions can start.

If you want to know more about scrum you can watch the following video:

Agile development provides a way to know the direction of a project THROUGHOUT the development cycle, not before.

By: Carlos Martell and Lucía Velasco.