SAD includes the creation of a system through the process of developing an

information system from a system design model. Information systems are the
medium through which programmers retrieve data from a database. The SAD
process does not include program design. To access a database, students need to
know SQL, but only in depth when using Microsoft Access. SAD is in widespread
use for business computer technology training purposes around the world. Web
Design Systems Analysis and Design (SAD) is a process of designing and making
software, we will be using SAD to design and plan the electronic appliances retailer
website.
SAD is also known as Structured Analysis and Design Technique which considers
everything related to the system analyzed and designed. The current situation should
be comprehensively scoped and analyzed. For a retailer of electronics and
appliances, this would include a look at how inventory is currently managed, what
happens when an order is placed, the current point of sale or interaction with the
customer, and so forth. As the relationship between the retailer and Rapid Response
requires a web platform to display all ontologies, the system must: be implemented
in Java (Server: JDK 8, Eclipse: Oxygen) not require a database be executed by
tomcat 8 But since it is only a web platform, so it will only be accessible with web
browser. As SAD said, the requirements should be clearly defined and should be
gather from all relevant stakeholders.
Designing: The design step in the SAD framework deals with laying the blueprint
for the proposed system. This phase mainly deals with the design of Web site
architecture, user interfaces, databases, integration with other system such as
inventory databases, payment gateways, and other modules that will be added into
the Web site. After designing the web platform, the development phase involves
coding and building the actual platform. After coding, it is necessary to test all
components of the web platform. However, we need to identify what technologies,
functionalities should be tested during testing phase.
Implementation means the deployment of the system and ensure it function same
as expected. Testing and Quality Control: A critical part of the SAD is the
implementation of rigorous testing procedures. Testing is essential to identify and
rectify any malfunctions or issues within the system. For an example: Retailer’s
website, this would be the abilities to search for products, place an order, and process
payments through proper channels.
Maintenance and Optimization: Once the website or web application is live, we
recognize the web technology will require ongoing maintenance, updates, and
optimization to keep the system running efficiently, securely, and aligned with
evolving business needs. The steps involved in software development will depend
on what kind of software is being developed. Software for a desktop computer runs
in a completely different environment with different limitations than software that
runs on an embedded system with radically different limitations. Typically, the
following conditions and high-level steps would be used as a good starting point:
Conditions:
1. A Software Requirement Specification (SRS) document should be available to the
development team. (There are other names for this document but the idea is that
there must be a "what to do" document available to you that is meant to be read by
the development team, such as "The software shall be able to print the current data")
This SRS document is sometimes referred to as the “Product Backlog” or the
“Feature Proposals”
2. Someone has done some initial thinking about the assignment. If development is
proceeding before preliminary planning has been done, take that as another clue that
this is not likely a project where you want to invest your effort!
Steps: 1. Conceptual Design
2. Planned Design
3. Development
4. Integration
5. Testing
6. Installation (or in Eclipse mode, you would run and verify)
7. Allocation and Maintenance
In actual processes many of the above steps would be executed along with the
others in a parallel fashion, rather than sequentially. Some items may be omitted, or
occur twice, depending on many factors. Each iteration through the steps above is
called an Increment. Exactly what gets done in each step varies with the software
development methodology being followed.
The Software Development Life Cycle (SDLC) is a framework that defines
the different activities performed at each stage of a software development project.
Web Design and the SDLC are necessary in any project involving technology driven
projects. There are many frameworks in the industry and the most popular one is
SDLC.
******************************************************************
In web development we have many different phases such as Analysis,
Specification, Design, Development, testing etc. When we apply all these principles
in an actual project we get many advantages, as it provides many supports to the
project. For example, without the web design and SDLC is an electronics and
appliances web-store we may have following stages in the same order. Planning is
the first step of any web design project.
During the planning phase, one of the major tasks is to define the project’s
goals and scope. The retailer’s web design project planning might involve outlining
the site’s objectives, as well as budgetary and timeline constraints. The analysis
phase aligns with the high-level steps in the SAD process by gathering and
understanding requirements from stakeholders. This is critical in ensuring the web
platform meets the supermarket’s specific needs.
Design consists in the process of creating and specifying the overall system
architecture, user interfaces, and database structures; it also aligns with the SAD
phase of our System design. The back-end of the project is designed to be a robust
and scalable web platform that can support large numbers of users at the same time.
Development phase: In development phase, the actual coding and
programming of the website is done which is the complied model of the system. The
SAD phase of development and implementation aligns with the development phase.
Testing: A comprehensive testing program is conducted to identify and correct any
software defects or issues. This is a direct reflection of the SAD’s emphasis on
testing and quality assurance.
Deployment Phase – during this phase, the web platform is deployed to a
production environment and made available to users. This phase will have a 1:1
relationship with the SAD Implementation phase.
Maintenance: A website is like a new car—after the initial check and selling, a car
typically doesn't start until it’s time to be serviced. Similarly with a website, users
aren’t coming to your site just because its new, users come to your site because it's
working. Just like a car, all systems must be "tuned up" to operate at their best
capabilities. This includes updates to not just the engine of the site (CMS, Blog
engine, Event Calendar, etc.), but also the regular software that must be upgraded
monthly. When you sign up for web site maintenance, the first month involves
setting up monthly backups, caching, spam protection, SEO optimization, site
monitoring and updates. Maintenance of the web platform is ongoing. We typically
recommend budgeting roughly 10% of the budget for a web project per year for
maintenance, updates, and improvements to the site based on your needs which you
discuss with your project manager. In conclusion, SAD and SDLC are models and
strategies. They are connected frameworks of building a framework.
SAD is the initial step in the Strategic Design Phase. Strategic Design is the main
period of the “Software Development Life Cycle” when a SWD is to be developed−
it characterizes the connection, a product is to have with the business environment.
The second step is SDLC is the System Design Phase. At the point when a SWD is
to be developed this stage aims at planning the framework. Web platform for the
electronics and appliances retailer requires use of both software development models
in the projects which would help in developing better systems.
******************************************************************
Different phases of System Analysis and Design (SAD): Structured System
Analysis and Design (SSAD) is a generalized software engineering approach used
for designing and developing various types of software, especially for large projects.
It is also known as Structured Systems Analysis and Design Method (SSADM).
SSADM is an organized approach to the analysis and design of information systems.
The objective of SSADM is to provide a framework for the construction of an
information system which is totally compatible with the requirements of the
organization the system will support.
In the first phase of development of an information system, i.e., the analysis
phase, the current system is examined and deficiencies found in the system are also
identified. A more efficient and reliable system is designed in the next phase, i.e.,
design phase. The new system is constructed in the final phase, i.e., implementation
phase. Structured Systems Analysis and Design Methodology (SSADM)
approach of systems analysis and design (SAD) was first proposed by Learmonth
Burchett in 1980. Much like the traditional SAD, the SSADM consists of a series of
stages and steps that are punctuated by a number of milestones. However, as the
SSADM is one of the most traditional approaches of SAD. Its greatest strength lies
in the fact that it combines three most traditional methods of SAD: data flow
diagrams (DFP), entity relationship diagrams (ERDs) and data dictionaries. The
SSADM follows a rigid waterfall like sequence where at the end of each stage, a
review is conducted to determine if ever stage was completed successfully.
Object-Oriented Analysis and Design (OOAD) is an approach to system
analysis and design that involves a set of techniques that makes use of the approaches
of object-oriented programming to obtain information about the system being
studied, promote design prototypes and eventually projects and their solutions.
OOAD is based on a number of concepts that support the identified approach that
results in out beating design resolutions. OOAD provides a clear, well-defined
format wherein characteristics and behavior of the objects are well-defined. Also,
when working with the objects and classes, its well defined and clearly known that
the major role is played by objects. The other roles in the OOAD include classes,
relation between the objects and classes, notations to represent each and every aspect
of the systems structure and behavior. The key feature of OOAD is representing
every task as the interaction of objects and classes. The UML (Unified Modeling
Language) can be used to represent the functional part of the System aspect and
cover the complete behavior. OOAD promotes a new addition to the old concepts of
the traditional way of object-oriented modeling (OOM) method. It is a flexible
methodology which can be used for the entire system development life cycle and is
technology independent. The object-oriented design analysis can be defined as a
method to identify the objects that integrate into the system and describes the
mechanism they acquire and interact with like the movement of data and execute the
specific behavior. OOAD uses the methods of object-oriented analysis along with
UML. Oriented analysis is concerned with creating a formal, detailed model of the
object-oriented solution. Though UML can be used in analysis to characterize the
users need, design to show how the systems parts solve the users need. Oriented
 Analysis divides parts into subsystems, gives a few relations between design
