Soft Eng | 2nd Quiz Flashcards
an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
spiral model
spiral process model was originally proposed by
barry boehm
it provides the potential for rapid development of increasingly more complete versions of the software
spiral model
a risk-driven process model generator that is used to guide multi- stakeholder concurrent engineering of software intensive systems
spiral development model
two main distinguishing features of spiral model
cyclic approach and set of anchor point milestones
it is for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk
cyclic approach
it is for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions
set of anchor point milestones
concurrent development model is sometimes called
concurrent engineering
it allows a software team to represent iterative and concurrent elements of any of the process models
concurrent development model
this activity may be in any one of the states noted at any given time
modeling
is dynamic, content specific, aggressively change embracing, and growth oriented
agility
it encourages team structures and attitudes that make communication more simplistic
agility
it emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate work products
agility
it can be applied to any software process
agility
it is most widely used agile process model
extreme programming
it uses an object-oriented approach as its preferred development paradigm
extreme programming
four (4) framework activities of extreme programming
planning, design, coding, and testing
a design prototype
spike solutions
an iterative refinement of the internal program design
refactoring
occurs both before and after coding commences
design
developers work in pairs, checking each other’s work and providing the support to always do a good job
pair programming
this framework activity of XP, stores user stories, values, acceptance test criteria, and iteration plan
planning
it defines four (4) framework activities: Planning, Design, Coding, and Testing
extreme programming
this phase of adaptive software development incorporates adaptive cycle planning, mission statement, project constraints, basic requirements, and time-boxed release plan
speculation
a technique for building complex software and systems
adaptive software development
focus on human collaboration and team self-organization
adaptive software development
it incorporates three phases: Speculation, Collaboration, and Learning
adaptive software development
refers to the planning paradox—outcomes are unpredictable, therefore, endless suppositions on a product’s look and feel are not likely to lead to any business value
speculate
in this mindset, planning is to speculation as intention is to need
adaptive software development
it represents a balance between managing the doing and creating and maintaining the collaborative environment
collaboration
it challenges all stakeholders and project team members
learning
an agile software development approach that provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment
dynamic systems development method
an iterative software process in which each iteration follows the 80 percent rule
dynamic systems development method
it establishes the basic business requirements and constraints associated with the application to be built
feasibility study
it establishes the functional and information requirements that will allow the application to provide business value
business study
produces a set of incremental prototypes that demonstrate functionality for the customer
functional model iteration
revisits prototypes built during functional model iteration to ensure that each has been engineered in a manner that will enable it to provide operational business value for end users
design and build iteration
it places the latest software increment into the operational environment
implementation
can be combined with XP to provide a combination approach that defines a solid process model
dynamic systems development method
they are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the five framework activities: requirements, analysis, design, evolution, and delivery
scrum principles
within each framework activity, work tasks occur within a process pattern called
sprint
emphasizes the use of a set of software process patterns that have proven effective for projects with tight timelines, changing requirements, and business criticality
scrum
items can be added to the backlog at any time
scrum
five framework activities of scrum
requirements, analysis, design, evolution, and delivery
a prioritized list of project requirements or features that provide business value for the customer
backlog
one of the most lightweight, adaptable approaches to software development
crystal methodology
it is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities
crystal
it promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions
crystal
it addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project‘s unique characteristics
crystal family
a model-driven, short-iteration process
feature driven development
it continues with a series of two-week “design by feature, build by feature”
feature driven development
it features are small, “useful in the eyes of the client” results
feature driven development
it means that requirements for a product are defined, managed and tested systematically
requirement engineering
it builds a bridge to design and construction
requirement engineering
it provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system
requirement engineering
it contains a complete information description, a detailed functional description, a representation of system behavior, an indication of performance requirements and design constraints, appropriate validation criteria, and other information pertinent to requirements
system requirement specification
it is a document that completely describes what the proposed software should do without describing how software will do it
system requirement specification
it is also helping the clients to understand their own needs
system requirement specification
the basic goal of this phase is to produce the SRS, which describes the complete behavior of the proposed software
requirement phase
it is said to be of high quality when the developer and user easily understand the prepared document
system requirement specification
it is when all user requirements are stated in the requirements document
correct
it is when every stated requirement has only one interpretation
unambiguous
it is when the requirements clearly define what the software is required to do
complete
all requirements are not equally important, hence each requirement is identified to make differences among other requirements
ranked for importance
it implies the probability of changes in the requirement in future
stability
the requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS
modifiable
it is when the source of each requirement is clear and facilitates the reference of each requirement in future
traceable
it implies that each requirement should be traceable to design and code elements
forward tracing
it implies defining each requirement explicitly referencing its source
backward tracing
it is when the specified requirements can be verified with a cost-effective process to check whether the final software meets those requirements
verifiable
it is essential for verifiability
unambiguity
it is when the subsets of individual requirements defined do not conflict with each other
consistent
these are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations
functional requirements
in some cases, it may also explicitly state what the system should not do
functional requirements
these are constraints on the services or functions offered by the system
non-functional requirements
it often applies to the system as a whole rather than individual system features or services
non-functional requirements
requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
product requirements
requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.
organisational requirements
requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
external requirements
