What is Software Design?

During complex projects, it will be hard to create a program without planning it before and to make it work as planned. In these cases, it is very common for the program to be filled with bugs and not meeting the customer expectations. There are three levels of design:

  1. Architectural design: Just getting a general idea
  2. High-level design: Shows all the subsystems
  3. Detailed: Shows all of the details

Software Requirements Elicitation and Specification

 

  • Requirement elicitation: Is the first step of creating a project. The client tells the programmer what they expect the program to do and how to do it. The information can be retrieved by interviews, observation, brainstorming, etc. The general process can be described as Discovering the needs of the costumer. (Discovering the needs of the costumer)
  • Requirement specification: This is the process of documenting the previous requirements and analyzing them in order to optimize the project

 

Goldsmith, R. (2015). Use elicitation techniques to discover software requirements. October 28th, 2016, de Search Software quality Sitio web: http://searchsoftwarequality.techtarget.com/feature/Use-elicitation-techniques-to-discover-software-requirements

Rouse, M. (2007). software requirements specification (SRS). October 28th, 2016, de Search Quality Software Sitio web: http://searchsoftwarequality.techtarget.com/definition/software-requirements-specification


Unified Modeling Language (UML) Types

A UML is a diagram that includes a collection of elements such as:

  • Programming Language Statements
  • Actors: specify a role played by a user or any other system interacting with the subject.
  • Activities: These are tasks, which must take place in order to fulfill an operation contract. They are represented in activity diagrams.
  • Business Process: includes a collection of tasks producing a specific service for customers and is visualized with a flowchart as a sequence of activities.
  • Logical and Reusable Software Components

 

HISTORY OF UML

        The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method.

       As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.

     The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.

Continue reading "Unified Modeling Language (UML) Types"

Functional and Non-Functional Requirements

Functional and Non-functional requirements are those statements that specify what the system should do.

Functional Requirements describe the behavior of the system; while on-functional requirements state a characteristic of the performance. For example: The functional requirement of a table is to hold objects, while the non-functional requirement is to hold up to 50kg.

6415553169_401ee8c1e7
Retrieved from: http://www.flickr.com

Some examples of Functional and Non-Functional requirements:

Functional Requirements

  • Business Rules
  • Transaction corrections, adjustments and cancellations
  • Administrative functions
  • Authentication
  • Authorization levels
  • Audit Tracking
  • External Interfaces
  • Certification Requirements
  • Reporting Requirements
  • Historical Data
  • Legal or Regulatory Requirements

Non-Fuctinal Requirements

  • Performance
  • Scalability
  • Capacity
  • Availability
  • Reliability
  • Recoverability
  • Maintainability
  • Serviceability
  • Security
  • Regulatory
  • Manageability
  • Environmental
  • Data Integrity
  • Usability
  • Interoperability

 

References:

StackOverflow. (2015). what is functional and non functional requirement. August 8th, 2016, from StackOverflow. Website: http://stackoverflow.com/questions/16475979/what-is-functional-and-non-functional-requirement

Ulf, E. (2012). Functional vs Non Functional Requirements. August 8th, 2016, from ReQtest. Website: http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/

 

 


Waterfall Method

13966371577_1e545704a8_n
Retrieved from: http://www.flickr.com

Also known as Linear Sequential Life Cycle Model, is a popular version of the Systems Development Life Cycle Model. Is often considered as the traditional model for software development. In the Waterfall Model, each phase must be completed in order t move to the next step. Usually applied to small projects with o uncertain requirements; there is no overlapping between the phases. At the end of each phase, a review takes place to determine if the project is in the right path.

These are the steps of the Waterfall Method:

  1. Requirements: requirement are gathered and documented
  2. Analysis: Analyzed whether the requirements are valid or not
  3. Design: Determines the architecture of the software
  4. Implementation: Coding
  5. Testing: Testing each component for making sure it works as expected
  6. Deployment: Sending the program to the users
  7. Maintenance: Fix the problems found in the future

 

The advantages of using the Waterfall Method are:

  • Is easy to comprehend
  • Allows for departmentalization and control
  • Each stage can have a predetermined due time

 

 

