In Software Engineering, we chant the term of validation and verification a lot between the software team members. Actually, it is used across the software project phases and I think there is a misconception in understanding the two terminologies and when to use them.
Most of the Software companies large, medium, small, or startup usually face issues in their software development projects and its delivery. The issues can vary from lack of documentation, lack of following the process, lack of process governance, lack of the integration and collaboration between the teams, lack of requirements traceability, lack of technology management, …etc.
We have discussed in a previous post the trends of software projects and that large software projects on the average run 66% over budget and 33% over schedule; as many as 17% of projects go so badly that they can threaten the existence of the company.
Therefore, some methods and techniques started to exist to tackle the software process issues to suggest different improvements and identify issues and inefficiencies in the process. These methods became a standard which the companies can follow to improve their software process. Moreover, each method established its ecosystem, from providing the training and certificates for the method to provide consultancy to help companies to improve based on actual practices.
In this article, It will be good to ask yourself if the software process improvement is a peril to have or a promise for a better change for the organization and to have a superior advantage in the market. For answering this, we will discuss in this article what is SPI?, what is the SPI process steps? what are the different methods?, the motivators and demotivators of SPI projects, what are the common success factors for SPI project implementation?
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:
- Context Diagram
- Use Case Diagram
- Activity Diagram
- Class Diagram
- Entity-Relationship Model
Software Testing is vital for any software development life cycle, it is fundamental to ensure the software quality and to have a workable functional software at the end of the project.
“Testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results” Bill Hetzel, 1988
The main motive for the testing is to ensure that all functionalities are working correctly as per the requirements. It is not only that this is the basic purpose of testing, while It is important to test how to break the system, how to simulate the abuse of the system by the quality team before someone else does that for you and it will be a disaster at this time.
Each one of us is surrounded by people, for example, families, friends, coworkers, or clients. These people are affecting our lives in a positive or negative way that shapes our personality as well. This kind of relationship with people needs a proper communication and management since this communication takes a big percentage of our life. Some studies point out that we spend an average of 70% of our day listening to others and an average of 30% speaking to them.
Similarly, strategic planning, architecture, project management, and other fields are powered by people, people who envision, plan, analyze, design, manage, execute, operate, …etc. Communication with those kinds of people should be managed effectively to ensure that every person not only informed but also involved and contributing to the process whatever it is. We mainly aim to those people as the stakeholders.
In this article, we will discuss who are the stakeholders, and why managing them is important, and how we should do that.
What is the Waterfall Model (Waterfall Methodology)?
It is mostly known as the traditional software development process model, widely used until now, and the most popular SDLC model and the one you should avoid to use. Moreover, it was the first introduced presentation of the software lifecycle.
You can read this Wikipedia page to know the waterfall model history.
The Waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement.
In this article, we will discuss the advantages and disadvantages of the waterfall, should we avoid it? when to use it? and the waterfall model pitfall, and why I see it as the father of the SDLC models.
The software development effort estimation is an essential activity before any software project initiation. In this article, I will illustrate how to easily estimate the software effort using known estimation techniques which are Function Points Analysis (FPA) and Constructive Cost Model (COCOMO).
The system should be easy to use.
The system should be flexible and scalable.
The system should be secured.
The system should be portable.
Did you read any requirements document and found one of the requirements statement mentioned above? Then, you started to think, what does it mean to make the software ease of use, how can I make that feasible, if I implemented that feature would the software became more usable? would it be acceptable to the customer? What are the metrics and acceptance criteria for that? How to transform these intangible requirements into something tangible can be implemented and measured.
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? Read more
There is no doubt how the architecture is important to shape the solution and define its characteristics in the different architecture domains, and how this solution will be adaptable and dynamic to absorb new business needs and handle different stakeholders’ concerns.
In most architecture development processes, different decisions are taken in the different architecture domains. Architects may make different decisions, such as choosing a specific component, in the conceptual architecture and follow a specific architecture pattern.
I created consolidated slides to illustrate most of the popular software development models. I hope that you will like it. Read more
Over the past 10-15 years, Software architecture has been widely spread in the software engineering community, To the extent that there are currently many career positions for software architect like Technical Architect and Chief Architect. Also, Architecture has involved in many different domains, for example, the architecture used to describe and refer to the internal structure of microprocessor and structure of machines or Network. For that matter, Trying to find one widely accepted definition for software architecture is not easy, and this issue has been introduced in many books when the authors start defining software architecture. Read more
Black box techniques are the only techniques available for analyzing and testing non-developmental binary executable without first decompiling or disassembling them. Black box tests are not limited in utility to COTS and other executable packages: they are equally valuable for testing compiled custom developed and open source code, enabling the tester to observe the software’s actual behaviors during execution and compare them with behaviors that could only be speculated upon based on extrapolation from indicators in the source code. Black box testing also allows for examination of the software’s interactions with external entities (environment, users, attackers)—a type of examination that is impossible in white box analyses and tests. One exception is the detection of malicious code. On the other hand, because black box testing can only observe the software as it runs and “from the outside in,” it also provides an incomplete picture. Read more
What is white box testing?
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. Read more
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. Read more
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. Read more
What did they say about Software security testing?
“Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” Gartner.
“Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money” Counterpane Internet Security.
“64 percent of developers are not confident in their ability to write secure applications” Microsoft Developer Research.
“Losses arising from vulnerable web applications are significant and expensive – up to $60 billion annually”IDC/IBM Systems Sciences Institute.
“If 50 percent of software vulnerabilities were removed prior to production use, enterprise configuration management and incident response costs would be reduced by 75 percent each.”Gartner.
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. Read more
“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. Read more
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.