One of the key success factors for any application or system is the way it was designed, and how easy for common users to understand how to use and interact with it and execute simple operations or tasks without prior training or manuals.
In this article, I will discuss seven key design principles introduced in Don Norman’s Design of Everyday Things. These design principles will help us design better for humans and to evaluate or critique any application design easily. The seven design principles are:
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.
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.
Software solution design process always targets the reuse of components and modules to speed up the development process, lower the project cost, and provide the customers with a faster valuable solution.
For any Software project initiation, mainly the solution architect think about if we already have a similar solution or application for the requested requirements or not. If it is possible to use some parts of the code or not. Maybe, we should search for ready-made products that we can use if a company or someone already developed this application and it satisfied our requirements.
Always, we will observe this kind of discussion for any project initiation and in solution architecture process.
In this article, we will discuss the 3 types of application software any software engineer, software project manager, technical sales, or architect should know.
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:
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 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 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.
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 IT systems and applications are everywhere now, from simple to complex systems to run basic data entry to control autonomous cars and autonomous planes and more complicated systems.
Unfortunately, after a lot of research in software process models and project management frameworks, Software and IT projects still have a very high failure rate. According to a study has been made by Mckinsey in 2012
On average, large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. That’s beside the common issues of deliverable quality of final software product according to specifications.
Another study from McKinsey in 2014 regarding how to achieve success in large, complex IT projects.
The Enterprise Architecture concept has been introduced since 1960 by Zachman. Although it is still not widely introduced for many organizations, It becomes an important topic in Information Technology community and many organizations are trying to understand how it is important to have Enterprise Architecture capability within the organization.
In this article, I will try to illustrate what is Enterprise Architecture, why it is important, and what are the existing practices for that? And how you can start?
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.
In the last couple of years, the fancy and sexy terminology the “Digital Transformation” has been used widely throughout most of the industries and become a trendy word. Over the past decade, we heard other similar words, for example, Digitizations, Information Era, Information Age, Digital Society, Information Society, Digital Business and more and more.
In my perspective, I see Digital Transformation as another marketing terminology more than a new science or knowledge. Read more →
If you attended any of Software Architectures classes or read any books regarding the Software Architecture, it is common to have buildings Architecture as an analogy to understand the main concept of the Software Architecture. We will use the same here to understand what is the style and what is the pattern
An architectural style is characterized by the features that make a building or other structure notable and historically identifiable. A style may include such elements as form, a method of construction, building materials, and regional character. Most architecture can be classified as a chronology of styles which changes over time reflecting changing fashions, beliefs, and religions, or the emergence of new ideas, technology, or materials which make new styles possible.
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 →
Did you face any situation where you have been confused between the software scope and its requirements? If YES, I think you are not alone, There are a lot of misunderstanding in software engineering practices between software scope and its requirement specifications. Most of the time, the software project missed the scope and fall in scope creep dilemma without any notice, and without the alignment with the software scope which turns the project and software to be unsuccessful.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?
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.
Quality Function Deployment was developed by Yoji Akao in Japan in 1966. By 1972 the power of the approach had been well demonstrated at the Mitsubishi Heavy Industries Kobe Shipyard and in 1978 the first book on the subject was published in Japanese and then later translated into English in 1994. 
The QFD methodology can be used for both tangible products and non-tangible services, including manufactured goods, service industry, software products, IT projects, business process development, government, healthcare, environmental initiatives, and many other applications.
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.
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.
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.