parts, assigns operations to design parts, and describes the interactions between
parts. Oriented design, on other hand, is Habitually put together in a category
structure, with classes positioned in the division’s subsistence closest to the part it
customs the most. Methods and data relations are bendy inside each one division.
Desirable relations between design parts are optional, along with a devoted abstract
and refined state for each part. Rapid Application Development (RAD): RAD is
an agile approach to SDLC that focuses on rapid prototyping and development. The
key feature is that RAD breaks the overall project into several smaller parts and
develops them at the same time, in a parallel fashion. Strengths of RAD: Due to use
of iterative development, rapid software development with high-quality is possible.
High level of customer involvement and satisfaction is also possible in RAD.
Weaknesses of RAD: Documentation may not be accepted in RAD. If customer
power is more than involvement is good otherwise not. The rapid application
development (RAD) approach seeks to reduce the amount of time needed to develop
systems through the use of prototypes, early user feedback and an emphasis on
knowledge. A key feature of RAD is that it seeks to develop prototypes of key system
interfaces early in the development process and then seeks user feedback on these
prototypes. This feedback allows system developers to gradually better understand
the requirements of a system and for the users to gradually better understand the
capabilities of system which are feasible to implement. Early implementations
typically contain significant design flaws, but as successive prototypes are
developed, the chances of finding each design error or missing component, tends to
dwindle. RAD can work reasonably well when a system is straightforward to
develop as the developer can incrementally refine their understanding of user
requirements. Additionally, most of the time in developing early prototypes is spent
interacting with the user to secure their feedback. RAD can work best where a project
is narrow in focus and generates knowledge that will be valuable to the organization
without a full development effort. Strengths of RAD is that developers find RAD
easier to explain to users who have Object-Oriented development experience, and
who will be able to recognize processes in an object after seeing a completed system.
RAD enables a system designer to gradually refine a user's understanding of business
rules so that after about a month, the user has a good understanding of what the new
computer system should to, and is able to make a significant contribution to the
design of that system. RAD relies on the skills of a soft systems analyst who
facilitates workshop discussions with the user community. The analyst captures the
users' ideas on paper, and builds an object model which is then evaluated by users,
modified, rebuilt, and eventually given to developers. Of course, as a choice, RAD
brings with it some limitations. RAD does not fit software systems which have a
large number of system interfaces or which require significant system architectural
components. One of the major benefits of RAD is that it speeds up the system
development cycle: bringing a working system to the end user within thirty months.
However, with many projects, time does not exist to bring the user to understand the
system and make meaningful contributions to the design effort. In this case, RAD
may provide a major disappointment by getting the user's hopes up while they are
only able to contribute minor design enhancements. The RAD Approach:
* Takes advantage of RAD strengths to reduce overtime; requires management's
understanding that the project may be late.
* Takes advantage of RAD strengths to expedite system development at reduced
staffing levels.
* Converges budget funds until October, and takes advantage of price reduction for
network, desktop terminal, CPU, etc. purchases.
* Concentrates user interruption one time.
* Pro-actively confronts stunning problems before caserns NASA into spiral of
minor technical snafus.
Most significant shortcomings of RAD:
• Users have difficulty in imagery to function of an object without seeing it.
• Users have difficulty in accepting a rapid prototype until it has been demonstrated
the functionality can be added to business rules.
Things to Remember About RAD:
• RAD's biggest drawback is when a user can't seem to recall a business rule, they
will frequently state "I'll know it if I can see it." Approach-Selection of Methodology
Overview This general approach suggests selecting one of the three primary
SAD methodologies (Structured, Object-Oriented, or Agile) based on the
requirements, constraints, and culture of the project as well as on the organization.
Key features
• Incorporates a broad spectrum of methodologies for handling different classes of
projects. Strengths
• Gives the development team the flexibility to select the most appropriate
methodology to use on a project.
• Recognizes that the most effective development projects require all types of
methodologies. Weaknesses
• Requires an in-depth understanding of each methodology in order to make educated
choices.
Each methodology currently in use has different and unique strengths that
make it suitable for specific types of tasks. The choice of an SAD approach should
always be based on the unique implications of the project’s goals, scope, and
timeline as well as the preferences and skills of the development team.
 CITY

