UNIVERSITY OF LAHORE, SARGODHA CAMPUS

DEPARTMENT OF COMPUTER SCIENCE

Software Architecture and Design

ASSIGNMENT #3

Name: Muhammad Hamza Riaz

Registration Number: BSSE-07183015

AGILE SOFTWARE ENGINEERING :

Agile:
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an
uncertain and turbulent environment.

Agile Software Development:

Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-
Driven Development (FDD).
 Agile software development is more than practices such as pair programming, test-driven
development, stand-ups, planning sessions, and sprints.
 Agile software development is an umbrella term for a set of frameworks and practices based on the
values and principles expressed in the Manifesto for Agile Software Development and the 12
Principles behind it. When you approach software development in a particular manner, it’s generally
good to live by these values and principles and use them to help figure out the right things to do given
your particular context.
 One thing that separates Agile from other approaches to software development is the focus on the
people doing the work and how they work together. Solutions evolve through collaboration between
self-organizing cross-functional teams utilizing the appropriate practices for their context.
 There’s a big focus in the Agile software development community on collaboration and the self-
organizing team.

 That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how
they’re going to approach things on their own.
 It means that those teams are cross-functional. Those teams don’t have to have specific roles
involved so much as that when you get the team together, you make sure that you have all the right
skill sets on the team.
 There still is a place for managers. Managers make sure team members have, or obtain, the right skill
sets. Managers provide the environment that allows the team to be successful. Managers mostly step
back and let their team figure out how they are going to deliver products, but they step in when the
teams try but are unable to resolve issues.
 When most teams and organizations start doing Agile development, they focus on the practices that
help with collaboration and organizing the work, which is great. However, another key set of practices
that are not as frequently followed but should be are specific technical practices that directly deal with
developing software in a way that helps your team deal with uncertainty. Those technical practices are
essential and something you shouldn’t overlook.

Methodologies Of Agile:

A methodology is the set of conventions that a team agrees to follow. That means that each team will have its
own methodology, which will be different in either small or large ways from every other team’s methodology.
So Agile methodologies are the conventions that a team chooses to follow in a way that follows Agile values
and principles.
“Wait,” you’re probably saying, “I thought Scrum and XP were Agile methodologies.” Alistair applied the term
framework to those concepts. They certainly were born from a single team’s methodology, but they became
frameworks when they were generalized to be used by other teams. Those frameworks help inform where a
team starts with their methodology, but they shouldn’t be the team’s methodology. The team will always need
to adapt its use of a framework to fit properly in its context.
Agile Process
Check below Agile process model to deliver successful systems quickly

AGILE MODEL VS WATERFALL MODEL:

Agile Model Waterfall Model

 Agile method proposes incremental and
Development of the software flows sequentially
iterative approach to software design
from start point to end point

 The agile process is broken into individual  The design process is not broken into an
models that designers work on individual models

The customer has early and frequent

opportunities to look at the product and make
decision and changes to the project
 Agile model is considered unstructured
compared to the waterfall model

 Waterfall model are more secure because

 they are so plan oriented

 Small projects can be implemented very

All sorts of project can be estimated and
quickly. For large projects, it is difficult to
estimate the development time. completed

 Only at the end, the whole product is

Error can be fixed in the middle of the project
tested. If the requirement error is found or
any changes have to be made, the project
has to start from the beginning

 Development process is iterative, and the  The development process is phased, and
project is executed in short (2-4) weeks the phase is much bigger than iteration.
iterations. Planning is very less. Every phase ends with the detailed
description of the next phase.

 Documentation is a top priority and can

Every iteration has its own testing phase. It allows
even use for training staff and upgrade
implementing regression testing every time new the software with another team

functions or logic are released

 Only after the development phase, the

In agile testing when an iteration end, shippable
testing phase is executed because
features of the product is delivered to the separate parts are not fully functional.

customer. New features are usable right after

shipment. It is useful when you have good contact
with customers
 Testers and developers work together  All features developed are delivered at
once after the long implementation phase.

 At the end of every sprint, user  Testers work separately from developers
acceptance is performed

 It requires close communication with  User acceptance is performed at the end

developers and together analyze of the project.
requirements and planning

