A quick summary upto what we did this far  from this series:

Software Engineering

Software engineering is a discipline of engineering concerned with the creation of software products based on well-defined scientific concepts, methodologies, and procedures. Software engineering produces an effective and dependable software output.

Software Development Models

Waterfall

It is useful when the requirements are explicit or when following a highly structured process, such as in critical systems that require extensive, exact, and accurate documentation to describe the system to be developed.

Not acceptable when criteria are vague and do not allow for frequent interaction with consumers for feedback and change proposals. It is not appropriate for major projects that may take a long time to create and deliver.

Prototype

It is, once again, an early sample or release of a product designed to test a concept or serve as a thing to be duplicated or learned from.

When needs are unclear, and interactions with the client and experimentation with an early version of the programme result in high satisfaction and clearance of what is to be implemented, this is highly valuable.

Its disadvantage is that appropriate tools for rapid development (such as coding) are required to produce a prototype. Furthermore, the expenditures of training the development team in prototyping may be prohibitively expensive.

Incremental & Iterative

They are appropriate for large projects and are less expensive to change requirements because they facilitate customer interactions with each increment.

Early versions of the programme are generated to allow for customer review and feedback.

They are not appropriate for tiny projects or those for which waterfall is best suited; A organized approach that includes a thorough and accurate description of the system.

Spiral

It's ideal for high-risk or huge projects with uncertain needs. The risks could be related to cost, schedule, performance, user interfaces, and so on.

Risk analysis necessitates highly specialised knowledge, and the risk analysis phase is critical to the project's success. It is ineffective for smaller tasks.

Agile

It is best suited for small to medium-sized projects with frequent changes in requirements because the customer is involved throughout each phase.

The project requires very little planning to get started. It saves the company both time and money (as a result of customer physical interaction in each phase). Productivity can be measured thanks to the daily meetings.

It is difficult to scale up to large projects that require documentation. A highly qualified crew is also required.

If team members are not committed, the project will either fail or never be completed. And there is always a time constraint, such as in increments, meetings, and so on.

Software Design And Implementation

The process of transforming a system specification into an executable system is known as the implementation step. If an incremental method is employed, the software specification may also be refined.

A software design is a description of the structure of the software to be implemented, data models, system interfaces, and possibly the techniques utilized.

The software designers iteratively construct the programme design, adding formality and detail and correcting the design as they go.

Here's an abstract representation of the design process that shows the inputs, actions, and output documents.

The software design process — From Software Engineering, 9th edition, Chapter 2, by Ian Sommerville

The diagram implies that the stages of the design process are ordered. They are, in reality, intertwined. In any design process, feedback from one stage to the next and rework are unavoidable.

These actions may differ based on the sort of system that needs to be created. We've demonstrated four major actions that could be part of the information system design process, and they are as follows:

1. Architectural design: It defines the overall structure of the system, the main components, their relationships.
2. Interface design: It specifies the interfaces between these elements. The interface specification should be precise. As a result, a component can be utilized without being aware that it is implemented. The components can be planned and developed concurrently after the interface definition is agreed upon.
3. Component design: Take each component and design how it will work, leaving the specific design to the coder, or make a list of changes to a reusable component.
4. Database design: The system data structures are designed, and their database representation is determined. This is determined by whether an existing database will be utilized or if a new database will be built.

These actions result in a set of design outcomes. The level of detail and depiction varies according to the system being created.

In critical systems, for example, detailed design documentation that provides a clear and accurate description of the system must be prepared.

These outputs may be graphical models of the system, and in many situations, code is generated automatically from these models.

Software Verification And Validation

Software validation, or, more broadly, verification and validation (V&V), is meant to demonstrate that a system both conforms to its specifications and meets the customer's expectations.

Validation may also include verification activities such as inspections or reviews at each stage of the software development process, from requirements definition to software development.

An essential validation technique is testing, which involves running the system with simulated test data.

The stages of testing — From Software Engineering, 9th edition, Chapter 2, by Ian Sommerville

Testing has three main stages:

1. Development (or component) testing: The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components.
2. System testing: System components are integrated to create a complete system. This process is concerned with finding errors that result from interactions between components. It is also concerned with showing that the system meets its functional and non-functional requirements.
3. Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than using simulated test data. It may reveal errors in the system requirements definition.

Components may be simple entities such as functions or object classes, or may be coherent groupings of these entities. Test automation tools, such as JUnit are commonly used to run component tests.

Component development and testing techniques are frequently linked. Programmers commonly build their own test data and test the code as they write it.

In certain cases, tests are written alongside the requirements before development begins. This helps testers and developers understand the requirements and identifies faults with the requirements.

Testing is directed by a set of test plans created from the system specification and design when employing a plan-driven development process.

The "V-model" software process model depicts how test plans are the link between each phase of the development life cycle and its associated testing phase.

Testing phases in a plan-driven software process — From Software Engineering, 9th edition, Chapter 2, by Ian Sommerville

What is Black Box testing?

In Black-box testing, a tester doesn’t have any information about the internal working of the software system. Black box testing is a high level of testing that focuses on the behavior of the software. It involves testing from an external or end-user perspective. Black box testing can be applied to virtually every level of software testing: unit, integration, system, and acceptance.

What is White Box testing?

White-box testing is a testing technique which checks the internal functioning of the system. In this method, testing is based on coverage of code statements, branches, paths or conditions. White-Box testing is considered as low-level testing. It is also called glass box, transparent box, clear box or code base testing. The white-box Testing method assumes that the path of the logic in a unit or program is known.

Software Maintenance

Even after the system has been put into operation, requirements are constantly changing. One of the primary justifications for the usage of software in large, complicated systems is its flexibility.

Historically, there has always been a distinction between the processes of software development and software evolution (software maintenance).

This divide, however, is becoming increasingly meaningless, and it makes far more sense to see development and maintenance as a continuum.

It is more reasonable to think of software engineering as an evolutionary process in which software is constantly altered over its lifespan in response to changing requirements and user needs.

References:

• Software Engineering, 9th edition, Chapter 2, Ian Sommerville — A highly recommended comprehensive textbook on software engineering.
• Software Engineering — Software Process Activities (Part 3)