PROJECT

DE
SOFTWARE

REFERENCE

Pressman, Software Engineering

 SUMMARY

Software and Software Engineering

MODULE 1 - THE SOFTWARE PROCESS

2) Process - A Generic Overview

3) Prescriptive Process Models
Agile Development

MODULE 2 - SOFTWARE ENGINEERING PRACTICE

5) Practice - A Generic Overview

6) Systems Engineering
Requirements Engineering
8) Analysis Modeling
Project Engineering
Architectural Project
11) Project at the Component Level
12) User Interface Project
13) Software Testing Strategies
14) Software Testing Techniques
15) Software Project Metrics

MODULE 3 - APPLICATION OF WEB ENGINEERING

Web Engineering
17) Formulation and Planning for Web Engineering
18) Analysis Modeling for Web Applications
19) Project Modeling for Web Applications
20) Web Application Testing

MODULE 4 - SOFTWARE PROJECT MANAGEMENT

21) Concepts of Project Management

22) Process and Project Metrics
23) Software Project Estimation
Project Scheduling of Software
Risk Management
Quality Management
27) Change Management

MODULE 5 - ADVANCED TOPICS IN SOFTWARE ENGINEERING

28) Formal Methods

Clean Room Software Engineering
30) Component-Based Software Engineering
31) Reengineering
The Road Ahead

Software and Software Engineering

In the 1950s, no one anticipated the importance of software; it evolved from

specialized tool for product;
Software has a dual role: product and vehicle for delivering the product;
Software is the key element in the evolution of systems and products based
a computer is one of the most important technologies in the world;
Software production presents a series of problems, such as obtaining
quality and adhering to deadlines and budget
The computers have made a series of things easier, but most
the things they make easier don't need to be done;
Software categories:
System Software = collection of programs written to serve others
programs;
2. Application Software = Isolated programs that solve a
specific business need;
3. Scientific and Engineering Software;
Embedded Software;
5. Software for Product Lines (e.g.: inventory control);
6. Web Applications;
7. Software for AI = Makes use of non-numerical algorithms to solve
complex problems that are not computable or analyzable
direct (e.g.: expert systems, neural networks, pattern recognition,
games,...);
 8. Ubiquitous Computing (distributed computing);
9. Netsourcing (distributed systems for using the WEB);
Open Software
Legacy software;
References:
• [Link]
• [Link]
• [Link]
• Unable to access external content.

MODULE 1 - THE SOFTWARE PROCESS

2) Process - A Generic Overview

• Software, like all capital, is incorporated knowledge, being

initially dispersed, tacit, latent, and incomplete;
Osoftware developmentit is an iterative learning process and
the result is the incorporation of collected, distilled knowledge and
organized, as the process is conducted;
• Software Development Processit is a framework for tasks
necessary for building quality software;
Software Process is not Software Engineering;
• Software Engineeringit is the creation and use of solid principles of
engineering in order to obtain economical software that is reliable and that
work efficiently on real machines;
Software Engineering is a technology in:
Focus on Quality
2. Process
3. Methods
4. Tools
The Process Framework establishes the foundation for a software process.
complete. It identifies a small number of framework activities,
applicable to all software projects, regardless of their
size or complexity;
Generic Process Framework:
1. Communication (client and other stakeholders)
2. Planning
3. Modeling
4. Construction
5. Implementation
The generic framework of Software Engineering is complemented by
several umbrella activities, such as:
1. Software Project Monitoring and Control;
2. Risk Management;
3. Software Quality Assurance;
4. Formal Technical Reviews;
5. Measurement;
6. Software Configuration Management;
7. Reusability Management;
8. Preparation and Production of the Work Product;
Each software engineering action is represented by a set of
tasks, each with:
1. Software Engineering Work Tasks;
2. Related Work Products;
3. Quality Assurance Points;
4. Project Frameworks
CMMI: Process metamodel based on a set of capabilities
in Software Engineering, which must be present as the
companies reach different levels of capacity and maturity of
process. To achieve these capabilities, the SEI establishes that the
organizations must develop process models that follow the
CMMI guidelines;
• PROCESS STANDARD: template, a consistent method to describe
an important characteristic of the software process. By the combination of
a project team can build a process that is better
satisfy the needs of a project. Below is described a model
to define a process standard:
1. Pattern Name;
2. Intention;
3. Type: Task, Stage, and Phase;
4. Initial Context;
5. Problem;
6. Solution;
7. Resulting Context;
8. Related Patterns;
9. Known Uses/examples
 • Process Evaluation, some proposals:
1. SCAMPI;
2. CBA IPI;
ISO 9001:2000 for Software
References:
• [Link]
• Cannot translate URLs.
• [Link]
• The provided text is a URL and does not contain translatable text.

3) Prescriptive Process Models

The prescriptive process models were originally proposed to

bring order to the chaos of software development;
A prescriptive model defines a distinct set of activities, actions
tasks, milestones, and work products that are necessary to do
Software Engineering with high quality;
• Life Cycle Model
• Waterfall Development Model
Incremental Process Models:
Incremental Model
[Link] Model
Emphasizes a short development cycle;
It is a 'high-speed' adaptation of the waterfall model;
Rapid development is achieved with an approach of
component-based construction
 Evolutionary Software Process Models
