1
Q
What is software engineering?
A
A computer is a programmable device, so the essence of computing is programming. Program development is the most essential use of a computer. Software engineering is the study of program development. How to do it efficiently, develop reliable programs, etc. Considers any software development activity software engineering.
the systematic application of methods to build software in a rigorous way. It involves technically building the system but also understanding requirements, working with stakeholders, finding a solution that balances stakeholder’s needs
2
Q
Why do we need software engineering?
A
Software is everywhere around us, to the point that the way we build and maintain our software effects our quality of life.
It can make the difference between a fun product and something the user hates, a successful company and a failed company, and in some examples life and death.
Example of a system that wasn’t engineered correctly: healthcare.gov (somewhere between requirements, architecture, politics, project management went wrong).
3
Q
How was the software engineering discipline born?
A
In the 60s, people realized they weren’t able to build the software they needed, resulting in the SOFTWARE CRISIS.
Software Crisis:
1 - Rising demand for software (moving from HW to SW in our products)
The demand for software at companies (NASA, Boeing) grew exponentially between 60s and 2000
2 - Effort required for larger systems doesn’t increase linearly:
Programming effort = individual could (heroically) do it right themselves, Software engineering = team
Developer tools will never catch up with increased complexity in demand
3 - Developer’s productivity growth: developer’s abilities can’t keep up with what’s needed in terms of size/complexity:
Gap between what’s needed and what’s available
4
Q
Various software processes
A
- Waterfall
- Go from 1 phase to the other in the same way water follows the flow in a waterfall
- Evolutionary Prototyping
- Start with a prototype, and evolve it based on feedback from the customer
- RUP/USP (Rational Unified Process/Unified Software Process)
- Heavily based on use of UML
- Agile
- Sacrifice the discipline a little bit to be more flexible and account for changes in requirements
5
Q
Software process
A
- Requirements engineering (implies business modeling beforehand)
- Talk to customer, stakeholders, whoever we’re building SW for, to understand what kind of system we’re trying to build
- Design
- High-level structure, that can become more detailed, of our software system
- Implementation
- Write code that implements the design that we just defined
- Verification/Validation
- Make sure the code behaves as intended
- Maintenance
- Adding new functionality, eliminating bugs, responding to problems reported from the field after it’s released
6
Q
Automated tools are ______ in software engineering.
A
FUNDAMENTAL
Not only for productivity. Not only efficiency, but also effectiveness
7
Q
Software development mistakes
A
- People-related
- Heroics
- Work environment
- People management
- Process-related
- Scheduling issues
- Planning issues
- Failures (low quality, lost deliverables)
- Product-related
- Gold-plating requirements
- Feature creep
- R != D
- If your project requires you to develop new algorithms, it’s more research than development, and therefore it should be managed accordingly (you’ll have a highly unpredictable schedule)
- Technology-related
- Silver bullet syndrome:
- situations in which there’s too much reliance on some previously unused technology
- Switching tools in the middle of a product: almost always has negative effects due to learning curves
- Lack of an automated VCS
- Silver bullet syndrome:
8
Q
What is an IDE?
A
A software application that supports software developers and has many useful features
Tools are the cornerstone of the software engr. discipline
9
Q
Requirements Engineering
A
- The process of establishing the services that the customer requires from the software system
- Also details with the constraints under which the system operates
- Important because:
- Many errors are made in Req Specifications
- Many are not detected early. Key is to detect them in RE.
10
Q
What is object-oriented programming?
A
- OO means to give precedence of data over function
- Data items rather than functionality become the center of development activities
- Allows for enforcing the very important concept of information hiding:
- Encapsulation and segregation of data behind well-defined and (ideally) stable interfaces
- Encapsulation and information hiding terms are often used interchangeably, although some people prefer to think of IH as being the principle and encapsulation being the technique to achieve it. The key idea is to hide data behind a wall and only give access through interfaces that you, the developer, define.
- Makes code more maintainable, because other code doesn’t have to be concerned about the “How” for an object, just that it works.
- Also allows for reuse of object definitions with incremental refinements, called inheritance.
- An object is a computing unit organized around a collection of state or instance variables that define the state of the object
11
Q
What is software architecture?
A
The set of principal design decisions about the system
- Most decisions don’t affect the system (e.g. choosing a for loop instead of while loop). The principal decisions, however, do
- Sometimes, distinctions between these 2 types of decisions is clear. Other times, it’s fuzzy. Bottom line is that if you believe something is an important design decision, that becomes an architectural decision
- SWA is like a blueprint for a SW system. Encompasses every facet of the system:
- structure
- behavior
- interactions
- non-functional properties
12
Q
Cohesion
A
measure of how strongly related the elements of a model are. We want modules to cooperate to provide a specific piece of functionality
Low coupling = high cohesion
13
Q
REST
A
Representational State Transfer
- hybrid arch style for distributed hypermedia systems, that is derived from several other network-based architectural styles, and that is characterized by uniform connector interface
- Extremely well-known, very widely-used, because it is basically the architectural style that covers the world wide web
14
Q
Software Design: how to analyze requirements with a client (AKA stakeholder)
A
- Have them write out the requirements (numbered list)
- Go through the req’s and underline the nouns, and write them as classes in a class diagram
- Then analyze the diagram you just created to see if you can eliminate/combine
- Then go back to the requirements list and look for things that may not have been obvious the first time
- Start adding attributes when it makes sense, and walk the client through what they mean
- Finally, work on operations (starting by underlining verbs in req’s)
- Verbs that clearly express an action
- Do all of this in UML
- At the end, when the diagram is done, encourage the client that they’re doing well, and ask them to think of anything they want to add or that needs to be changed. They should be able to do this now that the UML has been sketched out and they understand it.
- Debriefing: Ask what the client thought of it, whether they think it was useful, and if maybe they learned something about their own system (things they knew but never explicitly wrote down). This kind of analysis/exercise can help them figure out if there’s any kind of issues in their requirements.
15
Q
Software design patterns
A
- It can be difficult to come up with an effective design for a system. Design patterns can help by providing general reusable solutions to common recurring design problems
- Similar to architectural designs, design patterns can help developers build better designed systems by refusing design systems that worked well in the past and building on those solutions
16
Q
5 main classes of design patterns
A
- Fundamental
- Creational
- Support object creation
- Structural
- Help compose objects/put them together
- Behavioral
- Realizing interactions among different objects
- Concurrency
- Support concurrency aspects
17
Q
Failure vs Fault vs Error
A
- Failure: Observable incorrect behavior of SW. it is conceptually related to the behavior of the program rather than its code
- Fault: AKA bug: incorrect piece of code. It is related to the code and is a necessary, but not sufficient condition for the occcurrance of a failure
- Error: cause of a fault usually a human error, can be conceptual, a type-o, or something else
- This is the official IEEE terminology, so you can’t go wrong if you use it
18
Q
4 mainstream approaches of software verification
A
- Testing (dynamic verification) - most popular/most used in industry
- Static verification
- Inspections
- Formal proofs of correctness
Today, QA is mostly testing. Bill Gates: “50% of my company employees are testers, and the rest spends 50% of their time testing”
19
Q
What can testing prove?
A
It canNOT prove the absense of errors. it can only verify their presence.
Testing granularity levels include unit, integration, system, acceptance, and regression.
20
Q
Black-box testing
A
- based on description of the software (specification)
- cover as much specified behavior as possible
- cannot reveal errors due to implementation details
21
Q
White-box testing
A
- based on the code
- cover as much coded behavior as possible
- cannot reveal errors due to missing paths
22
Q
Random testing
A
Advantages:
- Pick units uniformly
- All inputs considered equal
- Eliminates designer bias (making the same assumption as when we read the specification as when we write the test cases)
- Developer might write code assuming the behavior of the user, and we might write tests making the same assumptions
- Problem is even worse if it’s the same person that develops the code and writes the tests
Problems:
- You’re unlikely to find problems. Bugs are like multiple needles in multiple haystacks. Searching randomly won’t be effective.
Instead, use Partition testing:
- The input domain is naturally split into partitions. Partitions are areas of the domain that are treated homogeneously by the software. Normally, failures tend to be dense in certain partitions.
- So, rather than picking inputs randomly from the entire domain, we want to:
- Identify partitions
- Select inputs from each partition
- By doing these 2 things, we can dramatically increase our chances of finding faults in the code
23
Q
Boundary values
A
errors tend to occur at the boundary of a (sub) domain, because they are values that are less understood by developers (e.g. last iteration of a loop, the input 0, etc.)
So, we want to select inputs at these boundaries
- This is complementary to partition testing
- Partition testing identifies the partitions in which we want to select inputs; and boundary testing will help select inputs in these partitions
24
Q
Category-Partition Method
A
It is a method of black-box testing for going from the specification (description of the system) to a set of test cases (like any other black box testing approach) by following 6 steps:
- Identify independently testable features
- Identify categories (this is key)
- Partition categories into choices (this is also key)
- Identify constraints among choices
- Produce/evaluate test case specifications
- Generate test cases from test case specifications
Categories are characteristics of each input element. For example, variable str has categories length and content. It’s somewhat subjective in general. Then within each of those, you try to find boundary values.
25
MC/DC
Modified Condition Decision Coverage (a type of branch and condition coverage)
## Footnote
MC/DC is stronger than branch and condition coverage because it considers every possible combination that changes the outcome and therefore subsumes B&C coverage, and therefore subsumes all the others. Extend branch and decision coverage with the requirement that each condition should affect the decision outcome independently
26
Characteristics of white-box testing
* Works on a formal model
* Comparable
* Two broad classes:
* Practical
* Theoretical
* Fully automatable
27
In general, Agile aims at
flat cost and at decreasing traditional overhead by following a set of important principles:
* Focus on the code (rather than design) to avoid unnecessary changes
* People over process
* Value people and reward them
* Iterative approach
* Deliver working software quickly and be able to evolve it just as quickly based on feedback. Feedback can come from many sources. Main source is the customer, who should be involved throughout the process.
* Customer involvement
* Expectation that requirements will change
* Simplicity - simple design, simple code, and so on.
* Simple does not mean inadequate, but rather as simple as possible.
Small releases, very often.
Test-driven development.
Simple design, just enough to meet requirements early on.
Pair programming
Continuous integration
28
Scrum Intro
Very popular process these days
* Similar to XP, is another Agile development process
* Scrum actors (3 main kinds):
* Product owner (customer): responsible for the product backlog (list of things to do). That is analogous to the user stories to be realized in XP
* Clearly express the backlog items and order them by priority value.
* Team: responsible for delivering shippable increments, is usually self organized, consists of 4-9 people, and can be thought of as the main development team in a project
* Scrum master: responsible for the overall scrum process
* Remove obstacles, organize events,
* Supervisor/manager
29
Scrum process
* Product backlog
* Single source of requirements for the process
* Ordered by value, risk, priority, and necessity to determine which to consider for the next iteration
* Living list (items can be added or removed). Defined by the product owner.
* Sprint planning
* Next sprint is defined
* Backlog items of interest are selected based on characteristics above, converted into tasks, and estimated
* Sprint backlog
* Set of backlog items that will be completed during the next sprint
* Sprint (2-4 week loop in drawing)
* Actual iteration of the Scrum process
* Within this main part there are many daily scrums which last 24 hours
* Daily scrum
* Usually characterized by 15 minute meeting of the team at the beginning of the day
* Discussion of accomplishments since the last meeting
* To-do list before the next meeting
* Obstacle analysis - discuss any issues - and possible solutions are proposed
* Sprint review and retrospective
* At the end of the 2-4 week cycle
* Sprint review: usually consists of a 4-hour meeting
* Product owner assesses the accomplishments over the specific sprint
* Team discusses issues that were encountered and solved
* Typically a demo of the deliverable for that sprint
* Product owner will discuss the backlogs
* Together, with the team, decide what to do next
* Retrospective
* More focus on the process
* The goal of this part of the meeting is possible process improvements
* Identify improvements, and if good improvements are identified, try to plan how to implement them and use them in the next iterations
* Potentially shippable product increment
* If good enough, release will not just be internal, but can also be deployed and used in production
30
What is refactoring?
the process of taking a program and transforming it, making it better (easier to understand, more maintainable, and in general improve its design) but with the same functionality as the original program
Goals are:
* Keep program readable, understandable, and maintainable.
* Avoid small problems soon so you can avoid big trouble later
31
Why refactor?
* Requirements change (and therefore we need to change our design)
* Design needs to be improved (even if requirements haven’t changed)
* e.g. need to add a new feature, need to make code more maintainable
* In general, programmers don’t come up with the best design the first time, so they may need to adapt it after the fact
* Sloppiness/laziness of programmers
* e.g. copy/paste programming (from another part of the program) and we end up with repeated code throughout project
* Create a method or class that provides the functionality
* Even something as simple as renaming a class is refactoring
* Increasingly popular with Agile development (more lightweight methodologies = easier more suited for refactoring)
32
Refactoring and OO languages
Especially important for object-oriented languages
Probably bc OO langs are designed to be flexible and reusable
Easy ways to do encapsulation, information hiding, etc. Easier to refactor without changing the functionality
However, refactoring is NOT specific to OO languages
33
Types of refactoring (there are a lot)
See attachment:
34
Risks of refactoring
You may introduce small regression failures
35
Costs of refactoring
* in some cases where IDE provides refactoring tools, it’s almost free
* In many cases though, it involves quite a bit of manual work
* Another cost is test development and maintenance (test cases that specifically test your refactoring) or even existing test cases might need to be updated (maintenance)
* Documentation maintenance
* Refactoring might involve changes in interfaces, names (of classes for example, and you’ll have to update documentation
36
When NOT to refactor
* When code is broken
* If code is a mess AND doesn’t work, it’s probably better to throw it away and rewrite it
* Refactoring does NOT fix broken code, because as we know it preserves the behavior of the system
* When a deadline is close
* It can take a while
* It can introduce problems
* When there is no reason to
* Only refactor when you see a problem with the design/structure of your code
* If the code is fine, there’s no reason to refactor
37
Bad smells
Bad Smells are usually not bugs and don’t prevent the program from functioning. They however indicate weaknesses in the design of the system that might cause problems during maintenance. They make it less maintainable, harder to understand, etc.
Examples:
* Duplicated code
* Common in copy/paste programming
* Use the extract method, and make a call to the method in call the places where the code is duplicated
* This simplifies the code and favors reuse because there could be more places in the future that benefit from the new method
* Long method
* The longer a procedure, the more difficult it is to understand it and maintain it
* Use extract method or decompose conditional. Basically, break down he method into smaller, more cohesive methods
* Large class
* Contains too many fields, too many methods, is too complex to understand
* Use extract class (or subclass) to break it down into multiple classes, each one with a more cohesive piece of functionality
* Shotgun surgery
* Everytime you make a change to the system, you have to make many little changes
* This is a symptom of the fact that the functionality is spread among different classes (too much coupling between the classes and not enough cohesion within the classes)
* Use move method/field, inline class to bring the pieces of functionality back together
* reduces dependencies on other classes, so classes can stand on their own and be more usable
* Feature envyMethod that seems more interested in a class other than the one it belongs to
* For example, it’s using a lot of public fields from another class, calling a lot of methods from another class,
* Use extract method, followed by the move method, so as to take the jealous method out of the class where it doesn’t belong, and put it in the class where it really belongs
* This decreases coupling between the 2 classes and improves your system
CS6300 - Software Development Process
flashcards
Decks in class (1)
# Cards
