The world knows manufacturing since almost the age of human beings on earth by creating different tools to help in their daily living routines. It was not at scale at the time but it is a sort of manufacturing process.
The manufacturing process has been advanced starting with Industry 1.0 until reaching Industry 4.0 with the mix of advanced technology, data & AI to improve the manufacturing process and strengthen the factory of the future with many innovative scenarios of full automation, connected supply chain, predictive maintenance, and others.
Going deeper into the manufacturing process, I found that there are lots of similarities in objectives, concerns, and challenges with the software engineering development process. This beauty of knowing the similarities and differences can make us learn how we can use the combined knowledge of two different industries to bring more innovation and efficiency for both.
In this article, I discuss from my observation what are similarities and the learning between both processes. To make good anatomy of the two, let us see them from different aspects
The rapid advancement of technology is never stopping, technology is never meant to be related to the information technology industry. Technology has been there since the beginning of human culture, when creating a fire to warm people to prevent animal attacks was a sort of technology to get this spark that will initiate the fire. The people at this age were developing technology that was important for their survival.
Technology is the use of scientific knowledge for practical purposes or applications. Whenever we use our scientific knowledge to achieve some specific purpose and adding more value to simplify our tasks, activities, or work, we’re using technology.
Technology usually involves a specific piece of equipment or a tool, but that equipment can be incredibly simple or dazzlingly complex. It can be anything from the discovery of the Axe to facilitate farming, all the way up to robotics, AI, and spaceships.
DevOps is one of the very popular terminologies especially in software development companies and there are many misunderstandings about what is DevOps, is it and new Software Development Life Cycle (SDLC), is it Agile or does it improve process agility, it is a role inside the team or what is the DevOps and how this can improve software delivery.
The big challenge
As we know that software after implementation and delivery, is used by the end-users inside the organization, it needs to be maintained and also operated, not only that it needs to be enhanced with the time until it is decommissioned or replaced with a new software powered by new technologies.
Most of the time, the team that manages the development, is different than who manages quality, and as well is different than who manages security, deployments, operations, and maintenance. Each team may have different objectives, leaders, and performance indicators. This led that the teams may compete more than collaborate and this often creates the blame culture and mindset.
This kind of siloed vertical disciplines inside the team, created a huge delay in the process, manual checks, and reviews, and even every team needs to deliver his work to the team after that in the process.
Whether it is Waterfall or Agile, software development contains almost the same steps, from analysis, design, development, testing, deployment, operations, and maintenance. Each SDLC deals with these steps in different ways according to the SDLC principles and planning. While most of the companies moved to Agile, they used the same team structures from Silos that every member is focusing on a specific area from these steps.
Although adopting Agile principles focus on enhancing the end-to-end development process by eliminating the issues in traditional software development lifecycles, the same challenges in managing the operations were still there and DevOps’ main purpose is to overcome those challenges.
A friend used to tell me a Prophetic Hadith that “One who is consulted is entrusted.” as a reminder when he/she wants to take advice in a personal matter or work-related advice. It means when I ask you for advice, then I gave you enough trust to give me good advice.
It was narrated from Abu Hurairah that the Messenger of Allah(ﷺ) said: “One who is consulted is entrusted.”
The Messenger of Allah(ﷺ)
When you became requested to give any advice, it means that the other person is trusting you and seeking your advice for help.
It is not easy to become a trusted advisor without a strong relationship, and this strong relationship needs time. The time can be short or very long according to the advisor’s capabilities and the other party who is seeking and receiving the advice.
In most of our daily conversations and discussions, whether with coworkers, friends, or family members, we argue and exchange opinions and recommendations, and suggestions.
Sometimes, we want an agreement on our opinion and assure that those shared thoughts and opinions are heard and applied. So, we try to persuade and convince others, and we try to minimize the resistance against our opinion for our own interest irrespective of the implied loss to others, or for all of our interests and have a beneficial outcome for all, that satisfies each one’s concerns.
This process of going back and forth discussion to reach an agreement between two parties or more is called negotiation. When you are asking someone to get you a cup of tea, asking your kids to do something or study, proposing a solution to a customer, discussing your job offer with an employer, asking your team to do certain tasks, and lots of other similar examples that we are doing daily without noticing, all are NEGOTIATIONS.
Negotiation is when a person wants another person to do or not do something for him or her.
Throughout my career in the information technology industry, I have observed different aspects which turned to be a set of personal principles and beliefs that I consider at any digital solution implementation that I would like to share with the community, I am sure they will resonate with you.
1- There are no IT projects
If you are working in the IT department in your organization, you will always hear common words, such as, the Business team wants, and business team needs, we need to align with business strategy, the Business team wants to work remotely, the Business team is considering our department as an isolated island that is not aligned with what we need. With time, you will see the shadow IT, and the business team will start to use their skills, and get any ready-made tools to finish their tasks to not face a bottleneck from the IT department.
This is mainly because IT staff is still thinking of these projects as IT projects, and the business team is seeing IT as a cost center that only consumes lots of money and resources without a return as per the business expectations.
Any work that we are doing, even if it’s done by individual efforts, will affect others in some way. The affected other side is the end customer who is concerned about benefits and results from this work. The end customer can be a consumer, a citizen, an organization with complex teams, or even a collection of all.
I believe that working individually or within a team(s) needs a different mindset shift that can have more understanding, empathy, active listening, collaboration, and appreciation.
This kind of relationship should be from both sides, not only you as who is doing the work but you as who is receiving the end results of this work. We are always facing challenges while delivering and observing teams that are complaining about the customers and how tough they are, how the customers provide vague and unclear requirements, how the customers want to change their needs without paying costs, how the customers are not appreciating the efforts.
Many complaints, sometimes I actually feel the same, and I become very frustrated. In these situations, you need to pause, rethink again, emphasize, and see what is the outcome of this tension, what are the trade-offs we should take, and what are the implications of our actions in the long term relationship with that customer.
It is not always on the customer side, it is also inside the team who is carrying out the implementation, and this team’s understanding and how the team is showing empathy.
Many times, I see individual members of the team who are seeing the customer as ignorant, they do not understand, they are seeing themselves as the experts in the situation and the customer is outdated. Sometimes, team members quit the project, or a company does not want to work again with that customer because of how tough was the process and the relationship between the teams.
Changing the mindset is not something easy, it may need changing our way of analyzing, engaging, implementing, negotiating, contracting, and many aspects that can support the healthy relationship on both sides between the implementers and the customer for better end delivery.
So, I wanted to list different mindset shift factors that can affect the way we think from both sides to deliver better usable solutions. I am using the client to indicate the end-user(s) who will be involved to provide their needs and requirements, impacted by the change introduced by the solution, and concerned by the outcomes of this solution. The implementers who present the teams that are responsible for the implementation and delivery of the solution. These two sides can be in the same organization or two different organizations, below is the summary of these factors:
Client-Vendor relationship mindset
The expert mindset
The learner mindset
My way or the highway mindset
Listening to act, and take the right action
Understanding and empathy mindset
Everything is important mindset
Solution boundaries mindset
limitless alternatives mindset
Unbounded scope mindset
Realistic and focused scope mindset
Rigid scope mindset
Adaptive & dynamic scope mindset
Project Management mindset
Product Management mindset
Scope management mindset
Expectations and Value management mindset
The Adoption Journey
Business needs as destination mindset
Operation needs and the journey mindset
Develop for test and deliver mindset
Develop for usage and operation mindset
Solution defensive mindset
Mindset Shifts Summary
In the next paragraphs, I will discuss each shift factor in detail.
The most difficult change is the change in people’s mindset, especially when they are used to perform and do the same activities for a quite long time in the same way.
People minds are usually wired to only see the value of their used traditional methods and techniques, and their daily routines. It is hard to convince them to even try to think if there is a better way to do this or that, I feel empathy with those mindsets because most of the time, this routine drags us and prevents us to pause and think about what can be improved!
I think I am lucky to have the experience before and after the internet, without and with mobile phones, traditional services & digital ones. There is no doubt how technology has enhanced and advanced our way of living and made doing things easier and achievable than before. The simplest example, you won’t be able to read this article from a different place in the world in few minutes after finishing it and translating it into your language and may ask the computer or your phone to read it for you as well.
My job is to help different organizations realizing these digital benefits and realize their digital road map and make it possible. while in this article, I would like to discuss and think with you about the possible implications on us as humans especially in this fast digital race.
I still remember when I was a 10 years old kid at the same age of my son, around 25 years gap between our ages, two and half decades that I would like to use as an analogy between the difference in the experience of my childhood versus my son’s childhood, especially that he lived only this new Information age and he is younger than the cloud computing. I would like to highlight the digital implications using two different anecdotes and discuss with you how the future may look like and if are we becoming robotic humans slowly!
Although the importance of architecture and the role of the architect in the digital-first initiatives we are living in today in the different business domains and industries, the architecture’s main vocabularies and terminologies are still not well understood due to non-acceptable widely used definitions and the different perspectives of each terminology.
In this article, I would like to deep dive into one of the fundamental vocabularies in the architecture which are around the models and modeling process, then explore the different perspectives and definitions of them. Moreover, highlight my perspectives and my agreement to the other experienced authors and architects. First, let us start with the model.
Wastes exist in many types and forms that hinder the business from operating in an optimum way. Waste management is one of the most effective ways to increase the productivity of any business while It is important to understand exactly what waste is and where it exists to eliminate it.
The waste can be defined as any action or step in a process that does not add value to the customer.
To identify these waste actions or steps, we need to understand how the business work to achieve its goals and objectives. Each business can be modeled through its services, products, capabilities, and skills that are important factors that shape the different business processes to provide those services or products and utilizing the business capabilities and skills. The process itself can add value or waste to the business.
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:
Many of DevOps teams are suffering from different attacks from people around the world who are trying to hack your website, compromise any information, robot sign up, send robots email, visit non-existing URLs.
These attacks if did not harm your application, it will increase the load on your environment and consume even the resources in not a good way. So, these attacks have to be prevented and blocked. In this article, we will discuss how to protect your ruby on rails app from suspicious and abuse attacks using simple methods which act as web application firewall (WAF) without the need to use and pay for external security services or WAF services.
Rails is a web application development framework written in the Ruby programming language that has been introduced at 2003. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks.
Ruby on Rails is one of the popular framework built on Model View Controller (MVC) architecture pattern and has a large developer community which made it robust and easy to get support.
At a former article, I have discussed the change management theories and practices through reading various research papers that discussed the change management in the organization. Change management is everywhere when there is a new project, new process, new improvements, starting a new business, or even a change of career or joining a new company. As you may know that Change management is a systematic approach to dealing with the transition or transformation of an organization’s goals, processes or technologies.
Nowadays, these transitions happen every day, new technologies, new job roles, new projects, new strategies, new challenges, and new opportunities are introduced. These transitions need a change framework to ensure proper management of this change for the benefit of the organization and the people.
In this article, I would like to discuss the types of changes to have a better understanding of the change behavior and pattern.
The software industry is considered a new industry compared to other old industries like automotive, banking, manufacturing, …etc, which makes professionals from different industries may not able to understand what is the role of the architect? what is the difference between architecture levels Why the architecture is important and when it is needed?
There is a lot of mix between the architecture roles, from enterprise architect, Business architect, data architect, system architect, infrastructure architect, software architect …etc? Moreover, there is a lot of misunderstanding about the different levels of architecture and design. Even some of the software engineers may not know the difference when each level is needed. I explained before the difference between the software architecture, software design, and software structure in this article, while it needs some extra illustration.
This article mainly will focus on why the architecture is important and when and what are the different levels from conceptual to the detailed design level from the software architecture perspective. So, let us start.
Change management theories and methods have been a hot topic for decades in strategic management, change implementation, and innovation implementation. Nowadays, in the information and technology industry, we see trends, such as, the digital transformation, digitization, automation, Digital Experience, and Customer and Citizen-centric approaches that lead to infinite change motives in the organizations and society that lead to new innovations.
Moreover, Change management projects have many different themes, for example, quality improvement, process improvement, re-engineering, reorganization, and organizations restructure. Although most of the organizations are trying to align with new trends and apply new changes effectively, the reported successful applied change projects were few and under specific circumstances and context (Kotter, 1995).
Change management is not only a theory, it is a practice that we can use not only in the organizations but within our daily lives, for example, pursuing a job or an academic scholarship, or even changing family habits. These types of motives, goals, or dreams lead to actions and a lot of hard work to satisfy these motives. I partially agree with (Dunphy 1996) who stated that:
“The basic tension that underlies many discussions of organizational change is that it would not be necessary if people had done their jobs right in the first place. Planned change is usually triggered by the failure of people to create continuously adaptive organizations”
(Dunphy 1996 as cited in Weick & Quinn, 1999)
In order to make people do their jobs right at any organization, their organization should empower them, the executives and managers should prepare those people and align their priorities with the organization strategy, and ensure that those people have the right capabilities to perform their jobs in the right way and to the intent expectation.
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.
In our daily lives, we collect or deal with different kinds of data. Almost, the data exists in any business nowadays and it presents the assets of our business, for example, in the health industry, you may need to know the data about the number appointment, the number of the doctors per specialty, the staff’ performance, the bed occupations, the mortality rate, the busiest day, the revenues, …etc.
In this article, we will define the types of data we deal with every day, and what are the measures of center and spread for data, which are powerful measurement tools to understand the data in a simple, better, and an easy way.
Absolutely, there is a dozen available ready-made tools and applications to calculate these measures easily, while I believe it is important to know how to calculate, use them and why.
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.
I read the book and I found that it very helpful and useful for sales representatives.
Personally, I have met a lot of salespeople who are selling without knowing anything about the customer needs, challenges or strategies and they are selling products features without presenting the true added value of these products. I think you may have faced the same, especially with the infrastructure and equipment vendors.
The book offers some useful techniques and tips to enhance the selling process and make it a value-driven process for both the customer and the seller. I think most of the big companies are using similar approaches and techniques mentioned in the book with different flavors.
I tried to summarize the key points which I think they are important to others while I do recommend to read this book. Here are the key lessons I learned from this book
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?
In our daily tasks, personal or work related, we usually face a situation that we have a variety of alternatives and there is a need for a decision process to pick one of them and to decide what will be the best to choose with a certain level of confidence.
These decisions can range from changing your job, selecting a candidate for a job vacancy, choosing the right software development life cycle, buy vs build decision or others. The common between all of them that they are decisions and they need a decision process.
In this article, we will discuss the process of trade-off analysis, and an example of different alternatives we need to select one of them. Read more →
Everyone uses different set tools every day at his/her workplace to finish tasks faster, organize the work, and collaborate with others. Each moment new apps and tools are created and it is becoming harder for us to select the which one to use and which one offers the basic required functionalities which enable anyone to interact and use it easily and retrieve our data at any time.
I would like to share with you a list of tools which I’m using mostly every day in my workplace and personally to organize things, explore new ideas, or even brainstorming. The good about these tools that they are free, portable, and compatible with all kind of devices. I hope you will find them useful.
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 technology revolution we are living, I’m sure that you read or heard a story about how data is changing our world. Data may cure a disease, solve a national problem, prevent a disaster, boost a company’s performance, make a team more efficient or enhance our experience.
Data is essentially the plain facts and truth collected during the operations of a business, while you are searching for some articles on the internet, using your mobile for sending a message or finding a location. Data is everywhere and increasing significantly, data is the lifeblood of decision-making and the raw material for accountability and the oil of this century!
Nevertheless, data alone cannot do that without proper understanding, analysis, visualization, transformation, and enrichment to discover the hidden power and the potential of data and reach the top of the Data Information Knowledge Wisdom (DIKW) pyramid. Read more →
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 →
Rails Framework is one of the greatest supporters for Rapid Application Development (RAD) which tends to abstract and simplify the web architecture so that Rails abstracts away the database through the Active Record which is the Object-relational mapping (ORM) for rails.
The Active Record is the layer of the system responsible for representing business data and logic. Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.
So, It helps in a way to manage all relations consistency and mapping in the class model without the need to write SQL statement to retrieve any data or the usage of CRUD (create, read, update, and delete) methods in general.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.
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.