Prototyping
The client usually identifies general requirements, not identifying
detailed input, processing or output requirements;
It is difficult to precisely define the human/machine interaction;
It can be an independent process model or embedded in another.
model;
A prototype is an excellent means of gathering requirements.
software

2) Spiral Model
Combines the iterative nature of prototyping with consolidated aspects
systematic of the waterfall model;
3) Concurrent Development Model
It applies to all types of software development and provides
a clear picture of the current state of the project;

Specialized Process Models

1) Component-Based Development
Commercial off-the-shelf software (COTS);
It incorporates many of the features of the spiral model;
2) Model of Formal Methods
Set of activities that lead to formal mathematical specification
of the program;
 3) Aspect-Oriented Software Development
Unified Process

4) Agile Development

Combines philosophy and development guidelines;

The fulfillment of product delivery is valued, not the activities of
A&P;
The modern environment that uses computational systems is fast-paced and
always changeable;
• Manifesto for Agile Software Development
Agile Process Models:
1. Extreme Programming (XP)
2. THE
[Link]
[Link]
5. Crystal
6. FDD (Feature-Driven Development)
7. Agile Modeling
Philosophy for Agile Development:
 Importance of self-organized teams, with control over the work they
execute;
2. Communication and collaboration among team members and between professionals
and your clients;
3. Recognition that changes represent an opportunity;
4. Emphasis on the rapid delivery of software that satisfies the customer;

MODULE 2 - SOFTWARE ENGINEERING PRACTICE

5) Practice - A generic view

The practice of Software Engineering involves concepts, principles, and tools.

that software designers apply throughout the software process.

5.1) Practice of Software Engineering

The practice is a broad set of concepts, principles, and tools that

can be used as the software is being planned and
developed;
The practice of ES is carried out by software engineers and managers;
The software development process provides a roadmap and practice
the details to achieve the goals;
Essence of Practice:
1. Understand the problem (communication and analysis)
Who is interested in the solution;
What are the unknowns;
The problem can be compartmentalized;
The problem can be represented graphically;
2. Plan a solution (modeling and software design):
There are analogous problems;
A similar problem has been solved;
Subproblems can be defined;
An effective solution to the problem can be represented;
3. Execute the plan (code generation)
The solution is in accordance with the plan;
Each component of the solution is correct;
4. Examine the result regarding accuracy (testing and quality assurance)
It is possible to test each component of the solution;
 The solution produces results according to the data, functions,
characteristics and behaviors that are necessary;
• Central principles of Software Development:
1. Because everything exists;

[Link];
[Link] the vision;
[Link] you produce others will consume;
[Link] open to the future;
[Link] ahead for reuse;
[Link], reason clearly and completely before action, produce
best results;
5.2) Communication Practices
Listen;
Prepare yourself before communicating;
Someone should facilitate the activity;
Face-to-face communication is better;
• Take notes and document decisions;
Seek collaboration;
Stay focused, modularize your discussion;
If something is not clear, draw a figure;
Proceed regardless of disagreement and if any clarification.
was not provided;
Negotiation is not a contest or game; it works better when both
parts win;
5.3) Planning Practices:
Understand the scope of the project;
Involve the client in the planning activity;
Recognize that planning is iterative;
Estimate based on what is known;
Consider risks as a plan is defined;
Be realistic (people don't work 100% every day);
Adjust the granularity as the plan is defined;
Define how to ensure quality;
• Describe how to control and implement changes;
• Follow the plan frequently and make adjustments when necessary;

W5HH
 Because the system is being developed (Why);
What will be done
When will it be completed?
Who will be responsible for a function;
Where are they located in the organization;
• How the work will be conducted technically and managerially (How);
How much is needed of each resource

5.4) Modeling Practices

5.4.1) Principles of Analysis Modeling
• The domain of the Information of a problem needs to be represented and
understood;
The functions to be developed in the software must be defined;
• The behavior of the software, as a consequence of external events,
needs to be represented;
• The models that show information, function, and behavior must be
partitioned in such a way as to reveal details in layers;
The analysis task should go from essential information to the details of
implementation
5.4.2) Principles of Project Modeling
The project should be related to the analysis model;
Always consider the architecture of the system to be built;
The design of data is as important as the design of functions.
processing;
• Both internal and external interfaces need to be designed with
care;
The user interface design must be in tune with the
end-user needs, emphasizing ease of use;
The component-level project must be functionally independent;
The components must be loosely coupled with each other and to the
external environment;
Project representations must be easily understandable;
The project must be developed iteratively, always striving for greater
simplicity
Generic set of tasks for the project:
1. Using the Analysis to choose a pattern (style) for the project;
2. Partition the analysis model into subsystems;
3. Design the user interface;
 4. Conduct the project at the component level;
