Sub Name &Sub Code- SA (701)

Assignment –I
1. Explain Software development methodology.
Ans :- Software development methodology implies dividing the workload into
specific segments for its faster management. It also describes management methods
used to increase the delivery efficiency, cooperation between development, design,
testing, and other teams, as well as the product owner. Methodologies also regulate
the participation of involved parties outside of the team, like clients and
stakeholders. Project participants know how and when to control the project without
interfering with the team.

Waterfall Model
The Waterfall software development approach is one of the earliest ones, having
appeared in the 1950s and defined in the 1970s by Winston W. Royce. Waterfall
software development is characterized by a very straightforward approach that
follows a rigid series of steps. Each phase must be completed one by one, and there
is no going back to a previous step.
Stages of Waterfall development

The critical thing to remember is that the exact number and names of Waterfall
development stages vary with regards to the project needs and the team visions.
Here’s a list of typical phases of Waterfall development.

 Gathering requirements: this is the stage where the team defines the product’s
functionality, interface, performance, checks its connection to business goals.
 Design: software development teams pick tech stacks, determine the databases that
they prefer, and prepare the technology. UX and UI designers define user
personas and create the interface.
 Build: developers write code for software functionality (user-end and server-end).
 Deployment: the code is tested and uploaded to the server.
 Maintenance: the team supports the final version of the application.
 Advantages

 The waterfall model is natural to measure and control: the workflow is organized in
clearly defined stages. Because there’s no switching back-and-forth, you can set the
timing precisely and plan the budget accordingly.
 Management is easy: due to its definite structure, it’s perfect for small teams and
inexperienced managers;
 Onboarding is faster: new developers can quickly get up to speed with the project
because all the stages logically follow each other.
Disadvantages

 Lack of flexibility: the team can’t fix issues left over from the previous stage which
leads to piled up bugs and technical debt;
 Collaboration issues: different teams do not work together. If something goes
wrong, developers, designers, and testers are likely to blame each other for the
failure.
Agile
 Agile is a constant repetition of development and testing stages in software
development. The project is flexible because developers, designers, and testers
cooperate with each other and can perform tasks simultaneously.

Agile is based on the following fundamentals which is defined by four values:

 Priority is given to individual interactions over tools and processes – people come
first;
 Collaboration over negotiation: the team strives to find the compromise with the
product owner, not to negotiate the best one-sided contract;
 Changes over planning: long-term goals are respected but pushed aside if needed.
 Product over complete documentation: developers should spend more time writing
code than reports.
 Advantages

 Flexibility: if there’s a mistake in project requirements, it can be fixed at any

moment, preventing the team from doing unnecessary work. The same applies to
any stage.
 Multiple product operations: software is released often but with small changes.
Disadvantages

 Less control: you can’t estimate the project cost early on. Negotiations with product
owners become more complicated because the team can’t create a precise estimate
or give certain budget guarantees.
 More commitment from the team: developers, testers, and designers should
communicate with each other and management.
Rapid application development (RAD)

RAD is similar to the Agile and prototype model. Like these software engineering
methodologies, it emphasizes the importance of building a minimum viable
product, but also, it prioritizes the speed of the delivery over other metrics.
Developers should quickly release new interactions of the product without being
overly perfectionist. The regular prototype model doesn’t impose such restrictions.

Similarities between Agile and prototype

 Developers are focused on creating the main functionality first, releasing the
product and then perfecting it;
 Testing isn’t as important early on the project;
 Flexibility is prioritized over planning, just like in Agile.
 Advantages

 Early feedback: users and stakeholders can evaluate the prototype early on and
contribute to the project with their opinions;
 Flexibility: developers can change product requirements and deliverables anytime;
 Quick results: having a done product is better than aiming to release a perfect one
without showing tangible results.
Disadvantages

 Rapid application development and rapid application methodologies, with their

emphasis on the time of delivery, can lead to the quick-and-dirty approach;
 Management difficulties: product managers need to continually control the process,
track tangible results, and monitor the quality of iterations

Dynamic system development (DSDM)

The DSDM methodology looks at the product not as just a collection of features or
code files, but as a complex system. Each software is evaluated in terms of tangible
value that it brings to businesses. The key priority of the development team is to
 understand how business works, define clear strategies and objectives, and reflect
these goals in the business logic of the application.

To be clear, systems development methods don’t have to be standalone. DSDM can

be combined with Agile, prototype development, or rapid development. However,
the priorities are shifted towards analyzing business, getting a strategic
understanding, and doing in-depth market research.

DSDM comprises five key stages: feasibility study, business research, functional
model ideation, system design, and implementation. As you can tell, the majority of
these stages fall in the first half of the product development process. DSDM
emphasizes on making sure that the product can bring expected benefits to the
company and market.

