CAREER: SYSTEMS ENGINEERING

SOFTWARE ENGINEERING PROJECT

MEMBERS:

NICOLE SERRATE

HUGO MARCELO AJHUACHO

ERICK RODRIGO MAMANI

Instructor: Eng. Zuleica Mariaca

AUGUST 2018
Santa Cruz - Bolivia

II
 INDEX

INDEX

STATEMENT CASE STUDY................................................................1

2. ASPECTS GENERAL.....................................................................................5

2.1. Title of the project............................................................................................5

2.2. Introduction......................................................................................................5

2.3. Definition from the problem....................................................................................5

2.4. Delimitations...................................................................................................5

2.4.1. Geographic.....................................................................................................5

2.4.2. Temporal.......................................................................................................5

2.4.3. Themes........................................................................................................6

2.4.4. Scope..........................................................................................................6

2.5. Objective General

2.6. Objectives Specifics

3. FRAME THEORY OF SOFTWARE ENGINEERING...............................................7

3.1. What what is and what is not Software Engineering.....................................................7

3.2. Principles fundamentals..................................................................................7

3.2.1. Principles that guide the process........................................................7

3.2.2. Principles that guide the practice..............................................................8

3.3. Principles that guide all structural activity..........................................10

3.3.1. Principles of communication.........................................................................10

3.3.2. Principles of planning

3.3.3. Principles modeling

3.3.4. Requirements of the modeling principles..........................................17

II
3.3.5. Principles of the design model.................................................................18

3.4. Principles under construction............................................................21

3.4.1. Principles of encoding............................................................................21

3.4.1.1. Principles of preparation........................................................................21

3.4.1.2. Principles of programming.....................................................................21

3.4.1.3. Principles validation

3.4.1.4. Principles from the test.............................................................................22

3.4.1.5. Principles deployment..........................................................................23

3.5. What it is quality

Quality of the software....................................................................................24

3.5.2. The Software quality dilemma............................................................24

3.5.2.1. Software sufficiently good

The cost of quality..................................................................................25

3.5.2.3. Risks......................................................................................................25

3.5.3. Achieve the quality of the software

3.5.3.1. Methods of Software Engineering.....................................................26

3.5.3.2. Techniques project management................................................26

3.5.3.3. Control of quality....................................................................................26

3.5.3.4. Assurance of quality....................................................................26

3.6. Elements software quality assurance................................27

3.6.1. Security of the Software...............................................................................27

3.7. Administration of the project...........................................................................27

3.7.1. The Administrative spectrum...........................................................................28

3.7.1.1. Definition The Staff........................................................................28

3.7.1.1.1. Participants.........................................................................................28

II
3.7.1.1.2. Leaders of Team.................................................................................29

3.7.1.1.3. Equipment of Software..............................................................29

3.7.1.2. Definition The product........................................................................29

3.7.1.2.1. Scope of the software..............................................................................30

3.7.1.2.2. Decomposition of the problem.............................................................30

3.7.1.3. Definition The process...........................................................30

3.7.1.3.1. Fusion of product and process..............................................................30

3.7.1.3.2. Decomposition of the process................................................................30

3.7.1.4. Definition The project.......................................................31

3.8. Scheduling of the Project.........................................................................31

3.9. Metrics of the Product.....................................................................................31

3.9.1. Measures, metrics and indicators.................................................................31

3.9.2. Principles of measurement

3.9.3. Metrics for the Requirements Model..............................................32

3.9.3.1. Metrics based on functions...............................................................32

3.9.3.2. Metrics for the quality of the specification..............................................32

3.9.4. Metrics for the Design Model.............................................................33

3.9.5. Metrics for object-oriented design...................................................33

3.9.6. Metrics for Tests................................................................................35

3.9.6.1. Metrics for Object-Oriented testing..........................................35

3.9.6.2. Metrics for Maintenance.................................................36

3.9.7. Definition Metrics for Software Quality.....................................36

3.9.7.1. Measurement of quality..............................................................................36

3.9.7.2. Efficiency in the removal of the defect......................................................37

3.9.7.3. Establishment from a software metrics program..........................37

II
 3.9.8. Administration of the Risk...........................................................................38

3.9.8.1. Identification of Risks.........................................................................38

3.9.8.2. Projection of Risk.............................................................................38

3.9.8.3. Assessment risk impact..............................................................39

3.9.8.4. The plan MMMR..........................................................................................39

4. FRAME THEORY OF METHODOLOGY........................................................39

4.1. PUDS

4.1.1. Characteristics.............................................................................................40

4.1.1.1. Iterative e Incremental..............................................................................40

4.1.1.2. Directed for the use cases..............................................................40

4.1.1.3. Centered in architecture.....................................................................41

4.1.1.4. Focused in the risks...........................................................................41

4.2. UML................................................................................................................41

4.2.1. Definition from Unified................................................................................41

4.2.2. Types of Domain.........................................................................................41

4.2.3. Objectives UML.............................................................................................42

4.2.4. Model.........................................................................................................42

5. ENGINEERING THE PROJECT SOFTWARE................................................43

5.1. Planning temporal.................................................................43

5.2. Organization of the staff (Structure of the software development team)

44

5.3. Estimation of the project (Assume Productivity = 29.5).................................45

5.3.1. Metrics based on Function Point ....................................................... 45

5.3.2. Values of complexity adjustment...............................................................47

5.3.3. Calculation from the point of function........................................................................48

II
 5.3.4. Calculation of Effort...................................................................................49

5.3.5. Calculation number of people who will make up the development team
of the software..............................................................................................................49

5.3.6. of the staff.......................................................................................49

5.3.7. Cost of the Software......................................................................................49

5.4. Analysis Risk Management........................................................................50

5.4.1. Scale based on the appearance of the staff..................................................50

5.4.2. Scale based on the technological aspect...................................................50

5.4.3. Scale based on the business aspect...................................................50

5.5. Management of Quality.....................................................................................51

5.5.1. Quality based on 5 metrics (Correction, Reliability, Efficiency,

Integrity, Ease of Maintenance)..................................................................51

5.5.2. Standards........................................................................................................51

5.5.2.1. Standard ISO 25000....................................................................................51

5.6. Budget....................................................................................................53

5.6.1. Cost partial of the software development tasks................................53

5.6.2. Cost partial of project management......................................................53

5.6.3. Cost partial resources............................................................................53

5.6.4. Cost partial of basic services..............................................................54

5.6.5. Cost partial of extra material...............................................................54

5.6.6. COST TOTAL DEL PROYECTO..............................................................54

5.7. Plan of communication.....................................................................................54

6. ENGINEERING OF THE PROJECT............................................................................55

6.1. Model of Requirements.....................................................................................55

6.1.1. Requirements functional........................................................................55

II
 6.1.2. Requirements non-functional...........................................................................57

6.1.3. Description of the actors............................................................58

6.2. Model of Analysis..........................................................................................59

6.2.1. Diagram general of the use cases.......................................................59

6.2.2. Specification of the use case 'Register Sale'.......................................61

Manage Sales

Seller......................................................................................................................61

Description

Normal

Alternative....................................................................................................................61

6.2.3. Model of domain......................................................................................62

6.2.3.1. Diagram of conceptual classes...........................................................62

6.2.3.2. Model relational data......................................................................63

6.3. Model of Design

6.3.1. Diagram of sequence...............................................................................64

6.4. Model Implementation.............................................................................65

6.4.1. Model of Components............................................................................65

6.4.2. Model of Deployment.................................................................66

7. CONCLUSIONS

8. RECOMMENDATIONS.........................................................................................67

9. BIBLIOGRAPHY.....................................................................................................68

II
 1. CASE STUDY STATEMENT

HUMAN RESOURCES INFORMATION SYSTEM FOR THE COMPANY

REPSOL YPFB.SA

I. PROBLEMATIC SITUATION

The company REPSOL YPFB S.A is facing difficulties with management

information from the HR area. In this regard, a system is needed that can
manage the Kardex, payroll sheets, AFP sheets, vacations, bonuses,
Settlements, control of lactations and reports of medical insurance admissions and discharges.

II. BUSINESS LOGIC

Employees are hired for projects, which can last from one to two.
years. The contracts of administrative personnel are indefinite in nature but the
field staff contracts are project-based. A project can span two
contiguous geographic areas.

Both workers and administrative staff need to submit the following information: ID,
Full name
Telephone.

For each project, workers are hired to carry out the dismantling work,
drilling, detonation, and seismic tracking of the predetermined lines in which
there is probably oil so that another company can later do the
extraction of the 'black gold'

Each contract specifies a basic salary according to the role (cook, nurse,
foreman, mechanic) that the worker has to perform in the field.

At the end of each month, the administrators of the different field projects must
send the attendance sheets of the workers to process the respective ones
payroll sheets. The pay slips must be printed along with the payroll sheets.
payment.

In addition to the general payroll, the AFP payroll must be printed.

At the beginning of each project, a sheet of all the workers must be printed who
they will be affiliated with health insurance.

At the end of each month, a sheet of the workers who must be filled out is also required.
withdrawn from health insurance due to contract expiration.