5. Develop an implementation model
5.5) Construction Practices
5.5.1) Principles and concepts of coding
Principles of Preparation (before writing a line of code):
Understand the problem;
2. Understand the principles and basic concepts of the project;
3. Choose a programming language that meets the
needs of the software and the environment in which it will operate;
4. Select a programming environment that provides tools
to make work easier;
5. Create a set of unit tests that can be applied, so
logo the components that are being coded are ready;
Principles of Coding (when to start coding):
Restrict your algorithms, following programming practice
structured;
2. Select data structures that meet the needs of
project;
3. Understand the software architecture and create interfaces that are
consistent with it;
4. Keep the conditional logic as simple as possible;
5. Create nested loops so that they are easily testable;
6. Select meaningful variable names and follow other standards
coding locations;
7. Write self-documenting code;
8. Create a visual arrangement that facilitates the understanding of the code;
9.
Validation Principles (after completing the first step of coding):
1. Conduct a code inspection when appropriate;
2. Perform unit tests, fixing discovered errors;
3. Refactor the code.
5.5.2) Testing principles:
All tests must be related to the customer's requirements;
The tests should be planned long before they are started;
OPareto principleit applies to software testing (80 - 20);
Generic Set of Test Tasks:
Design unit tests for each software component
2. Develop an integration strategy
 3. Develop a validation strategy
4. Conduct the integration and validation tests
5. Conduct the high-priority tests
Coordinate acceptance tests with the client
5.6) Implementation Practices
The implementation activity involves 3 actions:
Delivery;
Support and
3. Feedback.
Key Principles of Implementation:
Customer expectations regarding the software must be managed;
A complete delivery package must be assembled and tested;
A support regime should be established before the software is
delivered
4. Appropriate institutional materials must be provided to the
end users;
The software must be fixed first and then delivered.
Generic Set of Implementation Tasks:
Create delivery media;
2. Establish personal or group human support;
3. Establish mechanisms for user feedback;
4. Disseminate the delivery media among all users;
5. Conduct permanent support functions;
6. Collect feedback from users;

Systems Engineering

• Focuses on system elements: general objective, hardware architecture,

software, personal, database, procedures and other elements of
system
The Systems Engineering process takes various forms, aiming to
organize the development of computer-based systems
Business Process Engineering
2. Product Engineering;

6.1) Computer-Based Systems;

 Main elements: software, hardware, personnel, database, documentation and
procedures;

6.2) The Hierarchy of Systems Engineering

Regardless of the focus domain, ES encompasses top methods.

down and bottom-up to navigate the ES hierarchy:
Worldview;
2. Domain Vision;
3. Vision of the Element;
4. Detailed Vision;
• System modeling - restrictive factors:
1. Assumptions;
2. Simplifications;
3. Limitations;
4. Restrictions;
5. Preferences
System Simulation;

6.3) Business Process Engineering

Define architectures that allow a business to use information from

effective way;
3 architectures that should be analyzed:
Data Architecture
2. Application Architecture;
3. Technological Infrastructure;

6.4) Product Engineering

Translate the customer's desire for a defined set of capabilities to

a product in operation;

6.5) System Modeling

The system models tend to be layered (hierarchical);

Hatley-Pirbhai model - any computer-based system can be
modeled as a transformation using an input-output template;
 • Modeling with UML;

Requirements Engineering

7.1) A bridge for the Project and the Construction;

7.2) Tasks for Requirements Engineering:

Conception;
Survey;
Preparation;
Negotiation;
Specification;
Validation;
Requirements Management;

8) Analysis Modeling
9) Project Engineering
10) Architectural Project
11) Project at the Component Level
12) User Interface Project
13) Software Testing Strategies
14) Software Testing Techniques
15) Software Project Metrics

MODULE 3 - APPLICATION OF WEB ENGINEERING

Web Engineering
17) Formulation and Planning for Web Engineering
18) Analysis Modeling for Web Applications
19) Project Modeling for Web Applications
Web Application Testing

MODULE 4 - SOFTWARE PROJECT MANAGEMENT

21) Concepts of Project Management

22) Process and Project Metrics
23) Software Project Estimation
24) Software Project Scheduling
25) Risk Management
Quality Management
27) Change Management

MODULE 5 - ADVANCED TOPICS IN SOFTWARE ENGINEERING

28) Formal Methods

Clean Room Software Engineering
30) Component-Based Software Engineering
Reengineering
The Road Ahead

GENERAL TOPICS

Unified Process

The unified process (UP) of software development is the set of

necessary activities to turn user requirements into a
software system, using the OO paradigm;
It is based on components that perform interfaces;
• Uses UML;
It is driven by 'use-cases';
• 4 P: People, Product, Project, and Process;
It is iterative and incremental;
The Unified Process organizes its iterations into four main phases:
1. Conception: the objective of this phase is to raise, in a generic way
little is needed, the scope of the project. There should not exist here the

the intention to specify requirements in detail, the idea is to have

an initial view of the problem, roughly estimating effort and
deadlines and determine if the project is viable and deserves further analysis.
deep.
2. Elaboration: in the elaboration phase everyone (or the vast majority of
requirements) are raised in detail. In a first iteration a
the two requirements, those of greatest risk and architectural value, are
specified in detail. These are implemented and serve as
evaluation base with the user and developers for the
planning of the next iteration. In each new iteration in the phase of
there may be a requirements seminar, where requirements
 the old are better clarified and the new are detailed. At the end of the
