Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
81 Cards in this Set
- Front
- Back
|
Waterfall Lifecycle |
1.Feasibility 2. Analysis 3. Design 4. Build 5 Test 6. Implement -This is still #1 solution used today. -Easy to control -Very slow -Difficult to manage scope because so long and business can change before project complete
|
|
|
Prototype Lifecycle (Incremental) |
This evolved as a result of long lifecycle of Waterfall 1. Little Analysis and design 2. Build limited functionality 3. Working Software - This process repeats until the end result is the desired functionality
|
|
|
Spiral Lifecycle (Incremental) |
Each iteration involves 6 steps 1. Determine objectives, alternatives and constraints 2. Identify and resolve risks 3. Evaluate alternatives 4. Develop deliverables for that iteration, and verify that they are correct, and that we got the benefits 5. plan the next iteration 6. Commit to an approach for the next iteration |
|
|
Spiral continued |
Benefits 1. Incremental coverage of lifecycle 2. Fast partial delivery 3. "Potentially" uncontrolled evolution 4. User input for functional requirements 5. What is "working"? 6. "Potentially" controlled evolution over time |
|
|
Rational Unified Process (RUP) Lifecycle (Incremental) |
Very difficult to manage - workflows and phases are mixed together. Workflows 1. Business Modeling 2. Requirements 3. Analysis & Design 4. Implementation 5. Test 6. Deployment
Phases 1. Inception 2. Elaboration 3. Construction 4. Transition
|
|
|
Agile Approaches |
-(XP) eXtreme Programming -(AUP) Agile Unified Process -Scrum -Crystal -(FDD) Feature-Driven Development -(DSD) Dynamic Systems Development -(ASD) Adalptive Software Development -(TDD) Test-Driven Development -(LSD) Lean Software Development |
|
|
Things about Agile |
-Direct result of disgust with heavy world -No requirements gathering -Gets solutions out quicker -Agile uses graphical techniques from UML -Agile says code and solution is the code |
|
|
Agile Development |
Themes -Systems are best developed in small increments -Users and developers have to work hand-in-hand -Each system increment should be designed to handle the minimum requirements -When changes in requirements occur, they should be designed in. -There should be little or no documentation beyond code |
|
|
The Agile Approach |
1. The planning game: user stories (scope) & developers (estimates) 2. Small releases: value business requirement 3. Metaphor: replaces "architecture" 4. Simple design: all tests, not duplicate logic, states every intention, has fewest classes 5. Testing: design test before coding & promote coverage 6. Refactoring: constant redesign 7. Pair programming: one can pickup or modify the work of the other 8. Collective ownership: the group owns the central product 9. Continuous integration: no long, deliverate life cycles 10. 40 hour-week: development is a marathon 11. On-site customer: customer must sit with the team 12. Coding standards: code follows very strict guidelines
|
|
|
Scrum (Most Popular) |
-A management framework for incremental software development using one or more cross-functional, self-organizing teams of about 7; responsible for creating their processes within this framework -A structure of roles, meetings, rules, and artifacts -Fixed-length iterations (sprints) which are typically 2 to 4 weeks; each iteration builds a shippable product each iteration |
|
|
Scrum Role - Product Owner |
1. Single person responsible for maximizing ROI 2. Sets product vision 3. Re-priortizes the Product Backlog 4. Final arbiter of requirements 5. Accepts/rejects each product increment 6. Decides whether to ship 7. Decides whether to continue development 8. Considers stakeholders interest 9. May contribute as a team member 10. Has a leadership role |
|
|
Scrum Role - Development Team |
1. Cross-functional 2. Self-organizing/self-managing 3. Negotiates commitments 4. Has autonomy regarding how to reach commitments 5. Intensely collaborative 6. Co-located 7. Long-term, full-time membership 8. 7 plus/minus 2 members 9. Has a leadership role |
|
|
Scrum Role - ScrumMaster |
1. Facilitates the Scrum process 2. Helps remove impediments 3. Creates an environment for team self-organization 4. Capture empirical data for forecasts 5. Shield the team from interference and distractions 6. Enforces timeboxes (time spent on meeting or task) 7. Keep Scrum artifacts visible 8. Promotes engineering principles 9. Has no management authority 10. Has a leadership role |
|
|
Scrum Artifacts |
Product Backlog -Ranked list of desire functionality -items at top are more granular than items at bottom
Product Backlog item -Specifies the what -Often written in User Story form -Product-wide definition -Effort is estimated by the team -Roughly 2-3 people 2-3 days or smaller |
|
|
Scrum Artifacts |
*Sprint Backlog -Committed PBIs negotiated between the team and Product owner during the Sprint Planning Meeting -Scope commitment is fixed during Sprint Execution -Referenced during the Daily Scrum Meeting
*Sprint Task -How to achieve the PBI's what -Requires one day or less of work -Remaining effort is re-estimated daily, in hours -Owned by the team; collaboration is expected |
|
|
Scrum Artifacts |
*Sprint Burndown Chart -Indicates total remaining team task hours within one Sprint -Re-estimated daily & may go up and down -Promotes team self-organization -Discouraged if it becomes an impediment (such as a management report) |
|
|
Scrum Framework |
*Sprint Planning Meeting *Daily Scrum (Stand up) *Sprint Review Meeting *Sprint Retrospective Meeting |
|
|
Sprint Planning Meeting |
-At beginning of Sprint -Negotiate Product Backlog items -Determine amount of work to implement -Create an initial list of Sprint tasks |
|
|
Daily Scrum (Stand up) |
Might lead to Backlog refinement meeting -During a Sprint -Prepare product Backlog for next Sprint planning meeting -Estimate effort to complete items -Formulate technical information for priorities |
|
|
Daily Scrum (Stand up) |
(If no Backlog Refinement Meeting) -Every day for 15 minutes -Each team member, what was done previous day, what will be done today & what impediments exists -Maintain a current Sprint Task List, a Sprint Burn Down Chart (remaining work in Sprint Backlog) and an impediments list -Product owner attendance |
|
|
Sprint Review Meeting |
May lead to Backlog Refinement Meeting, if not -After a Sprint Demonstrate a working product increment to Product Owner -Live demonstration -Product Owner review -Declaration of what is done/not done -Review of Product Backlog for prioritization |
|
|
Sprint Retrospective Meeting |
-At the end of a Sprint -Team reflection on its own processes -Actions to adapt to future Sprints |
|
|
RDBMS vs OO |
* RDBMS (relational data base model) -IBM's DB2, Oracle 11g, Informix, Microsoft's Sequel Server, MySQL, and Access (desktop) -Separated application from the data Promotes program independence from data -Manages data as a "repository" -Minimizes redundancy -Most frequently used today |
|
|
RDBMS vs. OO |
*OO -Rational -Encapsulates method with data -Promotes reuse -Promotes component based construction -Manages object as a "repository" -Not widely used today because most of the applications are not OO |
|
|
IIBA International Institute of Business Analysis |
* An independent non-profit professional association serving the growing field of business analysis -Business analysis, systems analysis, requirements analysis or management, project management, consulting, process improvement *Established in in 2003 as Canadian Corp *Has become the leading association for business analysis around the World *Published the IIBA's Business Analysis Body of Knowledge Version 2.0 (BABOK 2)
|
|
|
Business Analysis |
The set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable organizations to achieve its goals |
|
|
Business Analysis Body of Knowledge |
*Intended to describe and define business analysis as a discipline, rather than define the responsibilities of a person with that job title of business analyst -Systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant *Solution -Meets the business need, by solving problems or facilitating an opportunity - - Subdivided into components including the information systems that support it, the processes that manage it, and the people who operate it |
|
|
Analyst |
*IT BA role: -Provide guidance to stakeholders on devising effective and efficient approaches to achieve the project objectives -Identify and resolve issues -Manage the risks -Liaise with other project areas to coordinate interdependencies and resolve issues -Liaise with various business units to gather requirements and resolve issues -Improve business processes -Gather and define business requirements -Analyze and map processes (current state/future state) -Analyze data -Produce high quality documentation - artifacts -Report status and issues to the Project Manager(s) -Contribute to enterprise architecture development from a business needs point of view
|
|
|
Requirement |
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents 3. A documented representation of a condition or capability as in 1. or 2. 4. May be unstated, implied by other requirements, or directly stated or managed. |
|
|
Six BABOK v.2 Knowledge Areas |
1. Business Analysis Planning and Monitoring 2. Enterprise Analysis 3. Elicitation 4. Requirements Analysis 5. Solution Assessment and Validation 6. Requirements Management and Communication |
|
|
Business Analysis Planning and Monitoring |
- Conduct Stakeholder Analysis - Plan Business Analysis Activities - Plan Business Analysis Communication - Plan Requirements Management Process - Plan, Monitor and Report on Business Analysis Performance |
|
|
Enterprise Analysis |
- Identify Business Need - Determine solution Approach - Define Solution Scope - Develop the Business Case |
|
|
Elicitation |
- Prepare for Elicitation - Conduct Elicitation - Document Elicitation Results - Confirm Elicitation Results |
|
|
Requirements Analysis |
- Organize Requirements - Prioritize Requirements - Specify and Model Requirements - Determine Assumptions and Constraints - Verify Requirements - Validate Requirements |
|
|
Solution Assessment and Validation Tasks |
- Assess Requirement coverage - Allocate Requirements - Determine Organizational Readiness - Validate Solution - Evaluate Solution |
|
|
Requirements Management and Communication |
- Manage Solution and Requirements Scope - Manage Requirements Traceability - Manage Requirements for RE-use - Prepare Requirements Package - Communicate Requirements |
|
|
Steps of B.O.O.M. (Business Object Oriented Modeling. Most SDLC look like this |
|
|
|
Initiation |
Starts with an idea in someone's head all the way to a BRD, which is started in this step. Identify and analyze the business requirements for the project, and state the main reason for doing the project |
|
|
Discovery |
Conduct investigation leading to an understanding of the solutions desired behavior.
|
|
|
Construction |
Complete the analysis and design, code, integrate, and test the software. |
|
|
Final Verification and Validation (V&V) |
Perform final testing before product or service is transitioned into production. |
|
|
Closeout |
Manage and coordinate development into production and close the IT project |
|
|
Creating a ball-park estimate |
|
|
|
Business Requirements Document (BRD) |
Make an early draft and revise it as project continues keeping baseline copies as you go to keep track of scope. This describes business requirements
|
|
|
Business Requirements |
- can be at work or personal, for profit or non-profit - Product or service-based |
|
|
Requirements Definition Description: Geting an accurate and complete description of what the businesss wants the system to do |
Tips for Success:
|
|
|
Requirements Management Description: Managing the user requirements and any changes throughout the life project life cycle |
Tips for success:
|
|
|
Requirement Challenges |
|
|
|
Requirements Management |
|
|
|
The role of an IT BA |
To represent the business stakeholders to the development community |
|
|
Main duties of the IT BA |
To discover and communicate requirements to the developers and to support testing |
|
|
A Business Model |
A collection of diagrams and supporting text that describes business rules and requirements |
|
|
The International Institute for Business Analysis (IIBA) is a professional body that offers a professional BA Certification and whose publication, the Businiss Analysis Body of Knowledge (BABOK), defines knowledge areas (KAs) relavant to the practice of business analysis |
lsdjflkd |
|
|
OO |
OO is an acronym for "object oriented." The OO analyst sees a system as a set of objects that collaborate by sending requests to each other. |
|
|
OO is a complete conceptual framework that covers the entire lifecycle of an IT project |
-OO affects the way the BA analyzes and models the requirements. -OO affects the way the software engineer (technical systems analyst) designs the system specifications -OO affects the way the code itself is structured. |
|
|
OMG Object Management Group |
UML is a widely accepted standard incorporating OO concepts first developed by the "Three Amigos" Booch, Rumbaugh, Jacobson, and now owned by OMG. |
|
|
Use case |
The specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system. |
|
|
Use Case Documentation (diagrams and/or text) |
Should describe the series of steps that take place during the interaction and include different ways that this interaction could play out. |
|
|
object |
is a particular "thing" that plays a role in the system and/or that the system tracks - for example, the customer Jane Dell Ray. An object has attributes and operations associated with it. The object is the basic unit of an OO system. |
|
|
Attribute |
is a data element of an object |
|
|
Operation |
a service that a class of objects can carry out |
|
|
Method |
is the process used to carry out an operation |
|
|
Message |
A signal from one object to another that requests the receiving object to carry out one of its operations. |
|
|
Encapsulation |
is an OO principle stating that everything about an object - its operations and properties - is contained within the object. No other object may refer directly to another's attributes or rely on a knowledge of how its operations are carried out. |
|
|
Class |
is a category of object. Objects of the same class share the same attributes and methods. |
|
|
Subclass |
A class that is a special case of another class |
|
|
Instance |
A term used to refer to an object that belongs to a particular class. |
|
|
Class hierarchy |
A tree structure representing the relationships among a set of classes. Class hierarchies always have at least top node (which may be the object class), but may have any number of levels in the tree and any number of class at each level |
|
|
Inheritance |
A mechanism whereby classes can make use of the operations and variables defined in all classes above them on their branch of the class hierarchy |
|
|
Polymorphism |
Ability to hide different implementations behind a common interface, simplifying communications among objects. Defining a unique display operation for each screen in a system would alllow any screen to be displayed by sending the message display, without concern for how that operation was actually carried out for a given screen. |
|
|
Entity class |
is something that business keeps information about, for example Customer |
|
|
Relationship |
is a connection between classes.
|
|
|
Generalization |
OO property that models partial similarities among objects, or commonalities.
|
|
|
Association |
An association between classes indicates a link between its objects - for example, an Account object and its Customer owner |
|
|
Aggregation |
a relationship between a whole and its parts |
|
|
Composite Aggregation |
a specific form of aggregation wherein the parts have no existence independent of the whole. |
|
|
Polymorphism |
An OO concept allowing one operation name to stand for different procedures that achieve the same end. The class of the acting object determines which action is selected. |
|
|
Use Case |
a typical interaction between the user and system that achieves a useful result for the user |
|
|
Business Use Case |
is a business process |
|
|
System Use Case |
Typical interaction with an IT system |
|
|
UML |
Unified Modeling Languate is a widely accepted standard for modeling business and IT systems that incorporates OO concepts |
