Software Architecture Design Report
Uploaded by
ScribdTranslationsSoftware Architecture Design Report
Uploaded by
ScribdTranslationsINFORMATION SYSTEM SOFTWARE AND
HARDWARE ARCHITECTURE DESIGN
REPORT
TADSI
Daniel Hernandez
YEAR 2019
INTRODUCTION
The physical architecture of the system refers to the topology of the system,
showing how the different subsystems or components (software) will be
physically assigned to the different computing equipment (hardware) used to
implement the information system. Deployment diagrams are used to describe
the assignment of software to hardware, which detail, among other things,
machine specifications, network capacity, and hardware requirements.
SCOPE OF THE INFORMATION SYSTEM
Information systems are essential as they allow us to have a greater scope of the
steps to follow within a project. The scope of this project is vital for clients as it
allows us to have a clearer idea of what they want and thus be able to provide
them with a quality service that can give them great satisfaction.
It is also essential to have high-quality tools so that the project to be developed
allows us to have the least possible errors and meet the budget, reducing the
increase in costs.
SCOPE OF THE INFORMATION SYSTEM
DEFINITIONS AND ACRONYMS
This project allows us to know the roadmap that we must follow with the system
in development, so it is very important to be able to follow what type of actors
would intervene in it and thus give peace of mind to the client.
We have used different tools to achieve the system
REFERENCES
Derniame, J. (2006). Software Process: Principals, Methodology and Technology.
Springer. Lledó, P. (2016).
Project Manager: How to pass the PMP exam.
James Rumbaugh, G. B. (2006). The Unified Modeling Language: A Reference
Manual (Vol. 2nd edition). Pearson Education.
DOCUMENT OVERVIEW
The system in development allows us to optimally interact with the principles of
the documents that are part of the report, having a clear and precise idea of the
objective in question. This report allows us to specify, through the diagrams, a
real route of the independence of the components of each of the developer's
interests in each of the required fields of action.
PRODUCT INSIGHTS
The product in question generates a series of perspectives that involve a series
of elements to give the client peace of mind about the project and also avoid
possible inconveniences when executing the values and respective actions of the
data and supplies that must be clear in this regard.
The product must also generate confidence when indicating its execution
purposes, whether in software or hardware processes.
PRODUCT FEATURES
These functions have to do with the efficiency in reading the process manual as
well as the layout of the systems that are involved with each other and the most
effective way of operating them for customer satisfaction. This is easy to interpret
and understand.
The product's function is to effectively solve a problem that the client exposes
and requires a correct interpretation so that its quality is effective.
RESTRICTIONS
There are few restrictions that prevent the correct appropriation of the system;
one only needs to be cautious in the way one interprets the process to be
followed.
ASSUMPTIONS AND DEPENDENCIES
SOFTWARE ARCHITECTURE
USE CASE MODEL
CLASS MODEL
PACKAGE MODEL
SEQUENCE MODEL
MODEL OF ACTIVITIES
HARWARE ARCHITECTURE
COMPONENT MODEL
DEPLOYMENT MODEL
NODE MODEL
ANNEXES