stage, 90% of the requirements have been raised in detail, the core of
the system was implemented with high quality, the main risks
they were treated and it is then possible to make more realistic estimates.
3. Construction: iterative implementation of the remaining elements of
less risk and easier preparation for implementation.
4. Transition: final tests and deployment.
The PU uses models that describe the system to be developed under a
certain point of view and its environment. The following are the models:
1. Requirements (functional and non-functional);
2. Analyses (classes and responsibility);
3. Project (project classes, subsystems, interfaces);
4. Distribution (physical nodes and the components in each node);
5. Implementation ;
6. Testes;

Requirements Engineering

It is a process that encompasses all activities that contribute to the

production of a requirements document and its maintenance over time
time
This process must be preceded by feasibility studies that, starting from the
project restrictions determine whether it is viable and whether it should
proceed to the identification of the requirements.
The requirements engineering process is composed of four activities of
high level
1. Identification.
2. Analysis and negotiation.
3. Specification and documentation.
4. Validation.

LIST 01

1) What is UML and what are the reasons for its creation?
2) What is the purpose of the UML use case diagram?
3) What were the A&P methodologies used over time?
What is Essential Analysis?
5) Describe the Environmental Model of Essential Analysis.
6) Describe the Behavioral Model of Essential Analysis.
7) Cite 3 características do ciclo de vida espiral.
8) Cite 3 características do ciclo de vida em cascata.
9) Why is a good requirements gathering important?
10) Cite e descreva os tipos de manutenção de software.
What is a software development process?
12) Present the main activities of a generic software development process.
13) Where is ICT applied in the work chain?
14) Why does the OO paradigm assist in the design of complex systems?
15) Cite two tools used for project management.
16) What is the Context Diagram and what is it used for?
17) What are the steps of a generic process?
18) Define functional and non-functional requirements.
19) What is a software production process?
What is the life cycle?
What is requirements gathering?
22) What is a Use Case Model for.
23) What are the main steps in a requirements gathering process?

LIST 02

What importance was given to software in the 1950s?

What is the dual role attributed to software?
3) What are the 10 categories of software?
4) What are they for:
a) Systems Software;
b) Application Software;
What is software development?
What is the software development process?
What is Software Engineering?
8) What are the layers of Software Engineering?
What is a software development process framework?
10) List the components of a process framework
generic software development.
11) What are umbrella activities?
12) List 3 umbrella activities?
13) How is an action represented in Software Engineering?
14) What is the CMMI model used for?
What is a process pattern?
16) Cite 3 elements that make up a process pattern.
What are prescriptive process models for?
18) Cite 3 examples of incremental process models.
19) Describe the RAD model.
20) Cite 2 evolutionary models of software process.
21) What are COTS components?
22) What does the model that employs formal methods consist of?
23) What are the phases of the unified process?
What is valued in agile development?
25) Cite two agile software development process models.
26) Quais os 4 principios da filosofia de Desenvolvimento Ágil?
27) Describe the steps involved in prototyping.
28) Describe the waterfall development model.
29) What is the difference between waterfall development and the models
incremental?
30) Why is the use of engineering techniques and tools important?
Software?

LIST 03

In the unified process, five workflows accompany the set of phases of

software development. Each workflow is a set of activities
executed by various project members. Considering the development of a
integrated management system (ERP), packaging into components of
software of the project model elements — such as source code file,
dynamic link library and executable components — is described by
workflow of _______________________
ENADE 2005

In the process of developing a materials control system

(raw materials) for a metallurgical company, the project team responsible for
mapping of requirements, developed its work following the four
subprocesses of requirements engineering. Initially, the analysis was made and the
evaluation to verify if the system would be useful to the business. In a second
At the moment, the requirements have been identified and analyzed, and right after that, they were
documented. Finally, it was verified whether the identified requirements were met.
user demands. Having executed this procedure, a company
independently of the audit, after analysis, it identified two problems in the process: the
the documentation of the requirements (forms and standards used) was inadequate
and did not allow for the correct understanding of the requirements; the checking process
between the users' demands and the reported specifications, it was not good
driven and its results were unsatisfactory. Considering the report of
independent audit, what were the two phases of the engineering process
requirements that faced issues?

3) Object-oriented thinking is an abstract way of thinking about a problem.

using concepts from the real world and not just computational concepts.
In this perspective, the adoption of the object-oriented paradigm implies
necessarily that:

A) users use the applications more simply.

B) the systems are encapsulated by other systems.
C) application programmers be more specialized.
D) objects should be implemented in an efficient and simple way.
E) computing is triggered by message exchanges between objects.

04) In the object-oriented design phase, in the context of a process of

software development, the activities of are developed:
A) definition of the system architecture and conversion of the system databases.
B) identification of the system objects and definition of the system architecture.
C) conversion of the system's databases and system integration testing.
D) system integration testing and system requirements analysis.
E) system requirements analysis and system architecture definition.