1
The monthly form sent to the health insurance must specify the same.
data that the payroll sheet to reduce the monthly amount that the company owes
pay the insurance.

During the work month, the system must record the advance requests for
salaries.

The company recognizes vacation twelfths, bonuses for all types of

contract (worker and administrative)

At the end of a project, it is necessary to process the calculations to settle all the
workers except for the administrative staff who continue with their active contracts.

It is necessary to control the accumulation of vacation time for administrative staff according to
the law (1 to 5 years: 15 days; 6 to 9 years: 20 days; >=10 years: 30 days). This type also
Workers are entitled to a seniority bonus according to the law (2 to 4 years 5%; 5
at 7 years 11%; 8 to 10 years 18%, etc

The workers must submit their RCIVA forms to the central office for the
discount deduction (13%) for commercial transactions. These amounts must
to be taken into account when processing the payroll.

III. DEVELOPMENT APPLYING SOFTWARE ENGINEERING

Temporal planning.

Organization of personnel (Structure of the development team of

software

Project estimation (Assume Productivity = 29.5)

Function Point Based Metrics

Adjustment values of complexity

Function point calculation

Calculation of Effort

2
 Calculation of the number of people who will make up the team of
software development.

Personnel cost

Cost of Software

Risk Analysis and Management

Scale based on the appearance of the staff

Scale based on the methodological aspect

Scale based on the business aspect

Quality Management

Quality based on 5 metrics (Correctness, Reliability,

Efficiency, Integrity, Ease of Maintenance

Rules

Budget

Partial cost of software development tasks.

Partial cost of project management.

Partial cost of resources

Partial cost of basic services.

Partial cost of extra material

TOTAL COST OF THE PROJECT

IV. DEVELOPMENT APPLYING METHODOLOGY

The development must be carried out using PUDS and UML.

3
V. BASIC USE CASES

VI. REQUESTED ARTIFACTS

a) Requirements Model

Functional Requirements

Non-functional requirements

Description of the actors

b) Analysis Model

General diagram of the use cases (all)

Specification of the selected use case.

Domain model

Diagram of conceptual classes

Relational data model

c) Design Model

Sequence diagram

Report design,

Database design: Logical and physical

d) Implementation Model

Components Model

Deployment Model

4
2. GENERAL ASPECTS

2.1. Project Title

HUMAN RESOURCES INFORMATION SYSTEM FOR THE COMPANY

REPSOL YPFB.SA

2.2. Introduction

The present document aims at the development of a SYSTEM OF

HUMAN RESOURCES INFORMATION FOR THE COMPANY 'REPSOL'
YPFB.SA

2.3. Problem Definition

The company REPSOL YPFB.SA is having difficulties with management.

information from the HR area. In this sense, a system is needed that can
manage the Kardex, salary sheets, AFP sheets, vacations, bonuses
Settlements, Control of lactations and reports of high and low from the second doctor.

2.4. Delimitations

The research will take the geographical space for information collection in
Department of Santa Cruz specifically in the metropolitan area

The present project will be carried out taking into account data included between the
year 2012 – 2017, since during this time period the company VUITON SRL had
greater inconveniences with your developed system.

2.5. General Objective

Develop a Human Resources Information System that allows to cover the

needs for the automation of the tasks of the company REPSOL YPFB.SA.

2.6. Specific Objectives

5
 Determine the requirements of the system to be developed in order to
lay the groundwork for the development of a design according to the
identified needs and difficulties.
Carry out the construction of the management system that solves the problems
analyzed and that meets the requirements obtained in the phase of
analysis and design.
Carry out the implementation of the developed system taking into account that
resulting software that meets all the proposed requirements and
approved by the officials of the company VUITON SRL.

3. THEORETICAL FRAMEWORK OF SOFTWARE ENGINEERING

3.1. What is and what is not Software Engineering

Software engineering is the application of a systematic, disciplined approach.

quantifiable to the development, operation, and maintenance of software, and the study of
these approaches, that is, the study of the applications of engineering to software.
Integrates mathematics, computer science, and practices whose origins are
they are found in engineering.

3.2. Fundamental principles

3.2.1. Principles guiding the process

Principle 1. Be agile. Whether the chosen process model is prescriptive or

Agile, it is the basic principles of agile development that should govern the approach.
Every aspect of the work that is done must emphasize the economy of
action: to keep the technical focus as simple as possible, to make the
work products that are generated as concisely as possible and take the
decisions locally, whenever possible.

Principle 2. At each stage, focus on quality. The exit condition for all
activity, action, and task of the process must focus on the quality of the product
work that has been generated.

6
Principle 3. Be ready to adapt. The process is not a religious experience, in it
there is no room for dogma. When necessary, adapt your approach to the
restrictions imposed by the problem, the people, and the project itself.

Principle 4. Form an effective team. The process and practice of engineering

software is important, but the goal is people. Form a team with
own organization in which there is mutual trust and respect.

Principle 5. Establish mechanisms for communication and coordination. The

projects fail because important information falls through the cracks or because the
participants do not coordinate their efforts to create a successful final product. These
they are aspects of management that must be faced.

Principle 6. Managing change. The approach can be formal or informal, but

mechanisms should be established to manage the way changes are made
they request, evaluate, approve, and implement.

Principle 7. Assess the risk. There are many things that can go wrong when you
develop software. It is essential to establish contingency plans.

Principle 8. Create work products that add value for others. Only generate
those work products that add value to other activities, actions or
tasks of the process. Any product of the work that is generated as part of the
software engineering practice will be passed to someone else. The list of functions and
required characteristics will be given to the person (or people) who will develop a
design, the design will pass to those who generate code and so on. Make sure
that the product of work imparts the necessary information without ambiguities or
omissions.[ CITATION Rog l 3082 ]

3.2.2. Principles that guide the practice

The practice of software engineering has a single overarching goal: to deliver to

high-quality operating software that contains features and characteristics

7
that satisfy the needs of all participants. To achieve this, it must
to adopt a set of fundamental principles that guide technical work.
These principles have merit regardless of the analysis and design methods that
the construction techniques (for example, the language of
programming or the automated tools) that are used or the approach of
verification and validation that is chosen. The following fundamental principles are
vital for the practice of software engineering:

Principle 1. Divide and conquer. To put it more technically, analysis and design
they should always emphasize the separation of entities (SdE). A big problem is
easier to solve if divided into a set of elements (or entities). The ideal
Each entity should provide distinct functionality that can be developed, and in
certain cases validate themselves, regardless of other entities.

Principle 2. Understand the use of abstraction. At its core, an abstraction

it's a simplification of some complex element of a system used for
communicate the meaning in a single sentence. When the abstraction sheet is used
calculation, it is supposed to understand what a spreadsheet is, the structure
general content that it presents and the common functions that apply to it.

Principle 3. Seek coherence. Whether creating a model of the

requirements, a software design is developed, source code is generated or
develop test cases, the principle of coherence suggests that a family context
makes the software easier to use.

Principle 4. Focus on information transfer. Software is about

with the transfer of information: from a database to an end user, from a
inherited system to a web app, from an end user to a graphical user interface
(GUI, for its initials in English), from an operating system to an application, from a
software component to another... the list is almost endless. In all cases, the
information flows through an interface, and as a consequence there are possibilities of
to make mistakes, omissions, or ambiguities. This principle implies that it must
pay special attention to the analysis, design, construction, and testing of interfaces.

8
Principle 5. Build software that has effective modularity. The separation of
entities (principle 1) establishes a philosophy for software. Modularity
provides a mechanism to carry out that philosophy. Any system
complex can be divided into modules (components), but the good practice of the
software engineering demands more. Modularity must be effective.

Principle 6. Look for patterns. Brad Appleton [App00] suggests that: The goal of
patterns within the software community is to create a body of bibliography that
help software developers solve recurring problems that arise
throughout the development. Patterns help to create a shared language for
communicate perspective and experience regarding these patterns and their solutions. The
formal coding of these solutions and their relationships allows for successful accumulation
the body of knowledge that defines our understanding of the good
architectures that meet the needs of their users.

Principle 7. When possible, represent the problem and its solution from various
different perspectives. When a problem and its solution are studied from various
different perspectives, it is more likely that there will be greater insight and that they will be detected

the errors and omissions.

Principle 8. Keep in mind that someone will maintain the software. The software
it will be corrected in the long term, when its defects are discovered, it will adapt to the
changes in their environment and improve at the moment participants ask
more capabilities. These maintenance activities become easier if they
apply a solid software engineering practice throughout the process of
software [ CITATION Rog 3082 ]

3.3. Principles that guide all structural activity

3.3.1. Communication principles

Effective communication (between technical colleagues, with the client and other participants,
and with the project managers) is among the most difficult activities that

9
must be confronted. In this context, principles of communication are studied here.
applied to communication with the client. However, many of them are applied
equally in all forms of communication that occur within a project of
software

Principle 1. Listen. Try to focus on the words of the speaker instead of

formulate your response to those words. If something is unclear, ask for
clarify it, but avoid constant interruptions. If a person speaks, never
appear beligerent in your words or actions (for example, with eye rolls
or head movements).

