All lessons Flashcards Preview

CS6300 - Software Development Process > All lessons > Flashcards

Flashcards in All lessons Deck (37)
Loading flashcards...
1

What is software engineering?

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

Why do we need software engineering?

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

How was the software engineering discipline born?

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

Various software processes

  • 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

Software process

  1. 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
  2. Design
    • High-level structure, that can become more detailed, of our software system
  3. Implementation
    • Write code that implements the design that we just defined
  4. Verification/Validation
    • Make sure the code behaves as intended
  5. Maintenance
    • Adding new functionality, eliminating bugs, responding to problems reported from the field after it's released

6

Automated tools are ______ in software engineering.

FUNDAMENTAL

Not only for productivity. Not only efficiency, but also effectiveness

7

Software development mistakes

  • 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

8

What is an IDE?

A software application that supports software developers and has many useful features

 

Tools are the cornerstone of the software engr. discipline

9

Requirements Engineering

  • 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

What is object-oriented programming?

  • 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

What is software architecture?

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

Cohesion

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

REST

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

Software Design: how to analyze requirements with a client (AKA stakeholder)

  1. Have them write out the requirements (numbered list)
  2. Go through the req’s and underline the nouns, and write them as classes in a class diagram
  3. Then analyze the diagram you just created to see if you can eliminate/combine
  4. Then go back to the requirements list and look for things that may not have been obvious the first time
  5. Start adding attributes when it makes sense, and walk the client through what they mean
  6. Finally, work on operations (starting by underlining verbs in req’s)
    • Verbs that clearly express an action
  7. Do all of this in UML
  8. 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.
  9. 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

Software design patterns

  • 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

5 main classes of design patterns

  1. Fundamental
  2. Creational
    • Support object creation
  3. Structural
    • Help compose objects/put them together
  4. Behavioral
    • Realizing interactions among different objects
  5. Concurrency
    • Support concurrency aspects

17

Failure vs Fault vs Error

  • 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

4 mainstream approaches of software verification

1. Testing (dynamic verification) - most popular/most used in industry

2. Static verification

3. Inspections

4. 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

What can testing prove?

It canNOT prove the absense of errors. it can only verify their presence.

Testing granularity levels include unit, integration, system, acceptance, and regression.

20

Black-box testing

  • based on description of the software (specification)
  • cover as much specified behavior as possible
  • cannot reveal errors due to implementation details

21

White-box testing

  • based on the code
  • cover as much coded behavior as possible
  • cannot reveal errors due to missing paths

22

Random testing

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:
  1. Identify partitions
  2. Select inputs from each partition
  • By doing these 2 things, we can dramatically increase our chances of finding faults in the code

23

Boundary values

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

Category-Partition Method

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:

  1. Identify independently testable features
  2. Identify categories (this is key)
  3. Partition categories into choices (this is also key)
  4. Identify constraints among choices
  5. Produce/evaluate test case specifications
  6. 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)

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