Structured System Analysis and Design Methodology and Agile Software Development

This article discusses the Structured System Analysis and Design Methodology (SSADM) and Agile Software Development. It explains the steps involved in SSADM, including logical data modeling, data movement modeling, and modeling the behavior of entities. It also describes the components of Extreme Programming (XP), including planning, designing, coding, testing, and listening. The article compares and contrasts the Agile development model with the traditional Waterfall approach.

Method of structured system analysis and design is the subject of the second task.
Using a graphic, describe and explain the many steps involved in the Structured systems analysis and
design process (also known as the Waterfall Model):
The Structured Systems Analysis and Design Methodology, or SSADM for short, is a set of rules for
creating software applications and carrying out system analyses. It is also known by its full name, the
Structured Systems Analysis and Design Methodology. It takes a method that is both formal and rigorous
when it comes to the study of information systems and the design of such systems. It was designed as a
standard for the establishment of British database projects by Learmonth Burchett Management
Systems (LBMS) and the Central Computer Telecommunications Agency during the years 1980 and 1981.
LBMS is an acronym for Learmonth Burchett Management System (CCTA).
A paradigm known as the waterfall serves as the foundation for the Structured Systems Analysis and
Design Method (SSADM), which is an open methodology. A large variety of commercial enterprises,
consulting firms, educational institutions, and manufacturers of CASE tools have all made use of it.
The SSADM conforms to the waterfall life cycle model from the beginning of the development process at
the level of the feasibility study all the way through to the stage of the physical design. One of the most
remarkable features of the SSADM system is the wide engagement of users in the stage of requirements
analysis. This is one of the most important components. It is necessary for the users to initial and sign off
on each completed step in order to guarantee that the requirements are met. Documentation is
provided to consumers that is plain and easy to understand, and it takes the form of a variety of
diagrammatic representations of the system. This documentation is sent to clients. SSADM is used to
divide a development project into a number of stages, modules, processes, and activities. When
employing SSADM, the very first model that is created is the data model, which is also the model that is
considered to be the most significant. It is a step in the procedure of gathering requirements and is
composed of stages, procedures, and products that have been thoroughly outlined. Modeling
techniques such as logical data modelling, data flow modelling, and entity behaviour modelling are the
three that are used in SSADM's modelling processes.
• Logical Data Modeling: This covers the stages of identifying, modelling, and documenting the data as
part of the process of collecting requirements for the system. This is done as a part of the process of
obtaining requirements for the system. A further subdivision of the data takes place, this time into the
entities and relationships that exist between them.
• Data Movement Modeling: In order to accomplish this goal, it is necessary to monitor the flow of data
throughout an information system. It conducts an investigation of the processes, data repositories,
external entities, and data transit in an open and honest manner.

• Modeling the Behavior of Entities Needs Finding the Sequence of Events That Impact Each Entity and
Documenting That Sequence Along with the Order in Which These Events Occur This step requires
determining and recording the sequence of events that influence each entity.
The following is a list of some of the most notable aspects of SSADM:
• Partitioning a bigger project into a number of more manageable modules, each of which has its own
set of clear goals to accomplish.
• Useful throughout the whole of the process of specifying the requirements and creating the system.
• Modeling techniques, including diagrammatic representation and a variety of others that may be of
use.
• Comprehensible and straightforward for users as well as for those who write the code.
• Carrying out a sequence of responsibilities in the order that has been decided in advance.
The following are the phases of SSADM:
Conducting a Feasibility Study involves conducting an examination of the many business sectors in order
to determine whether or not the system is capable of meeting the demands of the organisation in a way
that is both efficient and cost-effective.
Analysis of Requirements: Define the Needs That the System Will Create The current business
environment is modelled after the process of clauses and data structures that are engaged in the
analysis of requirements.

Requirements Specification: Determine the exact requirements for both the functional and the non-
functional components of the system, as well as the specific demands for the processes and data
structures that are required, and develop new technologies to meet those requirements.
Specification of the Logical System One of the options for the technical system is to make alterations to
the production and logical designs. Other options for the system include query processing and system
discussion.
Structure of the Body -
The process of producing programme specifications [3] involves the use of a physical architecture for the
database in addition to a list of software requirements, a logical system specification, and a technical
system specification.

Figure1: SSADM Life Cycle [4]
Development of agile software is the third task.
Agile software development refers to what exactly?
The term "Agile" refers to a methodology for developing software that places an emphasis on providing
functioning software in increments that are both modest and frequent rather than waiting until the very
end to give a finished product.
In agile methodology, one of the fundamental tenets is the practise of lean development, which
emphasises the production of minimally viable products (MVPs) that are subjected to several iterations

before being made public. Due to the fact that input is regularly collected and acted upon, the process
has become much more collaborative and dynamic [5].
1. Who should principally be credited for the introduction of the model, and when exactly did the
introduction take place?
Ken Beck, a software engineer, was the one who first proposed the idea of XP in the 1990s with the
intention of figuring out how to produce high-quality software more rapidly while still being able to
adapt to the changing needs of consumers. XP is an abbreviation for "extreme programming," which
stands for "extremely productive," and "extremely productive" is the goal of XP. Extreme Programming
Explained: Embrace Change was the title of his book, which was released in 1999 and in which he
expounded on various different XP approaches [6].
2. With the use of a diagram, provide a concise explanation of the model's primary components,
including:
The usual iterative processes or stages of the development process that are included in the XP
framework are as follows:
Planning:
The first thing that should happen during the planning phase is for the customer to have a meeting with
the development team and provide the requirements as user stories. These tales will outline the final
outcome that the client is aiming for in their project. After that, the team will assign estimates to each of
the stories, and then they will construct a release plan that will be partitioned into the iterations
necessary to cover the necessary features in increments. In the case that one or more of the storylines
cannot be estimated, what are known as spikes may be produced; this is an indication that further
research is necessary.
Designing:

The act of designing is technically a part of the process of planning; yet, in order to emphasise how
significant its role is, it may be better to consider it a distinct undertaking. It has something to do with
straightforwardness, which is one of the core XP principles that we are going to go through in the next
paragraphs. A good design will provide the system with logic and structure, in addition to the capability
to get rid of complex and redundant pieces that are not needed.
Coding:
Coding is the phase in which the actual code is generated by using various XP ideas such as collaborative
code ownership, coding standards, pair programming, and continuous integration. Coding takes place
during the phase known as "coding."
Testing:
Testing is performed in an extremely thorough manner, which serves as the basis for extreme
programming. The acceptance tests and the unit tests (automated testing to see whether the newly
produced feature works as planned) are both a part of this normal process (customer testing to verify
that the overall system is created according to the initial requirements).
Listening:
When you listen, you should always strive to keep up a conversation and provide your thoughts and
opinions. When articulating the required business logic and value, it is essential to include both the
customers and the project managers in the process. [6]
Figure 2: Extreme Programming Lifecycle [6]
A development process such as this one includes the participation of a number of different persons,
each of whom has their own particular tasks and responsibilities to play along the process. Extreme
programming places a strong emphasis on the value and significance of a variety of social skills including
communication, collaboration, receptivity, and feedback. It also places humans at the centre of the

system and places a strong emphasis on the value and significance of various social skills. For this
reason, experience points are often associated with the following roles:
Customers:
Customers are expected to actively engage in the development process by authoring user stories,
providing continuing input, and making all of the major business decisions relevant to the project. This is
the expectation.
Developers and programmers, please read this.
The members of the team who are really responsible for generating the product are referred to as
developers or programmers. They are responsible for carrying out user testing in addition to putting
user stories into action (sometimes a separate Tester role is set apart). Extreme programming is often
associated with cross-functional teams; hence, the skill sets of individuals working on such teams are
likely to differ.
Keepers of Score and Managers:
Customers and developers might be connected via the use of managers or trackers. It is not a required
function, and any one of the developers is able to assume the obligations that are connected with taking
on the role of performing it. These employees are in responsible of planning the get-togethers,
managing the dialogues, and keeping an eye on the essential KPIs that are used to quantify
performance.
Coaches:
It is feasible for coaches to assume the position of mentors inside the teams in order to provide
members with improved assistance in grasping the XP practises. It is often an outside assistant or an
external consultant who is not involved in the process of development but is acquainted with XP and can
thus help in the process of mistake prevention.
3. Why is this an effective iteration of the agile development model?

Extreme Programming is a suitable paradigm for software development since it has the following
characteristics:
• There is a possibility that using the XP framework will be beneficial, as well as reduce the amount of
time and money spent on the development process.
• The implementation of techniques for continuous testing and refactoring contributes to the
development of dependable, high-performing systems that need only a minimal amount of
troubleshooting.
• The principle of simplicity refers to the practise of developing code that is not only straightforward to
comprehend but also straightforward to alter in the event that it becomes required to do so in the
foreseeable future.
• The development approach of adopting a minimalistic iterative technique implies that practical
solutions can be developed very fast, and that only the features that are absolutely necessary are
created. This ensures that the product is as lean and efficient as possible.
• User stories are gradually taking the place of the cumbersome requirements documents, which has led
to a decrease in the total volume of documentation.
• Either there is no custom of working extra hours, or relatively little overtime is done.
• If there is consistent communication among the team members, which grants a high degree of
visibility and accountability, then all members of the team are able to keep up to date on the progress of
the project.
• Research has shown that using two programmers to write code together produces results of better
quality with fewer mistakes. The vast majority of persons who took part in the survey said that they felt
more certain about their profession and enjoyed working with others more while they were included in
the study [6].

4. Using the models of development presented, compare and contrast the agile development model
with the waterfall approach.
The traditional approach of developing software is referred to as the "waterfall technique," which is also
a more prevalent phrase. Before the advent of the Agile method, each and every project was managed
following the Waterfall strategy. The implementation of this time-tested tactic is done in a step-by-step
fashion. Each of the company's projects, before to being turned over to the customer, are required to
first complete a series of stages, the bare minimum of which is often five.
The testing phase of the Waterfall building process does not begin until the very last possible moment.
Because of this, using this approach to correct errors that surfaced in the early stages of the execution of
the project might, at times, prove to be hard.
Extreme Programming may be differentiated from the Waterfall paradigm in a great many ways,
including those that are described below:
• To begin, the nature of this approach is one that is iterative. It follows the same lifecycle over and over
again until the ultimate product is created, as opposed to having a variety of stages that follow one
another in order.
• The next component that distinguishes Extreme Programming from the Waterfall paradigm is the XP
team. In point of fact, this group functions as an Agile team that does not adhere to any certain
structure. It is self-managing, just like all of the other Agile teams that we've seen so far.

• The review of the testing plan is carried out after each iteration of the sprint in the Extreme
Programming technique, but in the Waterfall methodology, this topic is only brought up periodically
once the testing phase is already in process.
• One of the qualities that sets the XP methodology apart from the Waterfall approach is the ongoing
participation of the customer in the process of producing software. This is only one of the many ways in
which the two methodologies are differentiated.
• Testing is performed concurrently with the creation of software in the XP approach, but in the
Waterfall methodology, the testing phase occurs after the period in which the programme is
constructed [7]. This distinction is one of the key differences between the two methodologies.