Principle 2. Before communicating, prepare yourself. Spend some time understanding the
problem before meeting with other people. If necessary, make some
research to understand the specific vocabulary of the business. If you have the
responsibility to lead the meeting, prepare an agenda before it takes place
place.

Principle 3. Someone must facilitate the activity. Every communication meeting must
having a leader (facilitator) who: 1) keeps the conversation moving towards a
positive direction, 2) be a mediator in any conflict that arises and 3) guarantee
that other principles continue.

Principle 4. Face-to-face communication is better. But generally, it works better.

when there is another representation of the relevant information present. By
for example, a participant may create a drawing or document in "draft" that serves
as the center of the discussion

Principle 5. Take notes and document decisions. Things find a way.

to fall into the cracks. Someone who participates in the communication must serve as
secretary and write down all the important topics and decisions

Principle 6. Pursue collaboration. Collaboration and consensus occur when

the collective knowledge of the team members is used to describe
functions or features of the product or system. Every small contribution helps

10
to build trust among team members and create a common goal for
the group

Principle 7. Stay focused; make modules with the discussion. The more
the more people participate in any communication, the more likely the conversation is
jump from one topic to another. The facilitator should form conversation modules for
abandon a topic only after it has been resolved.

Principle 8. If something is unclear, make a drawing. Verbal communication has its

limits. Often, a diagram or drawing brings clarity when words do not.
They are enough to do the work.

Principle 9. a) Once something is agreed upon, move forward. b) If it is not possible to come to an agreement

agree on something, move forward. c) If a characteristic or function is not clear or cannot

clarify in the moment, move forward. Communication, like any activity of
software engineering takes time. Instead of doing endless iterations, the
participants must recognize that there are many issues that require
analysis (see principle 2) and that 'moving forward' is sometimes the best way to have
agility in communication.

Principle 10. Negotiation is not a competition or a game. It works better when

both parties win. There are many circumstances in which you and others
participants must negotiate roles and features, priorities and dates of
delivery.

3.3.2. Planning Principles

The communication activity helps to define the general goals and objectives.
supposed, subject to change as time goes by). However, the understanding
defining a plan to achieve them is not the same as setting these goals and objectives.
Planning activity includes a set of administrative and technical practices.
that allow the software team to define a roadmap as it progresses towards its
strategic meta and its tactical objectives

11
Principle 1. Understand the scope of the project. It is impossible to use the map if you do not

knows where it is going. The scope gives a destination to the software team

Principle 2. Involve software participants in the planning activity.

Participants define the priorities and establish the project constraints.
To include these realities, it is common for software engineers to have to
negotiate the delivery order, timelines, and other related matters
project.

Principle 3. Acknowledge that planning is iterative. A plan for the project never
it is carved in stone. By the time the work begins, it is very likely that the
things have changed. Consequently, the plan must be adjusted to include those
changes. In addition, incremental iterative process models dictate that it must
repeat the planning after the delivery of each software increment, with
based on the feedback received from users.

Principle 4. Estimate based on what is known. The objective of estimation is

obtain an index of the effort, cost, and duration of tasks, based on
understanding that the team has about the work they are going to do. If the information
it is vague or unreliable, so the estimates will also not be reliable

Principle 5. When defining the plan, consider the risks. If you have identified risks
that would have a big effect and it is very likely that they will happen, so it is
it is necessary to develop contingency plans. In addition, the project plan (including the
activity programming) must be adjusted to include the possibility that
one or more of those risks occur.

Principle 6. Be realistic. People do not work 100% every day. In any

In human communication, there is noise. Omissions and ambiguity are phenomena of the
Life. Changes happen. Even the best software engineers make mistakes.
These and other realities must be considered when establishing a project.

Principle 7. Adjust the granularity when defining the plan. The granularity is
refers to the level of detail adopted when developing a plan. A plan with

12
"a lot of granularity" provides meaningful details in the tasks for the work
what is planned, in increments over a relatively short period (so that the
monitoring and control happen frequently.

Principle 8. Define how to ensure quality. The plan must identify the
the way the software team seeks to ensure quality. If it is carried out
Technical reviews must be scheduled. If it is going to be used during construction.
pair programming

Principle 9. Describe how to manage change. Even the best planning

it can be canceled by uncontrolled change. The way in which it must be identified
The changes will be received as the engineering work progresses.
software. For example, does the client have the option to request a change in
Any moment? If one is requested, is the team obliged to implement it?
Immediate? How are the effect and cost of the change evaluated?

Principle 10. Follow up on the plan frequently and make the adjustments that are necessary.

They require. Software projects are delayed in relation to their schedule. By

Therefore, it makes sense to evaluate progress daily, in search of areas and situations.
issues where the scheduled activities do not align with the actual progress.
When himself
detect deviations, one must adjust the plan in
consequence

3.3.3. Modeling Principles

Models are created to better understand the real entity that is going to be built. When
this is physics (for example, a building, an airplane, a machine, etc.), a
model in identical form but to scale. However, when the entity that is going to
building software, the model must take a different form. It must be capable of
represent the information that the software transforms, the architecture, and the functions
that allow this to happen, the characteristics that users desire and the
system behavior while the transformation takes place. The models
they must meet these objectives at different levels of abstraction, in the first place

13
with the illustration of the software from the client's perspective and then with its
representation at a more technical level.

Principle 1. The software team’s main goal is to produce software, not

create models. Agility means delivering software to the client in the fastest way possible
Possible. The models that contribute to this are beneficial, but they must be avoided.
those who slow down the process or provide little perspective.

Principle 2. Travel light, do not create more models than necessary. Every model that
It is believed that it should be updated if changes occur. More importantly, everything

the new model requires time, which would otherwise be allocated to construction
(coding and testing). So, create only those models that make it easier and
quickly build the software.

Principle 3. Try to produce the simplest model that describes the problem or the
software. Do not build software excessively [Amb02b]. By keeping it simple
models, the resulting software will also be. The result is that there will be a
easy to integrate, test, and maintain software (for it to change). Moreover, the
simple models are easier to understand and critique by the members
of the team, resulting in a functional feedback format that
optimize the final result.

Principle 4. Build models that are susceptible to change. Suppose that your models
they will change, but ensure that this assumption does not make you careless. For example,

As the requirements will change, there is a tendency to ignore the models.

Why? Because it is known that they will change anyway. The problem with this
attitude is that without a reasonably complete model of the requirements, one
it will create a design (design model) that will invariably lack functions
and important characteristics.

Principle 5. Being able to state an explicit purpose for each model that is
Create. Every time you create a model, ask yourself why you are doing it. If you don't find

a solid reason for the existence of the model, don't waste time on it.

14
Principle 6. Adapt the models developed to the system in question. Perhaps
it is necessary to adapt the application's notation of the model or the rules;
For example, a video game application may require a modeling technique.
different from the embedded software that controls a car engine in real time
real.

Principle 7. Try to build useful models, but forget about developing models.
perfect. When a software engineer builds requirement models and
design reaches a point of diminishing returns. That is, the effort
required to completely finish the model and make it internally consistent
stop benefiting from having such properties. Is it suggested that modeling
Should it be poor or low quality? The answer is 'no'. But the modeling must
to focus on the following stages of software engineering.
Endless iterations to obtain a 'perfect' model do not meet the need for
agility.

Principle 8. Do not be dogmatic about the syntax of the model. If one is successful
to communicate content, representation is secondary. Although each member
the software team should try to use a consistent notation during the
modeling, the most important feature of the model is to communicate information that
allow the execution of the following engineering task. If a model is successful in
doing this, the incorrect syntax is forgivable.

Principle 9. If your instinct says that a model is not the right one, despite how it looks.
Well on paper, there are reasons to be concerned. If you are an engineer of
experienced software, trust your instincts. The software work teaches a lot
lessons, some at the unconscious level. If something tells you that a model of
design is destined to fail (even if this cannot be demonstrated clearly
explicit), there are reasons to dedicate more time to its study or to develop another one
different

Principle 10. Obtain feedback as soon as possible. Every model

it must be reviewed by the team members. The purpose of these reviews is

15
obtain feedback to use it in order to correct modeling errors,
change the wrong interpretations and add the characteristics or functions
inadvertently omitted.

3.3.4. Requirements of modeling principles

In the last three decades, numerous modeling methods have been developed.
of requirements. Researchers have identified the problems of the analysis of
requirements and their causes, and they have developed several modeling notations and the
heuristic sets corresponding to solve those. Each method of
analysis has a unique viewpoint. However, they are all connected by
certain operational principles:

Principle 1. The information domain must be represented and understood.

problem. The information domain includes the data that flows into the system
(end users, other systems or external devices), the data that flows out
of the system (through the user interface, network interfaces, reports, graphs, and others
media) and the data storage that collects and organizes objects
persistent data (for example, those that are kept in the form
permanent).

Principle 2. The functions that the software will perform must be defined. The functions of
software gives a direct benefit to end users and also provides support
internal for the characteristics that are visible to those. Some functions
they transform the data flowing into the system. In other cases, the functions
they activate some level of control over the internal processing of the software or over the
external elements of the system. The functions are described in many and different
levels of abstraction, ranging from a general purpose statement to the
detailed description of the processing elements that must be invoked.

Principle 3. The behavior of the software must be represented (as a consequence

of external events). The behavior of computer software is

16
determined by its interaction with the external environment. The inputs provided by the
end users, the control of the data carried out by an external system or the
data monitoring gathered on a network is the reason why the software is
behaves in a specific way.

Principle 4. Models that represent information, function, and behavior

they must be divided in such a way that they reveal the details in a stratified manner (or

hierarchical). Modeling the requirements is the first step to solving a

software engineering problem. This allows for a better understanding of the problem and

provides a basis for the solution (design). Complex problems are

difficult to solve completely. For this reason, the divide and conquer strategy should be used
and you will overcome. A big and complex problem is divided into subproblems until
each of these is relatively easy to understand. This concept is called
partition or separation of entities, and it is a key strategy in modeling
requirements.

Principle 5. The analysis work must progress from essential information towards the
detailed implementation. Requirements modeling begins with the
description of the problem from the end user's perspective. It describes the
"essence" of the problem without considering the way in which the solution will be implemented.
For example, a video game requires the player to 'teach' its protagonist.
in what direction to advance when moving towards a dangerous maze. That is the
essence of the problem. The detailed implementation (usually described as
part of the design model) indicates how the essence will be developed. For the game of
video, perhaps a voice input will be used, or a command will be typed on a keyboard, or such
see a joystick (or mouse) pointing in a specific direction, or perhaps moving in it
make a motion-sensitive device.

3.3.5. Principles of the design model

The software design model is analogous to architectural blueprints of a

house. It begins by representing the entirety of what is going to be built (by
example, a three-dimensional sketch of the house) that is gradually refined so that

17
guide the construction of every detail (for example, the layout of the plumbing). From
In a similar way, the design model created for the software provides several points.
different views of the system

Principle 1. The design must be traceable to the requirements model.

requirements model describes the information domain of the problem, the
visible functions for the user, the system behavior and a set of
classes of requirements that group business objects with the methods that apply to them
and service. The design model translates this information into an architecture, a
set of subsystems that implement the main functions and a set of
components that are the realization of the requirements classes. The elements
The design model must be traceable to the requirements model.

Principle 2. Always take into account the architecture of the system that is going to be

build. The software architecture (see chapter 9) is the skeleton of

system that is going to be built. It affects interfaces, data structures, control flow
and behavior of the program, as well as the way in which they will be carried out
tests, the susceptibility of the resulting system to receive maintenance and much
more. For all these reasons, the design must begin with considerations of the
architecture. Only after this is established should aspects be considered in the
level of the components.

Principle 3. The design of the data is as important as the design of the functions.
processing. The data design is an essential element of the design of the
architecture. The way in which data objects are created within the design
It cannot be left to chance. A well-structured data design helps simplify the
program flow makes it easier to design and implement components of
software and more efficient joint processing.

Principle 4. Interfaces (both internal and external) must be designed with

caution. The way data flows between the components of a system
has a lot to do with processing efficiency, error propagation and the

18
Simplicity of design. A well-designed interface makes integration easier.
easy and helps those who put it to the test to validate the component functions.

Principle 5. The user interface design must meet the needs of the
end user. However, in any case, it must highlight the ease of use. The interface
user is the visible manifestation of the software. No matter how sophisticated
its internal functions, nor how inclusive its data structures are, nor
As well designed as its architecture may be, a poor interface design often...
leads to the perception that the software is 'bad'.

Principle 6. Design at the component level must have independence.

Functional. Functional independence is a measure of the "unique mindset" of a
software component. The functionality delivered by a component must be
cohesive, that is to say, it must focus on one and only one function or sub-function.

Principle 7. The components should be loosely coupled to each other and to the
external environment. Coupling is achieved in many ways: with an interface of
component, with messaging, through global data, etc. As we
increases the level of coupling, it also increases the probability of
error propagation and decreases the overall ease of maintenance for
software. Therefore, the coupling of components must be kept as low
as long as it is reasonable.

Principle 8. Design representations (models) must be understood with

ease. The purpose of the design is to communicate information to professionals who
they will generate the code, to those who will test the software and to others who will give it

maintenance in the future. If the design is difficult to understand, it will not serve as a means
of effective communication.

Principle 9. The design must be developed iteratively. The designer must seek
more simplicity in each iteration. Just like happens with almost all activities.
creative, the design occurs iteratively. The first iterations serve to

19
improve the design and correct errors, but the subsequent ones should seek a design as
as simple as possible.

3.4. Construction Principles

The construction activity includes a set of coding and testing tasks.

that leads to an operational software ready to be delivered to the client or end user. In the
modern software engineering work, coding can be 1) the creation
direct programming language in source code (for example, Java), 2) the
automatic generation of source code that uses an intermediate representation
similar to the design of the component that is going to be built or 3) the generation

