SLDC... What?

SLDC. No, it doesn’t stand for some sexually transmitted disease. At least not in this post.
Software Development Life Cycle, that is. Okay, but what does it mean?  Essentially, it’s the thing you should do to ensure some software gets to be and stays good.

                         

For this to happen, you first observe; you’ll be making some investigation and analysis. This is very important, it will tell you where to go, what you’ll need; you define expectations and requirements, communicating with the end users. You can do this by doing interviews and surveys, considering multiple cases that describe what users might do (or even show real-life users some prototypes).

Only after you gather this detailed information, should you start planning: you establish technical requirements (hardware and software) and security processes/vulnerabilities. Further specifications like how the user interaction will be (entry fields, buttons, screens). You should also think about how easy it would be in the future to add new features, and make modifications.

Then, what would maybe be your first step had you not read this: coding. The difference is that by this point you have expectations at which to aim, user-desired features, hardware/software limitations, parameters to be tested and tweaked. After this phase is completed, you’ll have the finished product, but not the end of your hard work; after every coding milestone is reached, you have to evaluate how close it came to what was actually planned. However, you should also be open-minded for unexpected changes and issues. Team communication is crucial here, for progress to be really accomplished and not get stucked on some sort of loop.

So what do you do next? Well, you can’t (shouldn’t) just launch your software like that, testing should come first. You’re going to want to consider how your software will be implemented in different environments, as well as its user acceptance. Be sure to document every step of your way, so anything can be referenced in the future. Bug capturing tools might save your life at this point. This might lead you straight back to the coding phase, or even the design phase!

Ok, so we’re done with testing. Finally we can start the deployment/implementation! Depending on how your user-testing went, you might want to decide to train end users, or at least have some initial guiding for how to use your product (although not always necessary). You’re going to want to consider location factors.

If you’ve made it this far, don’t expect it to be the end. For software to be reliable and updated, you should frequently reevaluate its whole concept from the beginning multiple times. You know, that’s why it’s called a cycle. If it weren’t, why not just create a product that’s only usable for a short time, under certain conditions and with no real future implementation? You don’t want to do that. Please.

A Glimpse at Software Engineering History

Software Engineering. I’ve talked about it, you’ve heard about it, but who was first? How was it originated? Here I’ll try to summarize the story behind it, and some milestones that shaped the world we now know.

You might instantly try to to be thinking about which programming language people used back then, but no. Programmers back in the 50’s-60’s delivered programs by HAND, so that only hours later all the mechanical-electrical processes could be finished. This was very difficult to rely on, and led to high costs in the industry. This so called “software crisis” made it pretty clear some better solutions had to be found. Traditional engineering practices were sought to be applied to software, and over the next few decades some key ideas emerged that allowed engineers to break down projects into tinier (modular) pieces, communicating via interfaces.

One of these key ideas happened in early 1980’s, when thinking of data as objects that held independent states and could interact with each other began to emerge, the so called “object-oriented programming”. This lead to easier creation of GUI’s with menus and windows and improvements in security. At the same time, computing power increased at an incredible pace. As good as this was, it also made it possible for code not to as efficient as before, with much more memory and resources available.

Then, let me take you straight to 1989 when the magnificent Web emerges with the help of Tim Berners-Lee in Switzerland with one of his papers. However, it wasn’t until 1990 that a little of what you might imagine as “web” came into place, with users being able to have a graphical access to pages.

Then (oh, yes!), we also have the open-source movement in the 90’s which removed corporate code barriers, allowing an explosive expansion in software. This means not only the executable binary code was released, but the actual code whose compilation led to the binary executable. Consider this, together with how the cloud began to allow applications to be accessed in real time and the rise of the mobile industry (tablets and smartphones), and you have a little glimpse of how software engineering has come to be what it is today. If you ask me, today is just easier than ever before to develop your own next revolutionary idea, with so many tools at our disposal, and the ever-increasing pace at which software is being released to us.

