Reading...
Play button
Play button
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;
83 Cards in this Set
- Front
- Back
|
CH1 - Customized Products
|
Software that is commissioned by a specific customer to meet their own needs. The specification of what the software should do is owned by the customer.
Ex. Embedded control systems, air traffic control software, traffic monitoring systems. |
|
|
CH1 - Generic Products
|
Stand-alone systems that are marketed and sold to any customer who wishes to buy them. The specification of what the software should do is owned by the software developer.
Ex. CAD, Graphics programs, etc. |
|
|
CH1 - What is software?
|
Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.
|
|
|
CH1 - What are attributes of good software?
|
Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.
|
|
|
CH1 - What is software engineering?
|
Software engineering is an engineering discipline that is concerned with all aspects of software production.
|
|
|
CH1 - What are the fundamental software engineering activities?
|
Software specification, software development, software validation and software evolution.
|
|
|
CH1 - What is the difference between software engineering & computer science?
|
Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.
|
|
|
CH1 - What is the difference between software engineering and system engineering?
|
System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.
|
|
|
CH1 - What are the key challenges facing software engineering?
|
Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software.
|
|
|
CH1 - What is maintainability in terms of a product characteristic?
|
Software should be written in a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment.
|
|
|
CH1 - What is dependability & security in terms of a product characteristic?
|
Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to acces or damage the system.
|
|
|
CH1 - What is efficiency in terms of a product characteristic?
|
Software should not make wasteful use of system resources such as memory or processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation, etc.
|
|
|
CH1 - What is acceptability in terms of a product characteristic?
|
Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other system that they use.
|
|
|
L1 - Incremental Development
|
An approach to software development where the software is delivered and deployed in increments.
|
|
|
L2 - What are some specifications of a software?
|
Code.
|
|
|
L2 - What are some specifications of a software product?
|
1. Code
2. Generalization 3. Documentation 4. Configuration Files 5. Proof of Validation 6. Etc. |
|
|
L2 - What are some specifications of a software system?
|
1. Multiple programs
2. Interfaces 3. System Integration |
|
|
L2 - Systems engineering is a usually a linear process, rather than cyclic. Why?
|
It is difficult to change hardware and policy once created.
|
|
|
L2 - What are some examples of emergent system properties?
|
Volume (memory, HDD space, how does it scale)
Reliability (depends on hardware, software, operators) Security (vulnerable to attack? who has access?) Repairability (Is replacement of components easy?) Usability (depends heavily on documentation) Speed (depends on underlying hardware components) Robustness (reacts well to unanticipated use) Transparency (how rapidly can non-authors learn to change code) Extendability (how easy to add new functionality) |
|
|
L2 - Systems Engineering
|
A process that is concerned with specifying a system, integrating its components and testing that the system meets its requirements.
System engineering is concerned with the whole sociotechnical system - software, hardware, and operational processes - not just the system software. |
|
|
L2 - Software System:
How would we standardize interfaces between components? |
Template interfaces, examples interfaces, documentation.
|
|
|
L2 - Emergent Property
|
A property that only becomes apparent once all of the components of the system have been integrated to create the system.
|
|
|
L2 - Sociotechnical Systems
|
A system, including hardware and software components, that has defined operational processes followed by human operators and which operates within an organization. It is therefore influenced by organizational policies, procedures, and structures.
|
|
|
L2 - The software product:
How would you go about generalizing home-built code? |
Having someone else try it out, compiling on another OS...
|
|
|
L2 - Why are software systems so hard to implement?
|
Interfaces and testing scale exponentially with the number of components.
Refer to slide 19 in Lecture 2 powerpoint for diagram |
|
|
L2 - The software product:
What makes it more difficult than simple code |
Applied in unanticipated situations, proving safety,...
|
|
|
L2 - The software product:
What additional material could be supplied with a software product? |
Web sites, instructional videos, advertisements, upgrade guarantees,...
|
|
|
L3 - Software Process
|
The related set of activities and processes that is involved in developing and evolving a software system.
S - Specification D - Development V - Verification/Validation E - Evolution |
|
|
L3 - Component-Based Software Engineering (CBSE)
|
Summary: Use of standardized reusable building blocks (products).
The development of software by compromising independent, deployable software components that are consistent with a component model. |
|
|
L3 - Iterative Development
|
Summary: Bidirectional movement in the development process.
An approach to software development where the processes of specification, design, programming, and testing are interleaved. |
|
|
L3 - Linear Development
|
Summary: One-way progress from client needs to finished product.
|
|
|
L3 - Waterfall Model
|
A software process model that involves discrete development stages: specification, design, implementation, testing, & maintenance.
In principle, one stage must be complete before progress to the next stage is possible. In practice, there is significant iteration between stages. |
|
|
L3 - The Waterfall Method:
To which phase would you focus the most time and effort on if you were developing software to indicate whether an x-ray shows a tumor or not? |
Testing; software must never give a false negative.
|
|
|
L3 - Evolutionary Development
|
Specification, development and validation are carried out in parallel. Expose the client to many versions and incorporate their feedback.
|
|
|
L3 - The Waterfall Method:
To which phase would you focus the most time and effort on if you were developing software for a client known to change their minds often? |
2 answers:
1. Requirements definition, to force them to commit early? 2. Operation and maintenance. |
|
|
L3 - Complex Systems
|
1. Have interactions at many levels
2. Results in emergent behavior: behavior at one level emerges from behaviors at other levels |
|
|
L3 - Incremental Delivery
|
1. Not as structured as the waterfall method.
2. More structured than evolutionary development. 3. Focus on priorities: identify what functionality the client needs first. (What systems functionalities supports this user functionality) |
|
|
L3 - The Waterfall Method:
To which phase would you focus the most time and effort on if you were developing software composed of commercial off-the-shelf programs? |
Integration and system testing, to make sure the components work well together.
|
|
|
L3 - Where might you use throwaway prototyping?
|
Products where you need very specific requirements.
|
|
|
L3 - Managing Complexity
|
1. Iterate tightly and often (ITO)
-"All programmers are optimists" -Fred Brooks -Always have functioning code on hand -Fits with both top-down and bottom-up design |
|
|
L3 - Where might you use exploratory development?
|
2 answers:
1. New technology: difficult to know a priori what a software can make it do. 2. Products for a competitive market: can you make software do something new? |
|
|
L3 - What are some pros and cons of evolutionary development?
|
Pro: Useful when the client does not know what they want.
Pro: Parallelization allows maximization of labor-power. Con: No visible deliverables (except software versions) Con: Software poorly structured. |
|
|
L3 - Exploratory Development
|
(Sub-class of Evolutionary Development)
Used to design and develop a computer system or product and basically consists of planning and trying different designs until one of them seems to be the right one to develop. This model works best in situations where few, or none, of the system or product requirements are known in detail ahead of time. This model is largely based on educated guesswork. |
|
|
L3 - Throwaway Prototyping
|
(Sub-class of Evolutionary Development)
The creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system. |
|
|
L3 - Imagine you are a team leader in a production house using incremental delivery.
What would you develop first in software to indicate whether an x-ray shows a tumor or not? |
The ability to detect obvious tumors; more false positives than false negatives.
|
|
|
L3 - The Waterfall Method:
To which phase would you focus the most time and effort on if you were developing a new OS? |
2 answers:
1. Operation and maintenance, as new applications change user demands on the OS. 2. System design, to ensure that the OS is modular, and can be changed later. |
|
|
L3 - What are some pros and cons of incremental delivery?
|
Pro: Clients do not have to wait for entire system before use.
Pro: Experience with early prototypes informs future increments. Pro: Low risk of overall project failure. Pro: Most important components receive the most testing. Con: Hard to map requirements onto separate increments. Con: Hard to identify common facilities (e.g. event scheduler) needed by all increments. |
|
|
L3 - Imagine you are a team leader in a production house using incremental delivery.
What would you develop first in an online travel booking system? |
An engaging user interface; must keep the client on the site.
|
|
|
L3 - Imagine you are a team leader in a production house using incremental delivery.
What would you develop first in a new OS? |
3 answers:
1. Unique feature(s). 2. Backwards-compatibility; ability to run older programs. 3. Light use of system resources; must handle compatibility-heavy apps. |
|
|
L3 - Imagine you are a team leader in a production house using incremental delivery.
What would you develop first in real-time, physical simulation software? |
3 answers:
1. A graphical front-end. 2. The ability to run in real-time; interact with the user in real time. 3. Physical realism. |
|
|
L3 - Imagine you are a team leader in a production house using incremental delivery.
What would you develop first in a product for an international market? |
Documentation and GUIs in the required languages; plug-and-play databases.
|
|
|
L3 - What are some pros and cons of CBSE?
|
Pro: Fast delivery; cheap (less in-house development); backwards compatibility.
Con: Desired functionality must be compromised. Con: Potentially expensive: software must be purchased. |
|
|
L4 - What are some example interface specifications?
|
Amount and type of data passed between components; will communication be uni- or bidirectional?
|
|
|
L4 - Examples of component/data structure/algorithm specifications?
|
Use an off-the-shelf relational database; do a parallel, threaded implementation.
|
|
|
L4 - The most common cause of failure in software development is running over time (running out of time)!
Why? |
(From MMM, pg. 12-25)
1. Estimation for development is difficult and often poorly done. 2. Managers erroneously equate effort with progress: more effort must mean more progress! 3. Managers hesitant to tell clients, or their managers, that things will take more time. 4. Schedule progress is poorly monitored. 5. When slippage is recognized, manpower is added. |
|
|
L4 - The Mythical Man-Month (Person-month, PM)
|
A way to measure effort. The person-month is the amount of code one person can produce in a month.
|
|
|
L4 - How can we measure progress?
|
1. Lines of code written.
2. Lines of verified code. 3. Modules completed. |
|
|
L4 - What does it mean when a job is not partitionable?
|
Product is a single component. Thus communication costs are low.
|
|
|
L4 - What does it mean when a job is perfectly partitionable?
|
One person, one job ; No communication costs are incurred.
|
|
|
L4 - What does it mean when a job is partly partitionable?
|
There are multiple components, so some communication is required. Thus communication costs are higher.
|
|
|
L4 - Brook's Law
|
"Adding manpower to a late software project makes it later."
Communication costs increase exponentially as more team members are added to a project. |
|
|
L5 - What are some pros and cons of spiral development?
|
Pro: Clearly defined phases.
Pro: Risks are minimized. Pro: Developers get used to a rhythm. Con: Time consuming; many anticipated risky scenarios do not happen. Con: Lots of bureaucratic overhead. |
|
|
L5 - Spiral Model
|
A model of a development process where the process is represented as a spiral, with each round of the spiral incorporating the different stages in the process. As you move from one round of the spiral to another, you repeat all of the stages of the process.
4 Sub-activities: O - Objective Setting R - Risk Assessment & Reduction D - Development & Validation P - Planning |
|
|
L5 - Risk Management
|
The process of identifying risks, assessing their their severity, planning measures to put in place if the risks arise, and monitoring the software and the software process for risks.
|
|
|
L5 - Imagine you are a team leader in a production house using spiral development. What would you identify as risks, and how would you handle them in rocket controller software?
|
Run-time errors.
Handled by extensive testing, as realistic as possible (flight tests). |
|
|
L5 - Imagine you are a team leader in a production house using spiral development. What would you identify as risks, and how would you handle them in software built by an international team?
|
2 answers:
1. Confusion over metric vs. U.S. measurements. Handled by setting guidelines for reporting measurements. 2. Team intercommunication. Handled by offering technical communication seminars. |
|
|
L5 - Imagine you are a team leader in a production house using spiral development. What would you identify as risks, and how would you handle them in a new enrollment system for UVM?
|
2 answers:
1. Compromise of secure information. Handled by adopting special development processes for the software that deals with security. 2. Lack of scalability. Handled by extensive stress testing. |
|
|
L6 - Scrum
|
An agile method of development, which is based on sprints - short development, cycles. Scrum may be used as a basis for agile project management alongside other agile methods such as XP.
|
|
|
L6 - Agile Project Management
|
A group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
|
|
|
L6 - Agile Methods
|
Methods of software development that are geared to rapid software delivery. The software is developed and delivered in increments, and process documentation and bureaucracy are minimized.
The focus of development is on the code itself, rather than supporting documents. |
|
|
L6 - Plan-driven Development
|
A more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation.
|
|
|
L6 - Scaling Agile Methods
|
1. Bottom line: it's difficult to apply agile method to the development of large systems.
-large systems have long develop time cycles -and many (often competing) stakeholders -and often consist of seperate subsystems, with seperate teams 2. Agile methods work best when: -the organization is willing to take risks -the organization isn't too top-heavy or bureaucratic -team members work very well together and have a high skill level |
|
|
L6 - Pair Programming
|
(Component of XP)
A development situation where programmers work in paris, rather than individually, to develop code; a fundamental part of extreme programming. |
|
|
L6 - Rapid Application Development (RAD)
|
An approach to software development aimed at rapid delivery of the software. It often involves the use of database programming and development support tools such as screen and report generators.
|
|
|
L6 - Extreme Programming (XP)
|
A widely used agile method of software development that includes practices such as scenario-based requirements, test-first development, and pair programming.
|
|
|
L7 - Requirements Engineering
|
The process of coming up with crisp, clear, unambiguous, documented, measurable requirements.
-finding out what the requirements are -documenting the requirements -analyzing the requirements -checking the requirements (for consistency, feasibility, etc.) |
|
|
L7 - Requirements
|
Requirements are a description of what the system should do:
-the services it provides -the constraints on its operation The hard part: Requirements for a system are often vague; for example: -"the system should provide quick responses for clients." -"the system should provide query responses in an easy-to-read format." -"the system should be easy to use by all users." -"the Watson system should be able to win Jeopardy." |
|
|
L7 - Functional Requirements
|
1. Specific services that the system provides.
2. How the system responds to inputs. 3. How the system behaves. 4. Can usually be tied to a specific part of the software (a specific module or function). |
|
|
L7 - Non-Functional Requirements
|
1. Constraints on the system.
2. Often, requirements that apply to the system as a whole. 3. Often tied to emergent system properties. 4. Arise from aspects of general system architecture or infrastructure (think of "security" or "usability"). |
|
|
L7 - Requirements elicitation and analysis
|
look up
|
|
|
L7 - Requirements Management
|
For a large system that evolves, new requirements come up:
-how do the new requirements fit in with the old requirements? -users change, and new users might have new requirements. -the marketplace changes. -the legal/regulatory environment can change (eg. SSN as student ID#) |
|
|
L7 - What are the 3 sub-requirements of non-functional requirements?
|
1. Product Requirements
-specify general product behavior and tolerable ranges 2. Organizational Requirements -from company policy -delivery requirements -implementation requirements -standards requirements 3. External Requirements -from factors external to the system and its development process -interoperability requirements -ethical requirements -legislative requirements |
|
|
L3 - What are the steps in the Waterfall Process?
|
1. Specification
2. Design 3. Implementation 4. Testing 5. Maintenance |