executable code automation that uses a 'fourth generation programming language'

generation (for example, Visual C++).

3.4.1. Principles of coding

The principles that guide coding work are closely related to the
style, languages, and programming methods. However, it can be stated certain
number of fundamental principles:

3.4.1.1. Principles of preparation.

Understand the problem that is being addressed.

Understand the principles and basic concepts of design.

Choose a programming language that meets the needs of the software that
it will be developed and the environment in which it will operate.

• Select a programming environment that has tools that

make their work easier.

• Create a set of unit tests that will be applied once it has

finished the component to be coded.

20
3.4.1.2. Programming principles

Restrict their algorithms through the use of structured programming [Boh00].

Consider the use of pair programming.

Select data structures that meet the design needs.

Understand the software architecture and create interfaces that are consistent with
she.

Keep the conditional logic as simple as possible.

Create nested loops in such a way that they can be easily tested.

• Select meaningful names for the variables and follow other standards
encoding locales.

Write code that documents itself.

Create a visual image (for example, lines with indentation and blank) that helps to
understand.

3.4.1.3. Validation Principles

• Perform the code walkthrough when appropriate.

Carry out unit tests and correct the errors that are detected.

Redesign the code

3.4.1.4. Principles of the test

The test is the process that executes a program in order to find an error.

A good test case is one that has a high probability of finding an error that
It has not been detected so far.

A successful test is one that uncovers an undetected error up to that point.

21
3.4.1.5. Deployment Principles

Principle 1. Customer expectations must be managed. With too much

frequency, the customer expects more than what the team has promised to deliver, and the
disappointment arrives immediately.

Principle 2. The complete package to be delivered must be assembled and tested.

It must be assembled on a CD-ROM or other media (including downloads from the web) everything

the executable software, supporting data files, help documents, and others
relevant information, for later conducting a thorough beta test with users
real. All installation scripts and other operational features must
to run completely in as many different computing configurations as possible
possible (for example, hardware, operating systems, peripheral equipment,
network configurations, etc.

Principle 3. Before delivering the software, a support regime must be established.

A end user expects accurate answers and information when a question arises or
problem. If the support is ad hoc, or worse, does not exist, the client will be left
immediately dissatisfied. Support must be planned, the respective materials
they must be prepared and appropriate recording mechanisms must be established in order
for the software team to conduct a categorical evaluation of the classes of
support requested.

Principle 4. End users should be provided with learning materials.

appropriate. The software team delivers more than just the software itself. They must
develop appropriate training materials (if required); it is necessary
provide guidelines for problem solving and, when necessary, must
"what is different about this software increase"

22
Principle 5. Defective software must be corrected first and then delivered.
When time is tight, some software organizations deliver
low quality increases with the warning that the errors "will be corrected in
the next delivery." This is an error. There is a saying in the software business that
it says: "Customers will soon forget that you delivered a high-quality product,
but they will never forget the problems caused by a low-quality product. The
software reminds them every day.

3.5. What is quality

On a somewhat pragmatic level, David Garvin [Gar84], from Harvard Business School,
suggests that 'quality is a complex concept with multiple facets' that can
to describe oneself from five different points of view. The transcendental point of view
says (like Persig) that quality is something that is recognized immediately, but that not
it is possible to define explicitly. The user's point of view conceives quality in
terms of the specific goals of the end user. If a product meets these, it has
quality. From the manufacturer's point of view, it is defined in terms of specifications
originals of the product. If it meets them, it has quality. The point of view of
The product suggests that quality is related to inherent characteristics.
(functions and features) of a product. Finally, the perspective based on
the value is measured according to what a customer is willing to pay for a
product. In reality, quality includes all this and more.

3.5.1. Software Quality

Effective software process that is applied in a way that creates a useful product that
provides measurable value to those who produce it and to those who use it
Rog
3082 ]
3.5.2. The software quality dilemma

If you produce a low-quality software system, you lose because no one does it.
will want to buy. On the other hand, if you dedicate infinite time, too much effort and
huge sums of money to obtain a perfect software element, then

23
it will take so long to finish and will be so expensive to produce that anyway
it will be out of business. In any case, it will have lost the market window,
or they may simply have exhausted their resources. Thus, the people of the
industries try to position themselves in that magical midpoint where the product is
good enough not to be rejected immediately, not in the evaluation,
but it is not a perfectionist object nor with too much work that turns it
in something that requires too much time or money to be completed
Mey \l 3082 ]

3.5.2.1. "Sufficiently good" software