Agile metrics:
Metrics that can be collected for effective usage of Agile is:
  Drag Factor
o Effort in hours which do not contribute to sprint goal
o Drag factor can be improved by reducing number of shared resources, reducing the
amount of non-contributing work
o New estimates can be increased by percentage of drag factor -New estimate = (Old
estimate+drag factor)
 Velocity
o Amount of backlog(user stories) converted to shippable functionality of sprint
 No of Unit Tests added
 Time interval taken to complete daily build
 Bugs detected in an iteration or in previous iterations
 Production defect leakage

MINDSET OF AGILE:
Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and
principles provide guidance on how to create and respond to change and how to deal with uncertainty.
You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering
better ways of developing software by doing it and helping others do it.”
When you face uncertainty, try something you think might work, get feedback, and adjust accordingly.
Keep the values and principles in mind when you do this. Let your context guide which frameworks, practices,
and techniques you use to collaborate with your team and deliver value to your customers.

Business Analysis:
As Agile Software Development became more popular, people involved with software development activities
but who didn’t personally develop software looked for some way to figure out how these Agile ideas applied in
their line of work.
The Agile Manifesto and the 12 Principles were written by a group of software developers (and a tester) to
address issues that software developers faced. When you think of Agile as a mindset, that mindset can be
applied to other activities.
When you do that, Agile becomes an adjective. It describes how you perform some activity. It does not create
a new methodology for the reasons explained above.
When you want to understand Agile project management, ask “How might we perform project management in
a way that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and Project
Management Institute (PMI) explored this question through a joint effort to create the Agile Practice
Guide (Available to Agile Alliance Members).
When you want to understand Agile business analysis, ask “How might we perform business analysis in a way
that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and International
Institute of Business Analysis (IIBA) explored this question through a joint effort to create the Agile Extension
to the Business Analysis Body of Knowledge (Available to Agile Alliance Members).

The two concepts noted above are examples of an attempt to move Agile “outside of software.” Those efforts
have resulted recently in the Business Agility movement.
If you extend the idea of Agile as a mindset, then people seeking Business Agility ask themselves, “How might
we structure and operate our organization in a way that allows us to create and respond to change and deal
with uncertainty?”
You might say that business agility is a recognition that in order for people in an organization to operate with an
Agile mindset, the entire organization needs to support that mindset. Agile software development was never
truly Agile until the organization changed its structure and operations to work in an uncertain environment.

KEY CONCEPTS AGILE:

Below are a few key Agile concepts. You can see more in our glossary section.
 User Stories: In consultation with the customer or product owner, the team divides up the work to be
done into functional increments called “user stories.” Each user story is expected to yield a
contribution to the value of the overall product. (see more)

 Daily Meeting: Each day at the same time, the team meets so as to bring everyone up to date on the
information that is vital for coordination: each team members briefly describes any “completed”
contributions and any obstacles that stand in their way. (see more)
 Incremental Development: Nearly all Agile teams favor an incremental development strategy; in an
Agile context, this means that each successive version of the product is usable, and each builds upon
the previous version by adding user-visible functionality. (see more)
 Iterative Development: Agile projects are iterative insofar as they intentionally allow for “repeating”
software development activities, and for potentially “revisiting” the same work products. (see more)
 Team: A “team” in the Agile sense is a small group of people, assigned to the same project or effort,
nearly all of them on a full-time basis. A small minority of team members may be part-time
contributors, or may have competing responsibilities. (see more)
 Milestone Retrospective: Once a project has been underway for some time, or at the end of the
project, all of the team’s permanent members (not just the developers) invests from one to three days
in a detailed analysis of the project’s significant events. (see more)

 Personas: When the project calls for it – for instance when user experience is a major factor in project
outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product:
these are called “personas.” (see more)

Design Patterns:
In software engineering, a design pattern is a general repeatable solution to a commonly occurring
problem in software design. A design pattern isn't a finished design that can be transformed directly into
code. It is a description or template for how to solve a problem that can be used in many different
situations.

Uses of Design Patterns:

Design patterns can speed up the development process by providing tested, proven development
paradigms. Effective software design requires considering issues that may not become visible until later in
the implementation. Reusing design patterns helps to prevent subtle issues that can cause major
problems and improves code readability for coders and architects familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain problems.
These techniques are difficult to apply to a broader range of problems. Design patterns provide general
solutions, documented in a format that doesn't require specifics tied to a particular problem.