Advantages

 The first stages don’t require in-depth knowledge of software development;

 Provides product owners and software developers with strategic information that
will be necessary during product development, marketing, and support;
 Time- and cost-efficient: researching and analyzing isn’t as expensive as executing
and testing. Product owners can eliminate questionable concepts early on and avoid
wasting time and resources on their prototyping.
Disadvantages

 Time-consuming initial stages: if your team implements DSDM, be ready that the
first research stage will take quite a lot of time;
 Documentation: usually, DSDM software development approaches entail presenting
product owners with multiple reports and research documents;
 Difficult to manage: not all development teams know how to analyze concepts and
control employee’s efficiency of performing such analytical tasks.
Extreme programming (XP)

Extreme programming is a test-driven software development methodology. The

code can’t be considered perfect until the team didn’t run the tests of all system
modules. Extreme programming heavily relies on unit testing: after a piece of code
is developed, its quality needs to be checked immediately.

It’s evident that extreme programming requires QA and development teams to run
thousands of tests every day. To make this work, the team has to adopt automated
testing. The priority should be to invest the time at early project stages to automate
 functional, performance, and unit tests, and save time later on during the QA and
maintenance stages.

Fundamental principles of the methodology

 Software requirements and metrics are constantly evolving;

 Developers and testers invest a lot of time in automation and metrics;
 The development team is small – the emphasis is placed on testing and operations;
 Automation is a priority: everything that can be automated shouldn’t be done
manually.
Advantages

 Time and cost-efficient: the team doesn’t waste time on rewriting functionality and
eliminating bugs or technical debt;
 No need to refactor: the code is evaluated as it’s being written;
 Better performances: users don’t see functionality or interface bugs in the ready
project;
 Reduced risks: due to constant monitoring, the team minimizes the risk of sudden
system failures.
Disadvantages

 The lack of universality: a strict approach to quality assurance can limit

developers’ creativity, pushing them to develop error-free solutions rather
than innovative ones;
Investment in testing: product owners need to be ready to invest additional
budgets into testing execution and management.Explain software quality
mode.

Ans:- software quality mode

McCall’s Software Quality Model was introduced in 1977. This model is
incorporated with many attributes, termed as software factors, which influence
software. The model distinguishes between two levels of quality attributes:
 Quality Factors
 Quality Criteria
Quality Factors: The higher-level quality attributes which can be accessed directly
are called quality factors. These attributes are external attributes. The attributes at
this level are given more importance by the users and managers.
Quality Criteria: The lower or second-level quality attributes that can be accessed
either subjectively or objectively are called Quality Criteria. These attributes are
internal attributes. Each quality factor has many second-level of quality attributes
or quality criteria.
Example: The usability quality factor is divided into operability, training,
communicativeness, input/output volume, and input/output rate. This model
classifies all software requirements into 11 software quality factors. The 11
factors are organized into three product quality factors: Product
Operation, Product Revision, and Product Transition.
Factors of Product Quality
Below are the factors of Product Quality , that are discussed in detail.
Product Operation
It includes five software quality factors, which are related to the requirements that
directly affect the operation of the software such as operational performance,
convenience, ease of usage, and correctness. These factors help in providing a
better user experience.
 Correctness: The extent to which software meets its requirements
specification.
 Efficiency: The number of hardware resources and code the software, needs to
perform a function.
 Integrity: The extent to which the software can control an unauthorized person
from accessing the data or software.
 Reliability: The extent to which software performs its intended functions
without failure.
 Usability: The extent of effort required to learn, operate and understand the
functions of the software.

2. What is Architecture Business Cycle and how its work?

Ans:- “Software architecture is a result of technical, business, and social
influences. Its existence in turn affects the technical, business, and social
environments that subsequently influence future architectures. We call this cycle of
influences, from the environment to the architecture and back to the environment,
the Architecture Business Cycle (ABC).”
How the ABC Works :

1. The architecture affects the structure of the developing organization. An

architecture prescribes a structure for a system; as we will see, it particularly
prescribes the units of software that must be implemented (or otherwise obtained)
and integrated to form the system. These units are the basis for the development
project's structure. Teams are formed for individual software units; and the
development, test, and integration activities all revolve around the units. Likewise,
schedules and budgets allocate resources in chunks corresponding to the units. If a
company becomes adept at building families of similar systems, it will tend to
invest in each team by nurturing each area of expertise. Teams become embedded
in the organization's structure. This is feedback from the architecture to the
developing organization.

In the software product line case study, separate groups were given responsibility
for building and maintaining individual portions of the organization's architecture
for a family of products. In any design undertaken by the organization at large,
these groups have a strong voice in the system's decomposition, pressuring for the
continued existence of the portions they control.
2. The architecture can affect the goals of the developing organization. A successful
system built from it can enable a company to establish a foothold in a particular
market area. The architecture can provide opportunities for the efficient