Although, it has the disadvantage of being unable to go back if one of the steps has a mistake that was discovered in the next stages.

 

References:

ISTQB Exam Certification. (2016). What is Waterfall model- advantages, disadvantages and when to use it? August 8th, 2016, from ISTQB Exam Certification Website: http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/

Naveen. (2016). What is Waterfall Model in software testing and what are advantages and disadvantages of Waterfall Model. August 8th, 2016, from Testing Freak. Website: http://testingfreak.com/waterfall-model-software-testing-advantages-disadvantages-waterfall-model/

Tech Target. (2016). waterfall model. August 8th, 2016, from Tech Target Website: http://searchsoftwarequality.techtarget.com/definition/waterfall-model

Tutorials Point. (2016). SDLC – Waterfall Model. August 8th, 2016, from Tutorials Point Website: http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

 


Software Development Processes

6140777343_8b14730860
Retrieved from: http://www.flickr.com

The creation of every piece of software is done by following certain steps in a different order. These steps are the following:

  1. Requirement analysis: Extract the requirements of the software asked for the client
  2. Specification: Translate the processes into mathematical statements
  3. Software architecture: An abstract representation of the system.
  4. Implementation: Creating the code
  5. Testing: Making sure the code functions appropriately
  6. Documentation: Documenting the internal design f the software for future maintenance
  7. Training and support: Training the users on how to use the new software
  8. Maintenance: Find solutions for the newly found problems.

These are some of the methodologies that use these steps:

  • Agile Software Development Methodology: Develops software in short iterations that would later be put together.
  • Crystal Methods Methodology: Every software should use a methodology according to its specifications.
  • Dynamic Systems Development Model Methodology: Sees the software development as an exploratory endeavor in which nothing can be done perfectly the first time.
  • Extreme Programming Methodology: encourages the communication between the client and the software developers.
  • Future Driven Development Methodology: Having just enough processes to ensure scalability and repeatability while encouraging creativity and innovation.
  • Joint Application Development Methodology: End users, executives and developers attend to intense off-site meeting to work out a system´s details
  • Lean Development Methodology: Create change tolerant software
  • Rapid Application Development Methodology: states many principles that support the development of a software in a faster way
  • Rational Unified Processes Methodology: Represents an iterative approach that involves frequent testing
  • Scrum Methodology: Doing the prioritized work first
  • Spiral Methodology: Early identifications and reduction of project risks
  • Systems Development Life Cycle Methodology: Repeats the steps until the whole system is done
  • Waterfall Methodology: Steps can only begin once the previous step is done.

 

References:

Computer Hope. (2016). Software development process. August 8th,

Continue reading "Software Development Processes"

Code of Ethics

9577521978_e9b81b5822
Retrieved from: http://www.flickr.com

A code of ethics is a set of rules used as a guide for companies to demonstrate the expected behavior from the employees. The main purpose of these regulations is to conduct employee’s actions in accordance with values and ethical standards (Business Dictionary, 2016). In software engineering, it is almost the same rules that are applied to every software company with just a few variations.

This code of ethics was created by the Association for Computing Machinery in association with the Institute for Electrical and Electronics Engineers. It is divided in the following eight principles:

  1. Public: Act consistently with the public interest. Software engineers shall accept full responsibly of their work. Also, commit to making its software error free and usable.
  2. Client and employer: Know their limitants and act in a manner that is in the best interest of their client and employer.
  3. Product: Engineers must ensure that their products meet the highest professional standards possible
  4. Judgment: Maintain integrity and independence in their professional judgment
  5. Management: Ensure good management and maintenance according to an ethical approach
  6. Profession: shall advance the integrity and reputation of the profession consistent with the public interest
  7. Colleagues: Software engineers shall be fair and supportive with their colleagues.
  8. Self: Engineers must promote an ethical environment and participate in a lifelong learning

 

References:

Association for Computing Machinery. (1999). Software Engineering Code of Ethics and Professional Practice. August 8th, 2016, from ACM. Website: http://www.acm.org/about/se-code

Business Dictionary. (2016). Code of ethics. August 8th, 2016, from Business Dictionary. Website: http://www.businessdictionary.com/definition/code-of-ethics.html