In addition, patterns allow developers to communicate using well-known, well understood names for
software interactions. Common design patterns can be improved over time, making them more robust
than ad-hoc designs.

Creational design patterns

These design patterns are all about class instantiation. This pattern can be further divided into class-
creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively
in the instantiation process, object-creation patterns use delegation effectively to get the job done.

 Abstract Factory
Creates an instance of several families of classes
 Builder
Separates object construction from its representation
 Factory Method
Creates an instance of several derived classes
 Object Pool
Avoid expensive acquisition and release of resources by recycling objects that are no longer in
use
 Prototype
A fully initialized instance to be copied or cloned
 Singleton
A class of which only a single instance can exist

Structural design patterns:

These design patterns are all about Class and Object composition. Structural class-creation patterns use
inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain
new functionality.

 Adapter
Match interfaces of different classes
 Bridge
Separates an object’s interface from its implementation
 Composite
A tree structure of simple and composite objects
 Decorator
Add responsibilities to objects dynamically
 Facade
A single class that represents an entire subsystem
  Flyweight
A fine-grained instance used for efficient sharing
 Private Class Data
Restricts accessor/mutator access
 Proxy
An object representing another object

Behavioral design patterns:

These design patterns are all about Class's objects communication. Behavioral patterns are those
patterns that are most specifically concerned with communication between objects.

 Chain of responsibility
A way of passing a request between a chain of objects
 Command
Encapsulate a command request as an object
 Interpreter
A way to include language elements in a program
 Iterator
Sequentially access the elements of a collection
 Mediator
Defines simplified communication between classes
 Memento
Capture and restore an object's internal state
 Null Object
Designed to act as a default value of an object
 Observer
A way of notifying change to a number of classe
 State
Alter an object's behavior when its state changes
 Strategy
Encapsulates an algorithm inside a class
 Template method
Defer the exact steps of an algorithm to a subclass
 Visitor
Defines a new operation to a class without change

Exploring Inheritance

 Inheritance can be tired two ways: by subclassing existing classes and by executing
interfacing. The major objective of inheritance is reuse, but the two approaches accomplish
this objective in numerous ways.
 Inheritance is a characteristic offered by many class/object-oriented languages and allows
you to "inherit" some/all of the functionalities from a "parent" object or class.
 The object that inherits those functionalities can eventually alter some of them but for the rest
behave as the inherited class.
 There are following types of inheritance: -

• Single Inheritance

• Multiple Inheritance

• Multilevel Inheritance

• Hierarchical Inheritance

• Hybrid Inheritance

• Multipart Inheritance

Single Inheritance: It contains one Base Class and one Derived Class. Contents of the Parent
Class is Inherited into the Derived Class

Multiple Inheritance: Two or more base class inherited into a single derived class.

Hierarchical Inheritance: is straight opposite to Multiple Inheritance. One Parent Class is Inherited
into more than Derived Class.

Multilevel Inheritance: different form of inheritance. Base class inherited by another derived
class changes into base class and then inherited into derived class.

Hybrid Inheritance: the complex type of Inheritance. Parent Class is Inherited to Child Class and
the Child Class changes to Base or parent Class and once again Inherited to Child Class.

It could be combination of Single Inheritance and Multi Level Inheritance.

Multipart Inheritance: it is possible to have a single Base Class and that Base Class is Inherited
into a collection of Derived Class in any Part or direction.

Interactive systems with MVC architecture:

MVC is known as an architectural pattern, which embodies three parts Model, View and Controller, or to be
more exact it divides the application into three logical parts: the model part, the view and the controller. It
was used for desktop graphical user interfaces but nowadays is used in designing mobile apps and web
apps

MVC Architecture:

MVC is an architectural pattern which means it rules the whole architecture of the applications. Even

though often it is known as design pattern but we may be wrong if we refer it only as a design pattern

because design patterns are used to solve a specific technical problem, whereas architecture pattern is

used for solving architectural problems, so it affects the entire architecture of our application.

It has three main components:

-Model

-View

-Controller

and each of them has specific responsibilities

