I cannot believe that in 2019 a lot of companies are still using the waterfall model. Although I knew that some rare cases of projects need a waterfall model, the cases I have noticed were not one of them. Those companies did not change their traditional implementation methodology to deliver a quicker value to their customers.
Therefore, This article will discuss two important models that can help those who are still using the waterfall to deliver a quicker value to the customers without the need to be an agile company. But, it is the first step toward the change to agile.
V-Model is mostly known as the validation and verification software development process model (The Vee Model), and It is one of the most know software development methodology. Although it is considered as an improvement to the waterfall model and it has some similarities as the process also based on sequential steps moving down in a linear way, it differs from the waterfall model as the steps move upwards after the coding phase to form the typical V shape. This V shape demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.
Software visualization is essential in the software development lifecycle to realize how the software will be conceptualized, visualized, structured, understood, and implemented. Software visualization can be defined as the art and science of generating visual representations for the various aspects of the software.
The purpose of the visualization is setting a common understanding of the system for all stakeholders, for example, business users, development team, architects, designers, …etc.
It is a part of Software architecture and design which usually needs problem-solving and planning. This may include both a low-level component, algorithm design, and a high-level architecture design. The image below can summarize the types of visualization in the software architecture, for example, if we would like to present a system of two components, it can be visualized by text visualization or graphical visualization. I think all of us can conclude that the software requirements specifications document can be a textual visualization of the system. I think yes but not only as part of this textual presentation should include the design decisions and may have pseudo code in some parts.
In this article, we will discuss different types of graphical visualization for the software that are commonly used in the software development lifecycle. Therefore, We will discuss the following diagrams and their usage:
Use Case Diagram
However, this article will not discuss how to draw these diagrams and each diagram modeling language as there are a lot of resources available online for describing the modeling and notation standards.
Software development lifecycle models have different strategies and methodologies for the software development process and I wrote about the different types of development models, please review this article for more information, we also discussed how to select the most suitable model based on your project context.
Regardless, what model you have selected, these models are sharing mostly the same development phases with different arrangements, a more or a less phase. Furthermore, they can be implemented in an iterative and incremental model.
In this article, we will discuss the most common phases across all SDLC models. I will add other articles to discuss each phase in details 🙂Read more →
I received a lot of emails and comments regarding the best software development life cycle model. So, I had to write my opinion about that.
Actually, I think there is nothing called the best in absolute general, the best for me maybe not the best for you at this moment. Similarly, there is nothing called the best SDLC model in absolute general, you need to decide which one you need to use according to the software project context and what product or software you are developing, what about your competitors? And what are the team capabilities you have?
Black box testing is generally used when the tester has limited knowledge of the system under test or when access to source code is not available. Within the security test arena, black box testing is normally associated with activities that occur during the pre-deployment test phase (system test) or on a periodic basis after the system has been deployed.
Black box security tests are conducted to identify and resolve potential security vulnerabilities before deployment or to periodically identify and resolve security issues within deployed systems. They can also be used as a “badness-ometer” [McGraw 04] to give an organization some idea of how bad the security of their system is. From a business perspective, organizations conduct black box security tests to conform to regulatory requirements, protect confidentially and proprietary information and protect the organization’s brand and reputation.
Fortunately, a significant number of black box test tools focus on application security related issues. These tools concentrate on security-related issues including but not limited to:
White box testing and analysis, by contrast with “black box” testing and analysis, that are mainly performed on the source code. Also known as glass box, structural, clear box, and open box testing.
White box analysis and tests include:
It is known as “code review,” static analysis analyses source code before it is compiled, to detect coding errors, insecure coding constructs, and other indicators of security vulnerabilities or weaknesses that are detectable at the source code level. Static analyses can be manual or automated. In a manual analysis, the reviewer inspects the source code without the assistance of tools.
Selecting a Software Development Life Cycle (SDLC) methodology is a challenging task for many organizations and software engineers. What tends to make it challenging is the fact that few organizations know what are the criteria to use in selecting a methodology to add value to the organization. Fewer still understand that a methodology might apply to more than one Life Cycle Model. Before considering a framework for selecting a given SDLC methodology, we need to define the different types and illustrate the advantages and disadvantages of those models (please see the Software Development Life Cycle Models and Methodologies).
Software development life cycle (SDLC) is a series of phases that provide a common understanding of the software building process. How the software will be realized and developed from the business understanding and requirements elicitation phase to convert these business ideas and requirements into functions and features until its usage and operation to achieve the business needs. The good software engineer should have enough knowledge on how to choose the SDLC model based on the project context and the business requirements.
Therefore, it may be required to choose the right SDLC model according to the specific concerns and requirements of the project to ensure its success. I wrote another article on how to choose the right SDLC, you can follow this link for more information. Moreover, to learn more about Software Testing life cycles and SDLC phases you follow the links highlighted here.
In this article, we will explore the different types of SDLC models and the advantages and disadvantages of each one and when to use them.
When to perform Software security analysis and tests?
Most of the software security practitioners would agree that the common practice of postponing security analysis and tests after the software implementation phase and even after it has been deployed (i.e., during its acceptance phase), makes it extremely difficult to address in a cost-effective, timely manner any vulnerabilities and weaknesses discovered during the analysis and testing process.
In the Software industry, Most of the clients have a main requirement which is
“We want the system to be secured”.
Security is a non-functional property of the system, the main goal for securing the system to make this system dependable. So, we can depend on this system and it can perform its excepted functions as required and specified.
Therefore, it is mandatory to run the security testing procedures to ensure that we can depend on this system, but we need also to consider some functional requirements on writing requirements specifications document that help to obtain this goal.
Interviewing is one of the most important and popular requirements elicitation and requirements discovering techniques. Therefore, before making any interview, we should prepare for it. The preparation of the interview is an important factor for increasing the chance of making a successful interview and successful business analysis.
“We have two ears and one mouth so that we can listen twice as much as we speak.” Epictetus quotes (Greek philosopher associated with the Stoics, AD 55-c.135)
In human natural life, we are listening most of the time more than we speak, while this is called discriminative and passive listening which you are listening to voices with different level of sound and including the body language, but we need to control how to listen and when to concentrate on listening by managing and understanding listening skill especially on a career like analyst.
The Business Analyst is a key role in any software project and he is responsible mainly for the output from the analysis which phase is critical for the software project success, in this article we will discuss 5 core competencies that business analyst should have. let us go through them.
Creative thinking is the process by which we generate new ideas, imagine possibilities, and find relationships among seemingly unrelated concepts.