Good enough software contains high functions and features

quality that users desire, but at the same time has other darker ones and
specialized that contain known errors. The software vendor expects that
the vast majority of end users forgive the mistakes thanks to being very
happy with the functionality of the application

3.5.2.2. The cost of quality

The cost of quality includes all costs incurred in the pursuit of quality.
quality or when carrying out activities related to it and the subsequent costs of it
lack of quality. To understand these costs, an organization must have
measurement units that provide the foundation of the current cost of quality, that
identify the opportunities to reduce those costs and provide a basis
normalized for comparison. The cost of quality can be divided into the costs that
they are associated with prevention, evaluation, and failure.

3.5.2.3. Risks

The implication is that poor quality software increases risks for both
developer as for the end user. In the previous subsection, one of
such risks (the cost). But the harmfulness of poorly designed applications and
implemented is not always measured in dollars and time

3.5.3. Achieving software quality

24
The quality of software is not only seen. It is the result of good management of
project and correct practice of software engineering. The management and
practices are applied in the context of four main activities that help with
software team to achieve high quality in this: methods of engineering
software, project management techniques, quality control actions and
software quality assurance.

3.5.3.1. Software Engineering Methods

If you expect to build high-quality software, you must understand the problem you want.
resolver. It must also be able to create a design that is in accordance with the
problem and that at the same time has characteristics that lead the software to the
dimensions and quality factors

3.5.3.2. Project Management Techniques

The implications are clear: if 1) a project manager uses estimates to

verify that the dates can be met, 2) the dependencies are understood
the scheduled activities and the team resist the temptation to take shortcuts, 3) the
risk planning is carried out in such a way that problems do not encourage the
chaos, then the quality of the software will be positively influenced.
Rog 3082

3.5.3.3. Quality control

Quality control includes a set of software engineering actions that

help ensure that every product of work meets its quality goals. The
models are reviewed to ensure that they are complete and that they are
consistent [CITATION Rog 482]

3.5.3.4. Quality assurance

Quality assurance establishes the support infrastructure for the methods.

solid principles of software engineering, the rational management of projects and the
quality control actions, all of crucial importance when it comes to manufacturing

25
high-quality software. Furthermore, quality assurance consists of a
set of audit functions and reports to evaluate effectiveness and completeness
of quality control actions.

3.6. Software quality assurance elements

Standards
Review and audit
Tests
Collection and analysis of errors
Change management
Education
Security Management
Security
Risk management

3.6.1. Software Security

Software security is completely related to quality. It should be considered.

in security, reliability, availability, and dependency, in the initial phase, in the
design, in architecture, testing and coding, throughout the entire life cycle of
software [process]. Even people aware of the security issue
of the software focuses on the final stages of the life cycle. The sooner you
I detected a problem in the software, better. And there are two kinds of problems. One is
the errors, which are implementation problems. The other is software failures:
architecture problems in the design. People pay too much attention to the
errors but not enough to the failures.[ CITATION Gar 3082 ]

3.7. Project Management

Project management involves planning, monitoring, and control of

personal, processes and actions that occur as the software evolves from

26
a preliminary concept until its full operational deployment.
3082 ]

3.7.1. The Administrative Spectrum

The effective management of a software project focuses on the four Ps:

personal, product, process and project. The order is not arbitrary. The manager that
forget that the work of software engineering is an intensely
humans will never succeed in project management. A manager who fails in
encourage understanding communication with the participants during the first
stages of product evolution risks building an elegant solution
for the wrong problem.

3.7.1.1. Definition of: The Personnel

The People-CMM defines the following key practice areas for the personnel of
template
administrative, training, compensation, analysis and development of competencies,
professional development, team development, and team/culture development
among others. Organizations that achieve high levels according to this model
maturity of personnel capabilities have a very high probability of
achieve the implementation of effective administrative practices in the projects of
software.[ CITATION Mod 3082 ]

3.7.1.1.1. Participants

The software process (and any software project) is populated by participants,

who can organize themselves in any of the following areas:

1. Executive managers, who define the business topics that frequently

they have a significant influence on the project.

27
2. Project managers (technical), who must plan, motivate, organize and
to control the professionals who do the software work.

3. Professionals who provide the technical skills needed to submit

to engineer a product or application.

4. Clients who specify the requirements for the software to be developed,

just like other participants who have a peripheral interest in the outcome.

5. End users, who interact with the software once it is released for its
productive use.

3.7.1.1.2. Team Leaders

Project management is an activity that involves a lot of interaction with people;

For this reason, competent professionals often have poor
performance as team leaders. Simply put, they do not have the right mix of
personal skills. And yet, as Edgemon states: "Unfortunately, and despite
As frequent as it may seem, individuals simply stumble upon the role of manager.
of the project and become accidental project managers
3082

3.7.1.1.3. Software Equipment

There are almost as many human organizational structures for software development
as organizations that develop it. For better or for worse, the structure
Organizational structure cannot be easily modified. The concern for the
practical consequences and the policies of organizational change is not within the
scope of responsibility of the software project manager. However, the
organization of the people directly involved in a new project of
Software is within the scope of the project manager's action.

3.7.1.2. Definition of: The product

Result produced naturally or artificially, or the result of a work or operation.

[ CITATION Rev97 l 3082 ]

28
3.7.1.2.1. Scope of the software

The scope of software describes the functions and features that are delivered to the
end users; the data that is input and output; the 'content' that is presented to
the users as a consequence of using the software and the performance, the
restrictions, the interfaces and the reliability linked to the system.

3.7.1.2.2. Problem decomposition

The decomposition of the problem, sometimes referred to as division or elaboration of

problem, it is an activity that is centered on the requirements analysis
of the software. During the scoping activity, no attempts are made
for completely breaking down the problem. Instead, the decomposition is
applies in two main areas: 1) the functionality and the content (information) that
must be delivered and 2) the process that will be used to deliver it
3082

3.7.1.3. Definition of the process

A software process provides the conceptual framework from which it can

establish a complete plan for software development. A small number
conceptual framework activities apply to all software projects, without
import their size or complexity. [ CITATION Rog 3082 ]

3.7.1.3.1. Product and process fusion

Project planning begins with the fusion of product and process. Each
function that will be subjected to engineering by the team must go through the
set of activities of a conceptual framework that defines software organization.

3.7.1.3.2. Decomposition of the process

A software team must have a significant degree of flexibility when choosing the
software process model that is best for the project and tasks of the
software engineering that populates the process model once chosen. A

29
relatively small project that is similar to previous efforts can
achieve better by using the linear sequential approach.

3.7.1.4. Definition of: The project

Set of activities necessary to obtain a product.

]

3.8. Project Scheduling

It is an activity that distributes effort estimates over the duration.

project planning, by assigning effort to specific engineering tasks of the
software. It is the culmination of a planning activity that is a component
principal of software project management

3.9. Product Metrics

Product metrics help software engineers obtain

understanding of the design and construction of the software they develop, to
focus on specific measurable attributes of the work products of the
software engineering.

3.9.1. Measures, metrics and indicators

Although the terms measure, measurement, and metric are often used in a
interchangeable, it is important to observe the subtle differences between them. In the
In the context of software engineering, a measure provides a quantitative indication.
of the extension, quantity, dimension, capacity, or size of some attribute of a
product or process. Measurement is the act of determining a measure. A measure
quantitative measure of the extent to which a system, component, or process possesses an attribute

determined.

3.9.2. Measurement Principles

30
Formulation. The derivation of appropriate software measures and metrics for the
representation of the software that is being built.

Collection. A mechanism used to accumulate required data to derive the

formulated metrics.

Analysis. The calculation of metrics and the application of mathematical tools.

Interpretation. Evaluation of the resulting metrics to understand the quality of

the representation.

Feedback. Recommendations derived from the interpretation of the metrics

of the product, transmitted to the software team.

3.9.3. Metrics for the Requirements Model

The technical work in software engineering begins with the creation of the model
of requirements. In this stage, the requirements are derived and a
foundation for design. Therefore, product metrics that are desirable
provide understanding about the quality of the analysis model.
Rog 3082 ]

3.9.3.1. Function-based metrics

The function point metric (PF) can be effectively used as a means

to measure the functionality that enters a system.4 By using historical data, the
PF metric can then be used to: 1) estimate the cost or effort required
to design, code, and test the software;

3.9.3.2. Metrics for specification quality

Davis et al. [Dav93] propose a list of features that can be used to

evaluate the quality of the requirements model and the corresponding specification
of requirements: specificity (lack of ambiguity), completeness, correctness,
understandability, verifiability, internal and external consistency, feasibility
concision, traceability, modifiability, precision, and reusability. In addition, the

31
authors observe that high-quality specifications are stored
electronically, they are executable or at least interpretable, they are annotated by
relative importance, they are stable, they have a version, they are organized, they count with

cross-reference and are specified at the correct level of detail.

3.9.4. Metrics for the Design Model

The design metrics for computer software, like all the others
software metrics are not perfect. The debate continues regarding their effectiveness and
about the way they should be applied. Many experts argue that they
requires more experimentation before being able to use the design measures, although the
design without measurement is an unacceptable alternative. In the following sections, it
they examine some of the most common design metrics for software
computer. Each one can provide you with improved understanding and all
they can help the design evolve towards a higher level of quality.
[ CITATION Rog 3082 ]

