|
jautājums |
atbilde |
|
sākt mācīties
|
|
one activity in software engineering
|
|
|
|
sākt mācīties
|
|
a computer program and it's documentation
|
|
|
|
sākt mācīties
|
|
Execute the software using simulated test data
|
|
|
Activities in software engineering sākt mācīties
|
|
Specification of requirements, Validation and Testing, Implementation or development
|
|
|
Diverse software engineering techniques sākt mācīties
|
|
Waterfall model, Incremental model
|
|
|
|
sākt mācīties
|
|
Rational Unified Process, V-model, Incremental, Spiral, Waterfall
|
|
|
|
sākt mācīties
|
|
Not concerned with quality, ensures requirements are correct before using another process model
|
|
|
|
sākt mācīties
|
|
Large systems, plan-based, difficult to change requirements
|
|
|
System to control antilock braking in a car sākt mācīties
|
|
|
|
|
|
sākt mācīties
|
|
working software is more valuable that comprehensive documentation
|
|
|
|
sākt mācīties
|
|
stored in the Product Backlog
|
|
|
Use case inherit from use case? sākt mācīties
|
|
|
|
|
|
sākt mācīties
|
|
represent an actor and a use case have interaction/communication
|
|
|
Actor inherit from another actor? sākt mācīties
|
|
|
|
|
Activity diagram rounded rectangles sākt mācīties
|
|
|
|
|
Activity diagram diamonds sākt mācīties
|
|
|
|
|
|
sākt mācīties
|
|
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 sākt mācīties
|
|
|
|
|
Class diagram: solid line with empty white triangle at one end sākt mācīties
|
|
|
|
|
|
sākt mācīties
|
|
Two classes pointing at one third class with empty solid line white triangle
|
|
|
UML Use case diagrams are used to capture sākt mācīties
|
|
|
|
|
Software specification/requirement engineering sākt mācīties
|
|
understanding and defining what services or functionalities are required and identifying the constraints on the system operation
|
|
|
|
sākt mācīties
|
|
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
|
|
|
|
sākt mācīties
|
|
Earlier delivery and deployment, easy customer feedback
|
|
|
|
sākt mācīties
|
|
team communication, requirements do not hold up progress, facilitates customer feedback, visibility of everything
|
|
|
Use cases capture requirements? sākt mācīties
|
|
|
|
|
|
sākt mācīties
|
|
reducing by focusing on the essential observable behavior
|
|
|
|
sākt mācīties
|
|
hiding the details of the implementation
|
|
|
|
sākt mācīties
|
|
a single name may denote objects of many different classes that are related by some common superclass
|
|
|
|
sākt mācīties
|
|
"text-based" representation of an algorithm
|
|
|
|
sākt mācīties
|
|
responsible for the skeleton and the high-level organization of a software. Identifies the main structural modules/components in a system their relationships
|
|
|
|
sākt mācīties
|
|
show that the program does as intended, discover program defects
|
|
|
|
sākt mācīties
|
|
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
|
|
|