The global software development GSD — global software development —

has established itself as one of the major trends in the field of systems
information in organizations. Consider that an organization in the retail sector and
distribution based in Europe has established three development units
of software spread around the world: one in Brazil, one in India, and another in
China. Also consider that none of these units have any type of
certification and that the main problem of the organization is related to
development of systems that meet the needs of the organization and that
reflect the expectations of global customers.
In this situation, the level of the SW-CMM model and the KPA (key process area)
more suitable for the presented situation are, respectively,
A) level 2, KPA RM – requirements management.
B) level 2, KPA SPP - planning.
C) level 2, KPA SPTO - project monitoring.
D) level 3, KPA OPD – definition of the organization's process.
E) level 3, KPA SPE – software product engineering.

The project management model of PMI (Project Management Institute),

described in the PMBOK, involves a set of nine knowledge areas to be
considered with a view to improving the project management process,
expanding, consequently, your chances of success. Consider that, in the
development of a sales system for a company that operates in the segment
industrial, the initial budget has been exceeded by 120% and that the team of
the systems area has completed the system with more than four months of delay.
In the meetings with the users for the delivery of the system, it was found that this
did not meet the specifications expected by the users. In this situation,
areas of knowledge that make up the so-called triple constraint are highlighted,
what are the management areas of:

A) scope, hiring, and cost.

B) timing, hiring, and risk.
C) cost, time, and scope.
D) hiring, cost, and time.
E) risk, time, and scope.

The strategic planning of information systems can be understood

how the process of identifying a computerized application portfolio
that supports the business plan of organizations and assists in
concretization of organizational objectives. The main goals of the process of
strategic planning of information systems does not include:

A) the alignment of IT area strategies with business strategies.

B) the commitment of senior management, through the allocation of resources and
intermediate and incremental results.
C) the improvement of the performance of the IT area, either by more effective allocation of
resources, either through the increase in productivity of professionals.
D) the anticipation of trends, involving continuous technological innovation.
E) the identification, evaluation, and validation of controls
related to existing information systems, from the point
in terms of its efficiency and effectiveness.

08) Judge the following items regarding software testing.

I- The functional testing technique, which establishes the testing requirements based on
certain implementation allows to verify if the details of are met
code and requests the execution of parts or elementary components of
program; the structural testing technique approaches the software from a point of view
macroscopic and establishes the testing requirements, based on a certain
implementation.
In the unit testing phase, the goal is to explore the smallest unit of design,
aiming to identify errors in logic and implementation of each module; in
integration testing phase, the goal is to discover errors associated with the interfaces
among the modules when they are integrated, to build the structure of the
software, established in the design phase.
III- Criteria based on complexity, control flow, and data flow,
are used by the structural testing technique.
Select the correct option.

A) Only one item is correct.

B) Only items I and II are correct.
C) Only items I and III are correct.
D) Only items II and III are correct.
E) All items are correct.

The development manager of an IT company examined the following

spreadsheet about project progress.

project completed percentage (%)

already spent (in %)
P1 50 70
P2 80 65

Based on this spreadsheet and regarding the concepts of data, information, and
knowledge, judge the following items.

I - The number 65, in the bottom right cell, is a piece of data.

II - Associate the number 80 (bottom center cell) with the percentage completed (in %)
And to P2, concluding that project P2 is 80% completed is a piece of knowledge.
III - Saying that P1 is ahead or behind is an information.
IV - Say how much P1 will need more than what was initially planned in
The budget is a knowledge. Only the items are correct:

A - I and II.
B - I and IV.
C - II and III.
D - II and IV.
E - III and IV.

The objective of General Systems Theory (GST) is the formulation of principles

valid for systems in general, regardless of the nature of the elements that
they are composed of and the relations or forces existing between them. In the area of systems of
information, various problems require a multidisciplinary approach to be
resolved. For example, in the area of software development, the specification
of requirements presents several challenges of this type, such as aspects of
interpersonal relationships, business knowledge, conflict resolution
cultural differences etc. The purposes of TGS that can contribute to the
the resolution of these problems includes
I- the incentive for the total specialization of areas of knowledge.
II - the development of unifying principles that transcend the universe of
individual sciences.
III- the integration of contributions from various sciences in the search for solutions of
problems.
IV - the development of unique principles for each area of knowledge.
V - the development of studies aimed at increasing the separation between the
Natural and social sciences. Only the following items are correct:

I and II.
B) I and V.
C) II and III.
D) III and IV.
E) IV and V

11) What is the importance of version management in a process of

software development and how configuration management can help
in this process?

12) ForWhat is a version control system used for?

13) How does version control work?

14) What are the similarities and differences between version control
centralized and the distributed?

15) Name two version control tools and give an example of their use.

16) How does Version Control support software development?

• History. Records the entire evolution of the project, each change regarding
each file. With this information, it is known who did what, when
and where. In addition, it allows reconstructing a specific review of
file whenever desired;
• Collaboration. Version control allows multiple
developers work in parallel on the same files without
that one overrides the code of another, which would bring the reappearance of
defects and loss of functionalities;
• Variations in the Project. Maintains different lines of evolution of the same.
project. For example, maintaining a version 1.0 while the team
prepare a version 2.0.