3.9.5. Metrics for object-oriented design

There is a lot of subjectivity in object-oriented design: a designer

an experienced person "knows" how to characterize an OO system in such a way that it implements

effectively the customer's requirements. But, according to a design model

OO grows in size and complexity, a more objective view of the characteristics of the
design can benefit both the experienced designer (who acquires
additional understanding) as to the novice (who gets a hint of the quality that from
another way would not be available). [CITATION Rog 3082 ]

Size. Size is defined based on four views: population, volume,

length and functionality.

Complexity. Like size, there are many different views on complexity

of the software [Zus97]. Whitmire sees complexity in terms of features
structural when examining how the classes of a design relate to each other
OO

32
Coupling. The physical connections between elements of OO design (for example, the
number of collaborations between classes or the number of messages that pass between them

objects represent the coupling within an OO system.

Sufficiency. Whitmire defines sufficiency as "the degree to which an abstraction

it has the required characteristics of it or in which a design component
it has characteristics in its abstraction, from the point of view of the application
actual

Completeness. The only difference between completeness and sufficiency is 'the set of
characteristics against which abstraction or the component of
design" [Whi97]. Sufficiency compares abstraction from the point of view of the
current application.

Cohesion. Like its counterpart in conventional software, an OO component must

designed in such a way that all operations work together to
achieve a single well-defined purpose.

Primitivism. A characteristic that is similar to simplicity, primitivism

(applied both to operations and classes), is the degree to which an operation is
atomic, that is to say, the operation cannot be constructed from a sequence of
other operations contained within a class.

Similarity. The degree to which two or more classes are similar in terms of their
structure, function, behavior or purpose is indicated by this measure.

Volatility. As mentioned many times in this book, changes in design

they can occur when the requirements are modified or when they occur
modifications in other parts of an application, resulting in the
mandatory adaptation of the design component in question. The volatility of a
OO design component measures the probability that a change will occur.

3.9.6. Metrics for Testing

33
Test metrics fall into two broad categories: 1) metrics that
they try to predict the likely number of tests required at various levels of
test and 2) metrics that focus on test coverage for a component
determined

3.9.6.1. Metrics for Object-Oriented Testing

The OO design metrics noted in section 23.3 provide a hint of

the quality of the design. They also provide a general indication of the amount of effort
required test to exercise an OO system. Binder [Bin94b] suggests a broad
set of design metrics that have a direct influence on the
The 'probability' of an OO system. The metrics consider aspects of
encapsulation and inheritance

Lack of cohesion in methods (FCOM). The higher the value of the

FCOM, more states must be tested to ensure that the methods do not
They generate side effects.

Public and protected percentage (PPP). Public attributes are inherited from others.
classes and, therefore, are visible to those classes. Protected attributes are
accessible to methods in subclasses. This metric indicates the percentage of the
class attributes that are public or protected. High PPP values increase the
probability of side effects between classes because of public attributes and
protected lead to high potential for coupling. Tests must
designed to ensure the discovery of such side effects

Public access to data members (PAD). This metric indicates the number of classes
(or methods) that can access other class attributes, a violation of the
encapsulation. High values of APD lead to the potential for side effects
between classes. The tests must be designed to ensure discovery of
such side effects

34
Number of root classes (NCR). This metric is a count of the different hierarchies.
of class that are described in the design model. The suites of must be developed
Test for each root class and the corresponding class hierarchy. As per the
NCR increases, so does the testing effort.

Fan-in (FIN). When used in the OO context, the fan-in (input fan) in the
inheritance hierarchy is an indication of multiple inheritance. END > 1 indicates that a class
inherits its attributes and operations from more than one root class. FIN > 1 should be avoided.

when possible.

3.9.6.2. Metrics for Maintenance

IEEE Std. 982.1-1988 [IEE93] suggests a software maturity index (SMI) that
provide an indication of the stability of a software product (based on
changes that occur for each product release.

3.9.7. Definition of: Metrics for Software Quality

The metrics for software quality are intended to obtain a measure

quantifiable to demonstrate the quality of a software product.

3.9.7.1. Measurement of quality

Although there are many measures of software quality, accuracy, capacity of

Maintenance, integrity, and usability provide useful indicators for the team.
of the project. Gilb [Gil88] suggests definitions and measures for each.

Accuracy. A program must operate correctly or it will provide little value to its
Users. Accuracy is the degree to which the software performs the required function.
The most common measure of accuracy is defects per KLOC, where a defect
it is defined as a verified deficiency according to the requirements.

Maintenance capacity. The maintenance and support of the software represent

more effort than any other software engineering activity. The ability
maintenance is the ease with which a program can be corrected if it

35
find an error, the ease with which it adapts if its environment changes or improves
if the client wants a change in requirements.

Integrity. The integrity of software has become increasingly important in the era
of cyber terrorists and hackers. This attribute measures the ability of a system to
withstand attacks (both accidental and intentional) on their security. The attacks
can be made in the three software components: programs, data and
documentation.

Usability. If a program is not easy to use, it is often doomed to

failure, even if the functions it performs are valuable. Usability is an attempt
to quantify ease of use and can be measured in terms of the characteristics

3.9.7.2. Efficiency in defect removal

A quality metric that provides benefits both at the project level as well
in the process is the defect removal efficiency (ERD). Essentially, the ERD
it is a measure of the filtering ability of assurance and control actions
of quality as they apply throughout all activities of the framework
conceptual of the process.

3.9.7.3. Establishment of a software metrics program

The Software Engineering Institute (SEI) developed a very comprehensive manual [Par96b]
to establish a software metric program 'goal-oriented'. The
the manual suggests the following steps:

1. Identify business goals.

2. Identify what you want to know or learn.

3. Identify the subgoals.

4. Identify the entities and attributes related to the subgoals.

5. Formalize the measurement goals.

36
6. Identify quantifiable questions and the related indicators that will be used.
to help achieve measurement goals.

7. Identify the data elements that will be collected to build the indicators
that help answer the questions.

8. Define the measures to be used and make these definitions operational.

9. Identify the actions that will be taken to implement the measures.

10. Prepare a plan for the implementation of the measures.

3.9.8. Risk Management

Risk analysis and management are actions that assist the team in
software to understand and manage uncertainty. Many problems can destroy
a software project. A risk is a potential problem: it can occur, it can
it won't happen. But, regardless of the outcome, it's really a good idea to identify it,
assess its probability of occurrence, estimate its impact, and establish a plan for
contingency in case the problem actually occurs.

3.9.8.1. Risk Identification

Risk identification is a systematic attempt to specify threats to

project plan (estimates, schedule, resource load, etc.). When identifying the
known and predictable risks, the project manager takes a first step to
avoid them when possible and control them when necessary.

3.9.8.2. Risk Projection

Risk projection, also known as risk estimation, tries to qualify

each risk in two ways: 1) the possibility or probability that the risk is real and
2) the consequences of the problems associated with the risk, in case of
happen. You work together with other managers and technical staff to carry out four
risk projection steps:

Establish a scale that reflects the perceived likelihood of a risk.

37
2. Outline the consequences of the risk.

3. Estimate the impact of risk on the project and the product.

4. Evaluate the overall accuracy of the risk projection so that there will be no
misunderstandings.

3.9.8.3. Risk Impact Assessment

Three factors affect the likely consequences if a risk occurs: its nature,
its scope and its timing. The nature of the risk indicates the problems
probable if it occurs. For example, a poorly defined external interface in the
client hardware (a technical risk) will hinder early design and testing, and
it will likely lead to system integration issues later on
project. The scope of a risk combines the severity (how serious is it?) with its
global distribution (how much of the project will be affected or how many participants will be)

will they damage?). Finally, the timing of a risk considers when and for how long
time will feel the impact. In most cases, it is desired that the 'bad
news occur as soon as possible, but in some, the more
improve it, better.

3.9.8.4. The MMMR plan

A management strategy can be included in the software project plan.

of risk, or the risk management steps can be organized into a plan
of mitigation, monitoring, and risk management (MMMR) separately. The MMMR plan
document all the work done as part of the risk analysis and the manager
of the project is used as part of the overall project plan

4. THEORETICAL FRAMEWORK OF THE METHODOLOGY

4.1. PUDS

The Unified Software Development Process or simply Unified Process is a

software development framework characterized by being driven by use cases
use, focused on architecture and being iterative and incremental. The most refinement

38
known and documented of the Unified Process is the Rational Unified Process
or simply RUP.

4.1.1. Characteristics

4.1.1.1. Iterative and Incremental

The Unified Process is an iterative and incremental development framework consisting of

four phases called Initiation, Elaboration, Construction, and Transition. Each one
of these phases is in turn divided into a series of iterations (the initial one can
include several iterations in large projects). These iterations offer as
resulted in an increase of the developed product that adds or improves the
functionalities of the system under development.

Each of these iterations is further divided into a series of disciplines that

