Most of the time, testing is to validate that a program works correctly. This means it fulfills the requirements without errors. Essential part of SDLC. testing looks to achieve quality, stability, and guarantee proper responses.

One of the biggest aspects of testing is discovering bugs in the code. It’s also the kind I’m most familiar with. Errors are unavoidable, especially in large projects. No matter how good the programmers are, it is wrong to trust the code they write blindly. Good software needs to work and testing ensures it always does.

Kinds of testing:

• Unit Testing: Is done with code and consists con testing individual modules of the program.
• Black Box: Test functionality without knowing the program’s internals.
• White Box: Testing with knowledge of the internals. Try all branches, cases, etc.
• Many more on Code Project.

While I unit testing is the only one I have done knowingly, I found that I almost always use black or white box testing concepts when testing my code. The one I use the most is probably white box testing as I tend to test for specific branches in my code, making sure each case works well one by one.

There are still sometimes I try to do some sort of white box testing. I guess I now realize that I should be using this tool a lot more. It has happened to me that after testing various cases individually something that used to work may break. These problems tend to be very easy to miss, especially as a programmer as you tend to make many assumptions about how a piece of code works, so testing with some real-world use cases is very useful.

What is software architecture?

A step before coding that looks to ensure that the project will meet all the requirements and also have high quality. Refers to the structure of a program, meaning implementation details aren’t relevant. Public interfaces are the main focus of Software Architecture. It tries to explain relationships between the project’s modules.

As the Software Engineering Institute puts it:

“The software architecture of a program or computing system is a depiction of the system that aids in the understanding of how the system will behave.”

Behavior is the keyword in that definition. There are many ways to achieve something in programming. Some of the variables included are language, structure, modules, and way of communication. Most companies tend to change at least one of the previously mentioned aspects but, when trying to achieve the same thing, behavior remains a constant.

As with many other concepts, there are some principles that are considered key when doing software architecture. According to MSDN, they are:

• Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap.
• Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.
• Principle of Least Knowledge (also known as the Law of Demeter or LoD). A component or object should not know about internal details of other components or objects.
• Don’t repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should
  
  
  Continue reading "Building software" →

First step in SDLC. Includes translating requirements into something to make programming easier. TutorialsPoint lists 3 levels of results: Architectural (abstract idea on how to solve a problem), High-Level (breaks the system into components or modules and how they communicate), and Detailed (interfaces, logic, details on implementation).

The following are some software design concepts that everyone should know, taken from the same website:

• Modularization: Divide into independent modules.
• Concurrency: modules that may be executed in parallel.
• Cohesion: Dependability of elements inside modules. More is better.
• Coupling: Dependability between modules. Less is better

As you can see, dividing a project into parts is one of the most important steps in the process. A badly divided project can really make the whole fall apart. On the other hand, a project that has been divided properly won’t become a mess if one of its parts fail.

It seems that one should look to make  a software project look like many small projects where everything works as supposed by itself and whenever it’s needed (concurrency).

Identifying what the people involved want the piece of software to do. They can be described as what problem you want the program to solve. Wikipedia lists 4 key steps:

1. Elicitation: Finding out what your software should and shouldn’t do. Interviews, workshops, brainstorming, and role playing are used in this step. You should get input from users and customers.
2. Analysis: More precise interpretation of the requirements from the first step.
3. Specification: Organizing requirements in a way that facilitates communication. This step includes defining functional and non-functional requirements. Once listed, requirements need to be validated.
4. Management: Final agreement on the requirements and tracking progress on getting it done.

TutorialsPoint also lists what characteristics should be met when done with the process:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

These give you an idea of what one may do with requirements.

Modifiable is, to me, the most interesting one. Changing requirements later on agrees with the idea that software can’t always be made following a simple list of steps. As the project develops, old requirements can be changed and new ones added.

Functional and Non-functional requirements are different aspects that are both needed for a project to work well. They describe stuff that the software should do and how to do it. Different programs will not only have different requirements, they will vary the amount of focus put into each of these requirement categories.

Functional requirements are those that specify what the program will do. These are specific goals that the final product has to do. Functional requirements tend to be very specific to the program being developed. In many cases, these are the main aspect a consumer will care for. Functional requirements are what makes a program itself. Programs with the same or similar are considered to achieve the same thing.

Non-functional requirements are, according to Lawrence Chung from UT Dallas, “a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, and software quality attributes”. He also mentions they are much harder to test.

Some examples of software with similar functional requirements are Windows and Linux distributions. As OS’es they try to achieve largely the same thing, including allowing users to run other pieces of software. In this case, even some non-functional requirements are the same, like achieving good performance. Still, some non-functional requirements differ greatly. Being open source is a clear example.

Widely considered the oldest Software development methodology, the Waterfall method is ordered set of steps. Another way to describe it is as a line that only goes in one direction. Russell Kay at Computerworld describes as “a sequence of stages in which the output of each stage becomes the input for the next”. He lists the following steps:

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

Almost all other fields have used something similar to the waterfall method at some point. Compared to other methodologies used today, it is a very simple method. Still, it has many  troubling problems, especially those having to do with not being able to go back in the steps.

In my opinion, while it may work for some projects, the waterfall method isn’t really a good one for software development, because it doesn’t take advantage of the benefits of coding. Unlike other fields, coding doesn’t typically have limited resources to code, meaning there can be many version and different version can introduce only small

According to Niklaus Wirth at computer.org, Software engineering began in the 1960’s. It was during these years that computing became its own field. In the early days, computers were a way for other engineers and scientists to make computations. As time passed, people realized computers were complex enough that it was worth it to dedicate completely to them.

After the initial boom in computing, problems became apparent. In the early days, programming wasn’t well understood. This lead to projects failing or being badly planned. Another problem was in what direction to take computers. Many languages and approaches existed, but people didn’t know what to choose. This period was known as the Software Crisis.

With such big problems, engineers worldwide wanted find a solution. In a way, the approach ended causing more problems. Wikipedia mentions “The search for a single key to success never worked. All known technologies and practices have only made incremental improvements to productivity and quality. Yet, there are no silver bullets for any other profession, either”. Software engineers had to learn that there were many ways to get things done, no one method or language would fix the situation.

This situation improved with time. Another big change to the field was the introduction of the Internet. With it, the range of projects that could be developed grew tremendously. Many new ways to manage projects were created, some using new concepts, some reusing old ideas. These include Extreme Programming and Scrum.

Coding requires a wide range of abilities, which means one needs to be good at many things. Of the different required skills, some can be considered an art and some are mostly science. Achieving good performance, for example, is mostly a science. Still, even when talking about extremes, there is still some parts that could be considered art.

On the other hand, some aspects of coding are much more debatable. One specific area that could be considered either is software engineering. Even though there are a lot of rules and steps to follow, creativity plays a much bigger role. There are many ways to measure successful software engineering, which is why the art part is much more notable. In the performance example, time and steps are the only measurement of success.

Software Engineering can often include everything that has to do with a software project, meaning it very often deals with aspects outside of coding. Software Engineer Insider mentions that: “Software engineering differs from other branches of engineering in that professionals are building an intangible structure and not a tangible one”. I find this to be a key point in understanding S.E. Working with software projects differs greatly from working with other projects. Not relying on physical resources allows programmers to make many mistakes, which allows for a lot of testing.

Testing and trying new ideas is what adds the artistic aspect to S.E. While I think S. E. should mostly rely on science or engineering, there is always the opportunity to be artistic.