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;
117 Cards in this Set
- Front
- Back
|
What are the three elements of software? From lecture 1. |
• Instructions - computer programs that, when executed, provide desired features, function, and performance. • Data Structures - enable programs to manipulate information. • Documentation - describes the operation and use of the program. |
|
|
What is software engineering concerned with regarding the development of quality software to help solve problems? (3 elements). From lecture 1. |
• Theories • Methods • Tools |
|
|
Why is software engineering important? (3 aspects). From lecture 1. |
• The economies of all developed nations are dependent on software. • More and more systems are software controlled. • Software engineering expenditures represents a significant fraction of GNP in all developed countries. |
|
|
What is the difference between software engineering and computer science? From lecture 1. |
• Computer science is concerned with theory and fundamentals. • Software engineering is concerned with using computer theory,languages etc. to implement a solution to a problem. |
|
|
What is the essence of practice? (4 aspects) From lecture 1. |
• Understand the problem. - communication and analysis • Plan a solution. - modeling and software design • Carry out the plan. - code generation • Examine the results for accuracy. - testing and quality assurance |
|
|
What are Hooker's 7 general principles? From lecture 1. |
1.) The reason it all exists. 2.) KISS (keep it simple, stupid) 3.) Maintain the vision. 4.) What you produce, others will consume. 5.) Be open to the future. 6.) Plan ahead and reuse. 7.) Think. |
|
|
What is a software process? From lecture 2. |
A structured set of activities required to develop a software system. |
|
|
What do all software processes involve? (4 elements). From lecture 2. |
• Specification - defining what the system should do. • Design and implementation - defining the organization of thesystem and implement the system. • Validation - checking that it does what the customer wants. • Evolution - changing the system in response to changing customerneeds. |
|
|
What are plan-driven processes? From lecture 2. |
Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
|
|
|
What are agile processes? From lecture 2. |
In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. |
|
|
Which process is the best one? From lecture 2. |
• In practice, most practical processes include elements of both plan-driven and agile approaches. • There are no right or wrong software processes. |
|
|
What is a software process model? (3 elements) From lecture 2. |
• An abstract representation of a software process. • Presents a description of a process from some particular perspective. • General approach for organizing a project into activities.
|
|
|
What is the approach when there is no process model? From lecture 2. |
Opportunistic approach. |
|
|
Describe when the opportunistic approach is and is not acceptable. From lecture 2. |
• OK for small, informal projects. • Inappropriate for complex software. • Inappropriate for professional environments where on-time delivery and high quality are expected |
|
|
What are the cons of the opportunistic approach? From lecture 2. |
• Requirements and design not worked out before implementation. • The design of software deteriorates faster if it is not well designed. • Since there are no plans, there is nothing to aim towards. • No explicit recognition of the need for systematic testing. • The above problems make the cost of developing and maintaining software very high. |
|
|
What are 3 generic software models? From lecture 2. |
• Waterfall model. • Incremental development. • Reuse-orientated software engineering. |
|
|
In practice, which generic model are most large systems developed by? From lecture 2. |
In practice, most large systems are developed using a process that incorporates elements from all of these models. |
|
|
What is the downside to using the waterfall model? From lecture 2. |
It is difficult to accommodate change after the process is underway. |
|
|
When should you use the waterfall method? From lecture 2. |
The waterfall method is appropriate when the requirements are well-understood and changes will be fairly limited during the design process. |
|
|
When is the waterfall model used? From lecture 2. |
The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. |
|
|
What are 3 benefits of using incremental development? From lecture 2. |
• The cost of accommodating changing customer requirements is reduced. • It is easier to get customer feedback on the development work that has been done. • More rapid delivery and deployment of useful software to the customer is possible. |
|
|
What are 2 problems with using incremental development? From lecture 2. |
• The process is not visible. • System structure tends to degrade as new increments are added. |
|
|
What are two benefits to using reuse-orientated software engineering? From lecture 2. |
• Reduce the amount of software to be developed, and the cost. • Faster delivery of software. |
|
|
What is a problem with using reuse-orientated software engineering? From lecture 2. |
Requirement compromises. |
|
|
What are the 4 stages for the software life cycle? From lecture 4. |
• Inception • Pre-development • Development • Post-development |
|
|
What do business changes lead to? From lecture 4. |
Business changes lead to new and changed system requirements. |
|
|
What do new technologies open up? From lecture 4. |
New technologies open up new possibilities for improving implementations. |
|
|
What does changing platforms require? From lecture 4. |
Changing platforms requires application changes. |
|
|
Does the cost of change progressively get higher or lower? From lecture 4. |
Higher. |
|
|
What can you do to avoid making changes? From lecture 4. |
Prototype. |
|
|
Which process should you implement in order to tolerate changes? From lecture 4. |
Incremental development. |
|
|
What is a prototype? From lecture 4. |
A prototype is an initial version of a system used to demonstrate concepts and try out design options. |
|
|
A prototype can be used in... (two aspects). From lecture 4. |
• The requirements engineering process to help with requirements elicitation and validation. • In design processes to explore options and develop a UI design. |
|
|
What are 5 benefits of prototyping? From lecture 4. |
•Improved system usability. • A closer match to users’ real needs. • Improved design quality. • Improved maintainability. • Reduced development effort. |
|
|
What are the two types of prototyping? From lecture 4. |
• Evolutionary prototyping. • Throw-away prototyping. |
|
|
Describe evolutionary prototyping. From lecture 4. |
Evolutionary prototyping is an approach to system development where an initial prototype is produced and refined through a number of stages to the final system. |
|
|
Describe throw-away prototyping. From lecture 4. |
Throw-away prototyping is a prototype which is usually a practical implementation of the system which is produced to help discover requirements problems and then discarded. The system is then developed using some other development process. |
|
|
Describe incremental development. From lecture 4. |
• Develop the system in increments and evaluate each increment before proceeding to the development of the next increment. • Normal approach used in agile methods. •Evaluation done by user/customer proxy. |
|
|
Describe incremental delivery. From lecture 4. |
•Deploy an increment for use by end-users. •More realistic evaluation about practical use of software. •Difficult to implement for replacement systems as increments have less functionality than the system being replaced. |
|
|
What are 4 advantages of incremental delivery? From lecture 4. |
•Customer value can be delivered with each increment so system functionality is available earlier. •Early increments act as a prototype to help elicit requirements for later increments. •Lower risk of overall project failure. •The highest priority system services tend to receive the most testing. |
|
|
What are 2 problems with incremental delivery? From lecture 4. |
•Most systems require a set of basic facilities that are used by different parts of the system. - It can be hard to identify common facilities that are needed by all increments. •The essence of iterative processes is that the specification is developed in conjunction with the software. |
|
|
What is the strength of the spiral model? From lecture 4. |
Risks are explicitly assessed and resolved throughout the process. |
|
|
What are the 4 stages of the spiral model? From lecture 4. |
• Objective setting. - Specific objectives for the phase are identified. • Risk assessment and reduction. - Risks are assessed and activities put in place to reduce the key risks. • Development and validation. - A development model for the system is chosen which can be any of the generic models. • Planning. - The project is reviewed and the next phase of the spiral is planned. |
|
|
What are the 2 iterative models? From lecture 5. |
• Rational unified process. • Agile. |
|
|
What are the 4 stages of the rational unified process? From lecture 5. |
• Inception • Elaboration • Construction • Transition - Deploy the system in its operating environment. |
|
|
In rational unified process iteration, what are the two workflows? From lecture 5. |
• Process workflows. • Supporting workflows. |
|
|
What are some process workflows? From lecture 5. |
•Business Modeling •Requirements •Analysis & Design •Implementation •Test •Deployment |
|
|
What are some supporting workflows. From lecture 5. |
• Configuration management • Management • Environment |
|
|
In rational unified process iteration, what are the 2 phases? From lecture 5. |
• In-phase iteration. • Cross-phase iteration. |
|
|
Describe the in-phase iteration. From lecture 5. |
Each phase is iterative with results developed incrementally. |
|
|
Describe the cross-phase iteration. From lecture 5. |
As shown by the loop in the rational unified model, the whole set of phases may be enacted incrementally. |
|
|
What are 3 good rational unified process practices? From lecture 5. |
•Develop software iteratively. - Develop highest priority increments first. •Manage requirements. - Document requirements and track changes. •Use component-based architectures. - Organize the system architecture as a set of reusable components. |
|
|
What is the most important requirement of software systems? From lecture 5. |
Rapid software development and delivery. |
|
|
What is the aim of agile methods? From lecture 5. |
To reduce overheads in software process and respond quickly to changing requirements without excessive rework. |
|
|
What is the agile manifesto? From lecture 5. |
• Individuals and interactions > processes and tools • Working software > comprehensive documentation • Customer collaboration > contract negotiation • Responding to change > following a plan |
|
|
What are some agile principles that distinguish agile practices from traditional software life cycles? From lecture 5. |
•Deliver early and often to satisfy customer •Welcome changing requirements •Face to face communication is the best •Measure progress against working software •Simplicity is essential |
|
|
When should you apply the agile method? From lecture 5. |
• When developing small to medium sized products. • When the customer will be involved and there lacks external rules and regulations. |
|
|
What are some problems with agile methods? From lecture 5. |
• Difficult to maintain customer interest. • Team members may not be suited with the intensity of agile methods. • Prioritizing changes can be difficult. • Contracts may be a problem. • Do not scale well to suit larger projects. |
|
|
What are 2 examples of widely used agile methods? From lecture 5. |
• Extreme programming (XP) • Scrum |
|
|
Describe extreme programming. From lecture 5. |
• Best-known and most widely used agile method. • Takes commonsense software engineering principles and practices them to extreme levels. |
|
|
What are some of the practices of extreme programming? From lecture 5. |
• Customer team members. • User stories as requirements. • Pair programming. • Test-driven development. • Collective ownership. • Continuous integration. |
|
|
Describe the extreme programming release cycle. From lecture 5. |
Continually loops from: select user story for this release, break down stories into tasks, plan release, develop/integrate/test software, release software, evaluate system, and back to selecting the next story. |
|
|
What are the 3 phases to the scrum method? From lecture 5. |
• Planning • Sprint cycles • Project closure |
|
|
What 3 questions does each team member answer during the daily scrum? From lecture 5. |
•What did I do yesterday that helped the development team meet the sprint goal? •What will I do today to help the development team meet the sprint goal? •Do I see any impediment that prevents me or the development team from meeting the sprint goal? |
|
|
Describe requirements engineering. From lecture 6. |
• The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. •The requirements themselves are the description of the system services and constraints. |
|
|
What are two types of requirements? From lecture 6. |
• User requirements • System requirements |
|
|
How are user requirements written and who are they written for? From lecture 6. |
• Statements in natural language plus diagrams. • Written for customers. |
|
|
How are system requirements written? From lecture 6. |
• Written as a structured document containing detailed descriptions of the system's functions, services, and operational constraints. • Define what should be implemented. |
|
|
What are some user requirements? From lecture 6. |
• Client managers • System end-users • Client engineers • Contractor managers • System architects |
|
|
What are some system requirements? From lecture 6. |
• System end-users • Client engineers • System architects • Software developers |
|
|
What are functional requirements? From lecture 6. |
Statements of services that the system should provide, how the system should react to particular inputs and how the system should behave in particular situations and may state what the system should not do. |
|
|
What are non-functional requirements? From lecture 6. |
Constraints on the services or functions offered by the system such as timing constraints, constrains on the development process, standards, etc. and often apply to the system as a whole rather than individual features or services. Non-functional requirements may be more critical than functional requirements. |
|
|
What 2 things should requirements be? From lecture 6. |
• Complete • Consistent |
|
|
What are two effects that non-functional requirement implementation may have? From lecture 6. |
• May affect overall architecture of a system. • A single non-functional requirement may generate a number of related functional requirements. |
|
|
What are some non-functional requirements? From lecture 6. |
•Product requirements. •Organizational requirements •External requirements •Security requirements •Ethical requirements •Development requirements • *And roughly a million others. (I made this up) |
|
|
What is a goal? From lecture 7. |
A general intention of the user such as ease of use. |
|
|
What is a verifiable non-functional requirement? From lecture 7. |
A statement using some measure that can be objectively tested. |
|
|
What are the 6 metrics for specifying non-functional requirements? From lecture 7. |
• Speed • Size • Ease of use • Reliability • Robustness • Portability |
|
|
What is and is not a software requirement specification (SRS)? From lecture 7. |
• The SRS is the official statement of what is required of the system developers, including both a definition of user requirements and a specification of the system requirements. • It is NOT a design document. Should state WHAT the system should do and not HOW. |
|
|
Who are some of the users of a requirements document? From lecture 7. |
•System customers •Managers •System engineers •System test engineers •System maintenance engineers |
|
|
What are some of the ways of writing a SRS? From lecture 7. |
• Natural language • Structured natural language • Design description languages • Graphical notations • Mathematical specifications |
|
|
What are some guidelines for writing requirements? From lecture 7. |
• Invent and consistently use a standard format. • Use language consistently. - "shall" for mandatory requirements - "should" for desirable requirements • Highlight key parts of the requirement. • Explain why a requirement is necessary. |
|
|
What is a structured specification? From lecture 7. |
An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. |
|
|
What is one of the downsides of a structured specification? From lecture 7. |
Can be too rigid for writing business model requirements. |
|
|
What are the aspects of a form-based specification? From lecture 7. |
• Define the function. • Describe the inputs & where they come from. • Describe the outputs & where they go. • Describe information needed for computation. • Describe the action to be taken. • Pre and post conditions. • Side effects of the function. |
|
|
What is a tabular specification used for and why is it useful? From lecture 7. |
• Used to supplement natural language. • Useful when defining a number of possible alternative courses of action. |
|
|
What is requirements engineering? From lecture 7. |
In practice, RE is an iterative activity in which these processes are interleaved. |
|
|
What are some generic activities common to all processes? From lecture 7. |
•Requirements elicitation •Requirements analysis •Requirements validation •Requirements management |
|
|
What are scenarios? From lecture 7. |
Scenarios are real-life examples of how a system can be used. |
|
|
What should scenarios include? From lecture 7. |
•description of the starting situation • description of the normal flow of events •description of what can go wrong •Information about other concurrent activities •description of the state when the scenario finishes |
|
|
What are use-cases and what do the do? From lectures 7 + 8. |
• Use-cases are a scenario based technique in the UML which describes actor/system interactions. • Formal representation of system & environmental interactions. • Use-cases are high-level graphical models supplemented by more detailed tabular descriptions. • Illustrates system user activities. |
|
|
What are some requirements validation techniques? From lecture 7. |
• Review the requirements manually.
• Prototyping. • Test-case generation. |
|
|
How do requirements evolve? From lecture 7. |
Initial understanding --> initial requirements --> changed understanding of problem --> changed requirements. |
|
|
What is system modeling? From lecture 8. |
• The process of developing abstract models of a system. • Each model representing a different view or perspective of the system • System modeling means representing a system with a graphical notation (which is now always based on UML) |
|
|
What are graphical models used for? From lecture 8. |
• To facilitate discussion about existing or purposed systems. • To document an existing system. • As a detailed system description, used to generate a system implementation. |
|
|
What are the 4 types of system perspectives? From lecture 8. |
• External - context, activity • Interactive - use-case, sequence • Structural - class, data • Behavioral - state, sequence |
|
|
What are context models used for? From lecture 8. |
Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. |
|
|
What is an actor? From lecture 8. |
A user or outside system that interacts with the system beingdesigned in order to obtain some value from that interaction |
|
|
What are the 4 steps in use-cases? From lecture 8. |
Step 1:Identify the actors. Step 2: Identify the use-case. Step 3: Communication Step 4: System boundary |
|
|
What are the 3 components of a use-case diagram? From lecture 8. |
• Actors • Use-cases • The communication between actors and use-cases. |
|
|
What are the 3 use-case relations? |
• Generalization • Include • Extend |
|
|
When do you use the use-case relation extend? From lecture 8. |
Extend is used when a use-case conditionally adds steps to anotherfirst class use-case. Example: • update patient info --> make appointment |
|
|
When do you use the use-case relation include? From lecture 8. |
Include is used to extract use-case fragments that are duplicated inmultiple use-cases. Example: • record availability --> manage schedule |
|
|
When do you use the use-case relation generalization? From lecture 8. |
When you have a subsystem (general) that consists of multiple components individually connecting to another component (specialized). Example: Patient system - generalized. New patient - specialized. Old patient - specialized. |
|
|
Example Exam 1 question. T/F: Use-case actors are always people, and they cannot be system devices. From lecture 9. |
False. Actors can be people, external systems, or hardware devices. |
|
|
Example Exam 1 question. Multiple choice: Which of the following should be included in an SRS document. A.) Class definition. B.) Methods and attributes of classes. C.) Activity Diagrams. D.) Project Scope. From lecture 9. |
D.) Project Scope. |
|
|
Example Exam 1 question. Multiple choice: Which of the following is NOT an objective of having a requirement specification? A.) Define set of software requirements that can be validated. B.) Describe customer requirements. C.) Develop an abbreviated solution for the problem.
D.) Establish basis for software design. From lecture 9. |
C.) Develop an abbreviated solution for the problem. An requirement specification addresses the WHAT and not the HOW. |
|
|
Example Exam 1 question. Short Answer: At what circumstances the waterfall model is suitable? From lecture 9. |
• When the requirements are well defined and well understood. •When changes are limited. |
|
|
What is an activity diagram? From lecture 9. |
• Provides a graphical representation of the flow of activities within a specific scenario. • Supplements the use-case. • Tells you WHAT happens, not WHO does it. |
|
|
What are the 2 perspectives in an activity diagram? From lecture 9. |
• Conceptual perspective. - An activity is some task needed to be completed by a human or computer. • Specification perspective. - An activity is a method in a class. |
|
|
What are the links between activities in an activity diagram called? From lecture 9. |
Triggers. |
|
|
In an activity diagram, what is the purpose of guards? From lecture 9. |
Guards determine which trigger is used. Comparable to the functionality of an if statement. |
|
|
How many triggers can occur at the same point in time?
From lecture 9. |
One. |
|
|
In an activity diagram, what symbol is used to describe nested decisions? From lecture 9. |
The decision diamond. |
|
|
What are synchronization bars used for? From lecture 9. |
Synchronization bars initiate concurrent sections in an activity diagram. |
|
|
How do swimlanes distinguish between particular classes, people, or departments? From lecture 9. |
Swimlanes use vertical dashed lines to separate the diagram into zones, each zone representing a particular class, person, or department. |
|
|
When to use and not use an activity diagram? From lecture 9. |
Use: • When representing multiple objects and their high-level interaction. • To show behavior that spans over multiple use-cases, describing the workflow of the overall process. Do not use: • to see how objects collaborate. • to describe how an object behaves over its lifetime. |