remember those defined in the classic or waterfall life cycle: Analysis of
requirements, Design, Implementation, and Testing. Although all iterations usually
include work in almost all disciplines, the degree of effort within each one
it varies throughout the project.

Diagram illustrating how the relative emphasis on different disciplines changes to

length of the project.

4.1.1.2. Driven by use cases

In the Unified Process, use cases are used to capture requirements.

functional and to define the contents of the iterations. The idea is that each
iteration take a set of use cases or scenarios and develop the whole path
through the various disciplines: design, implementation, testing, etc. The process
use case driven is the rup. Note: in UP it is requirement driven
risks according to the UML 2 Book by ARLOW, Jim which mentions the topic.

4.1.1.3. Centered on architecture

The Unified Process assumes that there is no single model that covers all
aspects of the system. For this reason, there are multiple models and views that

39
define the software architecture of a system. The analogy with construction is
Clara, when you build a building there are various plans that include the different...
services of the same: electricity, plumbing, etc.

4.1.1.4. Focused on the risks

The Unified Process requires the project team to focus on identifying the
critical risks at an early stage of the life cycle. The results of each
iteration, especially those from the Elaboration phase must be selected in a
order that ensures that the main risks are considered first.

4.2. UML

The Unified Modeling Language (UML) is a visual modeling language that

it is used to specify, visualize, build, and document artifacts of a
software system.

4.2.1. Definition of Unified

A set of concepts can be used in the same model.

Combine the concepts commonly accepted by many oriented methods.

to objects. It can represent most existing models. It is designed
to model most application domains, including those
large, complex, real-time systems. It can be used in systems
developed in different programming languages, databases,
organization documents, firmware, and others. It is unified because it
I standardize several models into one

4.2.2. Types of Domain

Most application domains, including those that involve

large, complex, real-time, distributed systems, with processing
data-intensive or compute-intensive, among other properties

4.2.3. UML Objectives

40
They can use all the modelers.

Incorporate good design practices such as encapsulation, separation of concerns,

and the capturing of the intention of the constructed model

He intends to work properly with everyone, or at least with the majority of them.
existing development process.

4.2.4. Model
It is a representation, in a certain medium, of something in the same or another medium. The

model captures the important aspects of what we are modeling, from

certain point of view, and simplification omits the rest.

They can capture requirements about their application domain, the way in which the
users will use it, its division into modules, the common patterns used in its
construction and other things.

A model of a software system helps developers explore

various architectures and solutions for a design easily before writing the
code.

Semantics and presentation: the semantic elements of the model carry the
meaning of the model, that is, they transport the semantics. They are used for the
generalization of the code, the validity check, the metrics of
complexity. The visual presentation shows the semantic information in a way
that can be considered, reviewed, and corrected by human beings.

Context: The models are artifacts in a computer system, and they are used
within a larger context that gives them complete meaning. This context
includes the internal organization of the model, annotations on the use of each
model in the total development process, a system of default values and of
assumptions for the creation and manipulation of the element, and a relationship to
environment in which they are used.

41
5. SOFTWARE ENGINEERING OF THE PROJECT

5.1. Time planning.

42
5.2. Organization of personnel (Structure of the software development team)

43
For this project, it was determined to use the Centralized Team structure.
Controlled (CC) for the following reasons:

There is a single team leader.

This manager resolves high-level problems and coordinates the team.
Vertical communication between the boss and the team members.
It was the first organizational chart that was implemented.

Less time in problem solving due to fewer lines of

communication.
Medium or small projects

5.3. Project Estimation (Assuming Productivity = 29.5)

5.3.1. Function Point-based Metrics

USER ENTRIES
# Detail
1 Product registration interface
2 Sales registration interface
3 Customer registration interface
4 Order Registration Interface
5 Receiving registration interface
6 Employee registration interface
7 Supplier registration interface

USER OUTPUTS
# Detail
1 Product display interface
2 Sales visualization interface
3 Customer viewing interface
4 Order visualization interface
5 Reception viewing interface
6 Employee display interface
7 Supplier visualization interface

USER REQUESTS
# Detail
1 Salesperson Report