MVC Architecture:

The main reasons why MVC is used are: First, it doesn't allow us to repeat ourselves and second, it help to
create a solid structure of our web applications.

Model

It is known as the lowest level which means it is responsible for maintaining data. Handle data

logically so it basically deals with data. The model is actually connected to the database so

anything you do with data. Adding or retrieving data is done in the model component. It responds

to the controller requests because the controller never talks to the database by itself. The model

talks to the database back and forth and then it gives the needed data to the controller. Note: the

model never communicated with the view directly.

View: Data representation is done by the view component. It actually generates UI or user interface

for the user. So at web applications when you think of the view component just think the Html/CSS

part. Views are created by the data which is collected by the model component but these data

aren’t taken directly but through the controller, so the view only speaks to the controller.

Controller

It’s known as the main man because the controller is the component that enables the interconnection

between the views and the model so it acts as an intermediary. The controller doesn’t have to worry about

handling data logic, it just tells the model what to do. After receiving data from the model it processes it and

then it takes all that information it sends it to the view and explains how to represent to the user. Note:

Views and models can not talk directly.

Advantages of MVC

- MVC architecture will separate the user interface from business logic and business logic

- Components are reusable.

- Easy o maintain.

- Different components of the application in MVC can be independently deployed and maintained.

- This architecture helpt to test components independently.

Disadvantages of MVC

-The complexity is high.

-Not suitable for small applications.

-The inefficiency of data access in view.

Conclusion
So MVC is not that easy to understand, it’s really hard actually, but not impossible to learn and every

developer needs to keep it in mind when developing an application. Just keep in mind that MVC is an

architecture that divides your software into smaller components. The model deals with data and the logic of

your system. The view only displays data and the controller maintains the connection between the model

and the view. This ‘division’ enables readability and modularity as well it easier the testing part.

Just keep in mind these key points:

-MVC is an architectural pattern consisting of three parts: Model, View, Controller.
Model: Handles data logic.
View: It displays the information from the model to the user.
Controller: It controls the data flow into a model object and updates the view whenever data changes.
-It is invented by Trygve Reenskau.
- Even though it’s very popular and it does have some disadvantages, the main one is complexity.

Software reuse:
Software reuse is a term used for developing the software by using the existing software components.
Some of the components that can be reuse are as follows;

 Source code
 Design and interfaces
 User manuals
 Software Documentation
 Software requirement specifications and many more

What are the advantages of software reuse?

 Less effort: Software reuse requires less effort because many components use in the system
are ready made components.
 Time-saving: Re-using the ready made components is time saving for the software team.
 Reduce cost: Less effort, and time saving leads to the overall cost reduction.
 Increase software productivity: when you are provided with ready made components, then you
can focus on the new components that are not available just like ready made components.
 Utilize fewer resources: Software reuse save many sources just like effort, time, money etc.
 Leads to a better quality software: Software reuse save our time and we can consume our
more time on maintaining software quality and assurance.

What are Commercial-off-the-shelf and Commercial-off-the-shelf components?

Commercial-off-the-shelf is ready-made software. Commercial-off-the-shelf software components are
ready-made components that can be reused for a new software.

What is reuse software engineering?

Reuse software engineering is based on guidelines and principles for reusing the existing software.

What are stages of reuse-oriented software engineering?

Requirement specification:
First of all, specify the requirements. This will help to decide that we have some existing software
components for the development of software or not.
Component analysis
Helps to decide that which component can be reused where.
Requirement updations / modifications.
If the requirements are changed by the customer, then still existing components are helpful for reuse or
not.
Reuse System design
If the requirements are changed by the customer, then still existing system designs are helpful for reuse
or not.
Development
Existing components are matching with new software or not.
Integration
Can we integrate the new systems with existing components?
System validation
To validate the system that it can be accepted by the customer or not.

Software reuse success factors:

1. Capturing Domain Variations

2. Easing Integration
3. Understanding Design Context
4. Effective Teamwork
5. Managing Domain Complexity

How does inheritance promote software re-usability?

Inheritance helps in the software re-usability by using the  existing components of the software to create
new  component.
In object oriented programming protected data members are accessible in the child and so we can say
that yes inheritance promote software re-usability.