17) How does version control work?

Version control consists of two parts: the repository and the staging area.
work. The repository stores the entire historical evolution of the project,
recording every and any change made to each versioned item.
The developer does not work directly on the repository files.
Instead, use a workspace/copy that contains the copy of
project files and is monitored to identify changes
completed. This area is individual and isolated from the other work areas.
The synchronization between the desktop and the repository is done through
two commands decommit and update.
The commit sends a package containing one or more modifications made to the
working area (source) to the repository (destination). The update does the
inversely, that is, sends the modifications contained in the repository (source)
to the desktop (destination).
Each commit creates a new revision in the repository, containing the
modifications made, date and author. A revision works like a "snapshot"
of all the files and directories at a given moment of
evolution of the project. The old 'photos' are kept and can be
recovered and analyzed whenever desired. The set of these
revisions are precisely the history of the project.
Both centralized and distributed version control have
repositories and work areas. The difference lies in how each one
of these parts is arranged.

18) What is software quality?

R.: Software quality is a field of knowledge ofengineering of

softwarethat aims to ensure software quality through definition and
standardization of development processes. Despite the models applied in
software quality assurance mainly acts in the process, the main
The goal is to ensure a final product that meets the customer's expectations, within
from what was initially agreed.

19) What is software quality according to the ISO 9000 standard

R.: According to the standardISO
9000(version 2000), to aqualityit is the degree to which a
set of inherent characteristics of a product, process, or system meets the
initially stipulated requirements for these.

20) What is GQS (Software Quality Assurance)?

R.: Software Quality Assurance (SQA) is the key process area.

doCMMwhose goal is to provide the various levels of management with the appropriate
visibility of projects, development processes and products
generated. The GQS acts as a "guardian", providing a portrait of the use of the Process and
is not responsible for performing software testing or inspection of artifacts.

21) What is the CMM model

R.: The 'CMM - Capability Maturity Model for Software /SEI' is a

framework, which describes the main elements of a process of
effective software development. The CMM describes the stages of maturity
through which software organizations evolve their cycle of
software development through its continuous evaluation, identification and
corrective actions within a process improvement strategy. This path
improvement is defined by five maturity levels: initial, repeatable, defined,
managed and optimized.

What is CMMI?

CMMI (Capability Maturity Model Integration) is a reference model that

contains practices (Generic or Specific) necessary for maturity in
specific subjects (Systems Engineering (SE), Software Engineering (SW),
Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).
Developed by the SEI (Software Engineering Institute) ofCarnegie University
Mellon, the CMMI is an evolution ofCMMand seeks to establish a unique model
for the corporate improvement process, integrating different models and
subjects.
The current version of CMMI (version 1.2) presents three models:
CMMI for Development (CMMI-DEV) published in August 2006. It addresses the
product and service development process.
 CMMI for Acquisition (CMMI-ACQ) published in November 2007. It addresses
in the processes of acquiring and outsourcing goods and services.
CMMI for Services (CMMI-SVC) published in February 2009. It addresses the
processes of service providing companies.

23) What are the types of representation of CMMI?

Continuous and staged.

What is the purpose of continuous representation?

It allows the organization to use the order of improvement that best meets the
business objectives of the company. It is characterized by Levels of Capability
(Capability Levels):
0
Level 1: Executed (Defined)
Level 2: Managed
Level 3: Defined
Level 4: Quantitatively managed
Level 5: In optimization (or Optimized)

What is the purpose of representation by stages?

Provides a predetermined sequence for stage-based improvement

which should not be disregarded, as each stage serves as a basis for the next.
It is characterized by Maturity Levels:
Level 1: Initial (Ad-hoc)
Level 2: Managed
Level 3: Defined
Level 4: Quantitatively Managed / Managed Quantitatively
Level 5: In optimization
26) What does Requirements Engineering consist of?

it is a process that encompasses all activities that contribute to production of

a requirements document and its maintenance over time.
This process should be preceded by feasibility studies that, based on the
project restrictions determine whether it is viable or not and whether it should proceed to
the identification of requirements.

27) Quais as 4 atividades de alto nível da engenharia de Requisitos?

The requirements engineering process consists of four high-level activities.

level (Soares, 2005):
1. Identification.
2. Analysis and negotiation.
3. Specification and documentation.
4. Validation.
Another activity that can be considered as part of this process,
if we include the phase after the document's production (that is, its
Maintenance is the management of [Link] management, as
changes can be caused by a variety of factors ranging from innovations
technological changes in the nature of the business (and consequently in the
requirements), among others).

28) What does a feasibility study consist of?

R.:
Before proceeding with a more detailed analysis of a project's requirements,
A feasibility study must be conducted.
As the name suggests, this study aims to evaluate whether, from a point of
From a technological and organizational perspective, the project is viable.