Ethics in Software Engineering

Authors: Enrique García, Andrés Barro, Jesús Alvarez, Gerardo César, Carlos Martell

Ethics can be defined as our individual self-reflection and continual strivings to do good. At a professional level, codes or standards are created so that there’s an agreement to a profession’s ethical standards. Software engineers have the ability to deploy code directly to end users, and along this process there should be some ethical oversight, not only technical.

image obtained from: http://www.infoworld.com/article/2997057/it-management/the-volkswagen-scandal-and-software-engineering-is-a-code-of-ethics-needed.html

The ACM (Association for Computer Machinery) has published a code of ethics regarding software engineering, a document that outlines the guidelines for those engineers to act in a way that benefits society and conserves their integrity. It includes 8 basic principles that will be summarized in the next section:

1. Public

Software engineers have to take responsibility on his work; if by some way there are failure in his software and it harms the public, directly or indirectly, it becomes an unethical behavior. In other words, a software engineer doesn’t just make software but also he has to make sure to have the proper maintenance so it won’t cause problems with the users or with the public.

2. Client and Employer

Software engineers have to act to the best interest for their client and employers. Like any other job, you can't make public confidential information about professional work. You also have to respect your employer and your clients.

3. Product

This principle refers to making sure every product and related modifications to it meet the highest professional standards. There should be a pursuit for quality, reasonable schedule, costs and outcomes and achievable goals; to fully understand the specifications for the specific software. There should be adequate documentation, debugging and review. Maintain integrity of data and respecting privacy.

4. Judgement

In this principle, software engineers are advised to make decisions based on their experience, human values and social norms. They should not make decisions outside of their knowledge, be professionally objective when evaluating, avoid tricky financial practices, and avoid interest conflicts that may harm their professional activities, in most cases giving the customer a heads-up if the engineer senses they could come up.

5. Management

Another point addressed in the ACM code of ethics is that software engineers should subscribe to and promote an ethical approach to the management of software development and maintenance, including good management and making sure everyone is informed about the policies as well as making sure everyone is  assigned to where they suit their abilities.

6. Profession

To achieve this point, Software engineers have to treat the profession as a kind of group, meaning that all engineers must work together to make the profession better for everybody. Most of this is done by making sure others follow the code, including companies. A big part of making the profession better is to share knowledge so all engineers have a better time.

7. Colleagues

Colleagues are a very important part of every profession and that's why a whole part of the Code is dedicated to them. The main idea to take is to be fair to others. It is important to note that this doesn’t mean to ignore mistakes from others, but to be objective and focus on assisting other with their problems.

8. Self

Self improving is something every professional must do, especially Software Engineers. This way, you stay up to date in how to make quality software. Areas that of interest include security, design, maintenance, etc.

Software Engineering. What?

Software Engineering. Perhaps you’ve heard it before. In fact, for you to be reading this, you most certainly have.

The Association for Computing Machinery (one big joint amongst others in the software world) defines it as “developing and maintaining software systems that behave reliably and efficiently(...)”.

Now, you could say that sounds very similar to what you think of computer science. Yes… but no. They’re 2 different majors. Typically, both have within their curricula programming fundamentals and basic computer science theory. However, computer science tends have few core topics, so that students can later choose where to go next (networking, artificial intelligence, database, etc.), whereas software engineering tends to focus on a broad range of topics essential to building solutions that are useful and usable.

In this way, one might come to understand these two as the “artist” and the “engineer”. Computer science could typically be more involved in developing the theories and research that later become tangible things after the engineers set it up. But, it could also be the other way around. For as much as you have a major in one or the other, in the end it all comes to the way you approach things.

You shouldn’t categorize majors as either crafts or engineerings. If you’re up for categorizing things, then look at each person with these majors. None of them are exactly the same, nor do they think the same. They have different grounds and knowledge, yes, but might think as artists or engineers, or who knows what else...

Testing...

This is a test. Bleep,bloop. TC1019 Software Engineering course.