production and deployment of similar systems, and the organization may adjust its
goals to take advantage of its newfound expertise to plumb the market. This is
feedback from the system to the developing organization and the systems it builds.

3. The architecture can affect customer requirements for the next system by giving
the customer the opportunity to receive a system (based on the same architecture) in
a more reliable, timely, and economical manner than if the subsequent system were
to be built from scratch. The customer may be willing to relax some requirements to
gain these economies. Shrink-wrapped software has clearly affected people's
requirements by providing solutions that are not tailored to their precise needs but
are instead inexpensive and (in the best of all possible worlds) of high quality.
Product lines have the same effect on customers who cannot be so flexible with
their requirements. A Case Study in Product Line Development will show how a
product line architecture caused customers to happily compromise their
requirements because they could get high-quality software that fit their basic needs
quickly, reliably, and at lower cost.
4. The process of system building will affect the architect's experience with
subsequent systems by adding to the corporate experience base. A system that was
successfully built around a tool bus or .NET or encapsulated finite-state machines
will engender similar systems built the same way in the future. On the other hand,
architectures that fail are less likely to be chosen for future projects.

5. A few systems will influence and actually change the software engineering
culture, that is, the technical environment in which system builders operate and
learn. The first relational databases, compiler generators, and table-driven operating
systems had this effect in the 1960s and early 1970s; the first spreadsheets and
windowing systems, in the 1980s. The World Wide Web is the example for the
1990s. J2EE may be the example for the first decade of the twenty-first century.
When such pathfinder systems are constructed, subsequent systems are affected by
their legacy.

3. Explain Software Architecture and Software Design.

Ans:- The architecture of a system describes its major components, their

relationships (structures), and how they interact with each other. Software
architecture and design includes several contributory factors such as Business
strategy, quality attributes, human dynamics, design, and IT environment.
We can segregate Software Architecture and Design into two distinct phases:
Software Architecture and Software Design.

In Architecture, nonfunctional decisions are cast and separated by the functional

requirements. In Design, functional requirements are accomplished.

Software Architecture
Architecture serves as a blueprint for a system. It provides an
abstraction to manage the system complexity and establish a communication and
coordination mechanism among components.
 It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like
performance and security.
 Further, it involves a set of significant decisions about the organization related
to software development and each of these decisions can have a considerable
impact on quality, maintainability, performance, and the overall success of the
final product. These decisions comprise of −
o Selection of structural elements and their interfaces by which the system
is composed.
o Behavior as specified in collaborations among those elements.
o Composition of these structural and behavioral elements into large
subsystem.
o Architectural decisions align with business objectives.
 o Architectural styles guide the organization.
o

Software Design
Software design provides a design plan that describes the elements of a system, how
they fit, and work together to fulfill the requirement of the system. The objectives
of having a design plan are as follows

 To negotiate system requirements, and to set expectations with customers,

marketing, and management personnel.
 Act as a blueprint during the development process.
 Guide the implementation tasks, including detailed design, coding,
integration, and testing.

It comes before the detailed design, coding, integration, and testing and after the
domain analysis, requirements analysis, and risk analysis.

4. Explain software components and connectors

Ans:- Introduction to Software Components:

Software components are modular units of software that encapsulate a specific
functionality or behavior. They promote reusability, maintainability, and separation
of concerns. In this section, we will explore the definition, benefits, and
characteristics of software components, emphasizing their importance in modern
software development.

Types of Software Components:

Software components come in various flavors, each serving a distinct purpose. We
will discuss functional and non-functional components, library and framework
components, as well as third-party and custom-built components. Understanding
these distinctions will help you choose the right components for your software
projects.

Designing Software Components:

Designing effective software components requires careful consideration of design
principles and best practices. We will delve into component-based design principles,
such as component granularity, cohesion, and interface design. Additionally, we will
explore contract-based programming, which establishes clear specifications for
component interaction.

Software Connectors:
Connectors act as bridges between software components, facilitating communication
and interaction. We will define software connectors and explore different connector
types, such as procedural connectors, data connectors, and event-based connectors.
Understanding connectors is crucial for designing flexible and extensible software
systems.
Communication and Interaction in Software Systems:
Efficient communication and interaction are vital in software systems. We will
discuss synchronous and asynchronous communication, as well as various
interprocess communication mechanisms like message queues and remote procedure
calls. Additionally, we will introduce event-driven architecture and event-based
communication, which are gaining popularity in modern systems.

5. What is architectural pattern?

Ans:- An architectural pattern is a description of element and relation types