One way to assess the feasibility of a project is to obtain, through interaction with
the stakeholdersstakeholderin English) of the project (in meetings or
interviews, for example), the answer to the following questions:
Does the system contribute to the organization's objectives?
Given the technological and organizational (economic, political) restrictions,
environmental, available resources) and temporal aspects associated with the project, will it
Can the system be implemented?
If there is a need for integration between different systems, will this be
possible?
What does an ethnographic study consist of?
TheEthnographic Studiesthey are an analysis of the social component of the tasks
performed in a given organization. When a given set of tasks is
If it becomes routine for a person, it is expected that they will have difficulty articulating.
all the steps you take or all the people you interact with for the
carry out. Through a direct observation of the activities performed during
during an employee's work period, it is possible to find requirements that are not
they would be observable using conventional techniques. This observation can be
accompanied by audio/video records, however, it is not advisable to use them excessively
since the time required to process them may be too much. In this technique
it is assumed that the observed customer representative performs their duties
correctly, so it is advisable to be careful in choosing it.

30) What does software configuration management consist of?

R.:
According to Babich [BABICH86], software configuration management is:
The art of coordinating software development to minimize confusion is
call of
configuration management. Configuration management is the art of identifying, organizing
and control
software modifications that is being built by a team of
programming. The objective is
maximize productivity by minimizing errors.

According to Sommerville [SOMMERVILLE03], configuration management

configuration
management - CM) is the development and application of standards and procedures
to manage a
product of system under development. It is necessary to manage the systems in
development
because, as they develop, many different versions are created
of the software. These
versions incorporate proposals for changes, bug fixes, and adaptations
for different
hardware and operating systems. It is possible that there are several versions in
development and in use
at the same time. It is necessary to keep track of the changes that have been made.
implemented and of
how these changes were included in the software.

31) What does component-based software engineering (CBSE) consist of?

R.:
Component-Based Software Engineering is a branch ofEngineering of
Software, with an emphasis on the decomposition of systems, incomponentsfunctional
and logic elements with well-defined interfaces, used for communication between themselves
components. Components are considered to be at a level
de abstractionhigher thanObjectsand, as such, do not share state and
they communicate by exchanging messages containing data.

What is a software component?

Brown and Wallnau[3]they describe a component as 'a non-trivial, almost

independent, and replaceable part of a system that fulfills a clear function in
context of a well-defined architecture". In many ways, this description is
similar to that of an object inOOPComponents have an interface. They
they employ rules ofinheritance.
Already for Szyperski[4], the component is not necessarily a technology
specifically implemented and not the application, but rather a device of
software that has a well-defined interface.
But for Krutchen5, the component is an independent element that can be
replaced, however, it is significant, as it has a clear function in the context in
what was defined.
But the definition goes even further. Components are defined to offer a
certain level of service. In the case of "off-the-shelf commercial components" (or
commercial off-the-shelf - COTS), the software engineer knows little or nothing
about the internal workings of a component. Instead, to the engineer
the software is given only a well-defined external interface from which it
must work. The level of service is therefore crucial and needs to be accurate if you want
that the integration of the component into the software system is successful. Brown
The Wallnau describes a software component as 'a unit of
composition contractually specified and only with contextual dependencies
[Link] components are usually
built from many software "objects" (although the construction is not
confined to OOP) and provide a coherent unit of functionality. The thus
called "objects" work together to perform a specific task in
a given level of service. Components can be characterized based on
their use in the ESBC process: As mentioned above, we have the COTS. They are
components that can be purchased, pre-fabricated, with the disadvantage of
that, in general, there is no source code available, and thus, the definition of the use of
component given by the manufacturer (developer), and the services they offer,
must be reliably tested, as they may or may not be accurate. The
the disadvantage, however, is that these types of components should (in theory)
to be more robust and adaptable, as they have been used and tested (and reused and re-
tested) and many different applications. In addition to the COTS, the ESBC
clam
Qualified components[6]
Adapted components
Glued components
Updated components
33) What are the 2 processes that run in parallel in the ESBC?

Domain Engineering
The objective is to identify, build, catalog, and disseminate a set of components.
of software that have applicability for existing and future software, within
a specific application domain. An application domain is like a family
of products - applications with similar functionality (or intended functionality).
The goal is to establish a mechanism in which software engineers can
share these components by using them in future systems.
b) Component-Based Development
Component-Based Development (CBD) addresses the creation of systems
of software that involves the composition of components allowing for the addition,
adaptation, removal, and replacement of parts of the system without the need for its
complete replacement. This helps in the maintenance of systems since,
allows for the integration of new components and/or the update of existing ones. The
the approach is to create or adapt the components so that they can be used in
various systems. This idea aligns with reuse that seeks to provide flexibility
the development.

34) What are the main existing component models?

 CMM (CORBA Component Model) from OMG (Object Management Group);
DCOM (Distributed Component Object) and COM/COM+ (Component Object)
Microsoft's model; and
JavaBeans and Enterprise JavaBeans (EJB) from Sun.

35) What is the purpose of risk management?

Risk management can be defined as culture, process, and structure

