Coding: Coding, also known as programming, is the process of designing and building executable computer programs to accomplish

a specific task or solve a particular problem. It involves writing a set of instructions or code using a programming language that a
computer can understand and execute. The goal of coding is to create software applications, websites, or other computational
solutions. Coding Guidelines: The following are some representative coding guidelines recommended by many software
development organizations. 1. Do not use a coding style that is too clever or too difficult to understand: Code should be easy
to understand. Many inexperienced engineers actually take pride in writing cryptic and incomprehensible code. Clever coding can
obscure meaning of the code and hamper understanding. It also makes maintenance difficult. 2. Avoid obscure side effects: The
side effects of a function call include modification of parameters passed by reference, modification of global variables, and I/O
operations. An obscure side effect is one that is not obvious from a casual examination of the code. Obscure side effects make it
difficult to understand a piece of code. 3. Do not use an identifier for multiple purposes: Programmers often use the same identifier
to denote several temporary entities. For example, some programmers use a temporary loop variable for computing and a storing
the final result. The rationale that is usually given by these programmers for such multiple uses of variables is memory efficiency,
e.g., three variables use up three memory locations, whereas the same variable used in three different ways uses just one memory
location. 4. The code should be well-documented: As a rule of thumb, there must be at least one comment line on the average for
every three-source line. 5. The length of any function should not exceed 10 source lines: A function that is very lengthy is usually
very difficult to understand as it probably carries out many different functions. For the same reason, lengthy functions are likely to
have disproportionately larger number of bugs. 6. Do not use goto statements: Use of goto statements makes a program
unstructured and very difficult to understand. DFD: Data flow diagram is a graphical representation of data flow in an information
system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about
how data flows through the system. Types of DFD: Logical DFD- 1. Logical DFD depicts how the business operates. 2. The
processes represent the business activities. 3. The data stores represent the collection of data regardless of how the data are stored.
4. It’s how business controls. Physical DFD- 1. Physical DFD depicts how the system will be implemented (or how the current system
operates). 2. The processes represent the programs, program modules, and manual procedures. 3. The data stores represent the
physical files and databases, manual files. 4. It show controls for validating input data, for obtaining a record, for ensuring successful
completion of a process, and for system security. Class Diagram: Class diagram is a static diagram. It represents the static view of
an application. Class diagram is not only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application. Class diagram describes the attributes and operations of a class and also
the constraints imposed on the system. The class diagrams are widely used in the modeling of object-oriented systems because they
are the only UML diagrams, which can be mapped directly with object-oriented languages. Components: Class: Represents a
blueprint for objects. It includes the class name, attributes, and methods. Attributes: Represents the data members or properties of
a class. Each attribute has a name and a data type. Methods: Represents the operations or behaviors that the objects of the class
can perform. Each method has a name, parameters, and a return type. Visibility: Indicates the accessibility of a class member
(attribute or method) from outside the class. Common visibilities include public (+), private (-), and protected (#). Association:
Represents a relationship between two or more classes. It shows how objects of one class are connected or related to objects of
another class. Association can have a multiplicity to denote the number of instances involved in the relationship. Inheritance
(Generalization): Represents an "is-a" relationship between classes. It signifies that one class (subclass or child class) inherits the
attributes and behaviors of another class (superclass or parent class). Interface: Represents a contract for a class, specifying a set
of methods that must be implemented by any class that implements the interface. Shown as a dashed line with a lollipop symbol.
Use Case Diagram: A UML use case diagram is the primary form of system/software requirements for a new software program
underdeveloped. Use cases specify the expected behavior (what), and not the exact method of making it happen (how). Use cases
once specified can be denoted both textual and visual representation (i.e., use case diagram). A key concept of use case modeling
is that it helps us design a system from the end user's perspective. Testing: Testing a program consists of providing the program
with a set of test inputs (or test cases) and observing if the program behaves as expected. If the program fails to behave as expected,
then the conditions under which failure occurs are noted for later debugging and correction. Software Validation: Validation is
process of examining whether or not the software satisfies the user requirements. It is carried out at the end of the SDLC. If the
software matches requirements for which it was made, it is validated. Validation ensures the product under development is as per
the user requirements. Validation answers the question – "Are we developing the product which attempts all that user needs from
this software?". Validation emphasizes on user requirements. Software Verification: Verification is the process of confirming if the
software is meeting the business requirements, and is developed adhering to the proper specifications and methodologies.
Verification ensures the product being developed is according to design specifications. Verification answers the question– "Are we
developing this product by firmly following all design specifications?" Verifications concentrates on the design and system
specifications. BlackBox Testing: It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester
in this case, has a set of input values and respective desired results. On providing input, if the output matches with the desired results,
the program is tested ‘ok’, and problematic otherwise. Techniques: Equivalence class, Boundary values, Cause-effect graphing,
Pair-wise Testing, State-based testing. WhiteBox Testing: It is conducted to test program and its implementation, in order to improve
code efficiency or structure. It is also known as ‘Structural’ testing. In this testing method, the design and structure of the code are
known to the tester. Programmers of the code conduct this test on the code. Techniques: Control-flow testing - The purpose of the
control-flow testing to set up test cases which covers all statements and branch conditions.Data-flow testing - This testing technique
emphasis to cover all the data variables included in the program. It tests where the variables were declared and defined and where
they were used or changed.

Properties of good SRS: Concise. The SRS document should be concise and at the same time unambiguous, consistent, and
complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities. Structured. It should be well-
structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions
to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to
make the modifications to the SRS document easy, it is important to make the document well-structured. Black-box view. It should
only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify
the external behavior of the system and not discuss the implementation issues. The SRS document should view the system to be
developed as black box, and should specify the externally visible behavior of the system. For this reason, the SRS document is also
called the black-box specification of a system. Conceptual integrity. It should show conceptual integrity so that the reader can easily
understand it. Response to undesired events. It should characterize acceptable responses to undesired events. These are called
system response to exceptional conditions. Verifiable. All requirements of the system as documented in the SRS document should
be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation.
UI Requirements: User interface requirements are briefly mentioned below - Content presentation, Easy Navigation, Simple
interface, Responsive, Consistent UI elements, Feedback mechanism, Default settings, Purposeful layout, strategically use of color
and texture, Provide help information, User centric approach, Group based view settings. Decision Tree: A decision tree gives a
graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree
represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition.
Example: - Consider Library Membership Automation Software (LMS) where it should support the following three options: New
member: Decision: When the 'new member' option is selected, the software asks details about the member like the member's name,
address, phone number etc. Action: If proper information is entered then a membership record for the member is created and a bill
is printed for the annual membership charge plus the security deposit payable. Renewal: Decision: If the 'renewal' option is chosen,
the LMS asks for the member's name and his membership number to check whether he is a valid member or not. Action: If the
membership is valid then membership expiry date is updated and the annual membership bill is printed, otherwise an error message
is displayed. Cancel membership: Decision: If the 'cancel membership' option is selected, then the software asks for member's
name and his membership number. Action: The membership is cancelled, a cheque for the balance amount due to the member is
printed and finally the membership record is deleted from the database. 4+1 View Model: Logical View: 1. Concerned with the
functionality that the system provides to end-users. 2. Describes the high-level design of the system in terms of modules, classes,
and their relationships. 3. Shows the key abstractions and their interactions. Process View: 1. Focuses on the dynamic aspects of
the system, emphasizing the processes or tasks that execute concurrently. 2. Describes the system's runtime behavior and how
processes communicate with each other. 3. Includes aspects such as concurrency, distribution, and synchronization. Physical View:
1. Concerned with the system's physical architecture and how software components are mapped onto the hardware. 2. Describes
the deployment of software components on different machines or nodes. 3. Addresses issues related to performance, scalability, and
distribution. Development View: 1. Concerned with the organization of the software into modules or components and the
development process itself. 2. Describes the software development environment, tools, and the organization of the development
team. 3. Includes aspects such as source code organization, version control, and development workflows. Scenarios (Use Cases)
View: 1. Provides a set of scenarios or use cases that illustrate and validate the architecture. 2. Shows how the system behaves in
specific situations or under certain conditions. 3. Helps to ensure that the architecture meets the requirements and expectations of
stakeholders. Functional Requirements: Functional requirements define the specific features and functionalities that a software
system must provide. They describe what the system is supposed to do in terms of input, processing, and output. Functional
requirements typically include details about the system's behavior, data manipulation, and interactions with external entities.
Examples of functional requirements might include: User authentication and authorization mechanisms, Data input validation and
processing rules, Report generation and data export features, Specific operations or functions the software should perform. Non-
Functional Requirements: Non-functional requirements, on the other hand, specify the qualities or attributes that characterize the
system's operation, rather than its specific behaviors. Non-functional requirements are often related to performance, reliability,
security, usability, and other aspects that contribute to the overall quality of the software. Examples of non-functional requirements
include: Performance: Response time, throughput, and scalability requirements. Reliability: Availability, fault tolerance, and system
stability criteria. Security: Authentication, authorization, and data protection measures. Usability: User interface design, accessibility,
and user experience expectations. Maintainability: Code readability, modularity, and ease of future enhancements. W5HH Principle:
A series of questions that lead to a definition of Project Scope. Why is the software being built? What will be done? - What are the
activities that needed to be done? When will it be done? Different deadlines. Who is responsible for a function? Who will do what,
which part will be done internally, and which part externally? Where are they organizationally located? Where is the vendor located?
How will the job be done technically and managerially? How much of each resource is needed? Workforce, hardware, etc. Client
Server Model: The Client-server model is a distributed application structure that partitions task or workload between the providers
of a resource or service, called servers, and service requesters called clients. In the client-server architecture, when the client
computer sends a request for data to the server through the internet, the server accepts the requested process and deliver the data
packets requested back to the client. Client: When we talk the word Client, it means to talk of a person or an organization using a
particular service. Similarly in the digital world a client is a computer (Host) i.e., capable of receiving information or using a particular
service from the service providers (Servers). Servers: Similarly, when we talk the word Servers, It mean a person or medium that
serves something. Similarly in this digital world a Server is a remote computer which provides information (data) or access to particular
services.
MVC pattern: Model: The Model represents the application's data and business logic. It is responsible for managing the data,
processing it, and notifying the View of any changes. The Model does not directly interact with the user interface or handle user input;
instead, it focuses on the application's underlying functionality and state. View: The View is responsible for presenting the data to
the user and displaying the user interface. It receives updates from the Model and reflects any changes in the data. The View is
passive and does not handle the application's logic or data manipulation; instead, it delegates such responsibilities to the Controller.
Controller: The Controller acts as an intermediary between the Model and the View. It handles user input, processes it, and updates
the Model accordingly. The Controller also receives notifications from the Model about changes in data and updates the View to
reflect those changes. In essence, the Controller manages the flow of information between the Model and the View, ensuring
separation of concerns. Denial of Service (DoS): In a DoS attack, the attacker attempts to disrupt or disable a service by
overwhelming it with a flood of requests or traffic. This can be achieved by sending a large volume of traffic to a single target,
exploiting vulnerabilities in the target's system or network. The goal is to exhaust the target's resources such as bandwidth, processing
power, or memory, causing a service outage. Common methods used in DoS attacks include: Flooding attacks: Sending a high
volume of traffic to overwhelm the target. Protocol attacks: Exploiting vulnerabilities in network protocols to disrupt communication.
Application layer attacks: Overloading specific services or applications to render them inaccessible. Distributed Denial of Service
(DDoS): DDoS attacks are similar to DoS attacks but involve multiple sources or devices, forming a distributed network (botnet)
controlled by the attacker. By coordinating the attack from multiple locations, DDoS attacks are more potent and challenging to
mitigate. The distributed nature of the attack makes it difficult to trace back to a single source. Key characteristics of DDoS attacks
include: Botnets: Networks of compromised computers, often IoT devices or computers with malware, used to launch the attack.
Amplification: Exploiting vulnerabilities to amplify the volume of attack traffic. Spoofing: Faking the source addresses of packets to
make it harder to identify the origin.