together with a set of constraints on how they may be used. A pattern can be
thought of as a set of constraints on an architecture-on the element types and their
patterns of interaction-and these constraints define a set or family of architectures
that satisfy them. For example, client-server is a common architectural pattern.
Client and server are two element types, and their coordination is described in terms
of the protocol that the server uses to communicate with each of its clients. Use of
the term client-server implies only that multiple clients exist; the clients themselves
are not identified, and there is no discussion of what functionality, other than
implementation of the protocols, has been assigned to any of the clients or to the
server. Countless architectures are of the client-server pattern under this (informal)
definition, but they are different from each other. An architectural pattern is not an
architecture, then, but it still conveys a useful image of the system-it imposes useful
constraints on the architecture and, in turn, on the system.

One of the most useful aspects of patterns is that they exhibit known quality
attributes. This is why the architect chooses a particular pattern and not one at
random. Some patterns represent known solutions to performance problems, others
lend themselves well to high-security systems, still others have been used
successfully in high-availability systems. Choosing an architectural pattern is often
the architect's first major design choice.

The term architectural style has also been widely used to describe the same
concept.

6. Explain software architecture frameworks.

Ans:- common software architecture frameworks

Layered Architecture

The most common architecture pattern is the layered architecture pattern, otherwise
known as the n-tier architecture pattern. This pattern is the de facto standard for
most Java EE applications and therefore is widely known by most architects,
designers, and developers. The layered architecture pattern closely matches the
traditional IT communication and organizational structures found in most
companies, making it a natural choice for most business application development
efforts.

Pattern Description

Components within the layered architecture pattern are organized into horizontal
layers, each layer performing a specific role within the application (e.g.,
presentation logic or business logic). Although the layered architecture pattern does
not specify the number and types of layers that must exist in the pattern, most
layered architectures consist of four standard layers: presentation, business,
persistence, and database (Figure 1-1). In some cases, the business layer and
persistence layer are combined into a single business layer, particularly when the
persistence logic (e.g., SQL or HSQL) is embedded within the business layer
components. Thus, smaller applications may have only three layers, whereas larger
and more complex business applications may contain five or more layers.
Each layer of the layered architecture pattern has a specific role and responsibility
within the application. For example, a presentation layer would be responsible for
handling all user interface and browser communication logic, whereas a business
layer would be responsible for executing specific business rules associated with the
request. Each layer in the architecture forms an abstraction around the work that
needs to be done to satisfy a particular business request. For example, the
presentation layer doesn’t need to know or worry about how to get customer data; it
only needs to display that information on a screen in particular format. Similarly,
the business layer doesn’t need to be concerned about how to format customer data
for display on a screen or even where the customer data is coming from; it only
needs to get the data from the persistence layer, perform business logic against the
data (e.g., calculate values or aggregate data), and pass that information up to the
presentation layer.
one of the powerful features of the layered architecture pattern is the separation of
concerns among components. Components within a specific layer deal only with logic
that pertains to that layer. For example, components in the presentation layer deal
only with presentation logic, whereas components residing in the business layer
deal only with business logic. This type of component classification makes it easy
to build effective roles and responsibility models into your architecture, and also
makes it easy to develop, test, govern, and maintain applications using this
architecture pattern due to well-defined component interfaces and limited
component scope.

Client-server architecture
Client-server architecture is a computing model in which the server hosts, delivers,
and manages most of the resources and services requested by the client. It is also
known as the networking computing model or client-server network as all requests
and services are delivered over a network. The client-server architecture or model
has other systems connected over a network where resources are shared among the
different computers.

Client-server architecture is a computing model in which the server hosts, delivers,

and manages most of the resources and services requested by the client. It is also
known as the networking computing model or client-server network as all requests
and services are delivered over a network. The client-server architecture or model
has other systems connected over a network where resources are shared among the
different computers.

Typically, client-server architecture is arranged in a way that clients are often

situated at workstations or on personal computers, while servers are located
elsewhere on the network, usually on more powerful machines. Such a model is
especially beneficial when the clients and server perform routine tasks. For
example, in hospital data processing, a client computer can be busy running an
application program for entering patient information, meanwhile, the server
computer can be running another program to fetch and manage the database in
which the information is permanently stored.

Typically, client-server architecture is arranged in a way that clients are often

situated at workstations or on personal computers, while servers are located
elsewhere on the network, usually on more powerful machines. Such a model is
especially beneficial when the clients and server perform routine tasks. For
example, in hospital data processing, a client computer can be busy running an
 application program for entering patient information, meanwhile, the server
computer can be running

7. What is reference model?

Ans:- A reference model is a division of functionality together with data flow

between the pieces. A reference model is a standard decomposition of a known
problem into parts that cooperatively solve the problem. Arising from experience,
reference models are a characteristic of mature domains. Can you name the standard
parts of a compiler or a database management system? Can you explain in broad
terms how the parts work together to accomplish their collective purpose? If so, it is
because you have been taught a reference model of these applications.