Processs Models:
Waterfall Model:
The Waterfall Model is a traditional and linear approach to
software development, where progress is seen as flowing steadily downwards, like a
waterfall, through several distinct phases. the Waterfall Model is best suited for projects
where the requirements are well understood and unlikely to change. It's a methodical,
step-by-step approach to software development, but its lack of flexibility can pose
challenges in the face of evolving requirements or uncertain project scopes.
Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking
Modeling
Analysis
Design
Construction
Code
Test
Deployment
Delivery
Support
Feedback
Incremental Model:
The Incremental Model is an iterative approach to software
development where the system is built incrementally (a little more is added each time)
until the product is finished. the Incremental Model allows for a flexible and adaptive
development process. It is particularly useful when the complete system's requirements
are not well understood initially, allowing for continuous refinement and adaptation as the
project progresses. However, careful planning and management are essential to
successfully implement this model, especially concerning increment dependencies and
integration points.
Incremental Model
(Diagram)
Increment #1
Communication
Planning
Modeling
Increment #2
Construction
Dep
Communication
Planning
Modeling
Increment #3
Construction
Depl
Communication
Planning
Modeling
Construction
Dep
Prototyping Model:
The Prototyping Model is an iterative software development
approach where a prototype (a preliminary version of the software) is built, tested, and
refined based on user feedback until it meets the user's requirements and expectations.
the Prototyping Model is effective when user requirements are not clear initially or when
user feedback is crucial for the project's success. It emphasizes active user involvement,
rapid iterations, and continuous refinement, allowing for a more adaptive and user-centric
software development process. However, careful management of requirements and user
expectations is essential to maximize the benefits of this approach.
Prototyping Model
(Diagram)
Quick
Planning
Start
Communication
Modeling
Quick
Design
Deployment,
Delivery,
and
Feedback
Construction
Of Prototype
Spiral Model:
The Spiral Model is a risk-driven software development process
model that combines the idea of iterative development (prototyping) with elements of the
traditional Waterfall model. It emphasizes the importance of managing risks throughout
the software development life cycle. In summary, the Spiral Model is effective for large,
complex, and high-risk projects where early risk mitigation and client feedback are critical.
It provides a structured approach to managing uncertainties and evolving requirements
while ensuring the software development process is both flexible and adaptable.
Spiral Model
(Diagram)
Planning
Communication
Modeling
Start
Start
Deployment
Construction
6
Agile Development:
The Agile Model is an iterative and incremental approach
to software development that emphasizes flexibility, collaboration, customer feedback,
and continuous improvement. Agile methodologies promote adaptive planning and
encourage rapid and flexible responses to change. In summary, the Agile Model is a
widely adopted approach in software development due to its customer-centric focus,
flexibility, and ability to deliver high-quality products in rapidly changing environments. It
has become a cornerstone of modern software development practices, fostering
collaboration, adaptability, and customer satisfaction.
Agile Diagram:
Software Requirement Engineering:
1. feasibility study:
A feasibility study in Software Requirement Engineering is a critical
phase that assesses the practicality and viability of a proposed software project. It helps
stakeholders, including developers, project managers, and investors, make informed
decisions about whether to proceed with the project or not. The feasibility study evaluates
various aspects, ensuring the project is achievable within defined constraints.
2. Requirement gathering:
Gathering Requirements Through Interviews:
Prepare Interview Questions:
Prepare a set of open-ended questions designed to elicit detailed information about the
requirements.Questions should be clear, specific, and focused on understanding user
needs, system functionalities, constraints, and expectations.
Conduct Interviews:
Schedule and conduct interviews with stakeholders individually or in groups.Listen
actively, encourage participants to express their thoughts freely, and ask follow-up
questions to clarify ambiguous points.
Advantages of Interviews in Requirement Gathering:
In-Depth Understanding:
Interviews allow for in-depth exploration of requirements,
providing a detailed understanding of stakeholder needs and expectations .
Clarification:
Interviewers can seek clarification and elaboration on responses in realtime, ensuring a clear understanding of requirements.
Personal Interaction:
Personal interaction builds rapport and trust, encouraging
stakeholders to share valuable insights.
Customization:
Interviewers can customize questions based on the respondent,
tailoring the conversation to specific roles or expertise levels.
Disadvantages of Interviews in Requirement Gathering:
Time-Consuming:
Interviews can be time-intensive, especially when dealing with
numerous stakeholders, leading to project delays.
Bias and Misrepresentation:
Interviewers may introduce bias or misinterpret
responses, affecting the accuracy of gathered requirements.
Limited Scalability:
Interviews may not be practical for large-scale projects involving
a vast number of stakeholders.
Cost:
Organizing and conducting interviews can be costly, particularly if extensive
travel or specialized expertise is required.
3. Gathering Requirements Through Surveys:
Design the Survey:
Create a well-structured questionnaire. Questions should be clear,
concise, and focused on gathering relevant information.Use a mix of question types:
multiple choice, Likert scale (for measuring opinions), and open-ended questions (for
additional insights).
Distribute the Survey:
Choose appropriate survey distribution methods, such as
email, online survey platforms (like SurveyMonkey, Google Forms), or specialized survey
software.Ensure clear instructions are provided to participants on how to complete the
survey.
Collect Responses:
Collect responses within a defined timeframe. Send reminders to
participants to maximize response rates.
Analyze the Data:
Analyze the survey responses to identify patterns, trends, and
common themes.Use statistical analysis for quantitative data and thematic analysis for
qualitative responses.
Advantages of Surveys in Requirement Gathering:
Scalability:
Surveys can reach a large number of participants simultaneously, making
them ideal for gathering input from diverse stakeholders.
Efficiency:
Surveys are time-efficient, allowing participants to respond at their
convenience.
Anonymity:
Anonymity can encourage participants to provide honest feedback,
especially on sensitive topics.
Data Quantification:
Surveys generate quantifiable data, making it easier to analyze
and identify trends.
4. Gathering Requirements Through SRS:
Software
Requirement
Specification
(SRS) is a detailed document that describes the software system's purpose, functionality,
and behavior. While SRS itself is a result of requirement gathering and analysis, here's
how you can gather requirements effectively to create a comprehensive SRS in software
requirement engineering.
5. Validation :
In software requirement engineering, validation refers to the process of ensuring that the
gathered requirements accurately represent the needs and expectations of the
stakeholders. Validation is a critical step because it confirms that the documented
requirements align with the actual needs of the users and the objectives of the project.
CHAPTER # 3
Software Modularity
1 . Contex Model :
In software design and architecture, a context model is
a representation of the environment in which a system will operate. It defines the
boundaries, constraints, and interactions between a system and its external entities, also
known as stakeholders. A context model provides an overview of the system's
interactions with the external world, helping software architects and designers to
understand the system's scope and its relationships with other systems, users, hardware,
and software components.
Key elements of a context model include:
System Boundary:
Defines the scope of the system under consideration. It outlines what is
inside the system and what is outside.
External Entities:
Represent external stakeholders, which can be users, other
systems, hardware devices, or software components. These entities interact with the
system and have an impact on its behavior.
Interactions:
Describes the flow of information and data between the system and
external entities. It includes inputs, outputs, and communication protocols.
Constraints:
Specifies any limitations, rules, or restrictions imposed on the system by
the external entities. These constraints might include legal regulations, security policies,
or performance requirements.
Relationships:
Depicts the relationships between the system and external entities. For
example, it could show which external entities are clients, suppliers, or partners of the
system.
Context Diagram for Whatsap:
2. Interaction model:
In software engineering, an interaction model refers
to a representation of the way components within a system interact and communicate
with each other. It provides a high-level overview of how different modules, objects, or
components collaborate and exchange information to achieve specific functionalities
within the software application.
Here are some key aspects of the interaction model in software modeling:
Component Interaction:
Describes how different components of the system interact
with each other. Components can be modules, classes, objects, or even services in a
distributed system.
Message Passing:
Defines the method by which components exchange information.
This could involve method calls, events, messages, or any other form of communication.
Sequence of Interactions:
Specifies the order in which interactions occur. It outlines
the flow of control and data between components during the execution of a particular
functionality.
Interfaces:
Describes the methods, properties, and behaviors that components expose
to interact with other components. Interfaces define a contract between components,
ensuring that they understand how to communicate with each other.
Collaboration Diagrams:
Visual representations, such as UML (Unified Modeling
Language) sequence diagrams or communication diagrams, are often used to depict
the interactions between components. These diagrams show the sequence of
messages or method calls between objects or components over time.
Synchronous and Asynchronous Interactions:
Describes whether interactions
occur in a synchronous (blocking) or asynchronous (non-blocking) manner. Synchronous
interactions require the sender to wait for a response, while asynchronous interactions
allow the sender to continue its work without waiting for a response.
USE CASE DIAGRAM OF WHATSAP
3. Data Driven Model/DFd:
What is a Data Flow Diagram:
A data flow diagram (DFD) maps out the flow of information for any process or system. It
uses defined symbols like rectangles, circles and arrows, plus short text labels, to show
data inputs, outputs, storage points and the routes between each destination.
Symbols and Notations Used in DFDs:
Using any convention’s DFD rules or guidelines, the symbols depict the four
components of data flow diagrams.
1. External entity:
an outside system that sends or receives data, communicating
with the system being diagrammed. They are the sources and destinations of information
entering or leaving the system.
2. Process:
any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business rules.
3. Data store:
files or repositories that hold information for later use, such as a database
table or a membership form.
4. Data flow:
the route that data takes between the external entities, processes and
data stores. It portrays the interface between the other components and is shown with
arrows.
Level 0 DFD of online banking System :
Level 1 Data Flow Diagram for Online Banking System:
Level 2 Data Flow Diagram for Online Banking System:
4. Structural Models:
Structural Models, also known as Component Models or
Static Models, depict the static structure of a software system. They focus on representing
the system’s components, such as classes, modules, subsystems, and their relationships,
to provide a clear understanding of the system’s organization and dependencies.
Why are Structural Models Important?
System Understanding:
Structural Models serve as visual blueprints that help
stakeholders, developers, and architects understand the system’s architecture,
component hierarchy, and the interactions between different elements.
Design Validation:
By creating Structural Models early in the software development
process, architects can validate and refine the system’s design, ensuring that it meets the
desired functional and non-functional requirements.
Collaboration:
Structural Models act as a common language for communication among
team members. They facilitate discussions, enable better collaboration, and aid in
identifying potential design issues or bottlenecks early on.
A class notation consists of three parts:
Class Name:
The name of the class appears in the first partition.
Class Attributes:
Attributes are shown in the second partition.
The attribute type is shown after the colon.
Attributes map onto member variables (data members) in code.
Class Operations (Methods):
Operations are shown in the third partition. They are services the class provides.
The return type of a method is shown after the colon at the end of the method signature.
The return type of method parameters is shown after the colon following the parameter
name.Operations map onto class methods in code
CLASS DIAGRAM of Whatsap: