Soen 341 - Quiz 1

Front 1

What are the main four software activities?

Back 1

- Specification
- Development
- Validation
- Evolution

Front 2

Describe the six part Requirement/Specification flowchart.

Back 2

1<->2<->3 and 1->a, 2->b,3->c

Where
1=Requirement elicitation and analysis (with a. System Description)
2=Requirement Specification (with b. User and system requirements)
3=Requirements validation (with c. Requirement Document)

Front 3

Define the two steps in the requirements/specification stage:

Back 3

1. Software elements analysis: Extract the requirements. The customer typically knows what he wants, but does not know which software should do it. Demonstrating live code may help reduce the risk that the requirements are incorrect.
2. Scope analysis: Certain functionalities may be out of the scope of development because it is too costly, or because the requirements are unclear.

Front 4

What is specification?

Back 4

It is the task of precisely describing the software to be written.

Front 5

What are the four major types of design?

Back 5

- Architectural design
- Component design
- Persistence design
- Interface design

Front 6

Describe the flowchart of Validation/Testing.

Back 6

(1) <-> Component testing -> System Testing -> Customer testing -> (1)

Front 7

Describe the flowchart for Evolution/Maintenance.

Back 7

Define requirements -> System Assessment (1) -> Propose system changes -> modify system -> New System
Existing System -> (1)

Front 8

Define Software specification/development/validation/evolution.

Back 8

- Specification: What should the software system do?
o Define the software that is to be produced and the constraints on its operation
- Development: How can the specification be realized?
o Software is designed and programmed
- Validation: Try to break your software system
o Software is checked to ensure that it is what the customer requires
- Evolution: Reacting to changing market conditions
o Software is modified to reflect changing customer and market requirements

Front 9

Describe the Software Crisis of the late 1960’s

Back 9

- In the late 1960s, many large projects ran behind schedule, over budget and below specifications.
- The software was very inefficient, and was of low quality.
- Projects were unmanageable and code was difficult to maintain.
- Software was never delivered.

Front 10

Define Software Engineering.

Back 10

Engineering discipline that is concerned with all aspects of software production, from the early stages of system specification through to maintaining the system after it has gone into use.

Front 11

Define the Engineering discipline.

Back 11

Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints.

Front 12

What are the four Fundamentals of Software Engineering Development?

Back 12

1. Systems should be developed using a managed and understood development process.
2. Dependability and performance are important for all types of systems.
3. Understanding and managing the software specifications and requirements is important.
4. Where appropriate, you should reuse software that has already been developed rather than write new software.

Front 13

Describe the three types of testing:

Back 13

- Component testing
o Done by the person who writes the code
- System testing:
o Feature testing and performance testing
o System testing
o Regression testing
- Customer testing
o Acceptance testing
o Field testing

Front 14

Vaguely describe what Evolution/Maintenance consist of:

Back 14

- Maintaining and enhancing software to cope with new requirements or newly discovered problems.
- A small part is fixing bugs.
- A large part is extending systems to do new things.

Front 15

What are some of the other Software Development activities other than the main four ones?

Back 15

- Coding
- Deployment
- Documentation
- Software Training and support

Front 16

What is the Code-And-Fix model? What are some of its issues?

Back 16

It is a basic model used in the earliest days of software development which contained two steps:

1. Write some code.
2. Fix the problems in the code

- After many fixes, the code became very poorly structured causing the subsequent fixes to be very expensive.
- After the design phase was implemented, it was discovered that in many cases the programs didn’t match the users’ needs and so it was either rejected or had to be redeveloped, which was expensive

Front 17

What was the idea behind the waterfall model? What drives the waterfall model?

Back 17

- The original idea behind this model was that one should move to a phase only when its preceding phase is completed and perfected.
- The phases of development are discrete and there is no jumping back and forth between them.
- This model is document driven. Every step yields documents which are needed for the next step (and possibly later steps).
o Ex. The requirements document will be needed in the testing phase.

Front 18

Why is it that managers would like the Waterfall model?

Back 18

- Managers like the waterfall model because progress is observable and measurable.
o The transitions between steps become project milestones that indicate progress made.
o Documents are tangible evidence of progress.
- Using this model, we can estimate the cost by adding the estimated costs of each phase, and then adding a safety factor.
o NOTE: This can be problematic because we may not have enough information during the early phases to make accurate predictions about the effort needed, causing the later phases to be more expensive.

Front 19

State three reasons why the Waterfall model is a poor model:

Back 19

- It is based on classical engineering practice. Building something physical is not the same as developing software.
- Documents reflect what readers want to hear rather than what is actually happening.
- Late-changing requirements require a lot of rework.

Front 20

State three reasons why the classical model doesn’t work for software engr.:

Back 20

- Software development is not a well understood process.
- Scientific foundations are lacking.
- Software requirements change.

Front 21

Describe the Prototype model:

Back 21

Front 22

What is the workflow like in the spiral model?

Back 22

- The spiral model is risk-driven. It allows the model to accommodate any appropriate mixture of specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approaches to software development.
- Each phase starts with a design goal and ends with the client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye towards the end goal of the project.
- The spiral model combines the features of the prototyping model and the waterfall model. It is intended for large, expensive and complicated projects.
- The steps are iterated until the customer is satisfied.

Front 23

How does one create a new prototype in the spiral model?

Back 23

A new prototype is created by:
- Evaluating the previous prototype in terms of its strengths, weaknesses and risks.
- Defining the requirements for the new prototype.
- Planning and designing the new prototype.
- Constructing and testing the new prototype.

Front 24

What happens when the risk is deemed to great in the spiral model? What are some of the risk factors?

Back 24

If the risk is deemed too great, the customer can choose to abort the entire project.

Risk factors may involve:
- Development cost overruns
- Operating-cost miscalculations
- Any other factor that could, in the customer’s opinion, result in an unsatisfactory final product.
-
Once the customer is satisfied, the final system is constructed and thoroughly evaluated and tested.

Front 25

Advantages of Incremental development?

Back 25

Advantages:
- There is a working system at all times which clients can see and provide feedback on.
- Progress is visible
- Certain types of errors can be avoided

Front 26

Pros and Cons of Incremental Development are:

Back 26

Pros:
- The cost of changing the customer requirements is reduced.
- It is easier to get customer feedback.
- Customers are able to use and gain value from the software early.
Cons:
- It is hard for large organizations to adopt
- An architecture that is flexible tends to degrade quickly
- Clients want to change requirements

Front 27

What are the concerns one can have with making errors in Incremental Developmet?

Back 27

- A process model must recognize the possibility of errors and provide ways of correcting them.
- Errors made in early development tend to be more serious (more expensive to fix) than errors made later.
- However, there is a good chance that a requirements error will be recognized as soon as the corresponding software is incorporated into the system.

Front 28

Describe Plan-Driven Development:

Back 28

- Based around separate development stages with the outputs to be produced at each of these stages planned in advance.
- Incremental development is possible.
- Iteration occurs within activities.
- Everything is planned in advance.

Front 29

Why does plan-driven Development not work?

Back 29

- Software is a part of most business operations. As such, new software is developed at a quick pace in order to take advantage of new opportunities and to respond to the competitive pressure.
- It is almost impossible to derive complete set of stable software requirements.
- When a requirement change is made, the design, coding and testing need to be redone

Front 30

Agile, what is agile development? Explain interactions, working software and how we respond to changes in Agile.

Back 30

Agile Development
- In agile development, specification, design and implementation are inter-leaved.
- The system is developed as a series of versions or increments, with stakeholders involved in version specification and evaluation.
- There is frequent delivery of new versions.
- There is minimal documentation.
- Planning is incremental and easy to change.
- Most processes include elements of both plan-driven and agile approaches
.
Individuals and Interactions
- Face-to-face communication is the most effective method of communication for conveying information. This applies to both inter and intra team communication.

Working Software
- Working software is the primary measure of progress.
- The top priority is customer satisfaction. This is achieved through early and continuous delivery of software.
- Simplicity is essential

Responding to Changes
- Changing requirements are welcomed, even late in development.
- There is continuous attention to technical details. • The team regularly reflects on how to become more effective.

Front 31

Explain the five principles of Agile Methods:

Back 31

- Customer involvement:
o Customers should be closely involved throughout the development process. Their role is to provide and prioritize new system requirements, as well as to evaluate the iterations of the system.
- Incremental delivery:
o The software is developed in increments with the consumer specifying the requirements to be included in each increment.
- People not process:
o Team members should be recognized and allowed to develop in their own way, without prescriptive processes.
- Embrace change:
o Expect the system requirements to change, and so design the system to accommodate these changes.
- Maintain simplicity:
o Focus on simplicity in both the software being developed and in the development process. Actively work to eliminate complexity from the system.

Front 32

Define Extreme Programming:

Back 32

Extreme programming (XP) takes an ‘extreme’ approach to iterative development.
- New versions may be built several times per day.
- Increments are delivered to customers every two weeks.
- All tests must be run for every build and the build is only accepted if tests run successfully.

Front 33

Explain the Extreme Programming Practice of Incremental planning

Back 33

- Requirements are recorded on story cards. The stories to be included in a release are determined by the time available and their relative priority.
- Developers break these stories into tasks.

Front 34

Explain the Extreme Programming Practice of Small Releases

Back 34

Releases of the system are frequent and incrementally add functionality to the first release

Front 35

Explain the Extreme Programming Practice of Simple Design

Back 35

Enough design is carried out to meet the current requirements and no more.

Front 36

Explain the Extreme Programming Practice of Test-first development

Back 36

An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Front 37

Explain the Extreme Programming Practice of Refactoring

Back 37

All developers are expected to refactor the code as soon as code improvements are found. This keeps the code simple and maintainable.

Front 38

Explain the Extreme Programming Practice of Pair Programming

Back 38

Developers work in pairs, checking each other’s work and providing each other support.

Front 39

Explain the Extreme Programming Practice of Collective Ownership

Back 39

The pairs of developers work on all areas of the system. All the developers take responsibility for all of the code. Anyone can change anything

Front 40

Explain the Extreme Programming Practice of Continuous integration

Back 40

As soon as the work on a task is complete, it I integrated into the whole system. After any such integration, all the unit tests in the system must pass.

Front 41

Explain the Extreme Programming Practice of Sustainable pace

Back 41

A large amount of overtime is unacceptable.

Front 42

Explain the Extreme Programming Practice of on-site customer

Back 42

A representative of the end-user of the system should be available full time for the use of the XP team. The customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

Front 43

What is Test-Driven Development?

Back 43

- All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.
- The customer should be writing the tests with the developers to ensure that the end product is what they desire

Front 44

What are the cons of test-driven development?

Back 44

Cons of test-first development:
- Some tests can be very difficult to write incrementally.
- It is difficult to judge the completeness of a set of tests. The tests may not provide complete coverage.

Front 45

What is pair programming?

Back 45

Programmers sit together at the same computer to develop the software.

Front 46

Development of software requires a structure and organization that will :

Back 46

1. use the resources of the developer efficiently
2. ensure that the product meets the requirements of the client in terms of: Function, Performance and Reliability

Front 47

Describe Agile Project Management

Back 47

- The principal responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project.
- Project management is typically plan driven. The plan details what should be delivered, when it should be delivered and who will work on the development of the project deliverables.
- Agile project management, however, is different.

Front 48

What is Scrum and what are its three phases?

Back 48

Scrum is an agile method that focuses on managing iterative development rather than specific agile practices.
The three phases are:
- Outline planning and architectural Design
- Assess, Select, Develop, Review (repeat)
- Project Closure

Front 49

In Scrum terminology, what is a Development team

Back 49

Group of software developers (no more than 7 people). They are responsible for developing the software and other essential documents.

Front 50

In Scrum terminology, what is Potentially shippable product increment

Back 50

The software development that is delivered from a sprint. No further work (such as testing) is required.

Front 51

In Scrum terminology, what is a product backlog

Back 51

A list of to do items which the Scrum team must tackle.

Front 52

In Scrum terminology, what is a Product owner

Back 52

An individual whose job is to identify product features or requirements, prioritize these for development and continuously review the product backlog to ensure that the project continues to meet critical business needs.

Front 53

In Scrum terminology, what is Scrum

Back 53

Daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day. This is a short, face-to-face meeting that includes the whole team.

Front 54

In Scrum terminology, what is a Scrum Master

Back 54

- The Scrum master is responsible for ensuring that the scrum process is followed and guides the team in the effective use of Scrum.
- The Scrum master communicates with the necessary people outside of the team. The Scrum master protects the development team form external distractions.

Front 55

In Scrum terminology, what is a Sprint

Back 55

A development iteration. Sprints are usually 2-4 weeks long.

Front 56

In Scrum terminology, what is Velocity

Back 56

An estimate of how much product backlog effort that a team can cover in a single sprint.

Front 57

State four benefits of Scrum:

Back 57

- The product is broken down into a set o manageable and understandable chunks.
- Unstable requirements do not hold up progress.
- The whole team has visibility of everything and consequently team communication is improved.
- Customers see on-time delivery of increments and gain feedback on how the product works.