Software Engineering History

On the 50´s there were few computers,

And even fewer software engineers.

Programs were used by science researchers

And it remained like this for various years.

Programs were only written in Fortran.

Ten years later, Cobol was created

And that’s how business software began.

For software engineers they awaited,

As programming is a difficult task,

And learning the tricks was hard to bask.

And thus it began the “Software Crisis”.

Helpful resources were never enough.

It was a disease without the lyses.

Until they gathered to give it a though.

Engineering principles were applied

To what was thought as just a craft.

They also created a guide

Suggesting the creation of a draft.

Software was made collaborative

Which made it even more creative.

Mini computers worked with Unix

Which was easily programmed with C.

For which they were bought in large units

But the real progress was nowhere to see.

C was creating a huge problem

And it was hard to solve for them.

It was ninety-seventy-five

When microcomputers became cheap.

New languages started to arrive

And technology took a big leap.

Ken Bowles built a text editor,

File system ad debugger for Pascal.

Soon enough he became a creditor;

For fifty dollars he sold them all.

Object-oriented programming

Was created to avoid the jamming.

Tim Berners-Lee wrote a document

Describing archives linked

By hypertext and became opulent.

As the internet was created.

It was not until the nineteen-ninety,

That web browsers were created.

Software creation became free

And did not need to be licensed.

Smartphones and tables became appealing

And the word “cloud” got a whole new meaning.

 

 

References:

Viking Code School Prep. (2016). A Brief History of Software Engineering. August 8th, 2016, de The Viking Blog Sitio web: https://www.vikingcodeschool.com/software-engineering-basics/a-brief-history-of-software-engineering

Wirth,

1764490_53c26c257a_b
Continue reading "Software Engineering History"

Software Life Cycle

  • Also called Software Development Life Cycle
  • Is a framework that defines the tasks performed at each step in the software development processes
  • It is composed by many steps, although there are not officially defines.
  • Some of the steps are:
  1. Communication: The client negotiates with a software developer to agree on the terms of the new software.
  2. Requirement gathering: The software developers look for information related to the requirements of the client
  3. Feasibility Study: Find out if the project is financially, practically and technologically feasible
  4. System Analysis: Understand the limitations and the challenges involved in the software
  5. Software Design: Design the software and its interface
  6. Coding: The programming part of the whole software
  7. Testing: Verifying that the program works as expected
  8. Integration: Integrating the software with libraries or databases
  9. Implementation: Installing the software in the user machine and adapting it
  10. Operations & Maintenance: How the keep the software functional. Make changes when needed
  11. Disposition: Whenever the software needs an extreme makeover, be able to store the information somewhere

 

Software Development Paradigm: Strategies used to develop software

  1. Waterfall Model: The phases of SDLC will function one after the other
  2. Iterative Model: Repeats every step after every cycle
  3. Spiral Model: A combination of iterative and waterfall model
  4. V-Model: Like waterfall model but it is possible to go back is an error is found
  5. Big Bang Model: If put together lots of time, effort and resources, you create a software

Software Configuration Management

14137847_703018803179236_339232736_n

The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items.

The first SCM was used in 1950 and was made by hand on cards or tapes. Now there are a lot of SCM implementations like Plan Change Documentation, Source Safe, Vertical Sky and Git.

PROCESS:

  1. Identification of object in a software configuration
  2. Version control
  3. Change control
  4. Configuration Auditing
  5. Reporting

14182078_703019349845848_2043562261_n

ADVANTAGES

  • Reduced redundant work
  • Effective management of simultaneous updates
  • Avoids configuration-related problems
  • Facilitates team coordination
  • Helps in building management; managing tools used in builds
  • Defect tracking: It ensures that every defect has traceability back to its source

DISADVANTAGES

  • A file that has changed many times is going to consume a lot of unnecessary space because all the changes are going to be stored.

 

EXAMPLES:

  • Git
  • Trac
  • Visual Source Safe
  • Microsoft visual studio 2010
  • ALM
  • Harvest
  • AccurRev
  • ClearCase
  • Set-Liber