Software can be really finicky. As the matter of fact, it’s quite normal for software to fail. With this in mind, it’s important to detect what kind of problems may emerge in order to fix them in an easier and faster way. Before I get into the type of software maintenance, is important to mention that maintenance isn’t always done in order to fix a problem. It’s actually more about preventing the system to fail, and also it can be used to improve the system in way.
- There’s the corrective type, in which problems that stopped the system need to be addressed.
- Adaptive, where the system is modify in way in which it’ll be able to run in a different environment.
- The perfective one, where you try to increase performance.
- Preventive, you want to do your best at preventing future problems.
Open source is cool. If the name doesn’t give it away, open source software is software that is out there for anyone to grab, modify, and distribute. So, why is it cool you ask? Well, Jimmy, it’s quite simple. Open Source Software is an ever changing piece of software just because it’s out there for free. The fact that people take this free software, and modifies it for whatever he or she wants ensures the development, and distribution of the software. Anyone can take it, model what they want, and send it back out there. It’s like indirect collaborations between programmers. That sounds cool right?
Just in case that I didn’t really explained myself back there, I’ll provide with a huge example. A really cool one at that. Linux. The whole development of Linux has been thanks to the fact that it’s open source software. The whole system really blew up because there were so many people contributing to the software. Linux was even used as a base for other operating systems, and most servers run in Linux-based system.
So yeah, open source is cool.
We are now getting into the integration of software. So, software implementation is a discipline that ensures that the software system you’ll make integrates well into a complete system. So it’s to make sure you know how are you going to do your work, and finding out the best way to do it, and which tools you’ll need.
Programming methods are usually broken into two:
The structural in which you work with loops and other subroutines to make you code a little more legible.
The functional, which bases itself in mathematical functions.
So you can choose between those two in how you want to implement your system. Now, it’s also important to make sure that your code is somewhat easy to read, or that at least people can figure out easily what is going on in the code. This is why documentation is really important. There’s a few ways to make documentation, but the important thing is that you actually document your code. Designing a software is not a job of a single person, make sure that others understand what’s going on between the lines.
Now the tools:
- A text editor: You need a place to write your code. It can even be notepad if that’s you cup of tea, but you’ll need an editor.
- Compiler: Some languages only need an interpreter to run, but in some is necessary in order to translate the code into machine language or another lower level language.
- Debugger: You’ll need it for big piece of software. Using the good ol’ trusty print in console only works to a certain point. A debugger helps you find bugs and deal with them faster.
- A SCM tool is also really helpful when working with a group of
Continue reading "A good implementation is key"
When building a large piece of software you want to test it. Trust me. It would be pretty unwise to not do so. Not only it helps you to improve your product, but it also provides the stakeholders a view in the quality of the project. So that’s nice.
Testing involves the execution of a software in order to find bugs. Something that isn’t working like it should. It’s also used to evaluate different properties of the system. When testing you want to check this properties:
- The requirements set in the design are met
- It responses well to all kind of inputs
- The time of execution of the task is acceptable
- It’s stable enough
- It reaches the general result that the stakeholders want
There’s a lot of type of testing, such as installation testing, compatibility testing, smoke and sanity testing, regression testing, acceptance testing, alpha testing, beta testing, etc. You usually decide what kind of testing you want to do depending on the point of development your system is in.
Testing is important. You need to ensure that your system ends in a desirable level. There’s bad software implementation in a lot of places. Don’t let yours be one of them.
Software engineering, or implement a software system can be a little bit problematic. When implementing something you are bound to found a problem along the way. No one can get saved from that. However, you don’t have to go around, and try to fix things without a background. You see, there’s software design patterns. A software design pattern is a general tool used as a solution to a common problem found in software implementation, and software design. It’s not really a code, but a description of how to solve a problem. So that’s neat.
There’s quite a bit of software design patterns, and that’s an understatement. There’s designs for creational patterns, like the singleton, which makes sure that a class only has one instance, and lets it to be accessible to a global level; structural patterns, such as extension object, which adds functionality to the hierarchy but without changing it; behavioral patterns, which mostly focus in the use of the algorithm; and concurrency patterns, which deal with multi-threaded systems.
To be honest, this is usually more helpful when building a large software system, due to the fact that they tend to be a little bit more complex. Also, don’t take my word for it, look them up, there are so many design patterns, and they’re really interesting to read up on. I’m only giving a general over view of the subject, but there’s a lot more out there worth looking out.
Software architecture is about the fundamental structures found in a software system. Structures are created an also documented. It is specified how they work, what they try to accomplish, and how they interact with each other. This is necessary in order to understand well the whole software system and reason with it.
This idea is mainly implemented in order to make structural decisions on parts of the software system that is costly to modify once implemented. It shows 4 main characteristics:
Multitude of stakeholders: To provide what a series of stakeholders need. Stakeholders tend to have different points of view, and interests. It’s important to keep in mind the needs of each stakeholder. This means that software architecture must have a multidisciplinary nature.
Separation of concerns: The use of documentation to show that the needs or concerns of the stakeholders are being addressed by the modeling and description of each structure in the system.
Quality-driven: As of right now, software architecture tries to ensure that the software system is reliable, it has availability, maintainability, and other traits mainly focused in the stakeholders concerns.
Recurring styles: Over the years, there has been a development of standard ways to deal with certain concerns. Software architecture implements this.
Conceptual integrity: To show that the architecture of a software system shows an overall view of what is supposed to do, and how.
UML is quite interesting. UML, or Unified Model Language, is way of representing to a certain detail the development of the software of a project. It’s a general purpose, developmental, modeling language. The language is usually represented in diagrams, such as the structural diagram, behavior diagrams, and interaction diagrams.
In the structural diagram the components and classes diagrams are developed. In the components diagram, shows how components used in the development of the software will be wired together. This forms large components or software systems. In the class diagrams, the classes for the objects used in the project are defined. The attributes, and methods of this classes are shown to a certain detail.
In the behavior diagram, it is specify what each piece of the project is supposed to do and how it’s supposed to behave.
Finally, in the interaction diagram, the interaction between every subsystem of the project is specified.
In my opinion UML I kind of cool. I certainly lack the patience to go all out my why to develop this whole intricate thing to make my software implementation look cool though. That’s when UML loses me. It seems to me that it is a nice way to organize your project, however, I think that it has the same downfall as the waterfall method. You can focus too much in the planning and visualization of the project that you can get to the point in which you end up neglecting the implementation of it. So, UML is cool, but don’t dwell on it too much.
A software that no one is going to use is useless. You might have an awesome piece of code. Very well written, well developed, efficient, and practical, but people might not use it because it doesn’t serve any purpose to them. When developing software is important to keep in mind what is your software going to a port. Basically, defining the main requirements of the software. What it’ll do, and how it will be done. The IEEE Computer society defines requirements as following:
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
- A documented representation of a condition or capability as in 1 or 2.
To gather the requirements, and other resources from stakeholders interested or related to your project. This is the first step for developing requirements from a project.
During the analysis of the information gathered during the previous step, developers try to get a clearer richer idea of each requirements.
Representing the gathered information in a well-organized matter. This makes communication easier, and ambiguity less common.
Confirm the correct set of requirements.
It’s normal for requirements to change during the project. It’s important to manage this changes.
I’m just going to say this right of the bat. I really don’t like the waterfall method. The whole idea of the waterfall method is dividing the software development into 6 main concepts and areas.
- Finding out the requirements for the development of your software.
- The Analysis: you determine your project using models, schemas, and a business model.
- Design: You design the software architecture.
- Coding: You code.
- Testing: debugging, and problem solving.
- Operations: Installation, migration, support, and maintenance of the work (IMSM? Doesn’t sound too catchy).
Here’s a pretty picture to understand it better:
The whole idea of this method is to keep track of what you want, how you want it, and how you’re going to make it. If focuses a lot in the planning, and documentation of the software that is being developed. This is why I don’t like it. It’s important to keep track of what is being done, how it’s being done, and to make sure that everyone involved in it knows what is happening. However, sometimes projects using this method focus a lot on the documentation, and administrative side of it. This means that there might not be enough attention in the actual software implementation, and the client’s satisfactory level.
Diving into a project with only an idea in mind is usually a bad idea. I get that sometimes the unexpected events and things that come out of nowhere are the best. However, that’s not the tendency. You usually want to plan what you want to do. Personally, I’m not very fond of the idea, but it really is important to plan.
When you’re planning for a software engineering related project you can usually follow the general convention of software development process. It actually makes sense, and it’s quite helpful to separate the concepts before starting to work. There’s more than one though. The basic ones are the Prototype method, the Waterfall method, and the Spiral method. The waterfall method is discuss in another of my blogs, so I’ll focus in the spiral and prototype method.
The main idea the prototype system is creating prototypes, or incomplete pieces of the software being developed. It follows 4 main principles:
- Prototyping is not a standalone, complete development methodology, but rather an approach to try out particular features in the context of a full methodology.
- Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
- The client is involved throughout the development process, which increases the likelihood of client acceptance of the final implementation.
- While some prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.
The spiral development is something that I’ve personally used. The name of the process describes a lot of it. It breaks down the process like in the waterfall method. It is broken down in four ways, and a repeated along the process of the development:
- Determine your objectives
- Identify and resolve risks
Continue reading "Software Development Processes"