related to perceiving opportunities while managing effects
adverse. One explanation for the growing interest in risk management is
the opportunity to apply our ideas and tools to the 'new reality'
of risk". We believe that risk management should be an integral part of
good business practices, both at the strategic level and
operational
The main point of managing risks is to assess the uncertainty of the future.
way to make the best possible decision. In general, all risk management and
every decision-making addresses this issue. The benefits are
better decisions, fewer surprises, improvement in planning, in
performance and effectiveness and also, improvement in the relationship with the
stakeholders.

36) What are the types of risks in software?

R.:
According to Nature
Project Risks
Business Risks
Technical Risks
According to the probability of the event
Known
Predictable
Unpredictable

37) What are the continuous activities of Risk Management, according to SEI?
Communicate
Identify
Identify and locate risks before they become real problems
Analyze
Transform the risk data into information for decision-making
Plan
Translate and implement the risk information into decision-making actions and
risk resolution
Monitor
Monitor risk indicators and their resolution plans
Control
Correct the deviations from the risk resolution plans

What is a version control tool?

39) What is the importance of using a version control tool in a
project?
What does the component development philosophy consist of?
41) Give examples of component-based development architectures.
42) Why the exact establishment of the system requirements with the client and its
Why is exact understanding by the development team so important?
43) What is a 'milestone' in project management?
What is the purpose of change management?
What is reuse management?
46) Briefly describe what the practices of Engineering are for.
Software, what are its advantages in system development?

Considerations on Graph Theory

A graph G = (V, E) consists of a non-empty set V of vertices (nodes) and a

set (E) of edges (arcs), where each edge connects two vertices. A graph
can be represented in two ways: one based on a representation
visual, using closed circles for vertices and straight lines or curves for edges and others
more formal that uses matrices and vectors. The second form will be used in
data structures that work with graphs, in computer programs.
Below is an example of a graph G (V,E), where:
V ={a, b, c, d, e, f
E = {(a, b), (b, c), (b, e), (c, e), (c, d), (d, f)}}
(a, b) is an edge between vertex a and b.
A graph can be directed or undirected. In a directed graph, the order of the vertices matters.
in an undirected graph, this order is indifferent. A directed graph is also called
Digraph consists of an ordered triple (N,A,g), where:
N = A non-empty set of nodes
A = A set of arcs
g = Function that associates each edge with an ordered pair (x,y) of nodes
In function g, x is the initial point (endpoint) and y is the final point of a. Besides the
orientation can impose weights, where each arc has a numerical value
associate.

A path is a sequence of vertices v1, v2, …, vnconnected by edges (v1,

v223)... (vn - 1, vnThe edges are also considered as part of the
path. The length of a path is given by the number of arcs it
contains.
Umcircuitit is a path where the final vertex is equal to the initial one. A circuit will be
It's simple if no vertex appears more than once, except for the first and the last.
A simple circuit is called acycleA graph without cycles is called a
acyclic.

Given a graph, we say that one vertex is adjacent to another vertex if there is an edge between them.

a graph has an edge that connects the two. A loop is an arc with endpoints n-n, for
some node n. Two arcs with the same endpoints are said to be parallel.
A graph is connectedconnectedif there exists a path between any two vertices
of the graph.

The degree of a vertex is the number of edges adjacent to it. In a directed graph, the
the in-degree is given by the number of edges that arrive at the vertex and the degree of
output by the number of edges that exit.

A source is a vertex with an in-degree of 0 and an out-degree greater than 1. A sink is

a vertex with an out-degree of 0 and an in-degree>

A graph G = (V, E) is usually represented by an adjacency matrix.

Make program for Unix

The make program of Unix takes as input a text file containing commands.
in the form
d1d2… dn
Commands

Name is the name of a file that depends on files d.1d2… dn.

Read this text and execute commands if the last update date of any
file difor newer than of Name. That is, if any dIfor younger than
Name, it executes Commands, which are commands for Unix that possibly
they should update the file Name. Ex.:

prog : [Link] [Link]

ln -o prog [Link] [Link] [Link]
[Link] : a.c prog.h
cc -c a.c
[Link] : b.c prog.h
cc -c b.c.
[Link] : c.c
cc -c c .c

ln is the linker and cc is the compiler. If, for example, b.c is modified, make will
recompile it (Command "cc -c b.c"), because it will be newer than
"[Link]". Then "[Link]" will be newer than the program that will be linked by "ln -o"
prog [Link] [Link] [Link]
The dependency relationships of make can be represented in the form of a graph.

Elimination of Dead Code

We can represent a procedure as a graph where the instructions are

vertices and there exists a directed edge from v to w if w is executed after v (or can be
executed, in the case of if's and while's). The function

void f(
{
if (i > 0)
{
j = 1;
goto L1;
 a = 10;
}
else
j = 10;
return 1;

}
would be transformed in the graph

To discover the dead code, we perform a search starting from the first instruction of the
procedure marking all visited vertices. The corresponding instructions
the never-visited vertices will never be executed and can be removed by
compiler.
Note that with this same graph, it can be discovered whether the return instruction will be
executed by all the paths that connect the starting vertex to the vertex "end of
function". The answer to the graph above is: no.

Exercises

There will be a charge in the test for transformation of codes into graphs and verification of their

utility.