|
término |
definición |
|
empezar lección
|
|
one activity in software engineering
|
|
|
|
empezar lección
|
|
a computer program and it's documentation
|
|
|
|
empezar lección
|
|
Execute the software using simulated test data
|
|
|
Activities in software engineering empezar lección
|
|
Specification of requirements, Validation and Testing, Implementation or development
|
|
|
Diverse software engineering techniques empezar lección
|
|
Waterfall model, Incremental model
|
|
|
|
empezar lección
|
|
Rational Unified Process, V-model, Incremental, Spiral, Waterfall
|
|
|
|
empezar lección
|
|
Not concerned with quality, ensures requirements are correct before using another process model
|
|
|
|
empezar lección
|
|
Large systems, plan-based, difficult to change requirements
|
|
|
System to control antilock braking in a car empezar lección
|
|
|
|
|
|
empezar lección
|
|
working software is more valuable that comprehensive documentation
|
|
|
|
empezar lección
|
|
stored in the Product Backlog
|
|
|
Use case inherit from use case? empezar lección
|
|
|
|
|
|
empezar lección
|
|
represent an actor and a use case have interaction/communication
|
|
|
Actor inherit from another actor? empezar lección
|
|
|
|
|
Activity diagram rounded rectangles empezar lección
|
|
|
|
|
Activity diagram diamonds empezar lección
|
|
|
|
|
|
empezar lección
|
|
when a use case requires a list of different states of a system at a given time
|
|
|
Class diagram: solid line with empty white diamond at one end empezar lección
|
|
|
|
|
Class diagram: solid line with empty white triangle at one end empezar lección
|
|
|
|
|
|
empezar lección
|
|
Two classes pointing at one third class with empty solid line white triangle
|
|
|
UML Use case diagrams are used to capture empezar lección
|
|
|
|
|
Software specification/requirement engineering empezar lección
|
|
understanding and defining what services or functionalities are required and identifying the constraints on the system operation
|
|
|
|
empezar lección
|
|
the description of the structure of the software to be implemented. Responsible for the code level design, what each class is doing, its relationships, and scope
|
|
|
|
empezar lección
|
|
Earlier delivery and deployment, easy customer feedback
|
|
|
|
empezar lección
|
|
team communication, requirements do not hold up progress, facilitates customer feedback, visibility of everything
|
|
|
Use cases capture requirements? empezar lección
|
|
|
|
|
|
empezar lección
|
|
reducing by focusing on the essential observable behavior
|
|
|
|
empezar lección
|
|
hiding the details of the implementation
|
|
|
|
empezar lección
|
|
a single name may denote objects of many different classes that are related by some common superclass
|
|
|
|
empezar lección
|
|
"text-based" representation of an algorithm
|
|
|
|
empezar lección
|
|
responsible for the skeleton and the high-level organization of a software. Identifies the main structural modules/components in a system their relationships
|
|
|
|
empezar lección
|
|
show that the program does as intended, discover program defects
|
|
|
|
empezar lección
|
|
testing method by which individual units of source code (which have associated control data, usage procedures, and operating procedures) are tested to determine whether they are fit for use
|
|
|