FIRST_NAME
CUST_ID
ADDRESS ADDRESS

LAST_NAME
STATE
SALE
E-R DIAGRAMFOR
ELECTRONICSSTORE
SSN

FIRST_NAME EMP_ID SUPPLIED

LAST_NAME

To supplyprice
andamount
Orders

ORDER
QUANTITY
QUANTITY ITEM_DESC Items
ORDER_NO
TOTAL

PAYMENT_TYPE
ITEM_NO

Figure: Electronics and Appliances Retailer E-R Diagram

The evaluation of system design requirements is a critical phase in the system

analysis and design process. It involves assessing whether the proposed design meets
the specified needs and objectives of the organization or project. Here are some key
points to consider when evaluating system design requirements:
Alignment with Business Goals:
The system design should align with the overarching business goals and objectives.
It must contribute to the organization's mission and strategic vision.
Stakeholder Validation:
Ensure that the design requirements have been validated and approved by all relevant
stakeholders, including end-users, management, and technical experts. This helps in
avoiding misunderstandings and conflicts later in the project.
Completeness:
Verify that the design requirements encompass all necessary aspects of the system.
Missing or incomplete requirements can lead to gaps in functionality and usability.
Consistency:
Check for consistency within the design requirements. Ensure that there are no
contradictions or conflicting specifications that could lead to confusion during
implementation.
Feasibility:
Assess the feasibility of implementing the proposed design. Evaluate whether the
technology, resources, and budget are sufficient to realize the design within the
specified constraints.
Scalability:
Consider whether the system design can accommodate future growth and scalability.
Ensure that it can handle increased data volumes, user loads, and additional features
without significant redesign.
Adaptability:
Evaluate whether the design is adaptable to changing business needs and evolving
technologies. It should be resilient to changes in the external environment.
Usability and User Experience:
Assess the design from a user perspective. Ensure that it is user-friendly, intuitive,
and capable of providing a positive user experience. Usability testing and user
feedback are valuable in this regard.
Performance and Efficiency:
Evaluate the performance characteristics of the design, including response times,
throughput, and resource utilization. Ensure that the system meets performance
expectations under normal and peak loads.
Security and Compliance:
Verify that the design addresses security concerns and compliance requirements,
especially in industries with strict regulatory standards (e.g., healthcare, finance). It
should protect sensitive data and ensure data privacy.
Interoperability:
Consider whether the system can seamlessly integrate with other existing systems
and third-party services. Compatibility and interoperability are essential for a well-
functioning IT ecosystem.
Maintainability and Supportability:
Evaluate whether the design facilitates ease of maintenance and support. It should
be modular and well-documented, making it straightforward for future updates and
troubleshooting.
Cost-Effectiveness:
Analyze the cost implications of the design. Ensure that it falls within the allocated
budget and provides a reasonable return on investment (ROI).
Risk Assessment:
Identify potential risks associated with the design and assess their impact. Develop
mitigation strategies to address high-risk areas.
Testing and Validation:
Plan for comprehensive testing and validation of the design. This includes unit
testing, integration testing, and user acceptance testing to confirm that the design
meets the specified requirements.
Feedback Loop:
Establish a feedback loop with stakeholders to gather input and address any concerns
or changes in requirements throughout the evaluation process.
Documentation:
 Ensure that all design requirements are thoroughly documented, including
functional specifications, technical specifications, and design diagrams. This
documentation serves as a reference for implementation and future maintenance.
The evaluation of system design requirements is an iterative process that
involves continuous refinement and validation. It helps in identifying and rectifying
design issues early in the project, ultimately leading to the development of a system
that fulfills the organization's needs and expectations.