1
Q
How was software designed traditionally?
A
- designed to run as standalone applications that run on desktops or simple client- server applications.
- applications were developed by software engineering teams
- applications were packaged and deployed to be installed at the customer sites
- applications were managed by the system administrators who are also IT professionals, in the customer organization.
2
Q
How is software used/designed now?
A
- most applications are being hosted in the cloud,
- are accessed by a client (mobile or browser-based) applications
- Software that is embedded in devices are also still common, but they also operate differently from traditional applications.
3
Q
What are some types of modern software applications?
A
- Hosted applications
- Mobile Applications
- Embedded applications
4
Q
How do hosted applications work?
A
- run on servers, that are managed by the developers themselves
- users access the application as software as a service (SAS) model.
- software may run on a dedicated set of servers owned by the service provider (e.g. Google, Facebook), or they may be hosted in third party cloud computing services such as Amazon.
5
Q
What are the benefits of a hosted application?
A
The level of control the application developers have; application developers can change the server software as they wish because this does not require sending updates to customers
6
Q
What are mobile applications?
A
These are programs that are installed on mobile devices.
7
Q
How do mobile applications work?
A
- generally access a remote server for data and business logic, while the application running on the user device provides the basic user interface.
- Users download and install such applications through an application store,
- application developers upload new versions of the software to a application store.
- developers have to comply with a some type of process to upload new versions of the software to the application store.
8
Q
What are embedded applications?
A
These are applications that run on electronics devices, such as wearables, automo- biles, and medical devices.
9
Q
How do embedded applications work?
A
- Traditionally: software was installed once and did not change during the lifetime of the device.
- Now: embedded software available modern devices can be updated through over-the- air (OTA) update capabilities, and therefore, today this type of software is also deployed and managed different from the traditional embedded software.
10
Q
Define formal software engineering
A
- The philosophy that we need to exercise control over all aspects of the project.
- are sometimes called the prescriptive processes because they prescribe what must be done in order to achieve project outcomes.
11
Q
Define Agile software engineering
A
- The philosophy that we need to primarily exercise control over the outcomes of a project and guarantee that what is developed satisfies the outcomes.
- sometimes called the reactive pro cesses because they react to the project circumstances.
12
Q
What activities or phases constitute a software project?
A
- Requirements engineering
- Systems/architectural design
- detailed design
- Implementation
- Integration
- Testing
- Delivery and release
- Maintenance
13
Q
Define requirements engineering
A
eliciting the requirements for the system, analysing and defining these requirements
using models, and validating the requirements.
14
Q
Define systems/architectural design
A
defining the sub-systems (or components) within the system, and the relationships between them.
15
Q
Define detailed design
A
defining the behaviour of the components to fulfil the functional requirements.
16
Q
Define Implementation
A
programming the detailed design in some language.
17
Q
Define Integration
A
integrating the programmed parts with respect to the architecture.
18
Q
Define Testing
A
running executable tests on the programs in an attempt to find faults. Testing can take several forms, includ- ing:
19
Q
What are the 4 main types of testing?
A
- unit testing
- Integration testing
- system testing
- acceptance testing
20
Q
Define unit testing
A
tests the behaviour of individual components against their design;
21
Q
Define Integration testing
A
tests the behaviour of the sub-systems of components against the design;
22
Q
Define system testing
A
tests the behaviour of the system as a whole against the requirements
23
Q
Define acceptance testing
A
Tests that the system as a whole against the expectations of the customer or user.
24
Q
Define Delivery and release
A
packaging the software in an accessible manner and with useful documentation.
25
Define Maintenance
modifying the software to fix faults or to provide new requirements — sometimes a new project life
cycle in its own right.
26
Is there a strict order in the phases that constitute a software project?
No. different SDLC models offer different orderings and rationales for these orderings.
(For example, while testing is performed on the implemented software, some lifecycle models specify that the test phase begins before implementation, as some test cases can be defined as soon as the software requirements specification is complete.)
27
How do we go about designing a process to meet a goal?
start with the lifecycle model and then add in any activities for special requirements.
(for example, if we require high reliability then we may begin with an iterative process, but add prototyping, random testing, and reliability measurement to the generic template, such as the modified iterative process model)
The next step is to think about each of the activities in turn and ask the following questions:
- What steps do we need to take to produce the outputs from the inputs?
- What techniques and tools can be applied?
28
What is an example of steps we can take to produce outputs from inputs?
we can break the requirements activity into elicitation, analysis, specification and validation activities.
29
What are the 2 main types of processes?
Generally, we can identify two types of processes: within phase and across phase processes. Much of the study of software engineering is in the processes, tools and techniques required to develop specific kinds of system.
30
What are examples of techniques and tools that can be applied when designing a process to meet a goal?
interviewing, brainstorming, and focus groups
31
Why do we need tools and techniques when designing a process to meet a goal?
because to produce the outputs for most software engineering phases we often require deep analysis (using the techniques) and the production of complicated outputs (using the tools).
Tools are also used to help automate the more mundane steps in the production of an output and to manage the flow of artifacts between different process activities.
32
What does the requirements phase take as inputs?
any sources of requirements including project briefs, stakeholder lists, concept documents, and documented knowledge of prior similar systems
33
What does the requirements phase output?
software requirements specification (SRS).
34
What is an SRS?
- software requirements specification
- usually delivered in the form of a requirements package — a combination of English language re- quirements, models, mockups, and prototypes
- are complicated artifacts because of the high number of interdependencies and the need for consistency across the entire package.
35
What does the design phase take as inputs?
a set of requirements — it does not have to be complete
36
What does the design phase output?
A design.
It may be an architectural design or a detailed design, and must be passed on to an implementation team who build the design.
37
What are architectural designs?
architectural designs specify the main parts of the system, how they are interconnected and how they collaborate to achieve the main goals of the system
38
What are detailed designs?
detailed designs specify what functions are present in a component and the function preconditions and postconditions
39
What artefacts does the waterfall method produce?
These are:
• The requirements package produced in the requirements phase;
• The software design produced in the design phase;
• The code base produced in the implementation phase; and
• The test plan, test cases and test reports produced in the testing phase.
40
What are these artefacts important to the waterfall method?
1. They allow developers to measure progress; and
| 2. They allow developers to evaluate quality.
41
What are benefits of the waterfall method?
1. provides good support for projects that are well understood and have clear goals
2. it provides a good model for estimating project costs and tracking progress.
42
How does the modified waterfall work?
allow phases to be revisited one or more times based on feedback from later phases. But when a phase is revisited it is completed in its entirety before going back down the waterfall.
Example:
an unforeseen technical constraint at the design stage may force additional investigation of the requirements. In this case the requirements phase would be revisited, completed and reviewed again before passing the modified requirements package to the design phase again.
43
What are the cons of the waterfall method?
1. does not take into account the technological and domain related risks that are often found in software projects
2. does not allow for the iterations that are often required as understanding of the problem domain evolves during the course of the project
3. For large and complex projects there is not enough feedback provided to the client and it may be months (or years) between commissioning a system and seeing some part of it working.
44
When would you use the waterfall method?
When the the outputs of any phase remain relatively stable throughout the project once they are completed.
45
When wouldn't you use the waterfall method?
Revisiting phases too often in a waterfall slows the project down and in situations where requirements are uncertain or where technology may change a different process is better suited.
46
Why do we have incremental and iterative models?
to deal with uncertainty and changing project environments
47
How does the incremental model work?
Incremental models divide the development into a fixed number of increments each involving a planning, require- ments, design, implementation and testing phases. Each increment may follow a mini-waterfall or may even follow
some other process.
The key requirement for each increment is that it develops a complete and usable subset of the system functionality that can be deployed and can be evaluated. Changes required by the evaluation forms part of the planning and requirements for the next iteration.
48
What are the pros of the incremental model?
1. offers more flexibility than a waterfall
| 2. reduces many of the risks of a changing environment
49
What are the cons of the incremental model?
process needs to well managed
50
What steps need to be taken to ensure that the incremental model is well managed?
1. The first planning and requirements phase needs to provide a detailed enough set of requirements so that at least a high level design for the system can be done and the functionality divided into increments.
2. A software architecture often (but not always) needs to be produced early in the process and used to integrate increments.
3. Each evaluation needs to be turned into a set of requirements for the next increment. If requirements are changing then we must also keep an accurate record of which requirements pertain to which increment.
4. Typically good configuration management procedures need to be put in place before commencing incremental development projects.
51
How do incremental models manage risk?
by aiming to release often and early in order to receive client and user feedback on the evolving product
52
What is the iterative process?
An iterative process is one in which the development is broken up into a number of iterations.
53
What is the purpose of each iteration in the iterative process?
1. Refining and improving the requirements, design and implementation of the system based on feedback from users and testing;
2. Adding new functionality to the evolving system.
54
How do iterative and incremental processes differ?
* Incremental development specifies that the process develops different parts of the system at different times or at different rates and then integrates them as they are completed.
* Iterative development is a reworking development strategy in which time is set aside to revise and improve parts of the system
Iterative processes manage the risk of changing and uncertain environments by also aiming to gain client and user feedback often and early. In the case of iterative models developers can refine the requirements, design and system at each iteration.
55
What is the spiral model?
- a type of iterative model
- each iteration has distinctive sequence of activities that are designed to manage risk.
- designed to provide opportunities for getting a better understanding of the problem domain throughout the project.
56
What are the prototyping phases in the spiral model used for?
- to understand requirements
- design alternatives
- to get client feedback early in the development process
57
What is the sequence of operations in the first iteration of the spiral model?
1. A prototype of the system is created to explore the system requirements and to explore system alternatives.
2. A concept of operations document is produced from the lessons learned from the prototype that specifies the characteristics of the system and sketches the processes by which it will be built.
3. A set of requirements for the system is produced using the prototype and the concept of operations, and an iteration plan is developed.
4. The design, implementation and testing of the functionality planned for the first spiral now follow.
58
Define concept of operations
concept of operations describes the characteristics of the proposed system from the viewpoint of a user of the that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders.
59
How does the spiral model differ from the incremental approach?
each iteration typically involves risk analysis, prototyping to determine the feasibility and desirability of various alternatives, and then design, coding and testing.
60
What are characteristics of the agile method?
* focus on the code rather than the more formal processes
* are based on an iterative approach to software development; and
* are intended to deliver working software quickly and to evolve the working software quickly to meet changing requirements.
61
What are the key principles of the agile process?
1. Customer involvement
2. Incremental delivery
3. People over process
4. Embrace change
5. Maintain simplicity
62
What is extreme programming?
It aims to bring people together and focus them on producing a quality piece of software.
- keeps iterations short — two weeks at most
- run all tests on every build and only accept a build if all test are passed.
XP uses a set of rules that are designed to respond to change.
63
What are the fundamentals/features of XP?
1. incremental planning - have story cards. Stories that make it into the release are determined by time & priority
2. small releases - most valuable thing to stakeholders is released first
3. simple design - just enough to meet requirements
4. test first development
5. re-factoring - keeps the code simple and maintainable
6. pair programming
7. Collective Ownership
8. Continuous Integration
9. Sustainable Pace
10. On-site Customer
64
What are the downsides of XP?
1. customer is required to provide a representative to the project in a full-time role. Many customers will object to giving up such a valuable resource without having seen prior benefits.
2. XP requires a lot of discipline. e.g. projects struggle to obtain a full-time customer representative, and developers fail to continuously re-factor and integrate their code.
Like formal processes, failure to correctly follow the prescribed process makes the process goals more difficult to achieve.
65
What type of methodology is SCRUM?
iterative and incremental
66
What are the similarities between SCRUM and XP?
Scrum is a more high-level project lifecycle and management process than XP,
Similarities:
- short development iterations, called Sprints
- being prepared to respond quickly to change.
67
How long are typical sprints?
two to four weeks
68
Who makes up the scrum team?
Product Owner, Scrum Master and the Development Team
69
Who is the product owner?
represents the customer/stake-holders. The product owner writes user requirements in the form of User Stories, which are added to a Product Backlog, and these requirements are prioritised.
70
What happens in the sprint planning event?
the team decides which requirements form the product backlog can be implemented in the sprint. This is recorded in the Sprint Backlog
71
What is the sprint backlog?
The list of requirements from the product backlog that will be added to the sprint. The sprint backlog cannot be changed by anyone during the sprint. The product backlog can be changed at any time.
72
What job does the scrum master do?
The Scrum master facilitates the sprint, and is responsible for product goals and deliverables. He/she is responsible for resolving any impediments the development team might face that could impact the sprint, and also ensures that the Scrum framework is followed.
73
What is the daily SCRUM?
During a sprint, the team holds daily meetings, typically held at the start of each day. The purpose of the meeting is for everyone on the team to know what has been done, who has done it, and what remains to be done, while asking team members to make commitments to each other. The meeting has a strict time limit of 15 minutes.
74
What is asked in the daily SCRUM?
In this meeting, every member of the team stands up and must answer the following three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?
75
What happens after the sprint is complete?
anything from the sprint backlog that is not complete at the end of the sprint goes back to the product backlog. Furthermore, the team hold two meetings:
1. Sprint review meeting
2. Sprint retrospective
Each meeting has a strict time limit, typically three hours.
76
What is the sprint review meeting?
the team review the work that was completed and present it to the customer.
77
What is the sprint retrospective?
the team reflect on the sprint and discuss what went well during the sprint, and what improvements they can make for future sprints.
