Fichas
Software R&A
Fichas del conjunto (99)
- 1What does the software development lifecycle identify?- exact ACTIVITIES of development from inception to phase out
- the applied MODELING approach
- the METHOD and associated PROCESS - 2Describe the application domain- requirement elicitation
- analysis
- system design - 3Describe the solution domain- object design
- program implementation
- testing
- delivery
- maintenance - 4Describe requirement elicitation- client and developers define purpose of system
- the system is described in terms of actors and use cases - 5what is an actor?external entities that interact with the system
- 6what does a use case do?describes possible functionality of the system
- 7Describe analysis- devs aim to produce system model that is: correct, complete, consistent and unambiguous (CCCU)
- use cases are transformed into an object model that completely describes the system
- system model has attributes, operations and associations - 8Describe system design activity- devs define design goals
- system is decomposed into smaller subsystems
- system building strategies are selected (hardware/software platform decisions)
- result: subsystem decomp, strategies, deployment diagram - 9Describe object design activity- bridge gap between analysis model and software/hardware platform defined during system design
- result: detailed object model with constraints and precise descriptions for each element - 10Describe implementation activity- solution domain model gets transformed into source code
- 11Describe testing- find differences between system and its models
- find and repair faults in the system - 12Describe maintenance- remove software errors
- enhance existing software - 13When should a new system study be performed?when cost of continued maintenance is greater than that of creating an entirely new system
- 14what is a model?abstract representation of a system
- 15how to we deal with complexity?through modeling: focusing only on the relevant details, ignore everything else
- 16what 2 techniques is the structured approach based on?1) DFD: data flow diagrams
2) ERD: entity relationship diagrams - 17What type of modeling is DFD used forprocess modeling
- 18what type of modelling is ERD used fordata modelling
- 19what is process-centric?breaking system into manageable units using functional decomposition
- 20each new DFD is called what?intermediate levels
- 21when DFD reaches a point where functional decomposition is no longer useful, the level is called?functional primitive
- 22what is data-centric?evolves around class models
- 23What do use case diagrams describe?functional behavior of system as seen by user
- 24what do class diagrams describestatic structure of system: objects, attributes, association
- 25what do sequence diagrams describedynamic behavior between objects of the system
- 26what do statechart diagrams describedynamic behavior of an individual object
- 27What are the two structured methods?waterfall model, v-model
- 28what are the 3 RAD (rapid application development methods)incremental and iterative (phased), prototype model, spiral model
- 29what are the two agile methods?extreme programming model, SCRUM
- 30describe the waterfall model- each activity must be completed entirely before next activity can begin
- activities do not overlap - 31list advantages of waterfall model- simple and easy to use
- easy to manage - 32what projects is waterfall model good for- smaller projects with very well understood requirments
- 33list the disadvantagse of waterfall model- difficult to response to changing customer requirements
- adjusting scope can kill project
- working software isn't produced until late in the life cycle - 34when not to use waterfall model- high risk and uncertainty
- long run projects - 35describe the v-model- like the waterfall method: sequential path of execution of processes
- testing procedures are developed early in life cycle (before coding) - 36list advantages of v-model- simple and easy to use
- higher chance of success then waterfall because of test plans developped earlier in life cycle - 37when does v-model work well- small project with easy to understand requirements
- 38list disadvantages of v-model- rigid like waterfall
- scope adjustment is difficult and expensive
- no early prototypes of software
- clear path for problems identified during testing is not provided - 39describe incremental iterativemodel- each iteration passes through: requirements, design, implementation and testing
- 40list advantages of incremental interative method- functionality available earlier
- high priority functionalities recieve more testing
- more flexible: cheaper to change scope
- easier to test - 41list disadvantages of incremental iterative model- each iteration activity is rigid and does not overlap
- problems relating to system architecture can arise: all requirements aren't gathered up front - 42describe the prototype model- prototype build tested and reworked until acceptable requirements is met
- complete system is then developed - 43What is the difference betwen a system prototype and a throw-away prototypeSystem
- targets speed of delivery
- used to produce final product
- concentrates on well understood requirements
ThrowAway
- targets requirement determination phase
- discarded when requirement elicitation is completed
- concentrates on least understood requirements - 44list advantages of protoype model- helps to understand the requirements for the user interface
- feasibility of design approach is tested
- perfomance issues are explored - 45list disadvantages of prototype model- user treat prototype as solution which it isn't, its only a partial specification
- 46describe spiral model- 4 phases: system planning, risk analysis, building and customer evaluation
- waterfall model used for each prototype development
- activity sets are applied to "rounds" - 47describe the 4 quadrants of the spiral modelIV - explore alternatives, define constraints, identify objectives
I - manage risks, specify prototype
II - realize and validate a prototype
III - plan next round - 48list advantages of spiral model- emphasis on alternatives and constraints supports reuse of existing software
- 49what is spiral model good for?large scale software projects
- 50list disadvantages of spiral model- risk analysis can lead to project termination
- 51what is agile software development- much of modelling and documentation overhead is eliminated
- face to face communication
- short, complete iterations - 52what are "user stories" in extremem programming- features client wants
- 53how are "user stories" used in extrme programming?- the cost and duration of each story is estimated
- client decided what story will be featured in each build
- builds are divided into tasks
- test cases are drawn up for each task (TDD) - 54define TDDtest driven development
- 55list some unique features of XP- centralized computer workspace
- client rep works with XP team always
- no specialization
- no overall design step before builds start - 56what is the purpose of XPto minimize the number of features
- 57what is "refactoring"it is when the design is modified while the product is being built
- 58what 5 questions are asked during stand up meetings1) what have I done since yesterdays meeting?
2) what am I doing today?
3) what problems are preventing me from achieving this?
4) what have we forgotten?
5) what did I learn that I want to share? - 59describe the scrum model- simple management framework
- uses one or more cross functional, self organizing teams (5-7 people)
- teams are fixed length iterations (sprints)
- its a framework not a defined process or method - 60how is scrum different from XP?scrum doesn't define specific engineering practices
- 61list the scrum roles and their core responsibilitiesproduct owner - final arbiter of requirements
scrum dev team - attempt to build shippable product increment every sprint
scrum master - facilitates scrum process, not PM - 62list the 5 types of scrum meetings- sprint planning meeting
- daily scrum meeting
- sprint review meeting (refine understanding of requirements)
- sprint retrospective meeting (inspect team process)
- backlog refinement meeting - 63what are the scrum artifacts?- product backlog, product backlog item, sprint backlog, sprint task, sprint burndown chart
- 64what are the important factors to consider when selecting a methodology- clarity of user requirements
- familiarity with tech
- system complexity
- system reliability
- short time schedules
- schedule visibility (everybody including client can see how things are going) - 65what methodologies should be used when: unclear requirements, unfamiliar tech, complex, needs to be reliable, short time schedule with high visibilityphased, throw away prototyping, spiral
- 66what methodologies should be used when: clear requirements, familiar tech, complex, needs to be reliable, long time schedule with low visibilitywaterfall, v-model
- 67what methodologies should be used when: unclear requirements, familiar tech, not complex, needs to be reliable, short time schedule with high visibilityXP/Scrum (agile methods)
- 68what 2 question should be answered by system identification1) how can we identify the purpose of the system?
2) what is inside/outside the system? - 69what is a functional requirementdescribes interaction between system and environment (user and other external systems)
- 70what are the 2 categories of non fucntional requirementsquality requirements and constraints
- 71what are the advantages and disadvatages of a passive technique and give an example of one for requirment elicitationadvantage - time to consider answers, multiple perspectives easily
disadvantage - can't clarify anything
example - questionnaire - 72list 3 types of task analysispassive - no interruption
active
explanatory - people explain what they are doing as they are observed - 73what is JAD?joint application development, when PM's, users and devs all work together
- 74what aspects of uses cases are dtailed in the refinement process- elements (attributes, forms) manipulated by system
- 75what is the purpose of the <> relationship- to factor out common behavior between 2 use cases
- factor out and encapsulate behavior from a base use case - 76in what section of the use case do you include the included use case if it occurs at any point in the flow of event?in the quality requirements section
- 77in what section of the use case do you include the included use case if it occurs during an event?in the flow of events
- 78why is <> relationship usedto factor out optional or exceptional behavior
- 79describe requirement traceability- allows someone to follow the life of a requirement both forward and backward; from origin through implementation
- 80what are the 5 motivations for tracing requirements1) certification
2) change impact analysis
3) maintenance
4) reegineering
5) reuse - 81What is the motivation for using the chain of responsibility design pattern- gui classes raise streams of requests
- sometime only certain handler/processing element objects can handle these events
- need to process requests wiout hard wiring everything - 82What does the chain of responsibility pattern do?- chains processing elements together (receiving objects)
- passes all request messages from object to object until an object capable of handling the message is reached - 83How does chain of responsibility pattern handle unlimited number er of handlers to be linkedrecursive composition
- 84draw the chain of responsibility structure and explain the roles of each participant
- 85when should you use the chain of responsibility pattern- when you want to decouple sender and receiver requests
- when you want to dynamically add handlers
- when sender needs to be able to think of messages as launch and leave
- when multiple objects can handle requests - 86What is the motivation behind the mediator design patternreduce the number of interconnections between objects by keeping objects in the group from referring to each other explicitly
- 87what does a mediator do?controls and coordinates interactions for a group of objects
- 88draw the structure for the mediator pattern, identify and define the participants
- 89when should you use the mediator pattern?- when a set of object communicates in a well defined and complex way
- when it is difficult to reuse an object because it communicates with many other objects
- a behavior that is distributed amount several classes should be customizable without tons of sub-classing - 90what is limited by the mediator when it localizes behavior that would otherwise be distributed among several classes?subclassing
- 91list 3 consequences (not necessarily bad things) of the mediator pattern1) limits sub classing
2) promotes loose coupling between colleagues
3) many-to-many interactions become one-to-many interactions - 92what is the motivation for the strthe strategy pattern- allows many algorithms to be used interchangeably
- 93- hard wiring algorithms into a class is bad because:- different algorithms are useful at different times we don't want to support everything if we don't use the majority
- difficult to add and modify algorithms when code is integral part of a client - 94what is a "strategy" in terms of design patternsan object that is encapsulated by a defining class
- 95draw the structure diagram of the strategy design pattern, identify and define all participants
- 96when should the strategy design paptern be used?you want to choose which algorithm to use at run time
- 97what are the outcomes of the strategy pattern- context decided which strategy is best given current circumstance
- new algorithms can be added without modifying the context or client - 98what pattern is related to the mediator patternobserver
- 99what pattern is related to the strategy patternbridge (same UML diagram)
Información
- Descripción
- Engineering Fichas sobre Software R&A, creado por Yanick Houde el 25/10/2017.
- Creado por
- Yanick Houde
- Visitas
- 1
- Valoración