Analytics aims to describe, predict, improving development, maintenance, and management of software systems. Gathering information, analyzing it, and visualizing it are the main steps of various methods of doing analytics.
Analytics represent a basis of software diagnosis which helps in generating conclusions, evaluations, and findings of a software system.
First off, verification & validation are two terms that are common used in software development. They are commonly mistaken as if they were equal. Let’s begin by defining each term.
Verification is an evaluation of the process of creating a final product. It is useful to determine if the project development goes in the right track. Intermediary work is analyzed: documentation, data bases, etc.
Review of requirements
Review of design documents, including HDL and LDD
It is the process of evaluating the final product to determine if it matches the user needs. Basically all types of testing post-development are considered validation.
Prepare test requirements documents and other test specifications to analyze results.
Evaluate if these results is fit for use and reflects the project requirements.
Test for complicated values, stress, and all possible functionalities.
Check if errors exist, if they do, if a graceful message explain them.
Check business requirements, and if it is fit for it.
User Interface, often abreviated (UI), Design ensures that there are elements easy to access for what users may want to do. Accesibility is what UI design is all about, it must be understandable, and easy to do. Basically, it brings together visual, and interaction design with information architecture. Let’s do it beautiful.
Tips for a great interface
Keep it simple, avoid unnecesary elements.
Use common elements in your UI, users will feel more comfortable, and will get things done faster.
Structure the page based on importance, and consider relationships between elements and space.
Use colors and textures strategically.
The use of typography is important to create hierarchies, and make it more understandable.
“Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.” (TutorialsPoint, 2016)
Software needs to be tested to determine if all requirements were met. If there are any errors, bugs, mistakes, or gaps in the system.
Who does testing?
The more the better. Different points of view are required in this process: Normally, there is a software testing team; however, software developers, managers, and users also participate.
It is important to implement this phase throughout the development.
Why? To save time, reduce costs and errors.
Testing never ends
This means that there is always some improvement to the system; therefore, testing is needed to see if there is something to be improved.
Types of testing:
There are lots of testing types including compatibility, performance, usability, security, recovery, comparison, stress, unit, load, regression, system, etc.
Most known testing types are alpha testing which is done at the end of the development phase, where the software is almost complete; beta, where end-users are the ones testing the system supposedly finished; and black-box which tests if the system covers requirements.
So here you are again. If this is your first time, welcome to my blog, and congratulations for trying to learn something new.
What am I talking about?
Software Design Patterns, which are solutions to typical problems that software developers face during development. Trial and error was the method in which these solutions were obtained. A lot of time has been invested in Design Patterns.
What is GOF, and why is it important?
GOF or Gang of Four is the name of the crew that began this movement. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published their book Design Patterns – Elements of Reusable Object-Oriented Software in 1994. Their method in two basic methods of OOP (objected-oriented programming):
So in any project that you’re working in something really important is to know how the project is going to work. With this said, having a clear knowledge of the functional and non-functional requirements for your project. Now, what are the differences between functional and non-functional requirements, you ask? Well let me explain. To have things crystal clear functional requirements are those that you have for your project’s functionality. In a more non software engineering example, it’s like when you have to prepare a presentation. Your information is your functional requirements. You need that stuff in order to properly portray what you are presenting. Now, the non-functional requirements is everything that makes your stuff pretty. Again, in the weird presentation analogy this would be making things pretty. Maybe using a Prezi for your visual aid. Using a whiteboard while you talk. Stuff that aren’t really necessary, but they are nice to have.
So functional requirements focus in what is the software meant to do, and the nonfunctional requirements in certain qualities of the software. This qualities can be divided into two categories:
Execution qualities, such as security and usability, which are observable at run time.
Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
“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.” (SEI|CM, 2016)
Basically, Software architecture is the process of creating a blueprint of your program. What will be its functionalities, applications, method, designs, etc. The main difference between Software Architecture and Software Design is that the architecture will demonstrate what the system will do, and the design will show how it will do it. Software architecture is represented on a high-scale abstract style; henceforth, is just a guide to show developers what the system is intended to do, and what it needs to work.
What am I talking about? Software design. Helping the programmer in software implementation, it is a process that transform user requirements into a suitable form.
What we know?
If you’ve been following my blog posts, we’ve already talked about SDLC, and SRS where we discussed that a document is created to specify user and software requirements. It is important to make it specific, and make use of software terms. The first step in SDLC is Software Design, which changes the view of problem into solution.
The architectural design is the most superficial and abstract version of the system. It identifies software as a bunch of components that interact with one another. This is were developers take an idea of a proposed solution.
The high-level design breaks the “multiple components” concept of the architectural design, where a view of modules is portrayed and it shows where they interact with each other.
The detailed design deals with the implementation part, and its sub-systems, bringing together both previous designs. Defines the logical structure of each module.
Modularization is used to divide a system into multiple and independent modules. These modules are expected to carrying out independent functions, and may work as the base for the entire system.
Want to know more?
Read this blog post, where there is a more thorough explanation on the topic.
Born in 1994, UML is a technique for system specification in every phase. Created by Grady Booch, James Rumbaugh, and Ivar Jacobson, it covers all main aspects of previous designing methods. The first version of UML was released in 1997, and it has been successfully used in a number of different systems for different industries. (UNAM, n.d.)
Benefits of using UML:
Improves development time
Establishes concepts and executables
Creates a modelling language used by humans and machines
Improves support and control for project management
High reuse and reduced costs
Models systems using object oriented concepts
Types of UML diagrams
Types of UML diagrams with structure diagrams coming first and behavioral diagrams starting from position 8. Click on any diagram type to visit that specific diagram type’s description (Creately, 2012).
Defining requirements can be difficult because there needs to be a distinction between functional and non-functional requirements; however, both of these requirements are important to the system, and without them the system can crash or fail. The problem is when people miss these non-functional requirements, either they know about it or not.
What is a functional requirement?
Refers mainly to the expected function of the product. Product or system features, or what the program does is what the functional requirements are. Definitely it is easier to determine the functional requirements than the non-functional because they are almost obvious.
What is a non-functional requirement?
These requirements refer mainly to the attributes that include performance, security, usability, etc. Developers usually miss these requirements because they focus mainly on the functional requirements. When addressing incorrectly these non-functional requirements, the system actually fails. For example, the lack of usability or performance can lead to frustration or system problems. This is why non-functional requirements are so important for a system to succeed.