44
2 Product report
3 Product report with brands (For
marketing

FILES
# Detail
1 Billing text file for
taxes

EXTERNAL INTERFACES
# Detail
1 Printing of adhesive labels with code of
bars

Weighting factor
Parameter Count Subtotal
Simple Medium Complex

Number of tickets
7 2 2 3 21
of user

Number of exits
7 0 1 8 56
of user

Number of
requests of 3 0 3 09
user

Number of files 1 0 0 11

Number of
1 0 0 11
external interfaces

Count Total 88

∑ Ct

45
No influence

5.3.2. Complexity adjustment values

Does the system require reliable backup and recovery? 4

2. Does it require data communication? 4

Are there distributed processing functions? 0

Is performance critical? 5

5. Will the system run in an existing operating environment and

strongly used? 5

6. Does it require interactive data entry? 3

7. Does interactive data entry require transactions of

Should entries take place across multiple screens or operations? 3

8. Are the master files updated interactively? 3

9. Are the inputs, outputs, files, or requests complex? 4

10. Is the internal processing complex? 3

11. Has the code been designed to be reusable? 5

12. Are conversion and installation included in the design? 0

13. Has the system been designed to support multiple installations in

different organizations? 4

14 Has the application been designed to facilitate changes and to be 3

easily used by the user?

∑ Fi 46

5.3.3. Function Point Calculation

E=20

46
PF=∑Ct*(0.65+0.01*∑Fi)

PF = 88 * (0.65 + 0.01 * 46)

PF = 97.68

5.3.4. Calculation of Effort

Productividad = 29,5

P = PF/E

E = PF / P

E=97.68/29.5

E=3.31

5.3.5. Calculation of the number of people who will make up the development team
software.

Duration = Effort / People

Duration = 3.31 / 2

Duration = 1.6 Months

2 people are required to develop the system in 1.6 months.

Personnel Cost

Developer Hour: 35bs

Cost = Person x Hour$ x Hours x Days x month

3 x 35 x 8 x 25 x 1.6

33600bs for 2 developers in 1.6 months

5.3.7. Cost of Software

Cost = $hours * Function Points

47
Costo = 35 * 97.68

3418bs

5.4. Risk Analysis and Management

5.4.1. Scale based on staff appearance

Impact Possible
Risk Probability COST
o Solution
Damage to the To ensure
area of the teams
85 30 300
development of electronic
project s
Withdrawal from a Hire
member of the 25 20 personal 500
team new
Damages
Assure
climatic
the teams
in the area of 80 20 200
electronic
development of
project

5.4.2. Scale based on the technological aspect

Impact Possible
Risk Probability COST
o Solution
Increase hours
Technology for work
300
new no 30 50 to train on
tested the new
technology
Personal no Empower
40 30 500
trained personal

5.4.3. Scale based on the business aspect

Impact Possible
Risk Probability COST
o Solution
The resources 50 30 Inform the ------
they are not in charge of
available in project that the

48
 closing time
its moment it's going to be seen

affected
New
Increase the
characteristics 55 50 ------
working hours
requested
The teams
clients no
Request
they have
25 30 update of 200
the requirements
teams
that the system
needs
Request improvement
Larger number
of resources of
of users of 25 30 --------
server of
the planned
production

5.5. Quality Management

5.5.1. Quality based on 5 metrics (Correction, Reliability, Efficiency,

Integrity, Ease of Maintenance

5.5.2. Standards

1.1.1.1. ISO Standard 25000

This provides a guide for the use of the new series of standards.
international, called Requirements and Quality Assessment of Products of
Software (SQuaRE). It is a standard based on ISO 9126 and 14598 and its
the main objective is to establish a guide for the development of the products of
software with the specification and evaluation of quality requirements. It establishes
criteria for specifying quality requirements for software products, their
metrics and their evaluation. The software product must incorporate some
characteristics, in such a way that their efficiency of use is guaranteed for the
customer requirements. It is recommended that quality requirements should
be proportional to the needs of the application and how critical it is to be correct.
functioning of the implemented system.

The standard consists of the following divisions:

49
 SO/IEC 2500n. Quality management division. This division defines all the
common models, terms, and references mentioned in the other divisions
of SQuaRE

ISO/IEC 2501n. Division of the quality model. It presents a quality model.

detailed, including characteristics for internal, external, and operational quality.

ISO/IEC 2502n. Division of quality measurements. Presents a model of

quality reference of software product, mathematical definitions of metrics
of quality and a practical guide for its application. It presents applications of metrics
for the quality of internal, external, and in-use software.

ISO/IEC 2503n. Quality requirements division. Helps to specify the requirements

of quality. These requirements can be used in the specification process
quality requirements for a software product that is going to be developed or how
entry for an evaluation process. The requirement definition process is
guide by the established in the standard ISO/IEC 15288 (ISO, 2003).

ISO/IEC 2504n. Quality evaluation division. Provides requirements,

recommendations and guidelines for the evaluation of a software product, whether it is
Evaluators, such as clients or developers, carry out.

ISO/IEC 25050–25099. SQuaRE extension standards. They include requirements for

the quality of 'Off-The-Shelf' software products and for the common format of the
industry (CIF) for usability reports.

This standard defines three different views regarding the study of quality of a
software product:

Internal view: it deals with the properties of the software such as: size,
complexity or compliance with object-oriented guidelines. This view
it can be used from the early stages of development to detect deficiency of
software.

50
External view: analyze the behavior of the software in production and study its
attributes, for example: the performance of software on a certain machine, the
memory usage of a program or the time of operation between failures. This
the software is used once it is complete and ready for production.

Current view: measures the productivity and effectiveness of the end user when using the
software. This view is used once the software is ready and will be evaluated by the
client and will depend on its determining factors.

5.6. Budget

5.6.1. Partial cost of software development tasks.

25200bs for 3 developers in 2.8 months.

5.6.2. Partial cost of project management.

NAME COST
PLANNING 400
QUALITY 350
RISK 2000
TOTAL 0

5.6.3. Partial cost of resources

PRICE TOTAL
DETAIL QUANTITY UNIT
(Bs.) (Bs.)
Desktop Computer
2 Team 3500 7000
Intel Core i3
Project Engineering 15 Days 150 150
TOTAL 7150

5.6.4. Partial cost of basic services.

DETAIL UNIT TOTAL

51
 Electricity bill
375 MES 750
dear
Water bill
225 MES 450
estimated
Internet bill
per month (Plan
278 MES 576
ADSL HIGH
SPEED
TOTAL 1776

5.6.5. Partial cost of extra material

DETAIL QUANTITY
Stationery and photocopy 1000 Leaves 150 150
PIXMA 1700 Printer 2 Team 500 1000
TOTAL 0

5.6.6. TOTAL PROJECT COST

DETAIL COST
Partial cost of development tasks
33600
the software
Partial cost of resources 7150
Partial cost of project management 2750
Partial cost of basic services 1777
Partial cost of extra material 1150
TOTAL 0

5.7. Communication Plan

The success of an organization depends to a large extent on a style of

Effective communication between the interested party and project members.

Meetings will be held at the company's facilities. Progress will be presented.

of the project in PDF format so that the client sees the seriousness of the team.
work.

52
The means by which we will communicate with the client will be via email.
landline or mobile phone, to schedule a meeting and keep you informed about
the progress of the project.

6. PROJECT ENGINEERING

6.1. Requirements Model

6.1.1. Functional requirements

Name of the How to Test It

#
requirement Quality attributes
User login.
Show the company logo and a
small description
A menu must have the following
options:
Beginning
Products
RF001 Home page theClients
oBrands
purchases
Sales
Orders
Recepções
Log Out

Allow to register, modify and give

lower a product and carry out
RF002 Manage Products searches.
The code is autogenerated.

Allow to register, modify and give

RF003 Manage Clients download a Client and perform searches.
The code is autogenerated.
Allow to record, modify and give
RF004 Manage Brands download a brand and perform searches.
The code is autogenerated.
Allow to register, modify, and give
low to a purchase and the search for
RF005 Manage Purchases same.
The code is auto-generated by the system.
The description of the purchase is unique.

53
 Allow to register and deregister a
sale and the search for it.
RF006 Manage Sales
The code is autogenerated by the system.
The description of the sale is unique.
Allow to register and unregister a
order and the search for it.
RF007 Manage Orders
The code is auto-generated by the system.
The order description is unique.
Allow to register and unregister a
reception and the search for it.
Manage
RF008 The code is auto-generated by the system.
Receptions
The description of the reception is
unique.
Allow user login to
web system, through the login
(username) and password.
The user password: length
Authentication of the minimum 8 characters, maximum 12, therefore
RF008
user in the system less one special character and one letter
lowercase and uppercase, as well as a
number).
Permissions will depend on the role that
have.
Allows the user to see a list of
Report: Stock of
RF009 products from a date range of
Products.
registration
Report: Purchase and Allows the user to know the profit at
RF010
Sale detail within a range of dates

6.1.2. Non-functional requirements

Minimum hardware requirements are also needed, such as:

Intel(R) Core(TM) i3 CPU @ 1.60GHz.

4 Gb RAM memory for better performance.
Minimum 100mb of hard disk for the software, more space is recommended.
as the data in the database grows.
Printer for printing reports from the program.
Local Network Connection (Preferably wireless)

54
 Software Requirements

For the development of this system, various tools are required such as
to be

Brackets Text Editor

XAMP Server
The application must be developed in PHP, using the LARAVEL framework.
for the backend, and SQL derivatives with T/SQL for the database engine
MySQL data.

Software Requirements
During the registration of any type of data, the user will be asked for the
confirmation of the action.
The system will display messages confirming an action or notifying of an error.
All form fields must be validated before proceeding.
an action (Example: Save, Modify and delete) in the database.
Automatic backup of the database every night at
12:00 PM schedules.
Modification and updating of data through forms.
An error will be notified through a message and a sound.
A user manual to train the staff.
The application must have access levels for different roles.
Password expiration
Log of the operations performed on the database tables.

6.1.3. Description of the actors

CODE AUTHOR DESCRIPTION

ADM Administrator Natural person with

55
57
 6.2.2. Specification of the use case 'Register sale'.

RF006 Manage Sales

Actors Seller
Description Describe the functionality of recording sales in the system
Precondition The logged-in user has the role of seller.
Postcondition
The sale is shown in a list of completed sales.
n
Sequence
Step
Action
o
The seller enters the sales section in the option of
1
menu.
The system displays all the registered sales in the
2
system
3 The seller clicks on the new sale button
The system displays the necessary fields to carry out a
4
sale
The seller fills in the fields and clicks add
5
products.
The system displays a window with a list and with a
6 product search tool for the user to select the
Normal
products you wish to sell.
The user searches for and selects the products they want.
sell by double clicking on the product row and when
7
he selects the products he is going to sell, he presses the
button to add products for sale.
The system closes the window for selecting products and
8 show the selected products in a list, below
the fields of the sale.
The user fills in the quantity column in the product list.
9
and click on the button to finalize the sale
The system validates fields, records the sale, deducts products
10 from the inventory, show success message, and log in
log of the changes made.
Alternative Pass
Action
o
If there are no recorded sales in the system, a is displayed
2.1 message 'No records found' instead of the list of
sales
7.1 If the user selects a product twice, it shows a
message notifying that the product has already been selected

58
 If the user does not fill in the entire quantity column in the list of
9.1 selected products, an error message is displayed "se
they must fill in the quantity column
If a required field is missing, an error message is displayed.
10.1 All required fields must be completed to
continue

6.2.3. Domain model

6.2.3.1. Conceptual class diagram

59
6.2.3.2. Relational data model

60
6.3. Design Model

6.3.1. Sequence diagram

61
 sd Sequence diagram

Seller Sales Interface Sales Control Sales Table

Enter interface()

callmethodtoobtaindata()

sendrequest()

send data()

show data()

register sale()

registerSale()

Send information()

Information saved()

Show saved sale()

Check Sale()

Deactivate sale()

Change State()

Send Information()

Return saved information()

Show sale cancelled()

Check Sale()

6.4. Implementation Model

6.4.1. Component Model

62
Component Diagram

WebApplication

Web App
Products Web App
Web App Web App Web App Web App
Brands Receptions Clients
Sales Orders

Service

Services

Server
Web

Software

COMMERCIAL MANAGEMENT SYSTEM FOR VUITON SRL

Database

BDPerson BD Orders

BD
Clients
BD
BD Employees
BDProducts BD Sale
OrderDetails

BD
BD BD BD Suppliers
SalesDetail Reception ReceptionDetail

Operating System

System
Operation

Linux

External Connections

Manager Server Connections

From BD VUITON external

6.4.2. Deployment Model

63
cmp Deployment Diagram

Web Application (Structure)

Model Interface
ORM Object LAN - WAN Web explorer
(IE10, Firefox,
Controller Chrome
Data Business

Virtual directory of
the Application
Base motor of
Reporting Agent
data
SQL

Operating System Base Server

Apache server
Linux MySQL data

7. CONCLUSIONS

The system requirements were determined with the aim of

lay the groundwork for the development of a design according to the
identified needs and difficulties.
The management system was built that solved the problems.
analyzed and that met the requirements obtained in the phase of
analysis and design.
The implementation of the developed system was carried out successfully.
taking into account that the resulting software meets all the
requirements proposed and approved by the managers of the company VUITON
SRL.

8. RECOMMENDATIONS

Design, model, and describe each future update that will be made to
system.
Apply information security to achieve a higher degree of
availability, integrity, and confidentiality of data.

64
 Conduct a study of the system vulnerabilities (pentesting) and apply
a plan to mitigate or remove such vulnerabilities.

9. BIBLIOGRAPHY

IEEE Standard Glossary of Software Engineering Terminology.

Masias, J. (s.f.). slideshare Obtained of slideshare

Unable to access the content of the provided link.
software-10507081

McGraw, G. (n.d.). ComputerWorld. Retrieved from ComputerWorld.

Meyer, B. (n.d.).

Capability maturity model of personnel. (n.d.).

Pressman, R. (n.d.). Software Engineering. A Practical Approach.

Project Management Institute. (n.d.). Project Management Institute.

The QFD handbook

Wesley, I. S. (n.d.). Software engineering (sixth edition).

65